Most of the "standard" linux userland (in here i'm referring to the most fundamental parts), in my opinion, suffers from bad quality implementations and/or interfaces.
For example the current "standard" is:
Grub, Glibc, SystemD (and its companions), GNU Coreutils
All of those, falls in one or both of that problems, what accumulates to result in a bloated non-reliable system.

And a more general problem (this one affects any POSIX system) for unix utitilities is the lack of consistency, we are supposed to have one tool, each one with its own job, but we instead have a LOT of duplication and out of context flags for most unix utilities, a simple example is the recursion flag '-R' while we already have another utility to do recursion (find(1)).

We also have the problem of no co-work between the system; for example if you are using some scripting language to interact with the system that is not shell, you probably will suffer to make the unix utilities interoperate with it.

How to deal with those problems?
1-: Using alternatives is becoming harder, as software in general tends to born/grow in the same style, with little care about the "underneath quality". What alternatives you know? which of those would compose your "ideal" system?
2-: Should we ignore other things such as performance and "convenience" to have as much consistency as possible? Is even possible to break posix-compatibility and stay relevant?
3-: Maybe we should have a "coreutils-lib" written in C to give others language a way to interoperate with the unix utilities, or should they rely only on their own std lib?

What are your opinions in all of this? what things do you think that should change?

I personally think the current environment is very organic.

While the most common userland tools can be bloated for some usages, I don't think there's any claim about their reliability or general usefulness. There are alternatives for every scenario, from rugged systems to lightweight embedded ones. And having the system in the open give the ability to configure it to fit personal needs.

You mention extra flags and features, lack of consistency between them, and duplicate behavior, in my opinion that's more of a programmer's moral perception issue than an actual one.

From my perspective, the problem that rises in popular softwares is that they are gradually partnering with others, creating and adding too much coupling. Coupling is insidious because changing any of the lowest layer will ripple through the whole stack. The more you add coupling and the more the system looks like one rigid piece. My guess is that this is what we see in the partnership of the major DE developers, the freedesktop, etc..
Another one of my guess is that the team working on those softwares are trading technical debt for quick wins of being able to use bleeding edge features. That's the environment we live in today, fast iterations.

(07-11-2019, 02:29 AM)venam Wrote: While the most common userland tools can be bloated for some usages

Being bloated for a specific use is one thing, what i see happening is little to no care about resources consumption, and this mindset eventually affects the system as a whole.

(07-11-2019, 02:29 AM)venam Wrote: I don't think there's any claim about their reliability or general usefulness.

Fair, what doesn't imply we can't see the lack of those as a problem.

(07-11-2019, 02:29 AM)venam Wrote: You mention extra flags and features, lack of consistency between them, and duplicate behavior, in my opinion that's more of a programmer's moral perception issue than an actual one.

While true, that this isn't a problem per se, the thing is that the system should evolve with some criteria, otherwise you will end with a mess.

(07-11-2019, 02:29 AM)venam Wrote: From my perspective, the problem that rises in popular softwares is that they are gradually partnering with others, creating and adding too much coupling. Coupling is insidious because changing any of the lowest layer will ripple through the whole stack. The more you add coupling and the more the system looks like one rigid piece. My guess is that this is what we see in the partnership of the major DE developers, the freedesktop, etc..

Coupling in the sense of trying to have interoperability or reducing independence?

(07-11-2019, 02:29 AM)venam Wrote: Another one of my guess is that the team working on those softwares are trading technical debt for quick wins of being able to use bleeding edge features. That's the environment we live in today, fast iterations.

True, but i think that this mentality is still "isolated" to its own place, in the sense that the unstable development scenarios always have been this way, while the stable places continues to be stable.

TL;DR: GNU sucks. Everyone knows that. Few people care enough.
The Plan 9 userland is probably the best one, but it breaks POSIX. Like, a lot.

What's the optimum?

(07-11-2019, 07:55 PM)jkl Wrote: TL;DR: GNU sucks. Everyone knows that. Few people care enough.

GNU is usually fast, the code has good algorithms, the problem is that they don't care about SLOC and have the worst code style that have ever existed (at least in C).

(07-11-2019, 07:55 PM)jkl Wrote: The Plan 9 userland is probably the best one, but it breaks POSIX. Like, a lot.

Plan9 userland is good, specially in design, and for me it doesn't seems too hard to make it POSIX compatible, the problem is that hardly anyone has enough incentive to do this (as most of people don't care/understand about design/implementation quality)

