If you don’t already know the benefits it’s unlikely it solves a problem you have.

Even among its users many are using it because it’s cool rather than because they actually need it.

It’s a declarative system, meaning you can describe how it should be setup (using a magic strings you have to look up online) and then it “sets up itself” according to the description.

It’s normally something you’d use for mass and/or repetitive deployments.

It’s usefulness for a single system is debatable, considering you can achieve very close to 100% of “reproducibility” anyway by copying /home and /etc and fetching a copy of the package list.

Where the prescriptive approach is supposed to help is when you attempt to reproduce the system a long time later, after things like config files and packages have changed. But it doesn’t help with /home, it hasn’t been tested over long intervals, and in fact nobody guarantees long term compatibility for Nix state.

If someone gets access they can delete your keys, or set up something that can intercept your keys in other ways.

The security of data at rest is just one piece of the puzzle. In many systems the access to the data is considered much more important than whether the data itself is encrypted in one particular scenario.

Now replace “signal” in your comment with “ssh” and think it over.

If any part of the data gets corrupted you lose the whole thing. Recovery tools can’t work with partially corrupted encrypted data.

You. Don’t. Store. Secrets. In. Plaintext.

SSH stores the secret keys in plaintext too. In a home dir accessible only by the owning user.

I won’t speak about Windows but on Linux and other Unix systems the presumption is that if your home dir is compromised you’re fucked anyway. Effort should be spent on actually protecting access to the home personal files not on security theater.

Oh no, tell that to SSH.

The AUR is basically just a script that describes best case scenario for building something under Arch. They don’t have any specific quality rules they have to meet.

It’s super easy to make and publish an AUR script compared to a regular distro package (including Arch packages).

The ads are added in the app. If you cast, the Chromecast can’t add apps (yet) so they’d have to make ad streams instead, and switch between the streams show-ad-show which would take several seconds of loading screen each way and so on. Which is a level of fuckery even they shied away from.

TLDR they can’t (easily) show ads during casting.

No, unfortunately. 🙂 They’re not talking about secure paths inside the office, they’re taking about having all their processes using the floppy disks. They have a common format which is proprietary and can only be made with a proprietary PC program and can only be submitted on floppy disks.

Sure, but forcing an entire country to go through physical handling of each and every request is crazy. I really don’t understand how they managed for so long.

Would be rather short-sided of them. They rely on the free tier of their services for upscaling and word of mouth. People are already wary of the fact CF can snoop on what’s supposed to be private connections, but so far they’ve used that only for good.

Spending 20k to unchain yourself from a clearly ill-meaning vendor can be seen as a good investment in itself. 5k saved in (recurring) fees is a bonus.

What would they use Word for? This is about submitting data in their own standard formats in tiny files.

The real crime is that they’re not switching to online. Using optical discs is going to be even more ridiculous for those tiny files.

Why do you want to use Shouko? Yeah it can bulk-tag anime but it doesn’t necessarily do a better job than Jellyfin with AniDB plugin. Also, it tends to hammer their API like an idiot and will get your user temp-banned or even perma-banned (depending on the size of your collection), while the Jellyfin plugin has rate limits.

I used it once when I was moving my collection to Jellyfin and I barely got my account back.

I would strongly suggest using just the regular Jellyfin plugins and adding titles to the directory in small batches and taking breaks if it stops recognizing them because it means the API is throttling you.

Yeah that’s about what I had figured too, 400-600 kWh/mo per house during summer. Double that is more likely to be estimated capacity rather than actual use.

It’s obviously someone who forgot their gmail password and is trying a bunch of words to see if they remember it.

Um, why does the average Chinese home consume 1 MWh/mo? Or do they mean the battery capacity would account for one home consuming up to 1 MWh?

Many people have a warped understanding of what “two factor” means.

They conflate it with devices and they think it means that one of the factors (why one? which one? who knows) needs to be restricted to exactly one device.

What “two factor” really means is that you should have more than one required factor of authentication so that if one is compromised the attackers still can’t get in.

Ideally the factors should be spread across the “something you know” / “something you own” / “something you are” categories to complicate the manner in which they can be compromised.

We can only reliably rememeber a limited amount of passwords, so like it or not we have to use some devices at least some of the time.

The trouble with “something you own” is that it can be lost or damaged or stolen, and if you only have one of it then you’re fucked. So adding some redundancy is not a bad idea.

The larger issue is that everybody is stuck into extremely rigid and outdated mindsets that date back decades. “Two factors” don’t have to be exactly two, and they don’t have to include exactly one password, and so on. It should be fine if you wanted to secure your account with 3 passwords, and should be up to you if one of those password is a barcode tattooed on your taint so you need a mirror and to bend upside down to scan it.

Bottom line, use whatever you want and use your best judgment as to how secure is each factor. If you want to use something that syncs to multiple devices, go ahead. What you should consider is who has access to those devices and how it would affect you if they’re lost or stolen.

This whole debacle is a festival of stupidity:

• It’s a personal project that taxes the sole maintainer disproportionately.
• Millions of idiots use it blindly and end up building elaborate software on it. https://xkcd.com/2347/
• I’ll bet you 99.99% of those idiots use it only for ip.isPrivate(), which you can write yourself in 5 minutes.
• The CVE is a non-issue (who the fuck would call a function that takes string notation with hex numbers?)
• Appealing and reverting or downgrading CVEs is super complicated.

At this point the maintainer is fucked no matter what they do, so archiving the project and telling everybody to fuck off right back was really the only sane thing to do.