"Having had several issues with systemd, and really not liking the philosophy behind it, I am looking into alternatives. I really prefer something that follows the Unix philosophy of using small, focused, and independent tools, with a clear interface. Unfortunately, my favourite distro, Arch Linux, is very much pro-systemd, and a discussion of alternatives is liable to get you banned for a month from their forums. There is an effort to support openrc, but it is still in its infancy and without much support.
So, what are the alternatives, besides Gentoo? Preferably binary... I'd rather have something like arch, with quick updates, cutting edge, but I've already used a lot in the past Mandrake, RedHat, SourceMage, Debian, Kubuntu, and so on, so the package format or the package management differences don't scare me."
[ED Note: I'm imagining FreeBSD sitting in the room with the all the Linux distros he mentioned being utterly ignored like Canada in Hetalia.]
For somebody who hasn't been paying attention to the service manager wars, what are your issues with systemd? What don't you like about the philosophy of it?
I had a quick read of Why systemd? [0pointer.de] and Biggest Myths about systemd [0pointer.de], and don't see what the fuss is about.
OTOH, I am an OSX user these-days, and don't typically worry about such things.
What's "wrong" is that it's been demonized by the "We hate Lennart" crowd.
Well, evidently the opinion from the systemd author's website will be pro-systemd. And very much "pro" at that, I just read the page regarding myths about systemd, and apparently all of them are invalid. Who knew?
I myself think that they're trying to fix a non-existing problem. Sure, booting up faster is nice, but in a server environment it's not that big of a deal. Every sysadmin knows shell scripting, why mess with that? And before you tell me systemd is backwards-compatible... why use it if you're gonna keep your shell scripts?
There are still alternatives, thankfully. The BSD's should go unscathed from this mess, I reckon. Good on them.
Indeed, they were both biassed links. I googled a few other sources but didn't find anything particularly enlightening or worth linking to.Intelligently managing dependencies between services seems like a good idea, which appeared to be a reasonable advantage not provided nicely by the other systems, from what I could find in 5 minutes.I'm not for-or-against, I just would have preferred it if TFA actually made some kind of logical argument beyond not wanting to wear a blue hat because everybody knows red hats are what Cloister intended. [wikipedia.org]
why mess with that?
because it's 2014 and perhaps we don't need to keep legacy technology around just so a group of people can feel superior, perhaps we should use our latest knowledge to revisit old problems and propose a way which might reduce maintenance, use modern techniques that more people are familiar with and get rid of cruft that people are used to skipping around, instead we can just write it all out and have a clean system.
ever tried to debug an email server? nightmare....such a bunch of legacy hacks and patches, nasty design and awful learning curve, XMPP does what email should do much better than email does, also, multiple SSL certs? separate ip addresses? holy crap....I'm glad companies are throwing email in the trash and upgrading whenever they can, facebook, gmail, hotmail....they ALL work around the email server problem by providing a frontend which looks like an email server, but internally, does it's own thing once you're inside the gates....if the big guys think it's trash...then surely we should listen..
I had problems with pulseaudio to begin with, but now it seems to work flawlessly, maybe it's too complex, it could be stripped down and layered so people who wanted network transparency could install a library to do it, instead of building it in, a more modular architecture might be nice, but overall, this is what happens, it's called progress.
I'm glad somebody is trying to modernise these old systems.
Unfortunately the architecture is bloated such that no one could ever describe it as "clean".
Its NOT a new init system. Its a new init system, and a logging system, and a hotplugging system, all incredibly tightly integrated for frankly no good reason at all other than to make it difficult to use alternatives or replace it piecemeal.
And the way it was rammed into place was getting some GUI desktop environments to require it. Absolutely disgusting political behavior.
No, I think it would nearly define an un-clean system, the opposite of cleanliness.
I am slightly concerned with security issues, so my embedded systems that don't have or need hotplug systems or logging are now vulnerable to future hotplug and logging bugs, which totally sucks.
Its architecture might be brain dead but I haven't had any problems yet (crosses fingers). Replacing a craftsman's toolchest with a swiss army knife might sound idiotic, but if it works, well, that's not so bad. I acknowledge there are negative secondary effects like "here's something with an awful architectural design and it works, so lets copy that design style".
logging and hotplugging are important when your system is booting up, or services are running in response to devices coming and going.
remember, that as programmer, we all understand that "v1" is always the worst, "v2" fixes some problems and "v3" is where you start to implement new ideas, if this is v1 of a new architecture, then it can be fixed.
but saying that no progress forward is a good thing is just backwards thinking, sometimes you need to branch out and do weird things in order to find better alternatives.
obviously the people designing these systems are not idiots, so they either don't value your feedback, because their idea of a clean system differs from yours, or it's already possible to do what you suggest, but you didnt know it, or that nobody knows what opinions you have, or it's a future idea that will come down the line.
you're post reminds me of a wayland thread, it has a lot of similar statements.
Is systemd less featureful than the system it replaces too?
Your post is interesting and well written, although I don't agree with most of it, and have no idea why its posted as a "reply" to my post because its apparently entirely unrelated to my post.
no comment on tight integration solely for "product tying" purposes
no comment on rammed in because of demand from some desktop environment rather than any organic desire from users or admins, or as near as I can tell, anyone at all actually wanting it...
no comment on likely security issues
no comment on architectural design other than its new therefore it must be better. I've been around too long, fooled too many times, to fall for that one LOL. That one might have worked on me in '81.
does contain tangential appeal to authority, which is generally anti-convincing to me, but whatever.
does contain distraction of wayland. I notice a certain similarity in social behavior behind both the waylandites and the systemd supporters. Where are these people coming from?
I do agree with "v1 can be fixed" although not sure how tight integration into unrelated areas and lack of compliance with existing standard interfaces helps speed bugfixes. Usually that's not the preferred architecture and development style for rapid bug fixing. I've not been hit by any bugs so I've not researched that situation in depth.
One interesting thing to think about WRT systemd is most of the opposition revolves around negative PR about its architecture and how its being rammed down peoples unwilling throats. Yet it hasn't been a serious problem, at least for me, although logically cruddy and poorly designed and managed and deployed software should be an epic fail causing me massive headaches. Yet it doesn't, not yet. This conflict does not compute... That indicates the possibly, that the incredibly negative steaming cloud around systemd might not be the most fair and unbiased coverage. In that case, the most logical way to support systemd would be to fix the coverage, but the supporters have been remarkably ineffective at that task. All we get is authoritarianism, mailing list bans, false dilemas, all that kind of stuff. If the code is actually any good, it'll eventually be revealed as good code, although the people defending it generally seem opposed to that strategy, which is even weirder.
Don't you even notice that your argument applies to Slashdot Beta exactly?And nevertheless, you are here. On a site built on nothing but "legacy technology". Instead of http://beta.slashdot.org/ [slashdot.org] with "modern techniques". "It's called progress", isn't it? ;-)
It's really funny, but rather hypocritical.
Agreed. Being new for the sake of being new has no purpose.Here we are, on SoylentNews, are we not?
Slashdot Beta removes tons of useful features, in favor of trendy (aka ugly) new visual design. systemd has more features than other init systems. So it's quite the opposite.
As for "legacy technology" vs. "modern techniques", systemd is written in good old-fashioned C, just like Unix and Linux, not some trendy new language-of-the-week.
Things which "have more features" tend to serve as drop-in replacements for whatever they're designed to replace, and to outcompete them on the merits.
Systemd isn't noted for being capable of either. So is more properly defined as having *different* features.
Which is precisely the problem. Not everyone likes the new featureset better than the present one, and some like being deprived of choice even less.
oh no, I agree with you, I wouldn't use a codebase like this for a modern website, I'd start again and write something which solved those problems in a better fashion, but also let other people have their opinion on the templates that run the website, the data layer is one thing, but I dont see why they screwed up the templates so badly.
also, soylent news's interface is very old, antique and pretty hideous
so it's not hypocritcal at all, I have the same opinion about both, they are both old, out of date, solving problems that no longer exist and there are better solutions to be found.
(sorry, I didnt see your reply until now, so thats why it's a little bit late)
I myself think that they're trying to fix a non-existing problem. Sure, booting up faster is nice, but in a server environment it's not that big of a deal. Every sysadmin knows shell scripting, why mess with that?
SysVinit scripts don't have any way to restart services that have quit/crashed. That is EXTREMELY important on servers, and it's absence is notable on Linux.
There are various add-ons that do this, like daemontools, but they can't replace SysVinit, so you're stuck maintaining two mutually incompatible methods for running services.
I don't care about boot-up times, but not being able to have all system services automatically restarted (without human intervention at 3am), should anything happen to them, is a glaring failure on Linux, putting it a couple decades behind its competitors.
SysVinit scripts don't have any way to restart services that have quit/crashed. That is EXTREMELY important on servers, and it's absence is notable on Linux.
This is the dumbest thing a sysadmin can do, have services by default restart automatically on crash. You should first try to identify the problem cause before relaunching the service, to make sure it won't happens again.If you have a critical service that needs to be restarted, there is daemontools and some other alternatives. Making the automatic restart a default and part of the init system is dumb and dangerous, just serves to "hide under the rug" any issues that the crashing services have, until it is too late, and you have data corruption or worse.
This approach is for me the worst - "as I don't understand why people would use two tools with two complementary philosophies, I make this impossible, by adding the functionality I use to the main tool and making it impossible to be replaced without replacing everything and the kitchen sink".
Your comment just oozes with obvious ignorance about managing hundreds of servers doing serious work. You would NOT want to be paged at 3am just because nscd crashed after 600 days of uptime. It's utterly idiotic to claim someone needs to investigate every such happenstance, or that you should rewrite all your startup scripts so every system service is run out of daemontools. After all.. ANY service that you need to have running is "critical" and failure can't be ignored.
You offered ZERO example scenarios to backup your breathless assertion for how automatic service restarts are or can be either stupid or dangerous. If there was any such issue, it would be looming over daemontools since forever, and the widespread adoption of systemd by every distro out there just serves to show the experts know something you obviously do not.
My main problems with systemd are not technical.
1. It is LGPL. So there is no need to redistribute fixes. This is a RedHat sponsored project. The systemd developers do not at the moment seem to publish backport fixes just update fixes. So if RedHat (the company) for RedHat (the product) decide to backport fixes to a particular release, as they normally do, they are not under any obligation to publish source code of these fixes giving them a clear advantage and making Ubuntu server, Oracle Unbreakable, Scientific et al do all that rework.
2. All the daemons are bundled and tightly integrated. So if you choose a window display manager that requires the systemd-logind component your entire init system choice is now overridden. There is no plan to break up functionality into seperate packages that are independent so you can pick and choose what you want. The amount of services it has subsumed are core, critical and required by many other systems. dbus, logind, init, cgroup management et al.
3. No "advanced mode". Everything must go through systemd. For example, if there is some novel thing you want to try with cgroups it must be done via systemd. The last I read on the systemd devel list was that systemd will go as far as hiding cgroups from users (by users I mean sysadmins) and presenting slices. No ability to create your own cgroup policy engine, you have to use an api/dbus to instruct systemd to act on your cgroups.
4. Stifling independent innovation. Assuming points 1 to 3 are valid, developers must work in the systemd ecosystem or face not being adopted. Even if new "hyper init system X" gets invented and has unheard of, unimaginable functionality it will have to be integrated into the systemd packages or not be used. People won't be able to try it, they won't be able to install it without installing huge core components of their OS. And once a project is part of the systemd project the independant philosophy that may have driven the innovation will be subsumed.
In my opinion, this is very much the policy attitude of gnome all over again. Choices on behalf of the user "for their own benefit". "We're doing it to help you" etc. Remember the whole gnome argument about opening a new file explorer window every time? You couldn't have the old behaviour anymore because the gnome developers decided it was inefficient and you didn't want it.
Following the idea of "do not attribute to malice what can be explained by ignorance", I expect these developers are genuinely trying to build a better system and fix problems they perceive as important.
The problem is that it is a viral solution. All it takes is your favourite application to require one tiny aspect of systemd and you have the whole thing, whether you want it or not.
Systemd developers do not seem to be interested in building a system that contains independent and replaceable modules. Which is fine, it is their idea and their product. It does however mean that it heavily restricts the choice of sysadmins, distribution maintainers and users.
**By modular I don't mean ~100 tiny binaries in a single package, which is the current systemd. I mean 20 packages each with a well contained bundle of functionality, that you can choose from as other alternatives become available.
Coherent explanation; thank you!
It is LGPL. So there is no need to redistribute fixes.
There is nothing in the LGPL that says this.
If you distribute modified versions of LGPL code you must distribute the modifications, just like GPL.