Why systemd matters?

The second big problem: Attack Surface

On a hardened system without systemd, you have at most one root-privileged process with any exposed surface: sshd. Everything else is either running as unprivileged users or does not have any channel for providing it input except local input from root. Using systemd then more than doubles the attack surface.

This increased and unreasonable risk is not inherent to systemd's goal of fixing legacy init. However it is inherent to the systemd design philosophy of putting everything into the init process.

Systemd: The Biggest Fallacies
http://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html

Demystifying the init system (PID 1)
https://felipec.wordpress.com/2013/11/04/init/

systemd is the best example of Suck.
http://suckless.org/sucks/systemd

RED HAT PAYING DEBIAN TO FORCE SYSTEMD

Systemd is not an init system!!
If someone characterizes systemd as an “init system,” you may safely assume that s/he is either utterly clueless or deliberately obfuscating the discussion. Calling systemd an init system is like calling an automobile a cup holder. Not even Lennart Poettering pretends that systemd is anything but the “Core OS” (sic).

What systemd is is an effort to re-create large portions of existing userspace (including login, job scheduling, and networking, just to name a few) inside a single process traditionally reserved for the sole purpose of starting *nix userspace. (Just in case it isn't clear, there is a huge difference between starting userspace (init) and being userspace (systemd).)

At the end of the day, how one perceives this re-creation of existing userspace strongly influences one's reaction to systemd. There are plenty of perfectly legitimate reasons to be troubled by this re-invention of the wheel; they range from the philosophical and aesthetic, to the technical and mechanical, even the purely political and brutally practical.

And that's part of the problem when folks start to “debate” systemd. Very few folks have the chops to think about, much less talk about all of these areas simultaneously. As a result, the discussion becomes fractured and disjointed, in what is literally the textbook definition of bikeshedding. Suddenly, a talking head who's never written a line of code in his/her life offers up an authoritative-sounding-but-utterly-bogus opinion on systemd's maintainability. Add in the fact that folks on both sides (including Poettering himself) act as if name-calling is a perfectly good substitute for empirical evidence, and the “debate” becomes indistinguishable from white noise.

Full story:
http://forums.debian.net/viewtopic.php?f=20&t=120652&p=570371

only autists have a problem with it

>>61539877
This. As a developer, systemd is infinitely more convenient to work. It unifies service start-up, shutdown and also logging. It detects when services change on disk.

>that picture

didn't need to write all this we already know you have autism

>>61539877
>>61539899
Even if systemd were a demonstrably superior technology (which it isn't), adequately spec'ed (which it isn't) elegantly designed (which it isn't), well-coded (which it isn't), properly documented (which it isn't),or developed by a responsive and responsible community with a history of delivering robust and reliable software (*cough*pulseaudio*cough*), systemd would still be at best problematic, for one simple reason: it's insanely expensive to implement, particularly given the fact that it doesn't solve any actual problem.

>>61539877
>>61539899
>shills destroying digits
I want reddit to leave
you are shilling for a windows tier code written by a german cuck who is receiving payment from red hat.

Linus Torvalds bashing systemd developers for making kernel developers work around their problems

Key, I'm f*cking tired of the fact that you don't fix problems in the code *you* write, so that the kernel then has to work around the problems you cause. 

Greg - just for your information, I will *not* be merging any code from Kay into the kernel until this constant pattern is fixed. 

This has been going on for *years*, and doesn't seem to be getting any better. This is relevant to you because I have seen you talk about the kdbus patches, and this is a heads-up that you need to keep them separate from other work. Let distributions merge it as they need to and maybe we can merge it once it has been proven to be stable by whatever distro that was willing to play games with the developers. 

But I'm not willing to merge something where the maintainer is known to not care about bugs and regressions and then forces people in other projects to fix their project. Because I am *not* willing to take patches from people who don't clean up after their problems, and don't admit that it's their problem to fix. 

Kay - one more time: you caused the problem, you need to fix it. None of this "I can do whatever I want, others have to clean up after me" crap. 

Linus

http://www.phoronix.com/scan.php?page=news_item&px=MTY1MzA

I have never hated anything as much as systemd haters hate systemd.

Just don't use it? There are plenty of distributions and operating systems that don't use systemd.

>June 2017 - systemd Hit By New Security Vulnerability
Looking up a hostname from a vulnerable Systemd-powered PC, handheld, gizmo or server can be enough to trigger an attack by an evil DNS service: the software's resolved component can be fooled into allocating too little memory for a lookup response, and when a large reply is eventually received, this data overflows the buffer allowing the attacker to overwrite memory. This can crash the process or lead to remote code execution, meaning the remote evil DNS service can run malware on your box.

"A malicious DNS server can exploit this by responding with a specially crafted TCP payload to trick systemd-resolved in to allocating a buffer that's too small, and subsequently write arbitrary data beyond the end of it," explained Chris Coulson, of Ubuntu maker Canonical, who discovered the out-of-bounds write in systemd-resolved.

The programming blunder, assigned the ID CVE-2017-9445, was accidentally introduced in Systemd version 223 in June 2015 and is present all the way up to and including version 233 in March this year.

This means it is present in Ubuntu versions 17.04 and 16.10. Canonical has put out a pair of fixes for 17.04 and 16.10 to address the flaw.

https://www.theregister.co.uk/2017/06/29/systemd_pwned_by_dns_query/

>>61540105
>XYZ depends on systemd
>ABC depends on systemd
ABC and XYZ being heavy integrated programs

>>61540197
>answering to redditor shills

I'm currently running systemd on my primary server because I'm too lazy to install Gentoo on it right now. The only thing I miss in OpenRC on my other computers (all running Gentoo) is the fact that service $service status doesn't show the service's stdout log. Anyone know how to replicate this?

NASA BSD engineer explains why systemd is problematic

>My problem with this is that the order in which services are started should, in my opinion, be exactly the same each time and predictable to the sysadmin. With systemd, the order is not deterministic, so you don’t know what’s going to happen next time you boot. I work with servers and embedded devices; I don’t care much about boot time. A server spends several minutes in the BIOS during POST anyway, before the bootloader is even run; making the OS boot faster doesn’t change very much. Embedded devices already start quickly because you trim them down to the bare minimum. What I care about is that every time I boot, the same exact things happen in the same exact order — the order that I want.

>It seems no one can agree on whether systemd is modular or not. I think the problem is with different definitions of ‘modularity’. Systemd doesn’t put everything in PID 1 like some people suggest; it uses modules that communicate with each other. So it is modular in that sense. But these modules are very tightly integrated. You can’t easy remove some of them, or replace them with other things. So in that sense it is very monolithic. This is not at all like having a simple interface and passing data via stdin and stdout, which is the modularity that makes UNIX pipes possible. This is the sense that matters to me.

>[...]I dislike the way systemd is absorbing everything. It’s not just an init system, it’s become an everything-under-the-hood includes-the-kitchen-sink management system. That doesn’t feel modular to me. Why should systemd implement NTP when ntpd already exists? I think systemd-timesyncd and all the others like it are just reinventing the wheel.

Full article: https://bsdmag.org/randy_w_3/

>>61539939
>it's insanely expensive to implement,
It isn't, retard.

>>61539968
So what if he is receiving payment? Half the kernel regulars do that.

>>61540126
>the resolver isn't used unless you enable it

>>61539968
back to 8gag, retard

>>61540458
>Half

Several systemd-free Distros
Alpine Linux
antiX (based on Debian)
Calculate Linux
Crux
Devuan
Entropy GNU/Linux (formerly Less Systemd GNU/Linux)
Funtoo
Gentoo (ready options exist)
Manjaro (see OpenRC options)
Porteus
Puppy Linux
Slackware
Void Linux

File: 1480459554559.jpg (48KB, 253x229px) Image search: [Google]

48KB, 253x229px

I like systemd and never had a problem with it so kindly take your shit to some conspiracy board like >>>/x/

>>61540599
Are Parabola and Trisquel system D free?

>>61540821
I'm pretty sure people like you are just lazy enough to stick to what you know and uncomfortable knowing you don't know enough to make a change and consider that you have been compromised.

>>61540825
no

www.  parabola .nu/news/systemd-is-now-the-default-on-new-installations/
https://trisquel.info/en/forum/how-much-systemd-trisquel-7

>Trisquel 8 uses systemd as an init service (like Ubuntu 16.04 upstream and like Debian jessie even more upstream). That is why "systemd-shim" is useless. Previous versions of Trisquel use Upstart.
>>61540850
>answering to low quality bait

>>61540599
*Temple OS

>>61540197
If not using systemd was so superior, why don't you just write your own versions of XYZ or ABC that don't depend on systemd.

>lusers bitching about systemd
>lusers bitching about people using systemd
>lusers can't actually write code
>if they were developers, they would realize how much easier systemd makes everything.

File: probably not the best idea ever.jpg (80KB, 640x480px) Image search: [Google]

80KB, 640x480px

It's not like I hate it. I don't even have any issues with it where I'm forced to work with it, at least currently.

But it will fail in a bumblebee rm /usr manner one day, and I will laugh at everyone who was trying to whitewash it. Because if my previous job in HA systems taught me anything, this whole mess of a software along with its smug developer is a recipe for a disaster waiting to happen. I don't know if there's fire yet but there's plenty of smoke already. Who in their sane mind would call giving an invalid user root rights "not a bug"?

>>61541103
>If not using systemd was so superior
reddit was a mistake

File: 1412709597135.jpg (289KB, 1024x678px) Image search: [Google]

289KB, 1024x678px

>>61541132
>Who in their sane mind would call giving an invalid user root rights "not a bug"?
Avahi creator thinks this is not an issue.
Reminder that PulseAudio is more complex than writing a compiler

>>61541499
Grade A faggot. Look at his little scarf:

https://www.youtube.com/watch?v=ZTdUmlGxVo0&t=53m55s

>>61541533
Germany died in 1517

How does systemd compare to launchd? I like the idea of launchd a lot but I know very little about systemd.

>>61541603
>macos fag pretending to be intelligent

File: Untitled.png (77KB, 1488x551px) Image search: [Google]

77KB, 1488x551px

>>61541636
I'm a lifelong Windows user, at work we used to use SunOS but have since moved to FreeBSD. I consider moving to MacOS personally but my sound hardware doesn't seem to be supported and I don't exactly have the funds to buy Apple hardware each generation jump. launchd has been open sourced for a long time now and could probably work on any *nix system, much like other Apple open source projects (cups, clang, et al.). I know about launchd mostly from reading the documentation and seeing people talk about it at conferences, way before systemd was a thing. People complain about XML but you could probably just fork and swap that aspect out to create something preferable.

Not sure why you'd assume I was a mac user or how that's relevant to the question anyway, I'm guessing you know nothing about either init system.

>>61541719
Step 1: Download Salix or Devuan iso and dd to usb
Step 2: read 10 min of Debian/Ubuntu documentation
Step 3: install Firefox and browse /g/
Step 4: don't add strange repositories
Step 5: be happy forever.

>>61541755
I try to avoid using GNU if I can, not a fan of their vendor specific extensions/lock ins. I much prefer something closer to the POSIX standard and something with a more portable implementation.

>>61541778
>with a more portable implementation
why?

>>61541872
For personal hobby and for professional work I tend to deal with exotic hardware. It's really nice to learn 1 operating system that works on everything the same exact way and you can build it with whatever tools you need with minimal changes, I much prefer this than having to use a whole different and specifically scoped project and potentially having to port an entire toolchain because the system relies on it just to build.

NetBSD has a massive appeal to me for this reason, you can build it with damn near anything, setting up a package repository and cross compiler is simple, and with pkg-src you can build binaries nativley on it the same way you would on your workstation if you wanted to or needed to. You learn 1 thing and it works everywhere, instead of learning something that's almost the same thing but also has all these weird quirks or restrictions that are specific to the platform.

Some might call this lazy, but I much prefer a general and portable solution to a domain specific one, it makes things so much simpler overall for everyone involved.

>>61541971
you're a nice guy i'd be friends with
(no gay here I'm married)

>>61539850
>systemd is complex
For you. Only udev is shit, but recently haven't seen any bugs that triggered me. Also i don't maintain any distro so meh.
Nobody cares.

File: 1410816300293.png (26KB, 229x330px) Image search: [Google]

26KB, 229x330px

>>61543606

>>61544354
No homo.

>>61544161
> your arguments are invalid because I can't be bothered reading then
Mmmkay