Slashdot Mirror


Dynamic /bin support on FreeBSD

Dan writes "Gordon Tetlow has put together a patch to have /bin dynamically linked on FreeBSD. This is the first step on the way to having everything play nicely with ongoing work on getting NSS into the system. He cautions that the patch is preliminary and should probably be installed on a test machine."

54 comments

  1. -1 First Post by Anonymous Coward · · Score: -1, Troll
    It is official; Netcraft now confirms: *BSD is dying

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

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

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

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

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


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

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


    Fact: *BSD is dying

  2. hmm talkative bunch around here by shaitand · · Score: -1, Troll

    nobody has anything to say about this one?

    1. Re:hmm talkative bunch around here by Otter · · Score: 5, Funny
      The Slashdot writeup:
      Gordon Tetlow has put together a patch to have /bin dynamically linked on FreeBSD. This is the first step on the way to having everything play nicely with ongoing work on getting NSS into the system.

      The linked writeup:

      Gordon Tetlow has put together a patch to have /bin dynamically linked on FreeBSD. This is the first step on the way to having everything play nicely with ongoing work on getting NSS into the system.

      The message itself:

      I just hacked together support to have /bin dynamically linked. This is the first step on the way to having everything play nicely with nectar's work on getting NSS into the system.

      Not much more to add, is there? Except that this is the first step on the way to having everything play nicely with ongoing work on getting NSS into the system.

    2. Re:hmm talkative bunch around here by Unregistered · · Score: 1

      really i thought it was he first step on the way to having everything play nicely with nectar's work on getting NSS into the system. I guess i didn't really get it, then.

    3. Re:hmm talkative bunch around here by Anonymous Coward · · Score: -1, Offtopic

      Are you bright? witty? Do you have friends that laugh at your jokes? We at lrse hosting" are looking for a select few individuals to join our ranks at the internet's premier source of wit and style.

      Do YOU have what it takes? Register TODAY and FIND OUT!!!!

  3. Why? by aridhol · · Score: 5, Insightful

    Why do they need to change the established way things work (statically linked in /bin, dynamically linked in /usr/bin) to add a new system? Why not either adapt NSS or install it in /usr?

    --
    I can't say that I don't give a fuck. I've just run out of fuck to give.
    1. Re:Why? by Anonymous Coward · · Score: -1, Troll
      Would you like to read more trolls in your spare time? Sure, we all do. That's why we founded goatse info, where YOU get to rub elbows with all the ORIGINAL trolling greats!

      Would YOU like to:

      Trade segregation stories with Strom Thurmond ?

      Share stalking tips with Marko?

      Laugh at the preteen antics of Unterderbrucke?

      Keep up to date with the latest Perl stylings of Sexual Asspussy?

      Then come on down to Goatse Info. Where we're stretching the limits of crap flooding!

    2. Re:Why? by Neil · · Score: 5, Informative

      NSS (name service switch) provides "on the fly" reconfigurable name services - it is the mechanism that allows (for example) a Solaris or Linux machine to look up password entries in /etc/passwd, the NIS, LDAP, or whatever, depending on the contents of the "passwd:" line of /etc/nsswitch.conf.

      NSS works by dynamically loading the correct resolving routines from shared objects at run time. In contrast, a statically linked binary has "hard wired" name service lookup policies, which have been set by whatever library routines were statically linked into the executable.

      A system where some of the binaries obey preferences the admin expresses through /etc/nsswitch.conf but, say, /bin/ls doesn't is unlikely to be popular! :-)

    3. Re:Why? by R.Caley · · Score: 1
      NSS works by dynamically loading the correct resolving routines from shared objects at run time. In contrast, a statically linked binary has "hard wired" name service lookup policies, which have been set by whatever library routines were statically linked into the executable.

      This is, of course, not a sane justification. For example the resolver library quite happily obeys host.conf to control the same kind of decision about host name lookup dispite being statically linked into things. The highly sophisticeted answer is (shock) to have the library read the configiuration file.

      Just Say No to ls(1) not working because your library path is in a mess. Not to mention making life for rootkits one step easier.

      --
      _O_
      .|<
      The named which can be named is not the true named
    4. Re:Why? by antis0c · · Score: 1

      This is, of course, not a sane justification. For example not all resolver libraries bundled by default on the system, and applications certainly can't allow for all possible future resolver libraries. The purpose of NSS isn't just name resolution configuration, its to extend name resolution infinitely with new resolvers. Those resolvers become dynamic libraries which would have to be load, gasp, dynamically.

      If my /bin stuff is statically linked, and I install a new resolver, then what? No amount of configuration file reading is going to solve this one smart guy. I one: either have to recompile everything in /bin, or two: the things in /bin will need to be dynamically linked.

      --

      ..There's a-dooin's a-transpirin'
    5. Re:Why? by R.Caley · · Score: 1
      The purpose of NSS isn't just name resolution configuration, its to extend name resolution infinitely with new resolvers.

      How many times in the past 10 years have you desperately needed to have /bin/ls look up passwords in some bizzare new way?

      If my /bin stuff is statically linked, and I install a new resolver, then what? No amount of configuration file reading is going to solve this one smart guy. I one: either have to recompile everything in /bin,[...]

      I build world maybe 4 or 5 times a year. That's infinitely more often than I decide I need a new way to lookup passwords (since I never have).

      --
      _O_
      .|<
      The named which can be named is not the true named
    6. Re:Why? by antis0c · · Score: 1

      Well I'm glad your requirements permit that, so don't bother turning on the ability to dynamically link /bin. However not everyone's requirements are the same as yours so it's nice to have the ability. Also, Last time I checked, /bin didn't only contain 'ls'. Smart guy.

      --

      ..There's a-dooin's a-transpirin'
    7. Re:Why? by R.Caley · · Score: 1
      Also, Last time I checked, /bin didn't only contain 'ls'.

      So, how many times in the last 10 years have you needed to have /bin/cat look up passwords in a different way:-)

      --
      _O_
      .|<
      The named which can be named is not the true named
  4. Why by Anonymous Coward · · Score: 1, Insightful

    Who the hell needs this!?

    1. Re:Why by pmz · · Score: 5, Informative

      Who the hell needs this!?

      Some of the comments at the link in the article would suggest new or improved LDAP support. That's pretty significant. NSS stands for Name Service Switch, which allows alternative datasources for many of the databases traditionally stored in /etc.

      Solaris, for example, can use local files, DNS, NIS, NIS+, and LDAP for the hosts database. Minus DNS, these datasources can also provide the users database, the RBAC databases, the automounter configuration, bootparams, to name a few. To say it is useful is an understatement.

    2. Re:Why by Piquan · · Score: 3, Interesting

      That's good for who needs this. As for why, the NSS code works by dynamically loading the necessary backends. That's presumably why a dynamic /bin and /sbin are needed.

      So, my question is, why are /bin and /sbin traditionally static? Gordon's patch pretty much just sets them to dynamic linkage, and puts some libs and rtld in /lib. I'd think that if having /bin and /sbin dynamically linked was kosher, tho, that they would be. So I'm a little worried about this patch.

    3. Re:Why by pmz · · Score: 4, Informative

      So, my question is, why are /bin and /sbin traditionally static?

      Safety. When trying to repair a broken system, the dynamic linker and libraries become one less thing to worry about when the essential tools are staticly linked. I can't imagine that all the tools in /bin would need to be dynamic, so there's a good chance that many would remain static.

    4. Re:Why by aridhol · · Score: 3, Interesting
      /bin and /sbin need to be usable when only the root has been mounted. That means that they can't dynamically link to anything that's not in the root. That includes /usr/lib, which is where most dynamic linking takes place.

      I don't know why they needed to be completely static, as /lib still exists, so they should be linkable with libraries in there.

      It's probably just a safeguard against accidentally linking to a library in /usr/lib, just to have them fail when they're most needed.

      --
      I can't say that I don't give a fuck. I've just run out of fuck to give.
    5. Re:Why by KeyserDK · · Score: 1, Flamebait

      Linux has had this for ages?

      --
      still reading?
    6. Re:Why by JDizzy · · Score: 4, Informative

      Static because of the paranoia we have about libraries becoming corrupted. Consider this nightmare situation: Your computer panics, and in so it somehow gets a bit of filesystem corruption. You softboot, and discover that the FS corruption occurred in your libc and now all you dynamically linked executable that almost all of which link to libc are utterly useless. If fsck were dynamically linked it would be unable to examine/fix the file systems. That is why the /bin, and /sbin are all statically built, because these nightmares have happened before to some of use on other UNIX systems. WE do not dare to make that mistake on the most stable OS on earth! Also, what is somebody decided to put his libraries on /usr (mounted on its own filesystem), and have dynamically linked init on the root filesystem? The answer is the kernel wouldn't' be able to boot the system into single, or multi-user modes. There are many reasons to have static /bin and /sbin. On the other hand there are also a few reasons to not build them statically. Space is one major issue. The root filesystem would lessen in size dramatically if libc, and others, were not replicated into each executable. It would also open the door to more small version of FreeBSD that fit on floppies, and stuff. The only issue with dynamically linked /bin and /sbin is the need to fall back upon staticly built version of the same stuff in case your libs get corrupted. I think we might copy NetBSD and make a /rescue folder with crunched executables. Crunching is akin to compiling all your /bin and /sbin into one singulare binary file, and depending on how you invoke the binary, renders a different executable. Sorta like if I called crunch.bin as "fsck" it would bring the fsck code to the surface, or if the same crunch.bin were called as "ls" it would be ls. Inside the crunch.bin is dynamically linked , and archived executables. Hopefully that one file would not be damaged in fs corruption.

      --
      It isn't a lie if you belive it.
    7. Re:Why by pmz · · Score: 1

      Linux has had this for ages?

      I don't know much about FreeBSD and what it's current NSS capabilities are. This could be one of those things where Linux is stronger in some things but FreeBSD stronger in others. FreeBSD has a very good reputation, so I wouldn't expect the current limitations are show-stoppers.

    8. Re:Why by renehollan · · Score: 4, Interesting
      Hopefully that one file would not be damaged in fs corruption.

      Holy light bulb, Batman! (well, JDizzy, any way, to give proper credit). You've just given me an idea!!

      Given that some executables are more important than others in reparing broken filesystems, this situation particularly exacerbated with crunched binaries, why not add error correcting codes to them, and use inteleaving techniques to mitigate single block errors? Yes, they would grow, but not likely to the limit of multiple complete copies.

      Also, for sensitive dynamically linked libraries, perhaps the directory structure could be modified to have a common LD_LIBRARY_PATH for some system directories. Heck, never mind a mod: just make the loader sensitive to .ldpath symlinks in the directory of the executible.

      --
      You could've hired me.
    9. Re:Why by Anonymous Coward · · Score: 0

      I personally like the idea of an option for a static build at the cost of the NSS functionality. As for the addition of the /rescue directory for dynamic builds, that sort of sucks but may be the safest thing to do for people concerned about stability. The odd thing about FreeBSD is that dynamic libraries have rarely been a show-stopper for me. By contrast, Windows users are far too familiar with "dll-hell". I've also had trouble with shared library versions in Slackware, but then Slackware probably isn't worth anybody's time anymore.

    10. Re:Why by JDizzy · · Score: 2, Insightful

      It would seem feasible to put chrunched binaries into the kernel itself, but that would be nasty kernel bloat!

      --
      It isn't a lie if you belive it.
    11. Re:Why by sirket · · Score: 3, Informative

      The odd thing about FreeBSD is that dynamic libraries have rarely been a show-stopper for me.


      There are two reasons for this:
      • FreeBSD does not screw around with the libraries in between releases.
      • FreeBSD has always supported previous library versions.

      The first point is self explanatory. As for their library mecahnisms: The last dozen or so times I have installed Linux, I have had to go on a treasure hunt to find exactly the right version of libc for a given application (Oracle, whatever). With FreeBSD, the old libraries can (and often are) installed and built with the system so you never have to hunt for them. Simply edit /etc/make.conf and include the libraries you need and you are done. Period.

      FreeBSD libraries in make.conf also match the OS release so a 2.2 library is for a 2.2 kernel and program, etc. There is no guessing.

      -sirket
    12. Re:Why by renehollan · · Score: 1
      t would seem feasible to put chrunched binaries into the kernel itself, but that would be nasty kernel bloat!

      Yes, at some point, SOMETHING has to work O.K. in order for the system to boot. But, that something should be small enough and the rest reliable and redundant enough to permit the critical piece to either live in ROM, or floppy.

      Thought, bootable live CD distros are handy.

      Still, the one time you most desperately need to repair a sick system is also going to be the time you don't have your Swiss-Army utility CD.

      --
      You could've hired me.
    13. Re:Why by aphor · · Score: 2, Insightful

      This is significant in that
      1: the dynamic /bin utilities are JUST A TEMPORARY HACK, and that NSSWITCH will provide modular resolver support for important stuff like gethostbyname(3) among other things.
      In case you haven't noticed, we need a way (LDAP?) to resolve IPSec host certificates by hostname/IP, and DNS isn't doing the job... IMHO.. other people have other reasons for wanting this.
      2: dynamic linked /bin doesn't mean that everything is dynamic linked! You can static link everything, and dlopen(3) modules as you like.. falling back to a safe static function call if the .so is corrupted/gone. From FreeBSD-STABLE dlopen(3):

      ELF executables need to be linked using the -export-dynamic option to
      ld(1) for symbols defined in the executable to become visible to dlsym().
      3: if you use dlopen(3) you can choose to use the ldconfig(8) hints or you can build a special secure .so and open it directly, bypassing the hints.

      --
      --- Nothing clever here: move along now...
    14. Re:Why by JDizzy · · Score: 2, Interesting

      Right!

      I'm all for a really small /rescue partition with crunched init, fsck, mount, sh, and a few other essential tools to recover a broken system. The kernel could be altered in such a way that if it couldn't mount the root file system, it could mount the /rescue FS, and the fsck could happen. This would be a FreeBSD (shoot me) "safe mode" of sorts.

      If things were so broken that you couldn't fix them with the various built-in ways, a "rescue disk" (aka bootable cdrom, floppy) would have to be used to mount a pseudo root to in turn fsck the real root FS.

      --
      It isn't a lie if you belive it.
    15. Re:Why by realdpk · · Score: 1

      Sure. The executables are small enough you could probably store them in a directory on each of your slices and each of your partitions in the slices. I like the idea, and I've taken advantage of it before when I couldn't mount / but I could convince the kernel to mount /usr as / in single user.

    16. Re:Why by 42forty-two42 · · Score: 1

      Pssh. I'd just boot with linux init=/sbin/sash if my libs got corrupted.

    17. Re:Why by 42forty-two42 · · Score: 2, Informative
      The last dozen or so times I have installed Linux, I have had to go on a treasure hunt to find exactly the right version of libc for a given application
      There are only two versions of the libc ABI still widely used - libc.so.5 and libc.so.6. If your app requires a more specific version, override it. It'll work fine, IIRC.
    18. Re:Why by 42forty-two42 · · Score: 1
      As for why, the NSS code works by dynamically loading the necessary backends. That's presumably why a dynamic /bin and /sbin are needed.
      You could statically link all the libraries except libdl, if you really want static /bin and /sbin.
    19. Re:Why by KeyserDK · · Score: 1

      True, i've only used nss to play around with winbind
      in a win2k domain (samba3).

      Pretty odd seing windows usernames with 'ls -l' =)

      --
      still reading?
    20. Re:Why by parc · · Score: 3, Informative

      There is no /lib in current FreeBSD systems. You have to create one to go along with this patch, and several dlls will be placed in it.

      The only thing this realy gets you (other than NSS) is a smaller memory footprint at a (theoretical) cost in speed, as well as a little unsafeness in the case of one of your /lib libraries going bad.

      And you've got to remember not to put /lib on a non-root mounted partition. No big deal there.

    21. Re:Why by realdpk · · Score: 1

      Is glibc out of favor now then? I seem to remember having to have a few different versions of that laying around.

    22. Re:Why by 42forty-two42 · · Score: 1

      Dunno, I just have: -rwxr-xr-x 1 root root 1104040 Mar 21 11:19 /lib/libc-2.3.1.so lrwxrwxrwx 1 root root 13 Apr 4 16:19 /lib/libc.so.6 -> libc-2.3.1.so

    23. Re:Why by Anonymous Coward · · Score: 1, Informative

      Nothing in /rescue is dynamically linked:

      $ file /rescue/init

      /rescue/init: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for NetBSD, statically linked, stripped

      $ ls -l /rescue/init

      -r-xr-xr-x 127 root wheel 2564020 Mar 10 09:30 /rescue/init*

      So we (NetBSD) impersonate 127 programs in /rescue.

    24. Re:Why by CoolVibe · · Score: 1

      That's why, when this dynamic linking funnyness is going through, I want static versions of /bin and /sbin utils in /stand.

    25. Re:Why by JDizzy · · Score: 1

      it really should be an option! Your right!

      --
      It isn't a lie if you belive it.
    26. Re:Why by yanestra · · Score: 1
      Given that some executables are more important than others in reparing broken filesystems, this situation particularly exacerbated with crunched binaries, why not add error correcting codes to them, and use inteleaving techniques to mitigate single block errors? Yes, they would grow, but not likely to the limit of multiple complete copies.

      Bit failures are very rare when having filesystem problems. ECCs only help with (single or multiple) bit failures. They don't help if the whole block is destroyed (which it is, after the hardware's own error correction system has failed).
      Much more often it happens that the meta information of a filesystem got destroyed: You still have all your data, but you have no way to find them anymore.
      The most useful way of protecting your data is an identical copy of it. That means: Backup or mirroring or duplicating (as of IBM lingo).
    27. Re:Why by yanestra · · Score: 2, Insightful
      Sure. The executables are small enough you could probably store them in a directory on each of your slices and each of your partitions in the slices. I like the idea, and I've taken advantage of it before when I couldn't mount / but I could convince the kernel to mount /usr as / in single user.

      The problem is sitting in front of the terminal. It's absolutely no technical problem to have a partition somewhere containing all the data you need to get you system back to life if something very integral gets lost.
      The problems are:
      • deciding what is "all" you need,
      • deciding where to put it so it doesn't get damaged,
      • documenting the place so the person who needs it to fix a problem finds it,
      • keeping it sync'ed so it can be used,
      • but not too much sync'ed, so it doesn't copy your mistakes while administrating the system.

      In my opinion, imitating the laisser-faire of the Linux folks doesn't help in doing everyday's administration job.
      In my experience, the biggest problem with FreeBSD machines always has been finding some adequate tools to fix it when the system crashes after >2 years uptime- (Or do you have your FreeBSD 2.2 disk handy?)
    28. Re:Why by Eunuchswear · · Score: 1
      Solaris, for example, can use local files, DNS, NIS, NIS+, and LDAP for the hosts database.
      And on a SVR4 system (like, for example Solaris):
      $ ls -l /bin
      lrwxrwxrwx 1 root sys 8 Jan 4 2002 /bin -> /usr/bin
      So no problem with dynamicly linked /bin then :-)
      --
      Watch this Heartland Institute video
    29. Re:Why by Axello · · Score: 1

      Solaris, for example, can use local files, DNS, NIS, NIS+, and LDAP for the hosts database.

      I didn't know that. MacOS X 10.2 uses a similar mechanism to look up system information, like hostnames, printers, users, groups, mountpoints. The information can reside in BSD-like /etc/ files, LDAP, NIS or SLP databases, or obtained via Rendezvous or SMB. The system finds the information it needs in the selected items. See the utility "Directory Access" for more (albeit minimal) info.

  5. NSS = nsswitch by Anonymous Coward · · Score: 1, Informative

    I was wondering what it meant so I looked it up (http://www.freebsd.org/releases/5.1R/todo.html):

    "NSSwitch support -- Jacques Vidrine (nectar@) --
    Support for pluggable directory services using NSS, including adaptations of current directory services (local databases, NIS), and support for new services (LDAP, Active Directory, etc). This change has been committed, and requires broader testing."

    One thing I had noticed that in -current I had to use nsswitch.conf to have it use dns rather than looking up my home-net's hostnames in the host file. This was still host.conf in -stable.

    I believe other NIXes have had this for a long time, no?

  6. *BSD is ready for bin support by Anonymous Coward · · Score: -1, Flamebait

    Straight to the rubbish bin.

    1. Re:*BSD is ready for bin support by Anonymous Coward · · Score: -1, Offtopic
      Would you like to read more trolls in your spare time? Sure, we all do. That's why we founded goatse info, where YOU get to rub elbows with all the ORIGINAL trolling greats!

      Would YOU like to:

      Trade segregation stories with Strom Thurmond ?

      Share stalking tips with Marko?

      Laugh at the preteen antics of Unterderbrucke?

      Keep up to date with the latest Perl stylings of Sexual Asspussy?

      Then come on down to Goatse Info. Where we're stretching the limits of crap flooding!

  7. *BSD is dying by Anonymous Coward · · Score: -1, Flamebait
    It is official; Netcraft now confirms: *BSD is dying

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

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

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

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

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

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

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

    Fact: *BSD is dying

  8. Debate over dynamic /bin by evilcyber · · Score: 3, Informative

    As evidenced by the messages already posted, the Dynamic/Static debate is probably going to rage on here. To see how this will likely all play out, take a look at the NetBSD mailing list archives regarding the Pro's and Con's. You'll also see some of the solutions that came up to the various issues. NetBSD has already gone through this flame war when they commited a dynamic root to their tree. (Noted buried in one of the threads.)

    1. Re:Debate over dynamic /bin by Anonymous Coward · · Score: 0

      NetBSD went through the same "debate", with most of the objections coming from people who Fear Change, or had spurious objections which could be summarized as "Someone I know had a Linux/Solaris/... system with a fully dynamic userland and they got screwed once". NetBSD solved the latter problem by supplying a statically linked set of "recovery" tools under "/rescue".

      A fully dynamically linked system has many advantages, and the justification for retaining the "/bin and /sbin is statically linked, /usr/* is dynamically linked" split is spurious at best, as that configuration was really just a limitation when shared libraries were first implemented.

      Linux, Solaris and others have had a fully dynamically linked system for years, and its been successful overall, and the added enhancement of "/rescue" in NetBSD solves the main "how to recover" problem that the former have. If I recall correctly, part of the FreeBSD solution will be "/rescue" as well.

      Luke.

      (Color me biased; I did implement /rescue and the fully-dynamic changes in NetBSD ;-)

  9. Linux is dying by Anonymous Coward · · Score: -1, Troll

    It is official; Netcraft confirms: Linux is dying

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

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

    Redhat is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time Redhat developers Michael Evans and Timothy Buckley only serve to underscore the point more clearly. There can no longer be any doubt: Redhat is dying.

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

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

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

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

    Fact: Linux is dying

  10. Developer collapse: What Killed FreeBSD by Anonymous Coward · · Score: -1
    The End of FreeBSD

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

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

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

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

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

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

    Discussion

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

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

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

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

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

    Shouts

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

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

  11. Death Comes for *BSD by Anonymous Coward · · Score: -1, Troll
    So why now? Why did *BSD fail? Once you get past the fact that *BSD is fragmented between a myriad of incompatible kernels, there is the historical record of failure and of failed operating systems. *BSD experienced moderate success about 15 years ago in academic circles. Since then it has been in steady decline. We all know *BSD keeps losing market share but why? Is it the problematic personalities of many of the key players? Or is it larger than their troubled personalities?

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

  12. *BSD is dying by Anonymous Coward · · Score: -1, Troll
    It is official; Netcraft now confirms: *BSD is dying

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

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

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

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

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

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

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

    Fact: *BSD is dying

  13. Re: Or do you have your FreeBSD 2.2 disk handy? by Anonymous Coward · · Score: 0

    Using any boot floppy or CD and restore (8) your last backup?