Tim:
> > 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.
George N. White III:
> This points to a failure of the linux community to carry through with past
> initiatives to standardize the file hierarchy.
Did you ever dabble with the Amiga?
That had the system organised quite well. All commands went in C: (an
assign to a C directory in the root), all handlers in L: (another
assign, like with C:), all libraries in LIBS:, all fonts in FONTS:, all
scripts in S:, et cetera. 'twas quite neat and easily understandable.
Inspired by TripOS.
Trouble is they didn't follow through the neatness when it came to your
applications. They just went in some folder in your drive, often
selected by your own choice, and in isolation (no execution /path/ to a
binary to follow). To start it, you had to drill through folders to
find its icon, or leave it out on the desktop, or find a third-party
program to launch things (menus, docks, whatever), which had another
problem (programs started via command line weren't the same as their
icon being double-clicked). And if program A wanted to interact with
program B, either they had to be configured for their locations, or
both programs had to be already running.
Someone always cuts corners when it comes to designing things.
> > 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.
I think the writing was on the wall with that one. I know people who'd
rather trawl through 20 minutes of some (bad) youtube tutorial on how
to do something that 5 minutes of reading text and actually learning
how something worked so you could figure it out for yourself.
There are people actually proud of being idiots (I'd make a voting joke
here, but it made itself), and pour scorn on anyone smarter than they
are (there's another joke that just writes itself, here, too).
> > 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.
There's sense in that, at least in a achieving standardised
organisation. The trouble is we're getting flatpacks and appimages
that I find about as on-par as backyard programmers with their C64.
Every app looks different, doesn't fit into your desktop, poor feature
support, only concentrates on their app (ignorant that a PC is a multi-
tasking device, and their program isn't the only thing I'm running).
1) They aren't as universal as claimed.
(a) They still need to be compiled with something compatible
with your OS (there are some apps I can't install and
run for that reason).
(b) They only have minimal compatibility with your OS so you
get minimum functionality compared to native apps (lowest
common denominators is all they support, it's too much
effort to do more).
(c) Thanks to (b) more functionality has to be put into itself
to do the same jobs.
2) We get huge apps, because they have to replicate much of the
OS inside themselves (or the additional than OS support that
used to be installed for common use).
3) Thanks to sandboxing, or just plain lack of functionality,
we get apps that can't print, for instance.
I've got ones that can't, I have to print to PDF, then find something
else to print that PDF (which will fail when they eventually appimage
the whatever that prints PDF). If you attempt to print from the app,
it goes through the motions without error messages but does nothing.
Or, it cannot print to/through CUPS, it has to find the printer
directly using ZeroConf (hostname.local) instead of using the fully-
functional DNS system on the LAN, and will only print that way.
--
uname -rsvp
Linux 3.10.0-1160.119.1.el7.x86_64 #1 SMP Tue Jun 4 14:43:51 UTC 2024 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
--
_______________________________________________
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
