I was going to try ripping a Blu-ray that I bought recently, since I couldn’t find a quality rip anywhere

I don’t have first-hand experience, but I’ve heard that the linux version of MakeMKV does work; though I’ve seen some issues reported in the forum. MakeMKV is even available on nixpkgs.

I don’t know about MicroSD longevity, but I’ve heard BluRay and in particular M-Disc can last 100-1000 years of something crazy. So for archive, it might still be a good option.

I really hope streaming doesn’t become the only option, because even with >1Gbps internet, streaming services generally do not deliver as good of quality as I can get from something like a bluray. Even HBO and Netflix have very noticeable lossy compression.

I’ll give it a read! I wouldn’t have expected much relevant info on the Arch Wiki.

Got it, thanks for the correction. I had never heard of Pioneer before; I must’ve misinterpreted what I was reading on the forums.

Have a link?

Thank you! I found it on Anna’s Archive.

Sadly it didn’t have this one :(

Pretty sure the store requires that you provide a Japanese phone number. That’s where it was complaining for me.

Doesn’t that violate rule #3?

Less than $100 is tricky, but I’ve been meeting all your criteria with a Beelink EQ14. I also use it as my router.

Probably won’t solve all of your problems, but I like to at least change git’s default pager to delta.

I agree with the article’s ideas, but certain things about the execution bother me.

1. calculate_order_total_for_customer. I’d just call it calculate_order_total. It’s clear than any order will have a customer, it’s in the type signature.
2. is_user_eligible_for_discount. I’d call it user_is_eligible_for_discount. Because inevitably that function is getting called in an if statement, and you’d rather it read closer to proper English: if user_is_eligible_for_discount: ....
3. “Designing for Tomorrow”. I agree that dependency injection is a valuable technique, but it’s not always strictly necessary and they seem to say you might as well always do it just in case. That’s counter to YAGNI. Make sure you have an immediate use case, or let future you do it if you end up needing it. It’s not hard to refactor something to inject a dependency.

As for actual coding, I use ChatGPT sometimes to write SDK glue boilerplate or learn about API semantics. For this kind of stuff it can be much more productive than scanning API docs trying to piece together how to write something simple. Like for example, writing a function to check if an S3 bucket is publicly accessible. That would have taken me a lot longer without ChatGPT.

In short: it basically replaced google and stack overflow in my workflow, at least as my first information source. I still have to fall back to a real search engine sometimes.

I do not give LLMs access to my source code tree.

Sometimes I’ll use it for ideas on how to write specific SQL queries, but I’ve found you have to be extremely careful with this use case because ChatGPT hallucinates some pretty bad SQL sometimes.

If your health check is broken, then you might not notice that a service is down and you’ll fail to deploy a replacement. Or the opposite, and you end up constantly replacing it, creating a “flapping” service.

Is your issue that it’s hard to move files around without breaking seeding, or something else?

An issue which I aim to resolve using a self-hosted VPN.

Pretty much everyone I’ve talked to about this says the same thing. LLMs are useful for one-off scripts or quickly generating boilerplate. It just turns out that those tasks don’t make up the majority of programming work unless you are in a bullshit job anyway.

We aren’t yet great at knowing when LLM will save time and when it will inflate time.