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