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

Linux Filesystem Hierarchy (2004)

tldp.org

Post reply on HN
Print view View original

31–40 of 65 posts

Re: Linux Filesystem Hierarchy (2004)

#31

Post by Retr0id »

dun44 wrote: post #29
Retr0id wrote: post #19

Earlier quoted context omitted.

Could you elaborate? To me there seems extremely little overlap there (I'm familiar with both the procfs and linux's ptrace APIs, but not OpenBSD's ptrace).

Ptrace could an equivalent of what /proc was originally supposed to be, before it got repurposed for a bunch of sysctl-like purposes.

Interesting. I didn't know much about /proc's original design intent, and Wikipedia indeed says "the design of procfs aimed to replace the ptrace system call used for process tracing", citing https://lucasvr.gobolinux.org/etc/Killian84-Procfs-USENIX.pd... ("Processes as Files", USENIX 1984)

Re: Linux Filesystem Hierarchy (2004)

#32

Post by jmclnx »

mananaysiempre wrote: post #24
yrro wrote: post #12

Earlier quoted context omitted.

And to this day there is a mysterious 'bin' user on Linux systems that no one seems to use or know the purpose of. I wonder if another UNIX at some point added such a user in order to reserve '/usr/bin'...

At least one old UNIX book of French origin described the “bin” user as the owner of the common binary files on the system.

Yes, that was what I remember. I think having bin own the binaries was a kind of security check for suids. Avoids having a suid on a root owned binary. Plus you could use bin to install programs instead of root. Restricting who has root access.

But I suppose it did not work out as people were hoping and only added to admin costs.

Still, I was a bit annoyed when I noticed everything was owned by root as opposed to bin when I first installed Slackware decades ago. But I got over it :)

Re: Linux Filesystem Hierarchy (2004)

#33

Post by jmclnx »

yrro wrote: post #2

Hm, not to be confused with the Linux Filesystem Hierarchy Standard: https://refspecs.linuxfoundation.org/FHS_3.0/fhs.html ... which is referenced in hier(7) https://man7.org/linux/man-pages/man7/hier.7.html ... which is itself referenced in file-hierarchy(7) https://www.freedesktop.org/software/systemd/man/latest/file... (which is the first place I look things up these days).

Isn't Red Hat/Fedora ignoring these standards ? I noticed /run is not even mentioned. I wish Linux would go back to what I consider a sane Hierarchy :) Similar to what OpenBSD has.

These days seems Red Hat is deciding what the Hierarchy is instead of the community.

Re: Linux Filesystem Hierarchy (2004)

#34

Post by froh »

drexlspivey wrote: post #26

/bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin I never know where to put my own binaries so I just add my own at ~/bin. Some programs also add their own like ~/.cargo/bin what a mess

/usr/local is for all users of the multi-user server you're on, which you have installed locally.

~/... is for your personal user account

/bin (and /usr/bin, /sbin, /usr/sbin ) is for system software (from your distro of choice)

and /opt is for third party packages from third party providers

we tend to forget the "Unix" precursor of Linux comes from the data centre server world.

so "a mess" is relative

Re: Linux Filesystem Hierarchy (2004)

#35

Post by theandrewbailey »

drexlspivey wrote: post #26

/bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin I never know where to put my own binaries so I just add my own at ~/bin. Some programs also add their own like ~/.cargo/bin what a mess

I think the current standard for your own binaries is ~/.local/bin instead of ~/bin

https://specifications.freedesktop.org/basedir-spec/basedir-...

Re: Linux Filesystem Hierarchy (2004)

#36

Post by theandrewbailey »

froh wrote: post #34
drexlspivey wrote: post #26

/bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin I never know where to put my own binaries so I just add my own at ~/bin. Some programs also add their own like ~/.cargo/bin what a mess

/usr/local is for all users of the multi-user server you're on, which you have installed locally. ~/... is for your personal user account /bin (and /usr/bin, /sbin, /usr/sbin ) is for system software (from your distro of choice) and /opt is for third party packages from third party providers we tend to forget the "Unix" precursor of Linux comes from the data centre server world. so "a mess" is relative

> /bin (and /usr/bin, /sbin, /usr/sbin ) is for system software (from your distro of choice)

Don't most/popular distros symlink many of those together?

Re: Linux Filesystem Hierarchy (2004)

#37

Post by 2OEH8eoCRo0 »

jmclnx wrote: post #33
yrro wrote: post #2

Hm, not to be confused with the Linux Filesystem Hierarchy Standard: https://refspecs.linuxfoundation.org/FHS_3.0/fhs.html ... which is referenced in hier(7) https://man7.org/linux/man-pages/man7/hier.7.html ... which is itself referenced in file-hierarchy(7) https://www.freedesktop.org/software/systemd/man/latest/file... (which is the first place I look things up these days).

Isn't Red Hat/Fedora ignoring these standards ? I noticed /run is not even mentioned. I wish Linux would go back to what I consider a sane Hierarchy :) Similar to what OpenBSD has. These days seems Red Hat is deciding what the Hierarchy is instead of the community.

Fedora isn't the "community"?

Re: Linux Filesystem Hierarchy (2004)

#39

Post by cbm-vic-20 »

froh wrote: post #34
drexlspivey wrote: post #26

/bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin I never know where to put my own binaries so I just add my own at ~/bin. Some programs also add their own like ~/.cargo/bin what a mess

/usr/local is for all users of the multi-user server you're on, which you have installed locally. ~/... is for your personal user account /bin (and /usr/bin, /sbin, /usr/sbin ) is for system software (from your distro of choice) and /opt is for third party packages from third party providers we tend to forget the "Unix" precursor of Linux comes from the data centre server world. so "a mess" is relative

> we tend to forget the "Unix" precursor of Linux comes from the data centre server world.

Indeed. When I first encountered Unix back in the Dark Ages, not only was it common to be working on the same machine with a dozen other people simultaneously, we also had an environment where many programs were hosted on NFS filesystems, and we would have paths like /usr/nfs/alpha-dec-osf1 for Alpha binaries, /usr/nfs/decstation-ultrix for MIPS binaries, /usr/nfs/sparc-sun-solaris, etc. You would make sure your profile scripts included the right architecture path.

Even modern UNIXes (like Darwin/MacOS) include write(1), if you want to start a chat with someone else logged into your MacBook, I suppose.

Re: Linux Filesystem Hierarchy (2004)

#40

Post by Santosh83 »

DaiPlusPlus wrote: post #16
ahoka wrote: post #14

Earlier quoted context omitted.

With a proper redesign from scratch, it could have the same success and market share Haiku has.

Right, without back-compat, any system trying to gain marketshare is domed. ...but Linux has chroot, symlinks, hardlinks, and everything in-between - it's entirely possible to design a Linux environment where the clutter and warts of back-compat are only visible to the users and programs that need to see them.

GoboLinux attempts to reinvent the filesystem organisation for Linux while maintaining full compatibility.
Post reply on HN