On Fri, Apr 18, 2025 at 10:32 PM Tim via users < users@lists.fedoraproject.org> wrote:
> On Fri, 2025-04-18 at 18:38 -0400, Sam Varshavchik wrote: > > I forgot what were the actual, technical reasons for collapsing bin > > and sbin, except for "other distributions did it too". But the deed > > is done, and one just has to deal with the aftermath: > > The artificial idiot listed these summaries: > > * Simpler filesystem: Reduces unnecessary hierarchy and simplifies > finding executable files. > * Improved interoperability: Ensures scripts written for one > distribution run correctly on others, as the location of commands > becomes consistent. > * Easier maintenance: Makes it easier to manage system binaries > > But I'd argue that the hierarchies were there for a good reason. > *Simple* no-access to some things for some people/software. *Simple* > more privileged access to things in /sbin to those who had it in their > path, and lesser privileged versions of a command with the same name to > other people/things. Although another definition of sbin was not more > privileged commands, but static binaries. > This points to a failure of the linux community to carry through with past initiatives to standardize the file hierarchy. > > We have *paths* so appropriate things can actually find commands. We > shouldn't be hard-coding paths into other things. I don't think I've > ever typed /bin/ls to run ls. And there's a whole mess of reasons > things written for one distro won't work on another, a really big one > is the libraries that were compiled on one with a different compiler, > or you simply have a different version of the library. I think most > big programs are probably far more dependent on libraries than > individual commands. > > If you can't manage to maintain the binaries in /sbin and /bin (I'm > including scripts, not just precompiled binaries), that people have > managed for decades, or just understand why what's where, what hope in > hell do you have for managing a program with 10,000 lines of code in > it? > Before retiring I worked in a Scientific research institute. I'm a mathematician, but my role was helping scientists get their sums right. We had constant turnover of students and visitors and many projects with participants from institutions scattered around the globe with widely varying levels of IT support. This meant dealing with many different linux distros, and constant issues with differences in where tools were located and different versions of tools, so users often needed to install versions of tools not present or not configured to suit the user's tasks. A lot of my time was spent understanding why the same binary program crashed or gave different results when run on different systems. There were many large "mission critical" applications provided by the large space agencies. Two I was familiar with were a Java application from ESA and a a package of command-line tools from NASA. Both relied on open source libraries, but distro packages often omitted optional support (e.g., gdal support for obscure formats) so NASA built most of the 3rd party libraries they used. The NASA package included a script that adjusted paths to ensure that the correct tools were found. > Hell, why don't just we just dump *everything* into one huge directory? > That's make it really easy to manage (not). I get the impression that > there's too many un-trained programmers in the world, and much of what > they've learned has come from bad examples. > And, with AI, some no longer even attempt to learn. > > This malarkey is up there with we can't have /usr in a separate mount > point, any more, because we've put things in there that we need at boot > time. Well don't bloody do that! > I think we are headed towards having a minimal set of scripts and binaries installed in a system with most applications running in isolated containers with their own scripts and libraries so they give the same results across multiple distros. -- George N. White III
-- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
