Mailinglist Archive: opensuse (856 mails)

< Previous Next >
Re: [opensuse] Re: interesting reading about systemd - Sunday reply
On 10/02/2016 04:28 PM, Linda Walsh wrote:
Anton Aylward wrote:
On 10/02/2016 05:08 AM, stakanov@xxxxxxxxxx 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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
This Thread