SoylentNews is people
SoylentNews
Controversy is nothing new when it comes to systemd. Many people find this new Linux init system to be inherently flawed in most ways, yet it is still gaining traction with major distros like Arch Linux, openSUSE, Fedora, and soon both Ubuntu and Debian GNU/Linux. The adoption of systemd for Debian 8 "Jessie" has been particularly fraught with strife and animosity.
Some have described the systemd adoption process as having been a "coup", while others are vowing to stick with Debian 7 as long as possible before moving to another distro. Others are so upset by what they see as a complete betrayal of the Debian and open source communities that there is serious discussion about forking Debian. Regardless of one's stance toward systemd, it cannot be argued that it has become one of the most divisive and disruptive changes in the long history of the Debian project, threatening to destroy both the project and the community that has built up around it.
(Score: 2) by E_NOENT on Sunday September 28 2014, @10:41AM
...who find startup times dominated by POST up front...
Amen to that. It's gotten a little out of hand...
I'm not in the business... I *am* the business.
(Score: 4, Interesting) by VLM on Sunday September 28 2014, @11:32AM
For reasons very on topic to this article discussion, I installed freebsd 10.0 on Friday and started working on my recipes to integrate it with everything else.
The default boot loader for freebsd pauses for 10 seconds asking if I wanna go normal/multiuser or singleuser/rescue or whatever other options. The rest of the boot takes less time than that bootloader pause.
There's some heavy propaganda that its impossible to boot quickly without systemd but freebsd is pretty snappy, and it wastes most of its time in POST and bootloader anyway.
Another weird problem I've observed is xorg and friends take longer than the rest of the system.
So its like 10 seconds to post, 10 seconds for the boot loader, system boots in like 5 seconds, X takes maybe 10 seconds. Then LDAP and AFS (or maybe kerberos?) are unhappy for perhaps the first 3 minutes or so, such that I can't log in. If I could magically lower my system boot time to zero it would only improve boot times by about 3%. And the improvement isn't going to be that great and the pain isn't going to be worth it (very gentoo)
And this is on a desktop with all kinds of stuff running. The servers usually only have one service, so "mysql", thats it, so they boot even faster.
(Score: 0) by Anonymous Coward on Monday September 29 2014, @04:48PM
Are fscks, scsi device enumeration, and more recently: udev(systemd?) hanging the system for 30 seconds over whatever that module 'issue' was that Lennart complained to Linus about. The only other one has been ubuntu hanging for 60 seconds on network bringup for devices that aren't in the system (I've migrated HDDs between systems pretty regularly, either due to upgrades, to save time rearranging hardware, or just curiousity.) In that regard I haven't found a good way to either purge old network configs, or at least get it to ignore them for a faster bootup. Given that these systems are up for weeks/months at a time on average it hasn't been a major deal however. And in that regard system falls flat regarding benefits versus complexity. Most all of the plug and play features offered by systemd were already available from other sources. Most of them worked in a transparent fashion (Save maybe using Thunar or E17 for removable drive mounting instead of gnome/systemd.. do both of those use gvfs as their backend?)
(Score: 2) by present_arms on Sunday September 28 2014, @11:32AM
Can't argue with any of those points, POST on a server is a bane sometimes. Luckily a reboot for servers is a rare occaision (one would hope). I personally will be avoiding systemd with a passion, I'm pretty sure there will be more forks happening as more distros move to systemd.
http://trinity.mypclinuxos.com/
(Score: 2) by present_arms on Sunday September 28 2014, @11:37AM
apt-get install systemd
Reading Package Lists... Done
Building Dependency Tree... Done
E: Couldn't find package systemd
This is what I like to see :D
http://trinity.mypclinuxos.com/
(Score: 2) by maxwell demon on Sunday September 28 2014, @12:22PM
As a workaround you could create and install a package "sanity" which declares conflict with systemd. Then any attempt to install systemd will tell you that you'd first have to remove sanity.
Now all you have to do is to make the kernel package depend on sanity, and systemd cannot be installed any more. :-)
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by present_arms on Sunday September 28 2014, @12:58PM
That's actually a cool idea :)
http://trinity.mypclinuxos.com/
(Score: 0) by Anonymous Coward on Sunday September 28 2014, @01:19PM
A better idea is for Debian to just not include systemd at all.
(Score: 2) by present_arms on Sunday September 28 2014, @02:58PM
Right, but it seems to be a done deal and anyone objecting seems to be silenced, it's heartbreaking that a once great distro is willing to be this stupid.
http://trinity.mypclinuxos.com/
(Score: 0) by Anonymous Coward on Sunday September 28 2014, @12:00PM
Even on a rolling release distro like arch, It used to be kernel upgrades only. I could skip minor kernel releases for months unless I knew there was an issue. Now with systemd, there's so many packages not to be upgraded that it's impossible to keep track of what exactly is going on. Basically, I wait until I start seeing weird log messages about missing PAM modules and the like. Wait until I'm next on site (because if something goes wrong with pid 1...) and reboot then. For offshore cloud based servers, I run a backup and cross my fingers before rebooting.
Systemd -- the spanner in the works.
(Score: 1, Informative) by Anonymous Coward on Sunday September 28 2014, @12:34PM
Jesus Christ. Are these log messages about missing PAM modules showing up in systemd's binary logs? As an AIX admin, all of this stupidity from the systemd crowd really blows my mind. The fact that their software can fuck up PAM while logging about it to an unreadable binary log file is just astoundingly dumb.
(Score: 2) by cafebabe on Sunday September 28 2014, @12:38PM
By my calculations, a full marching bit test [eventhelix.com] on DDR3-1600 RAM would progress at 50MB/s. I assume shortcuts are taken, such as testing memory modules in parallel.
1702845791×2
(Score: 2) by E_NOENT on Sunday September 28 2014, @02:17PM
Fun video:
https://www.youtube.com/watch?v=3CkvZtLodGc [youtube.com]
I'm not in the business... I *am* the business.
(Score: 2) by cafebabe on Sunday September 28 2014, @05:38PM
So, in that example, a server with 64GB takes 309 seconds to boot. 137 seconds is for the memory test. That's about 0.5GB/s. But, hey, after you've diagnosed conflicts, systemd will reduce that by about 0.5 seconds.
1702845791×2
(Score: 2) by E_NOENT on Sunday September 28 2014, @07:44PM
I agree.
The whole "faster boot times" schtick is pretty meaningless IMHO.
I'm not in the business... I *am* the business.
(Score: 2) by cafebabe on Sunday September 28 2014, @07:51PM
The claim of faster boot times is worse than meaningless. It demonstrates a lack of understanding of typical requirements and it demonstrates a lack of understanding of Amdahl's law [wikipedia.org].
1702845791×2