DragonFly BSD: Daily Snapshots Available 57
Dan writes "Simon Schubert has offered to provide Daily Snapshots of DragonFly. The snapshots are available on FTP and HTTP. Simon says this is for users who want to give DragonFlyBSD a try and don't want to go through the FreeBSD4/cvsup/buildworld steps., and as a world tinderbox (logs are available for each run). DragonFly is an operating system and environment designed to be the logical continuation of the FreeBSD-4.x OS series. These operating systems belong in the same class as Linux in that they are based on UNIX ideals and APIs. DragonFly is a fork in the path, so to speak, giving the BSD base an opportunity to grow in an entirely new direction from the one taken in the FreeBSD-5 series."
entirely new direction ? (Score:3, Insightful)
What is so entirely differnet? No , not a flame i just dnot know...
Re:entirely new direction ? (Score:5, Informative)
DragonFly is an operating system and environment designed to be the logical continuation of the FreeBSD-4.x OS series. These operating systems belong in the same class as Linux in that they are based on UNIX ideals and APIs. DragonFly is a fork in the path, so to speak, giving the BSD base an opportunity to grow in an entirely new direction from the one taken in the FreeBSD-5 series.
It is our belief that the correct choice of features and algorithms can yield the potential for excellent scaleability, robustness, and debuggability in a number of broad system categories. Not just for SMP or NUMA, but for everything from a single-node UP system to a massively clustered system. It is the our belief that a fairly simple but wide-ranging set of goals will lay the groundwork for future growth. The existing BSD cores, including FreeBSD-5, are still primarily based on models which could at best be called 'strained' as they are applied to modern systems. The true innovation has given way to basically just laying on hacks to add features, such as encrypted disks and security layering that in a better environment could be developed at far less cost and with far greater flexibility.
We also believe that it is important to provide API solutions which allow reasonable backwards and forwards version compatibility, at least between userland and the kernel, in a mix-and-match environment. If one considers the situation from the ultimate in clustering... secure anonymous system clustering over the internet, the necessity of having properly specified APIs becomes apparent.
Finally, we believe that a fully integrated and feature-full upgrade mechanism should exist to allow end users and system operators of all walks of life to easily maintain their systems. Debian Linux has shown us the way, but it is possible to do better.
DragonFly is going to be a multi-year project at the very least. Achieving our goal set will require a great deal of groundwork just to reposition existing mechanisms to fit the new models. The Goals link will take you to a more detailed description of what we hope to accomplish.
Re:entirely new direction ? (Score:1)
Re:entirely new direction ? (Score:2)
Oh, come on, moderators! Is it so hard to spot a troll? Well, congrats to Mr. Anonymous Coward for his +2, informative for this brilliantly crafted drivel. It was actually fun to read, too.
Re:entirely new direction ? (Score:1)
Re:what is it? (Score:1)
They are also planning large changes to the packaging system. The new system will be similar to Debian's apt but will make it easier to upgrade only portions of the system (like only one application).
Re:What We Can Learn From BSD (Score:1)
snapshot and stop meaningless belief into so-called
authorities such as RMS and ESR.
Oh, wrt the filesystems: when ensuring absolute
data integrity, ufs outperforms ext3.
Measures: hard disc hardware write cache off,
softupdates on (ffs)
I'm happy with my MirBSD, and I hope other people
can profit from it - and be it just that I fixed
some bugs in OpenBSD and NetBSD code.
What is the purpose of MirBSD ? (Score:1)
Is it optimized for pentium class processors and therefore offers a comparable speed increase than the other BSDs ? Why would a person need to use MirBSD ?
I found a Development Plan, but that's more like a todo list, and doesn't list the goals of the project.
Please fill me in.
Re:What is the purpose of MirBSD ? (Score:1)
Well, the short story is: MirBSD is OpenBSD-mirabile,
and the name got too long, plus I needed a CVS tag.
The long story: I'm a happy OpenBSD user, but sometimes
I'm just not OK with the decisions made by our
"benevolent dictator" Theo de Raadt. That's why I started
to modify my tree locally - starting with wtf(1):
>>> http://marc.theaimsgroup.com/?m=103065556502499
Because I got positive feedback for not always OKing Theo,
I decided to make
Re:What We Can Learn From BSD (Score:1)
Re:What We Can Learn From BSD (Score:1)
metadata) only in one circumstance (tested that):
You forgot to disable the hard disc hardware
write cache. (This must be done for journalling
FSes as well if you want data integrity.)
FreeBSD does this with the bootloader, in OpenBSD,
you execute
# atactl wd0 writecachedisable
or use the interactive command for SCSI discs:
# scsi -f
and set the WCE entry to 0.
The daily snapshots (Score:1, Interesting)
To be fair, until they get all the messaging stuff done, it still primarilly "developers only", but as they hope to do all of this in small, "bite sized chunks", it's inexcusable that the insta
Re:The daily snapshots (Score:1)
Go back to sleep and wake up in 2020. Then troll again iof your old linucks setup permits.
It's a serious project. Take a few days to shift your world view please.
Re:What I know about *BSD (Score:1)
1. You can not play games on it. /usr/ports/games/ | wc -l
The ports collection begs to differ...
sh-2.05a$ ls
526
2. It cannot be used by my grandma.
Your one almost good point. Although if you set your grandma up with a system preinstalled w/ BSD that booted into a GUI she could handle it as easily as she can hand
Re:What I know about *BSD (Score:1)
1. You can not play games on it. If the BSD has Linux binary compatibility, you can indeed.
3. It lacks a GUI of any note. Is there no XFree86 for BSD?
4. There is no support available for it. Again, depends on your BSD.
6. It cannot be run on the x86 platform. Sefsckinwat?! I have been using PicoBSD for years - ON A 386DX!!!
9. It is incompatiable with GNU/Linux. Not necessarily. FreeBSD at least has a Linux binary compatibility module.
10.It is dying. W
Re:I think these Linux guys are seriously scared (Score:1, Interesting)
No, here on Slashdot they are in the popular circle -- Linux (and Windows). They get some heady thrill from being in the popular group for once. It's kind of sad how they keep autistically posting the same thing over and over.
Re:I think these Linux guys are seriously scared (Score:2)
But then, autism or its close cousin Asperger's disorder are probably common among a lot of Slashbots.
-uso.
short explanation on dragonfly (Score:1)
That's all. They disgree about sopme/most of 5.X design decisions.
I say let 'em roll and we'll see if it rocks later
DragonFly (Score:3, Informative)
DragonFly will be doing things that the other BSDs simply cannot, primarily due to having to support a large existing user bases. For example, right now I am in the midst of completely rewriting the VFS file path lookup code (namei, lookup, vfs_cache_lookup, VOP_LOOKUP, VOP_CACHEDLOOKUP). This is not something the other BSDs would be able to easily do though it might just be possible to port it to FreeBSD-5 once it is done. But the results are going to be phenominal... an almost complete removal of the vnode locking requirements for path lookups, and at least a 3x improvement in path lookup performance. We are also converting all system calls and both the file descriptor and DEV interfaces to messaging interfaces and asynchronizing the path all the way through using Amiga-style semi-synchronous I/O messaging (and it would be a serious mistake to compare the methodology to, say, Mach messaging), so it will be possible to support userland threads without eating a kerneland stack context for each running operation. There are many goals and this is going to be a multi-year project.
It is quite possible that DragonFly will be an alternative upgrade path for FreeBSD-4.x users rather then going to FreeBSD-5. FreeBSD-4 is nearing its end-of-life and DragonFly is really going to give FreeBSD-5 (and linux for that matter) a run for its money. We are taking an entirely different approach to SMP, one that involves asynchronous inter-cpu messaging to resolve conflicts and requires far fewer mutex operations in the critical path. Those interested in understanding the new approach should read DragonFly's light weight kernel threading code (kern/lwkt_thread.c and friends).
The first user release will probably not happen for a year. In the mean time, only serious developers and knowledgeable programmers should really be using DragonFly.