(07-11-2019, 07:55 PM)jkl Wrote: What's the optimum?

To this day i would say that the BSD's have the best userland, the code usually has smart algorithms, the code style is pretty good, usually the code is not unnecessarily huge, and the code tends to be reliable (at least for OpenBSD, which creates new functions to avoid common mistakes)

BSD's or musl based distros are there for those who want them. There are choices. Most people don't care enough though, I would switch to a more minimal install base than Arch if it wasn't for 1. steam games 2. the sheer amount of packages already packaged for you.

I agree massively with venam though. Coupling is the main reason of people's complaints, especially around systemd. You can't just simply replace it with another init even if that init serves your needs better. Hell we could extend this further even to the kernel... It's the main reason why I have never bothered to install gnome/kde or another DE environment. The amount of dependencies is unreal. People should have choice, but they shouldn't be locked into once they've made it.

I have followed the development of SerenityOS and think it is a very interesting project. In short it is a unix-like OS but unlike *BSD and linux, it is intended to be a complete OS where the kernel and userland (all the way to the GUI) is very aware of each other, not unlike MacOS. The main developer, Andreas Kling, has worked for Apple and really has a full vision on how everything should work.

So in context to the topic, this approach, optimizing the kernel for userland and vice verse, the complete system could be very efficient, streamlined, stable and consistent, but i guess the drawback will result in a monolithic project where it will be difficult to add independent userland OS-components (like init systems, display servers, and maybe even UI toolkits) that are better then built in ones. But as far as i understand this is exactly what Andreas wants, and what he consider being the biggest advantage MacOS has over other OS. Also the GUI is inspired by Windows2k.

SerenityOS is just about a year old now, but they have already been able to install it on actual hardware and gotten doom and quake to run. They are currently building a browser. Andreas uploads daily videos to his youtube channel that i cannot recommend enough.

https://www.youtube.com/watch?v=gZ2gBVzIjBU

tl;dr Do what GNOME, KDE, SystemD, Linux, GNU is doing:
be the change you want to see.

For a workstation, private computer. I think the Linux userland with all its options, abandoned good ideas, maintained and financially supported stupid ideas, ancient three-letter magic commands /etc. Is a fun rabbit hole to be in. And just as wildefyr mentions there is always a more pure choice, but it comes with a price, just as the alternatives comes with a price (sometimes prefixed with $). It is totally feasible to make ones own userland (and off course ones own custom kernel build). But there is really no point in yelling in to the void and demanding that GNOME, KDE, Firefox, GNU or whatever should become more minimal and less dependent on "bad" applications or syndromeD. "they" don't strive to be "minimal" and they are not "linux" (except for linux) or "unix" and they are probably not (you).

(09-11-2019, 05:45 PM)Wildefyr Wrote: People should have choice, but they shouldn't be locked into once they've made it.

I agree, projects could give a little more care to reduce the amount of hard dependencies, but how could this happen when are exactly those projects the ones taking all the attention.

(11-11-2019, 06:42 AM)budRich Wrote: I have followed the development of SerenityOS and think it is a very interesting project.

Seems a cool project, i will give a look at it

(11-11-2019, 06:42 AM)budRich Wrote: monolithic project where it will be difficult to add independent userland OS-components that are better then built in ones

Consistency is something that should exist at the same context, for example the unix tools, if you download coreutils it shouldn't be aware of all the tools that you have installed and have some consistency with them, but they should have consistency with itself.

(11-11-2019, 07:08 AM)budRich Wrote: tl;dr Do what GNOME, KDE, SystemD, Linux, GNU is doing: be the change you want to see.

I'm already doing something about that (at least to fix what i consider problems)

(11-11-2019, 07:08 AM)budRich Wrote: But there is really no point in yelling in to the void and demanding that GNOME, KDE, Firefox, GNU or whatever should become more minimal and less dependent on "bad" applications or syndromeD. "they" don't strive to be "minimal" and they are not "linux" (except for linux) or "unix" and they are probably not (you).

I agree, but i do believe that we should care about the design and implementation quality of the softwares that we use, because this is what will influence the directions and focus of new projects and even the older ones. This doesn't mean trying to "minify" GNU but using software that already does that.

Drew Devault made a website to track simplicity of projects, (supposedly) based on the functionality rather than softwares names: https://arewesimpleyet.org.

