DragonFlyBSD 1.0 Released 272
eeg3 writes "One year after starting the project as a fork of the FreeBSD-4.x tree, the DragonFly Team is pleased to announce its 1.0 release. Check out the project's diary for a list of the improvements the project has implemented. Also, be sure to grab it from one of the mirrors."
Re:Serious question: (Score:5, Informative)
Check the DF interview article for more info.
FreeBSD 5 (Score:5, Informative)
Re:And we care... why? (Score:4, Informative)
For those of us hearing about this fork for the first time, could somebody explain what these people felt was so wrong about the FreeBSD tree that they decided to go off on their own? Or, to put it another way... what's the diference between DragonFlyBSD and FreeBSD?
With all due respect, they answer your questions right on their home page! RTFHTML!
Re:Serious question: (Score:4, Informative)
For a project that wanted to get away from FreeBSD, the final diary entry shows at least two imports from FreeBSD.
I can't be critical of a group of people that release their own BSD in their spare time, but I guess I'm not seeing SMP as being important enough to fork an entire BSD system.
Re:Serious question: (Score:5, Informative)
Check out the original announcement of DragonFlyBSD on the FreeBSD stable list:
http://lists.freebsd.org/pipermail/freebsd-stab
Re:And we care... why? (Score:4, Informative)
However, while committer relations have always been an issue, DragonFly split off from FreeBSD-5 over major architectural differences, not anything else. We really do feel that FreeBSD-5 is taking the wrong approach to SMP and building something that is so complex that it will ultimately not be maintainable. We think we have a better way.
You can find more information if you actually visit the project homepage [dragonflybsd.org], or read a fairly recent ONLamp.com interview [onlamp.com] with the developers.
Re:Packages? (Score:3, Informative)
We have been in rigorous discussion over what kind of ports/packaging system we want to have. We have already agreed that the core ports/packaging system visible to end-users should be a binary system rather then a source build system. This isn't to say that sources would not be made available for customization purposes, just that most users just want to get a port/package installed as quickly as possible. While the BSD ports/packaging system does have a binary install capability it is insufficient for our needs.
The other thing we've decided on is to give the ports/packaging system the ability to isolate installations. One of the biggest problems one has maintaining a large multi-use system is when upgrading a package for one particular subsystem. Upgrades to the packages for one subsystem can interfere with packages already installed for another, and sysops cannot afford to have upgrades break unrelated subsystems. So, for example, we want there to be isolation between the packages associated with, say, the mail subsystem, and packages associated with, say, a workstation user. The two subsystems might install the same package or might install different versions of the same package... we want that to work.
Also... in response to whether they might use pkgsrc, he replies...
We are considering everything. Nothing is set in stone yet.
Re:Packages? (Score:5, Informative)
The DragonFly team has been discussing what ports/packages system to move to (or to build one) that supports our requirements. We've investigated several existing packaging systems so far and are right now investigating OpenPkg (www.openpkg.org), as it has the multi-instance support that is an absolute requirement for us.
Keep in mind that the DragonFly *USERLAND* is still primarily FreeBSD-4.xish (though with all the C99 stuff from FreeBSD-5 integrated), so anything that runs on 4.x will run on DFly with only minor tweaking.
-Matt
Re:Serious question: (Score:2, Informative)
Once you use a dual cpu machine, you never want to go back to single cpu.
This is true whether you're using Windows 2000/XP or *BSD/Linux.
When running Windows 2000, misbehaving apps that would normally suck up 100% of cpu only consume 1/2 of available cpu power.
Only downside (and maybe this is good for the reason mentioned just now) is that most apps don't take advantage of multiple cpus yet.
Another comment I have is that hyperthreading and other pseudo-smp technologies are evolving--so SMP might become more important sooner than we think.
Re:Serious question: (Score:5, Informative)
They're dropping Perl from the base. Meaning that it won't be required in order to build the system. Also, it will be installed as a third party port (add-on software).
Actually, the 4.X branch still has Perl in the base system. The 4.X branch is where DFBSD forked from. The 5.X branch is where Perl was removed.
Before, there were quite a few "system" programs that were perl scripts. Those programs were rewritten as "C" programs in order to rid the dependency of Perl in the base system.
It's not a bad thing. A Unix OS really doesn't need Perl. And if you really do need it, you can easily install it via the ports system or via the package system. No biggie. Makes the base install smaller and neater.
Re:Serious question: (Score:5, Informative)
In nearly all cases you will be paying a premium for a SMP box over a UP box, so much so that if space is not an issue for you, and you have no special requirements (e.g. big honking database app), it will be more cost and maintainance effective to buy two single-cpu boxes then one dual-cpu box.
What this means is that I, at least, am turning off the SMP boxes in my machines room as fast as I can migrate them to new, faster, and far cheaper UP boxes.
On the flip side, though, both Intel and AMD are moving to dual core (and power-pc has had quad cores for a long time), so a SMP-efficient kernel design is as important as ever. Within the next 5 years I believe that all consumer cpus will be dual-core at a minimum.
Now all one needs to be able to do is seemlessly cluster them together, which is precisely one of our long-term goals! (seemless != the current hacks you see on Linux currently).
-Matt
Re:Serious question: (Score:5, Informative)
Intel and AMD will be coming out with dual core CPUs by the end of next year: 2 CPUs in one chip with a very speed interconnect between the two. A dual CPU configuration is often faster than a single CPU that's twice as fast. (On the other hand, Hyperthreading gives a measly 30% at most). A dual core Pentium series processor would have 2 real processors each with 2 logical processors: so a quad processor. Once all new computers have at least 2 processors in them, the operating systems that can utilize them effectively will be have a significant advantage.
Re:Examining this FreeBSD train wreck (Score:3, Informative)
http://lists.freebsd.org/pipermail/freebsd-curr
Re:Examining this FreeBSD train wreck (Score:5, Informative)
This is a very old troll [freebsd.org]. Don't fall for it. It's already scored at 4.
Re:Serious question: (Score:4, Informative)
I can't speak for whatever you're VA-Linux machines are, but aren't those Dells 2U rack mounts with something like 800 Mhz processors. Comparing that to a modern Athlon64 or Opteron isn't exactly fair.
For the record, my purely anecdotal evidence follows. SMP machines are an order of magnitude better than a single UP, even at a lower combined clock rate. They just seem to work better, balance things better, and never get particularly bogged down by any single process like a UP machine.
Re:Serious question: (Score:1, Informative)
Unfortunately the FreeBSD core has come to be dominated by political types who are short on engineering skills. They gave Matt the air and locked him out of CVS. The FreeBSD kernel is currently full of ugly expedient hacks *and* several intractable bugs.
Of all the BSD kernels, FreeBSD can now be considered the most hackish and ill conceived. It wasn't always this way, of course. But presently the FreeBSD development environment continues to favor the political solution over the technically correct one. OpenBSD and NetBSD both do much better on quality issues. I suspect that DragonFly will come to be highly regarded as well.
Re:future vs. now (Score:1, Informative)
The statistics sample from 2001 over a year was a cheap attempt to minimize Matt's contribution to the project. The reason why he has been mostly silent is probably one of the most prominent signs of his superior maturity. The fact that the official defense (mostly fronted by Greg, atm) he wasn't such a substantial committer is crap, for the most part. If one wanted to go by the stats, Jeff Robertson (sorry if I munged the spelling) would be one of the key committers, and his UMA system isn't even entirely ripe yet, it's just been committed within the sample timeframe. That suddenly phk is at the top of the list, is simple a result of his newest attempt to add another large chunk of bit rot to the project that he can later claim not to have time to maintain "unless someone is willing to pay for my time" (like the atm bits, the half-finished devd monster, et.al.) One can hardly get him to look at his malloc bits, that put his name in lights at some point in the long past.
Matt didn't contribute because he was convinced that that the smp development direction that was chosen (my impression at least from the archives and my fading memory) was overly complex, too complex for the number and talent level of the contributers involved, and that it would delay a release from the -current branch significantly. So he was right. I'll almost bet that that was a constant sore for John, who still hasn't gotten his long-promised, but little delivered re-entrant work done, but he always had time enough to object to any other commits that might help along the way. Strangely Julian and Matt could work together. One might attribute certain commits to both Matt and Julian (if that would matter anyway, since -core is interested in proving the opposite statistically).
If the issue here had anything to do with IPFW, then you all better get out your C-coder hats and take a little more time to fix that rotting pile of muck that has been the standard broken packet filter interface for FreeBSD long past its possible usefulness. A packet filter with no central maintainer which is subject to once yearly random feature bloat through some wild university project from Luigi. The brokenness that Luigi introduced (and the repository bloat through backing out and recommitting, ad absurdum) was probably no less a threat to security than anything Matt did. If the security officer was to be blatantly honest with himself, ipfw would be marked broken for either a full audit or full removal (just port obsd's pf or something that someone actually actively cares about).
You've alienated Jordan, Mike, Bill Paul (for all I can see), Greenman, you constantly rag on Terry, even though he's seen and done more with FreeBSD than most of you, O'Brien is on the verge of quitting (since he, like I, am not convinced that GEOM is anything more than an ego trip that will never be completely maintained or usefully documented). There are certainly others, too, that have attempted to make technically correct contributions, but didn't fit into the sort of paranoid "glee club" that core would like to have around them. You guys lack the talent to steer the positive from Matt into the project and let the crap fall by the wayside. I'm not saying Matt's rants are the most intelligent thing he's done, but he's sat by the wayside and watch the superstars beat up the code to a point where it's less stable, slower, and more bloated than it ever was. I, for one, can understand his frustration (as I can with Mike's, Jordan's, and a few others),
Re:uname(1) (Score:2, Informative)
A browser doesn't belong into a base system, compare with Debian which also doesn't have one by default.
Having the bash as default shell is a typical Linux user comment. There are better shells which are smaller, faster or more comfortable without being GPL licensed.
It's better to specify i386-freebsd4.8 for configure, which is not a fault of DragonFly, but of configure.
DragonFly does currently have a small scheduler bug which leads to skips e.g. of MP3 during high disc activity. Other tasks e.g. the pipe handling are supposedly better than FreeBSD.
Re:uname(1) (Score:2, Informative)
You really don't have to cvsup.