chameleon

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.

Pantry lists and other similar “reverse shopping lists” (fridge/freezer, shower cabinet, medicine cabinet, emergency/comfort food stockpile). I cross-check them with my actual inventory and shopping list once a month and in the 6 years I’ve been doing that, I think there’s only been like two months where I actually had everything.

They’ve been flagging physical carts showing up in multiple places at the same time since the very moment the first Switch flashcart appeared (so likely before we ever had our hands on any). Places discussing the flashcart had been talking about increased detection and bans for a year or so.

It was even done on the 3DS before that. The 3DS had a whole tiny niche ecosystem of people selling “private headers”, dumping only the unique per cartridge info and selling it with the promise that they’d only sell any given header to one person. That too had a few instances of normal people complaining about bans with pre-owned games.

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).

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.

On the other hand, Wikipedia doesn’t allow original research and discourages primary sources while that’s very much part of what a journalist is expected to do; they write the secondary sources Wikipedia runs on. It’s a much harder job to discover and vet primary sources.

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.

There’s no 100% indicator, but presence/non-presence of a contributor license agreement that gives them the rights to distribute under any license is the best one I’ve found. Corporate backed FOSS where they want the option to turn into non-FOSS “just in case” means that will inevitably happen after people are locked in. Best place to look for one is the project’s documentation on how to contribute/how to send pull requests.

Stuff licensed under BSD/MIT style permissive licenses don’t need a CLA to go proprietary, but the ones that do tend to have a CLA anyway.

“CLAs” that are just an sign-off (developer certificate of origin like used by the kernel) are fine and are also treated as a CLA every so often, but the moment you see anything about giving one specific company a “perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license” or the like, run for the hills.

The email ecosystem is changing in recent years but yeah, it’s best to expect that there is at least one opportunity for any given email to be sent over the internet unencrypted. MTA-STS has been slowly changing the landscape but adoption isn’t going all that great.

Most paid certs aren’t worth much anyway. Payment and delivery info for DV certs isn’t validated by anyone, it’s literally the same concept as Let’s Encrypt. OV and EV are the only ones that theoretically have any value, but nobody is using those ever since they got rid of the URL bar labeling; even Amazon is on DV nowadays.

The main reason many sub-communities are stuck on Telegram (and Discord) are the public group chat/broadcast channel related features. Signal still has a 1000 member group size limit, which is more than enough for a “group DM” but mostly useless for groups with publicly posted invite links. Those same groups would also much rather have functional scrollback/search on join instead of encryption.

Gonna add a dissenting “maybe but not really”. YT is really aggressive on this kinda stuff lately and the situation is changing month by month. YT has multiple ways of flagging your IP as potentially problematic and as soon as you get flagged you’re going to end up having to run quite an annoying mess of scripts that may or may not last in the long term. There’s some instructions in a stickied issue on the Invidious repo.

It’s absolutely not the case that nobody was thinking about computer power use. The Energy Star program had been around for around 15 years at that point and even had an EU-US agreement, and that was sitting alongside the EU’s own energy program. Getting an 80Plus-certified power supply was already common advice to anyone custom-building a PC which was by far the primary group of users doing Bitcoin mining before it had any kind of mainstream attention. And the original Bitcoin PDF includes the phrase “In our case, it is CPU time and electricity that is expended.”, despite not going in-depth (it doesn’t go in-depth on anything).

The late 00s weren’t the late 90s where the most common OS in use did not support CPU idle without third party tooling hacking it in.

Pretty much every form of these scams is some kind of advance fee fraud. Two more possible avenues:

• “Upgrade to a business account”. They send you an email purporting to be from the payment provider you used saying you need to upgrade to business to receive a payment that large, and the upgrade page is a fake website run by the scammer that asks for a “refundable deposit” or the like (with a little helping of credit card fraud and of course a business account will require all kinds of personal info useful for identity theft too).
• “But I want it as an NFT” was popular for a bit, they want you to “pre-pay the minting fee but it’s ok I’ll add it to your payment” and then they disappear. But they want it on a website ran by them and the moment you put the crypto in they disappear. Not sure this scam is popular nowadays because NFT screams scam to just about everyone for a lot of different reasons. But “rich guy spends $5000 on dumbass NFT” was a legitimate genre of news for a little moment.

It’s all preying on someone that thinks they got an easy paycheck for work that they’ve already done, on a populace of artists that could really use said paycheck to pay for food and are thus willing to overlook weirdness or principles. They also tend to pick on newer and younger artists that haven’t quite figured out how to run a business yet, hoping that they haven’t heard of scams specifically targeted to their sector.

Requiring agreement to some unspecified ever-changing terms of service in order to use the product you just bought, especially when use of such products is required in the modern world. Google and Apple in particular are more or less able to trivially deny any non-technical person access to smartphones and many things associated with them like access to mobile banking. Microsoft is heading that way with Windows requiring MS accounts, too, though they’re not completely there yet.

Personally, I do believe that rootless Docker/Podman have a strong enough security boundary for personal/individual self-hosting where you have decent trust in the software you’re running. Linux privilege escalation and container escape exploits fetch decent amounts of money on the exploit market, and nobody’s gonna waste them on some people running software ending in *arr when Zerodium will pay five figures for a local privilege escalation or container escape. If you’re running a business or you might be targeted for whatever reason (journalist or whatever) then that doesn’t apply.

If you want more security, there are container runtimes that do cooler security stuff under the hood, like Firecracker/Kata Containers implementing a managed VM, or Google’s gVisor which very strongly intercepts kernel syscalls and essentially reimplements Linux in userspace. Those are used by AWS and Google Cloud respectively. You can integrate those into Docker, though not all networking/etc options are supported.