There is nothing wrong with systemD

There is nothing wrong with systemD

Other urls found in this thread:

utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight
utcc.utoronto.ca/~cks/space/blog/linux/SystemdWhyItWon
forums.debian.net/viewtopic.php?f=20&t=120652&p=570371
riaschissl.bestsolution.at/2015/07/systemd-the-linux-dilemma-and-why-we-will-migrate-away-from-debian/
github.com/systemd/systemd/issues/2402
steven-mcdonald.id.au/articles/systemd.shtml
ewontfix.com/14/
twitter.com/NSFWRedditGif

Agreed

>Gpl licensed, free and open source
>"Just werks"
>Faster boot process
>Eliminates bloat/meme packages

There is NO reason why one should delete systemd from his system. There is nothing systemd can't do what other init systems can.

>Botnet
Source is open, show where

>Not Unix
Neither is linux

>pottering
So what packages did YOU make yesterday?

Is this a fucking real stock photo, who the fuck needs this?

>what not to wear to work

who is this system deamon

>he can't spell systemd
I agree with you though, it's a far better init system than anything else, even though the number of other subsystems it's consuming somewhat concerns me.

>pottering
So what packages did YOU make yesterday?


When will this shit stop? This has NEVER been a valid argument.
>You have to be X and do Y in order to criticise X or Y

>Hating on someone, not someone's package
Seems like a legit response to me

I think the intention is "talk doesn't talk, code talks". Shut up and show us something better, or in other ways contribute.

The reason why UNIX and its descendant operating systems have had such longevity is because they're modular so you can change out the old parts for newer, better ones. Systemd completely shits all over that, so now all distros that adopt it can only live as long as systemd is a viable piece of software. They've taken our glorious POSIX modular lego set and turned it into a putrid Windows-tier layered onion.

>can't replace modules of systemd
you actually can though, just because no one has so far chosen to do so doesn't mean that it can't be done.

Additionally, systemd as a whole can be removed from the Linux world in exactly the same way it was added, in reverse.

Adding systemd isn't some one way ratchet in which we're now tied to it forever.

here's some sysadmin with a blog explaining it better than I can
utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight
utcc.utoronto.ca/~cks/space/blog/linux/SystemdWhyItWon

highlights:
>you can override a system-supplied unit with a sysadmin-supplied one without changing or removing the system-supplied one.
>systemd handles a lot of annoying infrastructure for you; for example, you do not have to arrange to daemonize programs you run.
>systemd keeps track of what processes belong to a particular service, so it can both list all the processes that are part of a service and tell you what service a particular process is part of. This is a boon to manageability.

>Speaking as a system administrator, systemd solves my problems better. The authors of systemd have looked at problems that are not solved by SysV init and come up with real solutions to them. Many of these problems are not solved by any of the alternatives that Felker [The guy who wrote "Broken By Design: systemd" -ed] put forward. In specific, often the alternatives assume (or require) cooperative daemon processes in order to fully realize their benefits; systemd is deliberately designed so that it does not and can fully manage even existing obstreperous Unix daemons with their willful backgrounding and other inconvenient behaviors.

lennart, will you please stop shitposting on Sup Forums and fuck off back to breddit.

>There is NO reason why one should delete systemd from his system
Yea. They shouldn't have installed in the first place.

>Because I said so
Oh look at this entitled faggot

(4) HOT NERD GIRLS ARE WAITING
TO TALK TO YOU !!!

>They've taken our glorious POSIX modular lego set and turned it into a putrid Windows-tier layered onion.

Apparently that was the plan all along.

It's about time for traditional (i.e. non-systemd) Linux distributions to draw a line, go their own way and stop trying to be compatible with the systemd-ones because it's a dead end, following that route will at some point force the distro to either itself adopt systemd due to no longer dodgeable dependencies, or be discontinued. That's surely precisely what Lennart is counting on, that over the course of the next decade all distros either adopt systemd or perish, and this must not be allowed to happen.

rekt

>There is nothing systemd can't do what other init systems can.
One of the main issues is it does way beyond an init system has business doing.

Yea that shit is intrusive and tries to monopolize the basic tasks of your system.

>how to impress your boss

Fixed That For You.

Although it's not an argument: I agree. Can't find the picture, but I remember a computer not being able to reboot because systemd decided to crash in the process..

>They've taken our glorious POSIX modular lego set and turned it into a putrid Windows-tier layered onion.

I agree with this, Maybe if no one could examine the source code then we should be leary of it but since it's open source there really is no argument for "muh botnet".

