11 ms·

sbin split (2010)

398 points by rohitpaulk 7y ago

oftenwrong 7y ago
Recent Debian and Ubuntu systems symlink (by default, possibly with exceptions) /bin, /sbin, and /lib* to their counterparts in /usr. Older systems may be able to perform the merge by installing the "usrmerge" package. I believe Arch takes it further and combines /bin and /sbin (and /usr/sbin) by symlinking them to /usr/bin.
- the_af 7y ago
  Do you know in which Ubuntu version this showed up? I just tested on my Ubuntu 16.04 (I know, I know) and they are not symlinked.
  - andreareina 7y ago
    18.04 here, /bin and /usr/bin are still different.
  - therealjumbo 7y ago
    I think it was done in Debian 10 which was released last summer. So you'll probably need a Ubuntu version newer than that.
  - oftenwrong 7y ago
    I believe Ubuntu started being usrmerged-by-default in 19.04 (Disco Dingo), although the release notes do not mention it. On 16.04 you can usrmerge your system by installing the usrmerge package: https://packages.ubuntu.com/xenial/usrmerge https://packages.ubuntu.com/xenial/usrmerge
- kseistrup 7y ago
  Correct, ArchLinux symlinks /bin, /sbin and /usr/sbin to /usr/bin.
  - shrimp_emoji 7y ago
    Confirmed on Manjaro (which is Arch-based) as well.
  - majewsky 7y ago
    Also /lib to /usr/lib.
- gweinberg 7y ago
  Doesn't this seem backwards? Given that the usr prefix doesn't mean anything anymore, wouldn't it make more sense to just put everything in /bin and keep /usr/bin as a symlink for backwards compatibility and eventually drop it?
  - bonzini 7y ago
    Putting everything in a single directory allows you to mount it from a remote for system with a single mount point. /usr means "the part of the OS that is the same across all hosts".
    - gweinberg 7y ago
      Everything is always in a single directory, it's called "/". I don't see why you think the files under /usr are particularly likely to be remote mounted.
      - afiori 7y ago
        If you remotely mount "/" then you ran out of namespace for non-remote files.
    - sjmulder 7y ago
      Isn’t that supposed to be share/ and maybe a few others? bin/ and lib/ are architecture specific.
- oat_bravo_nap 7y ago
  Here are the wiki pages for the move in Fedora and Ubuntu: https://fedoraproject.org/wiki/Features/UsrMove https://fedoraproject.org/wiki/Features/UsrMove https://wiki.debian.org/UsrMerge https://wiki.debian.org/UsrMerge
santiagobasulto 7y ago
Great story, I love these! Personally I always thought that the difference between `bin` and `sbin` was that `sbin` contained binaries with Superuser privileges (hence the `s` at the beginning).
- QuesnayJr 7y ago
  Wait, that's not the reason?
  - qayxc 7y ago
    It kind of is and isn't. So sbin is reserved for system binaries concerned with booting, administrative tools, repairing/restoring (the system), and the like. Since these essential utilities by their very nature require superuser privileges, it's tempting to think that sbin simply means "superuser binaries" or something. Someone else mentioned "statically linked", which is also true, but again just a side-effect of being for system programs. The programs in sbin need to be able to run without /usr, /lib, or /bin being mounted or even existing is the idea here. To me personally - and this is just my uniformed(!) opinion - the only split that makes sense across all circumstances is /bin vs /sbin and /var vs /. Simply because anything but /var could safely be considered read-only, while /var exists explicitly for writable data ¯\_(ツ)_/¯
    - derekp7 7y ago
      Also, you can mount /var with no executable set, for security purposes. If you go through the various security guidelines (such as STIG and various others), they give several paths that should exist as individual mount points -- both for the purpose of setting appropriate mount options, but also if a user program has write access somewhere in it, then they can't cause a disk-full condition on another (logging-type) path.
      - kyuudou 7y ago
        Same with /tmp - mounting it and allowing executables is a recipe for disaster in a multi-user web hosting environment.
