DragonFly BSD 1.4 is the third major release of Matthew Dillon’s fork of the FreeBSD operating system, and significant progress has been made towards reaching many of the project’s numerous goals. New in this release include a more up to date version of the GNU Compiler Collection (required due to the incread use of thread local storage in DragonFly), an import of NetBSD’s Citrus code (Comprehensive I18N Framework Towards Respectable Unix Systems), major reworking of all core subsystems in preparation for removing the MP lock, rewrites of various VFS related code and many updated drivers, frameworks and contributed programs. Perhaps the biggest potential change for users of the system is the inclusion of NetBSD’s pkgsrc package management system by default, and the retirement of the aging FreeBSD-4 ports system. A full list of changes to the system can be found here. Installation and post-install setup As has been the case for over a year now, installing the base system was quick and mostly painless. As always, I did not add users or passwords from the installer, nor did I change the timezone or set up the network until I had rebooted into the installed system, as I find the installer of limited usefulness for these tasks in it’s current implementation. Most irritating for me personally, is that the following charaters cannot be used in passwords entered into the installer, despite being valid within the operating system itself: For more issues with the installer, check out the following pages: http://www.dragonflybsd.org/main/errata1_4.cgi Once the system reboots, the very first thing I do is set it up to use blowfish passwords instead of the default MD5. After this, the root password was entered (so I could use characters not supported by the installer), users created, driver modules for harware are loaded (and set to load at boot in Because at the present time updates to the system require rebuilding from source, I like to keep a copy of the release’s source on hand. Easy enough to get, as an example CVSup file is provided in ‘ Very bad things happen if you try to checkout from the repo without that file, and then attempt to rebuild the system. I am left wondering why it’s not included by default, instead of being in the errata for the release. Also of note in the errata, new users don’t automatically have the new pkgsrc related paths in their profiles by default. A minor issue, and easilly fixed, but it leaves me wondering how something like this got missed in the RCs. Do the developers and testers only ever log in as root? Documentation and packages Although the man pages are well written, documentation in the DragonFly project overall leaves something to be desired. They have a slightly modified version of the FreeBSD Handbook, but it is somewhat out of date, and still contains references to functionality in FreeBSD not present in DragonFly, and written in such a way as to leave the reader believing them to be DragonFly features (quick off the top of my head example can be found here where it is claimed that “DragonFly is a 32-bit operating system (64-bit on the Itanium and AMD64) and was designed as such from the ground up.” DragonFly currently does not run natively on any 64 bit processors in 64 bit mode and there are no plans for port it to the Itanium family of processors. The DragonFly CD comes with few third party packages; only enough to allow one to rebuild the CD if required. The reasons for this are that Matthew Dillon wants the CD to remain small enough to be quickly downloaded, and that any packages included would be out of date as soon as the CD image was released. The very same can be said of DragonFly itself, but I digress. Setting up 1.4 to do anything useful (as a desktop system for example) of course requires a number of third party packages, which currently are in short supply. As of the release of 1.4, no official precompiled packages are available for download, and the package tools do not even have a default path to look for files on the Internet. Although the steps needed to go about getting said packages are documented online, the documentation is all in HTML, and the DragonFly system has no native ability to actually read those files (well, you can, but you’d have to tune out all of the HTML tags). Bad move installing DragonFly without having first saved a plain text copy of the errata and docs on a floppy. The documentation should be on the install CD so it’s accessible to people with only one machine to work with. Although the pkgsrc tools are included on the CD, they serve no immediate purpose due to the lack of working packages, or even a pkgsrc tree on hand with which to attempt to build them. I may have just missed it, but I found no notes on the CD on where to get the pkgsrc tree (not a huge problem for myself as my memory isn’t totally shot), and more specifically how to go about downloading it. The CD comes with example CVSup files, why not something for pkgsrc? Many commonly used software packages do not build on DragonFly at the present time, from my limited experience this includes at least KDE, GNOME, MPLayer, Blackbox (!?!) and some games that I use as quick tests to make sure OpenGL works correctly. Thankfully, X.org *does* build, but that just left me with the GUI equivelent of what I already had; a system I can’t use for day to day tasks. A few people from the DragonFly project are working to rectify this situation, but not all of their patches have been merged into the upstream pkgsrc code, and it remains to be seen if that is going to change in the short term. Final thoughts While a lot of work has gone into DragonFly since the last release, it is apparent that much more work is required to make it a usable desktop system for people who do not enjoy the challenge of making their computer perform basic tasks. The developers are working to rectify the pkgsrc problems, but it comes far too late for this release. Aside from that, some very simple things can be done to greatly improve the experience of would be DragonFly users. Simply including a few more useful packages on the install CD (Xorg, a web browser etc), as well as some more accessable and accurate documentation and including recomended files such as About the Author:;,`~!@#$%^&*()+={}[]\|/?<>'"
http://leaf.dragonflybsd.org/mailarchive/bugs/2006-01/msg00065.html/boot/loader.conf), and the final touches are added to /etc/rc.conf (network setup, firewall, shutting down sendmail, enabling usb and the console mouse etc.)/usr/share/examples/cvsup/‘. Some people prefer to keep a copy of the CVS repository on hand and for those people it’s recomended to have the following in /root/.cvsrccvs -q <br>
diff -u <br>
update -Pd<br>
checkout -P/root/.cvsrc (desribed above) by default, instead of leaving it to the user to set up after the system has been installed would go a long way.
Trent Townsend is an aspiring geek with few applicable skills (or any obvious knowledge or talent for that matter :P) who is dedicated nonetheless to learning new and interesting things in all areas of science and technology.
A mirror of official pkgsrc packages: http://chlamydia.fs.ei.tum.de/pub/DragonFly/
The information on how to set up pkgsrc is on the wiki: http://wiki.dragonflybsd.org/index.php/Set_up_and_use_pkgsrc
i’m not sure dragonfly will really ever go anywhere, but its nice to see talented developers implementing alternatives to the status quo.
whats needed is a real in-depth technical analysis and performance analysis of the as-of-2006 latest released kernels for linux, freebsd, netbsd, openbsd, darwin, and opensolaris. there’s a great deal of zealotry out there but its been a while since a real good comparison has been done.
I am personally getting sick of OS review articles that simply discuss how to install something and that it has few packages, yada yada yada.
DragonFlyBSD is supposed to be targeting some truly remarkable goals, one of which is becoming a distributed OS.
It is not supposed to be your grandmother’s desktop. Personally, I would’ve loved to have seen a discussion of the status of the project’s stated goals and how things seem to be moving along as compared to FreeBSD 6.x and 7.x.
Another thing to note is that traditionally the *BSDs share with each other, and I think this is great. Any improvements in scalability and scheduling achieved through the DFlyBSD project will surely make its way to the other BSDs.
“I am personally getting sick of OS review articles that simply discuss how to install something and that it has few packages, yada yada yada.”
It was written from the POV of someone who simply wants to use DF as a day-to-day desktop system, and noting some of the more irritating aspects of the system in regards to that.
“DragonFlyBSD is supposed to be targeting some truly remarkable goals, one of which is becoming a distributed OS. ”
Yes, and this is in fact one of the things that has attracted me to this OS. But guess what. It does not have those capabilities yet, and won’t for some time (a year or three are my uninformed guesses), so there is nothing for me (or anyone else) to have said about setting it up to do such things.
“It is not supposed to be your grandmother’s desktop.”
I never claimed nor imagined it to be, and of course by “desktop” I mean a typical UNIX fan’s desktop machine.
“Personally, I would’ve loved to have seen a discussion of the status of the project’s stated goals and how things seem to be moving along as compared to FreeBSD 6.x and 7.x. ”
There is also not much to say about this at the moment, as the system still runs under the MP lock, making comparisons with other systems (like FreeBSD 6) pointless, as those systems will likely outperform the current version of DF on MP systems.
“Another thing to note is that traditionally the *BSDs share with each other, and I think this is great. Any improvements in scalability and scheduling achieved through the DFlyBSD project will surely make its way to the other BSDs.”
I would certainly hope so, but like I said, it’s too early to tell with certainty if this will indeed be the case. Personally, I believe that DragonFly will be the top performer once the MP lock is largely gone, but beliefs without evidence to back them up are pointless, so nothing of the sort was mentioned.
Edited 2006-01-19 00:02
It was written from the POV of someone who simply wants to use DF as a day-to-day desktop system, and noting some of the more irritating aspects of the system in regards to that.
But that’s not it’s intended goal!
Why don’t you run some benchmarks? Find a root exploit in a common package and see if it works on DragonFly BSD(I believe OSes like OpenBSD have extra protection against that)! Comment on various drivers. Look at various administrative tools? Run them versus previous versions of DragonFly BSD?
Instead we have yet another “newb approaches desktop” article. Really, I’m sick of reading these “Well, I was trying to eat soup with a fork and it SUCKED!!!!!111!” articles.
I know I don’t have to read them but I’m trying to raise the bar here: get a little bit more depth here on OSNews.
Really there is a lot more to an OS than it’s desktop usage. Why not write about it’s scheduling algorithm, or it’s driver infrastructure? I’m sure many people would be interested in an in-depth article about an actual OS how it compares to another.
On the desktop it’s practically all the same. The installer might be different, and the package manager (the only useful thing covered) might be, but Gnome/KDE is always Gnome/KDE on Solaris or FreeBSD or Linux.
Really, did anyone _learn_ anything new from this article?
How is it Ars Technica can have in depth article about proprietary microchips while we get shallow tripe about an open-source OS?
Hell, did I even mention if DFBSD was SV init or RC scripts?
Frankly the author was unqualified to write anything. This is bad as the Jem Report on Solaris a while back. Please, if you agree with me mod me up: not for vanity but to try to encourage a little more from a site I love and have learned a lot from in the past.
Frankly, I think the most educational bits now are Rayner (sp?) comments.
¨Frankly the author was unqualified to write anything.¨
Oh I wouldn say that, but I am certainly not qualified to write some of the things you´d likely be interested in (really hardcore low-level stuff), so I´ve saved myself the embarrasment of even trying.
¨Frankly, I think the most educational bits now are Rayner (sp?) comments.¨
I agree with that statement, and quite frankly it is his comments that keep me reading the comment section, he is informative and does not whine.
Please by all means, feel free to submit something yourself if you don´t like the things that get posted here. I am looking forward to seeing what you´re capable of ;^)
Edited 2006-01-19 07:04
In my family we always said ‘your best doesn’t mean it’s good enough’ and I could write something but I don’t want to put more tripe out on the internet. I’ve written a few rough drafts over the last two years as to why Java is the ideal programming language for beginners but I realised it wouldn’t really fit here and it’d be too long for most people to read.
The only other thing I think I could write about is mode/context switches and why they screw over microkernels… but even then anyone who has a CompSci or SoftEng BSc or any technical college should already know that so it’d be like “bringing salt to the ocean.”
¨I’ve written a few rough drafts over the last two years as to why Java is the ideal programming language for beginners but I realised it wouldn’t really fit here and it’d be too long for most people to read.¨
Maybe, but we will never know until we see it, and we haven´t had a decent Java story in a while. As people don ´t get good at something unless they practice it, it might do you some good to finnish it and post it anyway, regardless of whether or not you think you will do a terrible job.
Live and learn, right?
Please by all means, feel free to submit something yourself if you don´t like the things that get posted here. I am looking forward to seeing what you´re capable of ;^)
No, you’ve got that backwards. If people don’t like what you write, it doesn’t mean that they should write something better. It means that you should write better.
Edited 2006-01-19 10:14
“No, you’ve got that backwards. If people don’t like what you write, it doesn’t mean that they should write something better. It means that you should stop writting.”
Interesting idea. Pass.
The review was useful for me. I was wondering about most things that the article informed me about. I even liked the style of writing. I agree I would also like a more indepth technical comparission… but that shouldn’t mean you should stop writing. Please keep doing it and I think you’re dealing exceptionally well with those sometimes pretty harsh comments.
Best regards,
-Stephan
Some OSs core assets are desktop and others are server. A good review should discuss the core asset of the system. The article would have been better if it had focused on the main goals of DF. Though, I appreciate comments on the Unix nerds user experience of DF too. Also he has every right to write about this. However, the goal of the article should have been stated from the start, even in the title. In a way the title is fooling the reader when it does not state that it is a review of the user experience since the reader does not immidiately associate DF with user experience, whereas “review of Ubuntu” would.
Frankly the author was unqualified to write anything. This is bad as the Jem Report on Solaris a while back.
Please, be a bit kind. And look to it from another perspective. Last week two people on a Dutch slack channel asked me (on separate occasions) whether they can use DragonFly as their desktop operating system. The DragonFly website says:
“DragonFly is an operating system and environment designed to be the logical continuation of the FreeBSD-4.x OS series.”
One of FreeBSDs intended uses is as a UNIX Workstation, so it seems fairly logical to see DragonFly as more as a research or distributed operating system. The bottom line is that I could point those persons to this article, and it would answer their question.
“DragonFly is an operating system and environment designed to be the logical continuation of the FreeBSD-4.x OS series.”
One of FreeBSDs intended uses is as a UNIX Workstation,
Indeed. DflyBSD is intended to function as a multi-purpose OS, just like FreeBSD. For one of it’s intended purposes, it doesn’t hold up yet. This is exactly what I liked to learn about in this review; perhaps this doesn’t hold for everyone, but this review worked for me (as someone similarly not hackerish, but at least interested in alternatives for day-to-day computer use).
And he did point out valid flaws in the installation cds after all.
I HEAR YOU!!!
and i hate the reviews that involve desktop screenshots…. they are all basically the same…linux, freebsd, netbsd. its the same desktop minus a few icons diffs.
okay, if the desktop has a custom app for making the system easy, that is always great to see, i love that type of inovation, but who cares how easy it is to install. its not a desktop OS, hell there isnt ANY desktop that is easy to install that some random person can just get the cd and go with. they let their neighbor computer guy do that…the important thing is how easy it is to maintain and USE….forget the install, that is trivial, it takes 30minutes to an hour, after that, for the unix desktops, it is done, you dont ever have to do that again.
i want to see in these reviews the innovation, not how easy it is to install… for this case it is an offshoot of BSD, aka you have to know what you are doing to some extent to use it. that is the target audience…PCBSD is targeting linux users and making a general desktop that any OSS convert can do (instead of a linux desktop) thats great. install is more important but not that important as long as the IT guy can do it.
Well, considering that DragonFlyBSD takes a completely different approach to the issue of SMP and scalability, I’d say that yes, this project does warrent a little time in the limelight.
With that being said, however, I hope that when the big parts are complete, and we have a scalable system with a nice packaging infrastructure, there will be someone from the project who can really go into depth into how the whole thing ticks when compared to the conventional approaches that most operating systems take when it comes to multiprocessor capabilities.
I am personally getting sick of OS review articles that simply discuss how to install something and that it has few packages, yada yada yada.
It’s a quick review. It raises awareness about what Dragonfly is. Gives a couple of tips to get going, points out some problems and offers a conclusion.
It was lucid and well done for what it offered, which is why I rated it 8.
You can write your own uber-leet review with indepth analyses, benchmarks and such if you want you know.
It’s a quick review. It raises awareness about what Dragonfly is. Gives a couple of tips to get going, points out some problems and offers a conclusion.
Herein lies the problem. It seems that all the reviews are “quick”. I am sick of “quick” – perhaps because I take the time to read about the project. Furthermore, the article is full of assumptions, for example:
Setting up 1.4 to do anything useful (as a desktop system for example) of course requires a number of third party packages, which currently are in short supply.
I think most *nix users can get a long fine for most tasks without a GUI – infact the only reason I usually have a GUI is for the convenience of having multiple terminals open.
I also have to point out that just saying DFly is “a logical extension of FreeBSD 4.x” does not mean it is supposed to be the Ubuntu. It simply means that Dillion felt that plans regarding the internals of 5.x were not the way to go – and when I say internals I speak of things like scheduling, SMP, internal APIs, etc. It has nothing to do with creating a fool proof GUI platform for grandma.
Lastly, I applaud the author for sticking his neck out, and I hope that he sees these criticisms as a way to improve future attempts. Will I put my money where my mouth is? I just might do that because it is easier to illustrate what I would like to see by doing it myself.
It was written from the POV of someone who simply wants to use DF as a day-to-day desktop system, and noting some of the more irritating aspects of the system in regards to that.
“It is not supposed to be your grandmother’s desktop.”
I never claimed nor imagined it to be, and of course by “desktop” I mean a typical UNIX fan’s desktop machine.
so wait, its a desktop review, but its not a desktop review? your lead in was good but the rest was garbage.
DFly isny ready for day-to-day desktop system.
“DFly isny ready for day-to-day desktop system.”
Yep. I think I made that clear.
I don’t mind these reviews, but didn’t any of the editors feel it was a pointless review that would’ve been better off not being put on here? It’s as if the reviewer did a review of a French cuisine restaurant and complained about the pizzas (as in: reviewing DragonBSD as if it were something else which it isn’t intended to be in the first place).
“as in: reviewing DragonBSD as if it were something else which it isn’t intended to be in the first place”
Were it not intended to be used in anything but clustering situations, then Joerg and the others wouldn’t be working to get things like KDE and GNOME working at all (they are, they’re just not done yet).
Seriously, some people just don’t think.
“DragonFly is an operating system and environment designed to be the logical continuation of the FreeBSD-4.x OS series.”
(FreeBSD makes a damned fine desktop system)
http://www.dragonflybsd.org/main/
~*~*~*~
“The applications to which DragonFly can be put are truly limited only by your own imagination. From software development to factory automation, inventory control to azimuth correction of remote satellite antennae; if it can be done with a commercial UNIX product then it is more than likely that you can do it with DragonFly too! DragonFly also benefits significantly from literally thousands of high quality applications developed by research centers and universities around the world, often available at little to no cost. Commercial applications are also available and appearing in greater numbers every day.”
(I imagine a desktop DragonFly system… )
http://leaf.dragonflybsd.org/~justin/handbook/nutshell.html
~*~*~*~
“3. What is the primary goal of dragonfly, servers or desktops?
Matthew Dillon: Both. When it comes right down to it the idea of targeting a system to the ‘server’ is simply another word for ‘reliability and scaleability’, and the idea of targeting a system to the ‘desktop’ is simply another word for ‘out of the box GUI’. It’s not really an either-or deal. All UNIX systems, including Linux, the BSD’s, DragonFly… basically use the same desktop components so supporting a desktop environment comes down to being able to provide integrated solutions that work out of the box.”
(From the project founder himself, right here on OSNews… )
http://www.osnews.com/story.php?news_id=6338
~*~*~*~
Okay. Does anyone else here need some more examples? I’ve got many, many, bookmarked, a few of them Matt Dillon quotes. Desktops are every bit as important to DragonFly as clustering.
Edited 2006-01-19 11:39
“You can write your own uber-leet review with indepth analyses, benchmarks and such if you want you know.”
I’d love for one of them to try, and I hope they let us know if the benchmark software even compiles, as I didn’t attempt to build them myself, and probably won’t attempt it until I hear something more from Joerg ;^)
I think DFly is an an amazing project. It’s good to see it getting reviewed and reported on. I suspect it’s also beneficial for the developers to be able to see what the top niggles are for a newcomer to the OS – allowing them to smooth the initial experience for experimenters.
I do think, however, that it would be very beneficial at this point to see a technical overview (perhaps even written by the project developers…) of all the new stuff in there at this point. Their restructuring of the kernel for scalability and simplicity is progressing well from what I hear. Also, they have some almost magical sounding functionality arriving in there, like:
* freeze running processes to a disk file and resume them later (this is in early stages, but it’s pretty cool they can do it at all!)
* high level journalling (this is *not not not* journalling like ReiserFS and friends do, it’s filesystem independent allows stuff like continuous backups, historical backups where you can rewind to *any* point in history, etc, etc, etc)
The continuing scalability and eventual plans for full cluster-awareness will make this an amazing OS. However, I do get the impression that most of the (limited) development resources are going into improving the foundations of the system, with the user experience largely being for later work. I think part of the reason people are sometimes upset about DFly reviews which (entirely correctly) report it as being unfriendly, is that the developers haven’t really been “trying” to make it friendly at this time, even though it’s an eventual intent.
“I think DFly is an an amazing project. It’s good to see it getting reviewed and reported on. I suspect it’s also beneficial for the developers to be able to see what the top niggles are for a newcomer to the OS – allowing them to smooth the initial experience for experimenters.”
One of the reasons I wrote it.
“I do think, however, that it would be very beneficial at this point to see a technical overview (perhaps even written by the project developers…) of all the new stuff in there at this point. Their restructuring of the kernel for scalability and simplicity is progressing well from what I hear.”
Yes, I would love for them to do so as well, but they are too busy at the moment working on the system to generally do such things. I am very happy for them that they are making considderable progress in reaching their larger goals, but as they intend DragonFly to be a production system moreso than a research system, the progress they’ve made to date means little in a real world setting, as very few applications natively run on it. Once the pkgsrc problems have been dealt with, real work and testing can be done.
“Also, they have some almost magical sounding functionality arriving in there, like:
* freeze running processes to a disk file and resume them later (this is in early stages, but it’s pretty cool they can do it at all!)
* high level journalling (this is *not not not* journalling like ReiserFS and friends do, it’s filesystem independent allows stuff like continuous backups, historical backups where you can rewind to *any* point in history, etc, etc, etc) ”
Exciting stuff isn’t it?! It was mentioned on the mailing lists recently that more work needs to be done in order to use the process checkpointing for migrating processes to other nodes in a cluster, and currently the checkpointing can only be done as root. Supposedly the journaling is essentially feature complete, but they need more testing to ensure its robustness. It should be fantastic by the next release once they’ve finished their port of Sun’s ZFS to go with it.
“The continuing scalability and eventual plans for full cluster-awareness will make this an amazing OS. However, I do get the impression that most of the (limited) development resources are going into improving the foundations of the system, with the user experience largely being for later work.”
This seems to be the case yes. Matt himself seems as focussed as ever on the guts of the system, and Joerg seems to be spreading his efforts all over the place, with few areas getting his full attention for too terribly long. Regardless, I don’t think that DragonFly would have progressed as it has without his efforts. I’m just selfishly left wishing that he would focus his attention on the pkgsrc mess until it largely works so that I can get back to actually using DragonFly as I have in the past ;^)
“I think part of the reason people are sometimes upset about DFly reviews which (entirely correctly) report it as being unfriendly, is that the developers haven’t really been “trying” to make it friendly at this time, even though it’s an eventual intent.”
I wouldn’t say that. One of the things I liked about DragonFly early on was that it was much less irritating than was FreeBSD at the time, due to many small things the DragonFly folks had done to make the system “more friendly.” It’s the lack of pkgsrc developers that is causing most of the grief I am having with the system here and now. Well, that and documentation.
Edited 2006-01-20 02:54
I generally follow the DFly Digest at http://shiningsilence.com/dbsdlog/ and most of the articles are either something kernel-ish, or something bizarre to do with pkgsrc (I generally focus on all the kernel stuff). I generally got the impression that high-level concerns weren’t really on the developers’ radar, but I guess they are (and Joerg in particular) trying to cover all bases. pkgsrc seems like a really cool system to me, and I hope that after a little time they’ll be able to get it working properly.
I’m still not clear on the licensing issues behind the port of Sun’s ZFS, but I’m sure Matt has some vision has to how this will all fit in. It certainly sounds like it’d be a worthy replacement filesystem.
There was (at one stage) a Xen port of DFly in progress by Kip Macy (the dude who did process checkpointing). He switched to implementing this support for FreeBSD because then he was allowed to do it in his work time. It’d be really cool to see that code (which is now going into the FreeBSD mainline) ported back into DFly too (most of the hard work is in the architecture dependent code and the device drivers, so in both cases the interfaces have hopefully not diverged so much as to make this very tedious).
http://leaf.dragonflybsd.org/mailarchive/commits/2006-01/msg00097.h…
http://www.shiningsilence.com/dbsdlog/archives/001509.html