Unix autists don't like it because it does more than one thing so it must be evil in some way.

Tldr: systemd is creating a more cohesive environment.

That sure is a bad thing, rather than relying on a bunch of parts made by different people who also don't talk to cobble together a Frankenstein monster.

Why don't they assimilate bsd or Hurd instead?

The BSD systemd is luanchd

launchd is great, tho

Didn't know redhat had an internet shilling department too

They're tasks of your SYSTEM, NOT YOU. What the fuck do you care which part of your operating system takes care of it? God, you faggots really just complain about the new thing because it's popular and you want to be special snowflakes. If SystemV had taken over systemd you'd be shitposting all over the place about how it void of modern functionalities

the sysadmin with a blog can fuck off to his redhat™ approved® distro of choice, and stop trying to reach other distros. If their product is so superior, why going the long way, imposing that shit to other distros (especially debian)?
Only the weak fear competition. Red Hat will never be microsoft.

How are they imposing their shit on other distributions? Debian chose to adopt systemd on their own accord.

If that's what you think about your """"""system"""""", then fuck off to windows.
God, why are you redhat loving faggots won't stop pretending that you care about GNU/linux and fuck off to the putrid half-windows-like OS you're trying to make?
I love you, historical revisionists. People like you still believe that the holocaust didn't happen forums.debian.net/viewtopic.php?f=20&t=120652&p=570371

It did not. And I smell your jewish undies!

Why are you smelling my undies?
Not jewish though.

There's two arguments against systemd that are logical, the rest is hipster bullshit.

1. It is completely against the Unix philosophy of making small, single use applications and piping them together for a lean, logical workflow.

2. If it fails, pretty much everything fails. It controls so much and has it's fingers in so many pieces of the system that it becomes a pretty large attack surface or axis of failure to your system.

That said, systemd is fucking awesome and lets you control a lot of shit in a much easier, more convenient way than with other init systems.

>completely against the Unix philosophy
user, the Linux kernel, udev, polkit, dconf, gcc, glibc - none of them honours the Unix philosophy. It's sadly a deprecated idea

>If it fails, pretty much everything fails.
Systemd is aware of such failure and starts itself back up upon crash - saving you from kernel panic. Also, the monolithic kernel itself is a bigger attack surface

It's not hipster bullshit. The point is not the Unix philosophy (which would be a seriously valid point anyways, since a lot of it coincides with the biggest principles followed by the modern science, such as the Occam's Razor).
The real issue consists in the unification of what once was modular, which in turn introduces a lot of smaller issues - for rather unimportant features.

And, in business, switching to something which is yet to prove WORKING, let alone working BETTER - is expensive. Seriously expensive. There's a reason there are people still using XP nowadays. Change costs.

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. [cit.]

read the link in

that feel when you're not smart enough to even utilize arch to an extent that makes systemD intrusive, yet you still want to defend the notion of having full access to your system so you can study it.

mint user here
whats systemd

It's the main reason you should move away from Mint.

riaschissl.bestsolution.at/2015/07/systemd-the-linux-dilemma-and-why-we-will-migrate-away-from-debian/

No, user, it's because Unix is easy to reimplement.
You have to sacrifice scalability for that.

As a non-autistic, I can firmly say I couldn't give less of a shit and neither should anyone else

Something that never even matters in your GUI experience

If you use it mainly on desktop - stop giving a fuck and move on, because this thread does not concern you that much.
However, if you manage at least one server - stay and read carefully, because systemd is the cancer that plagues almost any GNU/linux OS nowadays, and is the putrid horror that made GNU/linux what it was created to escape from.

>unix philosophy
That's an argument as technical as saying that houses built with Art Decó principles are better suited for southern climate instead of the Modernist or Gozerian ones.
Unix philosophy is not a technical argument in that sense. Those are design guidelines created in the 70's by a bunch of programmers with only one objetive: create a OS completely opposed to Multics in design, and also created for a machine with static hardware configuration.
>single point of failure
That doesn't account the fact that systemd has separate processes, only three are critical, and ANY FUCKING INIT PROGRAM IS A FUCKING SINGLE POINT OF FAILURE. That's a defect of Unix. Systemd at least it's aware of that and can avoid the kernel panic restarting itself gracefully.

what's the correlation of your link to linux mint?

>comparing the limitations of 70's CS with the occam razor
Let me guess: Are you a New Atheist too?

...

Except when it fails and most everything else with it.

Name one (ONE) init that is fail safe

Other inits are just that, systemd want's to be everything including the kitchen's sink.