teddyh 7y ago
For quite some time it was common for workstations to have a bare-bones OS installed on their small hard drives, but for /usr to be mounted via NFS to a large server with a large disk. This also, for a long time, justified the split.
- gravitas 7y ago
  Interesting this use case wasn't covered in the mailing list post, I too experienced this exact reason for them being split in the early 90s. In that era, a lot of university terminals were very low end (small disks) - they mounted shares if they ran as Netware clients as well, not just Unix/Linux/BSD. Some of them only had boot floppies.
- rjsw 7y ago
  Or just that you had to spread the local files over multiple drives, it wasn't really tied to the use of NFS. The /bin and /sbin directories would be on the boot partition/disk and would contain the programs needed to get to multiuser state. I still use multiple partitions, even on a 1TB disk.
- peterwwillis 7y ago
  This was one of those few cases were the split was necessary. You could ship a very small initrd via bootp (or floppy, or much later, CDROM), and once it came up it could mount /usr over NFS. In case there were problems with the NFS mount, you still had some utilities in /bin for troubleshooting. The alternative was 'remote root NFS', where the root filesystem itself was NFS, and any network problems hosed the machine entirely. Trying to attach some alternative troubleshooting tools into a thin-terminal, or customize the bootp server to boot a troubleshooting image just for the one malfunctioning box, was a lot more painful than just shipping troubleshooting tools in /bin.
- JdeBP 7y ago
  See https://utcc.utoronto.ca/~cks/space/blog/unix/DisklessUnixAndUsr https://utcc.utoronto.ca/~cks/space/blog/unix/DisklessUnixAn... and the comment by Greg A. Woods.
ape4 7y ago
Effort to clean it up: UsrMove https://fedoraproject.org/wiki/Features/UsrMove https://fedoraproject.org/wiki/Features/UsrMove
- deleted 7y ago
  [deleted]
peterwwillis 7y ago
And this has led to de facto standards, like '#!/bin/sh' is a 'standard' shell shebang, but not POSIX; if you want your script to be portable, you have to use '#!/usr/bin/env sh'. env is forever in '/usr/bin' probably because it first came about after new tools started moving to '/usr'. And I don't think env's file path is even in POSIX, it's just a de facto standard. Another fun fact is that execve() (which executes shebangs) only allows a single argument to the shebang program. Meaning if you use '#!/usr/bin/env sh', you can't specify arguments to 'sh' in the shebang. In any case, the name of the file being executed is appended as an additional argument at the end of the shebang.
- beefhash 7y ago
  > And I don't think env's file path is even in POSIX, it's just a de facto standard. You would be correct about that. And that sucks.
- lmm 7y ago
  I'm not aware of anywhere that /bin/sh won't work. /bin/bash is extremely non-portable though.
  - toast0 7y ago
    /bin/bash is popular in Linux systems, but not BSD or Mac or probably other Unixes which may not always have bash and if they do have it, it will be somewhere else. Also, a number of niche-ish Linux distributions are trying to replace bash with something else. It's no longer as portable as it once was.
    - bobbyi_settv 7y ago
      It's not just about whether it exists but also the version. For example, on my (Mac) laptop, /bin/bash is bash 3.2.57 (released in 2007), while "/usr/bin/env bash" gets the version installed by homebrew which is 4.4.19 (released in 2016).
  - dwheeler 7y ago
    POSIX does not specify the path of anything. It says that "sh" is a shell, but doesn't say that "/bin/sh" is that shell. See: https://pubs.opengroup.org/onlinepubs/9699919799/ https://pubs.opengroup.org/onlinepubs/9699919799/ I believe that in Solaris before Solaris 10, /bin/sh was the original Bourne shell (which didn't comply with POSIX), and in Solaris 10 it's ksh (which isn't either, but is way closer): https://unix.stackexchange.com/questions/538844/does-posix-guarantee-the-paths-to-any-standard-utilities https://unix.stackexchange.com/questions/538844/does-posix-g... Also, I don't think that "#!" is specified in POSIX. It's extremely common, it's just not in the specification. This is similar to find's "-print0" option, which also isn't in the POSIX specification but basically everyone implements it. If you want a specification of "where things go", the closest one in practice (and one that most modern distributions try to follow) is the Filesystem Hierarchy Standard (FHS): https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
