SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 19 submissions in the queue.
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.
Anyone can make an omelet with eggs. The trick is to make one with none.
(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.