/opt/local is already used (by MacPorts).
Understanding the bin, sbin, usr/bin , usr/sbin split
101–110 of 158 posts
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#102Glorious. More history bits like this please. At the same time, makes you think about dropping FHS .. yeah I said it.
A distribution that does just that is NixOS ( http://nixos.org/nixos/ ). It has to, because it's purely functional (new stuff shouldn't overwrite any of the old stuff) and it has to support several different versions of the same package being installed at the same time. It is awesome, especially the easy rollback and that you can specify an entire system with a recipe. Still, it feels strange for us who are used to m…
Funny I just installed my first nixos yesterday. They indeed can move away from FHS even if they support it.
As said before GOBO does that too; there was a handful of distros at max.
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#103Earlier quoted context omitted.
> Oh man... if only we had all statically-compiled Linux systems these days. Would you mind buying me a memory upgrade when this happens? I'll need one.
I honestly have no clue how much extra memory this would cost. I can see it being a big issue on embedded systems. But, with 512 megs being considered very low on modern desktop/server systems, I always thought the vast majority of recent memory use was data rather than code. Roughly how many processes are you running? Can anyone give a wild-assed guess how much memory it take to boot and load gmail in FireFox on a s…
You shouldn't see that much difference, at least on a system designed for static linking (modern GNU/Linux is explicitly not such a system, see http://www.akkadia.org/drepper/no_static_linking.html). There's still quite a bit of potential for interprocess resource-sharing.
If you somehow managed to get a statically linked Firefox (I think it would be very difficult, given the degree to which Drepper has abandoned the idea) on a modern Linux system, though, the resource usage would admittedly probably be quite impressive.
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#104Oh man... if only we had all statically-compiled Linux systems these days. Sure it'd be a pain to deploy changes in libraries, but less dependency-breaking consequences means you can push a patch to a single application without testing a whole suite of dependent apps. The really hacky solution to that seems to be building versioned packages in versioned directory paths (e.g. "/opt/lib/db/4/4.2/4.2.52/libdb.so") and m…
While not exactly what you are proposing, NixOS does something similar. It's not perfect, but it's far from hacky.
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#105The Fedora changes are bikeshedding. They start with wanting to change something, and then find a justification. Why not just put all the executables files in /Program Files/? All this to save a few bytes in $PATH, to avoid problems with systemd, and to avoid fixing udev.
That would break compatibility with a lot of existing scripts, which look for things in /bin, /lib, /usr/bin etc.
There are specific reasons why having a single mount point for all OS-provided binaries is a good idea, for example because maintaining a split that differs across distros and unixes is a maintenance nightmare. The main counterargument -- that it is desirable to have a minimally functional system without /usr mounted -- has been obsolete for years.
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#106Earlier quoted context omitted.
home directories iirc, lived in /u (/usr these days)
Depended completely on the site. The first UNIX machine I worked on (ca 1985-1986) still was putting them in /usr for instance. There were certainly sites that used /u for what is now commonly /home (or /export/home on Solaris, /Users on OS/X, ...) This was not something that predated "/usr" though: /usr was already added back in the early 1970s (the linked article was correct about that, although it got many other d…
/usr was originally only for home directories [...] /usr/bin popped up
I wonder if this is the origin of the 'bin' user as well, because that's a design decision that never seemed to make any sense.
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#107Earlier quoted context omitted.
For those who haven't seen the proposal for the / /usr merge: "Fedora (and other distributions) have begun work on getting rid of the separation of /bin and /usr/bin, as well as /sbin and /usr/sbin, /lib and /usr/lib, and /lib64 and /usr/lib64. All files from the directories in / will be merged into their respective counterparts in /usr, and symlinks for the old directories will be created instead" http://www.freedes…
Thanks. These seems like one of those things that while it might be sensible, wouldn't provide much of a win, so why bother with the mess?
Probably because fedora has a six month release cycle and they feel the need to make some kind of revolutionary change on every release.
Of course, /bin will never be removed since there are millions of scripts depending on /bin/sh in the wild. So they'll basically end up having to maintain this symlink spaghetti for a long time.
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#108As someone who comes from a Windows (and further-back, OS/2) background, the directory structure of -nix systems is baffling. It's really interesting to read the background on why it came to be structured a certain way, but I feel that the current structure doesn't jive with how we use computers in a modern way. The structure seems to be optimized for single-file command-line based applications and are not well suite…
For future reference, you can list all of the files associated with a package using this: dpkg-query --listfiles package-name Or use Synaptic's 'Installed Files' tab in the package detail dialog.
I often find myself looking for the opposite mapping; to which package does /usr/share/foo/bar.blob belong?
$ dpkg --search /etc/apt/
debconf, apt: /etc/aptRe: Understanding the bin, sbin, usr/bin , usr/sbin split
#109Earlier 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.
Why? What exactly does ip bring to the table that ifconfig doesn't have? Why am I required to learn YET another tool to do something that ifconfig has no problems doing. On linux to configure a wireless device you have iwconfig and ifconfig. And you have to use each in a different order to get it work. Whereas in FreeBSD I have ifconfig and it does all of it.
Ifconfig will fail completely in some cases.
Eg, an alias on a vlan on a bond.
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#110Earlier quoted context omitted.
For future reference, you can list all of the files associated with a package using this: dpkg-query --listfiles package-name Or use Synaptic's 'Installed Files' tab in the package detail dialog.
I often find myself looking for the opposite mapping; to which package does /usr/share/foo/bar.blob belong? $ dpkg --search /etc/apt/ debconf, apt: /etc/apt
I prefer "apt-file search" which is much faster than "dpkg -S" at the cost of some disk space and having to periodically do "apt-file update".