Why does everyone seem to hate systemd so much?

Why does everyone seem to hate systemd so much?
I quite like it

Other urls found in this thread:

bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658
github.com/systemd/systemd/issues/437
github.com/systemd/systemd/blob/master/DISTRO_PORTING#L45
github.com/elogind/elogind
without-systemd.org/wiki/index.php/Arguments_against_systemd
github.com/storaged-project/udisks/blob/master/packaging/udisks2.spec
wiki.gentoo.org/wiki/Udisks
github.com/ConsoleKit2/ConsoleKit2
twitter.com/NSFWRedditImage

same here, the desktop needs it.

although its overreaching, but one the dust settles down, someone is gonna take it apart and keep it the useful stuff.
Overall systemd is one of the best things to happen to linux on the desktop. thank god i dont ever have to fuck around with policykit permissions or udev rules ever again.

fuck off with your shit lennart.

...

I'm slightly ashamed to admit I'm not even sure what SystemD is. I am a professional software developer btw.

It puts you in the realm of 2 operating system designs. If the Linux kernel and userland were designed with systemd in mind it'd probably be fine.

MEMORY LEAK

and this anus

I just love it when my init system is a huge convoluted mess that does everything poorly instead of one thing well.

>I quite like it
I've got bad news about your sexuality.

People just hate it because it automates a lot of the easy shit like writing init shell scripts that they used to get paid for. Now they actually have to do something useful.

Overall systemd is a improvement over its predecessors.

>binary logs

>everyone
nope, it's only a vocal, uneducated and good-for-nothing minority.

ok, and now post your opinion

It's an init system. It runs daemons on bootup.

will there a time come when all jobs will be taken away from technology? i can see why Sup Forums hates pajeets, cheap labor time is here, what do you guys think how far is the time when everything will be automated and tech jobs will disappear

this

Once we make a single AI that can even vaguely understand the concepts of AI, it can be immediately distributed and work round the clock, which is a limitation we can't overcome as humans. That's just a short while before we become obsolete.

hold me user i dont want to lose the times when on the day of paycheck i treat myself by immediately ordering new keycaps or anime figurines

the desktop needs more than that.

>because it automates a lot of the easy shit like writing init shell scripts that they used to get paid for.
What planet are you living on? Even if you factor in watchdog/respawn components and service dependencies, even the most complex init scripts don't take a day to write. All of the things that systemd automates were menial, annoying tasks that nobody enjoyed doing.

That's putting aside that any employer who thinks those things take a lot of time is going to know jack-shit about systemd. Logically those lazy people would like systemd for reducing what little work they did further.

Uses lots of useless memory, is slow as fuck, has a shit ton of stuff that it shouldn't have (like a network manager and a bootloader), some programs have it as dependency for no good reason, they're basically asking the kernel to fix their crap, there are countless bugs, and the code is so big and horrible that is impossible to see if it has backdoors or vulnerabilities

People that dislike it bring actual reasons to the table.

People that claim to like it can't offer any positive facts or advantages. They only repeat that "it's new" or "I don't see anything wrong".

SystemD will probably soon come with google APIs installed.

It already uses google DNS and NTP services.

Nope.

bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658
github.com/systemd/systemd/issues/437

But it does. It silently falls back to Google DNS if user-supplied one can't be reached IIRC

Wrong again.

Kek

github.com/systemd/systemd/blob/master/DISTRO_PORTING#L45

There you go, you Poottering shill

Wrong again.

I could point out how this is a compile-time choice to ease developers in testing phases, and that distro maintainers are invited to apply their own compile-time choices.
I could point out how systemd-resolved is disabled per default in any distro (including Fedora) except in Ubuntu, where the maintainer chose to keep the upstream compile-time choice.
I could point out the compile-time DNS servers kick in only if no DHCP setup occurred, no /etc/resolv.conf is defined, no policy for systemd-resolved is defined and systemd-resolved is enabled.
I could point all this, but the usual, yet the useless peanut gallery would still spread FUD about hardcoded DNS servers that are not hardcoded at all.
It can't be helped.

>distros are to blame for upstream defaults

Hi Lennart.

>it's not a default because it can be changed
Are you real?

Not at all, and name calling wouldn't lead you anywhere. The same commit message you referenced says:
document that distros may/should change fallback DNS... as well as fallback NTP if they wish

The DNS and NTP fallback server situation is pretty similar, and
downstream distros might want to change both to whatever they need,
hence mention them both.
Maintainers are invited to apply whichever value they prefer at compile-time.

It's not a default, at all.

And that changes what the upstream default is how?

FUCK OFF REDHAT SHILL YOUR SHIT IS OBVIOUS

And if they apply none, they get Google. What do you call a value that is used unless an alternative is specified?

>Setting starts in a certain way and must be changed from that starting value.
>"Its not a default, guise!"

>someone is gonna take it apart and keep it the useful stuff
Someone already has. Just use elogind. Nothing else in systemd is useful.
github.com/elogind/elogind

