You know, this makes me wonder.. tangentially speaking- I wonder how hard it would be to rearrange the folder structure in linux so that I have something like this:
Wow, thanks for the reply, nice find! I did some poking around on my Linux system and even re-arranging the home folder was a task of its own because the system kept trying to replace folders in their original places. I will do some digging in to Gobo and see how they're handling this. Thanks again for pointing this out.
The directories that house your executables are read only to users other than root, to prevent attacks and overwriting them by non-root users.
/var stands for variable data--like log files, cache directories, spool directories, etc. You shouldn't put executables there. Ideally you should be able to set the noexec flag on it.
`/usr` actually exists because the original UNIX developers ran out of disk space and had to attach another disk. The difference between /bin and /usr/bin is not worth it and even Debian symlinks /usr/bin to bin.
But your distribution's package manager should be putting stuff in /bin or /usr/bin, not you. Anything that follows the regex "{asterisk}/local{asterisk}" is something the system owner can do whatever with. So you should be using /usr/local/bin or $HOME/local/bin. I don't know why there's no /local off of the root. (One thing I do on my own systems is make and use an /etc/local although I think you're supposed to use something like /usr/local/etc).
/opt is for third party programs that aren't installed via your distro's package manager.
If you do this, any customizations you make to a system can be easily backed up by copying all dirs with local in the name.
There's multiple decades of tradition behind these names, but they do date back to the age where actual teletypes were used.
The only real holdouts are proc/sys/dev which are the kernel and mnt/media/opt/srv which are really for the user/sysadmin and aren't really used by the OS anymore.
Genuine question: on what systems is `/tmp` persistent? Both macOS and Ubuntu 20.04 clear `/tmp` on every reboot for me, and I haven't changed the defaults at all.
Is it coincidence that you almost exactly replicated what macOS has? Except that /Devices is /Volumes, .../Apps is .../Applications. and /Boot is handled differently.
Of course, that's not perfect either, because a) decades of changes vs. compatibility have made it less clean in certain places, and b) pretty much all the POSIX paths still exist for unix-y compatibility, but overall it's like that.
> I wonder how hard it would be to rearrange the folder structure in linux
Restructuring the directories is the easy part. You just delete the old tree and make a new one. You can also mount procfs and sysfs wherever you want.
The hard part is modifying existing software to work with the new tree. So many programs assume you have a "standard" file system tree. So many programs assume procfs is mounted at /proc. So many programs have hardcoded paths. Shared library locationd can become part of the binaries when they're compiled. It's insane and you'd essentially be creating a new Linux distribution.
MacOS too. /usr/ and /dev/ and whatnot exist, they're just flagged as invisible in Finder. There's a command to globally unhide them for those who want to see them.
Yeah, it's a junction point, but it's also useless. Open a command box and CD to it; now what? A file explorer and set it as the directory, again, now what?
I know this is completely tangential. But you can Win-R and just type Documents and it will load your documents folder. Same for downloads, pictures, temp (windows temp), and I'm sure many others.
Works from File-Open dialogs and address bars and even in the command prompt you can even do "explorer documents".
You know, this makes me wonder.. tangentially speaking- I wonder how hard it would be to rearrange the folder structure in linux so that I have something like this:
/Users/{root, user0, user1, ... }...
/System/{Logs, Apps/{opt, container, ...}, Temp, Conf ...}...
/Devices/{Mount, sda, sdb, null ...}...
/Boot/...
GoboLinux does exactly that: https://en.m.wikipedia.org/wiki/GoboLinux
Wow, thanks for the reply, nice find! I did some poking around on my Linux system and even re-arranging the home folder was a task of its own because the system kept trying to replace folders in their original places. I will do some digging in to Gobo and see how they're handling this. Thanks again for pointing this out.
12 replies →
How do you deal with lack of being able to just point to "/usr/lib/include" or other things when saying "here's my directory of shared libs"?
This is definitely interesting though, and an improvement I would say
4 replies →
Dammit, I wanted to be the one to mention gobo linux [HN deleted my laughing emoji ffs]
1 reply →
This is what I want from Linux. Sensible & guessable names for newcomers to figure out where to put files and programs.
It's frustrating having to spend time to decide whether I should install a program in /var or /opt or /usr. What do they even mean!
So, I disagree with this convention altogether and use /apps or ~/apps now.
Oh, my young friend, you have no idea what POSIX has done to you.
"While no one sane would put newlines in directory names, such corruption of the results could lead to exploitable vulnerabilities in scripts."
http://www.etalabs.net/sh_tricks.html
4 replies →
Behold! https://en.m.wikipedia.org/wiki/Filesystem_Hierarchy_Standar...
37 replies →
The directories that house your executables are read only to users other than root, to prevent attacks and overwriting them by non-root users.
/var stands for variable data--like log files, cache directories, spool directories, etc. You shouldn't put executables there. Ideally you should be able to set the noexec flag on it.
`/usr` actually exists because the original UNIX developers ran out of disk space and had to attach another disk. The difference between /bin and /usr/bin is not worth it and even Debian symlinks /usr/bin to bin.
But your distribution's package manager should be putting stuff in /bin or /usr/bin, not you. Anything that follows the regex "{asterisk}/local{asterisk}" is something the system owner can do whatever with. So you should be using /usr/local/bin or $HOME/local/bin. I don't know why there's no /local off of the root. (One thing I do on my own systems is make and use an /etc/local although I think you're supposed to use something like /usr/local/etc).
/opt is for third party programs that aren't installed via your distro's package manager.
If you do this, any customizations you make to a system can be easily backed up by copying all dirs with local in the name.
There's multiple decades of tradition behind these names, but they do date back to the age where actual teletypes were used.
I mean we're heading there with /usr being your /System. Redhat/Pottering are doing heroic work in this space.
The only real holdouts are proc/sys/dev which are the kernel and mnt/media/opt/srv which are really for the user/sysadmin and aren't really used by the OS anymore.
Genuine question: on what systems is `/tmp` persistent? Both macOS and Ubuntu 20.04 clear `/tmp` on every reboot for me, and I haven't changed the defaults at all.
9 replies →
I'm not sure I'm a fan of the capitalization and spaces, other than that I'm all for more self-explanatory names.
3 replies →
Is it coincidence that you almost exactly replicated what macOS has? Except that /Devices is /Volumes, .../Apps is .../Applications. and /Boot is handled differently.
Of course, that's not perfect either, because a) decades of changes vs. compatibility have made it less clean in certain places, and b) pretty much all the POSIX paths still exist for unix-y compatibility, but overall it's like that.
> I wonder how hard it would be to rearrange the folder structure in linux
Restructuring the directories is the easy part. You just delete the old tree and make a new one. You can also mount procfs and sysfs wherever you want.
The hard part is modifying existing software to work with the new tree. So many programs assume you have a "standard" file system tree. So many programs assume procfs is mounted at /proc. So many programs have hardcoded paths. Shared library locationd can become part of the binaries when they're compiled. It's insane and you'd essentially be creating a new Linux distribution.
You don't even need to rearrange the folders themselves, just show them like that in the file explorer. Same way the windows explorer does.
MacOS too. /usr/ and /dev/ and whatnot exist, they're just flagged as invisible in Finder. There's a command to globally unhide them for those who want to see them.
Do you have any docs on how to do that? Thanks for the reply, I look forward to trying that.
Why not just symlink them? You can have best of both worlds with relatively little effort.
Make the overlay of your dreams!
You monster!
Don't even get me started on /usr/local/bin..
1 reply →
Couldn't you do it with plain old symlinks?
macos does something like that.
Yeah, it's a junction point, but it's also useless. Open a command box and CD to it; now what? A file explorer and set it as the directory, again, now what?
I know this is completely tangential. But you can Win-R and just type Documents and it will load your documents folder. Same for downloads, pictures, temp (windows temp), and I'm sure many others.
Works from File-Open dialogs and address bars and even in the command prompt you can even do "explorer documents".
Nothing says progress like renaming all your paths.