[Discuss] systemd sucks and containers suck and language-specific package repos suck

[Steve Litt]

markw at mohawksoft.com said on Tue, 15 Sep 2026 12:20:54 -0400

> Let me
>first articulate what is wrong with the software development model in
>one word: "libraries"
>
>The "shared library" was a fantastic idea way back when systems had a
>few megabytes of storage. All programs HAD to share code or you
>couldn't fit anything on a disk. It was a brilliant solution to a very
>difficult problem, but make no mistake, it was a compromise to truly
>portable code. It was always a hindrance to interoperability because
>of the independence of versions. Static libraries are nice, but they
>too have a version issue.

I'm not taking a stand on the VM or container issue, but as far as
libraries, is the the problem really the *concept* of libraries, or is
it the ridiculous way developers use them?

From my viewpoint, a good library is like a good program: Do one thing
and do it well. Have a thin, simple interface. Because it does one
thing, there's little need to keep making new versions. The library's
code is presumably small, so if somebody needs to add a feature, it's
just as easy to fork it and keep things minimal.

But nooooo! Witness GTk. What *doesn't* it do? It
includes Graphene to do vector math. It does UTF-8 and language
handling. It has everything and a marching band: 800K lines of code.
Maybe your distro is different, but every GTk application on my
computer spews GTk warnings by the dozens to camouflage any real
warnings. 

All these functionalities should be curated by the application's
developer, not tossed into an already monstrous toolkit.

When I write an extra 100 lines of code to avoid incorporating yet
another library, I'm lectured haughtily: "Don't reinvent the wheel."
And yet these people drag in a wheel, tire, inner tube, rim strip, hub,
cones, bearings, axle, 36 spokes with nipples and a coaster brake, when
all they really needed was one spoke nipple.

And man, don't they just love to require the latest version of every
library they use? That's OK if you use a rolling release like Void, but
it really sucks with Debian/Devuan stable. And then there are those
developers who think it's fun to modify the interface (not
implementation) of their library to break every application that worked
with the old version?

Just use PIP! Just use UV! Just make a Python specific to your program.
Who cares if your backups take hours and terabytes? And what's this
absurdity of Python library developers writing non-timing-critical
Python libraries in C? Geez Louise!

I'm not going to rewrite Tk for every application, but I sure don't
need a two ton toolkit: In a sane world I could pull in what I need
a-la-carte.

Markw, I'm not defending pre-compiled shared libraries: Anybody could
predict the problems. But of course, if every library, before
compilation, was less than 1000 lines, perhaps less than 100 lines,
with today's wildly fast computers a make file could compile the whole
thing in a couple minutes, and if there were some stupid error or
warning it could be fixed with an #IFDEF or similar, and then sent back
to the library developer.

SteveT

Steve Litt 

http://444domains.com