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

460 comments

  1. In other news by imipak · · Score: 4, Funny

    Brad Pitt announced a new fork from the -AC kernel tree.

    1. Re:In other news by Tumbleweed · · Score: 5, Funny

      > Brad Pitt announced a new fork from the -AC kernel tree

      Rule 1: You do not talk about the -AC kernel tree.
      RUle 2: You DO NOT talk about the -AC kernel tree.
      Rule 3: If it's your first night in the -AC kernel tree, you HAVE to post.

    2. Re:In other news by caluml · · Score: 0, Offtopic

      Offtopic? Stupid mods. Tumbleweed, have a "virtual" mod point from me.

    3. Re:In other news by Anonymous Coward · · Score: 0, Redundant

      "what can we learn from the above?"

      That you are a fucking idiot? Yeah, that's probably it.

    4. Re:In other news by Spunk · · Score: 1

      Truly an American icon.

    5. Re:In other news by Coffin+Joe · · Score: 0, Flamebait

      Tom Cruise is realeasing the DyingBSD, a new BSD flavor ... Go and get it before it is over .... ... sorry my pour english ... :^P

    6. Re:In other news by Anonymous Coward · · Score: 0

      Inflammatory personal attack? Insightful.

      Self-effacing humourous comment? Troll.

      Slashdot moderators in fucking action.

    7. Re:In other news by Anonymous Coward · · Score: 0

      Here's a URL for you, CNN Science News.

    8. Re:In other news by Anonymous Coward · · Score: 1, Funny

      In Soviet Russia BSD FORKS YOU!

    9. Re:In other news by Anonymous Coward · · Score: 1, Funny
      Dear Father O'Day:

      Thanks for your letter. Being Catholic myself, I know exactly what you're talking about! It has always been our plan here at Apple Computer Inc to revolutionize personal computing with our high-quality and highly gay products.

      I'm happy to answer your letter by letting you know that YES we will be releasing an entire hLife ("homo-life") software line. You'll be able to recognize it in stores by the small stylized logo depicting a large cock entering a tight anus with an Apple logo on it. ("Suddenly it all comes together" indeed!).

      Anyway, I hope you and other members of our community will join us on our mission, and purchase the exciting new hLife boxed set. Only the boxed set comes with translucent cock rings!

      Sincerely,

      Harry Rodman
      Vice-president
      Homosexual Liaison Services
      Apple Computer, Inc.

    10. Re:In other news by Anonymous Coward · · Score: 0

      Very interesting. Thanks for the link.

  2. And also by Anonymous Coward · · Score: 0

    Keannu Reeves announced: "Whoah."

  3. Wonderful by Anonymous Coward · · Score: 5, Funny

    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.

    1. Re:Wonderful by Anonymous Coward · · Score: 0

      Don't forget MirBSD!!!

    2. Re:Wonderful by carpe_noctem · · Score: 0, Troll

      MS Windows is a BSD? Am I missing something? /me checks out c:\winnt\ports

      --
      "Quoting famous computer scientists out of context is the root of all evil (or at least most of it) in programming." - K
    3. Re:Wonderful by Anonymous Coward · · Score: 1, Informative

      I think he's just making a sarcastic comment on the presence of BSD code in Windows.

    4. Re:Wonderful by EelBait · · Score: 0, Troll

      I think in the case of Windows, BSD = Blue Screen of Death. Your parent poster was probably just confused.

    5. Re:Wonderful by gantrep · · Score: 3, Insightful
    6. Re:Wonderful by Elwood+P+Dowd · · Score: 2, Insightful

      Try "strings ftp.exe"

      Or, if you don't have strings installed, just google for it.

      Iduno what else they've used, but they're legally entitled to use any portion they like, and many people surmise that they may have used quite a bit. Given that the copyright notice is no longer required, the world may never know.

      --

      There are no trails. There are no trees out here.
    7. Re:Wonderful by patbob · · Score: 1
      I understand they are taking from the community without giving back that that's "bad".

      However, doesn't it make them more and more like unix (BSD, Linux, etc.). Isn't it the case that the more like unix they become, the easier it will become to replace them with unix outright. Taking from the community without giving back isn't beneficial to the community, but being able to flat out swap out windows and put unix underneath their apps surely would be good for the community. If only MS would adopt the system call API that unix uses, their fate would be sealed.

      --
      Welcome to the net of 1000 lies. Upgrades are scheduled soon that should bring us to the 10,000 lies mark.
    8. Re:Wonderful by Arandir · · Score: 1

      They took part of the TCP/IP stack. Big fat hairy deal. So did every other OS on the face of the planet, including Linux for a period of time.

      --
      A Government Is a Body of People, Usually Notably Ungoverned
    9. Re:Wonderful by Eric_Cartman_South_P · · Score: 5, Funny
      FreeBSD, NetBSD, OpenBSD, TrustedBSD, XMach, Darwin, and Microsoft Windows.

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

    10. Re:Wonderful by Arandir · · Score: 2, Informative

      The copyright notice is STILL required. Only the advertising requirement was dropped. Which means they no long have to loudly announce the fact that they used the code, but that they are still forbidden from hiding that fact.

      --
      A Government Is a Body of People, Usually Notably Ungoverned
    11. Re:Wonderful by Trolling4Dollars · · Score: 1

      What about BSoD? That would qualify Windows wouldn't it?
      *rimshot*
      *ducks*

    12. Re:Wonderful by lateral · · Score: 1

      Yes indeed, what would Windows be without FTP?

      </sarcasm>

      L.

    13. Re:Wonderful by AxelTorvalds · · Score: 1

      Surely you can't count the Mach based kernels as "BSD"

    14. Re:Wonderful by yanestra · · Score: 2, Funny
      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.

    15. Re:Wonderful by Anonymous Coward · · Score: 2, Interesting
      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 kernel. Not going to happen but I can dream.

      As far as the Windows comment, that others have commented upon, yeah it was an off-the-cuff why-not-put-that-in thing with the infamous TCP/IP stack thing at the back of my mind. Mind you, apparently most layers of that stack have been rewritten, leaving a handful of userland utilities such as FTP that still have BSD code in them.

    16. Re:Wonderful by Anonymous Coward · · Score: 0

      ftp is an application that uses the sockets API. It isn't part of the TCP/IP stack. It's not likely the stack has any BSD code. It just doesn't =behave= like a BSD stack.

    17. Re:Wonderful by usotsuki · · Score: 2, Informative

      Here you go, but I'm working on some stuff too.

      -uso.

      --
      Dreams, dreams, don't doubt dreams, dreaming children's dreaming dreams. Sailor Moon SS
    18. Re:Wonderful by Anonymous Coward · · Score: 0

      Windows uses BSD code...does that mean it's UNIX?

      If I make a house using wood, does that mean that the house is a tree?

    19. Re:Wonderful by Hard_Code · · Score: 1

      I really hope for you that that is not your real mail address. If so...enjoy the spam...

      --

      It's 10 PM. Do you know if you're un-American?
    20. Re:Wonderful by Anonymous Coward · · Score: 0

      You forgot one.. here is the revised list:

      FreeBSD, NetBSD, OpenBSD, TrustedBSD, XMach, Darwin, Microsoft Windows, and Linux.

      Listed from great to total crap. ;)

    21. Re:Wonderful by usotsuki · · Score: 1

      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.

      --
      Dreams, dreams, don't doubt dreams, dreaming children's dreaming dreams. Sailor Moon SS
    22. Re:Wonderful by usotsuki · · Score: 1

      You might not realize it, but I actually posted the BSD Is Dying troll myself (note the '-uso.' on it).

      I, frankly, beg to differ. BSD is alive and well - and the troll's information is wildly inaccurate.

      I myself dabble in BSD - OpenBSD userland porting. If you download FreeDOS ODIN 0.4, there is a "cal.com" program included, and guess where it comes from. OpenBSD.

      Maybe it is dying (although, evidence points otherwise). No open-source OS of the scale of BSD will ever completely die. Someone will just fork and run. In fact, witness FreeBSD, NetBSD and Dragonfly.

      -uso.

      --
      Dreams, dreams, don't doubt dreams, dreaming children's dreaming dreams. Sailor Moon SS
    23. Re:Wonderful by Anonymous Coward · · Score: 1, Insightful
      they are still forbidden from hiding that fact.

      So BSD is not really free, is it? There are strings attached.
      Glad I found out before wasting my time downloading it.

    24. Re:Wonderful by steeviant · · Score: 1

      Find me a truly free operating system.

      As far as I know, there is no operating system, free or otherwise that will let you entirely conceal the name of it's creators.

      I wonder what operating system you're using?

    25. Re:Wonderful by steeviant · · Score: 1

      Ka-Ching!

      Another few cents to "Grass Roots Inc." a division of Microsoft.

    26. Re:Wonderful by Anonymous Coward · · Score: 1, Funny

      After all, BSD has way too many distributions, lets see oh about 6.

      Linux has about 2 x 10^4 distros.

      Good point.....NOT

    27. Re:Wonderful by Anonymous Coward · · Score: 1, Funny

      Heathen!!! You've misquoted the holy scriptures once again! Anonymous Coward you will burn in hell for all eternity!

      From the gospel according to BSDTroll:

      "Thus sayeth the Torvalds, "Verily I say unto you, the wages of BSD is death."" (Nested quotes)

    28. Re:Wonderful by grp · · Score: 1

      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,

      Forking can be a good thing. It allows for ideas that may not have had a chance otherwise. Look at what has happened with Linux. There are distros that give a wide variety of different user experiences, and many that fill a niche. Though, the existing BSD's are already pretty nice, it doesn't hurt to have another flavor.

    29. Re:Wonderful by Arandir · · Score: 1

      Wait seventy five years or so. Then Linux 0.97 and FreeBSD 1.0 will be in the public domain.

      The sole purpose of the BSD license is to keep the warranty disclaimer attached. This is necessary for the legal health of the developers and distributors. Otherwise it's the next best thing to public domain.

      --
      A Government Is a Body of People, Usually Notably Ungoverned
    30. Re:Wonderful by Anonymous Coward · · Score: 0
      I'll try to use a metaphor to explain it. Ok then, who would you rather date,
      1. Anita Bryant
      2. Alicia Silverstone
      3. Moms Mabley
      4. Jenifer Lopez
      Touch choices, maybe? It's the same way with Windows/Linux/BeOS/BSD -- whatever. You see it all depends on what *YOU* are looking for. There is no right or wrong answer, is there?

      P.S. I'd choose Alicia!

    31. Re:Wonderful by acidtripp101 · · Score: 1

      Great comeback... Well, you could probably tell where I was going with that.

      --
      Not Free(as in beer). Free(as in "I'm free to beat you over the head for being a dumbass")
    32. Re:Wonderful by Anonymous Coward · · Score: 0

      Elegy For *BSD


      I am a *BSD user
      and I try hard to be brave
      That is a tall order
      *BSD's foot is in the grave.

      I tap at my toy keyboard
      and whistle a happy tune
      but keeping happy's so hard,
      *BSD died so soon.

      Each day I wake and softly sob
      Nightfall finds me crying
      Not only am I a zit faced slob
      but *BSD is dying.

    33. Re:Wonderful by KrispyKringle · · Score: 1

      They briefly implemented part of the TCP/IP stack in NT3.5, if I remember right. They do not, supposedly, still use BSD code. Or at least, I don't see that notice in XP.

  4. administrators by geekmetal · · Score: 2, Funny
    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?

    --
    There are two kinds of egotists: 1) Those who admit it 2) The rest of us
    1. Re:administrators by be-fan · · Score: 1

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

      --
      A deep unwavering belief is a sure sign you're missing something...
    2. Re:administrators by CableModemSniper · · Score: 1

      apt and dpkg rule. debian is reeeeeeeeeeeeeaaaally easy to maintain. really. I started using gentoo on one of my boxes. You know what I missed? If I install a new *dm (gdm, kdm xdm) what have you it asks me which one I want to use as the default. I never had to type rc-update add something default to add to the system services. I'll admit the rc-update thing is really cool for taking stuff out, but if i say emerge openssh that probably means I want it to start the server when its done installing. People get all huffy about how emerge and apt are more or less the same thing but gentoo uses source, and therefore gentoo is better. Source is cool, but having debian ask me the how much it wants to bother me about configuration issues is cooler. Debian saying the package maintainer has released a new version of config file x is much cooler then /etc/._00whwhwerht00_rc kind of stuff. Debian isn't just apt. Its the whole packaging system that makes it great. And easy. Debian really isn't hard. Especially not compared to gentoo. Gentoo holds your hand a lot less.

      --
      Why not fork?
  5. And I thought... by Anonymous Coward · · Score: 0

    Here I was thinking that BSD is dead or dying. Maybe this will revive it...

    1. Re:And I thought... by cshark · · Score: 1

      I liked it. I think it's time for a new BSD, maybe something with an easier setup like the newer linux distros would be nice. Manually partitioning a hard drive is scary stuff. But I'm not holding my breath. The thing I didn't like about the site was that it's not very well designed, and the navigation scheme is confusing. It needs work, but over all, very promising.

      --

      This signature has Super Cow Powers

    2. Re:And I thought... by Anonymous Coward · · Score: 0

      Your kidding right? Sure the BSD installers are not 'friendly' if your not willing to read the manual. Manually partioning the harddrive is scary? That is no where near as scary as users aka the ID10T.

    3. Re:And I thought... by Anonymous Coward · · Score: 0

      Actually, partitioning a hard drive in BSD is a lot less scary than doing it in Linux. Linux bfdisk-style programs (wanna know what the "bf" stands for?) are evil. Sysinstall simply works.

    4. Re:And I thought... by Anonymous Coward · · Score: 0

      Get used to it buddy. The rest of us live in the real world.

    5. Re:And I thought... by ph43thon · · Score: 1

      the FreeBSD install couldn't be any more simple. (might could look nicer) It has an option to automatically assign slices for the /usr /var directories.. etc. The only complicated part of a FreeBSD install is picking what things you want to install. IMO

    6. Re:And I thought... by Anonymous Coward · · Score: 0
      The End of FreeBSD

      [ed. note: in this text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]

      When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.

      Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.

      FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.

      It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.

      So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.

      Discussion

      I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.

      From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.

      There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.

      Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.

      Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?

      Shouts

      To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.

      To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals. It's when y

  6. T1? hah! by Anonymous Coward · · Score: 0
    The site is:

    http://www.dragonflybsd.org/

    Hopefully my T1 can handle the cvsup load. Eventually I'll colocate some boxes to deal with that issue.

    <voice person="nelson">Ha ha!</voice>

  7. Obligatory Dying Post by Rakefighter · · Score: 2, Funny

    Dragonfly BSD is dying...

    --

    --Life may have no meaning, or, even worse, it may have a meaning of which you disapprove.

    1. Re:Obligatory Dying Post by dragonfly_blue · · Score: 1

      I resent that remark. :-)

      --
      Free music from Jack Merlot.
    2. Re:Obligatory Dying Post by outsider007 · · Score: 1

      matt dillon has finally achieved his life's dream:
      working with retards. (something about mary reference)

      --
      If you mod me down the terrorists will have won
    3. Re:Obligatory Dying Post by Anonymous Coward · · Score: 0

      All major surveys show that *BSD has steadily declined in market share. *BSD is quite ill and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.

    4. Re:Obligatory Dying Post by Anonymous Coward · · Score: 0
      Certainly we all can find common ground by acknowledging the plain truth that in the balance *BSD would have to be considered a failure. So why did *BSD fail? What is at the root of *BSD's colossal miscue?

      Once you get past the fact that *BSD is fragmented between a myriad of incompatible kernels, there is the historical record of failure and of failed operating systems. *BSD experienced moderate success about 15 years ago in academic circles. Since then it has been in steady decline. We all know *BSD keeps losing market share but why? Is it the problematic personalities of many of the key players? Or is it larger than their troubled personalities?

      The record is clear on one thing: no operating system has ever come back from the grave. Efforts to resuscitate *BSD are one step away from spiritualists wishing to communicate with the dead. As the situation grows more desperate for the adherents of this doomed OS, the sorrow takes hold. An unremitting gloom hangs like a death shroud over a once hopeful *BSD community. The hope is gone; a mournful nostalgia has settled in. Now is the end time for *BSD.

  8. Why dork with the existing FreeBSD... by Anonymous Coward · · Score: 5, Insightful

    ...packages and ports system. They're part of the best things FreeBSD has above Linux right now!

    1. Re:Why dork with the existing FreeBSD... by alph0ns3 · · Score: 0

      The packages and ports system of FreeBSD is nice, but I don't think it's above the best Linux ones. You can even have a copy of the FreeBSD one with gentoo...

    2. Re:Why dork with the existing FreeBSD... by binutils · · Score: 1

      I wish FreeBSD would use stow to manage everything in base.

      I have been a FreeBSD user since 2.0, it's great. The only rub is I've always disliked having everything included with "base". Often I use NetBSD or OpenBSD just so I don't have to install gcc or perl (I'm lazy).

      What I'd really like is if FreeBSD would use stow
      http://www.gnu.org/software/stow/stow.html
      to manage gcc, sendmail, bind, perl etc.. (tho there is now mailwrapper and perl has been removed from base in 5) I think the author of mailwrapper saw a problem w/ lack of flexability having everything within base and made an attempt to fix this. Tho mailrapper works, I think stow would have been a better solution.

      I think it would really make life easier using stow to manage packages.

      Just an idea. Thanks for taking time to read my comment.

    3. Re:Why dork with the existing FreeBSD... by JamesKPolk · · Score: 1

      perl has been moved to ports in FreeBSD 5.

    4. Re:Why dork with the existing FreeBSD... by __past__ · · Score: 1
      I personally think that using the same package format as for the ports would be a better idea that introducing yet another mechanism like stow, but that's a detail. I certainly agree that a more modular base system would help.

      Doesn't NetBSD do this now?

      IMHO it was a very good decision to move perl to ports. I can see the same for other contributed parts at least, say bind, sendmail or cvs which not everybody needs.

    5. Re:Why dork with the existing FreeBSD... by Anonymous Coward · · Score: 0

      Why "dork" with the existing ports system?! Just cos it is one of the best, doesnt mean we shouldnt try to do better. Better is always possible. Thank goodness someone has the balls to try. Im sure we will learn a lot from this effort, irrespective if it succeeds or fails.

    6. Re:Why dork with the existing FreeBSD... by binutils · · Score: 1

      as stated in my original comment.

    7. Re:Why dork with the existing FreeBSD... by phoenix_rizzen · · Score: 1

      Because the base OS is part of it, the included third-party software can't be updated using it, because there is no version built into it.

      Those are the main reasons that several different projects have been started over the years to replace the port tree. Unfortunately, none have come to fruition yet.

      It would be really nice to have just about everything included as a port. The installer would install the kernel, the shell, a few utilities, and the like, just enough to get a running system. Everything else (MTA, DNS, DHCP, extra shells, programs, etc) would be a port.

      That's the goal of the various projects. Hopefully Matt can make it happen.

    8. Re:Why dork with the existing FreeBSD... by Anonymous Coward · · Score: 0

      The BSDs generally don't like software with a license more restricive than BSD in the basic non-developer installation...

  9. Re:Another one? by Anonymous Coward · · Score: 0

    Once could ask the same of linux people. Why do we need 9000 linuxes, anyway? Last I checked, not counting Mswindows, we've only got three or four BSD's. Why not another one? Why not 8000 more? Gotsta stay competitive you insensitive clod!

  10. Re:Another one? by Kiriwas · · Score: 4, Interesting

    That doesn't make sense to me. Thats like deciding there are too many car manufacturers and complaining to Ford that there should be fewer and better car manufacturers. In fact, it would be EASIER to do this in the car industry because you can probably get the major car manufacturers together. No one ever said this new BSD was going to be good, just that it was here. No one said you should support it, but then again maybe you should. Each distro of anything is subject to the people that make it. If you want one final all encompassing sent-from-God BSD then go and make it!

  11. This won't succeed because... by Anonymous Coward · · Score: 0

    ...it doesn't have a cute little daemon in its logo.

  12. Re:alright, suckas by Anonymous Coward · · Score: 0

    "BSD is dying"

    That's another distro, right?

  13. Re:Another one? by Anonymous Coward · · Score: 0

    Fewer distributions? Letseee.. There's open net and free.
    That's three. There are some minor versions (e.g., picobsd)
    based on these.... There's also OSX/Darwin.

    That's too many for you? Before you answer, consider
    how many linux distros there are.

    Also, please follow up with proof, statistics and something
    more tangible that the crap you pulled out of your ass that
    having many distributions is inefficient. This is a conclusion
    you've reached, I suspect, without any proof or careful
    analysis. Show us the numbers that this is a 'bad' thing
    for an architecture.

  14. Re:Another one? by Anonymous Coward · · Score: 0

    Did you say "goatse stay more competetive"?

    And you're damn right, considering the competetion that guy faces!

  15. Re:Another one? by EelBait · · Score: 2, Insightful

    POW!

    All the various BSDs share code when one solution seems to fit more than just the distribution that developed it. If DragonFly is going to focus on something that the other four aren't, then more power to them. I'm sure the others will adopt any good ideas that come out.

  16. Re:One BSD by SweetAndSourJesus · · Score: 1

    Define "best"

    I think the reason that there are different BSDs is that there is no "best" for everyone.

    There's no need for a unified BSD because the source to all of them is free for use with almost no restrictions, so every flavor of BSD can benefit from the others.

    --

    --
    the strongest word is still the word "free"
  17. MOD UP! LAME SLASHDOTTING JOKE! by Anonymous Coward · · Score: 0

    not funny but should trigger some moderator reflex.

  18. Does this mean.... by 222 · · Score: 0, Troll

    *BSD is still dying? :)

    1. Re:Does this mean.... by archen · · Score: 0, Troll

      I guess... I mean the bugs are circling now =P

    2. Re:Does this mean.... by 222 · · Score: 1

      It never fails to impress me how much the majorty of /. readers/moderators have absolutely no concept of sarcasm....:p

    3. Re:Does this mean.... by Anonymous Coward · · Score: 0

      What it really means is that BSD is fractured and dying.

  19. You're thinking of DeadBSD, which was a short-lived flavor.

    --

    --
    the strongest word is still the word "free"
  20. Re:I don't understand. by Anonymous Coward · · Score: 0

    Even Notepad is straining to keep up as I type this.

    You type your Slashdot posts in Notepad? How sick is that?

  21. Re:Another one? by ThePlague · · Score: 0

    That's the bitch part about freedom: people don't always do what you want them to do.

  22. PORTAGE! by MarcQuadra · · Score: 4, Insightful

    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!)

    --
    "Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
    1. Re:PORTAGE! by Anonymous Coward · · Score: 0

      Portage isn't as powerful as PORTS is. If you want to configure something yourself you have to do a lot of extra work, where as with Ports you just ./configure && make && make install...

    2. Re:PORTAGE! by Anonymous Coward · · Score: 0

      Have you tried FreeBSD ports? Its as easy as it gets. make ; make install as root for most things. The major feature of FreeBSD though is that ports and packages both register the same way, and that you don't have to completely rely on ports to install everything. You should try pkg_add -r packagename. automatically fetches the latest version of many programs and installs it.
      Portage is like coke 2. Its a crappy rip off of the original.

    3. Re:PORTAGE! by LionMage · · Score: 1
      I must agree with this, which might be a surprise to some BSD die-hards. Portage is mainly what wooed me to Gentoo over other distributions of Linux (even Sorceror).

      It would be really cool to see the power and simplicity of portage brought to the BSD world. This would have two beneficial effects:
      • Making BSD even easier to set up and install software for.
      • The BSD community would contribute back a lot of improvements and ideas to Portage, making Portage even better in the long run.


      I love BSD -- it's why I run Mac OS X primarily at home -- so don't misread me. But if someone's looking at a new package management system for BSD, Portage is a good choice IMHO.
    4. Re:PORTAGE! by Rhone · · Score: 1

      Hmm, I've only been using Gentoo a little under a couple months now, and it didn't take me long to figure out that editing the ./configure in ebuilds is fairly trivial (and putting your edited ebuild in /usr/local/portage/category/app will keep it from being overwritten by updates).

      That said, though, I don't see what the advantage of using portage in BSD would be. I used FreeBSD for a little while before coming back to Linux, and at least from an end-user perspective, I haven't really felt much of a difference between Portage and FreeBSD's ports system.

    5. Re:PORTAGE! by Anonymous Coward · · Score: 0

      So like...

      Where do you think Portage *comes* from? Ports, maybe? Hello? FreeBSD uses a system called ports. Gentoo is an imitation, that's why they named it portage .....................

    6. Re:PORTAGE! by axxackall · · Score: 1
      FreeBSD uses a system called ports. Gentoo is an imitation, that's why they named it portage

      Gentoo is not an imitation of BSD: it's a GNU userland with Portage as a package manager. Portage is also not an imitation of ports - Portage is a further development of good ideas of ports after leaving behind bad implementation details of ports. The major improveent of the ports' concept in Portage is fine-grained control of dependencies and system/application settings/configurations.

      --

      Less is more !
    7. Re:PORTAGE! by Billly+Gates · · Score: 2, 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?

    8. Re:PORTAGE! by Anonymous Coward · · Score: 0

      Why? Install "portupgrade" and be happy.

    9. Re:PORTAGE! by someonehasmyname · · Score: 1

      The major improveent of the ports' concept in Portage is fine-grained control of dependencies and system/application settings/configurations.

      What?! Portage blows away configuration files every chance it gets! FreeBSD's ports system never overwrites config files, etc.

      As far as dependencies are concerned, install portupgrade and then use pkgdb to fix any issues.

      --
      Common sense is not so common.
    10. Re:PORTAGE! by Simon+Kongshoj · · Score: 5, Funny

      That's it. I'm going to mail Daniel Robbins and ask him to make the next in his brilliant series of articles at IBM DeveloperWorks a "OS advocacy for overzealous Gentoo freaks" piece.

      The first and most important bit: Always bring up Gentoo whenever ANYONE mentions ANY other operating system! This is of UTMOST importance! Just like annoying potential customers works for Internet advertisers, annoying potential users must work for OS advocates!

      Longhorn would kick ass if they installed unwanted software using PORTAGE instead of Windows Update!!!!! PR0T4G3 R0XX0RZ J00R B0XX0RS!

      I'm going to be burned at the stake for this, but don't worry, my karma ensures that I'll be back as a lotus blossom to annoy all you bloody geeks with pollen.

      --
      Six sick .sigs, the Number of the Beast!
    11. Re:PORTAGE! by gentoo-is-the-suck · · Score: 1

      Yeah, but, but, but, it's so fast! I've administered many unix-like machines, and I am convinced that gentoo will never be ready for server use. It's got a targeted user-base.....the nineteen year-old kid with his ereet gaming machine. I honestly tried to give it a chance, but it is nothing compared to any of the BSD's. Oh well, you'll never convince them of that.

      --
      Get a real distro.
    12. Re:PORTAGE! by BigBir3d · · Score: 1

      I am sure Eugenia at OSnews could write it for you. Of course, she would evangelize BeOS instead...

    13. Re:PORTAGE! by Anonymous Coward · · Score: 0

      If you actually bothered to study the Portage code, you'll notice it's nowhere near as elegant as the user interface. Have a look through the gentoo mailing lists around the time 2.0 was being developed.

      Admittedly, as far as from-source package systems go, portage is great from a user perspective. Certainly has an edge over the Makefiles in ports.

    14. Re:PORTAGE! by evilviper · · Score: 1

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

      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    15. Re:PORTAGE! by AndyElf · · Score: 1

      drop the ./configure step -- just make && make install (and optionally && make clean to clean it up).

      or do it all in one sweep with portinstall collection/port

      --

      --AP
    16. Re:PORTAGE! by chainedtothemoon · · Score: 1
      FreeBSD ports are simple tcsh scripts..

      No. The ports system is controlled via makefiles in ports/Mk and the port in question.

    17. Re:PORTAGE! by hhw · · Score: 2, Funny

      Portage on BSD is about as necessary as another Linux distribution.

      --
      http://astutehosting.com/
    18. Re:PORTAGE! by __past__ · · Score: 1
      From an end-user perspective this may be true, but internally, the ports system is quite ugly (and FreeBSD's more so than the one in OpenBSD and NetBSD's pkgsrc).

      One of the biggest problems is that there is no standard way to handle options in port makefiles. As a user, you have to examine the makefile to look for the WITH_* variables used, or hope that the port will tell you before it starts to build - but there is nothing that would allow you to get a list of supported options programatically, which would be needed for a GUI, or for ports that depend on certain options being set in other ports.

      The whole thing being basically written in make(1) (I wonder if it is the biggest application of make ever, I wouldn't be surprised) doesn't exactly help either, because it makes introducing changes somewhat delicate. Of course, switching to another system is not realistic, nobody wants to rewrite 8000 ports. Even a small change like moving the one-line package description from it's own file into the main makefile took a lot of work.

    19. Re:PORTAGE! by MarcQuadra · · Score: 1

      Portage never blows away MY config files. do you have CONFIG_PROTECT="" exported? that's what makes portage blow config files away, it's part of the install process to export that, but after you reboot it shouldn't be an issue.

      --
      "Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
    20. Re:PORTAGE! by Strog · · Score: 1

      Or we could go the other way. Pkgsrc is what NetBSD uses and it is available on several platforms. It is platform independant and you can check out Work In Progress before it makes it into the main tree. They have BSD, Linux, Irix, Solaris and OS X (Darwin) so far. I've been playing with it on OS X and Irix lately and it's nice to have some consistency across platforms.

      Of course everyone has their own opinion but I'll stick with ports/pkgsrc for me. Perhaps there will be something I like more later but not right now.

    21. Re:PORTAGE! by phoenix_rizzen · · Score: 1

      They just removed perl from the base, and now you want them to add python??

      Yeah, that's going to happen Real Soon Now(tm).

    22. Re:PORTAGE! by MarcQuadra · · Score: 1

      It's a NEW distro, they can have whatever they need in the base. That's why distributions are forked, right?

      --
      "Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
    23. Re:PORTAGE! by Anonymous Coward · · Score: 0
      I really gotta chime in here. It really pisses me off that FreeBSD does not let you (by default)
      % cd /usr/ports
      % make update
      It tells you that you need to futz around and configure things. If I wanted to do that,
      I'd install stuff by hand. I just want to update my ports - I don't think that's too much to ask.

      Yes, I've submitted that as a bug. Yes, it was rejected.

    24. Re:PORTAGE! by Anonymous Coward · · Score: 0

      Could you possibly be any more delusional??!

    25. Re:PORTAGE! by melatonin · · Score: 1

      FreeBSD ports are simple tcsh scripts

      Isn't that an oxymoron?

      ::ducks::

      --
      Moderators should have to take a reading comprehension test.
    26. Re:PORTAGE! by LionMage · · Score: 1
      Portage blows away configuration files every chance it gets!

      This is absolutely untrue, and flamebait to boot.

      Portage's default behavior is to write updated config files to a dotfile which the user then has to either replace the corresponding config file with, or merge into the config file. There's even a script in Gentoo called etc-update to assist with this task.

      You can turn off the protection of config files, or change which directories are considered "protected." If you turn this behavior off, you do so at your own peril.
  23. Re:I don't understand. by Anonymous Coward · · Score: 0

    If I had mod points today I'd be half-tempted to give you a Funny point for spoofing Slashdot's most popular Mac troll. You need to avoid the Offtopic negatives, though, by at least sneaking a Dragonfly BSD reference in there somewhere...

  24. pkg could be a lot better by HiFire · · Score: 5, Insightful

    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.

    1. Re:pkg could be a lot better by kwerle · · Score: 0, Flamebait

      I gotta chime in here:
      It really pisses me off that FreeBSD does not let you (by default)
      cd /usr/ports
      make update

      It tells you that you need to futs around and configure things. If I wanted to do that, I'd install stuff by hand. I just want to update my ports - I don't think that's too much to ask.

      Yes, I've submitted that as a bug. Yes, it was rejected.

    2. Re:pkg could be a lot better by dinivin · · Score: 1, Flamebait


      Yeah, because cvsup is such a difficult thing to figure out.

      Dinivin

    3. Re:pkg could be a lot better by Electrum · · Score: 2, Informative

      It really pisses me off that FreeBSD does not let you (by default)
      cd /usr/ports
      make update


      Put this in /etc/make.conf:

      SUPHOST=cvsup.freebsd.org
      SUP_UPDATE=yes
      SUP=/us r/local/bin/cvsup
      SUPFLAGS=-g -L2
      SUPFILE=/usr/share/examples/cvsup/stable-supf ile
      PORTSSUPFILE=/usr/share/examples/cvsup/ports- supfi le

    4. Re:pkg could be a lot better by kwerle · · Score: 1

      Yeah, because cvsup is such a difficult thing to figure out.

      Every decent OS does a better job. Even some not so decent OS's do.

      If cvsup is so trivial, why do I have to figure it out? Isn't that what computers are for? Taking care of the trivial?

      The truth is that it is trivial, but it should be free. Instead it is another FreeBSD disappointment.

    5. Re:pkg could be a lot better by iiioxx · · Score: 5, Informative

      I gotta chime in here:
      It really pisses me off that FreeBSD does not let you (by default)
      cd /usr/ports
      make update

      I dunno, I think cvsup and portupgrade do the deed quite nicely.

      # cd /usr/ports/net/cvsup-without-gui
      # make install && make clean
      # cd /usr/ports/sysutils/portupgrade
      # make install && make clean

      # mkdir -p /usr/local/etc/cvsup/sup
      # cp /usr/share/examples/cvsup/refuse /usr/local/etc/cvsup/sup


      ... tweak /etc/make.conf ...

      CFLAGS= -O -pipe
      COPTFLAGS= -O -pipe
      NOPROFILE= true
      USA_RESIDENT= YES (if you are)


      ... create /usr/local/etc/cvsup/sup/supfile ...

      *default host=cvsup2.freebsd.org
      *default base=/usr/local/etc/cvsup
      *default release=cvs tag=RELENG_5_1 (or your version)
      *default delete use-rel-suffix
      *default compress
      src-all
      ports-all tag=.
      doc-all tag=.

      ... then update your src and ports ...
      # /usr/local/bin/cvsup -g -L 2 /usr/local/etc/cvsup/sup/supfile
      # /usr/local/bin/portupgrade -ra

      Granted, you have to build a supfile, and tweak your /etc/make.conf a little first... But those are minor things, and in the case of cvsup, there are loads of good examples provided in /usr/share/examples/cvsup.

    6. Re:pkg could be a lot better by dinivin · · Score: 1


      Believe me, no OS does a better at package management, and package upgrades, than FreeBSD.

      Dinivin

    7. Re:pkg could be a lot better by burns210 · · Score: 1

      WORST example EVER. 2 lines in gentoo(cd to the ports dir, and make update) compred to 20 freaking lines you posted where you have to edit a file, make a directory and other crap that i don't want, or should have, to do.

      Ports in freebsd are cool. But updating packages installed, and updating the whole system, are two very cool things i would like to see.

    8. Re:pkg could be a lot better by kwerle · · Score: 1

      THANK YOU.

      Finally someone that understands that I shouldn't have to work to make things easy. They should just be easy.

    9. Re:pkg could be a lot better by kwerle · · Score: 1

      Believe me, no OS does a better at package management, and package upgrades, than FreeBSD.

      Never mind that you're wrong.

      Never mind that I've used MUCH better (the package management system in Nextstep was fab).

      The point is that it SHOULD be easier to update it (ie no work).

    10. Re:pkg could be a lot better by Anonymous Coward · · Score: 0

      If they made it that easy for you to upgrade it, you'd just wind up complaining because it downloads all the chinese and korean ports.

      Look, make a two line shell script called update.sh that downloads the newest info for the ports you want. I run webservers so I drop the audio, biology, cad, chinese, etc. ports.

    11. Re:pkg could be a lot better by iiioxx · · Score: 1

      Finally someone that understands that I shouldn't have to work to make things easy. They should just be easy.

      So just buy a freakin' Mac already... With that kind of attitude, why are you even messing around with BSD (or Linux for that matter)?

    12. Re:pkg could be a lot better by Anonymous Coward · · Score: 0

      Ever tried making a linux kernel.
      Not nearly as easy as BSD's

      To each their own.

    13. Re:pkg could be a lot better by snak0rific · · Score: 1

      two lines? last i checked it was just "emerge sync"
      also the updating "world" and "system" along with --deep and --pretend opts are pretty kewl.

      --
      -- "Put on your big girl panties and lift!"
    14. Re:pkg could be a lot better by gentoo-is-the-suck · · Score: 1

      And then spend two days going through /etc finding all the ._cfg files it's spit out in the process. FreeBSD Ports, and pkgsrc both work better than portage.

      --
      Get a real distro.
    15. Re:pkg could be a lot better by Arandir · · Score: 1

      If cvsup is so trivial, why do I have to figure it out?

      Sigh. Hopefully this will get past the lameness filter:

      #!/bin/sh
      echo "Quick-N-Dirty script to update all your installed ports"
      echo "slurping down the new stuff..."
      cvsup /usr/share/examples/cvsup/ports-supfile
      echo "rebuilding the ports database..."
      portsdb -Uu
      echo "building all updated ports..."
      portupgrade --all
      echo "done!"

      --
      A Government Is a Body of People, Usually Notably Ungoverned
    16. Re:pkg could be a lot better by iiioxx · · Score: 4, Insightful

      WORST example EVER. 2 lines in gentoo(cd to the ports dir, and make update) compred to 20 freaking lines you posted where you have to edit a file, make a directory and other crap that i don't want, or should have, to do.

      I wasn't trying to show that FreeBSD ports was somehow *easier* than Portage (or anything else for that matter), simply that it was not very difficult at all, and it gets the job done nicely.

      Personally, I don't see the problem with doing a little configuration to make the system behave exactly as I want. To me, that's a feature, not a flaw. Not to mention the fact that the 20 or so lines of command and code you seem to have a problem with, is a one-time setup task. After that, the system is a two-command process, one command if I create a simple shell script, no command if I add a cron job to do it once a week. This is just like your two-command process, except for the fact that *I* have dictated the mechanics of the process, rather than allowing a distributor to decide those mechanics for me.

      Ports in freebsd are cool. But updating packages installed, and updating the whole system, are two very cool things i would like to see.

      All you have to do is look, it's all right there. CVSup will update your ports tree, your source tree, your docs, or a custom combination of all of the above. Portupgrade will update all of your ports with one command. As to updating the system, the system and the ports are kept separate *by design*. The system can be upgraded independently from the ports, and vice versa. Updating the system itself is as simple as a 'make buildworld', 'make kernel', 'make installworld', and reboot.

      I dunno. Maybe this is just an "old school vs. new school" issue. "Old school" UNIX users and sysadmins simply see this as a reasonable means to get things done. "New school" Linux users (a lot of whom are migrating from the Windows world) seem to be looking for the command-line equivalent of clicking a button to get everything done. No work, and no knowledge of the system itself and how it operates, required.

      I, for one, prefer the old school way.

    17. Re:pkg could be a lot better by EvilAlien · · Score: 1
      You better be browsing /. the oldschool way for the intellectual elite (i.e., lynx) or your credibility just went out the window.

      Gentoo designed their ports system to be elegant, not the constant fiddle and hackjob that FreeBSD boasts. Just because 20 lines of code to make ports updating work was good enough for grandpa doesn't mean you should accept it as an example of intelligent design today.

      --
      perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10)'
    18. Re:pkg could be a lot better by Kaladis+Nefarian · · Score: 1

      Your methods may work, but they certainly are not "nice". Have you _used_ Gentoo Portage?

      (And yes I was a FreeBSD user for about a year, and it was great :-) switched back to Linux because of the Nvidia driver situation back then (I NEED GAMES!), but now that drivers are available I might give it another try soon)

      --
      * Several monkeys are here, playing banjos and wearing small hats.
    19. Re:pkg could be a lot better by Anonymous Coward · · Score: 1, Informative

      Uhhh... etc-update manages those updates very nicely, and you can interactively merge the old and new files with relative ease.

    20. Re:pkg could be a lot better by kwerle · · Score: 1

      I type this from a Mac, but my server is an Athlon. Mostly because I've had it since before OSX, and it does the job.

    21. Re:pkg could be a lot better by kwerle · · Score: 1

      Yes. I have this (the equivalent) already.
      Why did I have to write it?
      Why did you have to write it?
      Why don't they just make it work?

      The point is not that it can't be done. It's not even that it's hard to do. The point is that it should ALREADY be done so that you and I don't have to do it again.

      That's what we mean by "could be a lot better." Really, the FreeBSD process could be a lot better for all users if they made this (and other) trivial fix(es).

    22. Re:pkg could be a lot better by Anonymous Coward · · Score: 0
      When we speak of death, we surely mean the death of BSD.

      Dying? You betcha BSD is dying.

    23. Re:pkg could be a lot better by Cyclometh · · Score: 1

      If you want everything to be easy and be led by the hand through it all, go get yourself a copy of Windows.

      If, on the other hand, you're actually willing to do a little bit of upfront work so your system can behave the way you want it to rather than the way MS thinks it should then do it yourself- it's not that hard to do.

      I really can't believe that anyone would complain about how FreeBSD's package system works. Fact is, it does, hands down, and it's not that hard to learn or configure.

    24. Re:pkg could be a lot better by Cyclometh · · Score: 2, Insightful

      Well said. The problem with "easy" and "elegant" is that it's a pretty short step to "unconfigurable" and "uncustomizable". FreeBSD's design assumes that *you* want to control how things happen, not some preconfigured process designed by somebody who had no idea what your needs were.

      If ease and elegance of updating the operating system were the main criteria for picking one, we'd all be running Windows. Can't get much easier than going to a website and doing it all with one mouse button and rebooting.

    25. Re:pkg could be a lot better by Wastl · · Score: 2, Interesting

      And if you add something like the following in /etc/make.conf, you also get "make update" in /usr/src. :-)

      SUP_UPDATE= yes
      SUP= /usr/local/bin/cvsup
      SUPFLAGS= -g -L 2
      SUPHOST= cvsup3.de.FreeBSD.org
      SUPFILE= /etc/cvsup/standard-supfile
      PORTSSUPFILE= /etc/cvsup/ports-supfile
      DOCSUPFILE= /etc/cvsup/doc-supfile
      Sebastian
    26. Re:pkg could be a lot better by Anonymous Coward · · Score: 0
      (And yes I was a FreeBSD user for about a year, and it was great :-) switched back to Linux because of the Nvidia driver situation back then (I NEED GAMES!), but now that drivers are available I might give it another try soon)

      Um. Install Windows and dual-boot?

    27. Re:pkg could be a lot better by chainedtothemoon · · Score: 2

      Send Patches.

    28. Re:pkg could be a lot better by chainedtothemoon · · Score: 1

      Send patches and stop complaining.

    29. Re:pkg could be a lot better by Anonymous Coward · · Score: 0
      new with nicely Uhhh... etc-update merge manages those updates
      relative very, and you can old interactively the and files ease.

      I have no idea what the hell you are talking about.

    30. Re:pkg could be a lot better by Anonymous Coward · · Score: 0
      It is official; Netcraft now confirms: *BSD is dying

      One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.

      You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.

      FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.

      Let's keep to the facts and look at the numbers.

      OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.

      Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.

      All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are infinitesimally dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.

      Fact: *BSD is dying

    31. Re:pkg could be a lot better by Anonymous Coward · · Score: 0

      Good point. Another reason why FreeBSD sucks scabby cocks.

    32. Re:pkg could be a lot better by hhw · · Score: 1

      It tells you that you need to futs around and configure things. If I wanted to do that, I'd install stuff by hand. I just want to update my ports - I don't think that's too much to ask.

      I say it is too much to ask. When it comes to FreeBSD, editing files by hand goes with the territory. Why should the developers waste their valuable time making something already mind-numbingly simple into a completely thoughtless task? That's not in line with the goals of the project nor should it be.

      --
      http://astutehosting.com/
    33. Re:pkg could be a lot better by Ragica · · Score: 1
      On FreeBSD there are two excellent ports... i rarely use "make" or pkg_* utils anymore. You need to install "portupgrade" and "porteasy". The former is everything needed to build and update ports (or packages). The latter, while it also has port building options, is mostly good for keeping your ports tree up to date selectively. With "porteasy" you don't need to maintain the entire ports tree, but only update the ports you are interested (their dependancies will be automatically updated too); or with a single command using a couple of switches update all your installed ports.

      See the man pages for details.

    34. Re:pkg could be a lot better by Kaladis+Nefarian · · Score: 1

      I do dual boot. With the linux/windows combination however, I only need to reboot half the time, since some games are available for it, or can be used with winex. Under FreeBSD (back then) this was not possible.. bar basic 2D games.

      --
      * Several monkeys are here, playing banjos and wearing small hats.
    35. Re:pkg could be a lot better by kwerle · · Score: 1

      Did. Rejected.

    36. Re:pkg could be a lot better by kwerle · · Score: 1

      Did. It was Rejected.

    37. Re:pkg could be a lot better by TheRaven64 · · Score: 1
      Ports in freebsd are cool. But updating packages installed, and updating the whole system, are two very cool things i would like to see.

      Creating the supfile is simply a case of copying /usr/share/examples/cvsup/ports-supfile and modifying it to point to a local mirror.

      Updating every port on your system is simple a case of running the following command:

      portupgrade -a
      I have a cron job which runs every night while I'm asleep syncing my copy of the ports tree using cvsup and running the portupgrade command. It is two lines long and it ensures that I have an up to date system when I wake up (although obviously you shouldn't do that for a mission critical box, since you should always check the new versions of ports for nasty surprises before you install them).

      Oh, and if you don't want to waste CPU cycles compiling everything, then you can just specify the `-P' switch for portinstall, which will use precompiled binary packages instead.

      As to updating your entire base system, (i.e. everything that isn't a port) it is a simple case of running cvsup with a different sup file (from the same location, modified again to point to your local mirror) and running:

      make world
      --
      I am TheRaven on Soylent News
    38. Re:pkg could be a lot better by iiioxx · · Score: 1

      Your methods may work, but they certainly are not "nice". Have you _used_ Gentoo Portage?

      Yep. Sure have. :^)

      (And yes I was a FreeBSD user for about a year, and it was great :-) switched back to Linux because of the Nvidia driver situation back then (I NEED GAMES!), but now that drivers are available I might give it another try soon)

      Well, I'm not a gamer by any stretch of the imagination. Every once in a while I might get the itch to play a game or two, and for that I have a PS2 and a MAME box.

    39. Re:pkg could be a lot better by phoenix_rizzen · · Score: 1

      And the reason they were rejected was???? Did you try to convince them otherwise, or just wander off in a huff?

      What's the PR number?

    40. Re:pkg could be a lot better by kwerle · · Score: 1

      Did you try to convince them otherwise, or just wander off in a huff?

      I'd say I pushed the case.

      Funny, I seem to recall more email than is in the log. I also don't remember getting the last message, which shows a patch - though I don't see where it's been rolled.

      http://www.freebsd.org/cgi/query-pr.cgi?pr=45613

      It would really be great if they rolled it.

    41. Re:pkg could be a lot better by Arandir · · Score: 2, Informative

      There are a few reasons why this isn't done by default. First, portupgrade is not a part of the base system. Second, due to a chronic lack of space, there is not -STABLE ports tree, so automatically updating your ports could result in a broken system. Three, one size never fits all.

      Fourth, you need to understand the UNIX philosophy. In a nutshell it is "many small tools that do only one thing, but do them well." cvsup is a small tool that does one thing well. portupgrade is a small tool that does one thing well. Making either of them do the job of the other is not right.

      It took me three minutes to write the aforementioned script. Maybe FreeBSD could have saved everyone three minutes by including a similar script as a weekly cron job. But that ignores the fact that different users will want to use different cvsup servers, and that the servers will want people accessing them at different times. Imagine what the various goverment security agencies around the world would think if they saw a massive bandwidth usage spike every Monday at 2300 GMT!

      And of course, some people won't want to update everything. Some people won't want to update anything at all (don't fix it if it ain't broken). Then you have those people who can't use cvsup (like I can't at work because of a firewall)

      --
      A Government Is a Body of People, Usually Notably Ungoverned
    42. Re:pkg could be a lot better by kwerle · · Score: 1

      [many things that make sense]

      Here's the deal:
      cd /usr/ports
      make update

      should work. I don't care about cvsup. I don't care about portupgrade. I don't think an automatic cron job is the right thing to do. I don't care if it prompts me for which server it should hit the first time around. I don't care if it asks me which packages I want updated.

      cd /usr/ports/whatever
      make update

      should also work. I don't care about users who have specific needs that differ from the norm. I don't care about users who have firewall issues. I don't care about users who are off the 'net. For the 90% case, it should do the right thing. The rest can deal.

      Instead we have 90% having to do the work that should have been done for them. The other 10% have to do the work anyway, so who cares?

    43. Re:pkg could be a lot better by Anonymous Coward · · Score: 0

      *BSD is teh tréy ghey.

    44. Re:pkg could be a lot better by Astastrafal · · Score: 1

      It isn't about "old school" or "new school". It's about having a system that's prepared for the _common_ and _expected_ tasks that a user might want to do and right out the box is prepared to do them without much fuss. It is totally expected that at some point one would want to update the whole ports tree. Being able to treat the ports tree itself as a mere package would tend to indicate that the designers of the ports system have thought the whole problem through, and are applying the standard program-installation infrastructure that they themselves built to itself. It's a mark of a well thought-out system. Kind of like "everything is a file" in Plan9. Contrast that with Unix, where the idea is taken only so far and then you get a totally different namespace for network stuff. Jarring and inelegant. Same stuff here: You use ports for most every app, but not the ports tree itself (and also not the base system).

      The best course of action when designing an app is to make the common tasks simple (ideally no further configuration needed), but give enough power and flexibility so that the uncommon ones too are possible (I'm not a fan of denying power to users).

    45. Re:pkg could be a lot better by dinivin · · Score: 1

      And where did you get this mysterious 90% number from?

      Dinivin

    46. Re:pkg could be a lot better by Anonymous Coward · · Score: 0


      Old school, whelp, is favoring a better way of doing things, not a harder way.

      You may be old, but you obviously need schooling.

    47. Re:pkg could be a lot better by Kaladis+Nefarian · · Score: 1

      > Yep. Sure have. :^)

      Congrats. This answer however says nothing but "yes I have used it". And I'm really not interested in your gaming habits.

      --
      * Several monkeys are here, playing banjos and wearing small hats.
    48. Re:pkg could be a lot better by Kaladis+Nefarian · · Score: 1

      What are you comparing against? Because Gentoo is at least as configurable as FreeBSD. Have you used both?

      --
      * Several monkeys are here, playing banjos and wearing small hats.
    49. Re:pkg could be a lot better by Anonymous Coward · · Score: 0

      Use portupgrade.

      And remember that gentoo comes with the stinky GPLed kernel and related unstable filesystems.

    50. Re:pkg could be a lot better by kwerle · · Score: 1

      And where did you get this mysterious 90% number from?

      I pulled it out of my ass.

      Here is the important bit:

      cd /usr/ports
      make update

      should work.

    51. Re:pkg could be a lot better by iiioxx · · Score: 1

      Congrats. This answer however says nothing but "yes I have used it".

      You asked if I have used Portage. I answered your question. Perhaps from the brevity of my response you should have inferred my level of enthusiasm about it...

      And I'm really not interested in your gaming habits.

      Then why did you tell me about your own...?

      From your previous post:
      switched back to Linux because of the Nvidia driver situation back then (I NEED GAMES!)

    52. Re:pkg could be a lot better by Kaladis+Nefarian · · Score: 0
      You asked if I have used Portage. I answered your question. Perhaps from the brevity of my response you should have inferred my level of enthusiasm about it...

      Enthusiasm isn't the issue here. You detailed a long way to do something which Gentoo does with great ease, which you claimed to be "quite nice" ("I dunno, I think cvsup and portupgrade do the deed quite nicely.").

      Then why did you tell me about your own...?

      Well if you don't take it out of context:
      (And yes I was a FreeBSD user for about a year, and it was great :-) switched back to Linux because of the Nvidia driver situation back then (I NEED GAMES!), but now that drivers are available I might give it another try soon)

      I (obviously) did not want to seem like a hypocrite.
      --
      * Several monkeys are here, playing banjos and wearing small hats.
    53. Re:pkg could be a lot better by Anonymous Coward · · Score: 0

      "This is just like your two-command process, except for the fact that *I* have dictated the mechanics of the process, rather than allowing a distributor to decide those mechanics for me."

      And I'll wager that the majority of computer users today would rather have those mechanics dictated to them, as opposed to dicking around with configuration files.

      Of course, this is why we have forks and distributions and so forth - you get a system where you can fiddle around in configuration for hours, others get a system that's ready to go for what they need to do, out of the box.

    54. Re:pkg could be a lot better by iiioxx · · Score: 1

      Enthusiasm isn't the issue here. You detailed a long way to do something which Gentoo does with great ease, which you claimed to be "quite nice" .

      In case you hadn't noticed the red trim, this subject was regarding BSD. Not to mention that you seem familiar enough with Portage. Why would I need to go into some deep explanation of its mechanics? Are you looking for me to try to "prove" something? What exactly would be the point? :^)

      Well if you don't take it out of context:

      I (obviously) did not want to seem like a hypocrite.


      I think you're taking this all a little too personally. :^)

      Here's the way I see things:

      Linux distributions have a tendency to do things in very distribution-specific ways, and tend to be rather inflexible in that regard. This is probably why there are so many Linux distributions. Every time someone wants to do things in a different way, they break the system, and up pops a new distribution. I feel reasonably assured in making this statement, as I have used Linux personally and professionally since 1995 and ran quite a number of different Linux distros (including Gentoo). I have seen the Linux distributions become more numerous, more convoluted, and more incompatible with each passing year (and I don't see this trend reversing itself anytime soon).

      This is probably why there are relatively few BSD distributions. The BSDs tend to provide the core OS, and the tools to make things the way you want them to be, and that's it. The goal is to keep the system out of the admin's way. There is usually no need to fork the system, because the system is flexible enough to accomodate the needs and preferences of different admins. The system can be readily modified without breaking the fundamental mechanics.

      So maybe you could understand why someone might prefer a system that requires a few additional steps to get rolling, if it means having a very personalized system. I still say it boils down to experience and background. Making 20-odd lines of commands is no big deal to me. It takes all of two minutes for me to set things up, because I'm familiar with the system. For someone unfamiliar with the system, it might seem like an awful lot to do, and a lot to know (or figure out). For that person, the single-command system is probably going to be a lot more attractive (it would be 20 times easier to learn).

      But I don't think you can say that Portage is "better" simply because it requires less command syntax. It's really a matter of "does it do what I need it to do, with an amount of effort that seems reasonable to me". If it saves me labor, but doesn't accomplish what I need it to do, it isn't "better" for me. By that metric, it's reasonable to see how Portage might be better for you, and ports might be better for me.

    55. Re:pkg could be a lot better by iiioxx · · Score: 1

      It's about having a system that's prepared for the _common_ and _expected_ tasks that a user might want to do and right out the box is prepared to do them without much fuss.

      But this is where things get problematic. Whenever a developer tries to anticipate what the user expects and write around those expectations, they naturally have to impose some restraints upon the system. And the real problem is this: different users expect different things. Pretty soon, those restraints start getting in the way.

      Being able to treat the ports tree itself as a mere package would tend to indicate that the designers of the ports system have thought the whole problem through, and are applying the standard program-installation infrastructure that they themselves built to itself. It's a mark of a well thought-out system.

      On the contrary, I think such a concept shows a lack of vision. There are over 8000 applications in the ports tree. Is it reasonable to assume that every admin, on every machine, would want to track every port? Rather, the ports system is designed so that the admin can decide to track a specific group of applications on a specific machine.

      You use ports for most every app, but not the ports tree itself (and also not the base system).

      I think you're missing the elegance of the system, and the beauty of the design. Ports are applications that are outside of the core, maintained OS. I can upgrade any port or combination of ports without worrying about dependency issues with the core system. I can upgrade the core system without worrying about breaking the ports. I can selectively synch specific parts of the ports or source trees. It is very flexible, but because of that flexibility there isn't a one-size-fits-all way of doing things (which is why cvsup comes with a collection of sample supfiles).

      The best course of action when designing an app is to make the common tasks simple (ideally no further configuration needed), but give enough power and flexibility so that the uncommon ones too are possible (I'm not a fan of denying power to users).

      Well, when you figure that one out, you should patent it.

    56. Re:pkg could be a lot better by Astastrafal · · Score: 1

      But this is where things get problematic. Whenever a developer tries to anticipate what the user expects and write around those expectations, they naturally have to impose some restraints upon the system. And the real problem is this: different users expect different things. Pretty soon, those restraints start getting in the way.

      Different users expect different things, that's true. But there are always a set of common expectations associated with every application type that exists. If I download a mail client, I expect to be able to read and respond to my mail with it. If I download what purports to be a word processor, I expect to manage to type a letter with it. And so on. What an app designer should do is to make those very basic and very easily anticipatable tasks easy and convenient to perform. Doing so will never complicate matters at all. What should _not_ be done is to try to anticipate every possible combination of actions that a user might want to perform and place a button on the toolbar for it or a menu entry or a command or whatnot. Now _that_ would complicate things and the restraints you are talking about would start to be felt.

      Furthermore, if one creates an asbtraction or a model for performing a particular task, it is only good design to create it so that there are no arbitrary limitations imposed, and that one does not break the abstraction unnecessarily. Hence what I was saying: the ports tree is a mechanism for program installation. Not being able to treat the ports tree itself as an app to be updated, with an adjustable level of granularity if needed (for example being able to update a subtree), is a break with the abstraction created that only serves to highlight the shortsightedness of its creators. (In fairness, the original idea itself is cool and I was delighted when I first used it to see it in action. Its only that the people who did it didn't think ahead far enough). Another break with the abstraction is that ports is used only for a particular category of apps.

      On the contrary, I think such a concept shows a lack of vision. There are over 8000 applications in the ports tree. Is it reasonable to assume that every admin, on every machine, would want to track every port?

      Please. Have I ever talked about always tracking every port that's out there? What I'm saying is you should be able to cd into any subdirectory, or the root ports-directory, and update that.

      Rather, the ports system is designed so that the admin can decide to track a specific group of applications on a specific machine.

      Designed? It's all done by exchannel means, bringing in other apps and methods that's foreign to the ports concept. For God's sake.

      I think you're missing the elegance of the system, and the beauty of the design.

      The ports system _is_ elegant and beautiful, only I'm saying it could have been more so.

      Ports are applications that are outside of the core, maintained OS. I can upgrade any port or combination of ports without worrying about dependency issues with the core system. I can upgrade the core system without worrying about breaking the ports.

      Hmmm. Apps in the ports tree depend on the core. They depend on things like the libc and the kernel. Isn't there the possiblility that updating these could break apps built from ports?

      Regardless, that's tangential to what I'm talking about. I'm saying that a very nice program-installation mechanism was built. It could have trivially been extended to cover much more, like Debian and Gentoo have done. Instead it was unnecessarily limited in its scope.

      I can selectively synch specific parts of the ports or source trees. It is very flexible, but because of that flexibility there isn't a one-size-fits-all way of doing things (which is why cvsup comes with a collection of sample supfiles).

      What I'm proposing is as at least as flexible, and the major advantage is that it doesn't break with the standard way of

    57. Re:pkg could be a lot better by Kaladis+Nefarian · · Score: 0

      So what does does the ports collection do that Portage doesn't?

      --
      * Several monkeys are here, playing banjos and wearing small hats.
    58. Re:pkg could be a lot better by iiioxx · · Score: 1

      So what does does the ports collection do that Portage doesn't?

      I dunno, work on FreeBSD? :^)

    59. Re:pkg could be a lot better by cozman69 · · Score: 1

      Hmmm. Apps in the ports tree depend on the core. They depend on things like the libc and the kernel. Isn't there the possiblility that updating these could break apps built from ports?

      Nope. FreeBSD has several compatability libraries (compat3x, compat4x, etc) so if you do indeed upgrade your kernel and userland from let's say FreeBSD 4.8 to 5.1, your ports will work just as they had before, because they'll be using the compat4x libraries.

      Ports are totally separated from the core, by design.

    60. Re:pkg could be a lot better by yerricde · · Score: 1

      If ease and elegance of updating the operating system were the main criteria for picking one, we'd all be running Windows.

      Wrong answer, I believe. Under these conditions, we'd all be running Mac OS X.

      --
      Will I retire or break 10K?
  25. Re:BSD? More like LSD by Anonymous Coward · · Score: 0

    you were using the kludge known as X dumbass.
    Need a hit of Xtacy?

  26. New Packaging System by kevin_conaway · · Score: 2, Interesting

    Are they talking about replacing the ports system? I thought that that was one of those most revered parts of the original FreeBSD

    1. Re:New Packaging System by dododge · · Score: 5, Informative
      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.

    2. Re:New Packaging System by cpeterso · · Score: 1


      you mean like VMS? I think the VMS filesystem did file versioning similar to this.

    3. Re:New Packaging System by user32.ExitWindowsEx · · Score: 1

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

      Didn't .NET Assemblies promise something like this?

      --
      "Evil will always triumph because good is dumb." -- Dark Helmet
    4. Re:New Packaging System by drinkypoo · · Score: 1
      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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    5. Re:New Packaging System by dododge · · Score: 1
      I think the VMS filesystem did file versioning similar to this.

      I don't really know enough about the workings of VMS to say for sure. I think the VMS approach works on an individual file basis. I suspect that the versioning in the case of DragonFlyBSD will need to group files together into packages. Packages will have their dependencies explicitly stated somehow; for example the DragonFly writeup refers to the idea of a cron job that automatically cleans up unneeded packages after an upgrade.

      So for example, you have libfoo 1.3.2 installed already, and you see that 1.3.3 is available. You should be able to install the newer version and all related files (such as gettext strings) as a single entity. Programs using 1.3.2 will see no change at all; they still get the old code when they link with "/usr/local/lib/libfoo.*". They can't even see that 1.3.3 is there. You would then be able to switch those applications over to 1.3.3 for testing, one at a time, by telling the operating system to make 1.3.3 visible to them. Again, all related files that came with libfoo 1.3.2 or 1.3.3 have their visibility affected by this one change. The application still links with the same libfoo.* file, using the same full path, but gets the newer code transparently. When all applications that used 1.3.2 have been migrated to the new version and tested successfully, the old package can be removed safely (and the system will know this because it knows all of the active dependencies explicitly).

      The really nice thing here is that you can use this to upgrade some massive multi-package thing like Gnome, where there are a zillion sublibraries and packages with dependencies on each other. They can be installed right on top of the older versions, with all of their new dependencies intact, with no effect on installed applications that are using the old libs. And you can take your time doing it, since the old libs are never clobbered and the system remains stable.

      When compiling, you should be able to specify which set of libraries you want visible. So for example I wouldn't have to worry about some configure script scrounging through my machine and finding libraries that I don't want it to know about. On my current system, I might have all sorts of things installed for testing purposes, or that I'm planning to get rid of, and they might be in my default library path because right now that's the only convenient way for other applications to find them. Then I forget to strip those paths down to the bare mininum and find that something I just compiled has an unwanted dependency or linkage to one of those libs.

      Of course there are all sorts of subtle issues with implementing something like this on Linux. For example ld.so.cache isn't necessarily even a valid concept any more.

    6. Re:New Packaging System by Anonymous Coward · · Score: 0

      Trying to decide on a new packaging system for BSD. It will either be a coffin or a casket.

    7. Re:New Packaging System by Anonymous Coward · · Score: 0

      Correct me if I'm wrong, but I believe the Mac OS X frameworks mechanism does the same thing (multiple versions of the same dylib). Applications link at runtime to the same version they were built against, even though a newer or older version of the library may be installed.

    8. Re:New Packaging System by dododge · · Score: 2, Informative
      Correct me if I'm wrong, but I believe the Mac OS X frameworks mechanism does the same thing (multiple versions of the same dylib). Applications link at runtime to the same version they were built against, even though a newer or older version of the library may be installed.

      Yes, frameworks do something similar. But the design requires toolchains, runtime linking, and the libraries themselves to understand frameworks. So do you modify the applications and libraries to understand a new way of working, or modify the system so that the new way looks (to userspace code) just like the old way? Apple can take the former, arguably better route, because they control the system and can force everybody to play along. Linux on the other hand has this huge installed base that isn't going to budge until the new way becomes the common way. I have in the past done things like modify an application (and all of the libraries it depends on) to be relocatable and take a runtime prefix from an environment variable -- but that gets painful very quickly, and maintaining it is almost out of the question.

      Frameworks have the concept of a globally "current" library version, which takes precedence all the time. In the DragonFly approach (or at least in my similar dream design :-) all installed versions of a library have equal standing. The "current" version in my case is whatever version you want to be current at the moment, in the context of that specific running process.

      Frameworks also seem to have a requirement for forward compatibility in minor versions of libraries. If you link your application against version 1.3.x of a library, and you install 1.4.x on the system, the next time you run the application it will get linked against 1.4.x, unconditionally. At least that's what Apple's docs seem to say. This puts the burden on software authors to maintain this sort of compatibility guarantee. Frankly I don't trust Linux library authors that much, especially since they don't have anyone forcing it on them. I want a chance to test some older applications against 1.4.x, and I want the option of having those applications stay with 1.3.x if there turns out to be problems, even while 1.4.x is installed for other, newer applications and libraries to use.

    9. Re:New Packaging System by Anonymous Coward · · Score: 0
      Dear Apple,

      I am a homosexual. I bought an Apple computer because of its well earned reputation for being "the" gay computer. Since I have become an Apple owner, I have been exposed to a whole new world of gay friends. It is really a pleasure to meet and compute with other homos such as myself. I plan on using my new Apple computer as a way to entice and recruit young schoolboys into the homosexual lifestyle; it would be so helpful if you could produce more software which would appeal to young boys. Thanks in advance.

      with much gayness,

      Father Randy "Pudge" O'Day, S.J.

    10. Re:New Packaging System by Anonymous Coward · · Score: 0
      I have got to chime in here. It really pisses me off that FreeBSD does not let you (by default)
      % cd /usr/ports
      % make update
      It tells you that you need to futz around and configure things. If I wanted to do that,
      I'd install stuff by hand. I just want to update my ports - I don't think that's too much to ask.

      Yes, I've submitted that as a bug. Yes, it was rejected.

    11. Re:New Packaging System by Anonymous Coward · · Score: 0

      What's the advantage compared to the current system where the library files have the version in their name, and the dynamic loader chooses the version most appropriate to the program? You know, with the right linker flags the programmer can even specify if they want the same exact version, or only a compatible one (ie the same major version, and the same or later minor version).

    12. Re:New Packaging System by Anonymous Coward · · Score: 0

      You can pretty much do this with current systems. If you have libfoo installed, and you have

      /usr/lib/libfoo.so.0
      /usr/lib/libfoo.so -> libfoo.so.0


      Then at compile time, the linker will see -lfoo, follow the symlink for libfoo.so to libfoo.so.0 and link your code against libfoo.so.0 If you then install the newer libfoo.so.1, you would then have

      /usr/lib/libfoo.so.0
      /usr/lib/libfoo.so.1
      /usr/lib/libfoo.so -> libfoo.so.1


      New code gets to link against libfoo.so.1, and old binaries are not a problem because they are linked to libfoo.so.0, not libfoo.so

      The only part that this does not "solve" is that you can transition older binaries from libfoo.so.0 to libfoo.so.1 one at a time. They would either require a recompile, or you could attempt to change all of them by symlinking the old libfoo.so.0 to libfoo.so.1

      I guess this may not work on all systems as it depends on the linker understanding & following the symlink for libfoo.so, but there you go, time to get a new toolchain!

    13. Re:New Packaging System by louferd · · Score: 1

      Wow. That'll make rootkits ten times harder to detect. I'm not sure that's the best way to solve whatever the supposed problem is.

    14. Re:New Packaging System by stripes · · Score: 1
      you mean like VMS? I think the VMS filesystem did file versioning similar to this.

      Nope, VMS did file versioning, and you could look at old versions of VMS files (as long as nobody deleted the "backups"), and it was useful. But that isn't what this is.

      What is proposed for Dragonfly is when your application looks at /usr/local/lib it sees the libs it's package defined and no other files in /usr/local/lib.

      VMS had one "file name space", Dragonfly has one per package (or at least might have a new one for any given package).

      I'm not sure how this will interact with things like wanting to build a new program when there are multiple versions of GNOME installed with different versions of libgtk and diffrent include files. I guess you will "somehow" have to tell gcc (or the make that runs it, or the shell that runs the make that runs gcc) what file name space you want.

      I'm also not so sure how that will inteact with other parts of the system that want to see everything, liek say tar or whatever you use for backups. I understand how they could see libfoo.so.4.7 and libfoo.so.4.8 in one directory, but I'm unclear on how it would see /usr/local/include/foo.h when there are two foo.h files there. Maybe the package system will insist they are installed in different places in the "real file name space" and just map them into the "same place" in the file name space for packages.

      Anyway don't think "VMS Backups", think "Plan 9's per-process mountable filesystems" (I think also invented - or at least used - in BSD/OS for SCO compatability, and later in FreeBSD as part of the Linux compatability)

    15. Re:New Packaging System by stripes · · Score: 1
      What's the advantage compared to the current system where the library files have the version in their name, and the dynamic loader chooses the version most appropriate to the program? You know, with the right linker flags the programmer can even specify if they want the same exact version, or only a compatible one (ie the same major version, and the same or later minor version).

      It would (I assume!) apply to files other then just library files. You know config files, executbles used by shell scripts, desktop theme sets, jpeg files, header files.

      Also (from the site's text) since the dependency info is encoded somewhere the kernel can spot it something like a cron job can tell you which files are not used by any packages (I assume this would only be used for directories like /usr/local/lib, not people's home directories).

    16. Re:New Packaging System by dododge · · Score: 1
      New code gets to link against libfoo.so.1

      What if I don't want the newest version to be used?

      Which version of the library do the system header files match?

      And how do you handle the case where two minor versions of a library produce the same libfoo.so.* file?

      A basic problem here is the whole concept of a globally current version, especially since the system will normally assume the most recent version is the one you want. What if I've installed some prerelease or development version for testing? I don't want all of my applications automatically picking that up just because the system assumes it's ABI-compatible.

    17. Re:New Packaging System by dododge · · Score: 1
      I guess you will "somehow" have to tell gcc (or the make that runs it, or the shell that runs the make that runs gcc) what file name space you want.

      I'm very interested in seeing how DragonFly handles the administrative part of this. If this packaging system can be implemented in Linux it'd be nice to have the same commands/tools on both operating systems.

      Maybe the package system will insist they are installed in different places in the "real file name space" and just map them into the "same place" in the file name space for packages.

      That was my thinking about how it could be handled if implemented for Linux. The writeup for DragonFly suggests the idea of embedding a version suffix into file and/or directory names, which would be hidden when viewing them through the packaging layer.

    18. Re:New Packaging System by Istealmymusic · · Score: 1
      This project definitely looks interesting, but why do I need to have multiple versions of libraries installed simultaneously on a server?

      It just doesn't seem too useful. Couldn't I upgrade to newer versions of the programs that use each library, instead? Or better yet, couldn't library others NOT break backwards-compatibility?

      --
      "The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
    19. Re:New Packaging System by dododge · · Score: 1
      why do I need to have multiple versions of libraries installed simultaneously on a server?

      On a server? Perhaps not. Most of my interest in this comes from dealing with my workstation configuration. Such as wanting to try out some new application or library version on a whim without potentially breaking anything else on the machine. Since I build from source 99.44% of the time I currently make a new install prefix and put everything (all dependencies except maybe libc and libz) there; but that means that if I have four different things using some unstable or new version of libfoo I might end up with four copies of the same version of libfoo lying around for different reasons.

      Couldn't I upgrade to newer versions of the programs that use each library, instead?

      If they exist. And I don't want the old version of the program clobbered until I'm sure that the new one is stable and doesn't have some new misfeature.

      couldn't library others NOT break backwards-compatibility?

      There's no infrastructure policy such as Apple's that forces it. Library and application writers could maintain compatibility, but that doesn't mean that they always do. I prefer the system to defend itself so that I don't have to worry about whether they do or not.

      And remember that this isn't just a matter of single libraries. One of the main reasons DragonFly appears to be looking at this is to handle large updates where many pieces and packages have to be replaced. For example just to update gtk2 you're looking at a large number of libraries from different development trees (pango, freetype, pkgconf, etc). As you do the upgrade and the new minor versions clobber the old ones one by one, you have lots of intermediate stages where the dependencies on your system are broken and libraries might actively mismatch.

  27. PORTAGE! by MarcQuadra · · Score: 1, Interesting

    I'm crossing my fingers that this comes out with Portage as the package manager...

    --
    "Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
  28. Re:wheres teh by vergil · · Score: 1
    Ask randy. He'll prob. post it on the mirrors anon ftp server.

    -V

  29. BSD Women by Anonymous Coward · · Score: 0

    How many women will dress up like a dragonfly?! C'mon!

  30. Won't use it by YetAnotherName · · Score: 0, Offtopic

    The name's too long. DragonFlyBSD? Come on! I'm not even sure where to capitalize the letters! It's bad enough the "OpenBSD" is as long as "FreeBSD", but spoken it's an extra syllable. I'll stick with NetBSD. Yeah. Nice and short!

    1. Re:Won't use it by Valdrax · · Score: 1

      Ah, but the name's catchy. "Dragonfly BSD" just sounds so cool. However, the real legacy of this fork will come when the highly demanding porn industry gets a hold of its advanced SMP features and adds a few tweaks of its own to get "Spanish Fly BSD."

      --
      If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
    2. Re:Won't use it by usotsuki · · Score: 1

      I might consider my own distro. :) PL-BSD (Pathologic BSD).

      Is it possible to cross-compile a BSD kernel from {DJGPP, MinGW32, Cygwin, Linux} ?

      Is there a non-GNU ANSI compiler with a BSD license?

      -uso.

      --
      Dreams, dreams, don't doubt dreams, dreaming children's dreaming dreams. Sailor Moon SS
    3. Re:Won't use it by salimma · · Score: 1

      Well, it's already being used - there's a Palm OS game, Space Trader, where one of the mission is destroying the renegade experimental craft 'DragonFly' armed with lightning shields :)

      --
      Michel
      Fedora Project Contribut
    4. Re:Won't use it by tigga · · Score: 1
      Is there a non-GNU ANSI compiler with a BSD license?

      TenDRA
      http://www.tendra.org/

    5. Re:Won't use it by __past__ · · Score: 1

      Do non-alphanumeric characters count? Otherwise you might be happier with BSD/OS, even if it's not free.

    6. Re:Won't use it by Anonymous Coward · · Score: 0

      If any OS is dead, it is BSD/OS. It is deader than a homo AIDS rotted corpse.

    7. Re:Won't use it by Anonymous Coward · · Score: 0

      Not only is that cool in the sense that the original parts are under Crown Copyright (As in, Copyrighted by the United Kingdom Monarchy), it is also slightly scary in that one of the developers apparently uses the CVS username "nonce", and they should probably know better..

  31. What a great name idea! by jednet · · Score: 3, Funny

    What were they thinking when they named their project after a bug?

    1. Re:What a great name idea! by iworm · · Score: 1

      This may be a lame joke, but it's NOT Offtopic, idiot moderator.

    2. Re:What a great name idea! by satterth · · Score: 1
      What were they thinking when they named their project after a bug?
      Exactly the samething Microsoft was doing.

      Windows:

      Something for bugs to hit and stick to

      --
      Being called a dork on Slashdot must be like being called the retard in special ed.
    3. Re:What a great name idea! by SteelRat · · Score: 1

      actually dragonflies eat a lot of bugs for their bodymass.

      it would be like standard geek eating two times their own bodyweight in mountain dew.. while mashing 2 liter bottles to bits with their powerful mandibles..

      okay.. maybe it's not the best analogy, but I'm sticking with it.

    4. Re:What a great name idea! by Anonymous Coward · · Score: 0

      Well, dragonflys are one of the coolest bugs around... and they can be pretty scary if you've never seen one before. They are also one of the oldest species that has survived pretty much unchanged for tens of millions of years.

    5. Re:What a great name idea! by overbom · · Score: 1

      > What were they thinking when they named their project after a bug?

      they were probably thinking about how Dragonflies eat other bugs.

  32. Flogging a dead horse. by Anonymous Coward · · Score: 0

    Dead, I tell ya.

  33. You know your tired... by rf0 · · Score: 0, Offtopic

    when your read goals as goats

    Rus

    1. Re:You know your tired... by Anonymous Coward · · Score: 0
      What does this have to do with the imminent death of *BSD?

      When you think about it, *BSD has been more or less officially
      dead since Walnut Creek CD Rom went out of business.

    2. Re:You know your tired... by Anonymous Coward · · Score: 0

      Bury this dead BSD bitch. That cunt is dead.

  34. Re:just what this planet needs ... by cant_get_a_good_nick · · Score: 4, Informative

    Oh well, it's probably about hurt egos again. :(

    In a way it is. Matt Dillon got lost commit access to cvs a while ago because he was trying to get some stuff into 4.8 and got rebuffed. Looked like he violated their code of conduct a few too many times, got kicked out, and started a project where he made the rules. TdR in the house?

  35. BSD and Smart People by mslinux · · Score: 3, Interesting

    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.

    1. Re:BSD and Smart People by Anonymous Coward · · Score: 2, Insightful

      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 huge changes, as in FreeBSD, and tacking/forking things around in the kernel(s) themselves to support every piece of hardware possible, as with NetBSD.

      Look at it this way, if you locked Gates and Torvalds in a room for 10 years, would the result be as good as either current product is?

      So anyhow, we've got a "RedHat" - FreeBSD; we've got a "Debian" of sorts - NetBSD; and we've got OpenBSD, which has no obvious peer anywhere else. (Sure, Theo's gang shoots the food now and then - I got a bit tired around the OpenSSH holes, as did everyone - but as a research beast that craps running, user-ready software, they're doing great.) Now we've got DragonFly, which could really be the 'BSD for the desktop.'

      Darwin doesn't really count -- it runs, a lot of hackers enjoy it because they enjoy helping Apple, but without the Cocoa and Quartz APIs, you're left with little but a crippled research OS. OS X itself is only Free if you're purchasing Apple hardware.

    2. Re:BSD and Smart People by Anonymous Coward · · Score: 0

      Absolutely

  36. Re:BSD? More like LSD by Anonymous Coward · · Score: 0

    Same troll as you used on an SGI bash a few days ago - this is the post you made, and this was the thread.

  37. there's something about BSD by Anonymous Coward · · Score: 0

    In other news, Ben Stiller has started his own fork of the FreeBSD tree called "Angelfish" which competes directly with DragonFly. Apparently, the fight is really about who should be maintainer of FreeBSD itself...

    1. Re:there's something about BSD by Anonymous Coward · · Score: 0

      There's something about BSD. Yep. It's dying.

  38. Re:Dragonfly BSD, life expectancy? by Gogo+Dodo · · Score: 2, Funny

    Dragonflies live longer than 24 hours. See the British Dragonfly Society FAQ.

  39. Why 4.x? by Anonymous Coward · · Score: 0

    Just when FreeBSD got great (the 5.1 distro is the best ever - well worth using on the desktop) - they go and base a new distro off the (relatively) clunky 4.8.

    WTF? I don't understand the logic. FreeBSD 5 has superior performance, more features and better hardware support than 4.

    I'll be sticking with the newest relese of FreeBSD, thanks.

    1. Re:Why 4.x? by Anonymous Coward · · Score: 0

      Why rip out all the FreeBSD 5 stuff and replace it when you can start with a code base from before it was added?

    2. Re:Why 4.x? by m.dillon · · Score: 5, Informative
      That is the crux of the issue. The problem is that while a great deal of work has gone into FreeBSD-5.x, it is all based on a fine-grained mutex locking MP model that is simply not compatible with the methodologies being implemented for DragonFly. 4.x isn't actually 'old', a good deal of non-MP related work has been merged from 5.x into 4.x. We miss out on a few big things, like UFS2, snapshots, and the security infrastructure in 5.x, but 6 months down the road when we have our new infrastructure in place reimplementing those items will be a trivial exercise. Also, 4.x is a far more stable base to work from then 5.x.

      Insofar as performance goes, a higher version number does not mean higher performance. 4.x is a lot faster then 5.x for many types of tasks. DragonFly will be able to implement critical subsystems in MP, like the TCP stack, using an essentially mutexless design, which ultimately means that DragonFly will theoretically be able to perform better then 5.x in an MP environment once both are able to completely remove the MP lock. But that is down the road quite a bit and a lot can happen between then and now.

    3. Re:Why 4.x? by jonabbey · · Score: 1

      How do you think your proposed BSD model compares to something like RCU?>/p>

    4. Re:Why 4.x? by Anonymous Coward · · Score: 0

      better than, not better then This kept jumping out at me as I read everything at dragonflybsd.org. :-)

    5. Re:Why 4.x? by quantum+bit · · Score: 1

      Yeah, it's too bad because the work being done here looks very interesting. However, after using FreeBSD 5.x (following current except during major imports) for a while I've grown rather attached to some of the new things introduced in 5; devfs, newbus, ACPI, MUCH new hardware support, etc. etc.

      While these, or suitable equivalents will probably make it into Dragonfly at some time, who knows when that will be with all the major work being done. Still, I'm fascinated by some of the concepts (especially working VFS layering) and will definately be playing with this on a spare machine when I get some time...

    6. Re:Why 4.x? by Anonymous Coward · · Score: 0
      Whatever. Faggot.

      Anal fisting.

  40. FreeBSD, watch out! by Anonymous Coward · · Score: 0

    "Our goal is to create a flexible duel-purpose caching infrastructure"



    Maybe this project should just be called "Oedipus"

    1. Re:FreeBSD, watch out! by Anonymous Coward · · Score: 0
      If you read between the lines, there is only one conclusion which a sensible,
      honest person can reach - FreeBSD is dying.

      That is the real story here. DragonFly is merely the Rosenkrantz.

  41. No, no... by fm6 · · Score: 2, Funny

    This isn't the actor, it's the lawman. Jeez, Slashdotters are so ignorant!

  42. Re:GNAA LATE POST by Anonymous Coward · · Score: 0

    Are you giggling hysterically about your post, you pimple-faced, fat, geek boy? No one else on earth is laughing with you. Get help.

  43. rands? by Anonymous Coward · · Score: 0

    is that you?

  44. Matt Dillon, eh? by Spudley · · Score: 2, Interesting

    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)

    --
    (Spudley Strikes Again!)
    1. Re:Matt Dillon, eh? by Anonymous Coward · · Score: 1, Interesting

      Dillon is the ONLY reason I'm paying any attention to this. Dillon kicks ass. He can make it work, if anyone can.

      And yeah, I also owned a copy of DICE on my Amiga. Awesome compiler. Still have the floppies.

      (Of course, then ixlib came along with GCC...)

    2. Re:Matt Dillon, eh? by MisterFancypants · · Score: 1
      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.

    3. Re:Matt Dillon, eh? by Anonymous Coward · · Score: 0

      Dillon's been contributing to FreeBSD for a while now.

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

    5. Re:Matt Dillon, eh? by Billly+Gates · · Score: 1
      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. I believe Yahoo chose php over java for the threading reasons since the Java API opens a new thread for each connection if I recall.

    6. Re:Matt Dillon, eh? by FFFish · · Score: 1

      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?

      --

      --
      Don't like it? Respond with words, not karma.
    7. Re:Matt Dillon, eh? by Anonymous Coward · · Score: 0

      Wow. That's pretty neat. You know what I remember you for? Being kicked off the core team.

      Guess you decided to take the ball home with you this time, eh?

  45. Paging Lorraine by jonabbey · · Score: 4, Insightful

    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.

    1. Re:Paging Lorraine by Anonymous Coward · · Score: 0

      I guarantee the "Lorraine" comment will fly over the heads of 99% of Slashdot's readers.

      I got it though. :)

      If only I had a joyboard...

    2. Re:Paging Lorraine by nutznboltz · · Score: 2, Informative
    3. Re:Paging Lorraine by Anonymous Coward · · Score: 0

      good for you and google...

    4. Re:Paging Lorraine by Anonymous Coward · · Score: 0

      Actually, NeXT was BSD with Mach kernel replacements (the progenitor to darwin) and HURD still is in BETA even though the Unix-y GNU userland that was written to run on top of it has been happily running on monolithic kernels such as *BSD and Linux for ages, So I don't see a difference in approach here.

    5. Re:Paging Lorraine by nutznboltz · · Score: 1
      NeXT was BSD with Mach kernel replacements
      Mach was the true kernel with BSD running on it like a server. Mach doesn't have fork() or open()/close() or filesystems, that was done in the BSD server.

      The GNU Hurd also using Mach (but that's being replaced) as the kernel but instead of only having one monolithic server to do all the UNIX-y stuff it has separate servers for each filesystem type and process management etc.
    6. Re:Paging Lorraine by nutznboltz · · Score: 1

      I suppose I should finish this by saying that DragonFly is a BSD with changes that make it operate more like a microkernel. System calls and device drivers communicate with messages.

      Matt's trying to remove the MP lock (aka giant lock) bottleneck.

      This page explains what FreeBSD does when you run top on an MP system and you see processes waiting for *Giant:

      Approach 1: global kernel lock (aka Giant Lock)
      - only one processor executing in kernel at any time
      - acquire lock when entering kernel
      - release lock when exiting kernel
      - need to prevent interrupts on all CPUs
      - disable locally, otherwise deadlock
      - interrupts on other CPUs acquire lock

      - simple first implementation of SMP kernel
      - limits kernel concurrency
      - limits performance for larger numbers of CPUs

    7. Re:Paging Lorraine by Anonymous Coward · · Score: 0
      jonabbey, here is a clue especially for you,
      *BSD is dying
      Hope this helps.
    8. Re:Paging Lorraine by jonabbey · · Score: 1

      Aw, that's cute.

  46. Re: FreeBSD 4.x problem by ReLik · · Score: 0

    Learn to configure your box.

    --
    WTF is a sig?
  47. Oh no, not another! by foolip · · Score: 4, Insightful

    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.

    1. Re:Oh no, not another! by afternoon · · Score: 2, Interesting

      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 too much.

    2. Re:Oh no, not another! by Billly+Gates · · Score: 1
      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 author pissed alot of people off and Linus refused the code. After it was stabilized and demand picked up he changed his mind.

      BSD is about eliteness and stability. They do not take code from just anyone. Linux is more laid back and if its stable Linus will include because he wants the chance for anyone to enjoy hacking and playing around on his kernel.

      OpenBSD started this way because Theo pissed off some people when he was critical on Netbsd security. Theo not only had CVS write access removed but a few of the leaders would refuse all of his patched. Technically he was fired. Well he created OpenBSD so he could continue his work and became sucessfull.

    3. Re:Oh no, not another! by burns210 · · Score: 1

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

    4. Re:Oh no, not another! by drsmithy · · Score: 1
      BSD is about eliteness and stability. They do not take code from just anyone. [...]

      s/eliteness/quality/

    5. Re:Oh no, not another! by Arandir · · Score: 1

      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 conflicts. There's no compelling need (that I can see) for OpenBSD security auditing to be done in a fork distinct from NetBSD. Darwin isn't really a fork so much as it's the next generation NeXT updated with FreeBSD instead of the obsolete 4.3BSD.

      DragonflyBSD may have been sparked by personality conflicts (fortunately they're keeping the dirty laundry in a locked hamper), but it's going to have substantial kernel and userland changes that need a fork just to be worked on.

      --
      A Government Is a Body of People, Usually Notably Ungoverned
    6. Re:Oh no, not another! by Anonymous Coward · · Score: 0
      I've said it once; I'll say it again:
      *BSD is dying
    7. Re:Oh no, not another! by Anonymous Coward · · Score: 0
      It is bad, definitely bad. *BSD is in deep trouble.

      *BSD is dying. No ands. No ifs. No buts.

      Do I have to spell it out? D - E - A - D

    8. Re:Oh no, not another! by Anonymous Coward · · Score: 0
      The way I figure it -- and I'm good at this business -- *BSD is dying.

      That about covers it, I guess.

    9. Re:Oh no, not another! by Anonymous Coward · · Score: 0

      Efforts to resuscitate *BSD are one step away from spiritualists wishing to communicate with the dead. As the situation grows more desperate for the adherents of this doomed OS, the sorrow takes hold. An unremitting gloom hangs like a death shroud over a once hopeful *BSD community. The hope is gone; a mournful nostalgia has settled in. Now is the end time for *BSD. *BSD is dead.

    10. Re:Oh no, not another! by CaffeinieBaby · · Score: 1

      Now is the end time for *BSD. *BSD is dead.

      Except for the fact that every OS X machine is running BSD, right? (Predicting Apple's death is a loser's game; always has been.)

    11. Re:Oh no, not another! by Anonymous Coward · · Score: 0
      Whatever the differences a few of us might happen to possess, we certainly can strive find some common ground. No doubt all of us can easily acknowledge the plain truth that in the balance *BSD would have to be considered a failure. So why did *BSD fail? What is at the root of *BSD's colossal miscue?

      Once you get past the fact that *BSD is fragmented between a myriad of incompatible kernels, there is the historical record of failure and of failed operating systems. *BSD experienced moderate success about 15 years ago in academic circles. Since then it has been in steady decline. We all know *BSD keeps losing market share but why? Is it the problematic personalities of many of the key players? Or is it larger than their troubled personalities?

      The record is clear on one thing: no operating system has ever come back from the grave. Efforts to resuscitate *BSD are one step away from spiritualists wishing to communicate with the dead. As the situation grows more desperate for the adherents of this doomed OS, the sorrow takes hold. An unremitting gloom hangs like a death shroud over a once hopeful *BSD community. The hope is gone; a mournful nostalgia has settled in. Now is the end time for *BSD.

  48. Re:One BSD by nomadic · · Score: 1

    Define "best"

    In terms of BSD? MacOS X.

  49. Re:BSD? More like LSD by robi2106 · · Score: 1

    Ahhhhh interesting detective work . . . I suppose I usually ignore AC posts that seem inflamitory.

    I probably will still do so . . .but interesting to know that someone:

    a) has a standard troll post like that
    and
    b) it is moderately interesting troll post
    and
    c) someone bothered to remember a previous troll

    May be I don't have enough time on my hands...

    robi

  50. Seems light on details by Vladimus · · Score: 1
    I'm not an OS hacker (IANAOSH?), so it doesn't seem like this announcement is announcing much of anything. There aren't really any details of what this project hopes to accomplish other than a new packaging system, and that in itself does not justify a new operating system.

    Perhaps the devil (no pun intended) is in the details. Certainly from the perspective of a end-user, who usually don't deal with packaging systems in the first place, this new OS doesn't make any difference.

    --

    A rolling stone is worth two in the bush!

    1. Re:Seems light on details by phoenix_rizzen · · Score: 1

      Hmmm, I'm betting you haven't been to the website, then. There's *a lot* more to this than just a new packaging system. Actually, the packaging system is the *last* item on the todo.

      DragonFly is about testing out new, possibly better ways of doing things in the kernel. SMP, VM, IO, devices, virtually every subsystem in the kernel will be redone.

      Read through the website. It's in fairly easy-to-read English, and covers all the goals of the project.

      Don't consider this a fork in that you'll have a new OS to play with next year. Consider it more of a skunkworks to test out new ideas and methods using the 4.x codebase. Who knows, if it's good enough, it just might become the basis for 6.x, or we could see most of it get merged back into 4.x and/or 5.x.

    2. Re:Seems light on details by Vladimus · · Score: 1
      I did go to the site, but from the perspective of a desktop user, correct me if I'm wrong, none of the low-level kernel work really makes a difference. Of course, BSD isn't really a desktop OS in the first place (well, 'cept Darwin, sort of) but...

      As far as server use goes, I'm sure that this will introduce and/or implement a lot of good ideas. However, I would think that reimplementing a BSD kernel, with a minimum of bugs and holes, will be difficult without tons of support. And it doesn't seem to make much sense to start an OS with the intention of merging it back into the parent OS.

      --

      A rolling stone is worth two in the bush!

    3. Re:Seems light on details by Anonymous Coward · · Score: 0

      It's a DAEMON you fucking linux user.

  51. dragonflyBSD? you're kidding me? by ReLik · · Score: 0

    Oh comon Drag-On-Fly-Bee-Ess-Dee, what was wrong with the name FlyBSD?
    Now THATS an operating system name, nice, simple, to the point, and is just overall a bitchin` name.

    --
    WTF is a sig?
    1. Re:dragonflyBSD? you're kidding me? by Anonymous Coward · · Score: 0
      Here's a quick rundown:
      • *BSD is dying
    2. Re:dragonflyBSD? you're kidding me? by ReLik · · Score: 0

      You're wrong. I could say Linux is dying but it can't because it spreads so fucking fast it's like a virus.

      BSD is quality and not quantity, it can't die, because then a big chunk of the 'real' unix dies.

      --
      WTF is a sig?
  52. THIS MIGHT HAVE A CHANCE! by Anonymous Coward · · Score: 0

    This might have a chance of surviving! FINALLY - and I really _mean it_ - someone has thought about the mascot issue with BSDs. This DragonFly mascot will not scare anyone away, it will attract people. It was a wise choice and I personally think it looks cool :) Well done and I'm eager to see this project grow!

    1. Re:THIS MIGHT HAVE A CHANCE! by Anonymous Coward · · Score: 0

      All major surveys show that *BSD has steadily declined in market share. *BSD is extremely sick and its long term survival prospects are infinitesimally dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.

  53. best, eh? by SweetAndSourJesus · · Score: 1

    Best desktop, sure. No arguments here. I'm posting this from an iMac running 10.2.

    Best server? Highly debatable. OS X Server is a fine product, one I'd never disparage, but I'm very happy running a FreeBSD HTTP/IMAP/IRC/Loads of other stuff server and an OpenBSD firewall.

    The "best" is always whatever works best for you.

    --

    --
    the strongest word is still the word "free"
    1. Re:best, eh? by nomadic · · Score: 1

      But if you were to add up all the features, server-side and GUI, I think OS X would handily win.

      BTW, that's the greatest email address I've ever seen.

  54. Surely this is a mistake... by CyberKnet · · Score: 0, Flamebait

    Surely this is a mistake. It must be ... It has to be, becaise we all know: BSD Is Dying

    Did someone forget to give this guy the memo?

    --
    Video meliora proboque deteriora sequor - Ovidius
  55. Messaging layer by truth_revealed · · Score: 1

    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?

    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:Messaging layer by Anonymous Coward · · Score: 0

      It won't slow down FreeBSD at all if they choose not to merge in any code from DragonBSD. But this indeed will be interesting to watch.

    3. Re:Messaging layer by Billly+Gates · · Score: 4, Interesting
      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.

    4. Re:Messaging layer by m.dillon · · Score: 5, Informative
      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.

    5. Re:Messaging layer by CraigParticle · · Score: 1
      In fact Dillion help fixed the vm bug in Linux 2.4.

      Huh? FreeBSD's current VM (which Dillon played a very significant role in developing) was indeed the inspiration for the (Rik van Riel) VM in 2.4.0 through 2.4.9. But this VM was largely replaced in the 2.4 mainline kernels starting with 2.4.10. The replacement was principally a balance between Rik's multiqueue approach and Andrea Arcangeli's classzone-based patches. AFAIK, this "fix" had nothing to do with Dillon, besides it was a departure from the existing FreeBSD approach.

      Rik's VM has continued to develop -- it was maintained in Alan Cox's -ac tree for a long time and today it is very successful in the form of Rik's reverse mapping patches, a feature that (in a somewhat different form) is also in FreeBSD.

      The minimal reverse mapping feature itself has been integrated into kernel 2.5/2.6-test, though the page replacement algorithms in 2.5/2.6 are much closer to the original Arcangeli classzone approach than Rik's. We'll see if new page replacement schemes, and object-based rmap (akin to FreeBSD) show up in kernel 2.7.

      Point being, I know Dillon has admitted interest in Linux VM development, but I'm unaware of any direct involvement (i.e. patches).

    6. Re:Messaging layer by Anonymous Coward · · Score: 0

      Technically its not a job...

      Here, "its" should be "it's", as "it's" is a contraction for "it is". That clause has no verb.

      Infact

      "Infact" is two words, "in", and "fact". As such, what you should have written is "In fact..."

      The rest of your sentence structure is good, though.

    7. Re:Messaging layer by Anonymous Coward · · Score: 0
      All joking aside, FreeBSD really is "dying" in a sense. After Jordan and Mike left, the project has been a shambles. The best way to describe FreeBSD kernel code now is "shabby". Matt is a brilliant perfectionist who wants to do the right thing. The current state of FreeBSD kept him from pursuing excellence.

      Unfortunately the FreeBSD core has come to be dominated by political types who are short on engineering skills. They gave Matt the air and locked him out of CVS. The FreeBSD kernel is currently full of ugly expedient hacks *and* several intractable bugs.

      Of all the BSD kernels, FreeBSD can now be considered the most hackish and ill conceived. It wasn't always this way, of course. But presently the FreeBSD development environment continues to favor the political solution over the technically correct one. OpenBSD and NetBSD both do much better on quality issues. I suspect that DragonFly will come to be highly regarded as the latter two as well.

    8. Re:Messaging layer by JulianD · · Score: 1

      Technically its not a job but they refuse all his patches and he lost write access.

      Actually I think it was more due to personality conflicts; I can't comment on his technical ability. Users appear to love him, though, since he's very responsive to their queries, but as far as his ability to persuade core of his views, that's another matter.

    9. Re:Messaging layer by Anonymous Coward · · Score: 0

      This is just not true. The BSD political landscape aside, I find it extremely hard to believe that you are familiar with the kernel code of OpenBSD, FreeBSD, AND NetBSD to be specifically picking FreeBSD out of the lot and branding it as "shabby". I would like you to site specific "shabby" examples that support your rather confident wording. I am also interested in the "intractable bugs" and "expedient hacks" you mention in your post.

    10. Re:Messaging layer by Fly · · Score: 1

      This sounds absolutely fantastic. Thank you for the explanations here and at the dragonfly website.

      --
      end of line
    11. Re:Messaging layer by Elbereth · · Score: 1

      Hah. Keep fighting the good fight, soldier. Though we may never win a single battle, and the President will never declare a War On Bad English, we must never give up hope.

      Too bad you didn't post logged in, or I'd have added you as a friend.

    12. Re:Messaging layer by stripes · · Score: 1
      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.

      It is intresting and powerful, but there is no good reason the existing API methods are any more fragile then the proposed messaging system.

      I think one of Dragonfly's main arguments that messages are better is some API calls pass structs and when there is a need to chage the struct to add features old code breaks. I'm pretty sure stat is used as an example. Now I beleve it is true that compatability is broken from time to time because of this sort of issue, but I strongly beleve that it is needlessly broken.

      If you need to change the stat structure (say file sizes change from 32 bits to 64 -- I know, it is already 64, but it's an example, work with me here!) there is a way to keep it compatable. You allocate a new syscall number to deal with the new stat struct and leave the old syscall number around for the old stat structure. Yes this bloats the kernal a tiny bit (esp if you handle 32 bit overflows by doing anythign smarter then just giving back the low 32 bits!), but it does work.

      What the message passing method ends up doing is doing the same work in a kernel-protected (and I assume kernel loaded!) chunk of userland code. I'm not sure it is less bloat, even if it is more elligant.

      I do think other aspects of message passing may be quite useful, but as a answer to the "brittle API problem", it seems like a huge amount of overkill.

    13. Re:Messaging layer by Anonymous Coward · · Score: 0
      You know, I gotta chime in here. It really pisses me off that FreeBSD does not let you (by default)
      % cd /usr/ports
      % make update
      It tells you that you need to futz around and configure things. If I wanted to do that,
      I'd install stuff by hand. I just want to update my ports - I don't think that's too much to ask.

      Yes, I've submitted that as a bug. Yes, it was rejected.

  56. Finally ... by zxSpectrum · · Score: 1

    ... a place where the "BSD is dying" guy can post and be vaguely on-topic

  57. Re:GNAA LATE POST by Anonymous Coward · · Score: 0

    Oh, come ON people! The first GNAA post doesn't appear until after three pages of comments?

    Slashdot is the world's finest troll repository. We expect our trolls to be ON THEIR GAME at ALL TIMES. High standards are at work here. Shape up!

  58. TROLL? by Anonymous Coward · · Score: 0

    um... is he trolling because he didn't realize there was BSD code in Windows? sheesh! time to meta-moderate.

    1. Re:TROLL? by Anonymous Coward · · Score: 0
      Barbra Streisand Dummies - BSD

      July 18, 2003 -- Barbra Streisand has not forgiven Joe Lieberman for his pointed comments about how Hollywood debases American values. Bush-hating Babs gave bucks to every other major Democratic presidential contender - Howard Dean, John Kerry, Bob Graham, John Edwards, Dick Gephardt and even Al Sharpton - but conspicuously left Lieberman off her list. Could it be Iraq? Well Gephardt, Edwards and Kerry all voted for the Iraq war, as Lieberman did.

      Lieberman spokesman Jano Cabrera tells The Post's Deborah Orin: "As someone once said, people need people. And we look forward to returning to the way we were in the future and earning the support of our funny valentine in the general election." Not that Babs was overly generous for a multimillionaire - the maximum donation now is $2,000 but she gave $1,000 apiece. Also missing from her gift list was the only woman in the race, ex-Sen. Carol Moseley Braun, and the very most liberal contender, Rep. Dennis Kucinich (D-Ohio.)

  59. *BSD Basher Dead at 16 by slickwillie · · Score: 5, Funny

    Anonymous Howard, who made a career of proclaiming the demise of the *BSD Operating Systems, was found dead at his keyboard this afternoon. He had just turned 16. An unnamed police spokeswoman said it was an apparent case of "autoerotic asphyxiation gone haywire". [You know the rest of the story.]

  60. Hey pardners! by Trolling4Dollars · · Score: 1

    What does an old gunslinger have to do with this announcement? Even more important... will Miss Kitty be involved?

    1. Re:Hey pardners! by Anonymous Coward · · Score: 0
      On the radio it was William Conrad as Matt Dillon. When he was on TV, William Conrad played Jake and the Fatman. William Conrad sweated like a stuck pig cause he was so fat. He played the Fatman.

      Dodge City on the radio was a joyless barren place populated by psychos and depressives. Matt Dillion was a compulsive psycho as played by William Conrad. Dragonfly Psycho.

  61. hmm by luphus · · Score: 1

    So is forking something that's dying anything like beating a dead horse? :-)

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

    1. Re:Well, good luck to him! by burns210 · · Score: 1

      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.

    2. Re:Well, good luck to him! by SN74S181 · · Score: 1

      There are too many conflicting priorities.

      As an example, I work (only as a user) with the NetBSD packages collection. Because I like running a number of different architectures. For the NetBSD project, an important aspect of the packages collection is it's wide cross-platform focus. With FreeBSD and with Linux, there just isn't the same focus on ports working on many platforms. So the cross-platform wonderment that is the NetBSD pkgsrc system would be diluted if it were merged with the folks who really only care if it builds on i386.

  63. Lefties by siskbc · · Score: 0, Offtopic
    righties sure know how to kill everything that's not a fetus.

    Ironically, lefties know how to save anything that's not. Personally, I don't think either stance makes much sense.

    --

    -Looking for a job as a materials chemist or multivariat

  64. Re:just what this planet needs ... by Anonymous Coward · · Score: 0

    Looked like he violated their code of conduct a few too many times.

  65. Re: FreeBSD 4.x problem by AvengerXP · · Score: 1

    This one never gets old. I also laughed my ass off to the ones above. Here's my contribution, i've got spare Karma, *BSD, dead at 55.

    --
    Trolls dont like to be Flamebait, because they burn so well. Protect our Troll heritage!
  66. Debian BSD by YAH00 · · Score: 1

    I guess they need to look at

    Debian FreeBSD

    They've come quite a long way and have installable systems available

    Glibc Based Debian Freebsd

    Seems like this is what Dragon fly FreeBSD is trying to do

    1. Re:Debian BSD by merdark · · Score: 1

      No, this is very very far from what DragonflyBSD is trying to do. Just because the project want's to make an updated package manager doesn't mean it's anything like Debain.

      If anything, the packaging system is a cross between Debian's and Apple's (in the sense that packages are versioned and multiple versions can coexist in the system).

      The rest of the system is completely different. It's not glibc based, it's not GPL, it's not paranoid about commercial software, and the big changes are in the kernel. Debian is not in the kernel business.

  67. Security? by SewersOfRivendell · · 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

  68. Re:Another one? by Anonymous Coward · · Score: 0

    Makes you wonder if OS X/darwin will be paying much attention to what Matt's doing.

  69. NO SATANIC DEMON ANYMORE by Anonymous Coward · · Score: 0

    Good!

    No offensive satanic demon mascot anymore! This is what FreeBSD should've done YEARS ago - ditch that red guy with horns. Us non-satan worshippers can now give BSD a try.

    1. Re:NO SATANIC DEMON ANYMORE by merdark · · Score: 1

      It's still the child of a deamon though. In fact, much of UNIX was created by satan. I like heat myself, and just love the little deamon. ;)

      Of course, if you really want to be free of satan's influence there is always Jesux!

      Uh oh, Lucifer is gonna make me suffer for giving a link to the enemies operating system! *runs and hides*

    2. Re:NO SATANIC DEMON ANYMORE by Anonymous Coward · · Score: 0

      Tried to get our church to use FreeBSD once, but after our pastor looked at the URLs I gave him, he declined becuase of the Satanic imagery which he encountered. It bothers my conscience too, but I sort have ignored dealing with the issue . . .

  70. Critical mass by marcovje · · Score: 1


    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?

    1. Re:Critical mass by Anonymous Coward · · Score: 0
      marcovje writes,
      How is he going to sustain _any_ release engineering the quality FreeBSD (and the major Linux distro's) has/have?
      FreeBSD can no longer be considered quality in the same way that NetBSD and OpenBSD can. If anything Matt will improve FreeBSD over its current debilitated state.

      Although it may come as a surprise to you, and with all joking aside, FreeBSD really is "dying" in a sense. After Jordan and Mike left, the project has been a shambles. The best way to describe FreeBSD kernel code now is "shabby". Matt is a brilliant perfectionist who wants to do the right thing. The current state of FreeBSD kept him from pursuing excellence.

      Unfortunately the FreeBSD core has come to be dominated by political types who are short on engineering skills. They gave Matt the air and locked him out of CVS. The FreeBSD kernel is currently full of ugly expedient hacks *and* several intractable bugs.

      Of all the BSD kernels, FreeBSD can now be considered the most hackish and ill conceived. It wasn't always this way, of course. But presently the FreeBSD development environment continues to favor the political solution over the technically correct one. OpenBSD and NetBSD both do much better on quality issues. I suspect that DragonFly will come to be highly regarded as the latter two as well.

    2. Re:Critical mass by Anonymous Coward · · Score: 0

      Release engineering? FreeBSD? Don't make me laugh. Those folks wouldn't recognize a real "code freeze" if it was shoved up their collective arses.

      Okay, folks, we release in one week, bugfixes only now. Ooh, you have a sweet new widget that will likely introduce 200 new crippling bugs before perfected? Commit it to both CURRENT and STABLE! We'll just delay the release for three months, add some more buggy features and make the whiners eat their words while we wax on about "unmatched FreeBSD stability"- the really stable FreeBSD servers all run version 2.2.2. Ah, those were the days. We haven't had an on-time release since 4.3, and I'm loath to go against tradition.

  71. Re:One BSD by marcovje · · Score: 1


    Why not one *NIX them?

    I'm mainly a BSD user (still like Slackware, my first Linux encounter of the first kind), but from a user perspective the various BSDs are more coherent than the avg Linux distro.

    A different kernel is often irrelevant if you come above a certain level. A level below which an average user won't go anyway.

  72. Re:One BSD by marcovje · · Score: 1


    (should have used "preview" :-)

    Anyway. A lot of posters which whine about the fragmented BSD seem to forget that _any_ *nix OS fork will pick developpers from Linux too. While
    there used to be a large gap between FreeBSD and Linux, this has been closed in the last few years. FreeBSD got more user (-hardware) friendly, Linux moved, and partially even topped FreeBSD in the advanced server range.

    This might draw Linux developpers even in larger absolute numbers than from e.g. FreeBSD.

    And while the Linux developper numbers might be large, the real useful people are scarce, and every loss is, uhh...., a loss, while the new BSD
    won't be able to gain enough momentum to keep
    up in release engineering and hardware support.

    The era that *nix clones can enter the general purpose market is simply over, at least at this
    moment.

  73. Re:just what this planet needs ... by Anonymous Coward · · Score: 0

    ...Which might have a little to do with DragonBSD, since it branches off from 4.x...

  74. I CAN SEE THROUGH YOU by Anonymous Coward · · Score: 0

    Even BBEdit Lite is straining to keep up as I type this.

    would choose to use a Mac over other

    Come on, trolltacula, you can do better than that.

    -uso.

    1. Re:I CAN SEE THROUGH YOU by Anonymous Coward · · Score: 0

      sorry it was late. I'll try harder today.

  75. Portage on *BSD? by Metalhead01 · · Score: 1
    I've noticed a few posts about using Portage on DragonFly, and though this might be of interest to some people: a small group of Gentoo enthusiasts are working on porting (no pun intended) Portage to *BSD. The thread on the Gentoo forums is here.

    --
    The only reason I keep my Windows partition is so I can mount it like the bitch that it is.
  76. Its worse in the Gnu/Linux fork-world. by Anonymous Coward · · Score: 0

    Think about it.

    200+ different things all called *linux*, and 2 different sets of people.

    1 set - all the linuxes are from the same kernel, so it doesn't matter
    the other set? The marketing agents who want to prove SuSE is better than RedHat who's better than (juggle fork names in whatever order floats your boat.)

    Thus market confusion reigns.

  77. Good luck to you Matt. by NerdlyMcGeek · · Score: 0

    Though many folks have choosen to troll out the BSD is dying thingy they may have a point. As solid as all the BSDs ,Free, Open and Net are they have become remarkbly stodgy to use. I would guess the development teams are likely stuck in this same rut as well. I am happy to see somebody step up to the plate to try, but the BSD license will eventually kill this one to I fear. If it ever does come to maturity and show any real promise some mega corp will just hijack the codebase, upstage them and just spit in their eye again anyway. How do you spell sucess? GPL

    1. Re:Good luck to you Matt. by m.dillon · · Score: 4, Interesting
      You know, I hear this junk all the time and I can only conclude that the people who spout it off have no real understanding of what the BSD or GPL licenses actually are, let alone their respective effects on the environment around them. The hype has far outstripped the reality and the result are hoards of young programmers slapping the GPL on trivia and minutia that has no other effect then that of relegating their bits to the dustbin of history. And the really sad thing is that it can take years sometimes to realize you've screwed yourself when, say, ten years down the line you want to use work you did on a collaborative project for something that doesn't quite fit the license and find you can't because you have no idea who else to contact to unwind the GPL'd mess. Oops! I find the GPL useful only if I intend to potentially relicense to commercial entities under separate cover and that is pretty much it. The BSD does a better job, statistically, in polluting commercial source bases with open standards and always will. Even microsoft's attempts to proprietize BSD licensed code has resulted in a far greater adoption of open standards, such as with kerberos, then if they had written their own from scratch which would have been 100% proprietary instead of only 5% proprietary. TCP and DNS also come to mind. Those were big wins for our side folks, mostly looked over because you idiots focused in on what microsoft tried to do rather then the actual big picture effect of what they wound up doing.

      The problem with the GPL is that it doesn't trust its fate to human nature but instead tries to force an effect that tends to be against human nature. GPL is a license based on fear and uncertainty, at least from an idealogical standpoing. The BSD license recognizes human nature and works with it to far greater effect for the society as a whole. I prefer trust to fear. I'm just not the paranoid type and if one doesn't have commercial motives for using the GPL one really has to have a high level of paranoia to justify it. That is the reality of the GPL. I use it occassionally, but for commercial reasons only. Everything else I do under the BSD.

      -Matt

    2. Re:Good luck to you Matt. by Anonymous Coward · · Score: 0

      You are an idiot or a troll.

    3. Re:Good luck to you Matt. by Quill_28 · · Score: 1

      >I'm just not the paranoid type and if one doesn't have commercial motives for using the GPL one really has to have a high level of paranoia to justify it.

      Or maybe you are just not the socialist type.
      Don't mind people getting paid to program and feel the BSD license helps society alot more than the GPL ever will.(Note to the trolls, I did not say some of the programs written under the GPL did not help society, just that the BSD license helps society more than the GPL).

  78. Dragonfly BSD by Anonymous Coward · · Score: 0
    I know what Dragonfly BSD does... it eats Linux fairies!

    I'd hate to let it loose on Slashdot.. we'd have no comments on our posts!

    YOU FAIL IT, that's right motherfuckers.

  79. Re:148 dead in Iraq by Anonymous Coward · · Score: 0

    Lefties, on the other hand, are in favor of everything good, against everything bad, but won't specify what falls into which category, because different people have different ideas of what's right or wrong. Everything's relative, isn't it? Elect me, elect me!

  80. Re:just what this planet needs ... by Anonymous Coward · · Score: 0

    Don't cha know? Like many lower animals, *BSD eats its own.

  81. If bsd is among the dead? by ratfynk · · Score: 1

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

    --
    OH THE SHAME I fell off the wagon and use sigs again!
    1. Re:If bsd is among the dead? by Anonymous Coward · · Score: 0

      Why get in touch-typing with ELVIS when there's a perfectly usable VI?
      For singing, just hit the ESC-key repeatedly.

    2. Re:If bsd is among the dead? by Anonymous Coward · · Score: 0
      There's no beating around the bush: *BSD is a failure. Once you get past the fact that *BSD is fragmented between a myriad of incompatible kernels, there is the historical record of failure and of failed operating systems. *BSD experienced moderate success about 15 years ago in academic circles. Since then it has been in steady decline. We all know *BSD keeps losing market share but why? Is it the problematic personalities of many of the key players? Or is it larger than their troubled personalities?

      The record is clear on one thing: no operating system has ever come back from the grave. Efforts to resuscitate *BSD are one step away from spiritualists wishing to communicate with the dead. As the situation grows more desperate for the adherents of this doomed OS, the sorrow takes hold. An unremitting gloom hangs like a death shroud over a once hopeful *BSD community. The hope is gone; a mournful nostalgia has settled in. Now is the end time for *BSD.

    3. Re:If bsd is among the dead? by Anonymous Coward · · Score: 0
      We know it's dead.

      You know it's dead.

      Everyone knows it's dead.

      *BSD is dead.

    4. Re:If bsd is among the dead? by ratfynk · · Score: 1

      Last comment was a post from a dedicated Hot Mail user! Serve that up to the dead crowd leave being dead to the Greatfull. As I listen to 'Poor Peter' on my bsd box.

      --
      OH THE SHAME I fell off the wagon and use sigs again!
  82. Boy that was a quick troll bot response! by ratfynk · · Score: 1

    holy cow a ghost post bsd can't be dead that anon dead idiot only took a matter of miniutes to reply.
    Sounds like a political war between people with gig egos, and axes to grind.

    --
    OH THE SHAME I fell off the wagon and use sigs again!
  83. Re:BSD? More like LSD by Anonymous Coward · · Score: 0

    BSD is a failure. Simple as all that.

  84. Re:Another one? by Anonymous Coward · · Score: 0

    Dead is BSD. No longer worth the trouble. Dead.

  85. Pedantic Amiga Comment by Anonymous Coward · · Score: 0

    Matt - Love the project. Really, really love the project. I've been walking around with a ridiculous grin all day long that someone in the *NIX scene is finally going to try to Do the Right Thing. (Of course, as a FreeBSD user, I'm equally interested to see how KSE and the like perform when all is said and done -- but when it comes to doing something useful, like, say, deploying production systems, it's all about the solution with the right featureset and the fewest parts to break.)

    That said, I've got point out to the rabble that no, Amiga, in any of the Classic, Extra Crispy, or
    Third-Party-Possibly-Rebranding-to-Atari flavors, is certainly no deader than the good ol' Atari camp. It's just that, as you've said elsewhere, the Amiga scene has had GCC for quite a while -- and is now using it in the development of both competing OSes -- so we've less reason to bother you for legacy support than those poor ST users. ;)

    We're rooting for you!

  86. Re:Another one? by Anonymous Coward · · Score: 0

    That's the bitch part about freedom: people don't always do what you want them to do.
    And yet it is reasonable to conclude that *BSD is dying.

  87. Re:GNAA LATE POST by Anonymous Coward · · Score: 0

    hehehe, I'm laughing. YHBT.

  88. Re:One BSD by Anonymous Coward · · Score: 0
    FreeBSD went out of business and was taken over by BSDI who
    sell another troubled OS. Now BSDI is also dead, its corpse turned
    over to yet another charnel house.

    All major surveys show that *BSD has steadily declined in market share.
    *BSD is very sick and its long term survival prospects are very dim.

  89. Re:*BSD is dying by Anonymous Coward · · Score: 0
    I guess we can agree on one thing, i.e. that overall *BSD is indeed a failure. But why did *BSD fail? Once you get past the fact that *BSD is fragmented between a myriad of incompatible kernels, there is the historical record of failure and of failed operating systems. *BSD experienced moderate success about 15 years ago in academic circles. Since then it has been in steady decline. We all know *BSD keeps losing market share but why? Is it the problematic personalities of many of the key players? Or is it larger than their troubled personalities?

    The record is clear on one thing: no operating system has ever come back from the grave. Efforts to resuscitate *BSD are one step away from spiritualists wishing to communicate with the dead. As the situation grows more desperate for the adherents of this doomed OS, the sorrow takes hold. An unremitting gloom hangs like a death shroud over a once hopeful *BSD community. The hope is gone; a mournful nostalgia has settled in. Now is the end time for *BSD.

  90. Re:Another one? by Anonymous Coward · · Score: 0

    It is the age old story of market consolidation. It happened in the auto industry--LaSalle, Packard, DeSoto, all fine cars, all dead. The same shakeout is happening in the operating system realm. The end of BSD is a sign of progress in its own way. The consolidation of markets indicates a maturing market. This is a good thing. Even death brings forth new life.

  91. Re:It's NOT dying you bastards! by Anonymous Coward · · Score: 0
    Yes it is dying. FreeBSD went out of business, then BSDI bought up the remains. Now BSDI is also dead, its corpse turned over to yet another charnel house.

    All major surveys show that *BSD has steadily declined in market share. *BSD is sick beyond repair, and its long term survival prospects are infinitesimally dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.

  92. Re:Dragonfly BSD, life expectancy? by Anonymous Coward · · Score: 0
    It is common knowledge that *BSD is dying. And yet why did *BSD fail? Once you get past the fact that *BSD is fragmented between a myriad of incompatible kernels, there is the historical record of failure and of failed operating systems. *BSD is a failure.

    Efforts to resuscitate *BSD are one step away from spiritualists wishing to communicate with the dead. As the situation grows more desperate for the adherents of this doomed OS, the sorrow takes hold. An unremitting gloom hangs like a death shroud over a once hopeful *BSD community. The hope is gone; a mournful nostalgia has settled in. Now is the end time for *BSD.

  93. Ugh. Bad! by grimani · · Score: 1

    Yeah, DragonFly was a horrible movie.

    And it was Kevin Costner, not Matt Dillon.

  94. Re:Hard Times For FreeBSD by Anonymous Coward · · Score: 0
    In light of this further fragmentation of the *BSD community, we must ask ourselves: Why is FreeBSD dying? Then again, perhaps we should address the broader, more general question: Why did *BSD fail?

    Once you get past the fact that *BSD is fragmented between a myriad of incompatible kernels, there is the historical record of failure and of failed operating systems. *BSD experienced moderate success about 15 years ago in academic circles. Since then it has been in steady decline. We all know *BSD keeps losing market share but why? Is it the problematic personalities of many of the key players? Or is it larger than their troubled personalities?

    The record is clear on one thing: no operating system has ever come back from the grave. Efforts to resuscitate *BSD are one step away from spiritualists wishing to communicate with the dead. As the situation grows more desperate for the adherents of this doomed OS, the sorrow takes hold. An unremitting gloom hangs like a death shroud over a once hopeful *BSD community. The hope is gone; a mournful nostalgia has settled in. Now is the end time for *BSD.

  95. It's official... by 42forty-two42 · · Score: 1

    "BSD is dying" is dying.

  96. I'm not so sure :) by Balinares · · Score: 1

    > You need to rsync quite often

    Only before updating everything. How often that is, is up to you. :)

    > I noticed several broken ports.

    It indeed happens! Is it, however, Portage's fault, or that of the package's maintainer?

    > ... under FreeBSD I can chose specific mirrors to specific packages.
    > Try that with portage?

    GENTOO_MIRRORS="http://somewhere.somedomain.net" emerge somepackage

    You're welcome.

    Now don't take me wrong. BSD Ports are very good.
    It's just that Portage is no less good.

    --

    -- B.
    This sig does in fact not have the property it claims not to have.
  97. From another FreeBSD committer... by dcs · · Score: 1

    ...I wish Dillon luck. I have always admired his work, and thought the goals of his project I had heard of before interesting.

    People should realize FreeBSD couldn't go both ways at the same time. We went one way, and Dillon will be going another way. If his project survives, and I hope it does, it should benefit everyone. Even if the source itself is never used elsewhere, we'll learn with the experience.

    --
    (8-DCS)
  98. Forks are good... by cesarcardoso · · Score: 1

    I'm still trying to figure why people chime so much against forks. Forks make Open Source go round, let people explore new directions, and avoid ultimate fighting-style fights :-)

    Anyway, good luck to Dilon, especially on his ports/packages rewrite work.

    --
    Cesar Cardoso can be found at cesar at zyakannazio dot eti dot br (or at least I believe so)
  99. Re:Another one? by Anonymous Coward · · Score: 1, Insightful
    OK, I gotta chime in here. It really pisses me off that FreeBSD does not let you (by default)
    % cd /usr/ports
    % make update
    It tells you that you need to futz around and configure things. If I wanted to do that,
    I'd install stuff by hand. I just want to update my ports - I don't think that's too much to ask.

    Yes, I've submitted that as a bug. Yes, it was rejected.

  100. Re:Why Bother? by Anonymous Coward · · Score: 0
    Dear Apple,

    I am a homosexual. I bought an Apple computer because of its well earned reputation for being "the" gay computer. Since I have become an Apple owner, I have been exposed to a whole new world of gay friends. It is really a pleasure to meet and compute with other homos such as myself. I plan on using my new Apple computer as a way to entice and recruit young schoolboys into the homosexual lifestyle; it would be so helpful if you could produce more software which would appeal to young boys. Thanks in advance.

    with much gayness,

    Father Randy "Pudge" O'Day, S.J.

    * * * * * *

    Dear Father O'Day:

    Thanks for your letter. Being Catholic myself, I know exactly what you're talking about! It has always been our plan here at Apple Computer Inc to revolutionize personal computing with our high-quality and highly gay products.

    I'm happy to answer your letter by letting you know that YES we will be releasing an entire hLife ("homo-life") software line. You'll be able to recognize it in stores by the small stylized logo depicting a large cock entering a tight anus with an Apple logo on it. ("Suddenly it all comes together" indeed!).

    Anyway, I hope you and other members of our community will join us on our mission, and purchase the exciting new hLife boxed set. Only the boxed set comes with translucent cock rings!

    Sincerely,

    Harry Rodman
    Vice-president
    Homosexual Liaison Services
    Apple Computer, Inc.

  101. rands? by Anonymous Coward · · Score: 0

    Ayn Rand. C'est moi.

  102. Forks are bad... by Anonymous Coward · · Score: 0

    Forks are bad. Every time we BSDers have a fork it means *less compatibility*. It is truly ironic that each BSD variant is more binary compatible with Linux than with each other. The Linux folks got it right - keep the kernel standard and customize in user land. On the other hand we are almost exactly the opposite -- vary the kernel and keep user land almost the same. Wouldn't it be nice if commercial software vendors could release a plain "BSD version" guarenteed to work with Open/Net/Free/DragonFly/Whatever ?

  103. Re:Another one? by Anonymous Coward · · Score: 0
    Don't cha know FreeBSD sucks

    It teh ghey hay.

  104. Re: gah, ENAMETOOLONG by Anonymous Coward · · Score: 0

    gah ENAMETOOLONGTOOLONG.

    Better stick with EDOOFUS. ;^)

  105. back to the amiga by Anonymous Coward · · Score: 0

    matt should be putting his effort back into amigas. forget PCs brother!

    shit, I've been watching too much of Hulk Hogan...

    1. Re:back to the amiga by Anonymous Coward · · Score: 0

      Kinda weird, this Matt guy has an affinity for dead operating systems . . . :)

  106. Re:148 dead in Iraq by Anonymous Coward · · Score: 0

    Sounds like you've described most politicians, actually...

  107. sounds cool by Aeonsfx · · Score: 1

    Sounds cool, maybe its a chance for *BSD to gain some mainstream appeal. An improved package system could make it useable for mere mortals... Ah, but I'll probably stick to FreeBSD for the time being, it seems good enough to me... Tim

    1. Re:sounds cool by 1s44c · · Score: 1

      An improved package system could make it useable for mere mortals

      Mere mortals can't cope with:

      make
      make install

      What do you mean?

    2. Re:sounds cool by Aeonsfx · · Score: 0

      I mean, its packaging system is not entirely up to date with the ports. Don't get me wrong, I love FreeBSD, and I use it on both of my machines, but I don't think its the ideal system for newbies. Newbies should never deal with compiling from source, if you ask me. Sure, I'm happy with it, but I don't think my mom or my uncle understands why its taking 3 hours for them to install, say abiword, or kword... The packaging system is pretty good, but it could be better. And on another topic, DragonFly seems to be emulating many cool Amiga-like kernel features into the OS. He seems very open minded, and could make BSD very popular.

  108. Re:It's NOT dying you bastards! by Aeonsfx · · Score: 1

    Thats just silly. I use FreeBSD as my production workstation (that includes XWindows, Gnome 2.x, lots of bleeding edge stuff) and it works fine. *BSD isn't dead, and as long as its as FreeBSD is as well maintained as it is, I'm happy. Time to update my ports tree. :) Tim

  109. Re:I am gay by Aeonsfx · · Score: 0, Offtopic

    The statement of an anonymous coward, not BSD (which, incidentally, is *not* a living organism)

  110. Moderators on crack by CyberKnet · · Score: 1

    Follow the link guys. It's a link to a thread on a BSD mailing list complaining about a guy on slashdot posting the usual diatribe about BSD dying.

    it's s-a-r-c-a-s-m folks! And a little bit of irony mixed in...

    --
    Video meliora proboque deteriora sequor - Ovidius
  111. Re:BSD? More like LSD by Anonymous Coward · · Score: 0

    Don't be too impressed on a). The original poster is probably a script.

    It would be really interesting if the someone in c) is also a robot, though.

  112. Re:I am gay by Anonymous Coward · · Score: 0
    Aeonsfx sez:
    ". . . BSD (which, incidentally, is *not* a living organism)"
    Quite true. BSD is dead.
  113. Re:I am gay by Aeonsfx · · Score: 0

    No, no, no, you anti-BSD trolls are all quite confused (and incorrect). No operating system is not physically alive, thats what I was intending to say. Next, BSD is not dead. (Only cynical ./ readers, or windows users would say such things) In fact, its much easier to keep current with most *nix applications on FreeBSD than on most Linux Distributions, at least for me. Now, what I would constitute as being "alive" are three categories: 1) Is it maintained? 2) Is the source code available to fork if necessary? 3) Is it in widespread use? The answer to #1 is definitely a yes. And is FreeBSD maintained? Yes. Is NetBSD maintained? Yes. Is OpenBSD maintained? Yes. #2. Yes for all BSDs, well maybe a partial yes for Darwin... #3 Is it in widespread use? Sadly, this would have to be a no, but with the innovations of Darwin, (if you count that as BSD, then #3 is yes) and Dragonfly (which looks quite groundbreaking to me, if not much more so than Darwin) So whats your problem, coward?? can't show your true face?? Tim

  114. But did you incorporate Amiga's bouncing ball? by Anonymous Coward · · Score: 0

    Now that's high tech multitasking.

  115. DragonFlyBSD by Anonymous Coward · · Score: 0

    This looks *realy* cool!

  116. Developer lashes out: What Killed FreeBSD by Anonymous Coward · · Score: 0
    The End of FreeBSD

    [ed. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]

    When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.

    Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.

    FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.

    It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.

    So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.

    Discussion

    I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.

    From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.

    There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.

    Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.

    Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?

    Shouts

    To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.

    To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals.