Learn about Linux
Download Linux
Get Linux helpSpecial Offers
Feature: BSD
DragonFlyBSD 1.0A: A strong start
Share
Print
CommentsDon't mistake DragonFlyBSD 1.0A for a complete, finished, polished operating system. At this stage of development, DragonFlyBSD isn't good for much, as it has problems with SMP on systems that use Hyper-Threading Technology, and the XFree86 port (among others) didn't compile properly for me despite using the special compatibility overrides. I also had problems compiling the userland, which in BSD is called "the world." These problems rule out a lot of customization, and the lack of a working XFree86 port disqualifies DragonFlyBSD for desktop use. I'm not quite sure why this release was necessary if it doesn't fully work yet, but here is what you'll be up against if you decide to give it a try.
By the way, you might be wondering why the version number has an A after it; it's because the 1.0 release had a critical bug relating to disk slice sizing.
FreeBSD, but better?
DragonFlyBSD's FreeBSD origins are quite clear -- the boot loader, boot selection screen, Ports tree, and source tree all share structural and functional similarities to FreeBSD, even if in some cases the code is totally different. The outdated FreeBSD sysinstall installation utility has been replaced by installer. It's still ncurses-based, but it's easier to navigate and use. In spite of the easy installation procedure, you have to know your way around FreeBSD in order to use DragonFly, as the manual pages are all still FreeBSD-centric and there is no handbook or guide to help you learn the system.
FreeBSD has two discs in the full edition: an install disc with packages and a second LiveCD for diagnostic purposes. DragonFlyBSD has only one disc which serves both purposes, but there are only seven precompiled packages included on the CD. You can't connect to the Internet to download more packages or the Ports tree from within the installation program like you can with FreeBSD. At the end of the DragonFly install process you are not presented with a system that is capable of doing anything of substance, and you're not given the resources to immediately remedy that.
The FreeBSD Ports system is available, but neither it nor the DragonFlyBSD Ports tree are installed by default; same with the source tree (the source code for the entire base system -- the kernel and the userland). In order to get them onto your system you have to modify and use some cvsup supfiles from the /usr/share/examples/cvsup directory, then wait several hours (the DragonFlyBSD cvsup servers are few and quite slow) for everything to download. Once that's finished you can recompile your kernel and install programs -- well, a few of them at least. If all you want to do is install software, it doesn't take long to download the FreeBSD and DragonFlyBSD Ports trees.
The DragonFlyBSD Ports tree consists only of overrides for the FreeBSD Ports tree. In other words, you'll always use the FreeBSD Ports tree -- which is in /usr/ports -- to install programs, but some of them won't work properly in DragonFlyBSD because of code differences in the base system. In those instances you must manually install the compatibility override from /usr/dfports. If you're going to use DragonFlyBSD for a desktop system, it might be helpful to install all two dozen or so entries in the dfports directory to begin with.
If you've never had the pleasure of using the Ports system in a BSD operating system, it's simple: navigate to the directory of the program you want to install and then type make install and all of the correct source code and patches are downloaded, configured, and installed for you. Alternatively you can install a precompiled binary package by using the pkg_add command. Like FreeBSD, DragonFlyBSD uses name resolution for packages, so you don't have to specify the exact location and file name. If you want to install the portupgrade program, for instance, you'd either go to /usr/ports/sysutils/portupgrade and then type make install to compile it from source, or from any directory just type pkg_add -r portupgrade to retrieve and install the binary package. Dependencies are automatically calculated and installed for you.
So what exactly is the difference between DragonFlyBSD and the later FreeBSD 4.x releases? Here's what's listed on the DragonFlyBSD Web site:
- Core threading, process, interrupt, and network infrastructures have been replaced
- A multiprocessor-friendly slab allocater has been added
- A Light Weight Kernel Threading (LWKT) system that is separate from the dynamic userland scheduler
- A fine-grained system timer abstraction for kernel use
- A fully integrated light weight messaging system, and a core IPI (Inter Processor Interrupts) messaging system for inter-processor communications
The DragonFlyBSD team claims to have kept the renowned stability of the FreeBSD 4.x branch even though major subsystems have been replaced. Unfortunately the word "stability" is such a broad and vague term that it's hard to decide if that's true. To me, a stable system is one that works without needing to be constantly fixed. That notion of stability is predicated on the assumption that the system actually works to begin with. With DragonFlyBSD, as mentioned previously, there are at least some major Ports that do not compile, and the system locked up if I tried to compile in SMP support for my Hyper-Threaded machine. This, to me, is not stable.
Performance
The only previous performance numbers I have for the hardware on which I wanted to test DragonFlyBSD are with FreeBSD 5.2.1-RELEASE, which would be an excellent basis for comparison with DragonFlyBSD. The problem is, I couldn't get SMP to work on DragonFlyBSD without the system locking up just before the login prompt. I couldn't even SSH in from another machine on the network. The only way I could compare performance is by reinstalling FreeBSD 5.2.1, disabling SMP, and re-recording the test scores. This would have produced misleading results, as the processor's crowning feature would be disabled -- hardly a real-world scenario. The whole process of collecting data for a special case is a little too much trouble to go to at this point, as the results are likely to change quickly; when DragonFlyBSD is more mature I'll do a full-scale performance comparison with Open, Net, and FreeBSD.
With most operating systems I prefer to test on a number of different platforms to gauge hardware support and performance. Generally I start out with my most difficult system, based on an Athlon 64 processor, but in this case I started out with my most compatible modern system (Intel D875PBZLK motherboard, 3.2E GHz Pentium 4 CPU) -- a system that works with OpenBSD 3.5 and FreeBSD 5.2.1. If DragonFlyBSD 1.0A doesn't work on this system, it isn't likely to have better results on the others. Again, I'll wait for at least the next release before I give it the full run. Until then, the problems I've had trying to get DragonFlyBSD to work have been showstoppers, making further testing an exercise in frustration. Another factor is the long wait to download the source tree -- more than half a day on a very good broadband connection. By the time I finished testing on all of my systems, the next release would be out.
Conclusions
This may seem a negative review, but it isn't, really. I'm impressed with the efforts of Matt Dillon and the rest of the DragonFly team -- I think they've come a long way in a relatively short period of time. If they can manage to continue on the same track, DragonFly will easily overshadow FreeBSD in terms of technical merit, code quality, and performance. At this point I would not consider it for production use, as it just doesn't seem to work very well and it's difficult to ascertain which Ports will install and which will error out. The DragonFly team admits that this will be a multi-year project, although one could say that about any free software operating system at any point in its development.
Even though DragonFlyBSD seems to have gotten off to a rough start, the team has made lots of progress toward a superior BSD, and I look forward to the next release, but they won't get me to switch to DragonFlyBSD until I can actually use it for something other than a review.
| Purpose | Operating system |
| Manufacturer | The DragonFlyBSD Project |
| Architectures | x86 |
| License | BSD |
| Market | Servers, Unix workstations, advanced users |
| Price (retail) | Free to download |
| Previous version | Forked from FreeBSD 4.x |
| Product Web site | Click here |
Jem Matzan is the author of three books, a freelance journalist and the editor-in-chief of The Jem Report.
Comments
on DragonFlyBSD 1.0A: A strong startNote: Comments are owned by the poster. We are not responsible for their content.
The cvsup servers that I tried were abysmally slow. The worst one was the default server... since it's been about two weeks since I last used DragonFly, I can't remember the other server I tested. Was the main one cvsup.dragonflybsd.org? Whatever it was, I was glad I had another machine and a kvm switch so I could work on other things while the source tree crawled onto my test system.
Packages are irrelevant to my point about the non-compiling XFree86 port. As a user, I don't care about reasons and excuses as to why things don't work -- all I know is, I followed the directions and it didn't compile. Did you expect me to lie and say everything was perfect? You should treat this as an opportunity to fix what is broken so that the next version can be superior. You think this is that bad as far as negative reviews are concerned? Ridiculous -- I badly wanted to like DragonFly, but it didn't work right.
I thought DragonFly would have been better than what I used for this review. I was hoping to switch to it from FreeBSD 5.2.1 on my main workstation, actually. I hope the DragonFly team continues development and produces an excellent second release, but 1.0A just isn't usable for people with HT machines or those who need a reliable Ports tree.
-Jem
#1. CVSUP was slow because the main sites t1 was downgraded to an ADSL line. It clearly showed this on the forums.
#2. You should have defind X_WINDOW_SYSTEM before building X. This is a FreeBSD ports change that recently happened.
#3. SMP would most likely work if you boot w/o ACPI and or turn off HTT in the BIOS. This is actually a known bug no CERTAIN machines.
#4. The FAQ covers most of the problems you've encountered. Did you read it?
At any rate, you really should redo this review and spend more than 20 minutes on playing with DFLY if you want to do a fair and balanced review.
All of us would have loved to help you via IRC before spreading FUD.
Regards.
I had no idea the DragonFly community was filled with people like you. If I'd known, I would have ignored DragonFlyBSD accordingly. When I repost this review on my site in two weeks, I will make sure that I update it to reflect the spirit of the DragonFly community.
FYI: Just because you disagree doesn't mean it's FUD. This is nothing close to FUD. Maybe you need a trip to the Hackers Dictionary?
-Jem
You could have just subscribed to the mailing list, a newsreader isn't required to post them to it.
I spent several days testing this operating system to make sure that it wasn't a silly mistake on my part. I read what meager docs there were and followed all of the directions in UPDATING.
If you used the installer, you would have noticed the huge "EXPERIMENTAL SOFTWARE" notice when installing DragonFly.
I had no idea the DragonFly community was filled with people like you. If I'd known, I would have ignored DragonFlyBSD accordingly. When I repost this review on my site in two weeks, I will make sure that I update it to reflect the spirit of the DragonFly community.
I had no idea that NewsForge allowed authors with such an unprofessional level of journalism like you to post here. If I'd known, I would have ignored any NewsForge articles accordingly. When I get to posting a review on my site later this year, I will make sure that I update it to reflect the spirit of the NewsForge author community.
Maybe you need to learn how to take helpful suggestions?
-Someone not associated with DragonFlyBSD or its community in any way
Lets have a little look.
http://www.dragonflybsd.org/main/forums.cgi
"The DragonFly project has several forums for discussions. These forums may be accessed through newsgroups or mailing lists. Posts to newsgroups will be forwarded to the appropriate mailing list and vice versa."
"To subscribe to a mailing list, please read bestserv1.html, then send a subscription request to the appropriate list email address as shown below."
Yes, you really did a great job on this review.
Also, you completely unprofessional comment, about "the DragonFly community was filled with people like you", is as far from the truth as it can be. We just dont tolerate people taking a piss on the software that we use and work on, when not having any valid points at all.
Were there no non-hyperthreading machines around to benchmark on? The review hinted that other machines were available to test on.
I really dont think that you even tried to use the mirrors.
You do have a valid point though, the src tree should really be on the CD. But it does not take one and a half day to download the sources via cvsup from my server. That has to be an error on your side.
As other people pointing out, much of the problems you experienced are either freebsd-related (like building X) or answered in the FAQ. If you would take your time to search the dragonflybsd archives for your SMP problem you would have seen alot of responses about it (disable ACPI or remove the serial console).
From what I read from your review, you did not take your time to investigate problems at all. You just said "this and that didnt work. too bad." without even trying to fix it.
Next time, do your homework.
- Erik
erik(aat)pentadon.com
Installing it on my test server I see almost the same performance then 4.9 but slightly better then 4.10.
Not bad for a technology preview, If 5.2.1 had that stability I probably didn't even bother by trying this out. However it looks like its going to replace my production servers in a while.
"A year ago, when the DragonFlyBSD project was announced, I scoffed at it. "A FreeBSD fork, and they're not even using the new technology release!" I figured it was just a disgruntled developer's one-man crusade against the programmers he didn't get along with on the FreeBSD team."
<nobr> <wbr></nobr>...a reviewer who makes snap judgments about things without getting all the facts doesn't fill you with confidence?
But what it did do was pique my curiosity and get me to thinking maybe the OS was worth a gander despite the troubles he mentioned.. hey.. every OS has its warts, and 1.0 is always gonna be rough.
That is, right up until I saw how the community reacts if someone fails to declare it the Best OS EVAR!! \o/
But good luck with the whole "shoot the noobies and dissenters on sight" thing. You never know... it might work out this time around.
Another person clearly and kindly stated what he could have done to overcome these problems, was personally attacked on this public forum by Jem himself, and posted another kind post with extended information and a request to change his attitude, towards which Jem was unprofessional again.
Newbies are fine. Dissention is fine as long as it is correct. This wasn't correct, and Jem was later hostile towards corrections. Perhaps you should join #DragonFlyBSD sometime on EFNet. We're a great community.
Great job NewsForge!
Good luck with your personal crusade against ??? thing.
WARNING: http://reviews.b0x.com/ is trojan'ed
Posted by: Anonymous Coward on August 11, 2004 05:04 AMhttp://reviews.b0x.com/
The Jem Matzan review - release 1
Do not waste your time on reading JemReports
Incomplete reviews
reviews that are false
not organized at all
I do not recommend any report from http://www.thejemreport.com/ anymore. Jem is very rude, inconsiderate, and will not read the dragonfly webpage. Hence, I will let other people know of how Jem acts. Just ignore the gem reports from now on. The reviews are incomplete. There are better places around the internet to look, mainly be investigating it yourself if you want a real review.
I am pretty sure there have been other reviews that were false besides the reviews on BSD systems.
read mailing lists
join on IRC channels (mainly on irc.freenode.net and irc.efnet.net)
try the software fully and get a few years experience before giving a decision
Q: my attacking him?
A: No. Jem is the attacker. A direct attack by beig ignorant of the help that the DragonFlyBSD people get
His work is biased, they are not really too much reviews.
I will discuss this further right now.
1. Jem does not get deep in to any review.
Okay, so far from any review Jem has written I am seeing a lack of usage, user interaction, and reading of mailing list. This is a big let-down in the Jemreports. I think that someone should get a real commercial team of reviews who use all areas of software without being biased.
2. Jem was very rude in emails
okay, I tried explaining nicely, then Jem boasted on and on about how it was a job
3. They guy even insults people on his forum (see below)
The DragonFlyBSD-1.0A was moot<nobr> <wbr></nobr>.Jems problems with DragonFlyBSD<nobr> <wbr></nobr>..Could not get SMP to work
If Jem bothered to read the mailing list, Jem would have found a fix. Just disable the serial console
The port for the X window server would not compiler
If Jem bothered reading the mailing list, Jem would have found an answer.
DragonFlyBSD does *not* maintain the ports system. The ports system used is the FreeBSD port system
Final words
There are plenty of good news sites out there. You just have to watch what you read.
Just make sure to watch out for anything that is linked to http://www.thejemreport.com/ Most of the editorials are FUD.
This makes me think, "How many people were given a false image on his other reviews?"
David Ross
A table designed for four legs, but with only three attached is not working - it will fall over if you start using it. When writing a REview of a PREview - which usually is waist of time, it would be helpful if the design was discussed, and to what level of completion it is said to be at present.
The article writer points out that some things didn't work, which he expected would work at this stage. Expectations is a dangeorus thing, unless they are based on promises given. Where they given? If they were, it is only right to point out that development is lagging behind marketing.
Additionally, people seem to miss this point and then make statements like yours: ``the article writer points out that somet hings didn't work'': they DO WORK. They didn't work the way he did them. Since you seem to be fond of analogies, I'll give a good one here.
Imagine that you get on a bicycle and try to ride it. You fall off and break your leg. Now, your story is that the bicycle suddenly stopped and you flew off, hence the bicycle is broken. However, the truth of the matter is, you're used to hand brakes instead of pedal brakes. The bicycle works fine, you simply didn't learn how to use it properly.
DragonFly BSD is not a preview. We have a release and it works well (it has for me and numerous others). It is indeed still under development, but so is Linux, FreeBSD, Windows, or almost any other OS you may choose to use.
I recall seeing Netcraft publish benchmarks where they had better performance with Windows than Linux; Linux users heaped them with abuse. I felt a bit smug about that.
I don't feel great about this, because there's some similar behavior. Yes, there are errors in the review. It doesn't make Jem a Bad Person. He also has valid points, especially with documentation, which I hope to address.
Justin C. Sherrill
Will be moved to a real free company, not a adware hosting company
I must also say that the review is totally bogus. We do have (in-progress) documentation that is accessible within 3 clicks from our main site.
Two weeks ago, the forknibbler.com documentation was underway. I can find references to all these things with a simple Google search.
I really don't want to come across as elitist, but it really doesn't appear to me, as an active contributor to DragonFly BSD, that this person even did a half-hearted attempt at getting support: I read all our mailing lists, I'm active in the #DragonFlyBSD channel of EFNet (although it's not an official community, many contributors and developers hang out there). The DragonFlyBSD log that Justin Sherril maintains contains lots of up-to-date information on changes.
My thoughts on the review:
The first 3 paragraphs are full of untruths: the main points that are made (it doesn't work properly yet, it's not suitable for a desktop system and there was a critical error in DragonFly in the 1.0 release). DragonFly BSD has been working for me for four months now since I started doing development in that camp, I use it on my laptop in a workstation environment and I'll let you guys read the stuff that my fellow installer teammates posted about the 1.0 bug that was quite obscure that Chris Pressey and I fixed very quickly in cohort with Matt Dillon. Considering this (the installer) project was started in June by Hiten, Chris, Scott and myself (with others eagerly joining development in the time thereafter and before the release), I think we did a damn good job at making mostly bug-free and functional software in a little less than 2 months.
The fourth paragraph implies that our installer has the same functionality as sysinstall, which it certainly does not. Our 1.0A installer will only install from a livecd environment at the moment (no FTP/NFS/other install methods). The installer is a work in progress, and we're all working hard to make it better.
The DragonFly BSD CD does not contain packages because we don't want to bloat our distribution. That's why our ISO stays around 72MB in size.
There are a lot more differences in our source tree than are listed on the page. Check out the diaries for more on the site.
No offense meant, but I really don't think you're the most qualified person to perform benchmarks of DragonFly BSD, and the benchmarks you discuss in the next paragraph are benchmarks based on fairly specific hardware, instead of a more general purpose system. You also showed no interest in getting help with your problems before writing this somewhat defamatory post on newsforge, so I think you should leave benchmarking to somebody who has more of an eye for working with members of the team to do benchmarking: a fairly tedious process that needs fairly nitpicky information. You don't appear to be cut out for this work.
I understand that you don't mean to be negative in your review, and I appreciate the goodwill. But the negative comments you've made on DragonFly are all bunk, and hence your review's substantial material comes down to mostly: ``I'm impressed with the work Matt Dillon and the DragonFly team have done''.
Before the rest of you start associating this post with the thoughts / actions / feelings of other DragonFly users, members, their dogs, their goldfish or their benefactors: these are my opinions and experiences only. Don't try applying any of what I say to ``the DragonFly BSD community''.
So basically, you're just going to ignore what I said: ``don't apply what I said to all DragonFly developers''. And you label me ridiculous! I don't think this could get any more sarcastically hilarious.
Open source proponents regularly take media to task for uninformed, under researched articles, and they should. If you are going to review a product, you need to get into it in detail, as if you using it for real. Reading the DF archives, the author did not make any attempt to get any help before giving up and proclaiming DF broken. That's the real problem here.
However, I will state that DragonFly does disclaim itself from being the perfect OS in many points, the installer and webpage included. The points that Jem makes here, however, are points that were fixed. I think my point is that his statements are so general that, from reading his article, a potential user might think ``This OS doesn't work at all'', when that's not the case at all (and, indeed, everything he had a problem with has a solution). That's all I'm saying. No more, no less.
Viewer discretion advised. Void where prohibited. My opinion only. I don't represent anybody else.
Formal docuentation always lags actual code in a project at this stage.
DragonFly won't be a 'user' release for quite some time, there are still major pieces (like a new packaging system) that we need to do before I would consider it appropriate for an armchair user to install. The ports system is just a stop-gap for us so we can focus on the kernel for now. It's a hack on top of a hack on purpose. We don't want to waste limited developer resources on it when we are going to be replacing it soon anyway.
The kernel itself has undergone truely massive changes, with much much more to come. We've made phenominal progress over the last year. The infrastructure work we are doing is not going to reap rewards at the user-visible level for some time. We are quite literally ripping the guts out of the FreeBSD base and replacing it. For example, take SMP. The thread scheduler is fully MP safe and operates without the BGL, but the threads themselves still operate mostly under the BGL. But all of our new code is either MP safe or 95% of the way there... but we have no intention of trying to turn off the BGL too early and destabilizing the kernel right in the middle of the major work we still have to do on the guts, so you aren't going to see a major improvement in SMP numbers for at least another 6-12 months. But when we *are* ready to turn off the BGL our threaded architecture will allow us to do in a way that will not destabilize the system and which will reap instant subsystem-by-subsystem rewards, not to mention easy instrumentation via sysctls. All by virtue of the new architecture.
It's hard for a layman to understand why this rearchitecting of the kernel is important, because the visible rewards are not striking until late in the game. But from a developer's point of view th e rewards are obvious, immediate, and lasting. Most people don't realize just how massive the changes we've made have been precisely because we have managed to maintain pretty damn good stability throughout it all. Consider the fact that our installer was written in just 2 months, but the code is so well designed that it looks like it has been groomed for over a year. Consider the fact that under the DragonFly LWKT architecture it only took us 3 weeks to thread the network protocol stack. Just 3 weeks, with virtually no degredation in performance and we haven't even tried to optimize it yet! Consider the fact that the DragonFly synchronization methodologies are, in fact, the *same* for both UP and SMP, and equally efficient from an algorithmic point of view. This means that we are constantly testing all the coded algorithms even when running with the BGL, which makes debugging Big Giant Lock issues a lot easier.
DragonFly has a very bright future ahead of it. Even as we speak I have begun to dive into the last major kernel subsystem that needs to be threaded... that being the VFS layer. Once the major threading work is finished the BGL removal work (which is a lot easier in a threaded design) will commence.
-Matt "You'll just have to trust that it is me because I don't have a newsforge account and I'm not getting one" Dillon<nobr> <wbr></nobr>:-)
<A HREF="http://www.sciencedaily.com/encyclopedia/dragonfly_bsd" title="sciencedaily.com">http://www.sciencedaily.com/encyclopedia/dragonfl<nobr>y<wbr></nobr> _bsd</a sciencedaily.com>
-- Rengi
Please do not support these sites, they inhibit contributions to the articles that the wikipedia contributors have written. Go straight to Wikipedia (<A HREF="http://en.wikipedia.org/wiki/Dragonfly_bsd" title="wikipedia.org">Dragonfly_bsd</a wikipedia.org>).
Simple fixes
Posted by: Anonymous Coward on August 10, 2004 03:44 AMBenchmarking with SMP off would be fine. Arguing that it's not a "real-world scenario" is irrelevant; it's a benchmark. A number of benchmarks have been run by various people - performance is usually slightly worse than the FreeBSD-4 series (which can be blamed on active development), and much better than FreeBSD-5.
The source mirrors usually give excellent performance; the main DragonFly site is running on reduced bandwidth this past week because of work being done by the telephone company where it's located. Which mirrors weren't fast?
The entire DragonFly development team uses DragonFly both as server and desktop machines, along with a good number of users; The conclusion that the system can't be run seems somewhat... abrupt.
(Disclaimer: I'm a DF developer, so I'm trying to hold down an active bias here.)
#