Originally posted by cjcox
View Post
Announcement
Collapse
No announcement yet.
Fedora 40 Plans To Unify /usr/bin & /usr/sbin
Collapse
X
-
Last edited by Myownfriend; 25 December 2023, 02:54 AM.
- Likes 14
-
Originally posted by Myownfriend View Post
It used to do /home's job, too. Now, it's for user space resources but distros like Fedora don't differentiate anyway. /bin, /sbin, /lib, and /lib64 all link to their /use equivalent anyway.
- Likes 4
Comment
-
Originally posted by Delgarde View Post
Right. The model these days is that all distro content goes under /usr... executables, libraries, resources. You can put your own stuff wherever you like (e.g. we mostly put ours under /opt), but the stuff that falls under distro package management is all in one place under /usr.
For /sbin merge -- while it can be used to tell that something requires root to run, in reality every app requiring root, when lacking the required privileges, would either print a warning message or silently fail, so I am fine with merging out /sbin.
- Likes 3
Comment
-
Originally posted by ireri View PostNo, usr is not "user", it means Universal System Resources, learn that already people.
- Likes 7
Comment
-
-
Originally posted by cj.wijtmans View PostWhy not unify /dev /sys etc. And /home /mnt /media /root into /. Heck why not unify everything and every filename is a hash in /.
more to come destroying linux madness.
Here's the directory structure of my Debian sid (Trixie) + Nix.
You can see merged usr and the Nix store.
Code:/ ├── bin -> usr/bin ├── boot ├── dev ├── etc ├── home ├── initrd.img -> boot/initrd.img-6.6.8-amd64 ├── initrd.img.old -> boot/initrd.img-6.6.8-x64v3-xanmod1 ├── lib -> usr/lib ├── lib64 -> usr/lib64 ├── lost+found ├── media ├── mnt ├── nix │ ├── store │ │ ├── 001gp43bjqzx60cg345n2slzg7131za8-nix-nss-open-files.patch │ │ ├── 006k1g0ama5aasw9y0fzq1q77d6w5d4c-jq-1.7.tar.gz.drv │ │ ├── 00qday9c9iqv6fn8z5vbqvsm91k90zm3-crate-proc-macro-error-1.0.4.tar.gz.drv │ │ ├── 00qr10y7z2fcvrp9b2m46710nkjvj55z-update-autotools-gnu-config-scripts.sh │ │ ├── 00xq9ff6n6r1gcc53w5kkma8bz6snzqp-fortify-headers.tar.gz.drv │ [...] │ │ ├── zxsfbzdam6z5nvf495jghhhaa0x476ij-autoconf-2.69.tar.xz.drv │ │ ├── zykvqny5j601mxp1n86f3f50q0s79nap-02-fix-ftbfs-with-glibc-2.28.patch.drv │ │ ├── zz7fbkn5nq8vxsj9gcknwkrb0h814hja-valgrind-3.22.0.drv │ │ ├── zzy1by02va08j7hy6qd0hgyaigckgqn4-libedit-20221030-3.1.drv │ │ └── zzy4s1k2x44ba3199i4kklqcnrr2c9vs-crate-winapi-i686-pc-windows-gnu-0.4.0.tar.gz.drv │ └── var │ ├── log │ └── nix ├── opt ├── proc ├── root ├── run ├── sbin -> usr/sbin ├── srv ├── sys ├── tmp ├── usr ├── var ├── vmlinuz -> boot/vmlinuz-6.6.8-amd64 └── vmlinuz.old -> boot/vmlinuz-6.6.8-x64v3-xanmod1
Last edited by reba; 25 December 2023, 06:15 AM.
- Likes 5
Comment
-
Originally posted by cend View Post
I would suggest just dropping /usr outright and symlink everything, including include and share, right to root, if we would like to go down this path.
For /sbin merge -- while it can be used to tell that something requires root to run, in reality every app requiring root, when lacking the required privileges, would either print a warning message or silently fail, so I am fine with merging out /sbin.
Imho the Gobolinux folks have it right ( considering the limits they must face to maintain retrocompatibility with the Unix way ). We have a filesystem, we have files and we have directories. We have a sort of database. Why the hell don't we use directories to logically separate the various programs? So it becomes simpler to account for what is installed or not ( without needing a package index ). It becomes simpler to remove programs and ALL of their direct dependencies ( I mean config files, man, doc, icons and whatnot ). It is obviously easier to remove third party dependencies too.
The Unix way is really an abomination and the only justification is that computing resources were restrained at the time. But today it is time to rethink the whole thing.Last edited by pabloski; 25 December 2023, 06:24 AM.
- Likes 11
Comment
-
Originally posted by pabloski View PostBut today it is time to rethink the whole thing.
There is a lot of sense with specific directories for libraries and include files. This allows a system to be as lean and mean as possible; and I *like* having a root folder below 30GB of storage. Heck, if I could separate apps from system files, I could probably keep the root partition down to 10GB or so.
Continuing that trend, you have four more types of files that an app is bundled with; configuration files, documentation files, data files (think game content, font files and UI graphics), and finally the program executables. Separating docs and data files from the rest makes kinda sense, but configurations should be primarily controlled at system and user level, not app level.
The biggest flaw of Linux, is that there are no mechanisms that can separate older library versions with newer ones. This is partly by design, and partly because there is little to no proprietary software in Linux, so most of it can be recompiled or upgraded to newer library versions.
I do agree ever since EFI partitions and Coreboot became a thing, the need for a minimum viable root file system is completely gone; either you can boot a small Linux root of perhaps 60MB from EFI, and use that to netboot or whatever, or you could do the same thing from Coreboot. So there is really no real reason to keep the old filesystem structure as is, other than inertia. But there really is no reason to rush to change it either.
- Likes 5
Comment
Comment