is it really as bad as /g/ says it to be?

>>62169281
No. It's the future.

no it's good

Yes. And it's the future

>>62169295
>>62169304
interresting

>>62169281
It might be, but that's the problem, isn't it?

>>62169281
After moving to void linux I've noticed the difference in speed.
My computer used to take 1.54 mins to fully boot with Ubuntu, 1.04 mins for Arch and only 21 (sometimes less) seconds for Void Linux.
SystemD is cancer, remove NOW

Depends. Could be the future.

> Poettering

If you want to buy into this meme.

>>62169281
It's even worse. it's a distro running at PID 0.

>>62169281
It's actually worse, but /g/ wouldn't know since it's full of retards and vedditors.

>>62169376
Then you're doing something very wrong. I got Arch with systemd down to 1 second when booting from an NVMe SSD.

>>62169484
>NVMe SSD.
not anon, but with one of those, even wangbloat will boot fast.

>>62169484
How often do you plan boot your *NIX box?

>>62169484
removing all packages dosn't count

File: kqgtemhi43hz.png (654KB, 750x850px)

654KB, 750x850px

For an average user, there's no need to worry with it, however, it is kinda annoying that when it crashes it takes the system down with it. I think a lot of people have a problem with redhat interfering with their distro

>>62169523
>>62169526
That's not the point. (And an extreme case, I know.)
The point is you really fucked up if your Arch boots an entire minute.

>>62169527
>the state of /g/ in `date +%Y`

BTW it was a somewhat standard desktop system with Xfce. Nothing extravagantly bloated or minimalist.

>>62169281
Systemd is honestly fine for managing services and daemons
The only problem I have with it is when it WAITS FOR FUCKING EVER FOR THE START AND STOP JOBS

>>62169281
Yeah it's fucking awful, and it won't stop until it's taken over every daemon on the system

>systemd
>askimg if it's good
clearly a noob at unix

>>62169281

No.

You only care about it if

- you're a dev who's been in the Linux game a long time

- you really really care about "Unix philosophy"

- you think there's a Red Hat conspiracy to take over Linux [which there may or may not be].

If you're a desktop user it really doesn't matter.

>>62169315
Really makes you think.

>>62169281
Just a bunch of autist afraid of change.

>>62169281
It will soon come with a Twitter client and Microsoft Office.

>>62169281
It's horrific. This page has a good collection of links explaining/demonstrating the problems with systemd: http://without-systemd.org/wiki/index.php/Arguments_against_systemd
>>62169376
Void is great.
>>62169484
The difference for me between systemd and runit speed wise is marginal, runit was only around 2 seconds faster than systemd in my tests but it's also better in other ways.

>>62169281
No. The autists are raging about muh unix philosophy.

No, it's far worse

>>62173231
This is my primary argument against it. I don't care about "muh fast boot", or other bullshit. I care about it being stable, secured, bug-free. This is systems software, the margin for error is incredibly small, and having a critical system element that has a bad track record for security (already!) isn't encouraging.

When systemd finally "grows up" and stops being driven by autistic shitlord "but it sucks my cock while it boots" goals, and starts focusing on what matters, then I'll be happy to use it.

File: Kill it with Fire.jpg (68KB, 450x600px)

68KB, 450x600px

>>62173479
First, we're not autists.

Second, I actually give a shit about the software I use. I have specific reasons for using it. If I wanted to live in a world where ignorance is bliss, I would use Windows, or better yet, OS X.

Third, "muh unix philosophy" doesn't enter into the argument. This is about as much a strawman as the "but it's better than SysV" one that keeps showing up. Better yet, SysV isn't even full fucking SysV, it's van Smoorenburg rc scripts plus SysV, but the systemd folks can't even get their arguments correct.

Fourth, it's fucking bloated. I don't mean in a "gee she is a little chunky but cute" way, I mean in a "HOLY FUCK LAND WHALE AHOY" way.

Fifth, can anyone - ANYONE - explain to me why we need to have a fucking kitchen sink installed with our boot process? Process management, ok I'll give you that. Logging, sure, we need something to diagnose boot issues. But DHCP? Networking stack? Fucking QR codes? A fucking web server? (Windows tried that with Kernel-level IIS and look at the shitstorm they had securing it for several years) What comes next, a Briggs & Stratton 5hp vibrating dildo?

File: I'm deploying an app in the cloud.jpg (51KB, 732x501px)

51KB, 732x501px

>>62171199
I find it interesting that you completely missed the mark on server deployments.

Notice I didn't say fart deployments. I don't deploy my software in "the fart". You can keep your fart-based services, I'd rather have actual hardware.

>>62172457
Sure, why not? A full build and installation already has:

Boot Time Graphing
Networking Support
A DHCP server
Inetd/xinetd/UCSPI replacement
QR Codes
A Web service
JSON encoding
Device management
A user-space message bus
Temp file management
Session/seat management
Binary logging
Container integration (ala cgroups)

So why not just throw everything else in there? What could possibly go wrong?

>>62169546
Steaming urinal puck, yum

>>62169281
Single point of failure.