DragonFly At DragonFly 1.0-CURRENT

← Back to Stories (view on slashdot.org)

DragonFly At DragonFly 1.0-CURRENT

Posted by timothy on Wednesday November 19, 2003 @03:44AM from the nomenclature dept.

CoolVibe writes "For months, the DragonflyBSD fork of FreeBSD was maintaining compatibility with the existing FreeBSD-STABLE branch by using the 'FreeBSD 4.8-STABLE' name internally. In a few commits, Matt Dillon changed all the names, and DragonFly is finally sailing under its own banner. Things that DragonFlyBSD already has that FreeBSD-STABLE doesn't are, among others, application checkpointing, variant symlinks (not unlike Domain OS), Light-weight kernel threads, a more efficient slab-allocator, a multithreaded network stack, and the rcNG system."

28 of 108 comments (clear)

Min score:

Reason:

Sort:

I wonder by Leroy_Brown242 · 2003-11-19 04:01 · Score: 2, Interesting

One has to wonder if DFBSD will die due to lack of following, or if it will be the next awesome BSD. I am currently running FreeBSD 4.8 Release on my workstation. It might be worth it to grab a spare machine and install it to see what's up. Only if the distributed.net client will work on it though. ]:3}>

--
Pretty Pictures!
1. Re:I wonder by CoolVibe · 2003-11-19 04:24 · Score: 5, Informative
  
  It's already very good (and stable). Well allright, sometimes it breaks (that's development for ya), but wait a few hours, and the system is stabilized again (patches are backed out, or bugfixes get in). It's not like CURRENT, where you can hose your system beyond recognition if your not careful.
  Your Distributed.net client will Just Work Fine(tm). I'm still running that KDE 3.1.4 on my laptop that I compiled under 4.9-RCmumble, and that's still working quite spiffy.
  Dragonfly is almost a drop-in replacement. You can just pull it over your existing 4.x-STABLE box, and all your apps should work fine (except for kernel modules). Oh, if you have an NVIDIA gfx card, I ported the binary kernel module to DFBSD, and it's sitting smugly in the override ports. (read dfly's UPDATING about dfports)
  DragonFly as of current perfectly fills that niche where people want the latest and greatest, but don't want to run FreeBSD-CURRENT just yet. It's mostly production-safe. You can always revert back to your old FreeBSD-STABLE without much hassle.
  So, if you're really curious, just give it a go!
2. Re:I wonder by merdark · 2003-11-19 09:52 · Score: 4, Interesting
  
  I think this is one of the most promising new OS (or OS varient if you want to be picky). Personally, I can't wait for the package management system to get set up. Eventually, you will be able to run DBSD with binary only upgrades and installs. Should be cool.
  
  Ports are great, but damn does my p2 400 dislike hours and hours of compiling. :)
3. Re:I wonder by kkenn · 2003-11-21 12:56 · Score: 1
  
  Sounds a bit unlikely to me..it might be stable now because relatively few major changes have occurred, but when you track a development version of an OS you will run into serious problems from time to time, especially as it diverges more from FreeBSD-STABLE.
4. Re:I wonder by CoolVibe · 2003-11-23 23:43 · Score: 1
  
  You are right of course. Eventually it will be virtually impossible to do a clean switchover. But the DragonFly community is doing as much as they can to make the upgrade path as uneventful as possible.
  Even though it might not be possible in the future to 'upgrade' to DragonFly from a FreeBSD-STABLE machine, we'll try the hardest to keep the FreeBSD port system working until we have our package management sorted out. And boy, with the stuff that Matt has planned, that's going to be beautiful. Not the compilation of hacks that the package/port system is today. Not to blast the port system, it's serving us well at the moment, but there's always a better way :)
Variant symlinks are really cool by Euphonious+Coward · 2003-11-19 04:34 · Score: 5, Interesting

