I am running my entire homelab from podman quadlets (systemd managed podman containers) and it’s honestly very dope. Podman gets a bad rap for being second tier to docker but they legit have a bunch of awesome features for Linux users specifically that make it way nicer. Using systemd for docker status can add some misdirection occasionally, but having the logs from containers directly in journalctl alongside the rest of my system logs is amazing

Fair! I’m not giving enough credit to the fact that some applications don’t really have another option than to run root for some dependencies

I know it’s not the issue here really but

the container runs as root

That’s why we need to push for more self hosted containers to support running rootless. There’s no reason for it other than laziness IMHO.

It’s wild to me how many people will jump through a bunch of other random security hoops but not blink an eye about running containers as root

This thread just reminded me to cancel mine. Good riddance IMHO. I should’ve done it back when they started spamming me with “quests” (aka ads) for Amazon and random fucking gatcha games. Between the privacy stuff and the pressure to monetize, there’s next to no way it’s gonna get better.

If you want Fedora atomic Niri, use https://github.com/zirconium-dev/zirconium

I’m not even a proton user anymore, for several reasons including the politics of the founder.

It’s possible to be correct and also a dickhead, as evidenced by the way nanook is behaving in this thread.

People are downvoting you because you’re being an ass, don’t give yourself too much credit

Just recently switched to Niri myself - I think the fact that Niri inherits a lot from Smithay for compositior stuff really helps. It’s the same compositor base that cosmic DE uses. Sure hyprland has HDR at present and Niri doesn’t, but I think it helps a lot to not build a compositor and a TWM at the same time. vaxry is honestly just doing way too much and it’s unsustainable and new version blow ups like this were inevitable given how big the install base has become and how huge hyprland feature set has gotten

Idk about that, Gabe did a bunch of interviews around the time of windows 8 saying that signed app requirements and the windows store fiat that MS was trying to implement was an “existential threat” to valve and that they needed to migrate to a neutral OS as much as possible.

I’d argue that what we’re seeing now from valve is the fruits of a 10+ year campaign to undermine windows. And MS has been digging their own trench undermining windows at the same time, making their job even easier lol

But idk if it’s fair to call what valve is doing as “don’t worry about the competition” - I just think they (accurately) view MS as their competition instead of epic or EA or whoever is trying to do pc game stores

Thank you!

Cool but you are actually wrong. I’m not even the first guy you were arguing with. It works you’re just bad at computer and that’s OK

No u

You said “no screen sharing software works on it”. If “it” is anything other than your POS laptop, then you’re a fucking liar

What you said is literally incorrect. There are screen sharing applications that work on Wayland. I just used one ten minutes ago.

Did you actually read the link? The study basically attributes all of the negative effects to the change and not specifically standard time or daylight saving time, so I think what that means is DST is no more or less good for people than standard time. The switching is the part that is harmful.

In what way? Healthiness of a time standardization seems like it would be hard to validate. I personally prefer DST I’ve never considered either healthier or unhealthier. I remember hearing statistics about an abnormal number of car accidents and stuff happening the Monday after DST/ST changes. I’ve also heard some rhetoric about risk of car accidents with kids walking to bus or school being mitigated by standard time.

I’m assuming you mean something less acute than those which are focused on immediate outcomes like death lol? The only thing health related I can think of is daylight exposure and vitamin d levels, but it seems inconsistent whether people are more likely to take advantage of extra morning sunlight or evening sunlight. Seems like it would be a wash?

Anyway, I’m legitimately interested to know what you mean by “healthy”

Childbirth seems decidedly not chill. Maybe women just want to chill

Many GraphQL and gRPC APIs do exactly that and return HTTP 200 even if the request didn’t auth.

Just because you are heavily biased toward using HTTP status for application layer errors doesn’t make it right. It is so wildly common that people can’t imagine it working another way, and I get that.

But it’s not “wrong” to do application layer auth status codes and apply no transport layer auth status codes It’s just a different paradigm than most devs are used to.

What do you mean? You can literally run GraphQL without HTTP. This isn’t just a GraphQL-ism, gRPC also does it https://grpc.io/docs/guides/status-codes/

I understand that most people use GraphQL over HTTP and that from a developer perspective you’d rather have HTTP status codes like every other REST API. To which I’d say, why don’t you just use REST instead?

There are a bunch of legitimate reasons why a clean separation of transport layer and application layer makes sense - you just aren’t using them so it feels like an arbitrary frustration to you.

Have you ever run an application like a golang REST API behind an envoy or nginx proxy or load balancer and gotten an HTTP status 500 back and wrongly assumed it was coming from your application/golang code, only to later find it was a problem at the proxy or load balancer? If so, you’ve experienced the misdirection of combining transport and application layer being forced to share a status field. This isn’t a trivial example - time is wasted every day by developers misdiagnosing errors originating from transport as application errors, and vice versa.

You might not like it, but separating them IS smart design.

That’s true, but for a good reason. GraphQL is transport agnostic, so using HTTP status to represent errors doesn’t make sense. HTTP is just a carrier for GraphQL, and the status code represents whether or not the HTTP part was successful.