They are actually both much better than the things they replace, but a bunch of whiner babies can't stand the thought of anything changing and will claw and scream while being dragged into the future.

Systemd-resolvd is a bad DNS resolver and journalctl makes logging needlessly complicated and log files slow to read. Also, socket activation is basically xinetd and we got rid of it because it's a brittle hack, also slower than starting stuff as soon as possible if you actually need it.

I’ll agree with some parts of this as I have some big issues with parts of systemd. But writing service files with systemd is so much better and having a unified interface into logs is really really nice.

Sure, there are a few things it's better at. I don't think it's entirely bad, just that the good things are way outweighed by the bad.

Probably didn't even bother to diagnose the issue. It's hard to tell if it was even wayland related without logs and some digging. But lets just blindly blame wayland cause new thing bad!

Log in using wayland -> no desktop. Log in using x11 -> desktop. Clearly it's "wayland related" even if whatever root cause it is is something you wouldn't consider directly attributable to it. Logging into a graphical session is something that has just worked out of the box each other install on whatever random hardware I've used for many years. How is that classified as some nitpicky "new thing bad" complaint?

Well, it's like new car doesn't start but you have forgotten to put fuel into it, and now blame the car.

This is Linux desktop, like if you have never had a black screen before then I'm not sure what you expect. One culprit could actually be the home .config/.cache folders that have all kind of sh*t accumulated (like why do we still do it this way? It's horrible), so I usually rename them and try again to see if this is the problem behind the scenes.

Well, if I never had to put fuel into my old car then this would be a step back, no? I'm not a stranger to troubleshooting, and do a lot of it already, which occupies my energy and time for troubleshooting. I use Debian stable for a reason. It's mostly that if I didn't go looking for a new thing, it doesn't provide anything new that I want, it removes old things that I want, and it doesn't work without troubleshooting, why do I want this thing?

This specifically isn't the biggest issue for me right now because I use this machine mainly over ssh, but if I eventually can't do x-forwarding, RDP, or log in manually without finding some fix, that's a lot of extra work and lost functionality.

Blame on Wayland is absolutely justified here. If you force changes onto others its up to you to make sure you're not breaking things.

I am actually working on my own language, and getting something better than Go is actually not that difficult!

The hard part about making a language is creating the stdlib and tooling and support for the language, but actually creating a language itself that has more features and better features than go can be done by a single person in a few months or a year probably, depending on how much experience they have.

Generics specifically are a great example here. A single person can implement a language with go-level generics fairly easily.

Java is probably able to bump allocate memory or something similar, where rust is using a general purpose allocator.

I guess if you are formatting strings constantly this is important, but you can also use a bump allocator in rust if you really wanted to.

How large are your rust projects?

I am able to write rust on a moto g power (a cheap android smartphone) inside of termux, running on battery, in battery saver mode, and cached compile times for every single one of my projects is under 5s easily, if not faster. Fast enough that I don't notice it at all.

Even a "cold" compile was under 1 minute for me, and I have a decent amount of deps.

I guess my projects are fairly small compared to others though so idk.

And ironically with the exception of the python sqlite3 module, the rust alternatives are much higher quality, IMO.

Does anyone even use tkinter in modern times anyways?

I wouldn't start a company behind it but tkinter is perfectly fine for basic guis. It has its quirks but who doesn't?

Does it though?

People experience "blue screens" and kernel panics and such pretty often.

The statistics we have on real world security exploits proves that most security exploits are not coming from supply chain attacks though.

Memory safety related security exploits happen in a steady stream in basically all non-trivial C projects, but supply chain attacks, while possible, are much more rare.

I'm not saying we shouldn't care about both issues, but the idea is to fix the low hanging fruit and common cases before optimizing for things that aren't in practice that big of a deal.

Also, C is not inherently invulnerable to supply chain attacks either!

>The curl|sh workflow is no more dangerous that downloading an executable off the internet

It actually is for a lot of subtle reasons, assuming you were going to check the executable checksum or something, or blindly downloading + running a script.

The big thing is that it can serve you up different contents if it detects it's being piped into a shell which is in theory possible, but also because if the download is interrupted you end up with half of the script ran, and a broken install.

If you are going to do this, its much better to do something like:

    sh -c "$(curl https://foo.bar/blah.sh)"

Though ideally yes you just download it and read it like a normal person.

No it definitely is a monolith.

It's NOT loosely coupled in any way. Try running any part of the systemd software suite on an openrc system and see how that works out?

I have no idea why people are so insistent on claiming that its not a monolith, when it ticks off every box of what a monolith is.

Most systemd components do rely on some core systemd components like systemd (the service manager) and journald. I would say that a core thesis of systemd is that Linux needs/needed a set of higher-level abstractions, and that systemd-the-service-manager has provided those abstractions. The fact that other parts of systemd-the-project rely on those abstractions does not imply that the project is monolithic.

>Try running any part of the systemd software suite on an openrc system and see how that works out?

Well from this POV it's kinda openrc's problem if it doesn't. What about trying to run any part of the Openrc software suite on an Upstart system? The question why would anyone sane want to is rhetorical tho...

Why obsessing over whether systemd is monolithic and in what measure anyway? There certainly ARE optional systemd parts. So it's correct to say it's not entirely monolithic.

openrc-init can be used on an upstart system, the daemon manager itself can't but that's because you'd have two different daemon managers. Beyond that there aren't any openrc software components, because it was designed to be a modular init system that just handles what it was intended to handle.

The rest of the system for example chrony, sysklogd, cron, etc run fine on upstart systems, because they aren't tied to systemd and are fully modular.

It's okay to be a monolith, that doesn't make it inherently bad or anything, but we should be honest about it, and it does come with some tradeoffs.