What's so bad about systemd?

What's so bad about systemd?

Other urls found in this thread:

without-systemd.org/wiki/index.php/Main_Page
fibrevillage.com/sysadmin/516-why-systemd
debian.org/doc/manuals/debian-reference/ch03.en.html#_stage_3_the_mini_debian_system
support.ntp.org/bin/view/Support/ConfiguringAutokey
freedesktop.org/wiki/Software/systemd/InitrdInterface/
twitter.com/SFWRedditVideos

Autists like to scream about it because they hate change and convenience.

nothing

Systemd violates
>muh unix design philosophy
but other than that is perfectly fine.

Rolling

Don't waste your time here - READ THIS INSTEAD
without-systemd.org/wiki/index.php/Main_Page

Don't waste your time here - READ THIS INSTEAD
without-systemd.org/wiki/index.php/Main_Page

Don't waste your time here - READ THIS INSTEAD
without-systemd.org/wiki/index.php/Main_Page


Don't waste your time here - READ THIS INSTEAD
without-systemd.org/wiki/index.php/Main_Page


Don't waste your time here - READ THIS INSTEAD
without-systemd.org/wiki/index.php/Main_Page

Don't waste your time here - READ THIS INSTEAD
without-systemd.org/wiki/index.php/Main_Page

roll

Poettering is a faggot.
Other than that just use Void linux if you're autistic

maki maki gimme dat ficki

it does moire than 1 thing well

been running linux for a year... still have no idea what systemd is, though it's always near the top of top

The autism of people that imagine better designs, but never bring them to the table as something (more) workable like systemd.

It's quite awesome actually.

...

Systemd needs to
- Start enabled services on boot
- Stop them when I stop them
- Restart them based on the helpful Restart= line in the service ini file
- Let me enable, disable, start, stop and restart services with an easy-to-use command line interface

In that sense, systemd is literally the best init system I've ever used

Unfortunately that's less than 2% of what it does because pottering is fucked

rolly polly no fatties big money

sorry user

- Binary logs
- NSA involvement in its development
- Does too many things
- Binary logs
- Has too many features

>is literally the worst init system I've ever used
FTFY
Unless you've literally never used another init system before.

Don't waste you're time there. Read this instead.
fibrevillage.com/sysadmin/516-why-systemd

> Unfortunately that's less than 2% of what it does because pottering is fucked
No, because people start their computers in that many ways, and some of them for instance depend on dhcp and ntp or such.

please don't post any more, your stupidity is bringing this whole board down

Systemd is the best Linux distro ever made.

t. paid NSA employee.

Ok, but dhcpcd doesn't need to be built in to PID 1, ntpd doesn't need to be built into PID 1, literally just a service with RemainAfterExit=true or Type=oneshot and an ExecStart=/usr/bin/ntpdate -d pool.ntp.org would work. No reason to build it into the init system.

Hell you could even have a service with Type=forking and ExecStart=/usr/bin/ntpd -g

No reason to do what systemd is trying to do to ntp, pam, cron, getty, syslog, udev, mount, cryptsetup, at, dbus, acpi, cgroups gnome-sesion, autofs, audit, cryptsetup, etc....

tongue my anus

NSA/Red Hat's way to control the Linux ecosystem

Nothing. I use it, and love it. I even used it back when it wasn't cool. Back when it was called scvhost.exe.

>Interfacing via dbus
systemd should not require dbus. It should use it if it's installed, but not require it. This is a downside, not an upside
>read-ahead
was removed from systemd because it's performance features were "unproven" and "none of the [systemd developers] had rotational media"
>Timer-based Activation
bloat
>Path-based Activation (inotify)
upstart has this too but they wrote no for some reason
>Swap handling
bloat
>Snapshotting of system state
bloat
>XDG_RUNTIME_DIR Support
bloat
>Encrypted hard disk handling (LUKS)
no reason for this to be in PID 1, at all, ever, under any circumstances.
>Network Loopback device handling
/etc/network/interfaces may be deprecated for actual network interfaces, but it wasn't broken for lo so don't fix it.
>binfmt_misc handling
bloat
>Graphical UI
Fucking what?
>Container support (as advanced chroot() replacement)
Useful for some but should come disabled by default

Though you're right, 80% of the things on that list are good reasons to use systemd. I do like systemd a lot, but that list is not infallable

>sudo systemctl enable name.service
>sudo systemctl disable name.service
Real complicated man.

that's exactly what he said, work on your reading comprehension

Did you even read my post? I said that those two commands were one of the things I love the most about systemd

I heard only the init and udev were PID 1.

Much of it isn't built into PID 1, but just a binary in the systemd suite.

