Knurpht - Gertjan Lettink wrote:
But unlike GNOME + KDE, or vi + emacs, or Firefox + Chrome, supporting 2 init systems is a totally different situation
Not really -- unless they are not just limited to "init".
Start giving it a try,
--- It's a bit late to make it easy. If they started when sysV was still in place and added auto-port options for systemd, it would have been reasonably possible, but now, you'd have to reinvent the wheel -- also true is systemd is a monolithic piece of SW that has replace so much -- requiring any replacement of it to supply replacements for everything it has replaced.
That's the MAIN reason why choice was eliminated, as systemd provides all the choices -- it is one monolithic (yes, it is -- because the parts won't inter-connect with anything but systemd-parts) piece of SW that is designed to crowd out and extinguish any competing part that it has taken over.
That's an explicit and very serious accusation of the developpers of systemd. Please reread and think again.
I've read many times. I'm not the only one who has noticed systemd's lack of allowing alternatives. Show me how I could run my own "init(pid=1)" that implements a subscriber service for dying pid notifications... I believe you'll find it can't be done without modifying systemd -- and that such modifications won't be accepted upstream.
EVERY SINGLE SERVICE will need to have a systemd unit file (normally easy) AND a sysvinit script (normally complicated as heck).
Laugh! LSI included a 39-line auto-converter to generate sysd-unit files on the fly, from existing scripts. It's automated in a 39-line shell script -- and you call that "complicated as heck"?
Reread what's been called "complicated as heck".
--- You mean the scripts -- all of which were already written? It was a well understood technology that provided skeleton.templates for new services that were remarkably easy to generate services with.
Well, you've made your point, you don't like systemd, and you're still frustrated about the fact that systemd became the de facto standard.
You don't get my point. It's systemd's bad design I don't like. You can't replace parts and it doesn't allow use of standard interfaces if you tried. Maybe I want systemd to start my daemons, but not be PID 1. Will it allow that? Nope. Because it ties everything together, I can't use the parts I like -- give it everything, or nothing are the two options -- systemd was designed to not allow use of it's parts separately from init. A simple init could have provided info on processes dying with a subscription model, the same way the OS provides notices of file-alteration through something like famd -- allowing many programs to use the notification feature. The programs don't have to be installed in the kernel to monitor the files or monitor process death. But if one program replaces the standard interface and famd breaks? A bunch of other programs stop working. That systemd replaces pid-1 disallows any other "sharing" program that could notify all programs -- not just systemd or its tentacles. If anything goes wrong in systemd, you need to do the Microsoft-reboot dance, which is pathetic. I can't see businesses worried about uptime being happy about that. Init(pid1) could be a small separate program that was built for a specific purpose and provided a pid-death-notification service that could be used by "anyD" and wouldn't be hard to write -- but it won't work with sysD, which, I'm told, won't run unless it is started as pid-1. That's what I mean by sysD not being a team player that even *allows* any alternative -- it shuts down avenues of compatibility. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org