SoylentNews is people
SoylentNews
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
| 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.
spagmumps, n.:
Any of the millions of Styrofoam wads that accompany mail-order items.
-- "Sniglets", Rich Hall & Friends
(Score: 5, Interesting) by frojack on Tuesday March 18 2014, @10:14PM
Probably like OS2 there will be people singing the praises of Upstart for a long time.
Not because it proved to be very good, just because it proved to be different.
I don't like Systemd right now. Its horribly implemented in many distros, leaving many things broken and not easily manageable by most users. (Kind of like how KDE4 was a running three year disaster). But I understand, just as KDE4 became very stable and usable, systemd will finally get the kinks worked out and behave much better as time goes on.
What you have to remember, is that systemd was not built for you. It was built for big business, big government, big data centers, where things have to get booted much faster than previously. We are but crash test dummies in this grand scheme.
With that being the case, there was never any question that Systemd was going to win out in the end.
And it was built principally by a guy could care less about pissing and moaning from the user base, with a history of breaking the crap out of stuff and not being in any hurry to get it fixed. Far too much of Linux operates in this way these days. I liked it better when the focus was not on how long it took to boot, but on making sure you seldom ever had to reboot.
I also worry that Systemd hasn't been around long enough to have all the security angles addressed.
No, you are mistaken. I've always had this sig.
(Score: 5, Insightful) by Grishnakh on Tuesday March 18 2014, @10:28PM
What you have to remember, is that systemd was not built for you. It was built for big business, big government, big data centers, where things have to get booted much faster than previously. We are but crash test dummies in this grand scheme.
That's not the primary reason for systemd at all, and booting times are not very important on servers like they are on laptops and desktops and small embedded systems. systemd's raison d'etre is service management; sysvinit is positively primitive with just shell scripts; take a look at Windows with its service manager. That's basically what they're emulating, only much better of course. It starts services, stops them, restarts them if necessary, logs errors with them, etc. Beyond that, it manages other things too like devices (by incorporating udev) and system logging. There's a good reason it's called "systemd", it's not just for starting up the system, it's a whole layer for managing the entire system. Other UNIXes have had stuff like this for a while (I believe Solaris's version is called SMF); Linux is really quite late to the party.
As for horrible implementations, that's really up to the distros. They're supposed to perform some kind of quality control, and they're obviously dropping the ball as usual. KDE4 was the same: distros just dropped support for KDE3 all of a sudden and forced them to KDE4 (in KDE distros), instead of recognizing that KDE4.0 was alpha-quality and not ready for serious use, so of course disaster ensued. Distros need to stop simply accepting shovelware from upstream, and do some serious quality checks for themselves; if something isn't ready, help out to make it ready, and if that fails or is going to take too much time, revert to the old version.
(Score: 2, Insightful) by Anonymous Coward on Tuesday March 18 2014, @10:49PM
Damning with faint praise.
Ever notice the arrogance and aggression that meets the many valid technical criticisms? Given the attitude of the developers, the manual / FAQ for systemd may as well read "because fuck you - that's why". Not any better than Microsoft afterall then!
(Score: 4, Informative) by tibman on Tuesday March 18 2014, @11: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, @04: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, @07: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.
(Score: 3, Insightful) by sjames on Wednesday March 19 2014, @03:36AM
There's nothing primitive about using a shell language that is Turing complete for customization.
I see nothing in systemd that couldn't be accomplished in a cleaner manner with a few helper programs. Certainly there is no need to create an all singing all dancing monster with a tentacle in every pie.
The Unix way of small tools that do one thing and do it well has served us well for decades, the other approach gave us Windows and a bunch of also-ran OSes.
(Score: 2) by Grishnakh on Wednesday March 19 2014, @04:34PM
So I guess Solaris and AIX don't count as "UNIX" to you? How idiotic.
(Score: 2) by sjames on Wednesday March 19 2014, @07:10PM
At this point, Solaris and Aix are also-rans. BSD still seems in the running though, it's fairly popular behind the scenes.
(Score: 3, Interesting) by TheLink on Wednesday March 19 2014, @04:22AM
You're comparing with WINDOWS?! It's only in recent years they got preshutdown notifications compared to Unix init scripts which have been around for decades.
AND even then it's not yet natively supported by .NET services: https://connect.microsoft.com/VisualStudio/feedbac k/details/641737/add-windows-service-preshutdown [microsoft.com]
I've been considering writing a windows service to handle preshutdown notifications and then shutdown .NET services in an orderly manner. Maybe someone has written one already.
As for logging, the Microsoft/Windows logging culture is below par. It's possible to log useful logs in Windows, but somehow the logging culture is such that more don't compared to the "unix/unixlike" logging culture. Perhaps due to pushes for internationalization they have made logs equally useless in all languages ;). e.g. instead of "Unable to read file: '/zzz/xxx/yyy.conf': access denied" you are more likely to get stuff like "Error [0x123]: FILE_ACCESS_DENIED".
See also: http://support.microsoft.com/kb/307024 [microsoft.com]
(Score: 1) by Qzukk on Wednesday March 19 2014, @01:57PM
Having tried to debug a windows 8 computer that was unable to run windows update because the BITS service would not start, I can say that I never once saw an error code with the definition printed next to it anywhere in any log. Plenty of "Service failed to start with error -1892447375" or "Last error code 0x8f338b71".
(Score: 2) by Grishnakh on Wednesday March 19 2014, @04:12PM
I compared with Windows because more people are familiar with it than with something like Solaris.
And yes, Windows logging sucks. I never said Windows was a gold standard in anything.
Windows has a habit of taking really good ideas, and completely screwing them up with terrible implementations. Their service manager is an example of this I think. Unlike sysvinit, it'll actually tell you the current state of services (try kill -9ing mysql and seeing if sysvinit notices). But of course, the general way it's implemented sucks for many different reasons.
(Score: 2, Insightful) by digitalaudiorock on Tuesday March 18 2014, @10:43PM
But doesn't this imply servers where for all intents and purposes, almost all the parallel boot stuff is useless (like starting an app before the database for example)?
Personally I think Symtemd will go down as being a huge mistake. On my own machines I'm running Gentoo with no Gnome, Systemd or anything that requires either.
I think the whole f****** mess is cure for which there is no known disease. Don't ever get me started...the whole topic just pisses me off WAY too much and life is just too short.
(Score: 2) by forsythe on Wednesday March 19 2014, @12:45AM
I must agree. Assuming that Systemd's target userbase is enterprise, however, raises the question of why Systemd is pushing for adoption among user-focused distros (Arch, Debian, etc). Debian doesn't ship SELinux by default, why do they ship Systemd by default? I can see RHEL doing so, but why Debian?
I should also bring up the following to commentaries on Systemd:
http://ewontfix.com/14/ [ewontfix.com]
http://ewontfix.com/15/ [ewontfix.com]
They are mostly technical, but the author raises the point that, based on the technical design of Systemd, it's attempting to be an octopus that handles everything and is required by everything: the only real way for an application to get a certain type of behavior out of Systemd (that it probably wants) is to use Systemd's API, which ties the entire daemon to Systemd, rather than an init-system-agnostic daemon with a specific 20-line shell script wrapper.
That pervasiveness doesn't fit with a profile of Systemd as a niche product.