After many months of work DragonFly is about to release version 1.2 of its BSD based operating system. The first release candidate version can be download from dfly-20050406-pre1.2.iso.gz
DragonFly 1.2 Release Candidate available for Download
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
It would be nice if they put up what was new in this release or, well, anything about it. Does anyone here know what’s new (not like updated packages)?
http://wiki.dragonflybsd.org/index.php/DragonFly_Status
Check this link out, it has a pretty good summary of the things that they’ve been working on.
There are a lot of things that are close to being finished, but not quite (ie: fs journalling)
I’ve been using it as my main desktop for a while now, and haven’t had too many issues (mainly little things). No crashes so far.
Still not adequate for a desktop since it’s awkward to install Java and you will get a very old release (1.3.1). The Flashplayer is still at 6. 7 is possible but was very buggy last time I checked. Again, it’s difficult to install.
This plagues all the BSDs and it’s a shame.
Well, some people do fine with non-proprietary runtimes.
If you need Java, in some cases 1.3 might be fine (what are the problems in porting 1.4; are there many runtime-additions?). For Flash: I got it turned-quasi off most of the time (Flashblock extension on Camino). Rarely do I come across a website with Flash navigation, and then it’s usually not even worth it.
> Still not adequate for a desktop since it’s awkward to install Java and you
> will get a very old release (1.3.1). The Flashplayer is still at 6. 7 is
> possible but was very buggy last time I checked. Again, it’s difficult to
> install.
> This plagues all the BSDs and it’s a shame.
No it doesn’t and no it’s not. Look here:
http://www.freebsd.org/java/
and here:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/desktop-b…
That’s both java (post 1.3) and Flash on FreeBSD. I’ve had both running on my BSD desktop. It was not rocket science.
“many popups are Flash and many viri Java.”
Thanks… I needed the laugh!
From the Handbook:
“Installing Mozilla is simple, but unfortunately installing Mozilla with support for add-ons like Java™ and Macromedia® Flash™ consumes both time and disk space.”
For Java, you have to create an account on Sun’s website and download three files, some of them pretty big.
For Flash, you have to use a wrapper and thus download the large linux_base port.
I maintain my statement. It’s a shame when on Linux you can just do an urpmi or apt-get. I understand the reasons behind this and I use FreeBSD for some servers, it’s a really good tool, just not ready for the “average” user.
It’s just too bad that a new BSD based OS like DragonFly doesn’t provide anything else.
AFAIK, The DragonFly BSD developers are primarily reworking the foundation of the OS at this time. That’s what the focus is. It’s not (yet) about making it a killer Desktop, even though theoretically it could be considered on par with Linux. The biggest problem for end-users is that the FreeBSD ports tree, which dfly are piggybacking on for now, needs overrides for a lot of ports to build on DragonFly, and sometimes they break. A native solution is on the horizon, but it’s waiting for the new VFS feature set.
Good to see some developers willing to throw convention out the window, and willing to adopt new ideas. Nothing worse than developers saying, “yeah, lets create a better operating system – but stick to the same convetions!”.
Something I would love to see is a PowerPC port of it
that would definately make my day 
hahaha very funny indeed, and the window beside him has a sticker that says,
“apply tongue here”
There is a jdk14 override in dfports. It builds and works without problems.
It’s a shame when on Linux you can just do an urpmi or apt-get.
What about other distros of GNU/Linux than Mandrake or Debian.
And what about other architectures than GNU/Linux-x86 ?
No Flash on PPC.
I understand the reasons behind this and I use FreeBSD for some servers, it’s a really good tool, just not ready for the “average” user.
FreeBSD is ready for average user (since it is so damn simple to configure).
Now why would your average user need flash ? Java ?
I won’t debate over Java, qualities and defects, blah blah.
I had to use it. It is a tool, not a top-notch one, but good enough with yet one big handicap: it is not free (as in “I can twist the source to make it work all right on my architecture”).
Then again, DragonFlyBSD is not especially made for “average users”, or fake-geeks willing to impress girls with “wow, see that brand new OS nobody knows or use…”.
It is striving to implement new designs, and first to stabilize the system, then to be used in servers.
Then again, you might be spending some time coding for *BSD instead of complaining why your desktop lacks Flash, Java, and whatever other toy. 🙂
(That said, I myself am going back…)
Good to see some developers willing to throw convention out the window, and willing to adopt new ideas. Nothing worse than developers saying, “yeah, lets create a better operating system – but stick to the same convetions!”.
Yeah, I hope it pays off for the DragonflyBSD guys.
It certianly paid off for Linux when they refused to follow the Solaris style locking model that FreeBSD is (more or less) following.
Dragonfly is taking a different direction again. Interesting times.
“Still not adequate for a desktop…”
“This plagues all the BSDs and it’s a shame.”
You know, not every OS on the planet has to have “being a great OS for the average Joe” as a goal.
Obviously the BSD’s arent aiming for the consumer desktop market and that’s not a shame at all.
I`m actually very curious how the development on the journaling FS is going. While FreeBSD has background fsck, it is not an journaling FS, which is in some cases needed.
I know the are a lot of disscusion going on but the *BSD are lacking a good journaling FS.
grtz
I have running Dfly for a while “stable” and it has working perfect to a week ago when the ports dosent works so i needed to install all the dependes manually.
Go ahead, install Dfly, and cvsup the latest FreeBSD ports tree and DragonFly dfports tree. Now try to build some useful apps… Way too many apps won’t build from the ports tree. If you’re lucky enough, there’s a dfports override. If you’re even luckier, it’ll be the same version as the ports tree. Let’s assume you actually get those apps installed… A few weeks later you cvsup the ports tree again and try to do a portupgrade. Suddenly SDL in the ports tree is upgraded… By SDL in the dfports tree isn’t. Great… Now you have apps that want the newer SDL that keep building SDL from dfports, which you already have installed and which isn’t up-to-date…
You can always try pkgsrc, if you want.
First, you need to build and install the bootstrap code. Then you need to update bmake from the bmake package (the forget to tell you that on the gobsd.com site). Forget about getting enlightenment running, imlib2 fails to build. You currently need to patch the gtk2 port (assuming the patch hasn’t been committed yet). Firefox won’t build, nor will SDL. If you want to build Blender, it’ll try to build nasm, which requires the gcc3-c package… Which won’t build. (You can edit the nasm Makefile to remove the gcc3-c dependency).
Sorry folks, but DragonFly is really only suited for developers at the moment, IMHO.
Adam
Sorry folks, but DragonFly is really only suited for developers at the moment, IMHO.
I don’t remember anyone saying otherwise and I doubt that any of the DragonFly developers would disagree with you.
I would say it’s suited for developers and serious unix geeks though. It takes a bit of work but you can do it if your determined and somewhat knowledgeable.
I don’t remember anyone saying otherwise and I doubt that any of the DragonFly developers would disagree with you.
I never said they did, did I?
Adam
Though the developers may have never claimed that DragonFly was ready for the average user, they have said:
People will find that the DragonFly-1.0 release is still using the old 4.x pthreads model, and at the moment we are relying on the FreeBSD ports tree with DragonFly specific overrides for third party application support… about as severe a hack as it is possible to have. These two stop-gap items will be at the forefront of the work for the next year, along with a major move to start removing the BGL (Big Giant Lock, also known as the MP lock) from code inherited from 4.x, threading the VFS (Virtual File System) subsystem (the network subsystem is already threaded as of 1.0), and implementing asynchronously messaged system calls.
They posted that on their website when DragonFly-1.0 was released in July of last year. It’s nearly nine months later and, from a users perspective, the ports situation doesn’t appear to have been “at the forefront of the work.” Maybe something drastic will happen in the next 3 months, and DragonFlyBSD will either have it’s own ports tree, or work almost flawlessly with the FreeBSD ports or pkgsrc, but I have my doubts 🙂
Having said all this… I am quite impressed with the direction DragonFly has decided to go in. Without a doubt, it performs noticably better on my system than FreeBSD -CURRENT does, and I look forward to the time when I can completely replace my FreeBSD installation with it.
Adam
Adam
There is a considerable amount of pre-compiled software at http://www.gobsd.com/packages/
It’s easy to install any of these with ‘pkg_add -r’. I’m running Dfly as my main desktop OS right now, complete with mplayer, gnome2.6, OpenOffice, etc. Yeah, some of the software is a little aged, however, no more aged than most of the stuff you’d get with debian. Flash and Java are just as hard to setup on FreeBSD than they are on Dfly.
As for effort on ports or packages, well, I know one developer who is working on a package system in his spare time. Many others have done considerable work with pkgsrc. Many of these things are going on in the background and just can’t be seen unless you hang around on IRC or read the mailinglists regularly.
Dfly isn’t really ready for ‘regular’ users yet, but it’s not quite as bad as what people are making it out to be.
Yeah, some of the software is a little aged, however, no more aged than most of the stuff you’d get with debian.
But more aged than what you’ll find in the ports tree. At that’s the problem… All hell breaks loose when you try to do a portupgrade 🙂
Adam
http://www.homestarrunner.com is enough reason for me, proprietary or not I’m not going without it.
I thought the native solution for the FreeBSD ports thing was to use NetBSD’s portable pkgsrc?
Well, I think devs are hesitent to do too much work updating/fixing ports, because nobody knows what’s going to happen with the ports/pkg situation yet. Nobody wants to do a whole bunch of work only to have it tossed out the window if there is a major change in how ports/packages are handled.
Ports, for the most part have built okay for me — I just don’t try building things that I know are big, complex, or have a lot of dependencies.
All hell breaks loose when you use portupgrade on FreeBSD as well — it just doesn’t happen as often.
All hell breaks loose when you use portupgrade on FreeBSD as well — it just doesn’t happen as often.
I use it regularly on FreeBSD, and I can’t remember the last time I ran into a huge problem.
Adam
This is just a correction. It is not just a journal FS that is being worked on. There is an entire journaling “layer” being put into place to be able to do journaling for kernel tasks, userland tasks, backups and many many other things. Having a journaled filesystem is great, but having a journal for nearly everything, now that’s NEAT-O (possibly).
does anybody know if the bsdinstaller supports headless installation through a web-based interface? i heart something like this but didn’t found it anymore. thx
you read /usr/ports/UPDATING.. It’s a PEBKAC problem.
Yes, DragonFly supports a headless install.
You can use PFI to select the frontend you would like to use during install. See http://wiki.bsdinstaller.com/wikka.php?wakka=PreFlightInstaller for more information.
Regards,
Scott
They posted that on their website when DragonFly-1.0 was released in July of last year. It’s nearly nine months later and, from a users perspective, the ports situation doesn’t appear to have been “at the forefront of the work.” Maybe something drastic will happen in the next 3 months, and DragonFlyBSD will either have it’s own ports tree, or work almost flawlessly with the FreeBSD ports or pkgsrc, but I have my doubts 🙂
Not much work is being done on ports because Matt wants to rip it out and put a different system in place. One based on binary distribution and that can easily install several versions side by side IIRC.
I’m glad they’re working on the low level stuff now, which will make DragonFly a truly advanced OS with unique features. Those (like the new vfs stuff) can then be used to create a really cool packaging system in the future.
In the meantime ports/pkgsrc is perfectly servicable.
>It certianly paid off for Linux when they refused to follow >the Solaris style locking model that FreeBSD is (more or >less) following.
The FreeBSD and Linux SMP models are very similar. They differ with respect to the type of primitives employed ( spin vs blocking locks ). Oddly enough, FreeBSD recently commited an option to enable adaptive locks which are actually a cross-breed of the two methods ( spin a bit then block if neccesary ). I believe this is now the default behavior.
The FreeBSD’s interupt thread code, locking primitives and lock monitoring tool witness were originally ported from the BSDOS ( BSDi / WindRiver ) codebase which was deemed the most suitable starting point for the SMPng effort. More info available here …
http://www.lemis.com/grog/SMPng/Singapore/
I would be very surprised if Solaris didn’t employ a similar method of SMP locking. DragonFly is certainly taking the road less traveled however.
Anyway, FreeBSD’s approach can be combined with DragonFly’s to give a really good revolutionary experience? Both technologies address scalability problems but it seems like they are independent approaches where they can be combined.
Have any of the people suggesting DFBSD is only for hardcore “Unix geeks” and developers right now even ever given it a try?
Sure it might not be a *hardcore* desktop replacement, compared to some Linux distros that spend 100% of their time working on desktop useage, but it is ROCK solid and very stable as a server considering how young DFBSD is and how much development is happening. BSD’s by nature are more geared to serving so stop raping it because it doesn’t fit for ‘average Joe’ and home.
I have a DFBSD server running high traffic environment in my school and had NO problems with the ports I needed (mysql, perl, apache+modperl, php, phpmyadmin). Not to mention it handles the duties fine. I don’t understand where these comments come from. Sure some of the large ports may have problems (like X or Enlightenment), but just install binary package for now. No one complaines about using binary packages on Debian. Or help fix the ports and give back instead of complain.
Wrong.. The problem isn’t with my lack of knowledge of ports and portupgrade (I’ve been using FreeBSD for years and DragonFly since version 1.0) the problem is that the dfports tree is sadly out of date compared to the ports tree, making portupgrade problematic, at best.
The real problem, though, is the dependency on the FreeBSD ports tree (as the official source for DragonFly applications) to begin with. The FreeBSD developers couldn’t really care less about problems that ports have on DragonFly, so things break in ports (for DF) faster than they can be fixed in dfports.
Adam
The FreeBSD and Linux SMP models are very similar. They differ with respect to the type of primitives employed ( spin vs blocking locks ). Oddly enough, FreeBSD recently commited an option to enable adaptive locks which are actually a cross-breed of the two methods ( spin a bit then block if neccesary ). I believe this is now the default behavior.
Not really. Linux focuses first on lockless code and data, then on lightweight reader side code, then on fine grained, short held spinlocks, and lastly blocking semaphores.
FreeBSD has very few lockless paths. Their scheduler doesn’t even use per-cpu queues AFAIK. Their synchronisation primitives are mainly mutex oriented.
I would be very surprised if Solaris didn’t employ a similar method of SMP locking. DragonFly is certainly taking the road less traveled however.
In many respects Linux is closer to Dragonfly than it is to FreeBSD.
There is a point where you can take the per-cpu scheme too far though – there inevitably have to be *some* serialisation points *somewhere* if you want things like a consistent filesystem (which you do) and access to actual hardware devices.
i remeber there was discussion of using apt or a work-alike with dragonfly, what happened?
uh, journal fs? for a desktop os? sorry still a ext2 dude here, no major problems to report….. so I dont see a journaled fs as a big deal at all……
just my nasty opinion tho
>FreeBSD has very few lockless paths. Their scheduler
>doesn’t even use per-cpu queues AFAIK. Their
>synchronisation primitives are mainly mutex oriented.
How do you have a lockless path in an SMP environment and still share resources? Do you mean they focus on minimizing lock operations by increasing the ammount of code covered by a single locked segment? In this case, you inhibit the option for preemption which incurs latency. There is always a trade off. Lunix has been working on SMP a lot longer than FreeBSD. Give it a chance.
FreeBSD’s ULE scheduler has per-cpu queues which is not default for stability reasons. Linux didn’t have one either until 2.6 right?
>In many respects Linux is closer to Dragonfly than it is to
>FreeBSD.
A lot of what drangonfly gains is via the microkernel-like lwkt messaging API. What is it that linux employs that makes it similar in this respect?
How do you have a lockless path in an SMP environment and still share resources?
There are a lot of lockless algorithms and data structures.
The schemes preferred the Linux kernel where scalability is important are firstly per-CPU data structures where possible, then things like RCU and seqence/generation counting with read retry, atomic modification of data, etc.
Do you mean they focus on minimizing lock operations by increasing the ammount of code covered by a single locked segment?
No. In Linux, you lock data, not code. And where locks are used, the focus is on having as narrow a hold width as possible.
In this case, you inhibit the option for preemption which incurs latency. There is always a trade off. Lunix has been working on SMP a lot longer than FreeBSD. Give it a chance.
Actually FreeBSD developers used to brag about having a working SMP implementation before Linux, which I think may have been true – if not then it would have been very close, definitely not “a lot longer”.
And it’s not about giving it a chance or not. It simply currently does not have a good SMP implementation.
>The schemes preferred the Linux kernel where scalability
>is important are firstly per-CPU data structures where
>possible, then things like RCU and seqence/generation
>counting with read retry, atomic modification of data, etc.
Using per-CPU data is one of the methods rwatson and jbaldwin are testing to fine tune some of the subsystems that are now locked down.
http://www.freebsd.org/projects/netperf/
All of the methods you mention are very special purpose and could hardly be considered as a general locking strategy. Just good fits for certain scenarios.
>No. In Linux, you lock data, not code. And where locks are
>used, the focus is on having as narrow a hold width as
>possible.
I guess in linux the data just locks itself. What a nifty trick. For sure, the FreeBSD community could benifit from such a technique. Anyhow … how do you have a lockless path in an SMP environment and still share resources? From what you have said, the shared resources ( i.e. the data structures ).
>Actually FreeBSD developers used to brag about having a
>working SMP implementation before Linux, which I think may
>have been true – if not then it would have been very close,
>definitely not “a lot longer”.
Working is not optimal. Are you saying that removing the BKL was not at the top of the Linux 2.4.x priority list? During the same time period, removing GIANT was not a goal for the FreeBSD 4.x kernel. It is however a top goal for the 5.x kernel series. So, like I said before … give it a chance. Different historical priorities, different timeline.
>And it’s not about giving it a chance or not. It simply
>currently does not have a good SMP implementation.
As you keep stating. Its a lot easier to take pot shots at a system that is only half complete. Lets wait a bit and see how it all turns out. I think your going to be surprised to find out how well it finishes up. Even compared to what is turning out to be a very commercially backed kernel such as linux.