Slashdot Mirror


DragonFly BSD Announced

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."

3 of 460 comments (clear)

  1. Re:Messaging layer by Chexum · · Score: 5, Interesting
    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: Dillon's C Compiler... It's very weird to see the Amiga resurrected inside BSD..
    --
    "Ten years from now, they could do it in a few seconds." -- The Racketeer of the Hellfire Club, 1993, Phrack 42
  2. Re:Matt Dillon, eh? by m.dillon · · Score: 5, Interesting
    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

  3. Well, good luck to him! by DarkHelmet433 · · Score: 5, Interesting

    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.