Mailinglist Archive: opensuse (982 mails)

< Previous Next >
Re: [opensuse] Getting rid of systemd and putting sysv back
Ruben: since I subscribe to the list there is no point in cc'ing me as well.



On 09/25/2014 07:23 PM, Ruben Safir wrote:
On Thu, Sep 25, 2014 at 04:59:31PM -0400, Anton Aylward wrote:
On 09/25/2014 04:05 PM, michael norman wrote:
Goebbels.

Among quite a few other from about that time.
Yes, it was a time of ranting mad-men who held great political power,
the world over.


Really, that is quite a rant having zero to do with any topic.

YMMV.
Some do well with analogies in the real, the physical world and with
examples out of history. Those who can't learn from history, as one
philosopher said, are doomed to repeat it.





But just as with systemd, there are those who refuse to face evidence

No, that is not a rational resposonse. The problems with systemd are
deep and multiple and have beeen discusseded and can be rehashed.

And fixed.
Just like Linux has ALWAYS been, its "in development" because its FOSS.
While commercial software can afford a testing period "in house" before
release (though Apple's recent retraction after just one day of an
update that quite obviously wasn't adequately tested) the development
cycles we have rely more on 'suck it an see' by the community. People
often forget this, as was the case with KDE4 as well. Too many people
adopted 4.0 and found it, quite understandably and quite rationally,
buggy and deficient and incomplete. Well what did you expect? Now at
4.12 we have an excellent product. Yes there are still KDE3-naysayers
criticising it, but many of the criticisms are about design principle
differences, which were clearly stated up front. KDE4 was not meant to
be an evolution of KDE3; perhaps calling it "KDE" was the mistake.
Starting off with a new name might have made people less inclined to
adopt it so early.

But the flip side of that is that all those early adopters gave feedback
to the developers.

At least 'systemd' doesn't have the naming problem.

But it does have a problem with many people doing what you are doing,
Ruben and attributing shortcomings that are part of the development
process to the latest product.

"Yes it used to be, but we changed all that".

Google is being forced in EU to "forget" entries about certain people.
Perhaps we need a "forget" for the issues to do with systemd that no
longer apply.



But
it is not a "fiction" that systemd has absorbed a large number of
segments of the gnu system and has broken compatability with said
systems as well.

More "Big Lie". Sorry.
Sometimes I think of a cartoon I saw about a small boy pulling at the
loose thread on his woolly jumper. The last frame of the cartoon has
him with a big ball of wool and no jumper. In eliminating the shell
scripts of sysvinit the 'tread' leads to other things, and the API and
'declarative programming' model of systemd means other system admin
functions can make use of the API.

But as Michael Norman (I think it was) pointed out, the new generation
of Linux being used by commercial interests and to effectively use
virtual machines and chroot jails relies heavily on cgroups and the like
for resource management, then 'systemctl' is a reasonable way to manage
them and the process groups.


The fiction is that there is a need to replace the init system at all,

That is not a fiction.




let alone allow monolithic behemoth
take over everything from getty processes, login programs, serial port
emulators, logging systems, fs system mounting, device recognition and
kernel module loading, X11 startup and logging, initiation of databases,
webserver, programming environemts including cores...and this might just
be the tip of the iceberg. It is a damn nightmare, really. Then on top
of that, it is evidently written like such pure crap that Linus had to
run its developers off the kernal mailing list.


Another Big Lie. As has been shown a number of times, systemd is far
from monolithic. Much of what you bemoan is actually a more rational
way of starting, stopping and restarting functions that was present or
even available with sysvinit. The 'declarative' mechanism of the
'units' makes each item well contained and makes the dependency three
vry clear and easy to understand, something that simply is not possible
with the programmatic nature of sysvinit. That helps in debugging as
well. BTDT.

And you are wrong to say that it 'takes over'.

There are many example of this way of working in UNIX and Linux. The
big difference is that (a) the units are seperate files rather than
lines in a file, as with, for example, inetd; and (b) dependencies are
made explcit.

That latter case is interesting.
In my /etc/fstab I have to mount /home, then /home/anton, then (among
others) /home/anton/media, and once "media" is mounted only then can I
mount "music" and "photographs".

With /etc/fstab this is a matter of the lines being in the correct
order; mature users know that :-) "Mature" meaning "experienced".
"Experienced" meaning "having made a mistake and learnt from it".

Right now, one of the auxiliary programs of the systemd suite scans the
/etc/fstab and converts it to unit files with explicit dependency. I
could have simply set up the unit file myself.

See SYSTEMD.MOUNT(5)

<quote>
Mount units may either be configured via unit files, or via /etc/fstab
(see fstab(5) for details). Mounts listed in /etc/fstab will be
converted into native units dynamically at boot and when the
configuration of the system manager is reloaded. See
systemd-fstab-generator(8) for details about the conversion.
</quote>

The 'generator' is an open specification.
There is no reason someone can't write a generator to statically or
dynamically generate units, perhaps from a table.

Lets face it, there are UNIX/Linux systems out there where the
configuration is NOT in the tables in /etc/ which we are used to but in
an LDAP database. That includes such things as the user accounts and
passwords. Nothing new here; Berkeley was using databases for user
accounts back in the 1980s since even binary sorted /etc/password took
too long to parse. Eventually this became NIS/YP or on some systems LDAP.

Its not a refusal to face 'evidence'. It is being dead set against ONE
PROGRAM being resonsible for so many different aspects of the systems
operation, and making the system so damn hard to understand, alter and
to use.

Big Lie at work again.
The sysvinit setup was programmatic and the ONE PROGRAM that was
responsible for so many aspects of system operation was the shell.
To alter how things worked under sysinit you not only needed to be a
programmer, but you had to manually figure out code paths and side
effect. With systemd the init process is all declarative and very clear.

Lets face it; both the shell scripts of sysvinit and the unit files of
systemd make use of other programs. Despite the Big Lie inmplied and
often stated by the anti-systemd crowd, systemd does NOT mount file
systems, start the GUI, initiate databases or web servers. Just like
the shell code in sysvinit it makes use of axillary programs. It makes
use of 'mount' and 'unmount; of /sbin/agetty; of /usr/sbin/cron;
of /usr/sbin/avahi-daemon; of /usr/sbin/start_apache2

... and more. All that is clear simply by inspecting a running system.



Taking the vast majority of
system controls and cludging them all together as a single monolithic
program is not "New" or "innovative".

Indeed, but that's NOT what systemd is doing. Saying it is doing that
is a Big Lie. The evidence is to the contrary.

I want a simple, easy to access computer system that I can bend to my
will. I want files that I can read and understand.

Unit files are that; they are well documented; each thing addresses one
thing and one thing only; they all follow the same syntax and rules.
Sadly many scripts have been accumulated from different sources and
often don't have the same syntax and style.




This is a plain old fashion power grab.

UNIX always was a power grab.


This is a HUMAN problem. Not a technological one.


All problems are human problems.
It's humans, not turtles, all the way down.


--
"Preconceived notions are the locks on the door to wisdom".
-- Merry Browne
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
This Thread
Follow Ups