I've basically decided systemd isn't for me and have uninstalled it from my systems. The last straw for me was a recent security issue:<p><a href="https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet" rel="nofollow">https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_...</a><p>Which made me re-evaluate systemd. Fundamentally creating a monolithic tool to take over from many small single purpose tools seems counter to the UNIX philosophy, and makes it harder to hack on my (mostly desktop/laptop) systems.
A article about programming to systemd and how it helped the various distributions turned into HN emotional responses to bash systemd.<p>I like systemd and it has helped Linux advance. init was a mess and no one still has come with a golden response that shows the world how anything would be better then systemd.<p>systemd answered a difficult question and hopefully we willsee more similar advancements shortly for Linux.
Another nice video discussing the current limitations of using systemd user sessions for starting up desktop environments (=user session) is: <a href="https://www.youtube.com/watch?v=hq18daxTkLA" rel="nofollow">https://www.youtube.com/watch?v=hq18daxTkLA</a><p>On July Martin Pitt already started to discuss some of the difficulties on systemd-devel mailing list: <a href="https://lists.freedesktop.org/archives/systemd-devel/2016-July/037017.html" rel="nofollow">https://lists.freedesktop.org/archives/systemd-devel/2016-Ju...</a><p>During the systemd conference they've been working to create a good solution for this.
Oh wow, I didn't know about `systemctl mask`. I've been fighting with a computer that takes forever to boot because of nfs, even though I do not want nfs enabled. I was trying to use `systemctl disable` to no avail, but `mask` looks like it'll actually do the trick.
I think systemd the init should be separated from the rest of it. This will allow it be more easily managed, secured, developed and be replaceable by other inits thus retaining one of the most important aspects of Linux and prevent any single entity beyond the kernel from gaining too much influence.<p>The functionality that creates these deeper tie ins to Gnome, udev and others today prevent other inits from working for instance with Gnome. Now they want to add a kernel bus. This will make it extremely difficult to replace systemd. Can any supporter of open source and Linux really support this?<p>A init is a critical subsystem and should have limited scope that is clearly defined, be thorougly tested for that scope and released. Continuously developing and adding features to it does not make for a stable experience. Debian Jessie is now on a outdated version of systemd 2.15 while Systemd is at 2.31.<p>Things like predictable network names are ironically named as now they are not predictable to end users and scripts that work across systems. Things like eth0, eth1, wlan0 abstract the underlying hardware. If your solution cannot even abstract it and retains the arcane bus names and makes it difficult to even read let alone work with the interface name how is it a solution.<p>Things like binary logging may be important to a small subset of users and they should have an option to enable it. But why should it be imposed on everyone by default? The technical debt of niche cases should go to those who want it.
On Desktop and servers I had to reluctantly use systemd as-is, no time to replace it basically. never enjoyed it really.<p>On embedded linux I make, I use everything else but systemd.<p>I still worry that over time systemd will be integrated so deeply into linux that it will be impossible to remove and also leave no chances for alternatives and if its monolithic approach will be wrong then it will be too late.<p>Or maybe systemd wants to be everything, to make even linux obsolete
I've not looked closely at systemd yet, but my initial attempts with using sysctl on a test ubuntu 16.04 server, seems to reflect my experience with usage of svcadm in solaris/illumos, where the latter requires XML manifest instead of a "simple" script.<p>Is this an apt comparison for systemd, or is it way better/worse (I'm not an expert, so I'll leave the qualitative opinions to others!) than that?