It's time to turn off your computer. OK buddy?

>because systemd is a giant binary runing at pid 1

...

systemd isn't an init system - init's system function is to start up the userland. Systemd IS the userland now, - it fagocitated almost everything. And, guess what now became the largest attack surface (apart from the kernel), the largest point of failure and impossible to restart correctly because of its being monolithic?
This opposed to SysVinit that's failsafe in the sense that it does what it does without touching other system components.
no idea of who the "New Atheists" are, but I'm not seeing the connection between systemd and my religious beliefs
why?
I probably should, since I just finished compiling linux v4.7.1; However, I won't, since I'm enjoying the chance of debating with a redhat marketer without valid arguments here.

What meaningful discussion is this?
> the cancer that plagues almost any GNU/linux OS nowadays, and is the putrid horror that made GNU/linux what it was created to escape from.
Take your lullaby skills to /lit/

>Second paragraph
>He's OK with it because he's not a huge sperg
Well done retard

You sysvinit shills/apologists NEVER even attempt to engage in any meaningful discussion, never address any of the valid and relevant issues raised, but only use pseudoarguments like “it does one thing and does it well” or “Erick S. Raymond is OK with sysvinit", and otherwise just ridiculing, belittling or insulting (“red hat drone”, “win baby”, "irrelevant fringe hipster/sjw/whatever", etc.).

>Shut up and show us something better
openRC
runit
SysVinit

i do work on redhat/centos servers but i dont manage them really. if i do anything to them its just restarting services and moving shit around. basic scripts etc
im guessing systemd is the process that handles the gui?

What systemd is doing to the community as a whole is to deploy the "divide and conquer" and "embrace, extend, extinguish" tactics, among other things. On whose exact behalf and to what end, it yet remains to be seen.

>im guessing systemd is the process that handles the gui?

Hey, user.

If you don't like systemd go use some hippie distro and shut up. Let people use *buntu

Sup Forums memes are the worst

>systemd having swallowed countless other daemons is a meme :^)

ok, ok, maybe I'm exaggerating with metaphors; but that's not the point here. MAYBE if you presented any valid argument to support your point I'd refrain from using colorite language.
that's the exact thing you systemd apologists are doing while I'm here, presenting valid points to my favor. Also, you're falling to a false dichotomy "systemd vs sysvinit". It's not about that, it's about systemd vs several dozen of instruments that are part of a sane linux userland and that actually DO work.
weak bait though.
I'd recommend to you to let someone other handle your servers - or to hire someone to call when the shit hits the fan. Managing servers is not just restarting services...
Usually, in these cases you go search the entity who benefits the most from it. And I'm not seeing no one other than the RedHat. Who other would like to see debian becoming Yet Another GNU/Linux/Systemd distro?
Again, read this fucking link

>countless other daemons
Good riddance

And a init system should care of the orphaned processes and reap them. Init is also the ancestor or all processes directly or indirectly. And systemd-init does it very well, better that any of his predecesors.
Yes, systemd suite is also a basic userland, composed of well differentiated processes who are written to interact and comunicate between them in forms that in early UNIX days where unthinkable. They aren't a single mass of code running at same privilegie, like a giant amoeba. They are like our organs, distinctly, but well integrated between them. They are failure points as their code permits that. NetworkManager, for example, shouldn't bring down systemd-init or journald. And doesn't.
It isn't a single point of failure or a large attack surface like you're implying.
It isn't a giant blob.

All of your points you raise where contested in a way or another in lots of places. You simply keep ignoring them.

Ya

Dozen of instruments that, in a way or another depend of sysvinit and also they can't replicate the functionality of systemd completely?
Instruments abandoned and stagnant like ConsoleKit and the proper sysvinit?
Instrument who do process tracking in obsolete manners, like pid files, lose the processes who double fork, start the processes in linear ways and follow a linear design more suitable for a 80's or 90's machine?

>hire someone
we do have people that manage the servers. im the network guy. but sometimes we have to go in and make minor changes and setup scripts

>systemctl restart dbus

Systemd-init doesn't do that well for one simple reason - it cannot function alone. Try to isolate any systemd component and run it without the others - you'll see that it's not possible unless "the other components use the systemd API" - in other words unless you rewrite systemd. And that's why systemd is a giant blob.
If a systemd component fails others do, and viceversa. People find themselves restarting more often than necessary. And there's been evidence for this:
github.com/systemd/systemd/issues/2402
steven-mcdonald.id.au/articles/systemd.shtml
ewontfix.com/14/
the funny thing is that consolekit is authored by microsoft and redhat... Anyways, why do you retards always adress ONLY sysVinit as if it was your personal enemy? There are other init systems - OpenRC, to name one. It does its job egregiously too. Also, name me an instrument that tracks processes and DEPENDS on sysVinit. What the hell do you mean by stagnant, btw? What's the functionality you're missing right now that any of the existing tools you mentioned doesn't have while systemd does? Name at least one.
/thread

