FSFE Fellowship Blogs weblog
Why I am switching back to *BSD
I was FreeBSD user for six years and worked with it’s versions from 5.0 to 7.0. There appeared to much work with GNU/Linux related subsystems exclusively and it was easier for me to switch yet another UNIX-like operating system temporarily.
I tried several distributions but stayed exactly on Debian. My requirements were:
- mature, stable and reliable system without any bleeding edge software. I do not worry that there is no latest version of Firefox for example. Included in stable Debian’s distribution one fully satisfies me. Maybe it is not so fast as can be, but it is mature and working.
- less or more permanent distributions overall architecture without any sudden surprises after yet another packages upgrade. Of course sometimes it can not be skipped, but serious changes are always must be in a major software/distribution version that is rather seldom event.
- big collection and wide availability of various software. Debian has one of the biggest packages collection. And all of their binary compiled versions can be easily installed using single command. Of course you must trust it’s maintainers. I trust and rely on them.
- it’s basic installation should not have anything that I am going to remove as a first step. Just minimal bunch of tools and daemons. Ubuntu for example does not provide that: I have to remove huge piles of GNOME-related things and only then install my preferred ones.
Debian even now is the single distribution that can fit in those requirements. But several weeks ago I was very disappointed hearing that most part of it’s developers support integration with systemd.
You see, modern GNU/Linux-es are not a UNIX-like OS with UNIX-way hackerish concepts anymore. UNIX-es in my opinion always were very beautiful and smart programmers creations with really very elegant tasks solving. Most GNU/Linux-es lost that property.
Several decades there were quite few interprocess communication choices. Most time it is either plain text or, unfortunately, binary data floating between conveyors, pipes, domain or network sockets. Each daemon representing any subsystem can be less or more uniquely determined by socket path of pair of network address and port. In nearly all cases it can satisfy anybody.
Even at the very early days of UNIX systems hackers preferred plain text and similar driven protocols and file formats. Though rather relatively big SMTP responses are not as good as binary ones could be, exceptionally on that time slow links, hackers preferred human readable choices anyway, because they are simple, easy to debug, easy to maintain and easy to use.
But GNU/Linux does not like idea of beauty clever decisions and long time proven software. It’s developers (I can not call them hackers in most cases anymore) have to invent the wheel again and create yet another incompatible solution like several IPCs before and DBus itself. It requires heavy dependencies, it does not use well known socket-like paths and addresses, it uses unreadable binary protocol, it is slow and does neither guarantee any delivery nor has any buffering queue.
Access to various low level hardware devices used simple device node filesystem-like access. Of course many of them dictate standards existence and audio has one: Open Sound System, represented by entries inside /dev. Easy to use, easy to implement proven and mature system. If you want to stream audio data other the network you can easily use UNIX power to connect it for example with either pipe or network socket.
GNU/Linux folks do not understand that elegant solution and invent ALSA, aRts, ESD, NAS and PulseAudio at last. So many reinvented creations for rather simple thing. Of course OSS is not the right solution if you have to mix various sound inputs and outputs of both hardware and software modules. But JACK does this job pretty well. GNU/Linux developers do not think so again.
What about operating system’s initialization part? You have various daemons that should be started and controlled. You have to do various file system related steps, manage process execution somehow. All that tasks are done for a long time using shell interpreter, intended to solve them. As a fact each daemon has small shell script used to control server’s behaviour. Hackers need to glue those daemons together. For me, it seems to be very elegant solution to include trivial plain-text metainformation as script’s comments and to create symbolic links dependent on that metainfo with number included to force sorting done right, as in System V.
UNIX-way is to have many small tools, where each of them does single job, but does it well. Simple separate initialization system, simple separate logging system, simple separate shell interpreters, simple IPC socket-oriented libraries, simple daemons, cron, inetd and so on. Looks simple, clear and nice.
You are wrong! Modern GNU/Linux-es can not accept that, because they are missing written on compiled language (does not depend on already existing software for controlling process flows (shells)) program, with own IPC dependency, with own declarative language bloated combine of initialization, logging, cron/at-ing, inetd-ing and DBus/socket listening systems at once. Wait, systemd is pretty modular: several dozens of separate executable. Hackerish SysV is just a shell interpreter with several shell-scripts. Thirty years ago logs have been written on rather small hard drives in plain text, but today seems that hard drives became much smaller and more expensive and systemd decided to write human unreadable and unprocessable with any kind of sed/awk/shell/perl tools binary logs.
I still do not understand why GNOME and derivative distributions (I am sure that udev, systemd, dbus and GNOME are single aggregate) does not use very simple mailcap-files to decide what to do with various kinds of data. mailcap contains plain text lines with data content type and shell script code saying what program you need to run and apply to data. Just find the line by it’s content type and execute related command line. This can be done with single sed call. Just simple plain text file to rule all user’s software preferences. GNOME has to prerun software that will register itself on DBus (should be already running), then another software must create proper message, send it over DBus hoping that someone with catch it doing probably what user wants. It is awful.
And at last I see in Debian maillists that they are going to remove local sendmail server. I see what is happening: when systems are created by very clever hackers — they are very cool for educated technicians and other hackers. When ordinary labour crowd is falling in this world: it will be ruined. Usenet was destroyed like that. Email etiquette has mostly disappeared and replaced by top-posted huge quoted HTML messages, after user-friendly email clients born.
Security is not compatible with user-friendliness. Simple clever hacks are not compatible with classical user’s world of view. Developers never speaks users on the same language. There is always separation of developer-friendly and user-friendly. They can not coexists together, as like servers are pretty different from desktops.
Current Debian is very developer and server friendly system, while Ubuntu is aimed to be user-friendly. Systemd is great for desktop requirements, so let’s integrate it to desktop system. Why one is going to replace cron/at, SysV/rc, inetd, sockets, syslog, devnodes with single all-in-one bloated monolithic combine and remove sendmail? What will stay from UNIX itself? Arch Linux is going to mess /bin and /sbin with /usr/bin. So I won’t even find /bin/sh in that OS. It is not UNIX-like system anymore. It is yet another unmaintainable crap of compiled monolithic POSIX-compatible (hope so) code.
Of course there are really true hackerish UNIX-like GNU/Linux distributions, but all known ones require much manual work with them. Free software *BSD does not, as it has cool port collections and well maintained high quality overall system’s design (not a pile of absolutely different software pieces).