It has been getting so bad that even boring regular phone trees will hang up on you if you insist on talking to a human. If it’s ISP / cellular, nowadays I will typically just say I want to cancel my account, and then have cancellations route me to the correct department.

Yeah /u/deadbeef@lemmy.nz kind of understated the problem. They were seeing insane failure rates in data centers like 50%. At this point, any 13th or 14th gen CPU that has experienced any crash or instability should be considered faulty unless you know the cause of the crash is from something else. This isn’t just me saying this, mainstream outlets like Gamers Nexus are saying it.

If you’re a consumer and have one of those CPUs a replacement is probably in your future. And I wonder if Intel even has stock to replace that many at once…

I can’t think of anything like this ever happening on this scale before in computing history.

It was already settled long ago by the Supreme Court, but evangelicals are trying to use private action as a way around it, and I bet they’re hoping that one of several current lawsuits makes its way up to our new and corrupt court.

Oxidation in the fab process. They have simultaneously claimed that oxidation isn’t causing any issues, and that it’s caused only “some” crashing issues. Because they’ve been so wishy washy, it’s probably safe to assume that any 13th or 14th gen CPU that experiences any kind of crash or BSOD is degraded and should be RMA’ed immediately, otherwise you risk getting stuck with a permanently physically degraded CPU.

Intel says they identified the issue sometime in 2023 and fixed the fab process. So the good news is that any newly manufactured Raptor Lake CPU shouldn’t have this issue. The bad news is that Intel won’t give a date range of when the fab issue occurred, or exactly what CPUs it affected (by date code), so really the only choice consumers have at this point (before we get to the inevitable class action lawsuit) is to RMA at the slightest sign of instability.

Intel is also planning to release a microcode update in August, but there’s a lot of doubt that this can be fixed via microcode.

This was affecting 50% of Raptor Lake CPUs in data centers, and it’s become clear via video game telemetry that it has also affected a significant number of consumer chips.

https://youtu.be/OVdmK1UGzGs

Extension library for Tachiyomi forks. No idea if it works with Aniyomi.

https://github.com/keiyoushi/extensions

At least they didn’t hit keiyoushi.

LineageOS has been doing this for a year or so already.

I wonder if it has to do with reusing the transmission lines from the coal plant.

AUR tends to work really well for me. There are binary packages for almost every software that I use. Things do go wrong occasionally, but when they do it’s almost always solvable. AUR packages are just scripts, so you can go and fix the problem yourself and then tell the maintainer how you did it.

VPN drains my phone battery like crazy, plus eventually I’d like to be able to share my services with some less technical people, and want to keep the barrier to entry low for them, so I’ve been looking at what I’d want in order to be comfortable exposing services publicly.

Services are running on Truenas Scale (k3s).

What I’ve been thinking is:

1. Isolate services’ network access to each other and to my local network.
2. Reverse proxy in front of all services (probably Caddy)
3. Coraza as a WAF
4. Crowdsec Caddy module
5. Some sort of auth layer in the proxy, like oauth2-proxy (kind of tricky because not every service would work well with this, especially without client support). Probably would start with a 3rd party identity provider rather than rolling my own, especially since 3rd party will probably do a lot more monitoring around logins, patterns, etc.

Thinking of hosting the reverse proxy piece on a VPS. Probably not completely necessary because I don’t think hiding my home IP really buys me much security, but Caddy might be easier to configure on the VPS compared to Truenas (though I guess I could run it in a VM on Truenas).

Each app could run a wireguard sidecar to connect it to the VPS.

Curious what others think about this setup, or if the recommendation is still to keep things behind a VPN.

Wow, I was wondering why those were 404ing, saw the repo was deleted and a new one was just created, and saw this post from 15mins ago:

https://old.reddit.com/r/Tachiyomi/comments/192157x/2024_there_is_the_end/

TLDR: they purging all extensions.

This is the one I use.

I’ve been using zsh with oh-my-zsh for almost a decade, but sounds like I might want to try Fish + Starship.

You could do it, especially if you’re running Truenas Scale since that’s Linux. On Core you could do it inside a VM (I have Jellyfin set up inside an Ubuntu VM with persistent samba mounts to access my media).

On Scale the recommended way would probably be through helm charts, though config might look a bit different than the Docker Compose files here. There are charts for I think all the services mentioned: https://truecharts.org/charts/description_list

Personally I’m planning on waiting just a little bit longer for Scale to become more stable and then I’m going to migrate, rather than trying to set up all these services in a VM on my Core machine today.