It sorts software by functionality (compilers, shells, libc, etc..) and references "sane" implementations.
I like the concept, unfortunately this is from his point of view, and the list is very (very very!) opinionated (no mention of suckless tools like scc, sbase, ...), and seems to serve as an advertisement for his own software rather than an exhaustive list.
This is a good starting point though, if you seek for simple software.

Now we can discuss what "Simple" means for software: simple to use? or simple to code/review?
I'd strive for the 2nd, as the latter is more easy to judge. Usability being such a subjective topic.

(23-11-2019, 05:28 AM)z3bra Wrote: Now we can discuss what "Simple" means for software: simple to use? or simple to code/review?
I'd strive for the 2nd, as the latter is more easy to judge. Usability being such a subjective topic.

I agree. Things that are simple to use should be called friendly or easy or something like that. Simple should mean that the thing is quite primitive. Simple things, of course, can be as well friendly.

Have I understood correctly: someone wants to create simple computer environment ignoring the things that do the same thing but are already implemented?

He's rewriting the coreutils, each being self-contained (thus no code is shared amongst utils).

The website references software that is "simple", yet many implementations other than the author's are omitted. Even well known stuff like musl libc, suckless coreutils, etc...
Making such a list it good, this one is a bit too opinionated though.

(23-11-2019, 05:28 AM)z3bra Wrote: Drew Devault made a website to track simplicity of projects, (supposedly) based on the functionality rather than softwares names: https://arewesimpleyet.org.

Interesting list, sadly the list is ignoring a lot of existing solutions that meets the given criteria, and i wouldn't say that is necessarily because of superior quality of the cited alternative (for instance ctools seems to be of lower quality than suckless base, as i consider random behaviour unacceptable).

I will citate another list with similar intent: https://wiki.musl-libc.org/alternatives.html
This one before moving to git was an open wiki, so supposedly multiple people have added something in there, sadly this list is rarely modified and there are a few dead links.

(23-11-2019, 05:28 AM)z3bra Wrote: Now we can discuss what "Simple" means for software: simple to use? or simple to code/review?

Simple shouldn't be used in a context of usage, because there's no necessary link between simplicity and easiness.

I tend to disagree, simplicity of a tool can have a direct impact on its usage.
Take a screwdriver as an example, versus a screw gun. Both serve the same purpose. The screw driver is a simpler tool, which makes it easier to use: no manual to read as long as you know what a screw is. The screw gun though is more powerful, but you MUST learn how to use it: how change change between screw/unscrew, check battery state, remove lock, change speed, etc...

In the above case, the simplicity of one tool in regard of the other is about what it can do, not how it is made.
This is the same for software. If a tool has no options to change it's behavior, it will be "simple", as in you won't struggle to use it. But the code of this soft can still be a total cluster fuck...

Software simplicity is hard if you ask me.

(25-11-2019, 04:28 AM)z3bra Wrote: I tend to disagree, simplicity of a tool can have a direct impact on its usage.

Simplicity of design doesn't dictate how friendly is the interface. Modern computers, for example, are the pinnacle of complexity, still most people learn to use them without much effort (currently more true for smartphones, but they are basically portable computers).

(25-11-2019, 04:28 AM)z3bra Wrote: In the above case, the simplicity of one tool in regard of the other is about what it can do, not how it is made.

Doing less is being minimal not necessarily simple, otherwise we could never have simplicity; one time that we mix a lot of small and simple things the result would always, at some point, be complexity. But we already exist in a state distant from simple (what would make everything that we produce complex by nature)

(25-11-2019, 04:28 AM)z3bra Wrote: Software simplicity is hard if you ask me.

True. The correct ways are always harder

(25-11-2019, 06:02 AM)eadwardus Wrote: Simplicity of design doesn't dictate how friendly is the interface.

One part of the subject that wasn't brought up is the different between inherent/essential complexity to a problem and invented/accidental/unnecessary complexity.

Some issues are complex by themselves and it's not the software that will make them simple.

(25-11-2019, 06:33 AM)venam Wrote: One part of the subject that wasn't brought up is the different between inherent/essential complexity to a problem and invented/accidental/unnecessary complexity.

Some issues are complex by themselves and it's not the software that will make them simple.

This is true, because of that we should achieve as much simplicity as possible, but not more than that (that is limiting yourself).
But i would say that most of those, if not all, problems can be broken in little pieces, what makes possible to simplify things further.