From owner-freebsd-questions@freebsd.org Sat Feb 15 14:12:48 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5CEC823C6B3 for ; Sat, 15 Feb 2020 14:12:48 +0000 (UTC) (envelope-from freebsd@gregv.net) Received: from aurora.gregv.net (aurora.gregv.net [192.111.144.138]) by mx1.freebsd.org (Postfix) with ESMTP id 48KXJb3WQ4z4J9J for ; Sat, 15 Feb 2020 14:12:47 +0000 (UTC) (envelope-from freebsd@gregv.net) Received: by aurora.gregv.net (Postfix, from userid 1001) id E2A5711; Sat, 15 Feb 2020 09:12:38 -0500 (EST) Date: Sat, 15 Feb 2020 09:12:38 -0500 From: Greg Veldman 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> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Rspamd-Queue-Id: 48KXJb3WQ4z4J9J X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@gregv.net has no SPF policy when checking 192.111.144.138) smtp.mailfrom=freebsd@gregv.net X-Spamd-Result: default: False [3.72 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[gregv.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.73)[0.730,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.96)[0.964,0]; R_SPF_NA(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:31863, ipnet:192.111.144.0/20, country:US]; IP_SCORE(1.12)[ipnet: 192.111.144.0/20(2.06), asn: 31863(3.62), country: US(-0.05)] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 14:12:48 -0000 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