In this post I am trying to explain what I do not like about modern software develop practices, from code to software distribution, things are moving in a direction that feel wrong to my traditional UNIX Mindset.

Why I moved to Linux in the first place

The reason installing Linux in the early 1990s on a 386-DX 40 with 4MB RAM, was originally because I did not find a free C compiler for MSDOS, and heard that Linux comes with all kinds of stuff.

During the next years I settled with Debian, because of its huge selection of packages. This felt so nice. Like a huge puzzle consisting of thousands of small pieces that all fit together nicely! Shared libraries were a bliss, fixing bugs in one small library fixed it for all the software using it (linking against it). Minor versions of libraries made sure to have a stable ABI, while sometimes adding new APIs, and major versions where duplicated in distributions, as long as old software still depends on them.

Unlike in Windows, which had huge installers which installed the same dlls over and over again in a folder for each program you installed (apps where called programs back then :P), in Linux distributions it felt like a huge collaborative effort, an utopia, some kind of working real-life communism. The good way.

I also liked the fact that I only had to trust a single instance, being debian, which built all packages for all relevant CPU instruction sets, also making sure to fit debians free software guidelines.

The last thing I want to mention, is that C/C++ with its “zero cost abstraction” principle were meant to generate small and fast code.

To sum up what I liked about all this was:

  • small and fast executables
  • shared resources
  • easy collaboration by ensuring stable APIs and ABIs
  • distributions that put the puzzle pieces into place

New programming languages and ecosystems do it differently than C/C++ - and worse

Those are only examples, nearly every other new language/ecosystem does it the same

Python

That one really messed it up badly again. A beginners language with twisted syntax and using spaces instead of curly braces to hint at levels of code. Somehow everyone liked it. Slow, ugly and popular.

Since with python everything breaks at all time, and people do not care for stable APIs anymore, you could not even use two big python projects on one computer, that need different minor versions of a library.

The solution: virtualenv.

Seriously?

The idea, is to just install dependencies (pinned down to the minor and patch version) over and over again in some separated environment which you enter and exit every time you use a project.

Electron

Another crazy idea with what software developers came up then was: just write software for the web. Then bundle the web browser. Similarly as late-stage Java development which bundles the jre.

To be fair, web browsers offer excellent debugging support and manipulating and debugging layouts is very convenient. Yet, the end result is a web browser each, running on your system for all your favorite software. You need more ram! Signal, Element, VSCode running all the time? Make sure your new PC as as much RAM as you can afford!

And of course dependencies are also pinned down to the minor and patch versions.

Rust and Go

Both languages threw away the idea of shared libraries altogether. Instead they have a huge registry of 3rd party libraries. And the developers act like python developers. Rapid developement, no stable API for libraries.

So everything is pinned down to the minor and patch versions again. I remember a project that I built for Rust that had the “serde” crate (library) 12 (twelve!) times in different version in it’s dependency tree.

This is a vicious circle. Developers know that everyone pins down the minor version, so why having a stable API then? It wont break anything for projects depending on them as long as they keep their dependencies as is.

At least in case of Rust, it is fast, it is the only new language keeping the idea of zero cost abstraction, sometimes does it even better than C++, does huge efforts to optimize code and developers care for performance!

What does that mean for distributions like debian?

For python projects, distributions like debian would traditionally package all the python modules separately and the program package itself. But it is increasingly hard if there is such a big problem with library compatibility, even with minor versions. So important big python projects are really hard to package, if not impossible.

There is a similar problem with Go and Rust, where projects usually have a huge number of dependencies (some Rust crates only consist of ONE function). How should debian package the build dependencies, the source packages?

For Election projects with tons of npm dependencies the same problem arises.

And what if there is a security bug in a library? Debian would have to recompile all packages again, since there are no shared libraries anymore.

The result is that debian lacks more and more important software and we need multiple sources we trust and where we get software from (there is an apt source for Signal, Electron and others).

But it gets worse… with flatpaks and snaps.

Flatpack and snap

snaps (Ubuntu) and flatpaks (others) are a new form of distributing software packages that come with all their dependencies, so that the base distribution is no longer important. Both are huge. They do have some de-duplication methods to share resources, but it feels like a distribution in a distribution, some have big startup times, and do not make use of system libraries.

Flatpaks are provided on flathub, a bit of a software junkyard, where everyone throws their packages on.

Somehow it feels that Linux went more and more the Windows direction. Download software from the authors, instead from your trusted distributions.

In my opinion the design and mindset of modern languages and ecosystems played a big role in breaking what made me like linux distributions in the first place.

I wish everyone would have kept semantic versioning and shared libraries. Rust, you could have been great. But maybe I am getting to old ;)