Live data from Hacker News

Systemd redux: The end of Linux

blog.lusis.org

381–390 of 464 posts

Re: Systemd redux: The end of Linux

#381

I think the article got one thing wrong: That sooner or later every GNU/Linux distro will switch to systemd. I can think of three that most likely will not: Slackware, Crux, and Gentoo. Granted, the more that systemd binds itself to formerly modular userspace utilities and apps, the more pressure on those distros to make the switch, or else either fork every systemd userspace app at the risk of being left behind. But…

I'm also interested to see how things play out with OpenWRT. High-end home routers are starting to get a lot more powerful with the transition to ARM SoCs and NAND flash, but they won't be able to run any software that depends on the systemd ecosystem while OpenWRT is still supporting the massive install base of hardware that systemd can't fit on.

Ditto for small ARM devices like the Raspberry Pi. When the RPi version of Arch Linux went to systemd, the system actually got slower in my experience. On such an already limited device, it was a quantifiable difference; before systemd, Arch was the fastest GNU/Linux distro for the Pi by leaps and bounds. After systemd, even Raspbian feels faster than Arch, and now Slackware is the reigning king of speed for it (again, among Linux distros).

Unfortunately Slackware is still a bugaboo when it comes to installing it on the Pi, but once you've got it on there you can image your SD card and have a ready-to-roll distro that's lean and mean.

Re: Systemd redux: The end of Linux

#382
post #87
post #49

Earlier quoted context omitted.

> The fact that the article says that Solaris is the 'best of breed stack right now' That well-known paragon of SysV systems 8)

I'm a bit confused, was that sarcasm? Doesn't Solaris use SMF and not SysV?

There's SysV Unix, and SysV init.

Solaris is based off of Unix System V, as are AIX and HPUX.

You can be based off SysV without utilizing the init system from it

Re: Systemd redux: The end of Linux

#383
post #7

Everything I read about SystemD is negative. Negative on the technology, negative on the people who created it. Nothing positive. How is it that SystemD is about to dominate the market? Who is driving SystemD adoption, and why?

It's necessary to understand that desktop linux has been total shit always, and this has caused incredible pain over the years to people who, against all reason, continue to try to use it. It turns out the bazaar can't create a polished user-friendly product, period. Nevertheless, Red Hat and Canonical and others continue to try to foster desktop linux, on the now-obvious misguided theory that (a) the desktop matters…

[deleted]

Re: Systemd redux: The end of Linux

#384

Going against the "divide et impera" principle, "do just one thing, and do it well", "everything is a text file" (configurations and logs) and "pipes" which are very natural idiom, in a UNIX-like system which has been built upon these principles , is just bad engineering, shallow understanding and, perhaps, too high ambitions of knowing better how to fix what isn't broken. The question why do we have this project and…

> Except that the problem doesn't exist outside discussions of

except https://en.wikipedia.org/wiki/Init#Replacements_for_init

this problem was noticed and was trying to be fixed for a long time, by a lot of people

Re: Systemd redux: The end of Linux

#385

Earlier quoted context omitted.

Wow, great comment -- and one that all who endeavor to innovate in systems should take to heart. As my former colleague Bart Smaalders was fond of saying, "the hardest software to upgrade is the software in our brains"; when inventing new abstraction, it must be done so sparingly and (as much as reasonable) by leveraging extant notions. This isn't merely to allow a technology to be readily understood (though that too…

I think it is a perceived lack of this kind of humility in systemd that has been so alienating for those who have a long history with Unix: it's not as if other approaches are being rejected so much as they are not being considered at all. I really have the feeling that people are using double standards here, especially when suggesting Solaris or Solaris-derived systems. Since systemd is implementing pretty much what…

This is a rather disingenuous response.

It assumes that this is a troll post - which I don't think is fair. The author has concerns that are legitimate to them, and outright dismissal as a troll, whether or not you agree with them, is petty and judgmental.

