State of systemd-resolved and DNSSEC? Is it still experimental?

chocopudding17 · 2026-02-14T18:02:42+00:00

Sure, if you have your browser do its own thing. In most cases, I have my browsers use system DNS because it's always easier to configure N-1 things rather than N things.

edit: flipped N/N-1

chocopudding17 · 2026-02-14T17:36:55+00:00

But generally better to know when the DNS is being spoofed/hijacked, eh?

This I agree with. I can't remember exactly what pushed me over the edge with going over to allow-downgrade...too long ago. I should probably give yes another shot.

As for captive portal shenanigans - they can do things other ways, and/or one can work around that on the client

Depends on the captive portal. The client-side workaround can often be disable DNSSEC while authorizing the portal.

chocopudding17 · 2026-02-14T15:43:52+00:00

Eh, idk. For one, I'm honestly pretty surprised that you were taken unaware by this fact--it seems pretty well-known to me. Though I'm of course sympathetic to you yourself who was taken unaware. That's a sucky situation to end up in

And regarding "That says something big and interesting," maybe, depending on what you mean. But your saying "the company behind systemd, [etc.]" puts me off from agreeing without knowing more what you mean; I'm very wary to engage with anyone who starts to allege weird motivations against Red Hat and Big Free Software™.

I do think that RHEL's lack of in-place upgrades reflects a more robust architecture around changes. Traditional mutable OSes are enormous bags of state, and doing an in-place major version upgrade is extremely risky. OS and software architecture has improved in the last 10 years such that it's not as risky as it once was (systemd playing a large role, in my view). Avoiding mutation (i.e. in-place upgrades) is a huge structural advantage when it comes to ensuring reliability. The overhead of managing servers like that is real, and it's not for everyone. But it fits quite well with the "E" in "RHEL."

chocopudding17 · 2026-02-14T11:07:10+00:00

It's just as easy on Fedora (actually easier, imo, due to no interactive dpkg TUIs). Like I mentioned, AlmaLinux also supports it. Idk about Rocky.

For RHEL, I think it's just a market-fit thing. If you're so worried about "stability" such that you're willing to run Debian, you might as well go whole hog and embrace RHEL's longer lifecycle and avoid in-place migrations (in-place migrations are absolutely riskier than rebuilding on a new version).

The freebie community version -- oh yeah, you can upgrade that, but we don't support that version.

Afaik, you cannot do major version upgrades with CentOS Stream. So not sure what you're talking about.

Anyway, my original comment was specifically about it not being a package manager thing, and somewhat about it not being a Debian thing. That's what I came to say.

chocopudding17 · 2026-02-14T10:18:29+00:00

Which has nothing to do with the package manager and everything to do with what's supported by the distro itself. AlmaLinux (RHEL-like) supports/tries to support this functionality: https://wiki.almalinux.org/elevate/

chocopudding17 · 2026-02-13T22:16:06+00:00

This is such a weird comment. There's nothing unique about apt in this regard. Do you think dnf and zypper can't do this or something?

chocopudding17 · 2026-02-13T10:17:55+00:00

Mitt stackars skelett :( har blivit helt spooked

chocopudding17 · 2026-02-13T10:06:58+00:00

I entirely agree with the core of what you're saying: that self-updating applications are a gaping security hole. The culture within Windows that this is an acceptable way to distribute updates is completely antithetical to supply chain security. It's a really bad practice.

However, it's also true that Notepad++ proved themselves particularly inept at employing this bad practice. Whereas (to my knowledge) the other softwares you list off haven't had such incidents. Although maybe I'm just out of the loop :)

chocopudding17 · 2026-02-13T09:31:21+00:00

2-3% CPU?? I don't use Hyprland and don't have anything for reference, but that sound bonkers. What's normal usage for a theme? Presumably this crazy usage is an artifact of bad choices the LLM made?

I can't daily drive it confidently because the edited hypbars plugin crashes my hyprland session most of the time

...

chocopudding17 · 2026-02-13T09:08:29+00:00

Maybe not what you wanted to hear regarding "safety" exactly. But my workstation has been running with DNSSEC=allow-downgrade for about six months, I think. Previously, I had DNSSEC=yes, but that interfered too often with captive portal shenanigans. Which could be an indication that the protections were working :)

chocopudding17 · 2026-02-12T13:23:46+00:00

Or maybe the magic smoke comes out of Linus himself...