thats not true.
You just want to use my post to pass the point that nothing in systemd is useful.
Sorry i don't buy it.

I call him "a bad maintainer who can't read instructions about the software he's going to package". Even worse, he doesn't provide configs for such software at all, even if he's going to enable per default.

It's not a default, no matter how hard you memearrow.

What else in systemd is useful then?

You must be 18yo to post on this board.

Pray tell, what else is needed?
What feature is needed that ABSOLUTELY has to be a part of the init system?

It is a default, no matter how hard you shill.

>don't pass an option during compile time
>get google DNS
>this is somehow not a default

I prefer to believe systemd is simply a relatively new advancement in gnu+linux, and so it is a natural target for a FUD campaign by the enemies of free software.
The alternative is unpalatable to me because I don't want to believe that so many completely ignorant people feel entitled to vent such strong opinions.

>new advancement
What did systemd "advance?"

...

It has done a lot to advance trolling in the Linux community.
No more outdated tired flame wars about emacs vs vim or microkernels.

Declarative syntax, event-based startup - no, wait, upstart already had that.

But it's made by Red Hat instead of Canonical, and...uh...

What's useful about that?
What use did anyone ever had for ConsoleKit/logind?

Session managers are nice for tracking user permissions and stuff. Consolekit2 is pretty good as well, but you often have to go out of your way to compile for it.

Tell me an actual real situation were it came in useful for you.

Automounting usbs. There's no need to fiddle with udev rules.

No, it's not.

there's never a need to fiddle with udev rules for auto mounting permissions on any sane system

Yes it is.

>any sane system
AKA one with a session manager like Consolekit or logind.

No, one that already sets the appropriate group permission for removable media.

The peanut gallery gonna peanut, as usual. They'll disregard any evidence whilst showing no competence at all in packaging and development process. They'll completely avoid considering all this and that a config file is a mantainer's duty, as well as packaging. They'll completely miss that it's not used in any distro but one, and that in Fedora/RH/CentOS the default network service is the LSB one, followed by NetworkiManger and that the Ubuntu maintainer chose somehow to adopt something not ready for production.
Then, they'll spread FUD like "if you use systemd, it will default to google DNS" and the like. Simply untrue.

It can't be helped. You'll always be worthless good-for-nothing whiners.

You should look into udevil. Automounting usbs without polkit, consolekit, or logind.

So instead you're fiddling with group permissions via autofs or something silly like that? You do realize that the vast majority of distros use session managers right?

I'm aware that it's possible. It's just not as convenient.

What the fuck are you talking about?
You just have to add user to to the appropriate group and you're done.

Consolekit doesn't do automounting ffs.
It's just that FDO crap like udisks depends on it for permissions.

Which group?

That's my point. You don't even have to bother setting permissions. Just install gvfs, udisks or whatever and it works.

Do you not understand what a default is? systemd recommending that packagers change the dns and ntp servers at compile time does not change the fact that vanilla upstream systemd defaults to google dns and google ntp.

You should look into udevil it uses udev and plain old unix permissions to do automounting.

Here ya go op without-systemd.org/wiki/index.php/Arguments_against_systemd

>Which group
depends on the distro, for example "plugdev"

>That's my point
Your point is that you find ConsoleKit useful because you find other software, that unnecessarily depends on it, useful?

...

>Your point is that you find ConsoleKit useful because you find other software, that unnecessarily depends on it, useful?
I don't know what you're talking about here. Udisks doesn't depend on Consolekit. It's useful because you don't have to bother setting user permissions. You install it and that's it. The plugdev group you mentioned doesn't just magically work. It almost always depends on FUSE, pmount, or some other solution that is more hacky.

>Udisks doesn't depend on Consolekit
It does. You might not see it as a dependency in whatever you're using because it's provided by systemd.

>It's useful because you don't have to bother setting user permissions.
It's quite the opposite. It's an additional thing that has to be set up.

>The plugdev group you mentioned doesn't just magically work.
It does if the distro sets it up properly.
ConsoleKit doesn't magically work either - it has to be properly set up.

>It does. You might not see it as a dependency in whatever you're using because it's provided by systemd.
What? No it doesn't. Udisks has no reason to look specifically for consolekit. And consolekit looks for dbus not specifically udisks. You can build udisks without systemd as well.

>It's quite the opposite. It's an additional thing that has to be set up.
>It does if the distro sets it up properly.

Nonsense, if the display manager is compiled with consolekit support, then you're done. That's all you have to do. Trying to get automounting to work without a session manager means you'll be messing with udev or fuse or something. Yes, a distro could possibly set it up for you. However in practice, 99% of distros use a session manager either via systemd or possibly through consolekit or elogind if you're on a non-systemd distro.

>What? No it doesn't. Udisks has no reason to look specifically for consolekit.
Yes it does. Look it up.

