Slashdot Mirror
DragonFlyBSD 1.2 Released
vsarunas writes "The DragonFlyBSD Team is
pleased to announce
the official release of
DragonFly 1.2.0! Get it
here,
or here,
or as a torrent.
DragonFlyBSD is a continuation of the stable and high-performance FreeBSD
4 branch of FreeBSD with acpica5 and updated drivers so it runs on more
and newer machines. DragonFlyBSD can execute FreeBSD 4 and Linux binaries
and uses the FreeBSD ports collection. In addition, DragonFlyBSD is also
officially supported by pkgsrc. This release represents a significant milestone in efforts to improve
the kernel infrastructure. It features a standards-conformant
SACK implementation, improvements to the VFS layer, and a multithreaded
networking stack that utilizes the DragonFly lightweight message
passing system to communicate among processors. More information can
be found on Matt Dillon's journal and the
Status page
of the DragonFly wiki."
Fly Fred Fly!!!!
I would be interested in hearing from people how either of these BSD alternatives stack up as a desktop box.
If I wanted to install a BSD on my little home router/gateway, just for the sake of playing around with BSD, which BSD is the one to cut your teeth on?
With linux, the choice of distro is pretty much irrelevant - to me at least - because I wind up with virtually the same system, the only differences being the layout of some rc scripts.
The world of BSD isn't the same though, so which is the most prolific, or newbie-friendly, or has the widest support for common hardware, etc?
About the only thing keeping me from playing with BSD is the lack of a single "entry point".
I don't need no instructions to know how to rock!!!!
This is probably the best BSD out there performance-wise however, and I wouldn't be surprised if it begins to usurp OpenBSD server space in performance-critical installations soon.
I never vote for anyone. I always vote against.
-- W.C. Fields
for the performance differential between DragonFly and the regular FreeBSDs ?
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
It outlived the Pope.
I've been running DragonFlyBSD for a while now and it's always been stable and fast for me. This latest release has been rock-solid. I'd give DragonFlyBSD two thumbs up.
Oh, I can't be bothered. Somebody else do it.
I'm scared of numbers that can't be written as a fraction. It's an irrational fear.
nslookup wiki.dragonflybsd.org
Server: resolver.xs4all.nl
Address: 194.109.9.99
*** resolver.xs4all.nl can't find wiki.dragonflybsd.org: Non-existent host/domain
FreeBSD has not been the best FreeBSD release but it's *not* dead. 5.3 has been the *first* stable release of the 5.x series, and as expected is not as polished as it should be
I read the mailing lists (I'm not a FreeBSD user tough), and lots of work is happening. All those benchmarks you've seen where freebsd 5.3 loses were done with the 5.3 code which didn't incorported lots of performance work, just to get a stable 5.3 release
Expect 5.4 to be the real 5.x release ie: fast (LOTS of performance work is happening in the threading and VFS land) and stable (lots of critical bugs has been fixed, 5.3 was the first public release)
And no, FreeBSD 5 is not dying. RIght now FreeBSD is the BSD with better SMP support (and getting better), and dual core CPUs are starting to be sold this quarter. NetBSD and OpenBSD are not even near of the SMP support Freebsd has (oth of them detect several CPUs, but it will take all the year s it took to freebsd 5.x to use them efficiently, and most of the benchmarks done against NetBSD/OpenBSD are with only one CPU, which doesn't measure all the work done in the 5.x branch.
It was my impression that one of the reasons for FreeBSD-5.x was to rearchitecture several parts of the kernel for better SMP support. I know, I know, there were problems but it seems that it had to be done, and the sooner the better.
Now, if DragonFlyBSD continues down the road that was set by the 4.x train, what is going to be done about multiprocessor systems? I mean, multicore processors are right around the corner and other OS's (besides the BSD's I mean) like Linux are getting better and better(I won't even bother to mention Solaris).
I do not profess to be some kind of expert, anyone has anything informative to say about DragonFly's plans on this?
It outlived the Pope.
Are you sure he's dead? Has Netcraft confirmed it?
Treehugger? Treehugger... Treehugger!
I was excited when I heard a while ago about a new BSD variant because there are areas where BSD isn't specifically tuned to. However, Dragonfly BSD doesn't seem to address any particular deficit of the other BSDs. Every other BSD split has had a mission, OpenBSD to concentrate on security and NetBSD to concentrate on remaining cross-platform portability. What exactly is the reason for Dragonfly BSD?
I certainly don't see any kind of "mass disillusionment". FreeBSD 5.x has brought about added complexity for the sake of performance, namely in the SMP and multithreading arenas. These are areas where you will find the performance of NetBSD rather lacking. While NetBSD may win at certain meaningless microbenchmarks, the real world performance of FreeBSD, especially on multiprocessor systems, will generally be quite better. NetBSD has always had its primary focus on portability, whereas FreeBSD's has been primarily on performance. Microbenchmarks indicate, if anything, that FreeBSD has chosen higher overhead implementations which increase overall performance, whereas NetBSD has implementations whose simplicity incurs lower overhead on microbenchmarks.
Firefly has taken a radically different approach and is attempting to refactor a BSD kernel into a more microkernel-like operating system. So while FreeBSD decided to take the SunOS/Solaris-like approach, DragonFly has gone the way of Mach. This is a rather fundamental design schism, and is more indicative that microkernel concepts are still quite valid than any kind of mass disillusionment over FreeBSD 5.x. I think it's great that they're introducing microkernel concepts to a stable and mature POSIX compatible OS rather than starting from scratch, but sadly I think DragonFly will be an OS that has trouble finding its niche.
FreeBSD is the most polished and user-friendly BSD for your x86 box, by far.
..features a standards-conformant SACK implementation..
DragonFlyBSD: The BSD with Balls
insightful
Guess the upgrade will kill my little uptime :(
9:40PM up 187 days, 4:57, 7 users, load averages: 5.21, 5.16, 5.05
I have a lot of respect for Matt Dillon (as does pretty much everyone who's ever owned an Amiga), but I'm not sure yet that this is a good idea. The early versions of FreeBSD-5 were a mess, sure, but they've somehow managed to wrangle the new complexity into something that really works and works well.
Still, I wish nothing but the best for the whole DragonFly team. If their ideas pan out, then the whole *BSD culture can benefit from them. If they don't, then hopefully we can learn from their mistakes. Good luck, Matt!
Dewey, what part of this looks like authorities should be involved?
Have you tried to build any of those ports on FreeBSD? When I try it, I always have massive trouble with broken ports on FreeBSD. There are even periodic commit messages on the FreeBSD cvs-ports mailing list where huge numbers of ports get marked as broken and unbuildable in one fell sweep. Since DragonFlyBSD just uses the FreeBSD ports collection, you're basically taking your chances trying to compile any port.
It is official; Netcraft confirms: Pope John Paul II is dead.
One more crippling bombshell hit the already beleaguered Catholic community when the Vatican confirmed that John Paul II has died, ending his long papacy. Coming on the heels of a recent Netcraft survey which plainly states that Catholicism has lost more market share, this news serves to reinforce what we've known all along. Catholicism is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent survey of world religions.
You don't need to be a Kreskin to predict Catholicism's future. The hand writing is on the wall: Catholicism faces a bleak future. In fact there won't be any future at all for Catholicism because Pope John Paul II is dead. Things are looking very bad for Catholicism. As many of us are already aware, Catholicism continues to lose mindshare. Red ink flows like a river of blood.
All major surveys show that Catholicism has steadily declined in market share. Catholicism is very sick and its long term survival prospects are very dim. If Catholicism is to survive at all it will be among religion dilettante dabblers. Catholicism continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, Catholicism is dead.
Fact: Pope John Paul II is dead.
John Woo reprises his HK classic movie of redemption with a bullets-flying Open Source rendition about two BSD Projects and their struggle for respectability.
As you may not have noticed, the idea was to install it in his router/gateway, for the sake of playing around with it.
This means that:
[1] He already has the computer.
[2] A Mac Mini or iMac would simply not be viable from the hardware side of things.
Now, points for noting the FreeBSD livecds, but, really now, you shouldn't just take any opportunity you can to tout your pet OS, it doesn't really seem applicable here.
I remember sigs. Oh, a simpler time!
3:37PM up 1105 days, 21:09, 0 users, load averages: 0.00, 0.01, 0.00
This is my personal opinion, the biggest problem I had with other BSDs was the way they didn't fit with the way I prefer to do things. People with different preferences can easily have similar needs and come to different conclusions.
OpenBSD's goal is security, but as a side effect it's very easy to set up (eg hard to screw up and have an insecure configuration), and there are very few bugs compared to FreeBSD.
You don't tweak the kernel because the default one has almost everything that is supported. It makes the kernel bigger than it might otherwise need to be, but if you've got more than 16 mb of memory it doesn't matter.
There is a performance disadvantage (although PF performs well, and that's usually the only thing that matters), but things are easier to set up most of the time. If it's just a home gateway/router, your computer is probably bigtime overkill anyway, so you don't notice the performance disadvantage and you do notice the ease of configuration.
I probably wouldn't use it as a desktop OS because of the lack of software, but all the BSDs suffer from this. I couldn't even get by with FreeBSD as a desktop due to the lack of software. As a router, I haven't had any problems with getting software. What isn't in ports generally compiles fine. The one thing I haven't been able to get working with OpenBSD is a Haskell compiler, and the Haskell interpreter works fine so I don't care that much...
I rarely criticize things I don't care about.
Some /. poster told me that BSD was dead! What the hell!?
:)
Er, yeah, that was a joke. I love BSD, in fact my servers run NetBSD 2.0
- dshaw
Pkgsrc www.pkgsrc.org is extremely portable. Use _single_ portable packaging system, which works not only on BSDs. Don't double manwork for ${DEITY}'s sake!
Well, I have to say the slashdot response to this release is a marked improvement over the response to the last release. Most people are actually getting the concepts right this time! Kudos!
There are a few things I will clarify about the release, in particular about our approach to SMP and the inevitable comparisons against, FreeBSD.
On the SMP front what we are doing is basically rearchitecting big chunks of the kernel to operate efficiently in both UP and SMP environments, to be NUMA-friendly, and to be as maintainable as possible. Rather then throw mutexes around existing code we are undertaking a huge effort to make as many of our subsystems as mutex-free as possible by localizing the subsystem's operation on a per-cpu basis. Most of the time that means rewriting them from scratch.
One example of this is our core Light Weight Kernel Thread scheduler (LWKT). Each cpu has its own indepenant LWKT scheduler which means that any given copy of the scheduler itself does not have to deal with or worry about contention between cpus. The code is very, very clean. If you think about it a bit you will realize that such a beast would work just as efficiently in an SMP environment as it would in a UP environment, and that is indeed one of our major goals.
A second example of this is our network protocol stack (whos major architect is Jeffrey Hsu). A TCP connection goes through a hash and is routed to a tcp protocol handling thread on a particular cpu. If you have N cpus then your TCP connections will generally be split about evenly between the cpus. Any given connection is localized to its cpu which means that all the work related to that connection occurs on a single cpu and thus does not have to worry about or deal with contention between cpus... and operates as efficiently on a UP system as on a SMP system. The L1/L2 cache effects are an important bonus as well but the winning ticket is the ability for the protocol threads to run in a tight loop without needing to obtain or release a single mutex, lock, or other synchronizing mechanism other then the occassional critical section (which is a cpu-localize synchronization mechanism against interrupts).
Another major goal is to make the code more maintainable... readable, understandable, etc, without any major gotchas to an unwary programmer, especially new programmers who are attracted to the project. This does not mean that FreeBSD is less stable, but I certainly believe that DragonFly's code base is a lot easier to maintain and a lot easier for new programmers to work with, with a much shorter ramp-up time then someone trying to dig into the FreeBSD codebase and far fewer new bugs introduced. I am taking a long-term view here.
The problem with building an SMP friendly algorithm which requires a lot of synchronization to avoid contention (the mutex model) is that it is really easy to make a mistake and introduce a hard-to-find bug, especially if you are just ramping up on the codebase. The solution is to use algorithms (aka cpu-localization algorithms) that avoid the contention in the first place, and that is what we are doing. Regardless of FreeBSD's current stability (and I believe that FreeBSD is now far more stable then it was a year ago), they had to go and stomp hundreds of bugs introduced by experienced programmers. That's a red flag in my book, one that I am making a major effort to avoid in the DragonFly codebase.
In less then two years of work (with very little destabilization of the kernel during that period, by the way), we are now within shouting distance of FreeBSD's and Linux's SMP parallelism. The only area where we are still significantly behind is in boot-time interrupt routing. This release is the last release where the Big Giant Lock is going to be in the critical path. We spent a lot of time isolating subsystems in order to reach this point, to be able to now take the last few steps and actually turn the Big Giant Lock *off* on a thread by thread basis. Not only tha
> And no, FreeBSD 5 is not dying.
;)
Woa, thanks for the news!
I kinda thought that the 2.5 million active sites that FreeBSD is serving (it's much more than any given Linux distro; and it had a *25%* increase in one year) was a sign of imminent death.
--
Requiem for the FUD
Dragonfly is designed to make asynchronous communication between hardware resources very very lightweight and scalable. Right now SMP is not really very efficient. All of the locking that goes on to keep one processor from stepping on the other processor's toes ends up making all processors except the one with the lock wait for the lock to be released, for example. The idea is to organize the memory usage so that kind of waiting only happens when it is explicitly necessary.
Now, all of the sudden, the OS will scale to 64 CPUs. Maybe it would help to think of BSD scaling across processors like Solaris? Beyond that, it would allow vectorized (a whole batch of processing without if..then style branches) processing to happen cheaply off-core, perhaps on an asymmetric processor, or perhaps on another host across a network.. Like a server could use the GPU in the video card to do work...
--- Nothing clever here: move along now...
Yet another sickening blow has struck what's left of the *BSD community, as a soon-to-be-released report by the independent Commision for Technology Management (CTM) after a year-long study has concluded: *BSD is already dead. Here are some of the commission's findings:
.005% of internet servers. A recent attempt at a face-to-face summit in Boulder, Colorado culminated in an out-and-out fistfight between core developers, reportedly over code commenting formats (tabs vs. spaces). Hotel security guards broke up the melee and banned the participants from the hotel. Two of the developers were hospitalized, and one continues to have his jaw wired shut.
Fact: DragonflyBSD, yet another offshoot of the beleaguered FreeBSD "project", is already collapsing under the weight of internal power struggles and in-fighting. "They haven't done a single decent release," notes Mark Baron, an industry watcher and columnist. "Their mailing lists read like an online version of a Jerry Springer episode, complete with food fights, swearing, name-calling, and chair-throwing." Netcraft reports that DragonflyBSD is run on exactly 0% of internet servers.
Fact: the *BSDs have balkanized yet again. There are now no less than twelve separate, competing *BSD projects, each of which has introduced fundamental incompatibilities with the other *BSDs, and frequently with Unix standards. Average number of developers in each project: fewer than five. Average number of users per project: there are no definitive numbers, but reports show that all projects are on the decline.
Fact: There are almost no FreeBSD developers left, and its use, according to Netcraft, is down to a sadly crippled
Fact: *BSD has no support from the media. Number of Linux magazines available at bookstores: 5 (Linux Journal, Linux World, Linux Developer, Linux Format, Linux User). Number of available *BSD magazines: 0. Current count of Linux-oriented technical books: 1071. Current count of *BSD books: 6.
Fact: Many user-level applications will no longer work under *BSD, and no one is working to change this. The GIMP, a Photoshop-like application, has not worked at all under *BSD since version 1.1 (sorry, too much trouble for such a small base, developers have said). OpenOffice, a Microsoft Office clone, has never worked under *BSD and never will. ("Why would we bother?" said developer Steven Andrews, an OpenOffice team lead.)
With these incontroverible facts staring (what's left of) the *BSD community in the face, they can only draw one conclusion: *BSD is already dead.
Fact: DragonflyBSD, yet another offshoot of the beleaguered FreeBSD "project", is already collapsing under the weight of internal power struggles and in-fighting. "They haven't done a single decent release," notes Mark Baron, an industry watcher and columnist. "Their mailing lists read like an online version of a Jerry Springer episode, complete with food fights, swearing, name-calling, and chair-throwing." Netcraft reports that DragonflyBSD is run on exactly 0% of internet servers.
Man, Ill say -- anyone here on the mailing list? The name-calling and nit-picking are out of control. I cant' stand it.
// Btw: DragonFlyBSD is missing from this list because it's still too young for production use, not because it's less cool!!
... facts are facts. ;)
FreeBSD:
FreeBSD, Stealth-Growth Open Source Project (Jun 2004)
"FreeBSD has dramatically increased its market penetration over the last year."
Nearly 2.5 Million Active Sites running FreeBSD (Jun 2004)
"[FreeBSD] has secured a strong foothold with the hosting community and continues to grow, gaining over a million hostnames and half a million active sites since July 2003."
What's New in the FreeBSD Network Stack (Sep 2004)
"FreeBSD can now route 1Mpps on a 2.8GHz Xeon whilst Linux can't do much more than 100kpps."
NetBSD:
NetBSD, for When Portability and Stability Matter (Oct 2004)
NetBSD sets Internet2 Land Speed World Record (May 2004)
NetBSD again sets Internet2 Land Speed World Record (Sep 2004)
OpenBSD:
OpenBSD Widens Its Scope (Nov 2004)
Review: OpenBSD 3.6 shows steady improvement (Nov 2004)
OpenSSH (OpenBSD subproject) has become a de facto Internet standard.
*BSD in general:
..and last but not least, we have the cutest mascot as well - undisputedly. ;)
Deep study: The world's safest computing environment (Nov 2004)
"The world's safest and most secure 24/7 online computing environment - operating system plus applications - is proving to be the Open Source platform of BSD (Berkeley Software Distribution) and the Mac OS X based on Darwin."
BSD Success Stories (O'Reilly, 2004) (pdf) ~ from Onlamp BSD DevCenter
"The BSDs - FreeBSD, OpenBSD, NetBSD, Darwin, and others - have earned a reputation for stability, security, performance, and ease of administration."
--
Being able to read *other people's* source code is a nice thing, not a 'fundamental freedom'. -- Requiem for the FUD
IT IS OFFICIAL; WIRED NEWS CONFIRMS: LINUX IS SUPERIOR TO *BSD
*BSD is Dying, Says Respected Journal
Linux advocates have long insisted that open-source development results in better and more secure software. Now they have statistics to back up their claims.
According to a four-year analysis of the 5.7 million lines of Linux source code conducted by five Stanford University computer science researchers, the Linux kernel programming code is better and more secure than the programming code of *BSD.
The report, set to be released on Tuesday, states that the 2.6 Linux production kernel, shipped with software from Red Hat, Novell and other major Linux software vendors, contains 985 bugs in 5.7 million lines of code, well below the average for *BSD software. NetBSD, by comparison, contains about 40 million lines of code, with new bugs found on a frequent basis.
*BSD software typically has 20 to 30 bugs for every 1,000 lines of code, according to Carnegie Mellon University's CyLab Sustainable Computing Consortium. This would be equivalent to 114,000 to 171,000 bugs in 5.7 million lines of code.
The study identified 0.17 bugs per 1,000 lines of code in the Linux kernel. Of the 985 bugs identified, 627 were in critical parts of the kernel. Another 569 could cause a system crash, 100 were security holes, and 33 of the bugs could result in less-than-optimal system performance.
Seth Hallem, CEO of Coverity, a provider of source-code analysis, noted that the majority of the bugs documented in the study have already been fixed by members of the Linux development community.
"Our findings show that Linux contains an extremely low defect rate and is evidence of the strong security of Linux," said Hallem. "Many security holes in software are the result of software bugs that can be eliminated with good programming processes. However, we found that the BSDs seem to believe that they can just make up facts rather than write decent code. It is our belief that all of the BSD projects are on the decline and will be dead within a year."
The Linux source-code analysis project started in 2000 at the Stanford University Computer Science Research Center as part of a large research initiative to improve core software engineering processes in the software industry.
The initiative now continues at Coverity, a software engineering startup that now employs the five researchers who conducted the study. Coverity said it intends to start providing Linux bug analysis reports on a regular basis and will make a summary of the results freely available to the Linux development community.
"This is a benefit to the Linux development community, and we appreciate Coverity's efforts to help us improve the security and stability of Linux," said Andrew Morton, lead Linux kernel maintainer. Morton said developers have already addressed the top-priority bugs uncovered in the study.
YHBT. YHL. HAND.
my servers run NetBSD 2.0 So that explains why they're so slow and hackable.
Now if only Apple would use DragonFly as the basis of Mac OS X's BSD bits... what a FANTASTIC operating system it would be... =)...