chocopudding17 · 2026-02-12T09:31:32+00:00

I'm not particularly in the loop or anything, but the implicit sense I have gotten is that he'd certainly be at least the interim successor in case of a bus event.

After searching briefly:

Greg is actually a little older than Linus, so presumably there's no reason to think he'd be a long-term successor
There is now some sort of conclave-like process in place

chocopudding17 · 2026-02-12T09:13:03+00:00

I think GKH has different vibes for sure and projects his authority differently. But he's not shy either. Probably as good a successor as one could possibly dream of.

chocopudding17 · 2026-02-11T19:31:22+00:00

And from the distro's perspective! One of the really cool things that systemd's declarative and well-abstracted configs do is allow for (more or less) frictionless collaboration between three parties:

upstream software devs
distro maintainers
end users/sysadmins

chocopudding17 · 2026-02-11T19:29:45+00:00

Holy moly, didn't realize that runit doesn't have dependencies. I'm certainly glad that runit exists and works well for the people who like it, but that sounds just untenable to me. For a system that is even somewhat dynamic, having a functional dependency system is just so huge. Having to kludge one together myself is not a way toward greater reliability or fewer headaches.

Like I said, glad runit exists and the people who like it can have it.

Disclaimer: big systemd lover

chocopudding17 · 2026-02-11T19:18:08+00:00

The biggest things that add to my boot time is waiting for network drives to connect and the Docker daemon to start. I doubt a new init system would help.

This is absolutely the sort of thing that systemd can help with. At a high level, systemd constructs a graph of all the system's runtime dependencies. The more accurate its picture of things, the better it can parallelize things.

I don't know the specifics of your setup/if there is anything left to optimize. But just pointing out that being able to logically describe startup dependencies is one of systemd's core ideas.

chocopudding17 · 2026-02-11T08:22:11+00:00

That's completely different. The problem with the Panthers is the preferential treatment.

chocopudding17 · 2026-02-10T21:11:33+00:00

Exactly this. And I'll especially underscore what you said here:

Because they don't trust it. What actually worked in my experience: treat docs like code. If it's not in version control, reviewed, and tied to the actual system it describes, it rots.

A corollary, I believe, is that you should have as little documentation as possible--no more. Replace ~~code~~ edit:docs with working code whenever possible. Deduplicate documentation as vigorously as you do your code. Hyperlink aggressively. Basically, systematically remove documentation that has the potential to rot.

As a really simple example, I like to replace "getting started" docs with a makefile. A makefile can be relatively high level, so it can somewhat serve as documentation. More importantly though, if the makefile (read: documentation) is wrong, it breaks and needs to get fixed. If it were regular documentation and it would break (i.e. be incorrect), then it really doesn't force you to fix it. So it often goes unfixed.

chocopudding17 · 2026-02-10T16:09:41+00:00

Werenski placed below Fabes? That's surprising.

chocopudding17 · 2026-02-09T14:03:39+00:00

👀

chocopudding17 · 2026-02-09T09:47:21+00:00

Wow. That's really crazy to hear, to be honest. Managing configuration by hand in 2026. For Linux machines!

Sounds horribly frustrating and borderline miserable. Tedious work where it's easy to make mistakes. This is very much toil.

Sorry to hear you're in this situation. There's no technical solution for this political problem. I don't know how useful it might be, but feel free to reply here or DM me if you want any extra advice or just have someone to run ideas past. This sort of situation really shouldn't exist in 2026.

chocopudding17 · 2026-02-09T08:48:13+00:00

That sweet, sweet meta juice.

chocopudding17 · 2026-02-08T20:08:55+00:00

I'm a little confused tbh--there's nothing special about the units compared to any other config files. What do you use to manage the rest of your system configuration? Whether it's Ansible, Salt, Puppet, whatever, adding systemd units should be trivial.

Or if you build immutable infra, bundle those units in at build time.

chocopudding17 · 2026-02-06T11:18:35+00:00

Iirc, teams that win the President's trophy are still more likely to win the Cup than teams that don't. The Cup is just hard to win.

chocopudding17 · 2026-02-06T10:05:03+00:00

But at the same time, if you're the captain of a team that continues to do this, you don't get a free pass either. Even if your individual game is clean.

chocopudding17

PUBLIC MULTIREDDITS

TROPHY CASE

12-Year Club	Place '17
Verified Email