systemd

This forum is for general chat between members about Mageia.

Technical questions are supposed to be posted in support forums. Not here !

systemd

Postby duncangareth » Nov 8th, '14, 11:25

Greetings

I am very unhappy about the adoption of systemd. I do not like its monolithic binary approach. Sysvinit may not be perfect, but it is simple and the fact that it is shell script based is a benefit rather than an impediment. Debugging systemd related errors for hours and hours does not improve my sense of humour in any way whatsoever. After a recent series of updates, I found that my localhost based httpd server stopped working. I need it to work so that I can complete some website development jobs that I have.
I have no desire to spend a lot of time trying to find the cause of the problem in the huge convolution of systemd files.

I am afraid that I may have to either revert to an older pre-systemd version of Mageia or else go back to the very first Linux distro that I ever used, Slackware. I don't have time to mess about with Gentoo, which could be an option.

Apropos of systemd's documentation, I do not find it very helpful.

I think the developers of systemd need to read up on that which distinguishes UNIX and UNIX-derived systems like Linux distros from proprietary systems:

http://www.linfo.org/unix_philosophy.html

systemd is monolithic and obscure. Surely Mageia can do better!

I beg the developers of this fine distro to consider offering users a non-systemd alternative.

Some of us prefer using shell scripts to bloated GUI interfaces to perform various system tasks.

Contrary to what I said about changing to Slackware, I am prepared to continue using Mageia, under protest.

Love, Peace and all that jazz,

Duncan
duncangareth
 
Posts: 66
Joined: Oct 24th, '13, 21:05

Postby dglent » Nov 8th, '14, 16:31

I don't know* too much for systemd but it seems that we have to follow the "big" so we have no choice, except if we will have the necessary developers to maintain something else (sysvinit....)

a message from the systemd creator:
https://plus.google.com/u/0/+LennartPoe ... 2TZrTvu7vd

and another one from a kernel developer:
https://plus.google.com/u/0/+StevenRost ... tGhnM4jVoP

* although i understand very well the following from the second link:

