DragonFly BSD: Daily Snapshots Available

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."

Comments

entirely new direction ?

[raffe]

"... entirely new direction from the one taken in the FreeBSD-5 series."

What is so entirely differnet? No , not a flame i just dnot know...

Re:entirely new direction ?

[ukpyr]

From DragonFly home page [http://www.dragonflybsd.org/Main/]:
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.

DragonFly

[m.dillon]

It should be noted that DragonFly, being a fairly new project, is not meant to be production-ready for some time. Despite the short time since we forked from FreeBSD-4 we have made considerable progress, including getting a fully optimized light weight kernel thread scheduler in place, asynchronous IPI messaging (between cpus), a high performance slab allocator, and other items.

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.