Slashdot Mirror
DragonFly BSD Announces 1.0RC1
CoolVibe writes "Matt Dillon announced the availability of DragonFly BSD's 1.0 Release Candidate #1. Get it at Dragonfly BSD's site (please use a mirror or post mirrors as comments). Changes and features include: variant symbolic links, UDF support, lightweight kernel threads, message passing, GCC 3.4 in the tree, binutils 2.14, Kernighan's awk 2004-02-07, BIND 9.2.4 rc4, CVS 1.12.8, libpcap 0.8.3, tcpdump 3.8.3, less 381, MMX/XMM kernel optimizations are now on by default, greatly improving bcopy/bzero/copyin/copyout performance for large (>4K) buffers, XIO, acpica5, new AC'97 codec support, network stack revamping, long standing bug fixes for wide variety of support and stability issues, and way, way, way more. A new installer is also in the works that uses DragonFly's new CAPS IPC mechanism. The installer beta is available from LiveBSD. (Not updated to RC1 just yet, but it gives a nice idea of the progess made)"
MD5sum: MD5 (dfly-1.0RC1.iso.gz) = 663bc0ce4c077c4eeb38792e846210ea
Additionally, a torrent and list of mirrors are also available.
www.sitetronics.com/wordpress
Support for variant symbolic links is exciting. That makes it really easy to support 64/32-bit modes on Opteron systems. Similarly, it makes it easy to support variant ABIs for (e.g.) C++ runtime environments without encoding ABI versions into library names, but do look out for combinatorial explosion...
Our developer community is rather small; and we have an active IRC community of about 40 people (which includes a good number of our developers). We generally keep in touch this way, and of course, through the mailing lists.
Anyway, I'll speak for myself here: If I've ever needed a project to work on, I've found the DragonFly community to be the most responsive and helpful community in both finding and completing a project. And from the lists, I see that many people do actually contribute patches and we do have a large community of ``lurkers'' as it were.
www.sitetronics.com/wordpress
AT the highest level (remember that the BSDs share code very freely):
FreeBSD: stable, high performance on x86 and a couple other chips.
OpenBSD: Security, audited codebase.
NetBSD: Portability - if it runs 32 bits, it runs NetBSD.
DragonFly BSD: a fairly radical rewrite of the kernel, bringing in message passing inspired by Amiga and a bunch of other goodies that is too radical for a more stability-focused FreeBSD.
Not sure what you mean by "what apps is it suitable for". At current, DragonFly BSD hasn't even released version 1.0, so not suitable for production. And if you're not in production, choose anything you want.
I've been using it since february, and let me tell you, it's great! It's fast, and generally stable (between major changes, it is a prerelease OS don't forget!), and it runs legacy Linux and FreeBSD binaries at native speeds.
;^)
And it is being redesigned at it's core to be a clustering capable operating system (although this is not in just yet). Soon it will be able to run user mode drivers, greatly enhancing the stability of the system to levels that no other current OSS project can boast (and still be telling the truth
This truely is what a modern UNIX-like OS should be!
Way to go Matt and the rest of the DragonFly team!
Message passing is used by micro-kernels, yes. There are other examples though. IIRC Solaris does have some primitives in its kernel. For the normal usage case, in-kernel message passing allows us to better separate work and simplifies development without all the overhead a micro-kernel involves.
As I understand it, the point of lwkt is to maximize the benfit of CPU cache by keeping threads local to a given CPU. That's a slightly more batch oriented approach, and in SMP systems I think it will provide benefit for batch type jobs. But I think it will reduce the freedom of the kernel to run interactive stuff IMMEDIATELY, like Linux 2.6 and FreeBSD 5.x do now. They're both quite good at keeping interative tasks responsive.
I'm not an expert and it may actually increase performance because of the cache-- I don't know.
From what I've read though, I think that the overall DragonFlyBSD strategy has a credible chance of beating the performance of FreeBSD, Linux, and Solaris on SMP systems, especially for stuff like dynamic content and databases. I'm not saying it's a bad idea, I'm just saying that I can think of a few possible negative side effects.
I rarely criticize things I don't care about.
W^X, ProPolice, randomized shared library loading. All of these happen to ANY program compiled from source, with or without code auditing, and make overflows pretty damn hard to exploit, probably impossible.
Hehe, okay. I guess I simply misunderstood the type of information you were looking for, so forgive what others apparently have called my ``hotheadedness.''
:)
As has been explained a gazillion times, DragonFly is a fork of the FreeBSD, which started with the FreeBSD 4.8-RELEASE code.
The kernel features listed in the original post attempt to utilize features of modern processors and take into account modern ideas and research when developing new features.
One could say that our focus is on performance. A lot of the work that Matt, Hiten, Joerg and Jeffery Hsu are doing involve cranking up performance. This isn't to say that we aren't worried about stability or security, though.
The ``apparent misguided path of FreeBSD-5'' is a long political story and is one which I really don't like to get into much (because each side can be stressed and turned into a war), but basically Matt Dillon thought that the way the FreeBSD 5 series was handling SMP was irrational. His main reasons were that:
a) A mutex system would clutter up the kernel with tons of locks and obfuscate the code, effectively requiring experts in the area to continue further development,
b) Future developers would have to make sure that they understand how the mutex API works so that they don't stumble into weird SMP problems later,
c) It's heavyweight and isn't as fast as it could be.
Our model also opens up the future for really neat things like SSI (single system image), which shouldn't be terribly hard to implement. Our TODO list is large, and it's going to take a while, but I think we all enjoy working together on the project. It's a nice friendly community. Come check it out sometime
www.sitetronics.com/wordpress
Linux does "W^X", aka non executable mappings in non-leet speak
/usr/libexec/ld.so /usr/lib/libtermcap.so.9.0 /usr/lib/libc.so.30.3 /usr/local/bin/bash /usr/libexec/ld.so /var/run/ld.so.hints
... except via PAX, although I'll be glad to be corrected. Of course, not many major distros actually use PAX or Propolice, where OpenBSD delivers tested binary packages for 10 (or whatever the current number is) different architectures. I'm not interested in security where I have to patch and recompile my entire OS.
No it doesn't. W^X ensures that there are no pages in a process's address space which are writable and executable and separates them. Not just a non-exec stack. For example on i386:
0250B000 24K read/exec
0280A000 4K read/exec [ uvm_aobj ]
06B04000 188K read/exec
0861F000 508K read/exec
1C000000 348K read/exec
2250B000 4K read
2250C000 4K read/write [ anon ]
(trim)
7EB90000 4K read/write [ anon ]
865FF000 12K read
CDBFE000 28672K [ stack ]
CF7FE000 4040K read/write [ stack ]
Notice how the exec mapping stop, and the write mapping begin. This means on i386 the segment registers can be used to enforce read/write/execute - you dont need a new processor with per-page NX (although that works as well of course).
It does randomized shared library loading, and this doesn't require toolchain support in Linux, probably because its design is cleaner than OpenBSD's
Vanilla Linux doesn't
Linux can quite easily be built with propolice, and it has a very fine security infrastructure with SELinux. More advanced than what OpenBSD has.
Very funny. The average sysadmin understands the UNIX security model. Not many understand the insanely complex SE Linux thing.
Linux does a lot of things better than OpenBSD, but really, security just isn't one of them. I always regret posting to Slashdot to try to correct some of the cluelessness here, so this will be my last post here for a while again.
Well technically it can be compiled with either the 3.x or 2.9.x versions.
Both are available. You just have to set your CCVER variable.
I eat bees -- they taste stingy.