This systemd thing is really out of hand.
-
-
Liked for reasons I do not understand.
-
Just found this nugget roasting on a
:hocho: :kdbus is a technically watertight solution to a manufactured problem with intentional political side effects.
-
Someone at Devuan makes a Hitler rant video.
https://www.youtube.com/watch?v=_cdEFF-ttLw
Keep fighting the good fight, guys! And keep those tinfoil hats straight on!
-
I LOL'd at ALSA
-
GOD FUCKING DAMMIT I HATE THOSE.
Downfall is an excellent movie. If people are going to make this fucking awful stupid unfunny parodies, could they start from crappy source material? "Yeah it's the best history movie of the last decade, but the only reason anybody's heard of it is because someone replaced the subtitles with text about new Pokemon."
-
Using crappy source material would make these worse, not better. This one amuses me.The "now people can choose" even fits with Hitler being angry. This one is good on several levels.
LOL: "If only Linus wasn't such a dictator..."
-
Using crappy source material would make these worse, not better.
Those jokes could not be worse.
This one amuses me.
Then you are easily amused. Here's something else you might find compelling:
-
Then you are easily amused. Here's something else you might find compelling:
I'm amused that you found that or knew where to find it.
Those jokes could not be worse.
You're just green with envy that you aren't as funny as those guys.
-
GOD FUCKING DAMMIT I HATE THOSE.
Downfall is an excellent movie. If people are going to make this fucking awful stupid unfunny parodies, could they start from crappy source material? "Yeah it's the best history movie of the last decade, but the only reason anybody's heard of it is because someone replaced the subtitles with text about new Pokemon."
Fantastic movie. Still dig the parodies.
Hey, we could always all switch to the "old Spanish guy laughs" style
-
There is a menace which is spreading like a disease throughout the Linux world, it is called systemd.
Right "menace".
Now follows a list of unsorted links to the Systemd changelog with comments. The list is exceeding the life-time of a philosopher to discuss all implications on the sanity of a system design. That’s why the comments are kept short.
This guy is insane.
Network configuration should be in my init process.
Uh... shouldn't it?
Welcome to the Windows OEM world: Factory reset for Linux! Of course it is in your init process.
I like the ones where the only criticism is that it introduces a feature that Windows has.
I'd love to hear an explanation of why factory reset for Linux is a bad thing. Oh wait, doesn't Android (a Linux) already have factory reset? So...
Why does the kernel have tty handling? So in serious situations you will be able to debug it over the last standing PIN on your motherboard. Let us remove this, run it in pid 1.
He's complaining about removing it and also pointing out that SystemD still runs it in literally the same sentence, the fuck!?
»Interactive authentication«
This is bad because Windows has it (for fully-encrypted disks). But he doesn't spell that out, so I thought I'd mention that here.
Power management is required on boot up.
Uh, isn't it?
This is pure evil. Your pid 1 is now able to import complete system images over the network and show them to you as your running system. There is nothing that can go wrong.
What's wrong with having netboot?
- Führerbunker, 2015-07-31
Ah, I see we are dealing with a stable not-at-all-insane person here.
-
Mostly what he's complaining about is the way systemd just keeps on wedging more and more and more functionality into PID 1.
PID 1 has the special property of becoming a kind of adoptive parent for processes whose actual parents have already died, taking on the responsibility for cleaning up the process table when those orphan processes do eventually die.
There's a respectable school of thought that holds that all PID 1 ought to do is launch a "real" init process, then hang about doing nothing but cleaning up orphans and processing system shutdown and restart signals. That way it can be coded so simply as to be bug-free, and hence indestructible, by inspection.
The main objection that thinkers in this school have to systemd is the explosion of complexity designed into systemd's PID 1, which will inevitably make it buggy, which will inevitably lead to some proportion of systems that just hang in the field. This isn't crazy, just conservative. And to be fair, the systemd development team does have prior form in arrogantly asserting that any problem anybody has with their stuff can't possibly be their fault, even when it is.
It's not so much the Windows-alike facilities that rub folks the wrong way about systemd; it's the Windows-alike module complexity, the tight interdependencies, and the Windows-alike penchant for doing simple things in complicated ways.
I've been running systemd on my own boxes for a year and a bit now, and every now and again they do exhibit mysterious new behavior that's in-practice impossible to track down. Which is not really surprising, given the number of potential race conditions that systemd's design enables. On the upside, the frequency of that stuff is indeed reducing as systemd matures.
-
Mostly what he's complaining about is the way systemd just keeps on wedging more and more and more functionality into PID 1.
Right; but most of the stuff he's bitching about (like the network connectivity) does not run in PID 1.
Just because it's part of the SystemD project/code repo doesn't mean it runs in PID 1.
-
It might as well, if PID 1 relies on it for proper function.
I haven't looked closely at the systemd code - I'm a netadmin, and hence a systemd user, rather than an init system dev - but although there is undoubtedly a slew of ill-informed Lennart-bashing out and about on the web, I am not inclined to set my default position to Lennart Can Do No Wrong either.
There are genuine cultural risks in allowing any dev team to become as pervasively influential as the systemd team has, and we have not yet had enough time to work out just how many of the babies that got thrown out with the SysVInit bathwater we will actually end up missing.
-
The systemd project has a serious case of Not Invented Here syndrome.
Here are just a few examples:
journald, which does the same thing assyslog-ng.logind, which does the same thing asConsoleKit.networkd, which does the same thing asifconfigwrappers (such asifupdown) anddhcpd. And no,dhcpdis not a typo,networkdhas a DHCP server embedded into it.udevd, which does the same thingudevdoes.timedated, which does roughly the same thinghwclockdoes... and hell, that's just a wrapper for thegettimeofday/settimeofdaysystem calls.
-
logind, which does the same thing as ConsoleKit.
I thought logind was a redesign of ConsoleKit to avoid the poor decisions that made it hell to work with.
-
There are genuine cultural risks in allowing any dev team to become as pervasively influential as the systemd team has, and we have not yet had enough time to work out just how many of the babies that got thrown out with the SysVInit bathwater we will actually end up missing.
The open source culture is so awful and broken that I can't even imagine how this could be considered a bad thing.
-
The open source culture is so awful and broken that I can't even imagine how this could be considered a bad thing.
...because you could end with a situation where a certain player controls more than 50% of a market and refuses to implement a new standard to fix a fundamental drawback in a common protocol.
-
Oh but all the open source-y people brag that you can fork at any time, so that's an impossible situation.
-
Which is exactly why the tight interdependencies between the various components of systemd are problematic. Fork any of them and you've pretty much committed to forking all of them.
-
Ok; maybe it's not perfect. But since nobody else was solving those critical problems with shitty Linux I guess you just have to bow down and TAKE IT UP THE ASS.
-
Thank you for that. I was previously unaware of the Anal Rape design pattern.
-
The systemd project has a serious case of Not Invented Here syndrome.
And you're missing a bunch.
The one that pisses me off the most is DHCP being baked into the system. We're supposed to be migrating to IPv6 and getting rid of that legacy crap.
-
IPv6 is not mutually-exclusive with DHCP.
-
We're supposed to be migrating to IPv6 and getting rid of that legacy crap.
I thought it was NAT that IPv6 was supposed to get rid of, not DHCP. I don't want to have to tell each device by hand what it's v6 address is! (Especially not mobile devices, with their miserable on-screen keyboards.)
DHCP is updated for IPv6. The spec has been in place for ages.
-
I am fully aware of that. However, IPv6 was designed not to need DHCP, which is why IPv6 was defined in 1998 but DHCP6 wasn't added as an optional extra until 2003.
If you're going to stick DHCP in systemd, you might as well put in SLIP and PPP.
-
I don't want to have to tell each device by hand what it's v6 address is!
You don't have to. IPv6 has stateless autoconfiguration of IPv6 addresses, without needing a DHCP server. That's how they all get IPv6 addresses on my network.
-
I am fully aware of that.
Then you're whinging about... what?
If you're going to stick DHCP in systemd, you might as well put in SLIP and PPP.
Sure. Might as well. A lot of DSL systems still use PPP.
-
Then you're whinging about... what?
Stuffing features most people don't need into systemd. That's what this thread is about, remember?
-
IPv6 has stateless autoconfiguration of IPv6 addresses, without needing a DHCP server.
Either a device knows ahead of time what its address is, or it picks one at random, or it asks another service (at a known link-local address) what address it should use. Having devices just know ahead of time is a PITA because typing in addresses sucks, and random is only ever suitable for clients (servers have to be at a known address, given that DNS updates most definitely aren't instant). So we end up with something that looks like DHCP and quacks like DHCP! It might be integrated into the router infrastructure, sure, but it is logically a separate entity.
You're railing at the wrong thing. The IPv6 designers hated NAT.
-
It's a moot point, systemd-network only supports IPv4 DHCP.
So... if you're running an all IPv6 network, you still have an IPv4 DHCP daemon running. BRILLANT!
-
Having devices just know ahead of time is a PITA because typing in addresses sucks
Zeroconf. Welcome to 1999!
You're railing at the wrong thing. The IPv6 designers hated NAT.
They had multiple hates. A third one was variable size IP headers.
-
IPv6 is not mutually-exclusive with DHCP.
Indeed. And for my money, DHCP is much better designed than that router advertisement push bullshit that's supposed to be the alternative.
-
IPv6 has stateless autoconfiguration of IPv6 addresses, without needing a DHCP server.
DHCP can autoconfigure a lot more things than just IP addresses.
-
-
DHCP can autoconfigure a lot more things than just IP addresses.
I know that too, but I'd bet 99% of DHCP use is just configuring IP. I've never encountered an organization using DHCP to send information about printers and syslog servers.
Home users don't need DHCP for IPv6. If they do, chances are they already get it from their router.
Business servers don't need DHCP (they use static addresses), and even if they do want to use DHCP for some reason, they are typically only going to want 1 or 2 DHCP servers per network. So having a DHCP server in systemd is a pointless waste of space 99% of the time, and just increases the attack surface.
Seriously, if you have a valid use case for every machine on your network having a DHCP server, please go ahead and tell us about it. I'd be genuinely interested to hear it.
-
I'd bet 99% of DHCP use is just configuring IP. I've never encountered an organization using DHCP to send information about printers and syslog servers.
My school network uses it to configure IP address, default route, DNS, some additional static routes, WPAD and NTP.
if you have a valid use case for every machine on your network having a DHCP server
That would yield a horribly chaotic network, I would think. The case for having DHCP clients available everywhere is stronger.
-
Right. I have no beef with having a DHCP client available in systemd, for the time being, even though it will soon be unnecessary. It's having a server that's dumb.
-
OTOH, it's very handy to have a DHCP server available for internal private network use inside any machine that's hosting VMs; setting up your standard VM images with DHCP clients can save a lot of repeated configuration.
-
Yes, the VM image use case is undoubtedly why RedHat have shoved it into systemd. Still, that's a special case, and even there you don't need the DHCP server you'll end up with in all the VMs, so it's still misguided there I think.
-
That still doesn't explain why the tool that initializes your network interface on behalf of the kernel (which does the actual networking) should have a DHCPv4 server in it.
Did I mention that it takes less than a minute to install a dhcp server on your average Linux installation? Not only does it not live in a system startup process, but the ISC one also claims to support DHCPv6 (according to its website anyway).
-
Considering all the misinformation about systemd out there, I'm guessing it's not even part of the default systemd install.
-
I have a default Debian deskop systemd install right here. /lib/systemd/systemd-networkd exists, and the documentation tells me I can configure it as a DHCP client or a basic DHCP server (which the docs specifically mention is "Mostly useful for handing out leases to container instances").
The default configuration appears to be intended to enable a systemd DHCP client on a system running in a container, and a systemd DHCP server on every virtual Ethernet interface. Both of these look very easy to disable, should I wish to install a more capable server or client. I don't think it's a big deal.
-
So when's Red Hat's big lawsuit about how they're "eroding consumer choice" by including their own DHCP server in the box, configured by default, to the detriment of competitors in the space like ISC?
-
That would be when none of the distro maintainers can figure out how to package the competitor products in such a way that installing one of them automatically turns off any systemd fallback for the same service, i.e. never.
-
That would be when none of the distro maintainers can figure out how to package the competitor products in such a way that installing one of them automatically turns off any systemd fallback for the same service
Okay, that makes sense, I understand, so that'll probably happen in about two to thr--@flabdablet said:i.e. never.
HAHAHAHAHA! You're such a kidder!
-
So why the hell did you type it? I wanna get inside your head, man.
The doctor, is in
DHCPv6 - Wikipedia