>What's the functionality you're missing right now that any of the existing tools you mentioned doesn't have while systemd does? Name at least one.
Not him but:

User services, timers, good command line usability, automatic daemon restarting, socket activation, login session tracking (via cgroups), journald, coredumpctl, service file overrides, probably more

Those are the features that drew me to systemd personally, which I found myself lacking while using Gentoo+OpenRC. (I now use Gentoo+systemd)

My biggest complaint with systemd so far is the forced dbus dependency, and the fact that some failure modes are rather quiet (for example if you nuke /run which I have accidentally done, systemd thinks all of its critical daemons are no longer answering and force-restarts them after a timeout, which kills your active user session - I sort of wish it would have tried to notify me in some way (wall, email, whatever) about the problem first)

Oh right, another complaint I have with systemd: If you manage to nuke /run (which, again, I have accidentally done), the tools like “reboot” become unresponsive because they communicate with systemd via sockets

The work-around is not difficult because ‘init’ listens to signals (SIGRTMIN+5 = reboot, SIGRTMIN+4 = poweroff, etc.), but I find it weird that the “reboot” wrapper controls don't use this upon failure to contact init

If "well integrated" for you means it's a giant blob, then is a giant blob. Like a human body.
Oh, You're ignoring a thing from systemd: You can compile it for the bare minimum, only getting systemd-init, journald and udev. You add the rest.
Yep, once compiled you can't mix and match. But if you want, you can do it.

>mount efivars breaking motherboards
I know that systemd is your personal enemy, but that problem in particular isn't fault of systemd. It was because MSI did a unproper implementation of EFI in the motherboards. That problem could be exposed in any distro who mounts EFI variabless as files. Almost all distros are EFI aware these days, so, strictly speaking, isn't fault of systemd.

Do you know that EFI tools of systemd can also brick Apple Computers? You know why? Because the same. Unproper/odd implementation of EFI. I bet you hate both systemd and Apple, but you now not know who is worse.
:^)

>a giant page of yellow text over black background
Apart that the author insist on the myth that "Multics failed' I have problems with these points:
>It shuffles complexity around
Yeah, it's true. The daemonization code was changed into language. You don't have to worry to build a script for Debian, other for Fedora, etc.
But saying "because systemd units aren't real programs, there's no way to escape to more basic primitives as required." isn't completely true. You CAN daemonize a script if you need shell logic.
>It's unpredictable
Yes, because systemd assumes, more or less correctly, that resources can change at any time. The author more or less believes that his system is completely monolithic. Perhaps is not. Perhaps it is. I don't know his case.

The rest is read more or less as the typical greybeard rant who expects systemd to behave like a sysvinit.

Ewontfix insist in the same:
>muh pid 1 should be a program following muh 70's design guidelines
I explained why systemd doesn't do that: We expect more than we expect from 70's computers.

