They didn't do it to align with the open source community. They did it because Canonical wants outside investors, but potential investors don't think Unity can make money.
If Slackware ever moves to systemd, it will be a sad day, but i'll keep using Slack because it's the whole distro that I want, not just how the system initializes services. If I could deal with Windows's bullshit, I can deal with systemd. Just like ConsoleKit, and PolicyKit, and NetworkManager, and UPower, and PulseAudio, and HAL, and UDev, and DBus, and all the other annoying crap that's been shoved down our throats over the years. Now I know how old people feel when they talk about modern cars...
That's an odd assumption. I have. I'm a big fan of standardisation.
I understand some people not liking systemd, but there are a lot of folks out there who really prefer it. Once I started adopting it, I no longer needed/wanted to support cross-distro start scripts, since systemd does that. So non-systemd distros were dropped.
We're moving more and more to having unified low-level services across Unices, so it stops being about stupid things like "Oh sorry, Arch can't run this because it uses its own audio stack even if we're just using audio to make a notification sound", and starts being about the things that are fundamentally different about the systems.
Think about how nice it is that we don't have to recompile most things for most kernel versions. Why do we have to set up multiple startup script mechanisms?
Yes, nobody has ever had to recompile their application to work on a new kernel. If you mean that's nice that there's binary backwards compatibility, I agree. I don't see what this has to do with supporting multiple systems.
> Why do we have to set up multiple startup script mechanisms?
Why do we have to support multiple <insert any kind of software> ?
> We're moving more and more to having unified low-level services across Unices
AFAIK, the only thing I know of moving toward middleware unification specifically is Linux desktop software. Choosing to use systemd in exclusion of everything else is "unification" in the same way that nationalism/xenophobia/homophobia are. (i'm aware of how mean that sounds, but it's the closest comparison I can think of)
It is certainly nice that there is now middleware that abstracts the underlying software that controls the hardware, for example, or that authentication and authorization are more uncoupled. But this is really almost the opposite of what systemd does.
Although I'm speaking with my sysadmin hat (I have a few hats). I have a lot of software deployed/managed through Ansible (from node/ruby/python apps to proprietary apps). They might not provide a unit file, so I have to write my own (and I might send it upstream).
The main pain point I encountered regularly, was making sure that the process starts at the right time, has proper stderr logging and monitoring. I rarely bump into kernel or library problems (but that's just me, I'm not denying the problem). I understand what you mean though, systemd is just one of the base components. It doesn't fix everything, but it helps.
On "write once": I feel bad for people who have to read the shell scripts I've written. I think they're good and I'm a fan of keeping it simple, but my scripts don't come with a manual. Any junior dev can understand my unit files (tangential: that's also why I like Ansible/Puppet/etc).
I didn't write upstart units for that reason. I now write systemd units and it's wonderful.
By moniculture, are you saying that adopting systemd leaves you vulnerable to cross-distro vulnerabilities hitting a bunch of systems all at once? (Most of my knowledge on the downsides of monoculture come from Irish history) Or are you pointing to something else?
That's not a good standard for an operating system supposedly about flexibility, compatibility, and choice. And it's even more annoying for software which isn't intended to be run in a monoculture, like most of the open source/free software world.
And for that matter, did anyone make a systemd-to-sysv converter ? Because that should surely be possible, systemd service files being declarative.
If such a converter did exist, then suddenly, the systemd "service files" could become an actual standard, since they'd be (somewhat) compatible accross sysv and systemd. And maybe we could work from there and support other init systems...
Your suggestion of turning systemd's APIs and formats into a standard is not out of the question, but it would never happen. Poettering and his team showed they have zero interest in making a compatible system, or in making any concessions at all. Standards have to do both. And other platforms have to buy into the standard, otherwise it just sits there like a third leg.
The way it would probably end up is a project like Alien would adopt some of systemd's quirks. But so much of systemd is tied directly into the application via APIs that it would be a huge PITA to support both systemd and anything else - hence why some devs simply drop support for anything that isn't systemd. It's the same sort of thing that causes devs to only develop for Windows, or iOS/OSX, because it's more popular and porting to Linux is too expensive.
Another is daemonization. In traditional systems, long-lived processes daemonized themselves and took care of themselves. The big benefit was independence and flexibility. You don't have to do a lot of work to port it, or maintain it, or administrate it. A shell script and some simple conventions allow it to run in almost any environment, and all of the services basically worked the same way. Often this was out of the necessity of a complex program's needs, where the way it manages its tasks, or shares memory, or communicates with other processes, or handles signals, or is checkpointed, or debugged, etc may have had complex requirements.
But now, systemd recommends you not daemonize your process. Let systemd manage it for you! This works great for very simple services, but not so well for complex ones. Now people are writing more services that can't manage themselves and thus need something like systemd to take care of it, or it simply won't work as a daemon on a non-systemd system.
The systemd people would say, any system can adopt these calls and these methods! (Which is equivalent to saying, any OS can adopt Linux's completly nonportable and specific syscalls, even though they already have a working alternative) But that's not the end of it. Every piece of systemd that you adopt, then depends on other piece of systemd, so you can't just pick up one piece of the pie. You have to eat the entire thing.
The benefits of that unification are very, very tangible for package authors/maintainers - they now have to write just one flavor of a service file. And that is a great thing(tm) for the Linux community as a whole - well worth my own gripes with systemd itself.
Maybe switch to KDE’s KRunner? It’s the most functional and extensive search framework yet.
For me it's solving the problem of simply and reliably wiring up persistent and resilient services (not shipped with the OS).
I don't know about you, but that's a need I especially have on servers.
When systemd works, it works remarkably well.
That aspect was already largely solved, and has been for a long time. runit, upstart, daemontools etc.
Daemontools, like a number of djb's tools, manages to really manage to blend an amazing level of "just works" and "ZOMG, I configure this how?!"
Have been using it since it was introduced in Fedora 16 (as I was a fedora guy) and I've never been convinced of its use on a server.
I understand it solves some problems but does so while introducing new and harder to remedy ones. (like tight ABI integration).
I don't mind systemd (ok, I'd criticise it but not nearly hate it as much), but I don't like that it's now the default target which forces me to use it in future.
I'm a Systems Engineer, so I have different needs from servers than Developers I guess, I want things to be easy to debug and diagnose.
I will say that I'm not only accustomed to systemd or sysvinit, I've also used runit at scale, along with SMF on Solaris and openrc.
SMF Beats the pants off systemd, even if it uses XML internally.
https://news.ycombinator.com/item?id=14044287
I think there was a lot of hate for PulseAudio too.
I wonder what about Kay Sievers now, which was even hated by Linus Torvalds at one point.
I am sure the people who hate it have good reasons, but all I've heard is 'doesn't follow UNIX philoshophy', (guess what, the whole Linux ecosystem doesn't really, even Stallamn isn't a fan), 'centralized', (somewhat valid, but there's still Gentoo and Void Linux), binary text files, (installing a 'text logger' over journalctl takes 5s and the filtering capabilities of journalctl are awesome).
Also, the hate for PulseAudio largely died years ago. I for one am glad for people like Pottering, who are willing to think longer term and produce great* software.
Yes, maybe more buggy at the start, (but not really the case with systemd), but great eventually. Also, let's be honest, the reason you see more bugs in i.e. PulseAudio is because it is being developed in the open from its inception.
For example, how do you like the fact that init now comes with "hidden" timers ? After you've scoured every place that a "traditional" Linux might put scheduled tasks, you've come to the realization "Ooooh, now my init has its own cron!". Because obviously an init system needs its own cron!
Or the subtle way it breaks existing SysV compatibility. An RPM/Deb package drops its SysV init file at /etc/init.d, and the next thing your ConfigManagement system does is try to start the service - quite standard. Bang - "Unit not found"! Why? Now on systemd-enabled flavors, you need to reload the mofo after dropping in your files. Of course Systemd could hook into dbus and run crons, but it can't be bothered to inotify or even jit-check-upon-request /etc/init.d. Because subtle breakages are cool!
How about the systemd-hostnamed service? Why on earth would we need a service to change the hostname? And why should it care about the "chasis type" of the machine?
These are just some of my own WTFs encountered during my admittedly short but language-colorful interaction with systemd. I have nothing against the Systemd unit files, but the functionality/bug scope of the whole thing is way bigger than I'd feel comfortable with!
P.S. Poettering is reportedly a townie, so I'd love to buy him a beer someday and berate him over it.
They're not "hidden", just managed with systemctl like other services, you can still use regular cron if you'd like.
As to the rationale of including timers, it is for stuff like mounting and unmounting remote disks etc, at boot, which I personally would include under the responsibilites of a modern init system and 'system manager' in general, same with taking care of TRIM every so often etc., but I appreciate that it isn't for everyone.
> Or the subtle way it breaks existing SysV compatibility.
The SysV init scripts would regurarly break in subtle ways by themselves to be honest, I find systemd a much saner option.
> How about the systemd-hostnamed service? Why on earth would we need a service to change the hostname? And why should it care about the "chasis type" of the machine?
The systemd network stack is entirely optional and intended for scenario where you can't afford/don't need the 'fatness' of NetworkManager, just because it's there, doesn't mean you have to use it.
> P.S. berate him over it.
Plenty of people already did so, over and over, but have fun, considering you'd be buying him a beer...
So far in the history of nix, services have never equaled periodic tasks, to my knowledge. In that sense, it's a hidden surprise that would sooner or later bite everybody that has not been initiated in systemd. It makes things harder to debug.
> As to the rationale of including timers, it is for stuff like mounting and unmounting remote disks etc, at boot
Now do you go from that need to "and that requires an internal crond implementation in your init system". Why not atd, or regular cron, or sleeping processes? I'm genuinely curious, so if you're aware of public discussion of it, please point me in that direction.
> The SysV init scripts would regurarly break in subtle ways by themselves to be honest, I find systemd a much saner option.
I appreciate that the chaining and dependencies of SysV init were horrible. That doesn't make it OK for systemd to introduce more subtle breakages in even a very basic* usecase.
> The systemd network stack is entirely optional and intended for scenario where you can't afford/don't need the 'fatness' of NetworkManager
In the scenario where you do not need NetworkManager/GUI hostnamed would be quite worthless as well. /etc/hostname and the `hostname` command are more than enough to handle that case, thank you.
I guess my main issue with systemd is that it introduces (mostly?) unnecessary complexity, which makes me waste more time debugging problems. Of course it is better than SysV init, and I'm very happy with the syntax of system files. Yet, upstart showed that you can have those niceties without an excess of complexity.
The implementation is retarded. Last week my providers' iSCSI fabric suffered a glitch, which hosed a whole bunch of servers for hours because systemd refused to boot when it found the volumes not present. These were in no way critical to the operation of the stack. However, some moron somewhere decided that locking the system for 5 minutes on boot, and then simply refusing to boot properly, when everything required to boot is actually in place and OK is the correct course of action. I have enough of that kind of deranged thinking to deal with coming from Windows, I don't need it from my Linux machines.
Systemd sucks for servers. It might do a lot of nice fancy tech stuff, but it is extremely poorly thought out for use on the server.
This is not normal systemd behaviour, it waits for the resource, but only 1min 30s by default and then continues booting, (unless the services are considered critical for reaching certain target), logging a failed service, someone must have therefore explicitly configured a custom behaviour in your situation.
> The implementation is retarded.
May be, or may be whoever configured the server this way is, who knows?
> I have enough of that kind of deranged thinking to deal with coming from Windows
As I said above, this is not standard systemd behaviour.
I am not saying that systemd is perfect, but your case seems like misconfiguration, rather than "deranged thinking" from the systemd devs.
I'l encarouge you to read more on its configuration, it's actually fairly flexible, this[1] is a solid starting point.
(this was originally meant as a reply to above comment was mistakenly posted to grandparent.)
1 - https://www.freedesktop.org/software/systemd/man/systemd.ser...
2 - http://stackoverflow.com/questions/33776937/how-to-change-th...
Currently.
If you want the hostname to be preserved across reboots, you need to save it on disk - canonically, in the /etc/hostname config file.
Since /etc/hostname is an important per-machine config file, you probably want it owned by root.
Since you may want to edit this config file from a GUI control panel of some sort that you launch from a desktop environment running under a non-root user, you need a mechanism for the control panel process to be able to change the config file.
There are several ways to accomplish this:
* run the control panel process under root (for example, using sudo). This is not a good idea, especially under X11, since GUI toolkit libraries are not security hardened, have a large attack surface thanks to various GUI IPC mechanisms, and your control panel process could be subverted by hostile processes that have been waiting in the background for just such an occasion to arise.
* put your non-root user in a group which has write access to /etc/hostname. This is the traditional Unix solution, but it's not very flexible. If your user was not in the hostname-writer group, you will have to log out and back in for the change to take effect. And you can't create policies like requiring entering a password before performing administrative-type actions (unless the password is for sudo - and that is dangerous, see above).
* run a daemon under root that allows making edits to /etc/hostname. Provide an IPC interface to request a change to /etc/hostname; have the daemon check, via a call to a flexible, configurable authorization service, that the caller process has the right to perform a "change /etc/hostname" action (the authorization service might reply yes if, for example, the caller's user belongs to a specific group and verified his password within the last N minutes); and only then make the change on behalf of the unprivileged caller.
The latter seems like a better solution. Maybe over-engineered for managing a one-line config file, but definitely the solution to go with for more complex situations; so we might as well use the general solution in this case too.
The daemon is hostnamed; the flexible authorization service is polkit. See https://www.freedesktop.org/wiki/Software/systemd/hostnamed/ for more details.
While being a formally valid solution, it all seems like waste of simplicity and totally uncontrolled design process.
Good question! I've wondered about this before too, ought to research it.
> Is hostname the only thing with such problem, the only gui-configurable system-wide setting?
Of course not :) Systemd provides a half-dozen similar daemons for configuring things; hostnamed is probably the simplest one of them, so I was trying to justify why so much engineering went into something that looks so trivial: it's because the approach is generic.
The idea is that a non-systemd system could reimplement some of these daemons (or rather, their dbus interface; you could implement them in one executable if you want) - and the parts of a standard control panel application relevant to your system would just work.
"sudo vim /etc/whatever.conf" is perfectly fine.
"sudo gedit /etc/whatever.conf" might give an attacker already on your system a way to gain root.
Yes, just keep doing that. I run several Linux boxes with systemd, all of them without hostnamed.
Forcing all your users to use the One True Way on a complicated system usually just means you're ignoring many legitimate use cases. Microsoft still does that on Windows (APIs and ugly registry entries over everything) - and while I cringe everytime I see it, I still recognize that the approach has value for some situations.
Many of the daemons for systemd on the other hand are optional, which I personally find to be great. I can use the ones I need and leave the ones I don't.
As for the GUI: Why use a text file? That might be a good use case for you and me, but a terrible one for someone not used to administrate *NIX systems. Why not allow both? As long as the file-based approach is not neglected, I'm perfectly fine with that.
This kind of excuse-making makes me rabid. "We will use our position of power to drag everybody through debugging our poorly made software because we are amazing and one day it will be great" is not a position I will ever have much respect for.
If somebody's enough of a genius to see the future of software, they're enough of a genius to make their shit work for the audiences they are currently shipping to.
But practically? The service-files are a pleasure to write, the documentation is excellent, and I've not personally had a failure I could attribute to systemd. (Though I did come close, learning that systems with an old version of "snoopy" installed wouldn't boot under systemd.)
And I know a lot of musicians who still find PulseAudio not fit for purpose. There's no hate, just frustration at the adoption of a bad solution crowding out ones that work better for their given use case.
It was the same with init, but instead of digging into greppable script files, you need to dig into Google and systemd manpages first, then dig into the actual issues second.
PulseAudio actually implemented a Dbus API to release its lock on the AlSA device. jack2 can use this automatically take over when it starts. There also exists two-way sound transport for sending sound from Pulse to JACK. If that was automatically set up also, then we would have a plug & play solution for pro/real-time audio on Linux.
I listed the ones I could find and stated why I disagree with them, you could've made this a useful post by listing some additional ones, but instead you choose to just spell, (miscase?), systemd wrong.
ZFS is not compatible with the GPL. Canonical is treading a risky path with what they're doing.
I would love ZFS to be native on Linux, BTFS has had too many scary data loss bugs to be able to trust it.
Now they do it again with Wayland/Mir! It actually takes a significant amount of both balls and goodwill to give up on the product that you invested so much into for the sake of aligning better with your open source community. Bravo!
FWIW, I too would like to keep the DE experience of Unity, and especially the Dash panel and shortcuts. If that expose-text-search could scan non-focused browser tabs that would be a killer feature, but that's for the other thread.
The idea of "Let's simply ask HN users what they think" is a gem, that I suspect will now make it into many PMs' playbooks ;)