Variant symlinks as found in Domain OS (nee Domainix, nee Apollo Aegis) are symlinks that refer to environment variables, e.g.
ln -s '/etc-$(HOSTNAME)' /etc
to help enable sharing the root file system. (I don't know the variable-reference syntax used in Dragonfly). This was one of the really cool things about Aegis, which was based on Multics, not Unix. Unix/Linux/BSD have still not caught up to the networking capabilities of Aegis, and what they do have is usually clunkier than the way it was done in Aegis.
I thought about implementing variant symlinks on Linux. Probably it would need a new system call to tell the kernel where the process keeps its environment variables, to be run at each program startup, and a new process table entry field.
1. Re:Variant symlinks are really cool by Anonymous Coward · 2003-11-19 05:57 · Score: 1, Interesting
  
  Variant symlinks as found in Domain OS (nee Domainix, nee Apollo Aegis) are symlinks that refer to environment variables, e.g.
  ln -s '/etc-$(HOSTNAME)' /etc
  
  That's neat ... kinda. But any idea when we're likely to see plan9 namespaces hit any of the free *nix distributions? There's only so much you can do with environment variables after all.
2. Re:Variant symlinks are really cool by CoolVibe · 2003-11-19 06:03 · Score: 5, Informative
  
  Variant symlinks as found in Domain OS (nee Domainix, nee Apollo Aegis) are symlinks that refer to environment variables, e.g.
  
  ln -s '/etc-$(HOSTNAME)' /etc
  
  to help enable sharing the root file system. (I don't know the variable-reference syntax used in Dragonfly).
  It's exactly the same. The variables for symlinks can be set with the varsym(1) tool, and of course the vfs.varsym_enable sysctl has to be set to '1'. You can set symlink variables in global, user and process context.
3. Re:Variant symlinks are really cool by Euphonious+Coward · 2003-11-19 09:43 · Score: 1
  
  I see, it doesn't depend on environment variables as such, but environment-variable-like definitions in another namespace entirely, already known to the kernel. That's probably for the best.
  Where is this documented? A google search suggests that it uses "${var}" bracket notation, not "$(var)" notation as I had written.
4. Re:Variant symlinks are really cool by CoolVibe · 2003-11-19 23:00 · Score: 4, Informative
  
  You are right of course. I don't use varsyms yet, but I had a look at the code and that confirms what you said. Not much documentation yet, but the varsym tool has a manual page. It works like you expect. One sets a variable with varsym, and then you can use that variable (with ${} notation) in symlinks. Example:
  > cat > file-file1 this is file 1 ^D > cat > file-file2 this is file 2 ^D > ln -s 'file-${foo}' test > varsym foo=file1 > cat test this is file 1 > varsym foo=file2 > cat test this is file 2
  
  Of course, varsym defaults to user context, which means that the var is only 'visible' to the user. With the -s flag, the var becomes system wide, and you can also restrict the view to the process.
  There isn't much more to it. It's easy, clean and simple :)
5. Re:Variant symlinks are really cool by CoolVibe · 2003-11-24 00:02 · Score: 2, Insightful
  
  They will be used, but not gratuitously. It's mostly to get our packaging system to go where we want to, without having to worry about the new VFS stuff yet. Variant symlinks solve about 90% of the problems at 10% of the cost, so that's why they were implemented. Also, it kinda depends on what the person that installed DFly on his machine is doing :)
  When DFly's VFS subsystem is getting into shape, the need for varsyms will be less and less.
Hmm, well.. by JVStalin · 2003-11-19 11:40 · Score: 3, Insightful

Things that DragonFlyBSD already has that FreeBSD-STABLE doesn't are, among others, application checkpointing, variant symlinks (not unlike Domain OS), Light-weight kernel threads, a more efficient slab-allocator, a multithreaded network stack, and the rcNG system." Oh, boy! Let's look at 5.1-RELEASE's features: rcNG, KSE, Mandatory Access Control framework, better SMP, fast ATA drivers. I hate to say it, but, DragonFlyBSD is all most as silly as that xMach project. :-) It's about arrogance, not software.
1. Re:Hmm, well.. by endx7 · 2003-11-19 12:58 · Score: 1
  
  [snip DragonFly stuff list]... Oh, boy! Let's look at 5.1-RELEASE's features: rcNG, KSE, Mandatory Access Control framework, better SMP, fast ATA drivers. I hate to say it, but, DragonFlyBSD is all most as silly as that xMach project. :-) It's about arrogance, not software.
  
  It wouldn't surprise me if a good deal of the 'good' things will be ported back to FreeBSD. One of the things about the *BSDs is a lot of (code) sharing goes around.
  
  I'm kinda wondering what DragonFly-STABLE has that FreeBSD-STABLE doesn't have...I mean..wait... >:P
2. Re:Hmm, well.. by marcovje · 2003-11-21 00:25 · Score: 1
  
  I also have that feeling. (porting the best back to FreeBSD).
  
  It seems that there is one production BSD, FreeBSD, and the other ones are research projects, the best of which will be snatched later by the production free Unices FreeBSD and Linux
  
  - NetBSD : portability, cleanness
  - OpenBSD: Security, also a bit portability and cleanness, and a huge batch of stubbornness.
  - DragonFly: Mach kernel experiments.
  - Darwin: Also Mach kernel experiments.
  
  It's not that the above OSes don't have a merit for the user. They got the features in their own terrain first, and due to the fact that they are generally smaller and cleaner can copy eachother faster.
  
  If you happen to really need the feats under research, that can be important.
  
  However the forks can simply not live up to FreeBSD and Linux (and then specially /i386)'s driver base, release engineering, large scale package management and advanced enterprise features.