And precisely ntpdate and all these tools we don't want.

Shit will again end up in never-containing-everything-but-bloated-anyhow initrd, followed by some statically linked busybox+suite of programs in stage 1 of the boot or programs compiled against dietlibc or whatever.

The assertions involved in every distros boot were a pain in the arse, and so was the tooling to create and modify what many of they actually expected.

roll

Why do you want to replace ntpdate? It isn't broken. And it isn't in the initrd either.

Unrelated note, fuck dietlibc it's slow as heck. uclibc or musl are so much better.

SystemD isn't bad for me, never had a problem.
OpenRC isn't 100% pure of bash script.
SysVinit is what I want, its service file is pure of bash script and I love it.

This.
I think everyone mistooking systemd as an init system but rather it's a Linux distro.

too much system
not enough daemon

ntpd and crony are bloated overkill for generic servers and only really needed for time autists, systemd-timesyncd is a bretty good lightweight SNTP client

*chrony

>cron is bloated overkill, systemd timers are all that's needed for a simple server

k

rollin

pls

Is stage 1 the shell script /sbin/init in the initrd or the /sbin/init that's symlinked to /lib/systemd/systemd that gets exec()'d by switch_root?

more interesting post than the bait op

> And it isn't in the initrd either.
Yea, there you probably have busybox ntp or something? Or they didn't need it so you can add it yourself tediously on every update if you need it for network boot or whatever.

Now you'd think, ah well, use some prepared initrd that has it. But you can't use SOME initrd, because you need to mind the specific hand-off the distribution wants to do between the initrd and stage 1.

By the way, this also means if you alter the initrd you might as well have to alte the subsequent stage 1. Which probably again was built in a very special fashion.

> Unrelated note, fuck dietlibc it's slow as heck. uclibc or musl are so much better.
Sure. But that's what your distro might have used for either initrd or stage 1.

Maybe they had to do SOMETHING to downsize the stage 1 ntpdate and dependencies or such?

Enjoy all the hands-on work when you want your faster musl or uclibc and full ntpd rather than ntpdate.

I don't like the old pre-systemd world. It's overall much easier now.

Literally why would you ever need ntp inside the initrd. Start it after switch_root like a normal distro

Nice derail

NSA confirmed

I mean the first stage of typical inits - what most distros required between the initrd and the system running off the "normal" system binaries and stuff.

Terminology varies. I guess for example Debian would call it the "mini-Debian" of stage 3 of the overall startup rather than the stage 1 of the distro's own init.
debian.org/doc/manuals/debian-reference/ch03.en.html#_stage_3_the_mini_debian_system

Ok, so from when the kernel has mounted the initramfs and starts /sbin/init, to when that /sbin/init runs switch_root. You could have just answered the question like that. Not everyone knows the technical terms for it.

For example, because you needed to use autokey with ntpd, which ntpdate didn't support.

*Not everyone knows the technical terms, let alone the numbers

If I'm reading support.ntp.org/bin/view/Support/ConfiguringAutokey correctly, that doesn't require starting before the fucking rootfs has been mounted

It's not as good as OpenRC

You want the time secured so the certificates can be validated so you can mount your root off a network filesystem, for example.

Ok, if you're mounting your root off a network filesystem, and want to verify the certificate of your ntp server, them yes, you need to put ntpd in your initramfs.

If I had a dime for every time I absolutely needed that, I'd probably have negative money. Also, systemd doesn't help you in that situation at all afaik

Init isn't supposed to mount filesystems though. The process that mounts filesystems is supposed to mount filesystems.

Yeah I just looked it up, timedatectl doesn't support keys. You desperately want to replace ntpd with systemd but systemd doesn't even support your use case for why systemd is better

Hell it stores some of its config files in a binary format database. It's a shitshow.

> If I had a dime for every time I absolutely needed that
That's no argument. Yes, other people need something *you* don't need.

And the point is that the old way of doing anything even just marginally different generally required you to fuck with multiple annoying to edit and maintain things, such as an initrd and a stage 1. With a low chance of actually being able to use something from another distro and all that.

Now way more things are easily supported, even initrd-less boots and the like.

