Path towards future

Created on 2018-01-09 18:49

Published on 2018-01-09 19:54

I am a long time Unix (Linux mostly) user. I have started with Linux somewhere in 1995 having the first distribution on about 40 1.44 MBytes disks. After about one week of struggle I succeeded to run fvwm under X. Then I become a fan. Everything seemed natural and easier in Linux than in DOS or even Windows.

As the time passed I learnt more and more about Unices. I worked with FreeBSD, OS-X and Solaris. Each of these had some features that I really wanted to be available in Linux.

When I first worked with Solaris 10 I hated SMF. But after some time I discovered that it was better than the BSD init or SystemV init on Linux. I liked the declarative approach and simple dependency between services. I looked for some similar solutions on Linux but I was not able to find something at the same level. Apple's launchd was promising but licensing issues and plist editing were show stoppers. Upstart seemed always half cooked, somewhere between init and SMF. OpenRC was good but quite niched. So when "systemd" appeared I felt that it really happened for Linux to gain a major uplift. systemd solved many things I was missing in old init systems. Automatic daemon restarts and monitoring (I used to have monit for this), uniform syntax for service startup files (INI syntax is easier to maintain than XML especially over slow lines to remote systems using vim), device management, no more fancy shell scripting in the files, programability (it offered APIs). Working with systemd made some of the mundane tasks of creating installable packages bearable. When I started to use ansible tools I also remarked how easy was to control the behaviour of the system through systemd interfaces and tools. Farewell init! I have never looked back on it since then. Frankly I do not understand why people hate systemd so much. For me it solved most of the issues so I am on its bandwagon.

Another thing I wished for is easy install of application as OS-X drag and drop. On Unices this is still problematic. Deb, rpm and other package formats are managed by a myriad of tools (yum, dnf, apt, aur, zypper, pkg, ips, ...) each one with different syntax and options. A nightmare. Then, around 2008 I discovered GoboLinux, a distribution that really did something in the direction of simpler package management. Gobo abolished FHS and offered a better alernative. Every application is installed in its own directory and from there is symlinked to a central location. Traditional Unix directories are hidden from the user at kernel level hence offering a clean view over the system. Pretty neat. Even nowadays some things as flatpack cannot achieve this.

A third thing I wished for was dtrace on Linux. Solaris, FreeBSD and OS-X have it but on Linux there was no similar software. Not even something as mdb was available on Linux. Dtrace made the supervision of systems easy. It was lightweight and extensible. I was able to monitor realtime priority processes on Solaris with as little as 5% performance hit. Only recently dtrace started to be developed on Linux but it's not yet ready for primetime. That's kind of sad as it would be invaluable in the current context of cloud application where metrics and performance are crucial for scalability decisions. Dtrace would enable telemetry at a very low cost even for applications that were not built with telemetry options.

I have the impression that Linux is slowly moving towards something more future oriented while still keeping ties with its Unix origins. I do not feel that these are breaking Unix philosophy but rather offer an up to date tooling while holding the same old truths and principles in place.

As Arthur Schopenhauer said: "All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident". The same in my opinion will happen with some of these. They will become parts of the next generation Linux distributions overcoming all the present opposition.