saagarjha 7y ago
> I'm still waiting for /opt/local to show up... Wait no more, MacPorts installs to this by default.
- cosarara 7y ago
  I wonder what the next step is then. /local? /usr/opt?
  - JdeBP 7y ago
    /command * http://cr.yp.to/slashcommand.html http://cr.yp.to/slashcommand.html (-:
  - Spivak 7y ago
    RedHat actually has /var/opt and /etc/opt which, while odd, makes some sense since /opt is a free-form /usr and still needs variable space and configs.
    - rhizome 7y ago
      and which preserves the functional separations between the hier elements and doesn't require changing any backup procedures.
  - protomyth 7y ago
    Well, /usr/local is set as its own partition on OpenBSD so it can have different mounting instructions. b1c4a5629703d4fd.d /usr ffs rw,nodev 1 2 b1c4a5629703d4fd.e /usr/local ffs rw,wxallowed,nodev 1 2 I tend to do the evil thing of always creating an /opt just for my stuff that is system wide. So, I do have an /opt/bin/ so I don't mess with the system or package level stuff.
- Fnoord 7y ago
  And then there was Nix(OS). [1] > A big implication of the way that Nix/NixOS stores packages is that there is no /bin, /sbin, /lib, /usr, and so on. Instead all packages are kept in /nix/store. (The only exception is a symlink /bin/sh to Bash in the Nix store.) Not using ‘global’ directories such as /bin is what allows multiple versions of a package to coexist. Nix does have a /etc to keep system-wide configuration files, but most files in that directory are symlinks to generated files in /nix/store. [Insert obligatory xkcd quote about competing standards.] [1] https://nixos.org/nixos/about.html https://nixos.org/nixos/about.html
wjdp 7y ago
What is with the insistence of (in-paragraph) hard line breaks on documents still? I put this page into Firefox's reader mode and I get lines breaking all over the place as it's now got a mix of soft and hard line breaks. Should presentation of line length not be up to the client?
- peapicker 7y ago
  It it a <pre> formatted section from an old usenet post with 80 char line length... often on usenet posts were specially formatted with whitespace chars. Usenet display tools almost always use PRE and preserve that using monospace fonts to preserve the full possibilities of the information transfer.
  - cpach 7y ago
    It’s from a mailing list, not Usenet.
- acoard 7y ago
  You're not wrong, but this is plaintext in its purest form. It's literally just plaintext wrapped in a <pre> tag. They don't use any CSS on the site, besides the very infrequent `style` tag. This is more common with the type of people who use text-based browsers like lynx. (edit: As another comment says, note they use 80 chars) But as someone who has bash aliases for extracting text from a website so I can read it in my terminal (or page it with `less -r`), yes, this is something that bugs me too.
- gpanders 7y ago
  The email is space-stuffed meaning it was probably written with format=flowed[1] (you can tell because there are spaces appended to hard-wrapped lines). That RFC was invented precisely for the purpose you mention: hard wrap lines in "dump" plain text clients, but allow "intelligent" clients to soft-wrap according to their own display width. This email would display at full-width in a client that respects format=flowed (many modern email readers, except for, notably, Outlook and Gmail). But as others have pointed out, this is literally just the plain text of the email wrapped in a <pre> tag, so you get the hard line breaks. [1]: https://joeclark.org/ffaq.html https://joeclark.org/ffaq.html
Jaruzel 7y ago
I am sure that one of the original aims of the Linux Standard Base Project[1] was to fix and simplify the default file system hierarchy, but researching it now, it seems that they've backed away from doing anything drastic. --- [1] https://en.wikipedia.org/wiki/Linux_Standard_Base https://en.wikipedia.org/wiki/Linux_Standard_Base
ipnon 7y ago
The PDP-11 became super influential because it was the first machine that had seemingly unbound performance for its price, compared to any computer from the 60s or 50s. This gave programmers the freedom "write to their hearts content," leading to the innovations of Unix and the C programming language. Compare it to how modern web developers write entirely in the application domain, giving no regard to operating system or machine constraints. I'm proposing that the PDP-11 gave a similar feeling to programmers who had been restricted before, to a programming process that today seems as streamlined as carving hieroglyphics with a pickaxe. Eventually though the new programs started pushing up against the limits of the PDP-11. I propose that virtually anything that seems like magic in Unix or C, from filesystem organization to page sizes, traces its origin directly back to the PDP-11. We are still living in the world of microcomputers, no matter how far we may seem to have ventured away.
- cbm-vic-20 7y ago
  Compared to the PDP-7 and PDP-8, the PDP-11 instruction set and architecture is a breath of fresh air.