> Also, systemd doesn't help you in that situation at all afaik
It does. For example at the equivalent of stage 1 you should generally have /usr and /run mounted (because that's the recommendation when initrd are used freedesktop.org/wiki/Software/systemd/InitrdInterface/ ), plus you have almost "all you need to boot" in systemd itself anyhow, which is present.

Ok, so systemd starts ntpd after /usr is mounted, etc.. So you still don't need ntpd in your initrd. I don't see what you're getting at

good derail

Fuck off

anything is better than another systemd thread

>Ok, but dhcpcd doesn't need to be built in to PID 1
Pretty much nothing except launching a few scripts should be in PID 1

Ironic that systemd is now so bloated that it's slower than traditional system scripts. This is why I moved to BSD.

systemd.mount > fstab

Just give in.

>refracta8_xfce_i386-20161014_1432.iso

Linux got too mainstream and big and combined with retarded hipster contrarian culture led to this meme hate wherein those least qualified to make decisions on what init system a distro uses think their special snowflake opinion matters. Same people before this shit started never knew what an init system was, some still don't and wouldn't even fucking know what to replace it with.

Your shitty little opinion on how to run the distro is disregarded because it's a shitty little opinion. But because of journalist and forum clickbait, everyone thinks they get to tell everyone else what should be in the distro or not.

It's fucking over, all major distros use it now. You can keep crying about it and make more threads jerking off about muh unix philosophy. That shit was written over 60 years ago, pcs and hardware kind of changed in the mean time. You are more than welcome to fuck off to some shitty hipster anti-systemd distro, once finally given the chance to make something all the anti-systemd shits fail miserably showing off in detail how they indeed don't know the first fucking thing about making or maintaining a distro.

Nothing. Except that Poettering has lost his mind and tries to add almost all shit instead of develop the barebones and create a plug-ing architecture to add the shit that red hat kikes want.
But in principe is fine.

> You desperately want to replace ntpd with systemd
No, I don't want to have to maintain a initrd ntpd (maybe statically compiled), a stage 1 ntpd (maybe linked only against an included dietlibc which maybe doesn't work for ntpd and I might need to replace with uclibc or glibc somehow), and then then the running system ntpd (typical dynamically linked libraries), or such.

Yea, it'd probably be easier if systemd-timesyncd supported full ntp like ntpd rather than just simple ntp? Could be a thing, eh.

But I'm fine with the whole thing just being less of a mess overall by having what's important to replace all typical stage 1 things included.

>le epic everything in systemd is in a giant binary running in pid 1 maymay xD

>trying to do to
Did you literally just list all the things from that sock puppet gif?

That was satire it isn't meant to be taken literally you fucking moron.

> Ironic that systemd is now so bloated that it's slower than traditional system scripts.
This is actually not true.

roll

It's not fault of systemd that linux still doesn't had a proper IPC system. Dbus was used thus adopted.
It's not fault of systemd that no one has offered to maintain read ahead.
>muh cron
That shit even cant count the time
Upstart has design defects. Probably is one of the consequences.
>swap handling is bloat
Do you run a fucking pentium III?
>snapshotting of the system state
It's useful for servers and big enterprise shit. Not for the arch obese drone.
Granted, that should be implemented apart.
>still believing the lie that all systemd is implemented in pid 1

Roll

>>swap handling is bloat
>Do you run a fucking pentium III?

>service with ExecStart=swapon -a
good
>creating a new fucking binary to do just that
stupid

Actually swapon is a dumb fstab parser, the systemd implementation is far more sane.

-->

The systemd implementation uses systemd mounts, which are fucking retarted. fstab wasn't broken and there's no reason to replace it

fstab wasn't replaced user.

Is too late to rewrite systemd as a basic intelligent init and service management and let the rest of the shit being plugins?

>which are fucking retarted
retardedly awesome and better than fstab.

whats your favorite anime

Rolling

Rollerino

This season I recommend Masamune-kun no Revenge
:3

that wasn't what i asked nerd

Why wouldn't he add the full functionality typical systems need to boot?

Anything else hasn't actually worked well, it just meant you might constantly encounter distros that can't mount a LUKS encrypted /var right at the time /root is mounted or some shit like that.

I've seen too many to have a favorite.

Rollllll

I'm not talking about boot stuff, I'm talking about the shit catered to servers, like container support and shit, all in the same codebase.
Granted, I know that they can be disabled at compile time, but I think plugins could be more flexible and get cleaner code.

systemd has been nothing but frustration for me. It's not convenient at all. I lost count of how many times I had openSUSE and Debian crash in the middle of important operations. Systemd is immature.

So stop using Distro that have shitty support like Debian and OpenSUSE.

Haven't had a single systemd related crash on Gentoo, which has the best systemd support out of any distribution including Fedora.

I do agree adoption of systemd was kind haphazard and suspiciously in hurry but things are getting better SLOWLY.

What was the exact source of your problem user?

>liking typical highschool anime
That's why you like SystemD.
But when you like Serial Experiments Lain, you must hate SystemD.

I am on Slackware. It's rock solid and everything works just right.

>gentoo
>best systemd support
How is that possible?