Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Announcements Operating Systems BSD

DragonFly BSD Announced 460

JoshRendlesham writes "Matt Dillon announced today on the freebsd-hackers mailing list the creation of the DragonFly BSD project. It seeks to build on the work of FreeBSD 4.x, including a rewrite of the packaging and distribution system, among other goals."
This discussion has been archived. No new comments can be posted.

DragonFly BSD Announced

Comments Filter:
  • by imipak ( 254310 ) on Wednesday July 16, 2003 @04:34PM (#6456339) Journal
    Brad Pitt announced a new fork from the -AC kernel tree.
  • Wonderful (Score:5, Funny)

    by Anonymous Coward on Wednesday July 16, 2003 @04:36PM (#6456363)
    This is great news. God knows we need another BSD, I don't think anyone is happy that currently we only have FreeBSD, NetBSD, OpenBSD, TrustedBSD, XMach, Darwin, and Microsoft Windows.
    • by Eric_Cartman_South_P ( 594330 ) on Wednesday July 16, 2003 @06:01PM (#6457058)
      FreeBSD, NetBSD, OpenBSD, TrustedBSD, XMach, Darwin, and Microsoft Windows.

      And listed in order of stability, too! Informative post. :)

    • Surely you can't count the Mach based kernels as "BSD"
      • Re:Wonderful (Score:2, Interesting)

        by Anonymous Coward
        You know I was trolling. Why is it I get modded up when I troll and modded as a troll when I write about something I feel strongly about?

        Anyway, XMach is a version of BSD with a Mach-based kernel. I don't know what's the status of that current project, with Darwin and HURD nipping at its heels (not that either are perfect replacements) its not as popular as it might otherwise be.

        Remember, BSD is also defined by the userland. I look forward to BSD/Linux, the one true user land with the best supported ker

        • Re:Wonderful (Score:3, Informative)

          by usotsuki ( 530037 )
          Here you go [netlsd.org], but I [mailto]'m working on some stuff too.

          -uso.
          • I really hope for you that that is not your real mail address. If so...enjoy the spam...
            • It's URL encoded. A spider reading the page wouldn't grok it.

              Besides, I get 50 spams a day anyway. I don't think it likely that my e-mail address will get slashdotted, any more than it's likely that Goatse.cx or Tubgirl.com will get slashdotted.

              For everything else, I have two private addresses.

              -uso.
    • by yanestra ( 526590 )
      This is great news. God knows we need another BSD, I don't think anyone is happy that currently we only have FreeBSD, NetBSD, OpenBSD, TrustedBSD, XMach, Darwin, and Microsoft Windows.

      Unhappy with *BSD?

      • Too fast?
      • Too stable?
      • Too scalable?

      Solution: Simply fork off a new Windows branch and make it a better server OS.

  • Finally, we believe that a fully integrated and feature-full upgrade mechanism should exist to allow end users and system operators of all walks of life to easily maintain their systems. Debian Linux has shown us the way, but it is possible to do better.

    Oh no! Who will pay the administrators the big bucks now?

    • You know what's funny? When someone cites Debian as a system that "allows and users and system operators of all walks of life to easily maintain their system." Wow. BSD must really be hardcore! Even a Gentoo user like me is shaking in his shoes...
  • Dragonfly BSD is dying...
  • by Anonymous Coward on Wednesday July 16, 2003 @04:41PM (#6456413)
    ...packages and ports system. They're part of the best things FreeBSD has above Linux right now!
    • PORTAGE! (Score:5, Insightful)

      by MarcQuadra ( 129430 ) * on Wednesday July 16, 2003 @04:52PM (#6456525)
      I'd like to see Gentoo's Portage move onto BSD, it was originally inspired by the BSD ports system, but has become very easy to use and refined. It's time for a BSD to try out Portage (Mac OS X is geting Portage soon!)
      • Re:PORTAGE! (Score:3, Informative)

        Ewww. No thanks

        You need to rsync quite often and I noticed several broken ports.

        FreeBSD ports are simple tcsh scripts that are well tested and integrated since the whole FreeBSD team tests them out. The ports themselves are more stable and under FreeBSD I can chose specific mirrors to specific packages. Try that with portage?

      • Please, oh people, will someone tell me what the facination with portage is? Everyone saying how great it is, but I have yet to find anything that can't be done in the BSD ports, easier...

        By all means, fill me in...
  • by HiFire ( 680198 ) on Wednesday July 16, 2003 @04:54PM (#6456537)
    I find this project exciting. Having tried gentoo's portage it has become clear to me that ports could be a lot better. While ports does work, it has a bunch of tools which make its use easier which arent included by default and could be integrated into ports.
  • Are they talking about replacing the ports system? I thought that that was one of those most revered parts of the original FreeBSD
    • by dododge ( 127618 ) on Wednesday July 16, 2003 @06:21PM (#6457199)
      Are they talking about replacing the ports system?

      It's more than just replacing ports with portage, or apt-get, or some other userspace packaging system.

      What they're talking about doing is having kernel support for packaging. Multiple versions of the same library could be installed with the same filename simultaneously. An application would see the correct versions of the things it needs, and it would see only the things it needs, despite what else might be installed. This is to allow for piecemeal/partial upgrades among other things.

      To which I say: HALLELUJAH BROTHER!

      This is exactly what I've been wanting to graft onto Linux for some time now; my latest thinking is that it could be done with a userspace filesystem (to make files visible/invisible), extended attributes (to associate the visibility contexts with application binaries), and a bit of extra process state. If the DragonFlyBSD folks make it work, it'll be intrestesting to see how this behaves from an administrative point of view.

      In any case, this is not just a userspace change. This involves the kernel itself.


      • you mean like VMS? I think the VMS filesystem did file versioning similar to this.
    • Actually, the ports system is not so much what is so heroic about ports, it's the ports collection - namely, that the patches exist and are centralized. There are a couple examples of ports done better than FreeBSD ports, like OpenBSD's ports and of course the ubiquitously mentioned Gentoo Portage.

      The ports system was certainly something of a breakthrough, and the various imitators (and improvers) are simply biting its style, even if they are making improvements.

  • by jednet ( 241443 ) on Wednesday July 16, 2003 @04:59PM (#6456579) Homepage Journal
    What were they thinking when they named their project after a bug?
  • BSD and Smart People (Score:3, Interesting)

    by mslinux ( 570958 ) on Wednesday July 16, 2003 @05:05PM (#6456620)
    The problem with BSD is that there are too many Albert Einstein-like people involved with its development... and Matt Dillion is one of them. I don't mean that in a bad way. These guy are *smart* probably one in a billion kind of smart. The problem with that is they can't work together very well. Theo (Open BSD), Matt (FreeBSD) Both these guys forked over differences of opinion with other developers.

    Imagine what these guys could actually *do* if they put aside their differences and worked together!! No unsolved CS problem would be safe.
    • by Anonymous Coward
      The thing is, reading his proposal, this thing could be great- it's some of the best aspects of his BSD work, and things like AmigaOS, Be, HURD, and even Linux, rolled into one "modern," innately UNIX-compatible whole.

      People only live so long- sure, if you could somehow force all the gurus into a "Manhattan Project," they'd probably spit something interesting out the other end, but there'd be more tradeoffs involved. You can't have a system as (philosophically) tight as OpenBSD when people are merging hug
  • Matt Dillon, eh? (Score:2, Interesting)

    by Spudley ( 171066 )
    Wow. Matt Dillon. :) There's a name that brings back memories.

    Matt: if you're reading this, I loved DICE, and all your other work on the Amiga - your compiler is one of the reasons I'm a programmer today. I hadn't been keeping up with your work but it's good to see you're still out there doing stuff. :)
    (seems a lot of the old Amiga 'big names' have gone on to do interesting stuff in the time since)
    • Matt: if you're reading this, I loved DICE, and all your other work on the Amiga - your compiler is one of the reasons I'm a programmer today. I hadn't been keeping up with your work but it's good to see you're still out there doing stuff. :) (seems a lot of the old Amiga 'big names' have gone on to do interesting stuff in the time since)

      I agree with what you wrote. Also he was great in Drugstore Cowboy and The Outsiders.

    • Re:Matt Dillon, eh? (Score:5, Interesting)

      by m.dillon ( 147925 ) on Wednesday July 16, 2003 @05:59PM (#6457040) Homepage
      You are welcome, and ditto to the other followup poster! Now for the scary part: Despite the demise of the Amiga there are still people who use DICE, and DASM (65xx/687xx assembler). Apparently DASM has become a favorite in the classic Atari world. There are also still many old hardware installations based on the 68K and DICE is one of the few (complete) compiler toolsets for the 68K that can be run on a modern platform. Yow!

      -Matt

      • So Matt, what do you think of the new n:m Linux scheduler in kernel 2.6? I have played with it and its as smooth as butter. It is the only thing I am envious of from someone in the FreeBSD camp. Its almost realtime.

        I think that and multiple que's for each cpu can make quite a scalable system. It would rock if Dragonfly or FreeBSD implemented these features.

        I looked at your notes on threading and it sounds pretty cool even though I am not an OS developer. Threads are one of the few weaknesses if any in BSD
    • Memories, eh? You must be about 35 years old, too, and grew up watching Gunsmoke on CBC television, back in the days when the only channels were broadcast signal.

      Remember Ms. Kitty? When I was five, I was in love with her. I only found out that she was a woman of ill-repute (or at least some questionable sexual mores) when I was in my twenties. ...

      Damn. Googled it. It was Marshall Dillon, not Matt.

      Ah, hell. what's a few letters difference between friends anyway?
  • Paging Lorraine (Score:5, Insightful)

    by jonabbey ( 2498 ) * <jonabbey@ganymeta.org> on Wednesday July 16, 2003 @05:26PM (#6456769) Homepage

    Matt Dillon's early background as an Amiga programmer is really showing through here. He's basically proposing doing a piecewise conversion of BSD to an Amiga-style message-passing operating system.

    He's basically doing the reverse of what so many folks (NeXT, HURD) have done or tried to do.. not taking a microkernal and putting a UNIX layer over it, but taking a UNIX and scooping out the inside to replace it with a message-passing microkernal.

    This will definitely be a fun one to watch. Go, Matt, go.

  • by foolip ( 588195 ) on Wednesday July 16, 2003 @05:26PM (#6456772) Homepage
    My first reaction was "oh, forking is bad, we don't need another". But in truth, this is no more remarkable than the fact that there are 100s if not 1000s of different flavors of GNU/Linux.

    So there.
    • It's a double edged sword, you divide the codebase and you might divide the market. However, I think that the hundreds of versions of Linux have been really good in that they've created a fairly cutthroat Darwinian environment. We as users and admins can only benefit from the innovations coming from that. I really believe that evolution is the method most likely to create a platform to supercede all others.

      But then maybe I liked Blondie 24 [harcourt-i...tional.com] too much.
    • Matt Dillion was kicked out of the FreeBSD team several months ago. I would post an url but I am too lazy. He was one of the top FreeBSD developers.

      Unlike Linux, the *BSD teams are selective on who writes to where and if you piss a few of them off they have the power to refuse and delete your code.

      This is why BSD forks more often then Linux. Linux has mini-forks with packages and if it works well and demand is for it Linus typically will accept it and remerge it back. Look at Riser as an example. The auth
    • "But in truth, this is no more remarkable than the fact that there are 100s if not 1000s of different flavors of GNU/Linux."

      but how many linux distros have forked the kernel, rather than just repackaging/patching the standard kernel?
      • but how many linux distros have forked the kernel

        Let's see, how many commercial linux distros are there? If something's appended to the version number, it's a fork. Fortunately, if a new kernel feature proves useful or popular, Linus lets it in. Otherwise there would be a reign of confusion.

        The BSD forks are of a different kind. NetBSD and FreeBSD forked off the same codebase (386BSD) simply because neither project was aware of the other until too late. OpenBSD forked off primarily because of personality
  • The proposed new messaging layer sounds really interesting and powerful. A little like Mach or QNX, perhaps? Many kernel methods and system calls will use messaging instead of traditional brittle techniques that often lead to API problems down the road. Also, multithreaded kernel design should be simplified as result. My only question is how much will this slow down FreeBSD?
    • Re:Messaging layer (Score:5, Interesting)

      by Chexum ( 1498 ) on Wednesday July 16, 2003 @05:51PM (#6456975) Homepage
      The proposed new messaging layer sounds really interesting and powerful. A little like Mach or QNX, perhaps?
      No (or perhaps yes), from the superficial look, it seems very similar to the AmigaOS exec.library's functions. No surprise here, given Matt's background as an arch-developer for Amiga :) See also DICE [obviously.com]: Dillon's C Compiler... It's very weird to see the Amiga resurrected inside BSD..
      • Re:Messaging layer (Score:5, Informative)

        by m.dillon ( 147925 ) on Wednesday July 16, 2003 @06:54PM (#6457414) Homepage
        There are many Amiga-like concepts incorporated into the model, and plenty of new stuff as well. The Amiga had a highly optimal messaging system oweing to the fact that it ran on such a slow cpu making every cycle golden. Two features have been taken from the Amgia I/O model. First, the idea that the target can choose to perform an operation synchronously or asynchronously entirely independant of the type of operation the client has requested. In the Amiga model the client passes a hint which the target may choose to act on or choose to ignore and so do we.

        Another feature taken from the Amiga I/O model (for those who ever looked at the actual assembly code) is the ability to short-cut queueing operations. For example, if the target is able to execute a message synchronously regardless of what the client requested, the target can execute the message in the client's context and return a synchronous result code without even bothering to queue the message (I/O request in Amiga terminology). Likewise, if the client wants to run an operation synchronously and the target decides to run it asynchronously the target doesn't have to queue the message back to the client's reply port when it is through, it simply wakes the (blocked) client up.

        To make messaging truely efficient the 'optimal' case must have the lowest possible overhead. The Amiga model serves this requirement very nicely, making optimally handled messages take no more overhead then a subroutine call would take. This is extremely important in an MP design because queueing operations often require some sort of lock and being able to avoid a queueing operation in the optimal case is simply *HUGE*.

        Consider the optimal syscall path given the above. If a syscall can run without blocking your syscall 'message' winds up costing no more then a traditional syscall would. After all, there is no point asynchronizing a syscall that can run without blocking, you only have one cpu for any given userland thread anyway so you can't make things faster by switching out to handle something else and then back again. Yet in a traditional asynchronizing model like AIO, a great deal of effort and overhead is taken before you even know whether the I/O operation would block or not, making AIO expensive no matter how you cut it. The same goes with a select() based operation. And in a KSE style operation the expense occurs in having to maintain multiple kernel threads for system calls which are in-progress, instead of much smaller message structuers for system calls which are in-progress. The above Amiga-like features make it possible to encapsulate *ALL* system calls in messages, request asynchronous completion, yet still deal with synchronous completion in a manner which does not introduce a performance penalty.

    • Re:Messaging layer (Score:5, Interesting)

      by Billly Gates ( 198444 ) on Wednesday July 16, 2003 @06:39PM (#6457316) Journal
      Matt Dilion was fired from the FreeBSD team.

      Technically its not a job but they refuse all his patches and he lost write access. The chances now of it being merged into FreeBSD are remote.

      He had no choice but to fork if he wanted to continue developing. That or join the Openbsd team or Linux.

      Infact Dillion help fixed the vm bug in Linux 2.4. He actually has already developed Linux code.

  • What does an old gunslinger [imdb.com] have to do with this announcement? Even more important... will Miss Kitty [puzzlehistory.com] be involved?

  • by DarkHelmet433 ( 467596 ) on Wednesday July 16, 2003 @06:15PM (#6457158)
    Having NetBSD/FreeBSD seperate was good in many ways because it kept mutually incompatable folks away from each others throats. Once things cooled down, technology began to flow in both directions between NetBSD and FreeBSD. Later on, OpenBSD came along. All sorts of good things came from that. Can you say OpenSSH?

    It would be nice if DragonFlyBSD (gah, ENAMETOOLONG) was a similar deal. As a FreeBSD developer, I hope that there will be plenty of opportunities to take good stuff in both directions. If we can keep people away from each others throats and work on making the code better, then everybody wins.

    Diversity is good. Developers fighting each other is bad. Forks can be a good way to relieve the stress. There is no need to make a Big Deal(TM) about it.
    • universal package system?
      Darwin, Fink and Gentoo are working together to make a shared package system.

      Since everyone says, well since it is Unix-like, it probably only takes a recompile to port from X to Y... well, why not have a sourve based package system, and get the BSD's, Fink, Darwin, and Linux to jump on board? a simpel 'install' or 'make' script and BLAM, life is SO much easier.
  • Security? (Score:2, Insightful)

    It strikes me that, for any operating system capable of interacting with a network, security should be addressed as a top-level goal. I don't see it even mentioned on the web site.

    - Not Theo, but not Bill either


  • I'm a FreeBSD user, but not by religion. I use Linux on certain systems where some distro fits better.

    However during daily usage FreeBSD simply turned to be superior to the big few Linux distro's as far as release engineering goes.

    Matt branches, but let's take reasons and goals to be unimportant for now.

    How is he going to sustain _any_ release engineering the quality FreeBSD (and the major Linux distro's) has/have?

  • Does this mean that VoIP on Dragon Fly might put me in touch with my hero ELVIS, maybe even get him to sing?

Reality must take precedence over public relations, for Mother Nature cannot be fooled. -- R.P. Feynman

Working...