- musicale 7y ago
  Wasn't UNIX originally hacked together in assembly language on an already-obsolete PDP-7 that was sitting around unused? And according to Dennis M. Ritchie, the B language that preceded C was also first implemented on the PDP-7, whose auto-increment memory cells "probably" inspired Ken Thompson to create B's ++ and -- operators.
- aap_ 7y ago
  Page sizes on the PDP-11 are 8kb. Its successor the VAX had 512b pages. I don't think there's any PDP-11 heritage there. The filesystem organzation has more to do with disk sizes than the pdp-11. Also the pdp-11 wasn't a microcomputer but a minicomputer.
ainar-g 7y ago
IIRC, they got rid of all this in Plan 9. /bin was where binaries go. /usr was for user data. There were also /proc, /net, and probably /tmp?
- skrebbel 7y ago
  This Plan 9 nostalgia weirds me out. It never happened! It was vaporware all along! It's like having fond memories of Hillary Clinton's inauguration speech.
  - ainar-g 7y ago
    > It was vaporware all along! I don't think “vapourware” means what you think it means. To elaborate, the comparison with an alternative universe is silly, since there are actually papers that people can read and there is actually code that people can use. So saying that “it never happened” is wrong.
  - icedchai 7y ago
    I installed Plan 9 once back in the 90's. It certainly exists, it just never reached mass levels of acceptance.
    - blaser-waffle 7y ago
      I installed it in the mid-2000s to be cool. I'd say it's closer to the DMC DeLorean: short production run, works but has short comings, more of a meme than an actual commodity. It's not vaporware though, they definitely delivered something that works. It's just that there wasn't a good reason to use it compared to other options.
  - rm445 7y ago
    Are you mixing up Plan9 with some legendary vapourware OS, MULTICS or something? Maybe the HURD? (NB: not entirely vapourware, but less finished than Plan9). Because Plan9 was (and is) a real system that you could (and can) run.
  - yiyus 7y ago
Lammy 7y ago
Tangentially related, one of my favorite FreeBSD manual pages: hier(7) https://www.freebsd.org/cgi/man.cgi?hier(7) https://www.freebsd.org/cgi/man.cgi?hier(7)
- throw0101a 7y ago
  See also mtree(8): > The default action, if not overridden by command line options, is to compare the file hierarchy rooted in the current directory against a specification read from the standard input. Messages are written to the standard output for any files whose characteristics do not match the specification, or which are missing from either the file hierarchy or the specification. * https://www.freebsd.org/cgi/man.cgi?mtree https://www.freebsd.org/cgi/man.cgi?mtree It can also be used to create a hierarchy: * https://github.com/freebsd/freebsd/tree/master/etc/mtree https://github.com/freebsd/freebsd/tree/master/etc/mtree
dang 7y ago
2016: https://news.ycombinator.com/item?id=11647304 https://news.ycombinator.com/item?id=11647304 2015: https://news.ycombinator.com/item?id=9554134 https://news.ycombinator.com/item?id=9554134 2012: https://news.ycombinator.com/item?id=3519952 https://news.ycombinator.com/item?id=3519952 (Links for the curious. Reposts are ok after a year: https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html)
Taniwha 7y ago
minor nit - initrd/initramfs don't really precede linux
bcoughlan 7y ago
How does the terminal work in Unix? Well, in 1869... https://www.linusakesson.net/programming/tty/ https://www.linusakesson.net/programming/tty/
fulldecent2 7y ago
In my life we will probably never have a man on the moon and never replace POSIX.
remmargorp64 7y ago
The confusing and nonsensical (not immediately obvious by typing ls and reading) folder structure in unix/linux/etc has always been one of my biggest complaints with it as an operating system. I consider it to be a warning about the importance of refactoring and renaming things sooner rather than later, because the longer that something sticks around, the more dependencies it develops and the harder it is to change.

