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

[markw at mohawksoft.com (markw at mohawksoft.com)]

> 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?

That is a very good point. I guess names make a difference but the
underlying mechanisms are the same. A library as a concept is nessisary.
The C library is, in fact, a library, but in practice I think it is
different.

Let's make a conceptual distinction between and arbitrary functional
library and an "API." A API is a very formalized interface, often by
standards and committees. A "library" is a far far less formalized system.

>
> 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.

That's fair enough, but without a formalized interface eventually you'll
run into the same problem.

>
> 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.

That is, I think, a different category. That is a "framework" and
frameworks are a dependency hellscape.

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

I think this is an example of the "library" vs "API" mentality.

>
> 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.

This is a serious problem. I was an architect at a company where a
developer had worked for about 8 months on a feature without consulting me
or anyone else on the OS/platform team. It was a pseudo-embedded project,
not really embedded, but had very very rigid standards and size
requirements and check summed binary and config directories, but I
digress. This developer didn't really understand how to program system
level stuff so he introduced "boost." OMG what a disaster. When he added
the boost libraries to the build it broke everything.

 I was against using it, but the VP asked if we could make it work because
of the work already done. I was furious, but not unreasonable. I said
that we could but it will explode the build process, cause a lot of
dependency issues on upgrades, and destabilize development process.

We incorporated it and it did exactly what I said it would. Our build guy
was constantly frustrated. They guy who brought in boost left after a few
more months. We eventually had to rewrite the feature anyway, and I tasked
that person with removing boost in the process. The dev who removed boost
was surprised that it was only used for some fairly trivial OS stuff like
threads, mutexes, and some communications stuff.

>
> 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.

I'm not sure where this mentality comes from. It may be an open source
"freedom" thing. Maybe I blame Linus Torvalds?  I have been writing
software since the 70s. I've done system level stuff since the beginning.

If you look at the Windows NT kernel and the Windows API, it manages to do
something unheard of in the Linux world, you can write a driver or
application that can go unchanged into many different versions. The NDIS
driver is a perfect example. It is a solid API that is formalized.
Additions are added and previous API entry points go unchanged and remain
supported.

The Linux kernel and the operating environment, on the other hand, changes
internal structures regularly and a driver on one version (or even a
sub-version) may need changes to to compile.

This mentality seems to permeate the open source ethos. "We have the
source code, why do we need formalized API/ABI?" I think this is just a
wrong-headed mind-set. I designed an IP based block device interface for
our product as POC. The connection protocol included a version descriptor
that would tell clients the API level that would work. It worked, it was
solid, but eventually as always happens, needed extra features. The dev
who did the additional work changed some of the API but did not change the
version descriptor. Hence, all the test code broke. I told him to back out
his changes, change the version, try to keep the existing API the same,
update the test code, test it again, then try again.

An API has to be solid and unchanging, but if it changes it should change

>
> 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.

I don't think it is the size of the library, I think it is the fluidity of
the interface.