Re: [opensuse] interesting reading about systemd
-----Ursprüngliche Nachricht----- Von: Mathias Homann Gesendet: So. 02.10.2016 09:11 An: opensuse@opensuse.org Betreff: Re: [opensuse] interesting reading about systemd
Am Sonntag, 2. Oktober 2016, 08:35:36 CEST schrieb stakanov@freenet.de:
Found on Phoronix and thought to share.
" target="_blank">https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet
on Leap 42.1:
mathias@kirika:~> NOTIFY_SOCKET=/run/systemd/notify systemd-notify "" Failed to notify init system: No such file or directory
as a habit, by now I take blog posts that claim that systemd is a gigantic failure with an equally gigantic grain of salt.
Cheers MH
Well, to tell the truth, he is not saying this. His first point is that the way it is programmed (especially the "extra-gear") is not done as he would expect due to security concerns. His second point is that using interfaces that are only usable through systemd are like a vendor lock in. And in this I am quite able to follow the argument, things should stay modular. That his opinion is obviously not unbiased is already self explicative by the title. The fact that I did post it here is not to say: I endorse. But just to make it accessible. Because I think he has some interesting arguments. May be taken with salt and/or pepper. Question of personal taste :-) - --- Die Bundesliga hat begonnen! Alle Tore, alle Ergebnisse, alle News: Pocket Liga jetzt im https://app.adjust.com/dpynzd oder https://app.adjust.com/dpynzd herunterladen - kostenlos! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/02/2016 05:08 AM, stakanov@freenet.de wrote:
His second point is that using interfaces that are only usable through systemd are like a vendor lock in. And in this I am quite able to follow the argument, things should stay modular.
That that sort of misses the point, doesn't it? First the old sysv-init parts were only usable with BASH. Not the original Bourne shell, not the enhanced 1988 model Bourne shell. Not the C shall and not some of the other alternative shells. Oh, and not with Windows, either. Or the Atari, the PlayStation or the X-Box. Or VMS. Or VM/CMS. And yes, I know, each of those does 'vendor lock-in' as well. So its a fundamentally irrelevant argument. The second this is that systemd *is* modular. That it depends on sending messages via the D-Bus or sockets to the init process doesn't make it any less modular than the dependency sysv-init has on the shell, and the original arguments about interactions and side effects that ere the origination of systemd are perfectly valid criticisms of the inconsistent and unstructured approach of sysv-init and arbitrary, ungoverned shell scripts. The 'unit' approach of systemd is modular, regular, consistent and governed. In Ancient of Days, UNIX prided itself on having a very few, regular and consistent interfaces and relying on what amounted to a few basic patterns of operation and governance. You leant to few patterns rather than dealing with the huge number of interfaces and the collection of 'sui generis' operations. I recall reading about a comparison with VMS in the 1980s. A VMS developer in California commented that the bookshelf of the VMS documentation was a major threat if it collapsed on him in an earthquake. The UNIX documentation of the time, even the bloated USG version which I still have, occupied less than half a shelf. UNIX became and in turn Linux became more complex and more complicated in its interfaces and gyrations, and more arbitrary and unstructured. Saying all of sysv-init was in one place and only used the shell totally misses the point about the lack of discipline and order in those scripts. Even the 'baseline' ones of a distribution were only as 'regular' are the packager was willing to make them, and that could never be guaranteed. Once you added in 3rd party initializations, and customizations, who knows what might happen. There were no constraints, no checks. That systems go though increases in complexity with size and then a ratification as they become unmanageable is as axiomatic aspect of General System Theory. So too is that people in any population, even where the change is for the best for the whole group, resist the change for emotional reasons. Perhaps they do have too much invested in the old way of doing things. But I don't think this is the case here. Computers, software, the whole IT business is about innovation rolling 'ever onwards'. The profit lies in change. -- http://m.likesuccess.com/quotes/27/1312072.png -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 10/02/2016 05:08 AM, stakanov@freenet.de wrote:
His second point is that using interfaces that are only usable through systemd are like a vendor lock in. And in this I am quite able to follow the argument, things should stay modular.
That that sort of misses the point, doesn't it?
First the old sysv-init parts were only usable with BASH. Not the original Bourne shell, not the enhanced 1988 model Bourne shell. Not the C shall and not some of the other alternative shells.
??? Seems like it was open to POSIX compatible shells: sh/bash/ksh. What interpreter was used was specified on the 1st line. I saw many with /bin/sh, though I would guess the majority were /bin/bash because it is able to say more with less (more power, more consise).
Oh, and not with Windows, either. Or the Atari, the PlayStation or the X-Box. Or VMS. Or VM/CMS.
Neither systemd. These are *nix offerings -- but you can run bash on Windows, either under cygwin or native. From what I hear, MS will be offering bash-native as an alternative shell under Win10. If you want the POSIX startup -- run cygwin and write it. It's not that sysV can't startup the system, but MS doesn't provide the hooks for it.
And yes, I know, each of those does 'vendor lock-in' as well.
So its a fundamentally irrelevant argument.
--- Baloney! SysV doesn't put the vendor lock-in in its offering. With a shell script, it can call anything. It's important as to where the vendor lock-in is. If it is at the system level like Windows and systemd (requires it be started 1st), then you can't add to it using off-the-shelf parts that read stdin & write stdout/err.
The second this is that systemd *is* modular.
Bull. Show me where I can replace the part that sits @ pid=1 with a simple script.
That it depends on sending messages via the D-Bus or sockets to the init process doesn't make it any less modular than the dependency sysv-init has on the shell.
Sorry, but the script parts communicate with pipes and text. That's the way the *entire* user-space works. To move to requiring special formats and special sockets, etc is not open or modular.
I recall reading about a comparison with VMS in the 1980s. A VMS developer in California commented that the bookshelf of the VMS documentation was a major threat if it collapsed on him in an earthquake. The UNIX documentation of the time, even the bloated USG version which I still have, occupied less than half a shelf.
Right, because the interface between parts in Unix was *simple*. Vs. VMS/Windows/Systemd = structured and specific. You can't just "echo" a string into a DBUS socket. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/02/2016 04:28 PM, Linda Walsh wrote:
Anton Aylward wrote:
On 10/02/2016 05:08 AM, stakanov@freenet.de wrote:
His second point is that using interfaces that are only usable through systemd are like a vendor lock in. And in this I am quite able to follow the argument, things should stay modular.
That that sort of misses the point, doesn't it?
First the old sysv-init parts were only usable with BASH. Not the original Bourne shell, not the enhanced 1988 model Bourne shell. Not the C shall and not some of the other alternative shells.
??? Seems like it was open to POSIX compatible shells: sh/bash/ksh.
That's what I mean "open to..." See more below.
And yes, I know, each of those does 'vendor lock-in' as well.
So its a fundamentally irrelevant argument.
Baloney! SysV doesn't put the vendor lock-in in its offering. With a shell script, it can call anything.
Yes, that's exactly the problem,! See below.
The second this is that systemd *is* modular.
Bull. Show me where I can replace the part that sits @ pid=1 with a simple script.
You couldn't replace the old binary init program with a simple script. (Not all of its functionality. Don't confuse the running of the scripts in /etc.init.d with everything that the init/process=1 does) No more than you could replace the kernel itself with a script. In many ways the init program is the tools the kernel uses to manage top level programs. You replace that with a script and you are going to get into a lot of hazards and problems with locks and synchronization. That's not what shell programming is for!
Right, because the interface between parts in Unix was *simple*. Vs. VMS/Windows/Systemd = structured and specific. You can't just "echo" a string into a DBUS socket.
Here's the "Below" part. The problem with scripts and sysv-init was the lack of constraints and protocols. The start/stop/restart case statement structure was a convention. It was all about ad-hoc-ness. There was no concept of dependencies, or sequence other than the convention of numbering. You couldn't, as you can with systemd, make a script dependent on one other script by means of a enforced protocol, it was all "up to the programmer". The analogy I use in my presentations about the need for protocols and constraints read like this. If you paved over the whole of the earth you could drive in any direction. No constraints, not protocols, no intersections, no "give way" signs. You've got complete freedom of action. There may be conventions, but that's all they are. In reality we have streets and traffic signs and lanes, and stop signs and traffic lights to control flow at intersections. It allows us to have buildings and areas where the cars don't go, where the cars can 'rest' without being in the way of traffic. We have similar constraints and protocols for other 'traffic' such as network packets :-) The sad thing is that with cars on the road there is inadequate enforcement :-( The thing about systemd is that it introduced constraints, queues, protocols, channels of communication. And enforcement. An enforcement that wasn't available with the arbitrary shell programming of sysv-init. In many ways the coding of sysv-init was a collection of bad practices. There was a lot of 'redundancy' in, for example,e very script needing the same case statement with different bits in between. Systemd has a clean and regular API. Sysv-init has no API, it is just (arbitrary) shell programming. Back to the 'world paved over' analogy. I have, in other circumstances, reduced a large collection of similar scripts (some cron driven, mostly to do with downloading or uploading to a DB2 database on a mainframe over a sort-of-but-not-quite FTP service). The scripts there had no interlocks or flags. One function as to FTP a series of 5 files to the mainframe three times a day. There was nothing that indicated if the mainframe job had 'digested' the previous set of files. Yes, they could have been a set of flags that were FTP'd back and forth, but that required a definition of a protocol of cooperation between the mainframe programmers and the UNIX script programmers. *sigh* fat Chance! This was just one of the many FTP related script functions. Over the years many such scripts had been written. By different people. Poorly documented, if ever. Some were simply copies of each other with the hard coded settings changed. After a great deal of thought I managed to replace all these scripts with a state machine and table. It added clarity, maintainability, ease of extendibility and as a side effect it was pretty fast. There are a few basic principles I hold for good programming and one of them is to eliminate what amounts to 'stamp-copy' coding. Even at a very naive level, sysv-init could be replaced by a table-driven state machine much in the way that the Xinet system had entries for each service. I say naive; perhaps this is that Linda is thinking of when she imagines that the init (process 1) could be replaced by a script. Init does a lot more than run the scripts in /etc/init.d/. But it does not really replace process 1. It just replaces the running of the individual scripts for starting and stopping some subsystems. Early in his discussion of why he built systems, Leonard raises some other shortcoming with the script approach. Scripts, even my hypothetical state machine script driver, are fragile. And the init process has to do other things as well, and the init process of the SYSTEMV design had shortcomings as well. Systemd is FOSS. Many of the complaints about systemd aren't really an different from the ones we saw with KDE4, and now with Suse Leap 42.x. FOSS is always BOTH 'In development' and 'undergoing user testing of new features and upgrade'. Many of the criticisms that people keep voicing are now irrelevant with a more completed development. Apart from fixing many of the things that the old init code failed in, systemd also has many more advantages over init, things that init doesn't do or manage. * DBus Dependency * Device based Activation * Device dependency configuration with udev * Timer based Activation * Quota Management * Automatic Service Dependency Handling * Kills users Process at logout * Swap Management * SELinux integration * Support for Encrypted HDD * Static kernel module loading * Management GUI * List all the child processes * Interactive booting * Parallel service start-up * Resource limit per service * Automatic dependency calculation I realise that I may have to expand on the meaning of some of those rather that get into a simple 'yes-but' argument. For example the YAST tools to turn sysv-init functions on and off at different levels is not a real 'Management GUI'; its specific to Suse and doesn't manage the actual processes. I should also mention that systemd manages processes by cgroup rather than just pid. Oh, and by the way: http://blog.fpmurphy.com/2009/02/dbus-scripting.html and <quote src="http://0pointer.de/blog/projects/the-biggest-myths.html"> Myth: systemd is not scriptable, because of its D-Bus use. Not true. Pretty much every single D-Bus interface systemd provides is also available in a command line tool, for example in systemctl, loginctl, timedatectl, hostnamectl, localectl and suchlike. You can easily call these tools from shell scripts, they open up pretty much the entire API from the command line with easy-to-use commands. That said, D-Bus actually has bindings for almost any scripting language this world knows. Even from the shell you can invoke arbitrary D-Bus methods with dbus-send or gdbus. If anything, this improves scriptability due to the good support of D-Bus in the various scripting languages. </quote> -- Ah, nostalgia ain't what it used to be. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Those of us who use KDE have a GUI available for managing systemd: https://www.linux-apps.com/content/show.php/Kcmsystemd?content=161871 Available at https://software.opensuse.org/download.html?project=KDE%3AExtra&package=kcm_systemd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (3)
-
Anton Aylward -
Linda Walsh -
stakanov＠freenet.de