61–70 of 158 posts
The FHS (Filesystem Hierarchy Standard) [1] is the go-to reference for this sort of thing. It explains that `/bin` is for binaries that are essential before other file systems are mounted (e.g. in single user mode), and `/usr/bin` is for "most user commands" (all others). This allows you to keep a minimal local filesystem containing only the binaries needed for init to get the system running, and then `/usr` can be m…
Earlier quoted context omitted.
It annoys the hell out of me that people are still imposing the 486-era 1024Cyl and 8GB limitations in 2012. ArchLinux, for example, still really, really wants you to make a /boot.
There are plenty of good reasons to make a /boot. Encrypted laptops for example.
Earlier quoted context omitted.
It annoys the hell out of me that people are still imposing the 486-era 1024Cyl and 8GB limitations in 2012. ArchLinux, for example, still really, really wants you to make a /boot.
There are plenty of good reasons to make a /boot. Encrypted laptops for example.
Wow. As someone who was there (I know dating my self here) reading this is kind of like that scene in Sleeper where the person from the future is trying to understand artifacts from the past. So during the BSD / System V merge (project Lulu at Sun) the /opt filesystem was introduced as a way to keep 'packages' separate from 'system'. The difference between /bin and /sbin was that sbin was 'static-bin' which is to say…
It drives me crazy every time I'm on a Linux system and ifconfig is in /sbin, and not on users' PATH, even though the no-argument form works perfectly fine as a user.
And why / /usr split still makes sense: If it's needed to boot, it goes in root: boot images (including root filesystem) can be initrds, bootp images, flash sticks, or other similar tools. Maintaining the discipline of keeping what you need in / and what you don't need to boot in /usr helps when you're trying to minimize boot images, troubleshoot, and/or just simply keep things comprehnsible. Different partitions can…
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…
http://www.linuxtopia.org/online_books/linux_beginner_books/...
Though static-linking was originally used for a different purpose, today statically linked binaries make my life easier, and it has nothing to do with space constraints.
Paths are a pain in the neck. It feels like 90% of the work we have to do at the prompt is typing/automcompleting paths, or symlinking or setting env variables to deal with paths.
We certainly need a way to differentiate "system" stuff from "user" stuff. And on BSD, one can do this with the mtree spec files. mtree is one of my favourite utilities. One that is of course absent in Linux.
Linux could never have an mtree because its userland development has been too haphazard. Moreover, different "distros" are always pushing for idiosyncratic changes. The goalposts move much more frequently than with BSD.
Moving goalposts are also a pain in the neck.
Wow. As someone who was there (I know dating my self here) reading this is kind of like that scene in Sleeper where the person from the future is trying to understand artifacts from the past. So during the BSD / System V merge (project Lulu at Sun) the /opt filesystem was introduced as a way to keep 'packages' separate from 'system'. The difference between /bin and /sbin was that sbin was 'static-bin' which is to say…
No, it really has nothing to do with that at all. Linux can boot in pretty much the same way the genetic Unixes do, and in fact did for a long time. initrd and then initramfs came later and took some time to become widely used. Historically, Linux just mounted whatever filesystem the bootloader told it to as /, and executed init, which usually followed either a BSD or System V model, depending on distribution.
Linux evolved. Lots of things evolved. The filesystem layout, unfortunately, has merely become more chaotic.
Earlier quoted context omitted.
Every one of those paths I mentioned are paths I have encountered during my use of various unix distributions since 1991 (Solaris was the worst offender). And that's not even the complete list. I gave up trying to predict where software would install to a long time ago. My point is that what "makes sense" is subjective. Each developer/distro manager who made one of those paths thought to himself "it makes perfect sen…
Your encountering them doesn't make them part of FHS. Their being included in FHS does.