398 points by rohitpaulk 7y ago

Recent Debian and Ubuntu systems symlink (by default, possibly with exceptions) /bin, /sbin, and /lib* to their counterparts in /usr. Older systems may be able to perform the merge by installing the "usrmerge" package. I believe Arch takes it further and combines /bin and /sbin (and /usr/sbin) by symlinking them to /usr/bin.

the_af 7y ago
Do you know in which Ubuntu version this showed up? I just tested on my Ubuntu 16.04 (I know, I know) and they are not symlinked.
- andreareina 7y ago
  18.04 here, /bin and /usr/bin are still different.
- therealjumbo 7y ago
  I think it was done in Debian 10 which was released last summer. So you'll probably need a Ubuntu version newer than that.
- oftenwrong 7y ago
  I believe Ubuntu started being usrmerged-by-default in 19.04 (Disco Dingo), although the release notes do not mention it. On 16.04 you can usrmerge your system by installing the usrmerge package: https://packages.ubuntu.com/xenial/usrmerge https://packages.ubuntu.com/xenial/usrmerge
kseistrup 7y ago
Correct, ArchLinux symlinks /bin, /sbin and /usr/sbin to /usr/bin.
- shrimp_emoji 7y ago
  Confirmed on Manjaro (which is Arch-based) as well.
- majewsky 7y ago
  Also /lib to /usr/lib.
gweinberg 7y ago
Doesn't this seem backwards? Given that the usr prefix doesn't mean anything anymore, wouldn't it make more sense to just put everything in /bin and keep /usr/bin as a symlink for backwards compatibility and eventually drop it?
- bonzini 7y ago
  Putting everything in a single directory allows you to mount it from a remote for system with a single mount point. /usr means "the part of the OS that is the same across all hosts".
  - gweinberg 7y ago
    Everything is always in a single directory, it's called "/". I don't see why you think the files under /usr are particularly likely to be remote mounted.
    - afiori 7y ago
      If you remotely mount "/" then you ran out of namespace for non-remote files.
  - sjmulder 7y ago
    Isn’t that supposed to be share/ and maybe a few others? bin/ and lib/ are architecture specific.
oat_bravo_nap 7y ago
Here are the wiki pages for the move in Fedora and Ubuntu: https://fedoraproject.org/wiki/Features/UsrMove https://fedoraproject.org/wiki/Features/UsrMove https://wiki.debian.org/UsrMerge https://wiki.debian.org/UsrMerge

santiagobasulto 7y ago

Great story, I love these! Personally I always thought that the difference between `bin` and `sbin` was that `sbin` contained binaries with Superuser privileges (hence the `s` at the beginning).

QuesnayJr 7y ago
Wait, that's not the reason?
- qayxc 7y ago
  It kind of is and isn't. So sbin is reserved for system binaries concerned with booting, administrative tools, repairing/restoring (the system), and the like. Since these essential utilities by their very nature require superuser privileges, it's tempting to think that sbin simply means "superuser binaries" or something. Someone else mentioned "statically linked", which is also true, but again just a side-effect of being for system programs. The programs in sbin need to be able to run without /usr, /lib, or /bin being mounted or even existing is the idea here. To me personally - and this is just my uniformed(!) opinion - the only split that makes sense across all circumstances is /bin vs /sbin and /var vs /. Simply because anything but /var could safely be considered read-only, while /var exists explicitly for writable data ¯\_(ツ)_/¯
  - derekp7 7y ago
    Also, you can mount /var with no executable set, for security purposes. If you go through the various security guidelines (such as STIG and various others), they give several paths that should exist as individual mount points -- both for the purpose of setting appropriate mount options, but also if a user program has write access somewhere in it, then they can't cause a disk-full condition on another (logging-type) path.
    - kyuudou 7y ago
      Same with /tmp - mounting it and allowing executables is a recipe for disaster in a multi-user web hosting environment.

teddyh 7y ago

For quite some time it was common for workstations to have a bare-bones OS installed on their small hard drives, but for /usr to be mounted via NFS to a large server with a large disk. This also, for a long time, justified the split.