[...]SysV init needed a replacement. And systemd can be that and much more. But your refusal to help make the transition easier, I consider laziness. You don't want to be bothered with a method of handling no cgroups. Debian's systemd-shim interface is filled with bugs (you're not directly responsible for that, but I blame you for its design). You do come across as arrogant and the my-way-or-the-highway approach is what is pissing so many people off. One thing I've learned from working in Open Source community for the last 16 years, is that people that say they know better than everyone else are the ones that are not treated well by the community. But those that are willing to collaborate, and listen to others before pushing their own methods are welcomed with open arms.[...]
User avatar
dglent
 
Posts: 186
Joined: Mar 30th, '11, 07:04
Location: Paris region, France

Re: systemd

Postby doktor5000 » Nov 8th, '14, 18:33

duncangareth wrote:Apropos of systemd's documentation, I do not find it very helpful.

I think the developers of systemd need to read up on that which distinguishes UNIX and UNIX-derived systems like Linux distros from proprietary systems:

http://www.linfo.org/unix_philosophy.html

systemd is monolithic and obscure. Surely Mageia can do better!

Which part of the documentation you don't find helpful? And what is lacking?

You do know that unix systems were and are still proprietary for the most part. Also unix != linux, this is a simple thing that most people get wrong.

And if you don't want to use systemd, feel free to use one of the distros that don't use it. Check e.g. the lower section of http://boycottsystemd.org/ for a rundown.

You may also not be aware that linux accounts for many major improvements compared to even current unices.
And I'm operating unix daily, so this is not just wishful thinking, just pure facts.

If you think Mageia can do better, feel free to send patches and take maintenance and development for whatever alternative you propose.
Cauldron is not for the faint of heart!
Caution: Hot, bubbling magic inside. May explode or cook your kittens!
----
Disclaimer: Beware of allergic reactions in answer to unconstructive complaint-type posts
User avatar
doktor5000
 
Posts: 17630
Joined: Jun 4th, '11, 10:10
Location: Leipzig, Germany

Re: systemd

Postby jiml8 » Nov 9th, '14, 09:10

I have not paid a great deal of attention to systemd. My impression of it was that it was intended to replace the old system V init scripts and I could see why that would happen. I have considered systemd to be rather unnecessarily complex and obscure, but against that I really have not taken much time to learn about it; I have been focused on other things.

However, having just read a number of articles, messages, and blog posts that this thread pointed me toward, I find my attention on systemd to be much more focused, and now hardening against systemd.

Although the evidence was in front of me, I had not focused in on the fact that systemd is behind the recent problems I have had booting my system, and systemd is the reason why, when one component of the boot fails for whatever reason, the whole boot process goes off the rails.

I have observed - and commented - that it is not acceptable that the system should fail to even reach emergency mode when a hard drive is either missing or failed to start. Particularly this should not be true if the drive that fails is a non-essential drive - that is, a drive that does not contain the system. That never used to be the situation, and is the situation now that systemd has taken over drive detections.

I also have noted how systemd mishandling rc.local (either because I formatted it wrong - and it is significant that no one here can tell me how I formatted it wrong - or because of a bug in systemd) causes much of the rest of the boot to fail - including the loss of my consoles after I manually intervene in the failed boot to kill a hung process (plymouth boot screen) and manually restart dm. I was totally mystified by why my consoles would vanish...until I read that systemd has taken over the presentation of consoles.

Systemd is apparently spreading; one post discussed that systemd intends to take over netlink (!!!). What is up with that? This is all wrong. Linux has always been mix and match, plug and play. One program for one function. This is true even for the kernel, within the kernel. Now we seem to have this monolithic architecture growing up in the middle of the system, absorbing function after function, apparently not cooperating with alternative methods, and causing Windows-like failures, where a failure here causes something over there (that should be totally unrelated) to stop working.

I had not realized how pervasive systemd was becoming.

This is the wrong way for Linux to go. This is not progress.
jiml8
 
Posts: 1253
Joined: Jul 7th, '13, 18:09

Re: systemd

Postby syschuck » Nov 10th, '14, 21:18

First off, I want to say that of all of the Linux distributions out there, Mageia is hands down my favorite. This is coming from a Unix veteran dating all the way back to Ultrix on a VAX 780. I downloaded linux 0.x something from Usenet. In my twenties, I was administrator of a Plex P75 running AT&T SystemV that had about 60 terminals and 20 modems attached to it (for a 68020 it was impressive at 20Mhz). It was on that machine I came to know the purpose of the /etc/inittab and the run levels. Run level 1, was single user, 2 was multi-user with getty on terminals, 3 was getty on modem banks, 4 was modem and terminals, 5 was everything (We didn't have X windows or a network stack then). Anyway, it was cool because you could turn on all of the terminals with telinit 2, and then add modem banks, telinit 4, and at night time, to run a bbs, you would telinit 3. And you could put it in a 1 like crontab entry. All this was controlled by a simple well documented /etc/inittab. Over the years, I've really grown accustom to it, and all of the /etc/init.d/rc.X. In fact one reason I like Mandrake, Mandriva, and Mageia over all other distros has been the quality of /etc/init.d scripts. I like the 'chkconfig' program, the rc helper functions. When it would boot, you knew exactly what was going on, step by step, script by script.

Then with Mageia3 systemd was introduced and I was building a cluster of 20 diskless PCs booting pex from a Master node. I had not kept up how drastic the systemd change would be so I expected this to be and easy job. Geeze, was I sourly mistaken! I couldn't even find the system logs, not on the master nor on the leaf nodes. That week I became a systemd hater. First, binary log files are useless. I see no advantage to using 'journalctl' over 'cat'. Is there an equivalent to 'tail -f' ? Please tell me in journalctl speak. The second thing that got me was how the virtual terminals are activated at the very end of start-up. If the boot-up processes never makes it to the end, you will never have a virtual terminal that can open. If the main console is frozen from a crashed systemd thing, then your hosed and there is no way to take control of your machine. In the old /etc/inittab the virtual terminals were one of the first features enabled, which would make debugging much easier if the console crashed.

Unfortunately it is very common (to common IMHO) for a fight to occur between the Nouvia drivers and the Proprietary Nvidia drivers and have the console lock up. Without the virtual terminals there is no way to manually fix the /etc/X11/xorg.conf file. That means a hard reboot and a potentially corrupt filesystem. So in my opinion, that is a bug in systemd.

The fact that there are 42+ binaries, 250+ config files, and what appears to be 4-5 different directories used to store this bloated spaghetti, I can tell you with all certainty, systemd is NOT an elegant simple way of doing things. With all of that, I can never really tell what the system is doing. In the case of the 20 diskless Pex nodes running I was able to get it to a bash prompt and gave up in frustration because of systemd.

So here is how you improve systemd. Dump the binary logs (it's not needed). Start the Virtual terminals early in the boot cycle. Enable some meaningful debugging (debug consoles?) If a daemon is waiting for a socket, I would like to know that it's waiting for a socket. When it's booting and going through it check lists, I would be nice to know if it's kernel related, daemon related, or application related. Allow of the boot to be interrupted. And document how systemd can be manipulated through the kernels startup command line.

I know that is a little harsh, and it's probably been said before in other forums. But man, systemd has burned me one to many times.
syschuck
 
Posts: 15
Joined: Jul 4th, '13, 04:06

Re: systemd

Postby doktor5000 » Nov 10th, '14, 21:34

syschuck wrote:So here is how you improve systemd. Dump the binary logs (it's not needed). Start the Virtual terminals early in the boot cycle. Enable some meaningful debugging (debug consoles?) If a daemon is waiting for a socket, I would like to know that it's waiting for a socket. When it's booting and going through it check lists, I would be nice to know if it's kernel related, daemon related, or application related. Allow of the boot to be interrupted. And document how systemd can be manipulated through the kernels startup command line.

For the binary logs, feel free to discuss that upstream. You're aware that systemd is not our invention?
debug consoles are dead easy, you can even enable one from the kernel command line. Check e.g. http://freedesktop.org/wiki/Software/systemd/Debugging/
You can also easily forward systemd and all of the initscript output to console or e.g. to tty12 like in the old days. http://fedoraproject.org/wiki/How_to_de ... d_problems and https://wiki.archlinux.org/index.php/sy ... ev.2Ftty12
For the kernel command line, that is also documented: http://www.freedesktop.org/software/sys ... -line.html
Cauldron is not for the faint of heart!
Caution: Hot, bubbling magic inside. May explode or cook your kittens!
----
Disclaimer: Beware of allergic reactions in answer to unconstructive complaint-type posts
User avatar
doktor5000
 
Posts: 17630
Joined: Jun 4th, '11, 10:10
Location: Leipzig, Germany

Re: systemd

Postby martinw » Nov 10th, '14, 22:48

syschuck wrote:I couldn't even find the system logs, not on the master nor on the leaf nodes.

Nor could I when I first installed Mageia-3, but reading the "README" file in /var/log soon solved that problem.
I see no advantage to using 'journalctl' over 'cat'. Is there an equivalent to 'tail -f' ? Please tell me in journalctl speak.

'man journalctl' answers that question:
Code: Select all
OPTIONS
       ...
       -f, --follow
           Show only the most recent journal entries, and continuously print
           new entries as they are appended to the journal.

Note also that you don't have to use the journald service, you can install and use one of the old syslog packages, as mentioned in the /var/log/README file (admittedly I've not tried this myself, so can't vouch for whether it works in Mageia).
martinw
 
Posts: 609
Joined: May 14th, '11, 10:59

Re: systemd

Postby jiml8 » Nov 10th, '14, 23:01

Syslog continues to work fine in Mageia. I continue to use it.

And, I agree absolutely with the comments about binary log files; it is (IMO) neither necessary nor desirable, and it will cause some monitoring things that depend on reading the log file to break (blockhosts for instance, which I make use of to terminate ssh attacks).
jiml8
 
Posts: 1253
Joined: Jul 7th, '13, 18:09

Re: systemd

Postby doktor5000 » Nov 10th, '14, 23:05

martinw wrote:Note also that you don't have to use the journald service, you can install and use one of the old syslog packages, as mentioned in the /var/log/README file (admittedly I've not tried this myself, so can't vouch for whether it works in Mageia).

Yes, install the virtual provide "syslog-daemon" which resolves to either syslog-ng or rsyslog and you get free forwarding to plain old syslog.

@jiml8: For that or things like logwatch, you may want to have a look at journal-triggerd: http://jjacky.com/2013-10-06-run-trigge ... -messages/
Cauldron is not for the faint of heart!
Caution: Hot, bubbling magic inside. May explode or cook your kittens!
----
Disclaimer: Beware of allergic reactions in answer to unconstructive complaint-type posts
User avatar
doktor5000
 
Posts: 17630
Joined: Jun 4th, '11, 10:10
Location: Leipzig, Germany

Re: systemd

Postby ITA84 » Nov 11th, '14, 14:14

syschuck wrote:The second thing that got me was how the virtual terminals are activated at the very end of start-up.

I suppose you could edit some unit files to do this, but I don't know which ones, and maybe logind could get in the way.
That reminds me: will things change when virtual terminals become userspace (or whatever that VT_CONFIG kernel change is supposed to do)?

If a daemon is waiting for a socket, I would like to know that it's waiting for a socket.

Not sure what you mean by that (do you have an example with SysVinit?); other than looking at the logs, of course.

When it's booting and going through it check lists, I would be nice to know if it's kernel related, daemon related, or application related.

I don't get this either. Are you talking about a daemon or systemd? What check lists? What is related? With journalctl -k you get kernel log messages, while application logs shouldn't be in the journal, I think.

EDIT: about interrupting boot, it's not the default, but services with StandardInput=tty should be able to receive signals (like Ctrl+C) from the terminal, so if you have some services that you believe could hang, using that option should allow you to terminate them anytime. Note that this works for services, sockets and mount points.
ITA84
 
Posts: 199
Joined: Mar 5th, '13, 18:15

Re: systemd

Postby syschuck » Nov 13th, '14, 19:38

You know, if we are forced to use this systemd initialization let me add a few more items I would fix,

Directories. All of the startup is located in /usr/lib/systemd. If /usr is a separate partition then how is systemd able to boot? In my early days, when you booted single-user, the /usr partition was never mounted. So all the critical utilities and devices were located out of /usr in /bin /etc /lib /dev. /usr was for the user utilities in multi-user mode. systemd has a different idea. For example /etc/systemd/system/default.target is a link to /usr/lib/systemd/runlevel5.target and assumes the /usr is mounted or is hanging off root. I see that flaw was attempted to be fixed by copying /usr/lib/systemd to /lib/systemd. (Bug: the systemd binaries are hard coded to /usr/lib/systemd. It should be /lib/systemd).

And that is an improvement over init.d how? So if I add my own .service .target or whatever, it needs to be duplicated in multiple locations.

Second gripe; The filenames and directories don't make any sense and are not intuitive. Lets go back to the old /etc/inittab and see how /etc/rc2.d was launched. Names began with an S for Start, XX for it sequence and the name of the service so in /etc/rc2.d/S09resolvconf means start in the ninth slot, resolveconf. S09resolveconf was a readable shell script. If it the name began with K, it mean 'K'ill and was the script used to shutdown the service (also a readable shell script). The /etc/rcY.d was the directory that containd all of the scripts for runlevel 'Y'. It's very easy even on a complex boot processes to see what is being run and initialized. Very elegant simple and functional. Contrast that to systemd. All of the equivalent things are stored in /usr/lib/systemd/system or /lib/systemd/system (take your pick). You have a number of different types of files; you have .service, .target, .wants, .mount, .socket, .slice, .path (are there any more?). A person might guess that cups.service has something to do with the cups daemon (cupsd does provide the print services), but then there are cups-browsed.service, cups-lpd@.service, cups-lpd.socket, cups.path, cups.service and cups.socket! Also who came up the the brilliant idea of naming something cups-lpd@.service with an '@' in the filename? Maybe with time I'll get used to this.

It was just nicer to have /etc/rc3.d/S21Cups and you knew exactly from the filename when it would startup and that it run cups at runlevel3.

Here is another brain dead filename in systemd. -.slice! Then try to figure out what that one is about! Type 'more -.slice' "more: unknown option -.slice Usage: more [options] file..." This is a cruel joke isn't it? Type 'less -.slice'. Less replies "There is no -. option ("less --help" for help). Missing filename ("less --help" for help)." I know there are ways around that, but really, should I have to? Could anyone make a startup .ini file any more obscure?

Which leads to my next gripe; The .service, .target, .wants, .mount, .socket, .slice, .path, things (they are not scripts) are all modeled after the microsoft .ini configuration files. Lets look inside '-.slice'.
Code: Select all
[Unit]
Description=Root Slice
Documentation=man:systemd.special(7)
DefaultDependencies=no
Before=slices.target


Documentation= is self explanatory. DefaultDependencies=no does something with dependencies but what that is is not clear. What needs to know about dependencies, are they library dependencies like libX.so.2.1 or dependencies on other programs? It's not clear at all what that means of if you said 'DefaultDependencies=yes' what happens. Same thing with 'Before=slices.target'. To a new user, what is that supposed to mean. That slices.target needs to come before or after '-.slice'? Again, is this a cruel joke? The worst part is there are 240 of these '.ini' files. Uhhhhgggg.

To make matters even more funky with the spaghetti of .ini files are the binaries that read them. In the binaries, /usr/lib/systemd/system/ is hard-coded (there is the mount issue again), and the service .ini files are as well. In /usr/lib/systemd/system-generators/systemd-getty-generator you see it reference serial-getty@.service, console-getty.service, and
getty.target.wants. Programmers never write good documentation, so it's about as clear as mud how this thing works or even what it does?

I really don't know how systemd got this far along? How has it been dragged into just about every major distribution with *so many* design flaws and so many sharp eyes? I know systemd is upstream but I think the Mageia developers have more clout than this old hack. If the Mageia developers patched the filenames maybe other developers might take up the cause of fixing this mess and redesigning it so that it is easier to fix, patch, boot and comprehend and understand.

systemd is _________!

Dear Mageia users, you fill in the blank.
Last edited by doktor5000 on Nov 13th, '14, 22:52, edited 1 time in total.
Reason: added code tags
syschuck
 
Posts: 15
Joined: Jul 4th, '13, 04:06

Re: systemd

Postby doktor5000 » Nov 13th, '14, 22:54

doktor5000 wrote:If you think Mageia can do better, feel free to send patches and take maintenance and development for whatever alternative you propose.
Cauldron is not for the faint of heart!
Caution: Hot, bubbling magic inside. May explode or cook your kittens!
----
Disclaimer: Beware of allergic reactions in answer to unconstructive complaint-type posts
User avatar
doktor5000
 
Posts: 17630
Joined: Jun 4th, '11, 10:10
Location: Leipzig, Germany

Re: systemd

Postby syschuck » Nov 14th, '14, 00:09

With respect the the filename bug in '-.slice', this is how serious a problem it is.

Code: Select all
$ cd /usr/lib/systemd/system
grep Documenation *
grep: invalid option -- '.'
Usage: grep [OPTION]... PATTERN [FILE]...
Try 'grep --help' for more information.


This is really bad for a lot of automated codes that use wild card names.
More Bad news. the -.slice name is buried in 4 different systemd binaries. So it can't simply be renamed. The whole systemd thing needs to be recompiled to get rid of this one bad filename.
syschuck
 
Posts: 15
Joined: Jul 4th, '13, 04:06

Re: systemd

Postby MadmanRB » Nov 14th, '14, 08:47

another systemd topic, I hate these things.
Dont like systemd use slackware.
MadmanRB
 
Posts: 46
Joined: Sep 8th, '13, 19:50

Re: systemd

Postby jiml8 » Nov 14th, '14, 08:57

MadmanRB wrote:another systemd topic, I hate these things.
Dont like systemd use slackware.

That comment is about as worthless as they come.
jiml8
 
Posts: 1253
Joined: Jul 7th, '13, 18:09

Re: systemd

Postby MadmanRB » Nov 14th, '14, 09:00

jiml8 wrote:
MadmanRB wrote:another systemd topic, I hate these things.
Dont like systemd use slackware.

That comment is about as worthless as they come.


Hey at least I am not starting another "I hate systemd it is the work of microsoft blah blah" topic.
These systemd debates are the plague.
I am just annoyed by it, only supernerds who have used linux enough who can code for it that they might as well go off and go slackware or gentoo.
MadmanRB
 
Posts: 46
Joined: Sep 8th, '13, 19:50

Re: systemd

Postby doktor5000 » Nov 14th, '14, 11:20

MadmanRB wrote:These systemd debates are the plague.

Yes they are - and you make that point even more valid.
Cauldron is not for the faint of heart!
Caution: Hot, bubbling magic inside. May explode or cook your kittens!
----
Disclaimer: Beware of allergic reactions in answer to unconstructive complaint-type posts
User avatar
doktor5000
 
Posts: 17630
Joined: Jun 4th, '11, 10:10
Location: Leipzig, Germany

Re: systemd

Postby MadmanRB » Nov 14th, '14, 11:23

doktor5000 wrote:
MadmanRB wrote:These systemd debates are the plague.

Yes they are - and you make that point even more valid.

Only because I am annoyed by it.
MadmanRB
 
Posts: 46
Joined: Sep 8th, '13, 19:50

Re: systemd

Postby doktor5000 » Nov 14th, '14, 11:35

And how do your posts in this thread help with this?
If you don't like systemd, then for gods sake keep using Slackware if that makes you happy. But don't bother others that are happy with it.
Cauldron is not for the faint of heart!
Caution: Hot, bubbling magic inside. May explode or cook your kittens!
----
Disclaimer: Beware of allergic reactions in answer to unconstructive complaint-type posts
User avatar
doktor5000
 
Posts: 17630
Joined: Jun 4th, '11, 10:10
Location: Leipzig, Germany

Re: systemd

Postby MadmanRB » Nov 14th, '14, 11:38

doktor5000 wrote:And how do your posts in this thread help with this?
If you don't like systemd, then for gods sake keep using Slackware if that makes you happy. But don't bother others that are happy with it.

No I dont care one way or the other with systemd, I am more sick of the debates then systemd itself.
I personally dont mind systemd
MadmanRB
 
Posts: 46
Joined: Sep 8th, '13, 19:50

Re: systemd

Postby ITA84 » Nov 14th, '14, 11:39

syschuck wrote:Directories. All of the startup is located in /usr/lib/systemd. [...]

That's due to the UsrMove process, which was done in Mageia just like Fedora, Archlinux and other distributions. Legacy init would be in /usr/lib as well now.

And that is an improvement over init.d how? So if I add my own .service .target or whatever, it needs to be duplicated in multiple locations.

I understand this is done to keep a copy of the original configuration (mainly to enable a 'factory reset' of sorts). Keep in mind though that if you want to add a new service you'd only have to create one in /etc.

Second gripe; The filenames and directories don't make any sense and are not intuitive.

Personally I find the idea of runlevels to be too restrictive, and it doesn't help that different distributions use different semantics for them. I also don't really like that you have to use the filename to tell which services to start/kill and in what order, especially if you want to add your own services, which should mix with those made by the distribution. I'm sure you can get used to how dependencies and targets work, they're really flexible.

Here is another brain dead filename in systemd. -.slice!

Yeah, I don't understand this either, and I don't really like using special filenames in general. I don't know the rationale behind this, but even though they always say it's good practice to never trust shell expansion for command parameters, I'd rather not have standard filenames get in the way too.
ITA84
 
Posts: 199
Joined: Mar 5th, '13, 18:15

Re: systemd

Postby doktor5000 » Nov 14th, '14, 11:46

MadmanRB wrote:No I dont care one way or the other with systemd, I am more sick of the debates then systemd itself.
I personally dont mind systemd

You are sick of the debates, yet you still continue to feed them - so what's your point?
Cauldron is not for the faint of heart!
Caution: Hot, bubbling magic inside. May explode or cook your kittens!
----
Disclaimer: Beware of allergic reactions in answer to unconstructive complaint-type posts
User avatar
doktor5000
 
Posts: 17630
Joined: Jun 4th, '11, 10:10
Location: Leipzig, Germany

Re: systemd

Postby MadmanRB » Nov 14th, '14, 11:50

doktor5000 wrote:
MadmanRB wrote:No I dont care one way or the other with systemd, I am more sick of the debates then systemd itself.
I personally dont mind systemd

You are sick of the debates, yet you still continue to feed them - so what's your point?

I would have not replied further if I were not quoted or had a post directed at me.
MadmanRB
 
Posts: 46
Joined: Sep 8th, '13, 19:50

Re: systemd

Postby syschuck » Nov 14th, '14, 18:36

Well, I didn't want to cause a food fight on systemd. However, I think there is enough of a backlash to it, that people need to hear both sides of the debate. The end result maybe a compromise and a better product. As a long time user of Unix, Linux and just about every type of nix out there, one tends to expect a certain quality and layout. We do things differently from Windows, VMS, OS/2, and we do it right. We don't have a screwed up directory structure like Windows, or Odd-ball device names like VMS:. Over the years I've worked with a number of 'flavors' of linux (Suse, Slackware, Redhat, Vector, Puppy, PC/OS, and Unbuntu). I have opinions on each version, and can tell you why I preferred one over the other. Suse reminded me of HP/UX. Redhat = AIX, Slackware = Ultrix, Debian = Xenix. Each one had something unique about them. Mandrake and it's fork(s) reminded me of SGI Irix which was a very innovative Unix (I still prefer xfs over all other filesystems and it has saved my butt several times). What made each of the Unixs unique were their admin tools, their compilers and their init scripts. As systems have consolidated and Linux began to dominate this space, the issue of the compiler went away and so the various distros could compete on admin tools and their init scripts. The idea that something could unify the init process, to me, looks like an over reach.

When the requirements for the package require that the whole of the Unix philosophy and design be modified to fit the needs of the application, then the application seems to break that spirit. For example, I've seen this trend to move more and more system level functions into the /usr. The UserMov concept. To me this goes exactly against the well established hierarchy of the file system the dates all the way back to K&R! It destroys the organizational concepts of the filesystem's design. It's kind of like a book. A book is organized to have a cover, a table of contents, a preface, chapters 1...X, references, and a backcover. Book can be organized differently, but then they are odd and not normal.

So what does UserMov have to do with systemd. The reason for the proposal to move systems into user space is because of systemd. It's my understanding that systemd and usermov are ideas from the same guy; Lennart Poettering http://en.wikipedia.org/wiki/Lennart_Poettering. So as far as the UserMov, it sound to me like this is more of an excuse to not change systemd and not admit the systemd is a poor design breaking every unix philosophy rule that exists. As far as /usr do a 'man hier' and read. This is what it says about /usr:
Code: Select all
/usr   This directory is usually mounted from a separate partition.  It should  hold  only sharable, read-only data, so that it can be mounted by various machines running Linux.


Back to how to fix systemd, far as changes to systemd, besides it location, stupid filenames, and 50 binaries, I would consolidate all of the .service, .socket, .target, .mount ... files into one single .ini file. So for example, rpcbind.socket, rpcbind.servce and rpcbind.target would be merged int a single rpcbind.ini! That would reduce the spaghetti and it could easily drop the number of config files down to 75 to 100 instead of 250+. Windows users would be happy because then they could see a directory that might look something like this;
Code: Select all
dbus.ini  cpupower.ini  chronyd.ini  cups.ini  httpd.ini  freshclam.ini  saslauthd.ini


In other words, consolidate all of the duplicate and related .service, .socket, .target, .mount ... files into a single .ini file and be done with it.

Another option that might take less work, is taking Mageia 2 (pre-systemd) and updating it to mageia4.1 excluding anything that is systemd related. Call it Mageia4.1*
syschuck
 
Posts: 15
Joined: Jul 4th, '13, 04:06

Re: systemd

Postby doktor5000 » Nov 14th, '14, 22:20

syschuck wrote:However, I think there is enough of a backlash to it, that people need to hear both sides of the debate.

Sure, but if you only debate and don't write code or send patches, that will help nobody - this is what most people simply forget or get wrong.

Also Mageia 2 is open source - if you like, clone it from our SVN, and update and do whatever you like with it, nobody prevents you from doing so.
Cauldron is not for the faint of heart!
Caution: Hot, bubbling magic inside. May explode or cook your kittens!
----
Disclaimer: Beware of allergic reactions in answer to unconstructive complaint-type posts
User avatar
doktor5000
 
Posts: 17630
Joined: Jun 4th, '11, 10:10
Location: Leipzig, Germany

Next

Return to General discussions about Mageia

Who is online

Users browsing this forum: No registered users and 1 guest

cron