Hacker News Reader

Comment by SquareWheel | Hacker News Reader

How badly would things break if we tried to "fix" this split today?

Probably not too badly if we took a phased approach.

1 - Establish a new, consistent filesystem hierarchy. New code should use the new hierarchy. Move the legacy stuff to the new hierarchy and symlink the old locations to avoid breakage.

2 - After some time, make the legacy locations read-only. This will highlight any non-conforming code.

3 - After even longer, delete the legacy paths.

It would maybe be even easier if we could redirect writes (I'm not too versed in filesystem capabilities) from the legacy paths to the new ones.

> Establish a new, consistent filesystem hierarchy.

systemd is kind of enforcing this already, preferring /usr (where most of the packages go) over naked paths. This is the trend on relatively modern desktop systems, which thankfully preserves standard fs hierarchy while mostly keeping everything in one place. (Unfortunately there are bunches of non-desktop uses for Linux out there.)

> It would maybe be even easier if we could redirect writes (I'm not too versed in filesystem capabilities) from the legacy paths to the new ones.

Quite a few distros (and users like Rob Landley) use symlinks from /bin to /usr/bin and the same goes for /lib. sbin is sometimes linked to bin. This does some of the redirection.

(I am not aware of the /usr/tmp and /var/etc stuff mentioned in the message.)

> After even longer, delete the legacy paths.

Nah. Millions of scripts are writing she-bangs like #!/bin/sh and I don't really expect to see this being changed...

Workarounds using `env` is kind of crippled since a.) it introduces an extra level of dependency and indirection and b.) it stops the user from reliability passing options to the interpreter (Linux only cut at the first space, with all sorts of other *nixen doing different things with multiple spaces.)

Still, clutters and confuses new users. In wonder if some of the fs apis could hide the silly/redundant directories?

I much prefer compatibility symlinks actually existing in the file system over some complex, hidden pathname resolution override riles lurking in the kernel. That way, Windows lies.

> lurking in the kernel. That way, Windows lies.

Windows implements many overrides (e.g. "My Documents") as NTFS junctions with some hidden (+ system?) property set. (Sometimes you will find a proper hidden property handy, like in this case.)

Stuff like CON, NUL in non-UNC paths do hurt, though. Device files from an age without directories....

Don't get me started on Windows' bizarre, barely-documented behaviour. Magical filenames pointing to devices and file virtualization are bad enough... just try to decipher whether a given registry path is what it appears, or is redirected through yet more hidden virtualization magic some time. And we haven't even come to the truly wondrous series of overrides that occur when looking up names in the NT object namespace...

Some OSes, like Solaris, have already "fixed" this. However, the uglier thing that needs fixed is the initrd/initramfs. It served a purpose in 2002, but now is almost totally a historical artifact that adds more complication to the boot process. On distros inflicted with it, it makes boot problems even harder to fix because you have a layer-0 filesystem that has its own set of basic tools that are not used, or visible, at any other time. It kinda made sense in 2002, when you had to make sure that your boot partition was in the first 8 gigs of the filesystem, but nowadays, it is just a source of redundancy and errors.

None. On Fedora and Arch Linux at least, /bin, /lib, and /sbin are symlinked to the same directories in /usr/.

One workaround you can do is to add lots of symlinks to keep the old paths working. This is what they do in Gobolinux (a Linux distro that has a radically different filesystem organization)

One funny thing about Gobolinux is that you could still do the equivalent of a / /usr split.

You never really search /Programs for binaries, you aim that at /System/Index (housing the equivalent of the classic FHS for compatibility reasons). This means that things do not really need to live in /Programs to be useful.

And because of that you have two tools DetachProgram and AttachProgram that allow you to place a package (really just a tar-ball of the /programs branch) in an arbitrary location and have them be symlinked into place.

Thing about Gobolinux is that it do not depend on special Gobo only features. Everything is built around tools you will find in any *nix, and any action can be performed manually if need be.

Nor does it demand that something upstream do something special to placate them, as long as --prefix or similar actually works.

Reply on news.ycombinator.com