Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding the bin, sbin, usr/bin , usr/sbin split

lists.busybox.net

Post reply on HN
Print view View original

121–130 of 158 posts

Re: Understanding the bin, sbin, usr/bin , usr/sbin split

#121

Post by mhurron »

X-Istence wrote: post #73
mhurron wrote: post #60

Earlier quoted context omitted.

You can make a good case that /usr/local should be separate from /usr, where as /usr belongs on the same partition/slice as / on FreeBSD. /usr is the whole system as maintained by FreeBSD, where as /usr/local is where your ports are installed. /usr is going to grow slowly, /usr/local could get huge. Separate /usr/local out from /usr on a different disk. FreeBSD recommends softupdates on all filesystems, including /.…

The defaults for FreeBSD are / as UFS2 with no softupdates, see picture 2-19 in http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/in... for an example.

It has been a few months since I had to administer a FreeBSD machine, but personally since at least FreeBSD 7 I have had softupdates on on /.

The installer may still not have softupdates on, but the installer is very very conservative about defaults, and probably hasn't changed since, well ever. However, from the handbook http://www.freebsd.org/doc/en/books/faq/disks.html#SAFE-SOFT...

"9.4. Which partitions can safely use Soft Updates? I have heard that Soft Updates on / can cause problems.

Short answer: you can usually use Soft Updates safely on all partitions.

Long answer: There used to be some concern over using Soft Updates on the root partition. ..."

Re: Understanding the bin, sbin, usr/bin , usr/sbin split

#122

Post by vacri »

comex wrote: post #83
vacri wrote: post #65

Earlier quoted context omitted.

use 'ip' instead, ifconfig is deprecated. 'ip addr show' is the simple replacement for 'ifconfig', but ip is pretty flexible in what it can do.

I don't know if I'd prefer a non-portable way to do the same thing :) Does 'ip' have a form that just prints the current addresses without all the surrounding cruft? That would be pretty useful for the occasional shell script.

'ip addr show dev eth0' will show you the cruft just for eth0, but I'm not sure if there's a way to limit it to just listing the ipv4 or v6 addresses.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split

#123

Post by vacri »

DrCatbox wrote: post #116
vacri wrote: post #67

I've been liking the new location /srv, where you stick things that are custom to that machine. No more trying to guess where the previous admin thought files should go (/usr/share? /usr/local? /usr/foo?). http://www.linuxtopia.org/online_books/linux_beginner_books/...

You dont stick things that are custom to that machine in /srv, thats not what the article you linked to says. Its for serving using various services, so you would have /srv/http /srv/ftp and so on, you dont put packages/programs into /srv

Looks like I might be misusing it then. I've been migrating some old spaghettied servers to single-use VMs recently, each server has had almost half a dozen admins all with their own weird ideas. The idea of saying 'hey, all the custom stuff is in this directory' for future admins is seductive. Basically I'm replacing half a dozen admins' peculiarities with one admin's peculiarity...

Re: Understanding the bin, sbin, usr/bin , usr/sbin split

#124

Post by mrud »

vacri wrote: post #122
comex wrote: post #83

Earlier quoted context omitted.

I don't know if I'd prefer a non-portable way to do the same thing :) Does 'ip' have a form that just prints the current addresses without all the surrounding cruft? That would be pretty useful for the occasional shell script.

'ip addr show dev eth0' will show you the cruft just for eth0, but I'm not sure if there's a way to limit it to just listing the ipv4 or v6 addresses.

just add -4 or -6:

  ip -4 addr show dev eth0 or ip -6 a s eth0

Re: Understanding the bin, sbin, usr/bin , usr/sbin split

#125

Post by cturner »

I think that the motivations for shared libraries was once valid but these motivations are obsolete, and they're destructive. I think there's a lot to be said for the simplicity and reliability of static linking.

There is an argument that it's nice to be able to upgrade libraries and have everyone pick them up, but in practice that's mostly a myth because such upgrades are vulnerable to nasty small failures. Another argument is that is saves hard disk space - not an issue these days (perhaps it is in a small number of embedded systems still).

Any good counters to that?

Update: thanks for response. I found the link to the Drepper article linked elsewhere in this thread v informative also.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split

#126

Post by sirclueless »

snowape wrote: post #99

Why did the Fedora team choose to move /bin -> /usr/bin etc instead of moving stuff out of usr into root (/usr/bin -> /bin)? What is the point of having a usr directory when there is no separation between stuff in usr and stuff in root?

If you want to mount system directories read-only or over a network, it's easier if you put them all in a single mount point. This way you can just mount /usr, instead of having to mount /bin, /lib, and /lib64 this way.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split

#127

Post by Derbasti »

cturner wrote: post #125

I think that the motivations for shared libraries was once valid but these motivations are obsolete, and they're destructive. I think there's a lot to be said for the simplicity and reliability of static linking. There is an argument that it's nice to be able to upgrade libraries and have everyone pick them up, but in practice that's mostly a myth because such upgrades are vulnerable to nasty small failures. Another…

Well, consider GUI libraries like Qt, GTK or Cocoa. Cocoa in particular does not have any concept of a user modifyable "theme" or "style". However, it changes its looks with OS upgrades and all GUI applications change with it.

With static linking, that would clearly not happen.

Also, these libraries/frameworks are not exactly small, not even for todays hard drives, so the de-duplication does make some sense (and that is not factoring in the smaller size of SSDs). That said, I guess you could make this into an argument for filesystem level deduplication instead of dynamic linking.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split

#128

Post by snowape »

sirclueless wrote: post #126
snowape wrote: post #99

Why did the Fedora team choose to move /bin -> /usr/bin etc instead of moving stuff out of usr into root (/usr/bin -> /bin)? What is the point of having a usr directory when there is no separation between stuff in usr and stuff in root?

If you want to mount system directories read-only or over a network, it's easier if you put them all in a single mount point. This way you can just mount /usr, instead of having to mount /bin, /lib, and /lib64 this way.

So /usr is now the directory for where all programs installed by the system or package manager gets installed. That actually does make sense.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split

#129

Post by elehack »

lmm wrote: post #113
X-Istence wrote: post #75

Earlier quoted context omitted.

/usr is maintained by the OS, and contains stuff that isn't required for boot but to round out the system. /usr/local is where local modifications to the OS go, these can be site-wide (company wide) and can be hosted on NFS for example for network boots. User installed stuff belongs in /usr/home/ /*. Users shouldn't have root access to install stuff in /usr/local.

Side point: it really bothers me that on freebsd the ports system takes over /usr/local. I expect /usr/local to consist of things that I as admin have installed by hand, and nothing else.

Agree totally.

NetBSD uses the more sensical /usr/pkg for package-managed software, leaving /usr/local for the admin.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split

#130

Post by Symmetry »

cturner wrote: post #125

I think that the motivations for shared libraries was once valid but these motivations are obsolete, and they're destructive. I think there's a lot to be said for the simplicity and reliability of static linking. There is an argument that it's nice to be able to upgrade libraries and have everyone pick them up, but in practice that's mostly a myth because such upgrades are vulnerable to nasty small failures. Another…

Hard disk space isn't an issue, but internet bandwidth is. Also, being able to fit a fairly complete operating system on a CD.
Post reply on HN