Life in general is a very complex thing. Society is a complex matter, too. Also the IT world is a complex one. And so are many of today’s programs – for the good or the bad.
In many fields complexity is a necessity. You cannot build a simple microprocessor that satisfies today’s needs. And there is no way to have a very simple kernel that can do everything that we need. I agree to that and I do not want to condemn complexity as a whole. But – and I cannot stress that enough – while more and more sophisticated programs are being developed, projects have the tendency to become overly complex. And this is what I criticize.
A bit of history
Most of my readers are probably happy users of some Unix-like operating system. Some may live long enough to have witnessed how these systems changed over time. Many of us younger ones did not and so we only know what we have read about these times (or probably not even that).
Thinking about the heritage of Unix, another OS called Multix comes to one’s mind. This system was jointly developed by AT&T, GE and the MIT. It was a sophisticated operating system which had many remarkable or even truly revolutionary features for its time. A lot of effort and money was put into it. High expectations were put on Multics. And then eventually – it failed.
AT&T had pulled out of the project when they realized that it was rather slow and overly complex. They learned from it and attempted to create a system which followed the opposite approach: Aim for simplicity. This system lead to an incredible success: Unix.
So it is important to know that enthusiasm for technology and the urge to develop more and more complex programs is not a new phenomena at all. In fact I’d claim that it is the logical consequence of how man thinks. While all things begin with relatively simple forms, complexity as a concept does not follow after the concept of simplicity. On the contrary: Simplicity is the lesson learned after realizing the downsides of complexity.
Universalism and particularism
Some people seem to be fascinated with the idea to have one tool that should do nearly everything. Let’s assume we have that tool available today. The result will be an extremely complex application which has an overwhelming number of features. There will hardly be any single person who will know all these features (let alone bring all of them to use).
Now each feature you don’t use wastes space on your drive. While this is true, it is certainly the smallest problem when you’re not working in the embedded field. A bigger one is that it will surely be of low quality: While it can do a hell of a lot of things, it is very unlikely that all of its features will be comprehensive. The program is likely to be rather slow because optimizing a very complex program is extremely difficult. The worst thing however is that it is bound to contain a high amount of bugs, too!
It is a well-known fact that program code where functions are longer than the maximum lines that fit on the screen, contain far more bugs. For some reason a lot of programmers seem not interested in writing good code but either just want to get something done or aim at too ambitious goals which make the project overly complex.
On the other hand there are projects which specialize in a single, narrow field. If you suggest a new feature it may very well happen that it will be rejected. The people who work on this project do not care for stuff just because that’s currently ultra-hip. Instead they often refer to features which are not really needed as unnecessary bloat. These programs cannot do a lot of things by themselves but excel at what they can do.
Following the later idea is the Unix way of doing things. The true power comes from the combination of specialized tools which can yield mind-blowing results when used by an experienced user.
Featuritis?
There are quite a few programs which suffer from a strange illness which could be called “featuritis”. It often makes the host look handsome and appealing for many people. This illness is usually not deadly and often invisible for quite some time. But it does bear a very destructive aspect, too…
Two of the programs recently found infected are OpenSSL and BASH. The former kept so much legacy code in the project and even re-implemented things done better by others that it was impossible to have a good overview of the whole project code. The later implements a lot of features which are hardly ever used by anybody and also uses some functions of its own which are arguably wasted code since there are better alternatives out there.
Both projects succeeded in being widely distributed but read by few and understood by even fewer. And those few didn’t look at all the obscure parts of those unclear and confusing code. This is why severe bugs could exist for a very long time before anybody ever noticed.
Probably the most important project where I diagnose a particularly intense form of featuritis is Systemd. It acts like an init system but absorbed the functionality of so many other programs by now that I’m getting dizzy thinking of it. Worse: A lot of people who have looked at it more than just a bit claim that it is badly designed and the code is rather unclean. Even worse: The developers of Systemd have had a conflict with Linus Torvalds because they broke things with their code and even refused to fix it insisting that it was not their problem! And the true tragedy is that it has spread to a great many Linux distros. Once a really bad bug is found concerning Systemd, this will probably take suffering for admins and users to a whole new level.
An exit strategy for the brave
My respect for the OpenBSD guys continues to grow the more I read about it. They claim to have a very secure OS and from what they do I can only say that they mean it. The LibreSSL fork or the SystemBSD project are just two examples that show how dead serious they are. A lot of people seem to ridicule them because there are not too many OpenBSD users out there when compared to Linux. That’s true of course. Their OS may also not be very familiar from a Linux user’s point of view and the OpenBSD guys may not be too friendly towards newbies. But they are nice enough to make their projects portable so that everybody can profit from them!
And in case you want to stick with Linux, there’s a great source for this platform as well. The guys over at suckless aim at creating programs “that suck less”. Go ahead and read a bit – especially the sucks and rocks pages! On the first one you’ll flabbergasted at how bad the situation really is with a lot of programs. Yes, they are fundamentally broken – and their developers don’t care about that. Code correctness doesn’t pay of if you just want to target the masses. But if you want to do things right it does.
Are there really people out there who care? You bet there are. Think about this topic again and try out a few alternatives. You might well find a real gem here and there – if you are able to look over some of the shortcomings compared to the well-known, featureful and bloated defaults.
eerielinux 