On Fri, Apr 18, 2025 at 10:32 PM Tim via users <users@xxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
