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

216 of 460 comments (clear)

  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 Spunk · · Score: 1

      Truly an American icon.

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

      In Soviet Russia BSD FORKS YOU!

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

  2. 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: 1, Informative

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

    2. Re:Wonderful by gantrep · · Score: 3, Insightful
    3. 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.
    4. 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.
    5. 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
    6. 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. :)

    7. 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
    8. Re:Wonderful by Trolling4Dollars · · Score: 1

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

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

      Yes indeed, what would Windows be without FTP?

      </sarcasm>

      L.

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

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

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

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

    13. 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
    14. 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?
    15. 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
    16. 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
    17. 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.

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

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

      Ka-Ching!

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

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

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

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

    23. 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
    24. 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")
    25. 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.

  3. 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?
  4. 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
  5. 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 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.

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

      perl has been moved to ports in FreeBSD 5.

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

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

      as stated in my original comment.

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

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

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

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

  9. 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"
  10. You're thinking of DeadBSD, which was a short-lived flavor.

    --

    --
    the strongest word is still the word "free"
  11. 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 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.
    2. 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.

    3. 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 !
    4. 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?

    5. 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.
    6. 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!
    7. 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.
    8. Re:PORTAGE! by BigBir3d · · Score: 1

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

    9. 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
    10. 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
    11. 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.

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

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

      --
      http://astutehosting.com/
    13. 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.

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

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

    17. 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
    18. 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.
    19. 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.
  12. 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 dinivin · · Score: 1, Flamebait


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

      Dinivin

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

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

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

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

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

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

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

    9. 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)?

    10. 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!"
    11. 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.
    12. 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
    13. 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.

    14. 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)'
    15. 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.
    16. 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.

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

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

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

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

    21. 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
    22. Re:pkg could be a lot better by chainedtothemoon · · Score: 2

      Send Patches.

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

      Send patches and stop complaining.

    24. 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/
    25. 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.

    26. 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.
    27. Re:pkg could be a lot better by kwerle · · Score: 1

      Did. Rejected.

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

      Did. It was Rejected.

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

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

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

    33. 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
    34. 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?

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

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

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

      Dinivin

    37. 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.
    38. 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.
    39. 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.

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

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

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

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

    44. 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? :^)

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

    46. 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?
  13. 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 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.

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

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

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

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

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

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

  14. 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
  15. Re:wheres teh by vergil · · Score: 1
    Ask randy. He'll prob. post it on the mirrors anon ftp server.

    -V

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

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

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

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

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

  20. 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").
  21. No, no... by fm6 · · Score: 2, Funny

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

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

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

    5. 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.
  23. 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 nutznboltz · · Score: 2, Informative
    2. 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.
    3. 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

    4. Re:Paging Lorraine by jonabbey · · Score: 1

      Aw, that's cute.

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

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

    Define "best"

    In terms of BSD? MacOS X.

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

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

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

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

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

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

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

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

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

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

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

  31. *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.]

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

  33. hmm by luphus · · Score: 1

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

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

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

  36. 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!
  37. 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.

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

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

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

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

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

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

  43. 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
  44. 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.
  45. 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*

  46. 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
  47. 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/

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

  49. 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 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!
  50. 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!
  51. 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.

  52. Ugh. Bad! by grimani · · Score: 1

    Yeah, DragonFly was a horrible movie.

    And it was Kevin Costner, not Matt Dillon.

  53. It's official... by 42forty-two42 · · Score: 1

    "BSD is dying" is dying.

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

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

  57. 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)
  58. 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)
  59. 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.

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

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

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

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

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