gravitas 7y ago
Interesting this use case wasn't covered in the mailing list post, I too experienced this exact reason for them being split in the early 90s. In that era, a lot of university terminals were very low end (small disks) - they mounted shares if they ran as Netware clients as well, not just Unix/Linux/BSD. Some of them only had boot floppies.
rjsw 7y ago
Or just that you had to spread the local files over multiple drives, it wasn't really tied to the use of NFS. The /bin and /sbin directories would be on the boot partition/disk and would contain the programs needed to get to multiuser state. I still use multiple partitions, even on a 1TB disk.
peterwwillis 7y ago
This was one of those few cases were the split was necessary. You could ship a very small initrd via bootp (or floppy, or much later, CDROM), and once it came up it could mount /usr over NFS. In case there were problems with the NFS mount, you still had some utilities in /bin for troubleshooting. The alternative was 'remote root NFS', where the root filesystem itself was NFS, and any network problems hosed the machine entirely. Trying to attach some alternative troubleshooting tools into a thin-terminal, or customize the bootp server to boot a troubleshooting image just for the one malfunctioning box, was a lot more painful than just shipping troubleshooting tools in /bin.
JdeBP 7y ago
See https://utcc.utoronto.ca/~cks/space/blog/unix/DisklessUnixAndUsr https://utcc.utoronto.ca/~cks/space/blog/unix/DisklessUnixAn... and the comment by Greg A. Woods.

ape4 7y ago

Effort to clean it up: UsrMove https://fedoraproject.org/wiki/Features/UsrMove https://fedoraproject.org/wiki/Features/UsrMove

deleted 7y ago
[deleted]

peterwwillis 7y ago

And this has led to de facto standards, like '#!/bin/sh' is a 'standard' shell shebang, but not POSIX; if you want your script to be portable, you have to use '#!/usr/bin/env sh'. env is forever in '/usr/bin' probably because it first came about after new tools started moving to '/usr'. And I don't think env's file path is even in POSIX, it's just a de facto standard. Another fun fact is that execve() (which executes shebangs) only allows a single argument to the shebang program. Meaning if you use '#!/usr/bin/env sh', you can't specify arguments to 'sh' in the shebang. In any case, the name of the file being executed is appended as an additional argument at the end of the shebang.

beefhash 7y ago
> And I don't think env's file path is even in POSIX, it's just a de facto standard. You would be correct about that. And that sucks.
lmm 7y ago
I'm not aware of anywhere that /bin/sh won't work. /bin/bash is extremely non-portable though.
- toast0 7y ago
  /bin/bash is popular in Linux systems, but not BSD or Mac or probably other Unixes which may not always have bash and if they do have it, it will be somewhere else. Also, a number of niche-ish Linux distributions are trying to replace bash with something else. It's no longer as portable as it once was.
  - bobbyi_settv 7y ago
    It's not just about whether it exists but also the version. For example, on my (Mac) laptop, /bin/bash is bash 3.2.57 (released in 2007), while "/usr/bin/env bash" gets the version installed by homebrew which is 4.4.19 (released in 2016).
- dwheeler 7y ago
  POSIX does not specify the path of anything. It says that "sh" is a shell, but doesn't say that "/bin/sh" is that shell. See: https://pubs.opengroup.org/onlinepubs/9699919799/ https://pubs.opengroup.org/onlinepubs/9699919799/ I believe that in Solaris before Solaris 10, /bin/sh was the original Bourne shell (which didn't comply with POSIX), and in Solaris 10 it's ksh (which isn't either, but is way closer): https://unix.stackexchange.com/questions/538844/does-posix-guarantee-the-paths-to-any-standard-utilities https://unix.stackexchange.com/questions/538844/does-posix-g... Also, I don't think that "#!" is specified in POSIX. It's extremely common, it's just not in the specification. This is similar to find's "-print0" option, which also isn't in the POSIX specification but basically everyone implements it. If you want a specification of "where things go", the closest one in practice (and one that most modern distributions try to follow) is the Filesystem Hierarchy Standard (FHS): https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html

saagarjha 7y ago

> I'm still waiting for /opt/local to show up... Wait no more, MacPorts installs to this by default.

