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.
This login session: $13.76, but for you $11.88.
(Score: 2, Insightful) by KabukiWookie on Wednesday March 19 2014, @02:26AM
Can't agree more with this. Unlike desktops/notebooks where boot times may be a factor (although I don't really care if my notebook starts up in 2 seconds or in 5), adding additional complexity to something that has already been working fine for several decades seems not a such a good idea imho and more a change for the sake of change.
Using systemd feels to me like losing control over your start up sequence and handing everything over to a binary black box blob.
It would be good if a distro *does* want to introduce systemd or upstart that it's possible to make a choice between the three mechanisms during installation of a distribution. That way one can have control on their servers, while having a reduced boot time on a desktop/notebook. Linux is all about having choice right?
(Score: 4, Interesting) by caseih on Wednesday March 19 2014, @03:05AM
Have either of you ever tried writing a fully compliant init script for a custom daemon? Scripts tend to run hundreds of lines of code, and lots of reinventing the wheel. Checking for running processes, PID files, lock files, etc. It's a real nightmare I assure you. And if your daemon (running not as root of course) is not completely bug free and crashes occasionally, you have to hack a watch script to keep the thing running. Or use a non-standard super daemon like supervisord (very good), or inetd or xinetd. From a developer's point of view it's messy and not very sustainable. And slow of course. But like you I don't care about boot times.
With systemd I can get my daemon running with about 5 lines of ini code. Process supervision, restart control (no need to check for existing running processes). Just works. Yes it is a bit more opaque, but not overly so. The behavior of systemd is well defined. And you can read the source code to systemd if you want. And systemd is modular, so it's not like tons of things are running as process 1. As much as possible runs as other user processes. And the idea of using sockets as a means of synchronization is, well, genius. Totally simplifies things, only adds a couple of tiny calls to a static library to a daemon to take advantage, and does not tie the daemon solely to systemd (modified daemons work fine on older init systems, falling back to normal socket operations), and no data is lost as daemons come up since the data gets buffered in the sockets and blocks until processed. Also systemd is 100% compatible with system v init scripts still, if you insist on using them. I have a debian system right now that's partly systemd, partly system V.
I'll get modded down for this I'm sure, since soylent new's groupthink seems to be anti-systemd already. It's popular to hate on things. And I used to have concerns about systemd. But now that I've actually used it, and become familiar with it, I can see the benefits.
(Score: 2, Interesting) by Subsentient on Wednesday March 19 2014, @05:04AM
Oh man, this is upsetting. Now, I am taking this opportunity to advertise a little, but with Epoch [universe2.us], pretty much everything you mentioned is supported, and there are no dependencies outside of Linux and uclibc/dietlibc/glibc.
Reading the source? There are some *cough* ugly parts in Epoch, but you won't find more readable init system source code [github.com] anywhere I assure you.
I spent months of my life writing this thing just to keep from using systemd in a homebrew distro. SysD's issue is not it's features or implementation, it's the opaque-ness of the whole thing, not to mention the creator's admission of being bent on world domination with systemd.
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 1, Interesting) by Anonymous Coward on Wednesday March 19 2014, @09:42AM
Linux kernel as a dependency? Sorry, you lost me there. An init system shouldn't need anything outside of what a standard *nix system provides.
The unix wars were lost by everybody involved. We won, not Sun or IBM or HP or any of the others who wanted to be different. Standards won.
Take a look at http://ewontfix.com/14/ [ewontfix.com] - the section "So how should init be done right".
Your implementation is closer to system than it is to this.
(Score: 2, Interesting) by caseih on Wednesday March 19 2014, @03:38PM
I find your criticisms of Epoch a bit strange, honestly. I don't see how Epoch does not follow the section, "So how should init be done right." Have you downloaded Epoch and looked at the source code before making this criticism?
The blog post you link to is done by a smart fellow, but it doesn't appear he's actually worked very much with systemd as every criticism is inaccurate, or at the very least an unsubstantiated opinion. For example, his assertion that systemd more then "doubles the attack surface" of a hardened computer is pretty silly. In fact I'm not even sure what he's getting at there.
Unlike the Epoch author, I have no dog in the race. I just get tired of inaccurate criticisms of systemd by folks who've never even worked with systemd, or have any real knowledge of how it works. Having built an init system, the author of Epoch does have grounds to analyze and criticize systemd.
(Score: 1) by bookreader on Wednesday March 19 2014, @05:26AM
This was quite informative, thanks for sharing.