Why use a *nux distro?

[nova++]

I feel like relying on a completely unmaintained application for something security-critical is its own problem...

[Graf Zahl]

[quote="Chris"}
[/quote]
/usr/lib/x86_64-linux-gnu is 3.4 GB here. If each app kept its own copy of all the libraries it uses, or even if identical versions were merged while every minor update was installed side-by-side for each app built against a slightly different version, that would be a fair bit of space taken up. Maybe not a lot a lot, but still way more than necessary.
[/quote]

The big question here is, how much do the apps actually use from this?
Normally it's only a small part that gets frequently reused by different applications.

[Graf Zahl]

I feel like relying on a completely unmaintained application for something security-critical is its own problem...

Yes, sure it is. But swapping out some third party library, vulnerability fix or not, is also a gamble. Who knows what side effects there may be?

[Chris]

The big question here is, how much do the apps actually use from this?
Normally it's only a small part that gets frequently reused by different applications.

That's not something that can be easily answered without looking at what libraries all these apps use.

It doesn't help when apps want to use unnecessary bloated middleware. Like simple 2D sidescrolling platformers being built on Unity (or maybe more site-relevant, ports of Doom 1 and Doom 2 using Unity and each game having its own copy of the engine, turning what could be a few dozen megs per game into hundreds if not gigabytes). Or otherwise simple GUI apps using their own copies of Electron.

[Graf Zahl]

Most of the time this binary bloat is relatively minor compared to the data these apps use. On my system all application installations combined use 20 GB, that's 2% of my hard drive - and half of it is Visual Studio alone.

I don't think it'd look much different on Linux - but in many cases all those dependencies simply cause more trouble than the little storage space they save.

[dpJudas]

It doesn't help when apps want to use unnecessary bloated middleware. Like simple 2D sidescrolling platformers being built on Unity (or maybe more site-relevant, ports of Doom 1 and Doom 2 using Unity and each game having its own copy of the engine, turning what could be a few dozen megs per game into hundreds if not gigabytes). Or otherwise simple GUI apps using their own copies of Electron.

Sharing Electron between apps would be a complete nightmare. The HTML/CSS/Javascript they are made out of is usually miraculously working just with what they tested it on and if you replace the browser engine with a new one it most certainly would break some of the applications. Same thing applies to games - the people coding those are more artists than professional developers. Those two examples you picked are very good examples of why you do not want them all to be updated from a shared location.

[Chris]

Sharing Electron between apps would be a complete nightmare.

Sure, that was more to point out apps using unnecessarily large middleware for what they need. Electron apps are basically a web app bundled with some build of chromium, which is extreme overkill for most (if not all) GUI apps that use it, creating a lot of resource waste (in terms of storage, memory use, and CPU use). Using a more purpose-built solution, like Qt for example, would result in a smaller footprint from the get go, making the separation less problematic, but also have more capacity to share modules and further reduce bloat.

[Graf Zahl]

You won't be able to convince developers to forfeit the advantages of web development for a bit of memory savings or performance.
But with Electron apps you only solve half the problems with shared libraries - they have enough bloat from all the Javascript modules they need to tag along.

BTW, Visual Studio Code is 300 MB overall, so you still can install a few 100 of such bloatware products before you run into HD space issues.

[Marisa the Magician]

Most of the time this binary bloat is relatively minor compared to the data these apps use. On my system all application installations combined use 20 GB, that's 2% of my hard drive - and half of it is Visual Studio alone.

I don't think it'd look much different on Linux - but in many cases all those dependencies simply cause more trouble than the little storage space they save.

On my system I have several thousand packages installed, including several "large" ones, and the total space they take amounts to about 6GB. (I'm obviously not counting all the "caches" and other user data for browsers, electron apps, gpu drivers, steam, wine, etc. Those take up a bit more)

[dpJudas]

On my computer Apex Legends uses 105 GB of disk space (10% of my disk). Just to put all these sizes into perspective on modern computers.

[Graf Zahl]

On my system the two largest chunks are my "programming" folder containing all my MSVC projects and my "games" folder. Those 2 are more than half my used hard drive space.
So the entire "binary bloat" thing appears to be a bit exaggerated...

[nova++]

Something for consideration: Statically compiled libraries can have unneeded parts optimized away by the compiler, whereas shared libraries cannot seeing as as-yet-unspecified applications may need them.

Over-bloated software is an independent issue for the most part IMO, although there is overlap with dynamic vs static libraries. But let's not let this turn into a "MY filesystem is smaller than YOUR filesystem" slap fight or something.

[Marisa the Magician]

Well, I'm just saying, that MAYBE having shared libraries between different programs does help reduce redundancy at a large scale. People can have all their reasons against the way Linux distros handle stuff, but there are advantages too.

[nova++]

Nothing wrong with it being a case-by-case thing, either. In my own case, for linux (and windows!) versions of anything I release I want to make it as light on dependencies as possible.

[Rachael]

The drawbacks may outweigh the benefits for some people, but that isn't always the case. Personally I was never trying to say there were no benefits to that system at all - just that too many times I've been burned by incompatibilities by individual component upgrades where this kind of thing simply does not happen in Windows almost ever, if even at all (well, okay, DirectDraw was an exception ....), and therefore, I do honestly see more drawbacks than benefits.

It always depends, of course, on how your system is designed and engineered, and how you actually use it. Having a 6 GB system sure is nice, but it's not a system that I really can honestly see myself using. I would rather have my apps be self-contained.