From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2675 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Steve Litt Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: The "Unix Philosophy 2020" document Date: Sat, 12 Oct 2019 14:58:59 -0400 Message-ID: <20191012145859.1b568c45@mydesk.domain.cxm> References: <20190831130730.ki6ma7i5curucowe@caspervector> <20190901091157.bjtfhqq6d2rg75yo@CasperVector> <20190927083816.tectynx7dzlfcvb7@CasperVector> <20191012173743.drzlgnrw4hib6hh4@CasperVector> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="248295"; mail-complaints-to="usenet@blaine.gmane.org" Cc: "Casper Ti. Vector" To: supervision@list.skarnet.org Original-X-From: supervision-return-2265-gcsg-supervision=m.gmane.org@list.skarnet.org Sat Oct 12 20:59:07 2019 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iJMba-0012UT-Qg for gcsg-supervision@m.gmane.org; Sat, 12 Oct 2019 20:59:07 +0200 Original-Received: (qmail 26502 invoked by uid 89); 12 Oct 2019 18:59:32 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Original-Received: (qmail 26495 invoked from network); 12 Oct 2019 18:59:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; h=X-Originating-IP:Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:X-Mailer:MIME-Version:Content-Type:Content-Transfer-Encoding; s=default; d=troubleshooters.com; b=BjP7UOk0jYs7pII2xfISplr5jQgGfjGuETjgtt8RohCmZ0QeP2W9iGrg6uMHpg6cpeElShHT9pW4f89cPc+wrvVjx4qk3bmF6sldWkE2cBjuAeFw5Ezz6MDs3hbZhKW1sqmd/353a0kaVIvsCsTvRR2uHd1DO00DYyBlI0qRFlM=; DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=troubleshooters.com; s=default; t=1570906740; bh=rSXJZq210FsqxkEEtxwNMyx2ENI=; l=2993; h=X-Originating-IP:Date:From:To:Cc:Subject:Message-ID:In-Reply-To: References:X-Mailer:MIME-Version:Content-Type: Content-Transfer-Encoding; b=kJBIfN/t6QEZpHRfCLAb/HxiE5B5v3YpFYOh7P3WZLiZqmqTpjwwkgfXPEtYOV0Pw QOtIQuv2OuH63KJfARBKTGLtIeetqnl80EpQso/9J/cBooPmh0voOHW8806hw0Fymf L9tdyHj6Xmj5MISk1zC5McQxZTHOY1rdpza66p30= X-Originating-IP: [72.188.224.222] In-Reply-To: <20191012173743.drzlgnrw4hib6hh4@CasperVector> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-unknown-linux-gnu) Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2675 Archived-At: On Sun, 13 Oct 2019 01:37:43 +0800 "Casper Ti. Vector" wrote: > However, people told me that the document is not quite accessible to > those who know really little about systemd: one example is they do not > even know much about how the modules are organised in systemd, so the > claim that the systemd architecture has how cohesion and high coupling > may seem unfounded; Hi Casper, About not knowing how systemd modules are organized: NOBODY knows that except Poettering et. al. To my knowledge, there has never been published a systemd block diagram with both the blocks and the interaction lines between those blocks. Systemd "block diagrams" are typically a bunch of blocks in layers, which indicates nothing about how they're organized. So if you defined how the modules were organized, as a block diagram, you would be the first. Contrast this situation with sane init or supervision systems. Here's my block diagram of daemontools: http://www.troubleshooters.com/linux/djbdns/daemontools_intro.htm#daemontools_mental_model If I were to modify that block diagram for runit, the "system boot" and "inittab" would be replaced by runit-init, /etc/runit/1, and /etc/runit/2, with the latter exec'ing (being replaced by) the runit equivalent of svscanboot. With my understanding of s6, if I were to modify it for s6, I'd have the s6 PID1 do some initial stuff, then exec (be replaced by) an executable that does exactly two things: 1) Listen for and act on appropriate signals 2) Supervise the s6 supervisor, which on my diagram is svscanboot. So with s6, PID1 becomes a supervisor that supervises one program, the main supervisor (did I finally get that right, Laurent?) Look at the situation. For daemontools type stuff, a guy who is a Troubleshooting Process Trainer, an office automation Programmer, a tech writer and an author (in other words, NOT an expert on inits) can draw a complete and reasonably accurate block diagram including interaction lines, whereas with systemd the millions of dollars Red Hat spends on the "best and brightest" to produce, maintain, and evangelize systemd cannot produce such a diagram for systemd. This is telling. So when the systemd fanboiz tell you that you haven't provided systemd module interaction, tell them that information is not available, and that's excellent evidence of cohesion, high coupling, and gratuitous complexity. Here's another diagram I use when speaking to those who claim systemd is modular because it has modules: http://troubleshooters.com/linux/systemd/lol_systemd.htm And when speaking with somebody knowledgeable enough to say that all that gratuitous crosstalk goes through one channel, namely dbus, tell them that doesn't matter a bit, because the crosstalk still happens. SteveT Steve Litt Author: The Key to Everyday Excellence http://www.troubleshooters.com/key Twitter: http://www.twitter.com/stevelitt