chameleon

There aren’t a lot that work well with Space Age, because overhauls are generally incompatible in terms of gameplay/balancing and Space Age itself is essentially an overhaul. Most new mods made for the Space Age era are new planets instead of overhauls, there’s Loup’s Guide to the Galaxy if you want some community-curated advice on what’s decent vs not worth the time (not a mod but it lives on the mod portal anyway).

But if you really want it, there’s a Krastorio 2 fork called Krastorio 2 Spaced Out that integrates Space Age. I think it’s about the best it can be, which is to say, I’m not a big fan of it but other people seem to like it. Nauvis is pretty much just vanilla K2 with new rocket silos while the other planets are slightly janky Space Age.

Not sure, but I can reproduce it on my end. The actual download pages on get.videolan.org have ads, the main site does not.

I’ve seen the claim around but I’m highly skeptical of it. DDR5 is far too slow for anything where memory bandwidth really matters, any newly produced chip that’s gonna be used for AI is on HBM3 or HBM3e, or possibly GDDR6/GDDR7 if it’s a GPU pulled from the consumer segment. HBM5 is still a very, very early research project and is certainly not being produced yet.

The idea is interesting, but $13/month for one ‘mystery’ album from an artist you (most likely) don’t know feels rather up there.

root= isn’t correct for booting a live image like this. You need to use some specific parameters to guide the initramfs to where it can find the /boot/x86_64/airootfs.sfs file, and in general, something like that will be the case for most distros but there are lots of unique mechanisms. Looking at the grub.cfg, /loader/entries or similar files will usually get you some things you can put into your favorite search engine to hopefully find some documentation. For Arch it’s part of mkinitcpio-archiso: https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/blob/master/docs/README.bootparams?ref_type=heads

I don’t have a setup to test it but if If I’m not mistaken something like this should work:

options  "archisosearchuuid=2025-08-01-13-39-26-00"

These containers are/were for self-hosting. VMWare previously owned Bitnami, it was their attempt to make it easier to self-host rather than paying a cloud provider, which should directly benefit them because VMWare got its money from businesses that self-host + self-host people growing up learning free homelab ESXi and wanting to apply that at work. It helps a lot if there’s well-maintained solutions for deploying popular stuff.

Then Broadcom bought VMWare for a ridiculous price and is doing none of that.

Tends to change by playthrough but 50% water scale/150% water coverage/~200% resource frequency+size+richness is my go-to. Creates lots of natural chokepoints, available resources end up feeling like they’re similar to default map settings, gives you enough area to build a reasonable bus starter base at the start but eventually pushes towards a more train spaghetti playstyle.

scripts mix configuration with logic and this was a big reason why a lot of distributions switched to systemd in the first place

What was really wrong with the old BSD-style rc/init systems is that they mixed configuration with the logic required to start/stop the service at all, and that that logic was running in the same session it was being executed from (inheriting the environment, FDs and the like). These daemontools-style supervisors don’t have that problem, the run script is essentially just systemd’s ExecStart= and it gets forked off from the supervisor itself and is then managed by it. Lots of them are just #!/bin/sh \n exec coolservice.

There’s plenty more things that systemd does pretty well that this doesn’t do (dependency management seems to be sorely lacking here in particular), but this kind of approach is much closer to it than the old rc scripts.

All true, wanted to add on to this:

Note that smart peeps say that the docker socket is not safe as read-only.

That’s true, and it’s not just something mildly imperfect, read-only straight up does nothing. For connecting to a socket, Linux ignores read-only mount state and only checks write permission on the socket itself. Read-only would only make it impossible to make a new socket there. Once you do have a connection, that connection can write anything it wants to it. Traefik and other “read-only” uses still have to send GET queries for the data they need, so that’s happening for legitimate use cases too.

If you really need a “GET-only” Docker socket, it has to be done with some other kind of mechanism, and frankly the options aren’t very good. Docker has authorization plugins that seem like too much of a headache to set up, and proxies don’t seem very good to me either.

Or TLDR: :ro or stripping off permission bits doesn’t do anything aside from potentially break all uses for the socket. If it can connect at all, it’s root-equivalent or has all privileges of your rootless user, unless you took other steps. That might or might not be a massive problem for your setup, but it is something you should know when doing it.

The modern breed of CAPTCHAs is mostly only trying to verify that it’s a full-fat browser. undetected-chromedriver, camoufox, pydoll, patchright and a million other libraries/tools exist. Nothing’s perfect and it’s a cat & mouse game, but this single incident is a sample size of one as well.

