Why I am switching back to *BSD
Набрёл тут на свою же статью восьмилетней давности. Уже тогда я вернулся
на BSD, не было больше сил терпеть переход Debian на systemd. Любопытно
было прочитать это самому, ибо сейчас я точно по другому выражаюсь. Я
правда не понял почему я написал что юзал FreeBSD с 5.0-ой версии, ведь
у меня ж до сих пор живы четыре CD-диска с 4.5, в которой я выходил из
vi кнопкой reset.
I was FreeBSD user for six years and worked with it’s versions from
5.0 to 7.0. There appeared too 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
* 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
* 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
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
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
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
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).