This is an advantage, not a problem. If parts are loosely coupled I can exchange them with other parts that maybe fit my needs more. Is this possible with systemd? For example, can I replace udev in systemd with mdev or hotplug2?

1 members found this post helpful.

Yes.

And will the rest of systemd work coupled with mdev or hoptplug2? Or will the parts of systemd that are relying on a service like udev (if there are such, which I would expect, like the mount daemon) just refuse to start or, worse, start udev as a dependency?
I am really interested in that: can systemd be as flexible as the current system?

2 members found this post helpful.

...sorry...

Double post.

Sure.
You might not have all the advantages that come with systemd, but hey, you don't have those with plain sysv either ;-}

I've recently had to do something similar on a fedora system with both systemd and LXC (didn't work with sysd's udevd enabled).
Replace "disable" with "stop" if you want to do/try this on a running system without rebooting.

PS: ... again, at the end it's really just another (but imho better) init system.

A mother addressing her family:

"We have guests coming over for dinner this evening. We want to have a pleasant conversation at the dinner table so remember, no discussing politics, religion, or systemd."

3 members found this post helpful.

This brings to mind a certain Vincent Price movie (yes I'm that old) wherein a gourmand is force fed a banquet including his own pet poodles until he expires. The analogy fits systemd quite well. I would much rather have simpler more robust fare in portions suited to my needs.

I am a C/C++ programmer and also program in assembly language. Scripting languages exist because not all problems can be best solved using compiled programming languages. Scripting languages are designed to balance simplicity with flexibility and provide complex text parsing capabilities. Compiled programs are not always faster than scripting languages. A lot of that depends on the capabilities of the language and the programmer. I can say from experience that I am not expert at every kind of text parsing problem and that is what scripting languages do best. Were I to try and write something in C that I can easily write in a shell script the result might have horrible performance. I view writing scripts as writing programs using a different language. Scripting languages offer great benefits for testing and debugging. Making a change and testing the change requires much less time than recompiling a program and then running the program. Also, one can test individual scripts rather than the entire initialization system (program).

If even GRUB can make use of well established scripting language elements, why does systemd need its own, different way of defining behavior? If systemd needs to re-invent scripting and configuration languages, why does it not support changing all the behavior in the scripting languages? The answer seems obvious. Those working on systemd are not focused on making life easier for the people using systemd. They are making systemd easier for the programmers developing systemd. Those programmers are most familiar with C. This is a classic pitfall many inexperienced programmers encounter. One does not design the user interface and features around the software. One designs the software, user interface and features for the application. I am a firm believer in using established standards and precedents. If I'm designing an application and there is a well established way of doing things then I try to stay close to that. I try to add new functionality in a way that extends rather than replaces the established way of doing things.

How modular is systemd? How easy is it to test the initialization of one subsystem? How confident can one be that a test of one subsystem will catch problems when the entire system is initialized? Having "perfection" is not helpful if the process to achieve that "perfection" is laborious and unpredictable. A system administrator's job is to keep the system running and introduce necessary changes with as little down time as possible. It is much better to know that the system will successfully boot in 1 minute than to know that it might boot (or not) in 10 seconds.

In the words of my colleague, "Whats your hurry?". He was rather sarcastically putting things into perspective when asked to drastically redesign some software to only modestly reduce the execution time. Sometimes, the faster you go, the longer the trip takes. Because there are already good ways to initialize a Linux system, it will be necessary for systemd to prove itself. That means not only must systemd be faster, but more importantly it must be more reliable, more flexible, easier to use and better documented.

As a programmer who has worked for some large companies, I have seen the attitudes that programmers can develop in that environment. Many start to believe that users have no choice but to accept what the programmers choose to do. Some begin to believe that everything they do must be right because they are insulated from the end user's problems. The rude awakening comes when suddenly there aren't enough users to justify the programmer's job. Or, a programmer may do something on their own and discover that nobody is particularly enthralled with their work. The most difficult part of programming often isn't writing the software. It is understanding what the users want and need, then deciding how to best give them those things. Sometimes what the programmer wants to do, or what is easy to do, is not what the users really want and need.

8 members found this post helpful.

True.
However ... I'm not that young either and I'm more annoyed with other programmers who simply refuse to accept anything new, just because that old stuff just happened to work for them.

Reality: Most users don't care about these things as long as it works for them.

Not saying systemd is perfect, but it did introduce some good things.
Even if you don't like it, do you really like sysv?

The problem here is that we at this point do not know if these things work for them. This test will begin when RHEL 7 is deployed with systemd and all the admins in charge of RHEL or CentOS systems will be confronted with it. For now we have it only on desktop systems, AFAIK, and desktop users are far easier to convince with fast boot times and such stuff.
It may work out well for systemd, but we have not seen it working in professional environments yet.

1 members found this post helpful.

A musical analogy for systemd:

Systemd is the double-bass-drum pedal of the GNU/Linux world.

Sure, it's faster.

Sure, some great players use it.

But is it really better?

The kick drum is just one part of a band (an important integral part), but there is a lot more going on than just the kick drum. And if you are only concerned with being faster, are you really going to make "better" music? Will the band really benefit from you making more noise?

Sometimes, when you limit yourself, or use something that is more understandable and "simpler", you push yourself to realize things, and do things, you never would have. By limiting your tools, you can expand your perspective.

My new employers run a redhat shop, so I'll be getting to work with systemd first-hand. Half looking forward to the educational experience, half dreading the horror.

I'd be really interested in your first impressions and early experience, as I am sure others will be. Please post your comments as you think them useful to us Slackware Neanderthals!

Erik, you said a lifetime's worth.

I couldn't have said it any better or any more sanely.

My points highlighted in bold above as to why I feel that we admins are getting the shaft.

Truth be told, I'm glad I'm learning FreeBSD right now, as well as PC-BSD. It's a sad day when the Linux user wants to make things more difficult for the Linux admin, and even worse when a troll who has everything against not only the UNIX Philosophy, but also the Slackware mentality come in and try to say "GNU/Linux needs to be more like Windows". I only use Windows because I have to at work and at home for games, but the majority of the systems I administer are BSD or Linux based machines. If GNU/Linux becomes another Windows, then screw Linux.

No offense to Patrick for trying to keep some sanity within his own distribution, and more power to him if he ever can find a way to keep Slackware devoid of this trashware, but if needed, I will flush GNU/Linux straight down the toilet without prejudice, even if Slackware has to be flushed. Though it will at least be flushed with some honour.

@Erik Fl,
Our backgrounds seems to be almost identical - however, your eloquence is far superior to mine.
I could not have said it any better no matter how hard I try - I bow to thee - well put!!!!

In the world of the system and network administrator the term "faster booting" is meaningless when it comes to getting a system up and running. Real system and network administrators do have time limits to deal with, yes, but at the same time, we also have system and network stability and reliability to worry about. In short we have to work with a nearly failsafe system, and systemd is far from being failsafe.

This isn't a RonCo product where you can "set it and forget it". System and Networks require attention to detail and giving the maximum control to an administrator means sacrificing things like systemd in favor of administrator friendly init systems that rely on plaintext scripts that can be easily edited and quickly deployed for a service to be restarted by.

Let me make that clear...

User Friendly and Administrator Friendly are two entirely different terms.

In short the easier it is to edit and get working again, the faster your services come back online.

For us, Init systems like SysVInit, OpenRC, and BSDInit have been extremely reliable, because for the most part, they all use the same scripts in plaintext. I hate working with programming languages and the more complex you make a system, the longer it takes to get that system back online and working again. Having to generate a configuration file, then find out it was wrong, and now you have to re-generate it time and time again until you get it right... is ludicrous.

If at all on sysvinit and compatible systems, you can open a file in a text editor like nano, change a setting, save the work, and relaunch the service with a simple (for example as you would in Slackware) "/etc/rc.d/rc.samba restart" command in superuser mode, you've saved a hell of a lot of time, and eliminated a lot of overhead and problems from testing configuration files again and again to make sure it is right before you restart the service.

We system and network administrators could care less about how fast your system boots. This isn't a damn race, and we do not have time to play and jack around with C language code none of us understand nor are willing to understand. We aren't hackers with thumbs up our arses, nor do we care to be.

Systemd has no place in the enterprise IT world, and chances are, it never will unless the language shifts from using C programming language generated configuration files to simplistic plaintext scripts, and that isn't likely to happen.

3 members found this post helpful.