cosarara 7y ago
I wonder what the next step is then. /local? /usr/opt?
- JdeBP 7y ago
  /command * http://cr.yp.to/slashcommand.html http://cr.yp.to/slashcommand.html (-:
- Spivak 7y ago
  RedHat actually has /var/opt and /etc/opt which, while odd, makes some sense since /opt is a free-form /usr and still needs variable space and configs.
  - rhizome 7y ago
    and which preserves the functional separations between the hier elements and doesn't require changing any backup procedures.
- protomyth 7y ago
  Well, /usr/local is set as its own partition on OpenBSD so it can have different mounting instructions. b1c4a5629703d4fd.d /usr ffs rw,nodev 1 2 b1c4a5629703d4fd.e /usr/local ffs rw,wxallowed,nodev 1 2 I tend to do the evil thing of always creating an /opt just for my stuff that is system wide. So, I do have an /opt/bin/ so I don't mess with the system or package level stuff.
Fnoord 7y ago
And then there was Nix(OS). [1] > A big implication of the way that Nix/NixOS stores packages is that there is no /bin, /sbin, /lib, /usr, and so on. Instead all packages are kept in /nix/store. (The only exception is a symlink /bin/sh to Bash in the Nix store.) Not using ‘global’ directories such as /bin is what allows multiple versions of a package to coexist. Nix does have a /etc to keep system-wide configuration files, but most files in that directory are symlinks to generated files in /nix/store. [Insert obligatory xkcd quote about competing standards.] [1] https://nixos.org/nixos/about.html https://nixos.org/nixos/about.html

wjdp 7y ago

What is with the insistence of (in-paragraph) hard line breaks on documents still? I put this page into Firefox's reader mode and I get lines breaking all over the place as it's now got a mix of soft and hard line breaks. Should presentation of line length not be up to the client?

peapicker 7y ago
It it a <pre> formatted section from an old usenet post with 80 char line length... often on usenet posts were specially formatted with whitespace chars. Usenet display tools almost always use PRE and preserve that using monospace fonts to preserve the full possibilities of the information transfer.
- cpach 7y ago
  It’s from a mailing list, not Usenet.
acoard 7y ago
You're not wrong, but this is plaintext in its purest form. It's literally just plaintext wrapped in a <pre> tag. They don't use any CSS on the site, besides the very infrequent `style` tag. This is more common with the type of people who use text-based browsers like lynx. (edit: As another comment says, note they use 80 chars) But as someone who has bash aliases for extracting text from a website so I can read it in my terminal (or page it with `less -r`), yes, this is something that bugs me too.
gpanders 7y ago
The email is space-stuffed meaning it was probably written with format=flowed[1] (you can tell because there are spaces appended to hard-wrapped lines). That RFC was invented precisely for the purpose you mention: hard wrap lines in "dump" plain text clients, but allow "intelligent" clients to soft-wrap according to their own display width. This email would display at full-width in a client that respects format=flowed (many modern email readers, except for, notably, Outlook and Gmail). But as others have pointed out, this is literally just the plain text of the email wrapped in a <pre> tag, so you get the hard line breaks. [1]: https://joeclark.org/ffaq.html https://joeclark.org/ffaq.html

Jaruzel 7y ago

I am sure that one of the original aims of the Linux Standard Base Project[1] was to fix and simplify the default file system hierarchy, but researching it now, it seems that they've backed away from doing anything drastic. --- [1] https://en.wikipedia.org/wiki/Linux_Standard_Base https://en.wikipedia.org/wiki/Linux_Standard_Base

ipnon 7y ago

The PDP-11 became super influential because it was the first machine that had seemingly unbound performance for its price, compared to any computer from the 60s or 50s. This gave programmers the freedom "write to their hearts content," leading to the innovations of Unix and the C programming language. Compare it to how modern web developers write entirely in the application domain, giving no regard to operating system or machine constraints. I'm proposing that the PDP-11 gave a similar feeling to programmers who had been restricted before, to a programming process that today seems as streamlined as carving hieroglyphics with a pickaxe. Eventually though the new programs started pushing up against the limits of the PDP-11. I propose that virtually anything that seems like magic in Unix or C, from filesystem organization to page sizes, traces its origin directly back to the PDP-11. We are still living in the world of microcomputers, no matter how far we may seem to have ventured away.

