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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org