Second, you are somehow conflating dislike of systemd with love of sysv init. The cognitive dissonance here only makes sense to me if you believe that systemd is perfectly fine, and think that the only reason people dislike it is because it's different.

However, if someone is recommending a solution that utilizes SMF, is it such a stretch to think that it might not be because they are in love with sysv init, and instead might think that the implementation of systemd is lacking?

I personally like the underlying idea of SystemD - because I like SMF. I do not like the implementation of systemd, and also have reservations about the people helming the project.

Re: Systemd redux: The end of Linux

#386
post #355

Earlier quoted context omitted.

You know this is funny, I remember reading comments EXACTLY like this about 3-4 years ago but with pulseaudio in place of systemd. Pulseaudio was Lennart's previous project. It broke everything in linux sound for a while, everybody moaned and hated it and said it was the worst thing since the crucifixion of Christ. Yet, name one problem you had with sound on linux in the past year? There are very few. Pulseaudio now…

> Yet, name one problem you had with sound on linux in the past year? That's just it. Linux sound worked fine for me before Pulseaudio, and FreeBSD sound has always worked perfectly fine for me. In fact, FreeBSD solved sound mixing sooner via /dev/pcm virtualization (while Linux chose to create the Linux-only ALSA instead), and has always had lower observed latency. Pulseaudio screwed up my audio so badly that for a…

To clarify, "/dev/pcm virtualization" means FreeBSD does audio mixing and re-sampling in kernel space.

Re: Systemd redux: The end of Linux

#387

Going against the "divide et impera" principle, "do just one thing, and do it well", "everything is a text file" (configurations and logs) and "pipes" which are very natural idiom, in a UNIX-like system which has been built upon these principles , is just bad engineering, shallow understanding and, perhaps, too high ambitions of knowing better how to fix what isn't broken. The question why do we have this project and…

> Except that the problem doesn't exist outside discussions of except https://en.wikipedia.org/wiki/Init#Replacements_for_init this problem was noticed and was trying to be fixed for a long time, by a lot of people

Traditionally, one of the major drawbacks of init is that it starts tasks serially, waiting for each to finish loading before moving on to the next. When startup processes end up I/O blocked, this can result in long delays during boot.

For a server it doesn't matter, leave alone "broken". long delays during boot is grossly exaggerated, because delays are mostly due to network errors/timeouts or file-system checks, but you can do almost nothing "in parallel" without clean FS or configured network interface.

Well, for some Ubuntu for mobile devices they could have adapt some "optimized" sysvinit-scripts (not /sbin/init) replacement, but, please, don't tell us that everyone needs this. Leave servers and home workstations alone.

Re: Systemd redux: The end of Linux

#388
post #231

Perhaps this is a controversial idea, but is this not just someone finally taking the tried and true Open Source "advice" to heart? That is, every time I've reported something is broken, wonky, doesn't work reliably, et cetera, I've been told, "Submit a patch.", "Write some code.", or worse, "Implement it yourself." Someone finally got fed up with the haphazard state of affairs in Linux-land. Fed up with the fragment…

Lennart didn't just submit the code and put it out there. He lobbied other projects to hard-depend on it, and lobbied distros to adopt it. Systemd didn't succeed where less poisonous equivalents failed because it was technically superior (it isn't), it succeeded because of shady back-room politics.

How dare he ask other people to use the software he wrote.

Re: Systemd redux: The end of Linux

#390
Does systemd increase the security of the OS or reduce it? For example, does it allow currently-separated processes to dip into each others' memory space? I would appreciate a birds-eye view from someone familiar with the security ramifications of systemd.

Would not the incorporation of many loosely-coupled but individually secure mechanisms into a single monolithic mechanism be useful to an entity whose purpose was to monitor communications, view/modify systems unbeknownst to sysadmins and users, etc.? Yes, I'm talking about the NSA et al. I reference the following which also brings up Red Hat's control of Linux:

"Julian Assange: Debian Is Owned By The NSA"

http://igurublog.wordpress.com/2014/04/08/julian-assange-deb...

Post reply on HN