Slashdot Mirror


NetBSD-current Is Now fully dynamically linked

jschauma writes "After quite some discussion on the current-users MailingList, Luke Mewburn announced that NetBSD-current is now, per default, a fully dynamically linked system. Please see his post to the list for details."

12 of 28 comments (clear)

  1. Blech by ctr2sprt · · Score: 4, Insightful
    I suppose the benefits will ultimately outweigh the costs, but it's just so much easier to have statically-linked /bin and /sbin programs. Means that no matter how badly I screw up an install of libc (for example), I'll at least be able to boot the system and the most important programs. Besides, it's so much easier to set up chroot jails when you don't need to worry what libraries /bin/sh and /bin/sleep require.

    Actually, I suppose it really is a good thing: the people who want this new behavior can have it, and the people who don't are likely to be the ones who'll make-world anyway. I ain't agin it, I'm fer it, and ignore all statements to the contrary!

    1. Re:Blech by forsetti · · Score: 3, Interesting

      Not being a NetBSD user, (but a BSD lover nonetheless) I'm not completely clear on this, but will this solve your disaster scenario?:

      ... from article ...

      Specific rescue tools are provided in /rescue, rather than overloading /bin and /sbin for that purpose.

      ...

      Are utilities in /rescue still statically linked?

      --
      10b||~10b -- aah, what a question!
    2. Re:Blech by Dahan · · Score: 3, Informative
      Are utilities in /rescue still statically linked?

      Yes, they are.

    3. Re:Blech by zulux · · Score: 2



      Specific rescue tools are provided in /rescue, rather than overloading /bin and /sbin for that purpose.



      Good God!
      Yuk! /res I could handle but /rescue - that's too many chars to type! What's next /my_single_user_mode_rescue_tools? ;)

      --

      Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.

  2. Re:NetBSD Project Resuscitation Plan by Dahan · · Score: 2
    Does flamebait count double or something?

    No, you're just stupid and can't read. Your post is currently scored at 1, with 1 Flamebait mod. But I'm sure you'll be at -1 soon enough.

  3. Get rid of /usr by amorsen · · Score: 3, Interesting
    Now, with everything dynamically linked and the rescue system properly moved to /rescue instead of polluting /, it is time to finally get rid of /usr -- or even better turn it back into the user directory it was always supposed to be. /usr/bin was invented way back when someone was running out of disk space in / and figured he could create a user account called bin (with home directory /usr/bin) and dump the extra binaries there. These days with logical volume management and overly large disks such hacks are no longer necessary.

    NetBSD has just removed the last excuse for having / separate. Only one more step, and the Unix file hierarchy is back to its root.

    --
    Finally! A year of moderation! Ready for 2019?
    1. Re:Get rid of /usr by castlan · · Score: 2

      Wow, that seems utterly sensible, and I'm officially piqued. Do you have any pointers for information regarding the intentions and history of the Unix file hierarchy? I've never actually considered the possibility that the tree could be trnsparent and sensible.

      It seems that the (Linux) FHS should really take this information into account. If not, perhaps a UNIX Purists' alternative to the FHS should be fleshed-out, where /usr supplants /home. If you can provide some credible links, I for one would fully agree with your stated position. Maybe I'd even compile the information into a centralized resource if one doesn't already exist.

    2. Re:Get rid of /usr by amorsen · · Score: 2

      All this historic stuff is mostly told in legends. Very little is documented, especially on the Web. You can find some things in the Google Web Directory or directly in The Unix Heritage Society. I have not had any luck finding references for file hierarchy stuff. If you like to read there is a nice list of books.

      --
      Finally! A year of moderation! Ready for 2019?
  4. Re:NetBSD Project Resuscitation Plan by photon317 · · Score: 2
    Point by Point:
    I have old sun boxes that run great on netbsd, but like shit on Linux.


    Old Sun hardware and NetBSD go great together I'm sure, they're both half-dead legacy stuff.

    FreeBSD is for new hardware, NetBSD bring a really modern incarnation of 4.4BSD to all hardware big or small, short or tall. I'm not a dumpster diver, but there are boxes that are useful but too old to upgrade, too useful to throw out, and not new enough to handle bloasted linux distros.


    Too old to upgrade and too useful to throw out? Really? You can buy a decent homemade PC clone for FreeBSD and/or Linux for $500 and blow the pants off of 20-40 older peice of crap machines like 680x0s and old Suns. So why bother? Throw them out. And not all Linux distros are bloated - try Gentoo.

    I also like NetBSD better than OpenBSD. If anything troll OpenBSD and trojaned tar theo the idiot. OpenSSH should be ripped away from those morons. Mr theo no package management.


    Theo does some good work, and I'd really like to see all of the other opensource projects audit their code like they did. I'm tired of hearing losers like you dump on OpenBSD when they finally have a hole. They're still outperforming [insert OS here]'s security by orders of magnitude. Their lack of package management and whatnot sucks, but it's still great for a dedicated firewall box that doesn't change much.

    And the EXT3 filesystem, and Reiser, is crap. If anything say, JFS or XFS.

    Also, the linux kernel is rarely seen in a 100% working sate. Seriously. Configure it, select everything and compile with the recommended compiler. See how many warnings and show stoppers you get.


    Sorry, Ext3 kicks ass. JFS and XFS are promising, but what I've seen of XFS has been very unstable. Reiserfs is buggy too. In any case, all I mentioned was ext3, and it does kick ass.

    I've seen linux kernels in 100% working states for years, all the way back to version 1.1.x. Turning everything on and compiling sounds like a pretty stupid idea, maybe you need to read the docs. A stable series kernel well-configured is a beatiful thing (outside the early 2.4 series, they went "stable" too early imho), and can run for years on end.

    At least with FreeBSD its clean, source is formatted readably, and has comments.


    Great, clean source with comments. My little ping monitoring package I wrote at work is clean source with comments, but that doesn't make it a domineering force in the world of OS's. Linux won the popularity contest early on, and hence has attracted the most attention and developers, which leads to a win in an opensource world unless the lead developers go crazy.

    --
    11*43+456^2
  5. Re:NetBSD Project Resuscitation Plan by photon317 · · Score: 2


    Still bugged, I'm now at "-1 Troll", with a total of two downmods (1 troll, 1 offtopic).

    --
    11*43+456^2
  6. Re:NetBSD Project Resuscitation Plan by be-fan · · Score: 2

    Sorry, Ext3 kicks ass. JFS and XFS are promising, but what I've seen of XFS has been very unstable. Reiserfs is buggy too. In any case, all I mentioned was ext3, and it does kick ass.
    >>>>>>>>>>.
    What have you seen of XFS? I've used it on several different Linux distros, and on everything from a 486/33 to a P4/2000. Never had a single crash, file corrupt, or whatnot. And the XFS file tools are indispensible. And from the posts on the internet, most people find XFS as rock solid as I do.

    --
    A deep unwavering belief is a sure sign you're missing something...
  7. Re:NetBSD Project Resuscitation Plan by photon317 · · Score: 2


    What I saw of XFS was I ran a 2.4.19 kernel with the "release" XFS source in it, and about my fifth reboot of the machine or so, it decided to hang when mounting my xfs root filesystem read-only, leaving me pretty hosed, had to boot back off a cd.

    --
    11*43+456^2