Dev.SN ♥ developers
Sections
Dev.SN
elias writes:
"A very public and sometimes acrimonious dispute in the Debian ecosystem about upstart versus systemd has been settled in favour of systemd. Some go as far as to brand it a new era after the Linux civil war [Beware popups].
We also had an asksoylentnews question on what the fuzz was all about. But what can upstart contribute to systemd now the war is over, or will it simply be a technology that we remember fondly, but do not see any more in a few years time?"
This discussion has been archived.
No new comments can be posted.
Ubuntu Concedes Defeat in Upstart vs Systemd
|
Log In/Create an Account
| Top
| 1000 moderator points
| 41 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
I'm not a robot like you. I don't like having disks crammed into me... unless they're Oreos, and then only in the mouth.
-- Fry
(Score: 4, Informative) by tibman on Tuesday March 18 2014, @07:18PM
sysvinit is positively primitive with just shell scripts;
Comparing cli tools to ui is not a good idea. Wouldn't you say that windows services is almost exactly like Webmin's bootup and shutdown section? Is a full UI required to admin a server?
I'm not sure why sysvinit is primitive because it uses shell scripts. Would using a different language (compiled) improve anything? Not every distro requires its entire userbase to migrate to new subsystems either. Gentoo, for example, lets you decide if you want to do systemd or sysvinit. They've had it available since 2011. I'd hope that Debian would permit the same.
Tightly integrating all those parts together sounds spooky. What if someone wants to fork a part of it? Imagine if KDE swallowed Xorg and they became one project? Don't get me wrong, i'm not saying systemd isn't good or that it doesn't have a bright future. I just wanted to argue a bit about calling sysvinit primitive. I'd accept ancient though : ) Systemd is pretty much no better, each service has a config script. You just can't run them anymore.
SN won't survive on lurkers alone. Write comments.
(Score: 2) by Grishnakh on Wednesday March 19 2014, @12:05PM
This has nothing to do with GUI vs. CLI. It has to do with a service manager that actually knows the state of various services and continuously monitors them. sysvinit doesn't really do this; all it does is kick off a shell script with a command ("start", "stop", "restart", etc.). It doesn't actually know if a service is still running or not, if the process has died, or anything except what that shell script returns when the service is (re)started.
Would using a different language (compiled) improve anything?
The idea of needing a language to run services is rather laughable. The only reason it was done with sysvinit is because it's an easy hack. systemd doesn't use a language, it uses a simple description file (basically an INI file). The management daemon does everything internally.
When your programs save their state and configuration in files, do they need to be in a particular language? No, of course not. Go look at your .rc files sometime. The idea of using a language to tell a program what to do is utterly ridiculous; it only needs a configuration file.
Tightly integrating all those parts together sounds spooky.
So I guess you think it's "spooky" that Linux's kernel is tightly integrated with its device drivers, right? Or that Gnome or KDE has many tightly integrated parts? What OS do you use anyway? It's obviously not any conventional Linux distro.
What if someone wants to fork a part of it?
Then they can fork it. What's the problem? Big projects have been forked before (XFree86, LibreOffice), and systemd is much smaller than these.
>Imagine if KDE swallowed Xorg and they became one project?
Why on earth would they do that? That doesn't even make any sense.
(Score: 2) by tibman on Wednesday March 19 2014, @03:12PM
It has to do with a service manager that actually knows the state of various services and continuously monitors them. sysvinit doesn't really do this;
You're looking for rc-status. It shows you each service and its current state. Similar to if you run the service script with status at the end. Like "/etc/init.d/apache2 status".
Though a bit of a text blob, here is actual output (butchered to fit) from rc-status where i've manually killed mysql. Mysql is reported as "crashed". This is a good cli representation of my current running services and their state.
Runlevel: default
sshd [ started ]
dhcpcd [ started ]
net.eth0 [ started ]
netmount [ started ]
ntpd [ started ]
vixie-cron [ started ]
local [ started ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed
Dynamic Runlevel: manual
mysql [ crashed ]
apache2 [ started ]
SN won't survive on lurkers alone. Write comments.