>However in practice, 99% of distros use a session manager either via systemd or possibly through consolekit or elogind if you're on a non-systemd distro.
Just because the distro is misconfigured and relies solely on ConsoleKit does not make ConsoleKit useful.
You can have a pre-configured setup that is just as painless without it.
Ergo it is useless for you. You don't use any of the functionality that is not already provided by simpler mechanisms.

You don't have to mess with fuse or udev for automounting without consolekit. Just install spacefm and udevil and your done.

>Yes it does. Look it up.
Great argument. Why don't you look it up?
github.com/storaged-project/udisks/blob/master/packaging/udisks2.spec

It says it requires systemd there, but you can build udisks2 without it as evidenced by Gentoo.
wiki.gentoo.org/wiki/Udisks

>Ergo it is useless for you. You don't use any of the functionality that is not already provided by simpler mechanisms.
You're making an awful a lot of assumptions there. My distro doesn't have a pre-configuration. I set it up myself. I actually use elogind (but I have used Consolekit2 in the past). The reason being is because they are simple to use.

That works if you're using logind/elogind. Unless spacefm does something special. It might.

(((systemd)))

Oh. Since you like it so much would you mind telling us all what you "like" so much about it?

Speak, unknowledgeable faggot.

Spacefm does do something special. It uses udevil which uses the rare and elusive sticky bit.

>It says it requires systemd there, but you can build udisks2 without it as evidenced by Gentoo.
gentoo needs elogind.for it.
Even the wiki page mentions polkit, which needs Consolekit.
Dependency is a transitive relation.

> My distro doesn't have a pre-configuration.
It does. That's the whole point of a distro. Even gentoo.
And there's of course the upstream provided pre-configuration.
Which in case of FDO software is all configured to be interdependent.

I didn't like it at the beginning, but journalctl is /comfy/ af

Udevil on its own is merely one of many automounters. You still would have to have something that sets permissions I'll admit that I've never tried spacefm+udevil, so it's possible that spacefm does something to nicely solve the problem.

>gentoo needs elogind.for it.
No it doesn't. That's optional.

>Even the wiki page mentions polkit, which needs Consolekit.
The actual dependency in question is dbus. Udisks doesn't communicate directly with polkit. It merely reads what dbus tells it to do. Using polkit with Consolekit or elogind is optional and not required.

>Which in case of FDO software is all configured to be interdependent.
I know you autistically hate FDO, but this is just a case of multiple programs communicating with dbus.

You are the one telling me all the time how udisks is already configured to use ConsoleKit and only ConsoleKit.
Clearly it is a dependency. You're arguing against your own point.

>udisks is already configured to use ConsoleKit and only ConsoleKit
>only ConsoleKit
I never once said "only Consolekit." You don't seem to understand how this works. ConsoleKit tells dbus what permisions to use and udisks reads what dbus says. That's it.

Spacefm just takes advantage of udevils nicety. Udevil uses the u+s sticky bit to run as root so it doesn't need consolekit or polkit or dbus for permissions.

No, this is not how it works at all.
Udisks asks PolicyKit if the user has permission to mount the device.
PolicyKit, by default, answers yes if either the user is root or if he's in the ConsoleKit session.

PolicyKit can just as well be configured to also answer yes if the user is in plugdev.

Don't you just love how needlessly complex red hat software is?

No, Udisks talks to dbus and not directly with policykit or consolekit. You can also use Consolekit without policykit if you so desire.
github.com/ConsoleKit2/ConsoleKit2

It doesn't fucking matter how they communicate.

Does nm-applet not depend on NetworkManager because they talk over dbus instead of some ABI?

I don't know. I don't use NetworkManager. Udisks works without policykit and consolekit, so no those aren't dependencies.

>Udisks works without policykit and consolekit, so no those aren't dependencies.
Not correctly, you said so yourself!

And nm-applet would also "run" without NetworkManager installed.

>Not correctly, you said so yourself!
Where? Udisks's only job is to tell dbus what storage devices are present. What you do with that information is up to you.

>I need ConsoleKit because otherwise I can't mount shit with udisks
>but udisks totally doesn't depend on ConsoleKit guize

pick one

The vast majority of distros don't even use Consolekit. They use logind via systemd. You can also use elogind. You could write your own session manager if you want. Or not even have one. That's not a dependecy.

Now you're just being autistic because you ran out of actual arguments.
It's pretty clear to you that I'm talking about ConsoleKit/ConsoleKit2/logind/elogind etc. when I say ConsoleKit. Don't even pretend otherwise.

>lump a bunch of different software together and call it a dependency
Great argument.

It's the same fucking shit, functionality-wise.
Who cares what's the current pointless rewrite is called.

>It's the same fucking shit, functionality-wise.
And? Do you also complain that you need a thumbnailer service to get image thumbnails in a file manager. There's only like three or four of them I think.

A thumbnailer gives you thumbnails you don't have otherwise.
ConsoleKit5000 gives you permission to use something you already have permission for.

But you don't already have permission for it.