Adequate process tracking via cgroups
Adequate process killing at shutdown (no, Unix didn't do that correctly)
Awareness of appearing and dissapearing resources.
A common way to daemonize things.
Etc.

lol please delete this, can't deal with another *nix copy pasta

>They aren't a single mass of code running at same privilegie, like a giant amoeba. They are like our organs
> the cancer that plagues almost any GNU/linux

you guys are mede for each other

Yeah, I'm not exactly a great fan of apple or msi. But, if you write an userland you should stay careful about mounting shit in rw that you shouldn't.
>systemd-init, journald and udev
Why am I getting 3 different programmes in one package? does your car manufacturer weld the steering wheel to the brakes and to the transmission box? Because that's what systemd is trying to do - tightly couple different binaries in order to create a monolithical userland that may or may not work marginally better (only because the development started with different assumptions from, say, sysVinit).
There are some issues addressed by systemd that solve problems that arose more recently - and it succeeds in making a point. But the point is that systemd is bad not because it solves some issues, but because it does more harm than good. There never was a need to cram everything into a giant blob of code - and before you try to say that it's not - the fact that you mentioned recompilation states by itself that it is. You don't need to recompile OpenRC to update udev in, say, gentoo - you recompile udev, restart it - and voila' - no need in even rebooting. What before was a bunch of blocks that you could change at runtime now is a layer that cripples that possibility. And the servers are those who suffer the most of this choice.
The other reason because it's bad is in the fact that it was forced onto distros outside RedHat. It's undeniable that there was a strong push for systemd adoption - even for the distros who did not care that much. If systemd is so good - why not wait and see how the other distros decide to adopt it by themselves? Programmers tend to accept better solutions by themselves, without being forced.
> muh pid 1 should be a program following muh 70's design guidelines
why fix what ain't broken? How often have you seen sysVinit/OpenRC failing recently?
next you will say that it's not clear what su does.
You're becoming predictable, mr. Poettering

>mount shit in rw that you should not
But thats the point of EFI. The OS should be able to write variables to NVRAM. Without that, we lose the benefits of EFI, like EFI bootloader config. EFI was created to play nice with the Operating System in levels that BIOS couldn't

>Why am I getting 3 different programmes in one package?

Because systemd is designed in that way?

>does your car manufacturer weld the steering wheel to the brakes and to the transmission box?

No, but I can't change that. They're tied to the design of my car. I lose personalitation, but I gain better security, less headaches, and big etc. Isn't a hot rod after all.

>Because that's what systemd is trying to do - tightly couple different binaries in order to create a monolithical userland that may or may not work marginally better (only because the development started with different assumptions from, say, sysVinit).
Yeah, is that what systemd does, intents to do and it does. And doesn't work marginally better. In fact, works much nicer that the fragile crap we had years ago who depended of hacked scripts. Isn't a blob running in PID 1 but isn't too modular like some Unix autists like.

>There never was a need to cram everything into a giant blob of code - and before you try to say that it's not - the fact that you mentioned recompilation states by itself that it is. You don't need to recompile OpenRC to update udev in, say, gentoo - you recompile udev, restart it - and voila' - no need in even rebooting. What before was a bunch of blocks that you could change at runtime now is a layer that cripples that possibility. And the servers are those who suffer the most of this choice.
Servers doesn't need systems who can change pieces like lego blocks. Servers need to have replicable systems manageable, having process track, having anti tamper measures, etc. Rebooting one time at month isn't a issue if you can secure the other things.

Actually, systemd was developed with servers in mind. Most vitriol comes from thinkerers, like Gentoo or UNIX die hard fans, like Suckless or CRUX. Systemd is developed with the needs of actual servers in mind, who are very distinct to the mainframes of 80's.
>The other reason because it's bad is in the fact that it was forced onto distros outside RedHat. It's undeniable that there was a strong push for systemd adoption - even for the distros who did not care that much. If systemd is so good - why not wait and see how the other distros decide to adopt it by themselves? Programmers tend to accept better solutions by themselves, without being forced.
Because that happened, you like or not.
Distro maintainers compared the solutions, and systemd was better in the long run. Upstart wasn't sufficient for Ubuntu or Fedora. OpenRC is the pet project of a thinkerer distro, who doesn't solve the problem of being depended of Sysvinit and being broken.
Big distros need to be easily deployable, easily interoperable, predictable in the functionality to some extend. Systemd makes that possible. Before that, god help us! Balkanization didn't help us.
I don't know how Red Hat forced the adoption of systemd anyways. The only argument they have for that is "Oh, some distro mantainer works for Red Hat" Sorry, but that isn't sufficient. Big distros aren't one man effort.
>why fix what ain't broken?
Because Unix Philosophy IS broken. Sorry.
"Do one thing and do it well" as it dictates doesn't scale like we want. Joining little programs with pipes only did the 80% of the work. Piping isn't sufficient as a way to have IPC. Computers aren't monolithic beasts who are held in universities: They resources appear and dissapear any time now. We had to suffer readdir () because the belief that "Everything is a file" was perfect. And big bunch of etc.
The only advantage of Unix Way is that makes it easy to reimplement.

>How often have you seen sysVinit/OpenRC failing recently?
Lot of times: Rogue processes who double forked because a badly written bash script gave me nightmares. Fixing it means I could not distribute anymore until I wrote a variant for every operating system. Sometimes, Init segfault and bring my whole system down, of nothing. And shutdowns were clean like systemd does it.
>next you will say that it's not clear what su does.
You know that does su in the context of containers in systemd?
That's was the most recently shitfest we had.

If I wanted an obfuscated monolithic POS OS I could just install windows.

Should I make the effort and switch to OpenRC?

Don't bother, OpenRC is a piece of shit in comparison