Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.)

See also https://freedesktop.org/wiki/Software/systemd/separate-usr-i....

> 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...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: