Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 15 Feb 2020 09:12:38 -0500
From:      Greg Veldman <freebsd@gregv.net>
To:        Vincent DEFERT <20.100@defert.com>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Technological advantages over Linux
Message-ID:  <20200215141238.GY1879@aurora.gregv.net>
In-Reply-To: <fde4cbec-efa0-de36-18f9-696e5cdfea3d@defert.com>
References:  <mailman.19358.1581761921.21074.freebsd-questions@freebsd.org> <fde4cbec-efa0-de36-18f9-696e5cdfea3d@defert.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Sat, Feb 15, 2020 at 12:23:37PM +0100, Vincent DEFERT wrote:
> IMO, the real problem with systemd has nothing to do with the supposed 
> mental disorder affecting its developer, but with the fact that systemd 
> control the behavior of all system services and this is what has made me 
> look for alternatives to Linux.

The insanity of systemd is a large part of what convinced me
to migrate all my personal machines from GNU/Linux to FreeBSD
a couple of years ago.

I use the term insanity loosely, to cover everything from certain
design decisions to how the change was implemented on several
popular distros...

> A very concrete example: the DHCP client of a machine doesn't behave the 
> same way with or without systemd. When run without systemd (e.g under 
> Devuan), the DHCP client honors all the features described in the 
> standard. When run under the control of systemd (e.g under Debian), it 
> just takes the IP address, netmask and gateway from the DHCP server.
> 
> Simply stated, the behavior of a machine under the control of systemd is 
> no longer predictable, you have to forget standards and RFCs and learn 
> the systemd way.

Here's another concrete example: just yesterday I spent literally
three hours debugging a post action hook function in a popular
PHP application.  This function was, at the end of processing a
record, supposed to update certain data relating to that record
into a PostgreSQL database.  Everything worked exactly as it was
supposed to when running all the steps individually by hand, but
when run through the production webserver environment it simply
refused to fire.  After much poking around, I figured out that
a recent update to the system changed the systemd unit file for
the php-fpm process to set PrivateTmp=true, which was causing
the prod environment to no longer be able to see the PostgreSQL
socket which lived in /tmp (the real /tmp).

I know of no words to fully describe the magnitude of this
facepalm, which was foisted upon me with no notice or warning
as part of applying routine patches to the operating system.

-- 
Greg Veldman
freebsd@gregv.net



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20200215141238.GY1879>