Announcement

Collapse
No announcement yet.

Fedora 40 Plans To Unify /usr/bin & /usr/sbin

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by cjcox View Post
    10 years from now. Fedora finally removes last Linux library so that everyone can use Windows.
    We're talking about merging directories. You realize that, right? Like.. they're merging directories so that it matches Arch. How does that make Fedora more like Windows?
    Last edited by Myownfriend; 25 December 2023, 02:54 AM.

    Comment


    • #42
      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.
      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.

      Comment


      • #43
        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.
        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.

        Comment


        • #44
          Originally posted by ireri View Post
          No, usr is not "user", it means Universal System Resources, learn that already people.​
          AFAIK, it was "Upper Second Root", and it was added when they acquired a new hard disk, and the contents from the first "overflown" to that second one. And that was why / contained only the barely needed things to boot (it was their first, small disk) and /usr contained everything else, available after the system had boot enough to be able to mount the disk.

          Comment


          • #45
            Slightly off-topic but am I the only person who thinks it's stupid to have /mnt and /media?

            Comment


            • #46
              Originally posted by poncho524 View Post
              So the FHS doesn't matter?
              Why should (all of) it unequivocally matter? Everything has its purpose... or not. For example, the rationale for the way some directories were initially split has become obsolete probably decades ago.

              Comment


              • #47
                Originally posted by cj.wijtmans View Post
                Why 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.
                Congratulations, you've just reinvented the Nix filesystem.

                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.

                Comment


                • #48
                  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.
                  To be honest, the Unix way of organizing the filesystem is the shittiest thing in the universe. It comes from a vision where the system is a logically monolithic block, where all "user" software is just a bunch of binaries glued to the operating system ones. They didn't even try to separate the two things.

                  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.

                  Comment


                  • #49
                    Originally posted by pabloski View Post
                    But today it is time to rethink the whole thing.
                    Not really disagreeing with you, it is time to rethink the filesystem, but the only other example, Windows, is equally terrible.

                    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.

                    Comment


                    • #50
                      Originally posted by ireri View Post
                      No, usr is not "user", it means Universal System Resources
                      To add to this informative post: "home" means Hapless Observer of Meaningless Explanations.

                      Comment

                      Working...
                      X