14 ms·

sbin split (2010)

534 points by taubek 5y ago

ibejoeb 5y ago
...cache invalidation, naming things, filesystem hierarchy Taxonomy, in general, consumes and perplexes us. It only seems to get worse as time goes on. Look at your typical react app...
kuharich 5y ago
Past comments: https://news.ycombinator.com/item?id=3519952 https://news.ycombinator.com/item?id=3519952, https://news.ycombinator.com/item?id=11647304 https://news.ycombinator.com/item?id=11647304, https://news.ycombinator.com/item?id=22614731 https://news.ycombinator.com/item?id=22614731
gjadi 5y ago
> GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke. That's one way to make new friends :)
szastamasta 5y ago
I must say I really like the MacOS idea, that every app has it’s own folder. I think that apps scattered through filesystem are not a good idea at all. Maybe they should symlink executables to /bin and shared libraries to /lib. Also everything that is needed to boot should probably be in a sealed readonly filesystem or binary anyway. I think we have made a mess with unix filesystem stricture and it really needs to be simplified.
- cassepipe 5y ago
  You should really check out GoboLinux then : https://gobolinux.org/ https://gobolinux.org/
- jmbwell 5y ago
  macOS also does a more strict but tidier hierarchy, grouped into "domains" … /System/* is "stuff from Apple" (including /System/Library, etc.), / is for "stuff on the local machine" (/Applications, /Library, etc.), and then each user can have their own hierarchy in their user directory (~/Applications, ~/Library, etc.). Of course, the "stuff from BSD" winds up in /bin and /usr/bin anyway, so it's still a mess. https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW14 https://developer.apple.com/library/archive/documentation/Fi...
cassepipe 5y ago
Anyone ever tried to run GoboLinux as a sysadmin ? What was the experience like ?
betagammaxyz 5y ago
Path dependence -- just like the default 80x24 character terminal window size that goes back to the VT100 of 1978. A curious historical hangover. GUI defaults are obviously less consequential, though.
basemi 5y ago
I think modern distros have resolved the issue . For example this is void-linux: $ ls -ld /bin /sbin /usr/bin /usr/sbin lrwxrwxrwx 1 root root 7 May 3 00:20 /bin -> usr/bin lrwxrwxrwx 1 root root 7 May 3 00:20 /sbin -> usr/bin drwxr-xr-x 1 root root 39444 May 10 18:41 /usr/bin lrwxrwxrwx 1 root root 3 May 3 00:20 /usr/sbin -> bin Ubuntu, Debian and RHEL, on the contrary still splits up: $ ls -ld /bin /sbin /usr/bin /usr/sbin lrwxrwxrwx 1 root root 7 set 25 2021 /bin -> usr/bin lrwxrwxrwx 1 root root 8 set 25 2021 /sbin -> usr/sbin drwxr-xr-x 2 root root 69632 mag 11 14:00 /usr/bin drwxr-xr-x 2 root root 20480 mag 11 13:33 /usr/sbin
b65e8bee43c2ed0 5y ago
- `/home/username/bin` and for binaries installed under that specific user - `/bin` for everything except the above, including binaries installed under root - same pattern for configs, auxiliary and transient stuff change my mind
Danielle69 5y ago
[dead]
deergomoo 5y ago
> Then somebody decided /usr/local wasn't a good place to install new packages, so let's add /opt! I'm still waiting for /opt/local to show up... Heh, MacPorts installs stuff to /opt/local on the Mac.
mc4ndr3 5y ago
TL;DR. Storage used to be so expensive per gigabyte that binaries were arbitrarily categorized into distinct file system partitions. Nobody ever bothered to revisit this and merge back to just /bin. Also, why the heck was $HOME/bin never a thing?
michaelcampbell 5y ago
One of my first exposures to *nix in the corporate world was on a Sun Sparc, running at the time SunOS 4.something. The sysadmin at the time told me the /sbin versions of things where for statically linked binaries that didn't need any other FS' mounted to read any dynamic libs. I'm not asserting it was right, but just another view into "tribal knowledge" vs "urban legend" vs ???
jlundberg 4y ago
For those who liked this text and want to read more from the author, have a look at his busybox replacement toybox: http://landley.net/toybox/ http://landley.net/toybox/
sdgdfgsfdfgsdfg 5y ago
Its funny how many quirks of UNIX/C/etc go back to the severe limitations of early day computers. Which is why using modern languages like Rust and its compiler really feels like coming up for air.
- alecmg 5y ago
  I think Windows is even more permeated with legacy Off the top of my head: Nobody questions why main drive is C:, remnant of [an] early computer having two floppy (not sure) drives on A: and B: Or more recent - C:/Windows/System32 holds 64 bit executables; 32 bit exectuables live in C:/Windows/SysWOW64
  - indrora 5y ago
    Fun fact this is the second time Microsoft have pulled this. The first time was for legacy 16 bit Windows applications running on Windows NT. Since most people have moved to 64bit processors, it has been shuttered. https://en.wikipedia.org/wiki/Windows_on_Windows https://en.wikipedia.org/wiki/Windows_on_Windows
  - DavidVoid 5y ago
    As a user, the main one that really annoys me is the "Program Files" vs "Program Files (x86)" split. I can kinda see why they have to be different folders, but why did they have to name it "... (x86)" instead of "... (32bit)"? You can call the 64 bit architecture x64 all you like, but it's still using the x86 instruction set and it's frequently referred to as x86-64, so naming that 32 bit only folder "... (x86)" will just make things more confusing than they should be.
    - jeroenhd 5y ago
      I think this was because at the time of picking the name, Windows with a working 65-bit Windows-on-Windows subsystem only ran on x86 and x64, so the naming made sense. DEC builds weren't relevant at the time and ARM was still far away from gaining 64-bit support. There was a 64 bit version of XP for Itanium but that couldn't run x86 code natively. It'll be interesting to see what Microsoft will do if Windows on ARM actually takes off. As far as I know, the current translation layer can't execute amd64 on ARM, only x86. Will we see Program Files, Program Files (x64) and Program File (x86)? It would make sense; have the redirection system ready to go and the naming scheme would also make perfect sense. ARM doesn't need a special 32-bit folder because there's no notable 32-bit vs 64-bit clash; nobody is migrating upgrading their Windows CE device to Windows 11, after all.
smartmic 5y ago
> Embedded guys try to understand and simplify... It is indeed true that when you have limited resources, simpler - in the sense of better, more beautiful - solutions often emerge.
Waterluvian 5y ago
Speaking of this, is there a good resource that elegantly but succinctly describes the intent of each of linux’s (Unix’s?) root directories? I’ve spent like eight years with Ubuntu and realize it’s all symbol manipulation to me. I learn what is and goes where but all in practice and never because I understand the semantics.
- wkz 5y ago
  https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf
- faho 5y ago
  You probably have a "hier" man page on your system. https://man7.org/linux/man-pages/man7/hier.7.html https://man7.org/linux/man-pages/man7/hier.7.html Also systemd has a "file-hierarchy" man page for its understanding of the hierarchy, which includes e.g. its use of /run and which directory can be read-only - https://man7.org/linux/man-pages/man7/file-hierarchy.7.html https://man7.org/linux/man-pages/man7/file-hierarchy.7.html
  - Waterluvian 5y ago
    Aha! Thanks so much.
- drothlis 5y ago
  Many distros, including Debian & Ubuntu, have merged /bin and /usr/bin, with symlinks for backwards compatibility: /bin -> /usr/bin (and similarly for /usr/lib etc). https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
  - happymellon 5y ago
    Did Debian do it? I thought there was internal conflict in the project whether it would happen, and has been for a decade.
heinrichhartman 5y ago
Now that we understand this can we please put all system tools into /bin? Disk space for binaries has not been a problem for decades now.
- pilif 5y ago
  having the system mounted in its own sub directory rather than be spread over multiple directories (there's /usr/bin, /usr/share, /usr/lib, etc) has the advantage that a single read-only mount can mount the whole OS. Having the OS mounted read-only provides some security benefits. The other option would of course be to have / mounted ro and then have rw mounts in /home, /etc, /var and /tmp, but this is more complicated than a a rw / and a ro /usr
  - andrewshadura 5y ago
    While that's true, these days initramfs is what performs this job.
- hulitu 5y ago
  It depends. Fsck is slow on big hard drives. Also separating data from programs is a good idea.
- captainmuon 5y ago
  Disk space was not really the issue. Back in the day extra partitions would actually mean you waste space. It's more efficient to put them on one partition. The issue is organisation. There is already so much junk in the bin folders. I think it would be much neater to further split the bins into various categories: "shell tools" like ls, [, echo; "applications" like firefox, inkscape, "helpers" like gnome-settings-daemon, ... There is no need to show weird daemons when pressing TAB in bash, and there is no need to show `ls` when picking an application via a GUI.
  - pmoriarty 5y ago
    The problem with that suggestion is that some things belong in more than one category. A much more flexible way of organizing is to use tags. This way a file could have more than one tag. Having a tag hierarchy would be even better, so you can browse down the hierarchy as you'd traverse the tree structure of a typical file system (with the added advantage of allowing a single file to have multiple categories that it could be in).
j16sdiz 5y ago
> There's no actual REASON for any of it anymore. No reason to do it on embedded system. Lots of backward compatibility reason on servers/desktops.
- pilif 5y ago
  it's my understanding that most distros by now have moved to have their stuff in /usr, though there might still be backwards compatibility symlinks of course.
  - hulitu 5y ago
    Good luck mounting /usr when mount is in /usr/bin. Not everybody uses a ramdisk to boot the system.
    - pabs3 5y ago
      Not using an initrd is unsupported on lots of distros these days.
      - blueflow 5y ago
        You mean initramfs, initrd is unsupported on lots of distros these days.
        pabs3 5y ago
        Right.
    - colonwqbang 5y ago
      Just don't put /usr on its own partition. What is the point anyway after we have merged /bin into /usr/bin, /lib into /usr/lib etc. Just put your operating system on a single partition and be happy.
- usrbinbash 5y ago
  Backward compatibility can be ensured with a couple of symlinks.
EdSchouten 5y ago
I once sent out a proposal on the FreeBSD lists to merge /sbin with /bin, and /usr/sbin with /usr/bin. People were concerned that this would slow down the system, due to PATH lookups taking longer. Even when I demonstrated the opposite was true (it being faster due to fewer directories needing to be scanned), I wasn't able to get consensus. What a shame.
- cryptonector 5y ago
  A merge needs to be done carefully for backwards compatibility. You could move all the things in /bin and /sbin to /usr/bin and /usr/sbin, then leave behind links (symbolic or hard). Since everyone ends up having /bin and /usr/bin in PATH, this merge makes a lot of sense from a performance point of view. Merging bindirs and sbindirs is a touchier topic. Many things in sbindirs should have been in bindirs all along, and many should move to libexecdirs, but some should stay behind so that privileged users can keep sbindirs out of PATH when they're not wearing an admin hat.
- gorgoiler 5y ago
  What about /usr/games! Insensitive clod!
  - tremon 5y ago
    /usr/games should never have existed in the first place, imnsho. If it's a small game, its binary could just have been put in /usr/bin. If it's a large game, it probably should be in /opt/$game.
    - bityard 5y ago
      It's a historical unix thing. Things in /usr/games (which were not all games) were frivolous and not essential to the OS, and were distributed as a separate tape or archive so that admins could easily choose whether or not to install them.
      - jmclnx 5y ago
bjourne 5y ago
Roughly the same reason why dotfiles became a thing on Unix: https://linux-audit.com/linux-history-how-dot-files-became-hidden-files/ https://linux-audit.com/linux-history-how-dot-files-became-h... Fortunately more and more software is putting its config in ~/.config/ rather than dumping it all over users' home directories.
- sph 5y ago
  AFAIK the XDG spec isn't a thing on macOS, so you get those CLI utilities written by devs on their fancy Macbook Pro that pollute your home directory, such as Deno, Doom Emacs, Elixir, Rust/Cargo, Kubernetes, npm, vscode, etc.
  - jeroenhd 5y ago
    I can understand devs not using the right circumstances if their platform of choice doesn't come with an easy way to determine the right directory to put stuff in, let alone create it if necessary. What I really want is an API that does "create/open/delete a file/directory for the relevant configuration/cache/resources store", be it user configured or platform default. What I get is an external package that gives me a list of potential storage locations (of which I'll probably just pick the first) that may or may not be actual directories on the system which I may or may not have access to touch files in. Some devs are kindly reminded that there's a spec for these things but often it's too late as data is already in specific paths that users may have come to know. That way you end up with paths that get set by environment variables where you have to tell each and every program where to put their crap. Other programs don't care enough to implement the standards (like Firefox; the bug report about XDG is old enough to vote [1] and it's still not implemented fully). Kubernetes has an open issue for its client that only ever gets bumped. Even worse are devs that are reminded of standards like XDG and then decide to give everyone the middle finger. Snap is one of them, not only is the data directory hard-coded, it's hard-coded lowercase unlike every other standard directory on Canonical's distribution itself! Snap's biggest competitor, Flatpak, decided not following the standard is not a problem [3]. At least it's special snowflake folder starts with a period so that it's hidden by default, I suppose. Even Bash doesn't support XDG [4] because not everyone uses Linux (and apparently no effort should be made to support OS specific standards?) with the suggestion closed as won't fix. Many tools that do support XDG only care about their own standards, of course; Windows has had SHGetKnowlFolderPath since Vista, replacing SHGetFolderLocation which dates back to Windows 2000. Still, developers like to push POSIX standards into Windows, creating .dotfiles and not even bothering to at least mark them as hidden. There's a big list on the Arch wiki[7] listing programs and their compatibilities with XDG. [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=259356 https://bugzilla.mozilla.org/show_bug.cgi?id=259356 [2]: https://github.com/kubernetes/kubernetes/issues/56402 https://github.com/kubernetes/kubernetes/issues/56402 [3]: https://github.com/flatpak/flatpak/issues/1651 https://github.com/flatpak/flatpak/issues/1651 [4]: https://savannah.gnu.org/support/?108134 https://savannah.gnu.org/support/?108134 [5]: https://docs.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetknownfolderpath https://docs.microsoft.com/en-us/windows/win32/api/shlobj_co... [6]: https://docs.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetfolderlocation https://docs.microsoft.com/en-us/windows/win32/api/shlobj_co... [7]: https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcoded https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcode...
Taniwha 5y ago
I'd forgotten that RK05s only had 1.5Mb which made me think about my disk quota as a student around the same time on a mainframe - 500 180byte blocks - ~90k - but I could back my programs up and take them home - on cards
captainmuon 5y ago
I've read this explanation a couple of times, and if you go all the way back to PDP-11 the split does indeed sound ridiculous. I had my first contact with Linux from some magazine CDs in the late 90s, I think it was Red Hat or SUSE based. The documentation there had a much clearer explaination: /sbin, /usr/sbin is for binaries that need root. You put them in separate directories so their permissions all match up, and so they don't show up when completing in bash. The paths without /usr - /bin and /sbin - are available from the get go. It is the very first partition that is mounted, and what is guaranteed to be available if you do "init 1" or boot in single user mode. You can also do fsck from there (assuming the boot partition is not damaged). I don't know how this integrated with initrd (initramfs wasn't a thing yet). I think there was only one "base system" - either initrd was very basic, or the whole base was in initrd, or something similar. The paths with /usr were managed by the package manager. Word of mouth was: don't install anything manually there. If you do (via make install), keep around the source so you can do make uninstall. But better install to /usr/local or /opt.
- cesarb 5y ago
  > I don't know how this integrated with initrd (initramfs wasn't a thing yet). As far as I recall, early Linux didn't have initrd either; it's a novelty which came later. > But better install to /usr/local or /opt. I believe /opt is a novelty which appeared on either FSSTD or its successor FHS; I think /usr/local is older (perhaps even older than Linux), being the default --prefix for autoconf.
- jjice 5y ago
  > I had my first contact with Linux from some magazine CDs in the late 90s, I think it was Red Hat or SUSE based. Man that sounds awesome. I know we have it made these days with modern internet and computers, but sometimes I day dream about being 19 in the mid to late 90s and getting to experience that age of computing.
- Athas 5y ago
  > /sbin, /usr/sbin is for binaries that need root. You put them in separate directories so their permissions all match up, and so they don't show up when completing in bash. I also got this explanation, but it never made much sense to me. First of all, the binaries there are executable by everyone anyway. Second, it really doesn't matter that they show up during completion. Third, many of them work fine and are quite useful without root! I don't recall the specific examples that bothered me (/sbin and /usr/sbin have been in my PATH forever now), but I think it was something like ifconfig or ping.
usrbinbash 5y ago
This is by far the best explanation for the mess that is historical file hierarchies I have ever read.
phendrenad2 5y ago
On my personal Linux desktop PC I have dumped all binaries into /bin. And /sbin, /usr/bin, and /usr/sbin are symlinks to /bin.
vfinn 5y ago
Bad/illogical/outdated directory structure is one of the most annoying things I've encountered while using Linux, because it makes the admin job feel unnecessarily messy (things are all over the place), and it feels as if there's a fundamental imbalance in the system that you can't get rid of.
- li2uR3ce 5y ago
  > it makes the admin job feel unnecessarily messy Many admins feel like a Jedi when they memorize all the trivia about a file's path. There's no shortage of people in a particular profession that feed on unnecessary complexity even when the original reason for said complexity (i.e. tiny drives) doesn't exist any more. Now if you'll excuse me I have to figure out why sound doesn't work on Linux in 2022 like it's 1997. No seriously, I legit have to do that now. Someone should really develop another system for sound, again.
  - deleted 5y ago
    [deleted]
  - b65e8bee43c2ed0 5y ago
    "I use arch btw"
    - deleted 5y ago
      [deleted]
  - survirtual 5y ago
    I just got done building an omni-channeling recording system, with a soc running ubuntu-server & alsa handling recording from several usb dacs connected to microphones. I feel your pain. Sound on linux is a nightmare. But now that I have an understanding of it, here are some helpful things I learned. - Make sure alsa-utils is installed - Auto-configure hardware devices: alsactl init - View hardware for playback (use arecord for opposite): aplay -L | grep “^hw:” ^ Use that to make sure your hw is being detected - Lower level list of sound cards, if having issues: cat /proc/asound/cards - Base alsa conf: /usr/share/alsa/alsa.conf ^ go there to dive deeper into what alsa is actually doing. It will also show you the priority for config files, so you can go through that and check which ones are in use and modify accordingly. alsactl init should handle most configuration though. - you will want to mess with this: /etc/modprobe.d/alsa-base.conf …and get it working for your hardware. This is a resource to understand that file better: https://alsa.opensrc.org/MultipleCards https://alsa.opensrc.org/MultipleCards You can google configuration files and find one that works for you. Most issues for normal use will revolve around which card gets set to index 0 / default, so if you know your card you want as default, I’d recommend finding your device id (i think cat /proc/asound/cards will give you vendor/product ids you can use) then making a config using that id to set it as the default card, independent of indexing. Turned into a lot, stopping here. Sound really shouldn’t be this hard for end users or devs, but it is what it is right now. Anyway, it’s fresh on my mind so at the very least, I might be able to point you in the right direction. Good luck! - Someone with no more hair left to pull out
baby 5y ago
Tangent, but that's what made getting into Linux/Unix really hard. You have all these folders and files and no README.md to explain what is what. And there seemed to be no logic at all with how things were organized or named (and names often were shortened to abbreviations that I couldn't comprehend). I'm wondering what a modern system made to be readable and understandable would look like. The other thing, coming from windows, was not understanding where to install things. In windows there's like a single place where you install all your stuff.
- cesarb 5y ago
  > You have all these folders and files and no README.md to explain what is what. Markdown is a novelty. Back then, it would be just README (with no file extension at all). > In windows there's like a single place where you install all your stuff. Windows was even worse. Whenever you installed something, parts of it were in a new directory at the root of C:\, and parts of it were dumped in C:\WINDOWS\SYSTEM together with all the rest that's already there, often overwriting files of the same name (and the names were limited to 8 characters plus the extension, so they were quite opaque) used by other software you had installed earlier (that's the original scenario of what is now called "DLL hell"). On later Windows versions, instead of a new directory at the root of C:\ it was a new directory within "C:\Programs Files" (or is it "C:\PROGRA~1"? Or perhaps "C:\Arquivos de programas" aka "C:\ARQUIV~1"? Or something else?), and instead of C:\WINDOWS\SYSTEM it was now C:\Windows\system32, and there's also the "Common files" directory somewhere. And since there's no package manager (actually there is one, but not everything uses it, and it's very complex), you don't know which file came from which software. Oh, and if the program you installed overwrote a "protected" system file, the operating system overwrites the file again with its own copy.
  - baby 5y ago
    As a user everything was in program files/
    - stouset 5y ago
      It wasn't, though.
YesThatTom2 5y ago
- elevader 5y ago
  > I don’t wanna be callous but on a scale of 0=I stubbed my toe and 10=children are starving in [insert location] this seems to be a -3. Not sure what we are measuring here but the issue of this particular article annoying you seems like a -25 by comparison, so maybe just ignore it?
- robertlagrant 5y ago
  > If not… holy crap can we please stop repeating articles like this??? Is there really a world-stopping problem that requires this to be fixed?
- Accacin 5y ago
  > I don’t wanna be callous but on a scale of 0=I stubbed my toe and 10=children are starving in [insert location] this seems to be a -3. The scale is a measure of what though? > My theory is every so often someone stumbles upon it, thinks “oh that’s interesting!” and submits it, not realizing it’s a duplicate? ..and then tons of readers in the same boat upvote it? (Similar to how urban legends about dog-sized rats taken as pets in Mexico keep circulating and will forever) I'm not sure this is a theory, this is literally how the site works, is it not? You know what I do when I see an article title that I've seen before and it's something I don't care about? I don't click it. Most times though, I do click into the comments to see what a 'new' audience thinks about it.
- 91edec 5y ago
  > My theory is every so often someone stumbles upon it, thinks “oh that’s interesting!” and submits it, not realizing it’s a duplicate? ..and then tons of readers in the same boat upvote it? The social bug being that you keep getting older and there is always young newcomers that don't have the knowledge you have already picked up? https://www.youtube.com/watch?v=9gWtrnb4KjU https://www.youtube.com/watch?v=9gWtrnb4KjU
upofadown 5y ago
>Standards bureaucracies like the Linux Foundation ... happily document and add to this sort of complexity without ever trying to understand why it was there in the first place. That is because that is a standards organization's job. They exist to document what is actually being done, not editorialize about what should be done. This seems to be a good example of the virtue of this sort of behaviour. The mostly arbitrary changes that have been done here have in themselves caused more problems and wasted effort than just keeping everything the same as it was.
- deleted 5y ago
  [deleted]
temptemptemp111 5y ago
TheCycoONE 5y ago
https://fedoraproject.org/wiki/Features/UsrMove https://fedoraproject.org/wiki/Features/UsrMove (2012) and the linked systems article https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor... include some motivation for changing the status quo, and moving all the duplicate root paths into /usr.
codedokode 5y ago
The fact that there are several directories with binaries is not a problem by itself. The problem is that many applications use hardcoded paths instead of searching for these binaries using PATH. It means that if someone decides to get away from this legacy structure and move OS into something like /system/debian-11.1.2/ all those programs would break. Examples: [1], [2]. I assume that developers have hardcoded those paths because /sbin is often not included into PATH. [1] https://github.com/blueman-project/blueman/blob/fcef83a01c80bec3bbee731a162ce18a0f4c097a/blueman/main/NetConf.py#L365 https://github.com/blueman-project/blueman/blob/fcef83a01c80... [2] https://github.com/blueman-project/blueman/blob/fcef83a01c80bec3bbee731a162ce18a0f4c097a/blueman/main/PPPConnection.py#L82 https://github.com/blueman-project/blueman/blob/fcef83a01c80...

534 points by taubek 5y ago

...cache invalidation, naming things, filesystem hierarchy Taxonomy, in general, consumes and perplexes us. It only seems to get worse as time goes on. Look at your typical react app...

kuharich 5y ago

Past comments: https://news.ycombinator.com/item?id=3519952 https://news.ycombinator.com/item?id=3519952, https://news.ycombinator.com/item?id=11647304 https://news.ycombinator.com/item?id=11647304, https://news.ycombinator.com/item?id=22614731 https://news.ycombinator.com/item?id=22614731

gjadi 5y ago

> GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke. That's one way to make new friends :)

szastamasta 5y ago

I must say I really like the MacOS idea, that every app has it’s own folder. I think that apps scattered through filesystem are not a good idea at all. Maybe they should symlink executables to /bin and shared libraries to /lib. Also everything that is needed to boot should probably be in a sealed readonly filesystem or binary anyway. I think we have made a mess with unix filesystem stricture and it really needs to be simplified.

cassepipe 5y ago
You should really check out GoboLinux then : https://gobolinux.org/ https://gobolinux.org/
jmbwell 5y ago
macOS also does a more strict but tidier hierarchy, grouped into "domains" … /System/* is "stuff from Apple" (including /System/Library, etc.), / is for "stuff on the local machine" (/Applications, /Library, etc.), and then each user can have their own hierarchy in their user directory (~/Applications, ~/Library, etc.). Of course, the "stuff from BSD" winds up in /bin and /usr/bin anyway, so it's still a mess. https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW14 https://developer.apple.com/library/archive/documentation/Fi...

cassepipe 5y ago

Anyone ever tried to run GoboLinux as a sysadmin ? What was the experience like ?

betagammaxyz 5y ago

Path dependence -- just like the default 80x24 character terminal window size that goes back to the VT100 of 1978. A curious historical hangover. GUI defaults are obviously less consequential, though.

basemi 5y ago

I think modern distros have resolved the issue . For example this is void-linux: $ ls -ld /bin /sbin /usr/bin /usr/sbin lrwxrwxrwx 1 root root 7 May 3 00:20 /bin -> usr/bin lrwxrwxrwx 1 root root 7 May 3 00:20 /sbin -> usr/bin drwxr-xr-x 1 root root 39444 May 10 18:41 /usr/bin lrwxrwxrwx 1 root root 3 May 3 00:20 /usr/sbin -> bin Ubuntu, Debian and RHEL, on the contrary still splits up: $ ls -ld /bin /sbin /usr/bin /usr/sbin lrwxrwxrwx 1 root root 7 set 25 2021 /bin -> usr/bin lrwxrwxrwx 1 root root 8 set 25 2021 /sbin -> usr/sbin drwxr-xr-x 2 root root 69632 mag 11 14:00 /usr/bin drwxr-xr-x 2 root root 20480 mag 11 13:33 /usr/sbin

b65e8bee43c2ed0 5y ago

- `/home/username/bin` and for binaries installed under that specific user - `/bin` for everything except the above, including binaries installed under root - same pattern for configs, auxiliary and transient stuff change my mind

Danielle69 5y ago

[dead]

deergomoo 5y ago

> Then somebody decided /usr/local wasn't a good place to install new packages, so let's add /opt! I'm still waiting for /opt/local to show up... Heh, MacPorts installs stuff to /opt/local on the Mac.

mc4ndr3 5y ago

TL;DR. Storage used to be so expensive per gigabyte that binaries were arbitrarily categorized into distinct file system partitions. Nobody ever bothered to revisit this and merge back to just /bin. Also, why the heck was $HOME/bin never a thing?

michaelcampbell 5y ago

One of my first exposures to *nix in the corporate world was on a Sun Sparc, running at the time SunOS 4.something. The sysadmin at the time told me the /sbin versions of things where for statically linked binaries that didn't need any other FS' mounted to read any dynamic libs. I'm not asserting it was right, but just another view into "tribal knowledge" vs "urban legend" vs ???

jlundberg 4y ago

For those who liked this text and want to read more from the author, have a look at his busybox replacement toybox: http://landley.net/toybox/ http://landley.net/toybox/

sdgdfgsfdfgsdfg 5y ago

Its funny how many quirks of UNIX/C/etc go back to the severe limitations of early day computers. Which is why using modern languages like Rust and its compiler really feels like coming up for air.

alecmg 5y ago
I think Windows is even more permeated with legacy Off the top of my head: Nobody questions why main drive is C:, remnant of [an] early computer having two floppy (not sure) drives on A: and B: Or more recent - C:/Windows/System32 holds 64 bit executables; 32 bit exectuables live in C:/Windows/SysWOW64
- indrora 5y ago
  Fun fact this is the second time Microsoft have pulled this. The first time was for legacy 16 bit Windows applications running on Windows NT. Since most people have moved to 64bit processors, it has been shuttered. https://en.wikipedia.org/wiki/Windows_on_Windows https://en.wikipedia.org/wiki/Windows_on_Windows
- DavidVoid 5y ago
  As a user, the main one that really annoys me is the "Program Files" vs "Program Files (x86)" split. I can kinda see why they have to be different folders, but why did they have to name it "... (x86)" instead of "... (32bit)"? You can call the 64 bit architecture x64 all you like, but it's still using the x86 instruction set and it's frequently referred to as x86-64, so naming that 32 bit only folder "... (x86)" will just make things more confusing than they should be.
  - jeroenhd 5y ago
    I think this was because at the time of picking the name, Windows with a working 65-bit Windows-on-Windows subsystem only ran on x86 and x64, so the naming made sense. DEC builds weren't relevant at the time and ARM was still far away from gaining 64-bit support. There was a 64 bit version of XP for Itanium but that couldn't run x86 code natively. It'll be interesting to see what Microsoft will do if Windows on ARM actually takes off. As far as I know, the current translation layer can't execute amd64 on ARM, only x86. Will we see Program Files, Program Files (x64) and Program File (x86)? It would make sense; have the redirection system ready to go and the naming scheme would also make perfect sense. ARM doesn't need a special 32-bit folder because there's no notable 32-bit vs 64-bit clash; nobody is migrating upgrading their Windows CE device to Windows 11, after all.

smartmic 5y ago

> Embedded guys try to understand and simplify... It is indeed true that when you have limited resources, simpler - in the sense of better, more beautiful - solutions often emerge.

Waterluvian 5y ago

Speaking of this, is there a good resource that elegantly but succinctly describes the intent of each of linux’s (Unix’s?) root directories? I’ve spent like eight years with Ubuntu and realize it’s all symbol manipulation to me. I learn what is and goes where but all in practice and never because I understand the semantics.

wkz 5y ago
https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf
faho 5y ago
You probably have a "hier" man page on your system. https://man7.org/linux/man-pages/man7/hier.7.html https://man7.org/linux/man-pages/man7/hier.7.html Also systemd has a "file-hierarchy" man page for its understanding of the hierarchy, which includes e.g. its use of /run and which directory can be read-only - https://man7.org/linux/man-pages/man7/file-hierarchy.7.html https://man7.org/linux/man-pages/man7/file-hierarchy.7.html
- Waterluvian 5y ago
  Aha! Thanks so much.
drothlis 5y ago
Many distros, including Debian & Ubuntu, have merged /bin and /usr/bin, with symlinks for backwards compatibility: /bin -> /usr/bin (and similarly for /usr/lib etc). https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
- happymellon 5y ago
  Did Debian do it? I thought there was internal conflict in the project whether it would happen, and has been for a decade.

heinrichhartman 5y ago

Now that we understand this can we please put all system tools into /bin? Disk space for binaries has not been a problem for decades now.

pilif 5y ago
having the system mounted in its own sub directory rather than be spread over multiple directories (there's /usr/bin, /usr/share, /usr/lib, etc) has the advantage that a single read-only mount can mount the whole OS. Having the OS mounted read-only provides some security benefits. The other option would of course be to have / mounted ro and then have rw mounts in /home, /etc, /var and /tmp, but this is more complicated than a a rw / and a ro /usr
- andrewshadura 5y ago
  While that's true, these days initramfs is what performs this job.
hulitu 5y ago
It depends. Fsck is slow on big hard drives. Also separating data from programs is a good idea.
captainmuon 5y ago
Disk space was not really the issue. Back in the day extra partitions would actually mean you waste space. It's more efficient to put them on one partition. The issue is organisation. There is already so much junk in the bin folders. I think it would be much neater to further split the bins into various categories: "shell tools" like ls, [, echo; "applications" like firefox, inkscape, "helpers" like gnome-settings-daemon, ... There is no need to show weird daemons when pressing TAB in bash, and there is no need to show `ls` when picking an application via a GUI.
- pmoriarty 5y ago
  The problem with that suggestion is that some things belong in more than one category. A much more flexible way of organizing is to use tags. This way a file could have more than one tag. Having a tag hierarchy would be even better, so you can browse down the hierarchy as you'd traverse the tree structure of a typical file system (with the added advantage of allowing a single file to have multiple categories that it could be in).

j16sdiz 5y ago

> There's no actual REASON for any of it anymore. No reason to do it on embedded system. Lots of backward compatibility reason on servers/desktops.

pilif 5y ago
it's my understanding that most distros by now have moved to have their stuff in /usr, though there might still be backwards compatibility symlinks of course.
- hulitu 5y ago
  Good luck mounting /usr when mount is in /usr/bin. Not everybody uses a ramdisk to boot the system.
  - pabs3 5y ago
    Not using an initrd is unsupported on lots of distros these days.
    - blueflow 5y ago
      You mean initramfs, initrd is unsupported on lots of distros these days.
      - pabs3 5y ago
        Right.
  - colonwqbang 5y ago
    Just don't put /usr on its own partition. What is the point anyway after we have merged /bin into /usr/bin, /lib into /usr/lib etc. Just put your operating system on a single partition and be happy.
usrbinbash 5y ago
Backward compatibility can be ensured with a couple of symlinks.

EdSchouten 5y ago

I once sent out a proposal on the FreeBSD lists to merge /sbin with /bin, and /usr/sbin with /usr/bin. People were concerned that this would slow down the system, due to PATH lookups taking longer. Even when I demonstrated the opposite was true (it being faster due to fewer directories needing to be scanned), I wasn't able to get consensus. What a shame.

cryptonector 5y ago
A merge needs to be done carefully for backwards compatibility. You could move all the things in /bin and /sbin to /usr/bin and /usr/sbin, then leave behind links (symbolic or hard). Since everyone ends up having /bin and /usr/bin in PATH, this merge makes a lot of sense from a performance point of view. Merging bindirs and sbindirs is a touchier topic. Many things in sbindirs should have been in bindirs all along, and many should move to libexecdirs, but some should stay behind so that privileged users can keep sbindirs out of PATH when they're not wearing an admin hat.
gorgoiler 5y ago
What about /usr/games! Insensitive clod!
- tremon 5y ago
  /usr/games should never have existed in the first place, imnsho. If it's a small game, its binary could just have been put in /usr/bin. If it's a large game, it probably should be in /opt/$game.
  - bityard 5y ago
    It's a historical unix thing. Things in /usr/games (which were not all games) were frivolous and not essential to the OS, and were distributed as a separate tape or archive so that admins could easily choose whether or not to install them.
    - jmclnx 5y ago

bjourne 5y ago

Roughly the same reason why dotfiles became a thing on Unix: https://linux-audit.com/linux-history-how-dot-files-became-hidden-files/ https://linux-audit.com/linux-history-how-dot-files-became-h... Fortunately more and more software is putting its config in ~/.config/ rather than dumping it all over users' home directories.

sph 5y ago
AFAIK the XDG spec isn't a thing on macOS, so you get those CLI utilities written by devs on their fancy Macbook Pro that pollute your home directory, such as Deno, Doom Emacs, Elixir, Rust/Cargo, Kubernetes, npm, vscode, etc.
- jeroenhd 5y ago
  I can understand devs not using the right circumstances if their platform of choice doesn't come with an easy way to determine the right directory to put stuff in, let alone create it if necessary. What I really want is an API that does "create/open/delete a file/directory for the relevant configuration/cache/resources store", be it user configured or platform default. What I get is an external package that gives me a list of potential storage locations (of which I'll probably just pick the first) that may or may not be actual directories on the system which I may or may not have access to touch files in. Some devs are kindly reminded that there's a spec for these things but often it's too late as data is already in specific paths that users may have come to know. That way you end up with paths that get set by environment variables where you have to tell each and every program where to put their crap. Other programs don't care enough to implement the standards (like Firefox; the bug report about XDG is old enough to vote [1] and it's still not implemented fully). Kubernetes has an open issue for its client that only ever gets bumped. Even worse are devs that are reminded of standards like XDG and then decide to give everyone the middle finger. Snap is one of them, not only is the data directory hard-coded, it's hard-coded lowercase unlike every other standard directory on Canonical's distribution itself! Snap's biggest competitor, Flatpak, decided not following the standard is not a problem [3]. At least it's special snowflake folder starts with a period so that it's hidden by default, I suppose. Even Bash doesn't support XDG [4] because not everyone uses Linux (and apparently no effort should be made to support OS specific standards?) with the suggestion closed as won't fix. Many tools that do support XDG only care about their own standards, of course; Windows has had SHGetKnowlFolderPath since Vista, replacing SHGetFolderLocation which dates back to Windows 2000. Still, developers like to push POSIX standards into Windows, creating .dotfiles and not even bothering to at least mark them as hidden. There's a big list on the Arch wiki[7] listing programs and their compatibilities with XDG. [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=259356 https://bugzilla.mozilla.org/show_bug.cgi?id=259356 [2]: https://github.com/kubernetes/kubernetes/issues/56402 https://github.com/kubernetes/kubernetes/issues/56402 [3]: https://github.com/flatpak/flatpak/issues/1651 https://github.com/flatpak/flatpak/issues/1651 [4]: https://savannah.gnu.org/support/?108134 https://savannah.gnu.org/support/?108134 [5]: https://docs.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetknownfolderpath https://docs.microsoft.com/en-us/windows/win32/api/shlobj_co... [6]: https://docs.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetfolderlocation https://docs.microsoft.com/en-us/windows/win32/api/shlobj_co... [7]: https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcoded https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcode...

Taniwha 5y ago

I'd forgotten that RK05s only had 1.5Mb which made me think about my disk quota as a student around the same time on a mainframe - 500 180byte blocks - ~90k - but I could back my programs up and take them home - on cards

captainmuon 5y ago

I've read this explanation a couple of times, and if you go all the way back to PDP-11 the split does indeed sound ridiculous. I had my first contact with Linux from some magazine CDs in the late 90s, I think it was Red Hat or SUSE based. The documentation there had a much clearer explaination: /sbin, /usr/sbin is for binaries that need root. You put them in separate directories so their permissions all match up, and so they don't show up when completing in bash. The paths without /usr - /bin and /sbin - are available from the get go. It is the very first partition that is mounted, and what is guaranteed to be available if you do "init 1" or boot in single user mode. You can also do fsck from there (assuming the boot partition is not damaged). I don't know how this integrated with initrd (initramfs wasn't a thing yet). I think there was only one "base system" - either initrd was very basic, or the whole base was in initrd, or something similar. The paths with /usr were managed by the package manager. Word of mouth was: don't install anything manually there. If you do (via make install), keep around the source so you can do make uninstall. But better install to /usr/local or /opt.

cesarb 5y ago
> I don't know how this integrated with initrd (initramfs wasn't a thing yet). As far as I recall, early Linux didn't have initrd either; it's a novelty which came later. > But better install to /usr/local or /opt. I believe /opt is a novelty which appeared on either FSSTD or its successor FHS; I think /usr/local is older (perhaps even older than Linux), being the default --prefix for autoconf.
jjice 5y ago
> I had my first contact with Linux from some magazine CDs in the late 90s, I think it was Red Hat or SUSE based. Man that sounds awesome. I know we have it made these days with modern internet and computers, but sometimes I day dream about being 19 in the mid to late 90s and getting to experience that age of computing.
Athas 5y ago
> /sbin, /usr/sbin is for binaries that need root. You put them in separate directories so their permissions all match up, and so they don't show up when completing in bash. I also got this explanation, but it never made much sense to me. First of all, the binaries there are executable by everyone anyway. Second, it really doesn't matter that they show up during completion. Third, many of them work fine and are quite useful without root! I don't recall the specific examples that bothered me (/sbin and /usr/sbin have been in my PATH forever now), but I think it was something like ifconfig or ping.

usrbinbash 5y ago

This is by far the best explanation for the mess that is historical file hierarchies I have ever read.

phendrenad2 5y ago

On my personal Linux desktop PC I have dumped all binaries into /bin. And /sbin, /usr/bin, and /usr/sbin are symlinks to /bin.

vfinn 5y ago

Bad/illogical/outdated directory structure is one of the most annoying things I've encountered while using Linux, because it makes the admin job feel unnecessarily messy (things are all over the place), and it feels as if there's a fundamental imbalance in the system that you can't get rid of.

li2uR3ce 5y ago
> it makes the admin job feel unnecessarily messy Many admins feel like a Jedi when they memorize all the trivia about a file's path. There's no shortage of people in a particular profession that feed on unnecessary complexity even when the original reason for said complexity (i.e. tiny drives) doesn't exist any more. Now if you'll excuse me I have to figure out why sound doesn't work on Linux in 2022 like it's 1997. No seriously, I legit have to do that now. Someone should really develop another system for sound, again.
- deleted 5y ago
  [deleted]
- b65e8bee43c2ed0 5y ago
  "I use arch btw"
  - deleted 5y ago
    [deleted]
- survirtual 5y ago
  I just got done building an omni-channeling recording system, with a soc running ubuntu-server & alsa handling recording from several usb dacs connected to microphones. I feel your pain. Sound on linux is a nightmare. But now that I have an understanding of it, here are some helpful things I learned. - Make sure alsa-utils is installed - Auto-configure hardware devices: alsactl init - View hardware for playback (use arecord for opposite): aplay -L | grep “^hw:” ^ Use that to make sure your hw is being detected - Lower level list of sound cards, if having issues: cat /proc/asound/cards - Base alsa conf: /usr/share/alsa/alsa.conf ^ go there to dive deeper into what alsa is actually doing. It will also show you the priority for config files, so you can go through that and check which ones are in use and modify accordingly. alsactl init should handle most configuration though. - you will want to mess with this: /etc/modprobe.d/alsa-base.conf …and get it working for your hardware. This is a resource to understand that file better: https://alsa.opensrc.org/MultipleCards https://alsa.opensrc.org/MultipleCards You can google configuration files and find one that works for you. Most issues for normal use will revolve around which card gets set to index 0 / default, so if you know your card you want as default, I’d recommend finding your device id (i think cat /proc/asound/cards will give you vendor/product ids you can use) then making a config using that id to set it as the default card, independent of indexing. Turned into a lot, stopping here. Sound really shouldn’t be this hard for end users or devs, but it is what it is right now. Anyway, it’s fresh on my mind so at the very least, I might be able to point you in the right direction. Good luck! - Someone with no more hair left to pull out

baby 5y ago

Tangent, but that's what made getting into Linux/Unix really hard. You have all these folders and files and no README.md to explain what is what. And there seemed to be no logic at all with how things were organized or named (and names often were shortened to abbreviations that I couldn't comprehend). I'm wondering what a modern system made to be readable and understandable would look like. The other thing, coming from windows, was not understanding where to install things. In windows there's like a single place where you install all your stuff.

cesarb 5y ago
> You have all these folders and files and no README.md to explain what is what. Markdown is a novelty. Back then, it would be just README (with no file extension at all). > In windows there's like a single place where you install all your stuff. Windows was even worse. Whenever you installed something, parts of it were in a new directory at the root of C:\, and parts of it were dumped in C:\WINDOWS\SYSTEM together with all the rest that's already there, often overwriting files of the same name (and the names were limited to 8 characters plus the extension, so they were quite opaque) used by other software you had installed earlier (that's the original scenario of what is now called "DLL hell"). On later Windows versions, instead of a new directory at the root of C:\ it was a new directory within "C:\Programs Files" (or is it "C:\PROGRA~1"? Or perhaps "C:\Arquivos de programas" aka "C:\ARQUIV~1"? Or something else?), and instead of C:\WINDOWS\SYSTEM it was now C:\Windows\system32, and there's also the "Common files" directory somewhere. And since there's no package manager (actually there is one, but not everything uses it, and it's very complex), you don't know which file came from which software. Oh, and if the program you installed overwrote a "protected" system file, the operating system overwrites the file again with its own copy.
- baby 5y ago
  As a user everything was in program files/
  - stouset 5y ago
    It wasn't, though.

YesThatTom2 5y ago

elevader 5y ago
> I don’t wanna be callous but on a scale of 0=I stubbed my toe and 10=children are starving in [insert location] this seems to be a -3. Not sure what we are measuring here but the issue of this particular article annoying you seems like a -25 by comparison, so maybe just ignore it?
robertlagrant 5y ago
> If not… holy crap can we please stop repeating articles like this??? Is there really a world-stopping problem that requires this to be fixed?
Accacin 5y ago
> I don’t wanna be callous but on a scale of 0=I stubbed my toe and 10=children are starving in [insert location] this seems to be a -3. The scale is a measure of what though? > My theory is every so often someone stumbles upon it, thinks “oh that’s interesting!” and submits it, not realizing it’s a duplicate? ..and then tons of readers in the same boat upvote it? (Similar to how urban legends about dog-sized rats taken as pets in Mexico keep circulating and will forever) I'm not sure this is a theory, this is literally how the site works, is it not? You know what I do when I see an article title that I've seen before and it's something I don't care about? I don't click it. Most times though, I do click into the comments to see what a 'new' audience thinks about it.
91edec 5y ago
> My theory is every so often someone stumbles upon it, thinks “oh that’s interesting!” and submits it, not realizing it’s a duplicate? ..and then tons of readers in the same boat upvote it? The social bug being that you keep getting older and there is always young newcomers that don't have the knowledge you have already picked up? https://www.youtube.com/watch?v=9gWtrnb4KjU https://www.youtube.com/watch?v=9gWtrnb4KjU

upofadown 5y ago

>Standards bureaucracies like the Linux Foundation ... happily document and add to this sort of complexity without ever trying to understand why it was there in the first place. That is because that is a standards organization's job. They exist to document what is actually being done, not editorialize about what should be done. This seems to be a good example of the virtue of this sort of behaviour. The mostly arbitrary changes that have been done here have in themselves caused more problems and wasted effort than just keeping everything the same as it was.

deleted 5y ago
[deleted]

temptemptemp111 5y ago

TheCycoONE 5y ago

https://fedoraproject.org/wiki/Features/UsrMove https://fedoraproject.org/wiki/Features/UsrMove (2012) and the linked systems article https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor... include some motivation for changing the status quo, and moving all the duplicate root paths into /usr.

codedokode 5y ago

The fact that there are several directories with binaries is not a problem by itself. The problem is that many applications use hardcoded paths instead of searching for these binaries using PATH. It means that if someone decides to get away from this legacy structure and move OS into something like /system/debian-11.1.2/ all those programs would break. Examples: [1], [2]. I assume that developers have hardcoded those paths because /sbin is often not included into PATH. [1] https://github.com/blueman-project/blueman/blob/fcef83a01c80bec3bbee731a162ce18a0f4c097a/blueman/main/NetConf.py#L365 https://github.com/blueman-project/blueman/blob/fcef83a01c80... [2] https://github.com/blueman-project/blueman/blob/fcef83a01c80bec3bbee731a162ce18a0f4c097a/blueman/main/PPPConnection.py#L82 https://github.com/blueman-project/blueman/blob/fcef83a01c80...