https://ec.europa.eu/commission/presscorner/detail/en/ip_25_1339

Everything regarding enforcement is early stages but what they’re aiming for is much more specific than chat control and is based on existing wording in the Digital Services Act.

Then it can’t be booted with new media. Microsoft has been very, very slow with the automatic rollout of their own key updates, and made just about no progress over the past two years. It’s been manual updates + newly produced systems only.

The trick here is that they have a key-exchange-key that can be used to update the other keys. That doesn’t expire (or rather, not in a meaningful way). But, a Windows image is still only going to boot on a system that trusts the key that was used for it. If you make a Windows image on a 2011 system now, it’s going to be signed with the 2011 key, and it won’t boot on a system that distrusts that key. The same is true in reverse.

Their key update documentation is all available and some enterprises have been on the new key for a while, but it’s a lot of manual work and a lot of problems have popped up, most documented in there. How they’re going to roll this out automatically to normal users isn’t obvious to me. There’s technically nothing stopping a system from trusting both the 2011 and 2023 keys, and I wouldn’t be entirely surprised if they end up never pushing the 2011 revocation.

The keys they use for their own OS don’t truly expire until late 2026, and I expect they’ll do their best to delay it until then, but the next time they have to update their boot manager is going to be painful and introduce all kinds of new problems.

There’s a disclaimer in the readme: https://github.com/juanfont/headscale/?tab=readme-ov-file#disclaimer

The maintainer Tailscale contributes happens to be the lead developer by commit count at the moment.

They also had a major ass security issue that a security company should not be able to get away with the other day: assuming everyone with access to an email domain trusts each other unless it’s a known-to-them freemail address. And it was by design “to reduce friction”.

I don’t think a security company where an intentional decision like that can pass through design, development and review can make security products that are fit for purpose. This extends to their published client tooling as used by Headscale, and to some extent the Headscale maintainer hours contributed by Tailscale (which are significant and probably also the first thing to go if the company falls down the usual IPO enshittification).

I haven’t seen proper reporting but the Play Integrity install source thing is accurate. There’s a reasonably good overview straight from the devil himself.

Lots of things that have very valid reasons on paper that also just happen to give Google a stupid amount of control and will backfire for a somewhat small percentage of people in very bad ways. We’ve been at “you can’t use pretty much any bank unless you agree to either Google or Apple terms” for quite some years now, now we’re giving those same app developers ways to detect if their device has accessibility APIs enabled (useful to protect against bot farms, but also a functional check for “you’re able-bodied”) or is in security support (also a functional check for “not reliant on hand-me-downs”).

Not them but between those two I’d recommend Kanboard if you’re going to be the only user. Far lighter and easier to administer piece of kit, has everything you’d want from a fancy task list but not much more. WeKan is rather heavy software but does have a few features that are probably quite important for large team use.

PUID is indeed handled inside the container itself, it’ll run a container-provided script as whatever the container’s UID 0 happens to be first which then drops to whatever $PUID happens to be inside the container. user= is enforced by Podman itself before the container starts, but Podman will still run as root in that setup. That means Podman is running “rootful”, while if you started the container manually as $uid using the regular Podman CLI, it would be “rootless”. That is a major difference in a lot of respects, including security, and you can find quite a bit of documentation on the differences between those operating modes online; it wouldn’t fit in a comment. Rootless is generally considered the better mode, though there are some things that still require a rootful container.

In the upcoming NixOS 25.05 or current unstable, there are some tools you can use to run containers rootless as another user more easily using a new $name.podman.user = ""; setting. From what I understand they’ll still be root-managed systemd system services that require sudo to operate, but that means privileges get dropped by systemd before running Podman, instead of dropped by Podman before running the container. This stuff is recent and I haven’t used it, I just happen to know it exists, relevant nixpkgs commit if you wanna dig into it yourself: https://github.com/NixOS/nixpkgs/commit/7d443d378b07ad55686e9ba68faf16802c030025

FWIW, your domain will most likely eventually get used by spammers and then it’ll be an endless string of somewhat expected but unpredictable failures from there on onwards, with no actions you can take to reduce it. It’s good to keep an eye on what comes in but I wouldn’t invest too much effort into failure alerting.

My crappy electric Philips toothbrush from the internet of shit era. If you press the single button it has slightly wrong it goes into some Bluetooth pairing mode or whatever that you can’t take it out of until it gives up 2 minutes later.

It’s the usual combination of AGPL + CLA, they’re allowed to relicense to any license of their choice at any moment. They’ve had the CLA in place since the previous SSPL license and the more-previous BSD license naturally allows that kind of stuff.