a4z, why do you care so much about people's opinions concerning systemd? I think that you seem to be very emotionally invested in this topic. I've worked on a systemd system (Debian Jessie) as a user a little bit and the place didn't burn down. Slackware's BSD init suits my purposes. It has been around a longtime. Its stable. It works as well today as it did a decade ago.

I have not yet received an answer for my one technical question regarding systemd. Did it have to absorb udev? They promised to support it as init agnostic for a longtime, but then they backtracked 2 years later. Is there a technical reason why this was the only way other than they wanted to incite flame wars (my guess)? Why must there be 2 packages that supposed to do the same thing? Is it impossible to get the functionality systemd needs without stepping on everyone else's toes, creating flame wars to this day? I've read some of them but none have answered my question. I can understand why projects like KDE don't want to have to support 10 different versions of the same thing: "This class kdisplaymanager in plasma-workspace shows our abstraction layer growing since 2004; it currently has Logind support but as we have been adding to a constantly broken abstraction layer it's used very badly. It has tracking code for over 5 different systems (KDM, old GDM, new GDM (which is now old), consolekit, org.freedesktop.DisplayManager, and now logind) and is probably one of the ugliest pieces of code in Plasma."
http://blog.davidedmundson.co.uk/blo...emd-and-plasma

1 members found this post helpful.

We seem to be facing few related, yet different issues here:

1. A renowned entity pushing a "new snake oil" product (to rule them all?). And dong so in a "old wrong way" as seen before (HURD? OS/2? )

2. Users having "invested heavily" into Mastership of using Linux, or few distros, finding "us" (the Slackers) who refuse to suffer hardship for using GNU/Linux, and do it the lazy (easy?) way. No wonder the friction

3. A tendency (or is it just me?) to see ever more distro's stars fade away with the last few, contrary become ever larger, yet ever less about free software or free development. It feels (tome at least) as if the cave is closing?

I hope our ship (Slackware) continue to sail on for long time?

4 members found this post helpful.

It absolutely will, one way or another.

3 members found this post helpful.

... and for the Slackware team:


for delivering us the last (AFAIK) and by far the best distro tailored for human use and administration.

Long live Slackware!

PS
the other day i just used nc (for the first time) over a serial line to put a file on a "remote" host running Slackware setup - felt so "hacker" in the moment :^)

2 members found this post helpful.

Maybe the systemd devs should take heed:
http://xkcd.com/371/

Does Systemd rely on the kernel to solve dependencies?

Insane doesn't even touch how bad this is. This is downright f-u-b-a-r. Running everything over PID-1 is bad enough of a design, but creating a vulnerability point that can be web accessed either from internally on a network, or even externally from the world wide web... There isn't a definition that I can even think of that begins describes how idiotic this is.

I can understand if you are creating an embedded system like DD-WRT and such to create a local link access point with a 192.168.x.x address, but a cloud based access point open to the web? Sigh...

You know what... let them... It's their fault if the systems end up as major attack targets by hackers. They don't know when to quit, and they refuse to address issues, so when the house of cards goes "splat!" let this be on systemd and their developers as well as those systems who bought into this idea.

2 members found this post helpful.

As the OP I originally placed this thread in Slackware, since it is one of the few to remain non-systemd (and my favored distro for some years), it is most relevant to the future direction of Slackware. Since most of the other distros have already (recently or several years now) switched to systemd then most likely news of this nature would be of little use to them, as given the pro-systemd communities stance towards anything that shows flaws in systemd.

Now, why you would address that particular question to someone other then the OP is another matter.

3 members found this post helpful.

But you can replace systemd with SysV or upstart as a possibility right ?

Or have distro creators gone out of their way to make it really difficult for geeky users ?

Systemd requires a number of changes to services - inclusion of dbus, journald... Some/many services have been modified to work with systemd, and will NOT work with SysV or upstart without a completely different build of the service (distros really don't like that). Some of the mandatory modifications are that the service may need to tell systemd when they are operational... The standard way is that the service is operational when it forks to become a daemon - and the startup script can do other things that may depend on that service. With systemd you can't do that AND have the "automatic restart" and valid dependency tracking. So to accomplish that, the service has to use dbus to inform systemd when it is ready for operation, and NOT become an independent daemon (they have to remain in the forground, which previously was a debugging option only).

Not all services have to be altered though. But due to multiple dependency (such as NetworkManager, dhclient, named, and databases)... to get the order right, systemd has to wait on NetworkManager... but NetworkManager has to wait for dhclient to initialize the network. Getting this to work required changes to NetworkManager and dhclient (it is where the networkManager-wait-online came from; before that NetworkManager would say the network was ready... even though it wasn't). This introduces more problems in that Apache needs the network - perhaps for accessing a remote database, thus it may require named... which doesn't work without the network either. Thus the dependency network keeps growing more complex...

It isn't the distro makers that have made things difficult. It is the systemd developers.

4 members found this post helpful.

It is very difficult to remove systemd and retain full functionality.

The distro maintainers aren't really to blame for that... Most of them are just going with the flow.

Although, I guess it could be argued that they should have asked more questions before making unilateral decisions.

It is my understanding that the difficulty of keeping Debian on sysvinit motivated the Devuan fork. Preventing various apt-get upgrades from switching the system back to systemd was the greater chore.

so, systemd requires various services all be foreground tasks sending signals over DBUS during the wholeuptime?
how to get rid of zombies?
how to free up frozen handles?
and last not least; the sistem load/pressure of this just demands lighter hardware platforms (as routets for instance) use exotic inits (read less tested)?
And other who comply will have to re-boot every so often that even Windows users will pity and mock them?
So non UNIX way.

A few questions from my side ...

1. systemd was honestly not needed ? they first said it was just a alternative system for faster boot initially

2. they said systemd is good for servers farms - the problems lacking in SysV or upstart could be handled in other ways instead of writing a complete new system from scratch ?

If it is in fact so ridiculously complex , why arent distros reverting to older methods ?

What is more amazing is that only slackware was sensible enough to avoid it, all the other distros just pressed it in their latest release (esp shocked at debian , considering there are so many distros forked from it).

What really bugs me , is that the average linux user , is left with no choice but to use systemd whether he likes it or not. If anything , GNU/Linux is about choice and freedom.

Call me crazy (or thank me later), but my gut feeling says someone is trying to control/influence things (just my 2 cents on this one).

No. It is only mandatory when the service is first ready for use. After that systemd just monitors the child process. When it exits (a SIGCHLD signal) then systemd can/may do something about it.
The linux kernel has an extended system call (prctl) that can set the identity of the reaper rather than just using pid 1.
"lighter"? It takes about 30MB currently.
The problem isn't reboot... The problem is that it is VERY difficult to add a new service to the dependency network - and have things work. It can hang boot or shutdown, with little to no debugging information.

I have found that it works relatively well for small systems - little complexity in disk structure and networking. It does boot faster in that situation. It has some advantages for laptops dealing with wireless.

Some claim it works well for big servers... But if you look at the servers the complexity is being offloaded to NAS (either fiber channel/infiniband based) making the aggregate result "simpler" for the host. The VMS also have a relatively simple setup (dividing the work between the host and VM) but it requires more CPU hardware for the duplication of systemd among all the VMs.

I used to be able to run 5 to 6 VMs on my 8 core workstation. Now it boggs down at 3.

But the more complex things get the easier it is to stuff up the works.