Kogasa

Why would you do that

sparkling arch, sparkling fedora, and diet arch

Arch teaches you to exercise muscles that would otherwise atrophy. Understanding how your system is put together, how to diagnose and fix problems, how to handle upgrades safely. It becomes just as easy as any other OS and you’re better off for it.

That doesn’t follow. What I think you mean is that by defining the constraints so rigorously, you’ve basically solved the problem yourself. But that’s exactly the point. The LLM isn’t the problem solver, it’s the execution engine that does the wiring-up and the ticking of boxes. The easy part, arguably, sure. But still considerable effort that can be saved, and that effort may be better spent on the problem-solving + constraint-defining stage.

Mandatory disclaimer that this is not a pro-AI post. I also don’t agree that this setup works, anyway. It’s a classic Bob Martinism, the idea that writing good enough specifications makes the implementation irrelevant; it’s the type of idea that is allergic to reality

It would be trivial to add online only drm with a killswitch to physical media. If that’s the problem, discs aren’t the solution. What we actually need is legal protection for consumers.

Nothing, bias from the .NET Framework days probably

Using aur helpers is fine if they make it easy to read the pkgbuild, which paru does. It’s too annoying to check for PKGBUILD and upstream/vcs updates for each package individually.

Ideally the aur helper would point out when 1) a package changed maintainers since your last install, 2) a package’s PKGBUILD itself changed (not just the upstream/vcs source), 3) the PKGBUILD is less than 24h old or so. And for #2, it should also show you the changes similar to what you see on the AUR site’s “view changes” page. I’m not aware of any aur helper that does these things, but hopefully recent events prompt a change.

Not who you asked, but I want to shill for spaghetti aglio e olio for a sec.

It has 3 ingredients. Pasta, olive oil, garlic. Fancy stuff will taste better, but the cheapest will taste fine. I use pre-minced garlic out of a tub when I’m really down bad and it’s still excellent. Salt, pepper, red pepper flakes, maybe parmesan cheese if you have it, and sometimes I’ll throw in some frozen peas. It comes together in about 2 minutes longer than it takes to boil the pasta and can be really quite good.

Haven’t really looked into it. I have Jellyfin set up and ready to switch over already. Maybe I’ll check it out when Plex blows up

They have a sorta proprietary metadata service that is presumably based on imdb, thetvdb, etc. but they also handle detection and collection of metadata regardless of where the information ultimately comes from. It’s nothing that Jellyfin doesn’t do though.

I’m sticking with Plex since I have the lifetime pass too, but the writing’s on the wall, I’m ready to switch to Jellyfin whenever Plex dies or ruins itself

They provide the apps, metadata servers, and relay service. It’s a lifetime pass. IMO that’s worth the price it used to be, $70 or whatever. The new price is just absurd, they want you to pay periodically for life because people spend more that way.

Just change your name to Gimp.

I don’t support the change. That’s not my point. My point is that if we’re going to argue the dev being threatened isn’t a victim because he’s actively harming privacy, we should be aware that the changes he proposed are not actually harming privacy at all.

Age verification laws: slippery slope. Sure. I agree.

Adding optional age field to systemd userdb: not slippery. Systemd isn’t being weaponized as an age verification suite. It’s just not happening.

You don’t, and you don’t have to fill them in with accurate information, so it isn’t.

It’s mostly not going to be used at all.

As I said, I also object, but you have to realize you’re literally just doing the slippery slope meme unironically. The part that makes it a fallacy is the unjustified assertion that more egregious changes are the inevitable result of the first one, except the first one is materially harmless and in line with existing PII fields in userdb. It’s completely reasonable to expect systemd to go no further than it already has.

No, it literally just can’t violate your privacy in any way. You have complete control over what, if anything, is placed in that field. No information about you can be gained or disclosed by virtue of the systemd change alone. You can think it’s a bad change because it signals intent to follow a trend of supporting privacy-invading age verification, but you can’t say this specific change in itself is privacy-invading.

“user is likely accessing service from a *nix device” isn’t PII. of course anything can be used for fingerprinting, but this type of “leak” is about as insignificant as it gets. It’s not what most people would consider a violation of their privacy.

It may be inconsequential in a literal sense if the law isn’t enforced meaningfully, which is probably pretty likely. I don’t really care what California law says and I doubt they’ll try to convince me.