cbm-vic-20 7y ago
Compared to the PDP-7 and PDP-8, the PDP-11 instruction set and architecture is a breath of fresh air.
musicale 7y ago
Wasn't UNIX originally hacked together in assembly language on an already-obsolete PDP-7 that was sitting around unused? And according to Dennis M. Ritchie, the B language that preceded C was also first implemented on the PDP-7, whose auto-increment memory cells "probably" inspired Ken Thompson to create B's ++ and -- operators.
aap_ 7y ago
Page sizes on the PDP-11 are 8kb. Its successor the VAX had 512b pages. I don't think there's any PDP-11 heritage there. The filesystem organzation has more to do with disk sizes than the pdp-11. Also the pdp-11 wasn't a microcomputer but a minicomputer.

ainar-g 7y ago

IIRC, they got rid of all this in Plan 9. /bin was where binaries go. /usr was for user data. There were also /proc, /net, and probably /tmp?

skrebbel 7y ago
This Plan 9 nostalgia weirds me out. It never happened! It was vaporware all along! It's like having fond memories of Hillary Clinton's inauguration speech.
- ainar-g 7y ago
  > It was vaporware all along! I don't think “vapourware” means what you think it means. To elaborate, the comparison with an alternative universe is silly, since there are actually papers that people can read and there is actually code that people can use. So saying that “it never happened” is wrong.
- icedchai 7y ago
  I installed Plan 9 once back in the 90's. It certainly exists, it just never reached mass levels of acceptance.
  - blaser-waffle 7y ago
    I installed it in the mid-2000s to be cool. I'd say it's closer to the DMC DeLorean: short production run, works but has short comings, more of a meme than an actual commodity. It's not vaporware though, they definitely delivered something that works. It's just that there wasn't a good reason to use it compared to other options.
- rm445 7y ago
  Are you mixing up Plan9 with some legendary vapourware OS, MULTICS or something? Maybe the HURD? (NB: not entirely vapourware, but less finished than Plan9). Because Plan9 was (and is) a real system that you could (and can) run.
- yiyus 7y ago

Lammy 7y ago

Tangentially related, one of my favorite FreeBSD manual pages: hier(7) https://www.freebsd.org/cgi/man.cgi?hier(7) https://www.freebsd.org/cgi/man.cgi?hier(7)

throw0101a 7y ago
See also mtree(8): > The default action, if not overridden by command line options, is to compare the file hierarchy rooted in the current directory against a specification read from the standard input. Messages are written to the standard output for any files whose characteristics do not match the specification, or which are missing from either the file hierarchy or the specification. * https://www.freebsd.org/cgi/man.cgi?mtree https://www.freebsd.org/cgi/man.cgi?mtree It can also be used to create a hierarchy: * https://github.com/freebsd/freebsd/tree/master/etc/mtree https://github.com/freebsd/freebsd/tree/master/etc/mtree

dang 7y ago

2016: https://news.ycombinator.com/item?id=11647304 https://news.ycombinator.com/item?id=11647304 2015: https://news.ycombinator.com/item?id=9554134 https://news.ycombinator.com/item?id=9554134 2012: https://news.ycombinator.com/item?id=3519952 https://news.ycombinator.com/item?id=3519952 (Links for the curious. Reposts are ok after a year: https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html)

Taniwha 7y ago

minor nit - initrd/initramfs don't really precede linux

bcoughlan 7y ago

How does the terminal work in Unix? Well, in 1869... https://www.linusakesson.net/programming/tty/ https://www.linusakesson.net/programming/tty/

fulldecent2 7y ago

In my life we will probably never have a man on the moon and never replace POSIX.

remmargorp64 7y ago

The confusing and nonsensical (not immediately obvious by typing ls and reading) folder structure in unix/linux/etc has always been one of my biggest complaints with it as an operating system. I consider it to be a warning about the importance of refactoring and renaming things sooner rather than later, because the longer that something sticks around, the more dependencies it develops and the harder it is to change.