i’m lizard
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.
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.
There are both dumps with full history and ones that are just the current set of articles. The full dump happens once a month on the 1st, but will often take ~2 weeks to run to completion, so you probably have to look back to the April 1 2025 dump for those. The metawiki dumps page has all the info.
Windows prefers to deactivate or minimize the write cache on removable devices, most of the common Linux distros generally don’t make such changes. Microsoft has a very good reason for that default: not a lot of people actually use the “safely remove hardware” option and if the cache is enabled, using and waiting for that is a hard requirement for the data to have actually made its way onto the drive.
Github: https://github.com/suitenumerique/docs
Self-hostable, but it seems like an absolute behemoth of an application if their “non-production-use-only” docker-compose file is to be believed, and I couldn’t find any production-ready deployment instructions on a quick skim. No obvious signs of federation and I didn’t see anything on their roadmap, not sure it would make a lot of sense for this though.
Gives them excuses to punish “weird”/non-perfectly-conforming kids. The definition of the actual law is broad and open to more or less any interpretation you want it to have.
Borg or the like with ‘hardcoded’ plaintext/regularly full-disk-encrypted key is acceptable. Someone that has your unencrypted private key sitting on your server has almost certainly already obtained access to the entire set of data you’re backing up, with the backup key itself only meaningfully guarding access to older backups.
The more important thing is to securely keep extra copies in case the server fails. I keep mine in a group in my password manager, one per repo.
The good stuff is usually hidden in low view hell (or in text form, stuck on personal blogs nobody reads). Getting an audience is mostly a property of marketing, not quality. There’s not a lot of natural overlap between those that can teach well and those that can market well.
(It’s a joke/reference, I guess it’s not 100% known though. My bad.)
I really do hate “I know what I have so you are going to pay whatever number I set” capitalism though, which is what they do here. These registrars figured out a loophole around the redemption grace period and are, from the start, set up to make you lose the domain and then spend significant money on a completely unfair auction where they have the power to plant fake bids, rather than paying the usual static redemption fees that aren’t that excessive.
Heartbreaking: The Worst Capitalist Practice You Know Just Accidentally Picked A Funny Target
You go to the settings and verify it. You don’t have to host anything, just verify that you own the domain via text file or DNS record and choose to set it as your handle. Bluesky’s ATProto has a couple extra layers of indirection and it’s very easy to get a custom handle as a result.
The downside of this setup is that running your own complete network is completely impossible. If you want to follow theonion.com, anyone can find did:plc:a4pqq234yw7fqbddawjo7y35 in the DNS without too much work. That’s the identifier for The Onion’s Bluesky account, and even if they swapped back to .bsky.social, that ID number would stay. But that DID tells you absolutely nothing about where the data is currently hosted.
So how do you figure that out? Well, you register it with https://plc.directory/ which is ran by Bluesky and cannot currently be replaced. There’s fancy cryptography involved that makes it hard for them to spoof data, but they are perfectly capable of simply not giving any data out for any given DID.
I don’t have Obsidian around, but this has been happening elsewhere lately too, almost certainly because of this underlying Electron issue: https://github.com/electron/electron/issues/43819
Unfortunately there’s not much you can do about it. Electron decided to depend on functionality not yet in a released version, and that very interesting choice flows down to everything that updates their Electron on the regular.
Sorry, I’ve had a (self-imposed) busy week, but I have to admit, that also has me rather stumped. As far as I can tell, your second entry should work. If the device is visible in /dev/mapper under a name, it should be able to mount under that name.
The only thing I can think of is that some important module like the ext4 module might be missing somehow? You can get pretty confusing errors when that happens. Dracut is supposed to parse /etc/fstab for everything needed to boot, and maybe that’s not recognizing your root for some reason. dmesg might have some useful info at the end after you try to mount it. If that’s what’s happening, you could try to add add_drivers+=" ext4 " in your dracut.conf and regenerate it (the spaces are important!). But if that’s not it, then I’m probably out of ideas now.
All true, wanted to add on to this:
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:
:roor 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.