3. Re:Hmm, well.. by Anonymous Coward · 2003-11-21 05:00 · Score: 1, Insightful
  
  Silly? Such a judgemental attitude seems much more silly than the fortitude it takes to accomplish what Matt has.
  
  I'm happy Matt has a place to try his ideas which have been shouted down time and time again by loudmouth, arrogant Dane and Australian developers (you know who you are).
  
  Dragonfly will either prove the latter to be the FUD frauds we suspect they are or to have been right all along.
  
  Stay tuned, you might just learn something. Then again, maybe not.
4. Re:Hmm, well.. by Anonymous Coward · 2003-11-22 09:06 · Score: 2, Insightful
  
  You might want to take a look at the DragonFly design page. FreeBSD-CURRENT's SMP design is based
  on the traditional "lock everything down" model, which has scaling problems with current hardware trends. In addition, their particular implementation will be particularly hard to maintain in the long run. Really, the only thing you mention that is
  likely to be considered for incorporation in DragonFly is tht ATAng.
  
  You sound like one of the BSD developers who dislikes Matt on principle. So you may be right in your case about the arrogance vs. software.
i have tried a snapshot of dragonfly... by jms258 · 2003-11-20 05:20 · Score: 1

it seems very stable, and we all know matt dillon does good work ...

i think the dragonfly theory of package management will really bring something new to the *BSD table and i plan on continuing my support for the project in the future

personally, i think we need more *BSD forks ... as long as they are productive and (somewhat) original .. i say the more the merrier.
I really wish I had a spare box right now... by acidtripp101 · 2003-11-20 11:29 · Score: 5, Informative

The ONLY thing that was keeping me from using dfbsd was the fact that I had to
a) install freebsd-stable
b) cvsup the dfbsd sources
c) recompile everthing
d) then have my system

Now that dfbsd has it's own ISO, I might have to find an old junk box somewhere to install it on (I actually like freebsd 4.x more than the 5.x series so far... MUCH faster, but I'm sure that'll change when it goes stable (no more debugging symbols, etc.)

--
Not Free(as in beer). Free(as in "I'm free to beat you over the head for being a dumbass")
1. Re:I really wish I had a spare box right now... by Dwonis · 2003-11-23 09:02 · Score: 1
  
  Have you tried VMware?
Re:What kind of chip are you running?!?! by merdark · 2003-11-20 13:45 · Score: 2, Funny

Go touch the core of your P2 when it's working and it'll talk through you. Its a very intense experience. ;)
MIDI support? by thanjee · 2003-11-20 17:35 · Score: 2, Interesting

Doe DFBSD have *WORKING* Kernel MIDI support?

The first BSD to have that will become my favourite. So far FreeBSD is in the lead :)

--
Saying your OS is the best because more people use it is like saying MacDonalds make the best food
1. Re:MIDI support? by unborn · 2003-11-24 02:41 · Score: 1
  
  It had it with my sb16 back on 3.x
Thanks for the reminder... by devphaeton · 2003-11-21 03:52 · Score: 1

I spent last night looking at a spare machine that was given to me, trying to figure out what to put on it...

I would say that DBSD would be as good a choice as any :o)

--

do() || do_not(); // try();
Server Names by devphaeton · 2003-11-21 04:23 · Score: 1, Offtopic

Anyone have any trivia on why the servers that host the daily snapshots are named after an STD?

* FTP: ftp://chlamydia.fs.ei.tum.de/pub/DragonFly
* HTTP: http://chlamydia.fs.ei.tum.de/pub/DragonFly

(on the bottom of http://www.dragonflybsd.org/Main/download.cgi)

I mean, even in German, The Clap is The Clap, right?

--

do() || do_not(); // try();
1. Re:Server Names by CoolVibe · 2003-11-23 23:49 · Score: 2, Interesting
  
  Might I refer you to RFC 2100? It explains why some hosts have such weird names sometimes. :)
Re:What We Can Learn From BSD by Anonymous Coward · 2003-11-21 05:10 · Score: 1, Interesting

Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

Witness Redhat keeping its CVS out of public access. At least the BSD's allow one to track changes to their kernels and back out mistakes made by the developers.

Linux (as delivered by Redhat) is effectively a closed source operating system between releases.
Re:BSD problems by Dwonis · 2003-11-23 09:06 · Score: 1

Enable DMA transfers on your hard disk?
Re:BSD problems by unborn · 2003-11-24 02:35 · Score: 1

You know this is a troll since IT doesn't even mention which BSD flavour IT has problems with.