CountVon

joined 1 year ago
[–] CountVon@sh.itjust.works 4 points 3 weeks ago

Yeah, I don't get it either. What I've seen doesn't look anywhere close to an 8+ out of ten rating. Will be interesting to see the player ratings on this one...

[–] CountVon@sh.itjust.works 8 points 3 weeks ago

I don't dislike that art style in general, but to my mind it seems like a poor fit for a Dragon Age game. I guess they're pivotinf strongly away from the series dark and gritty roots, which is unfortunate because I think that was one of its strong points.

[–] CountVon@sh.itjust.works 18 points 3 weeks ago (5 children)

Watching Skill Up's review now, and oof. That art style... that writing. Don't know who they made this game for, but it's definitely not me.

[–] CountVon@sh.itjust.works 18 points 1 month ago (3 children)

Oh I'm streets ahead, I never took him at his word in the first place.

[–] CountVon@sh.itjust.works 120 points 2 months ago (1 children)

Keep in mind that Larry Ellison is fundamentally incapable of caring whether or not "citizens will be on their best behavior." The only reason he would say a thing such as this is because he sees an opportunity to make money from such a system.

Do not fall into the trap of anthropomorphising Larry Ellison. You need to think of Larry Ellison the way you think of a lawnmower. You don't anthropomorphize your lawnmower, the lawnmower just mows the lawn, you stick your hand in there and it'll chop it off, the end. You don't think 'oh, the lawnmower hates me' -- lawnmower doesn't give a shit about you, lawnmower can't hate you. Don't anthropomorphize the lawnmower. Don't fall into that trap about Oracle.

[–] CountVon@sh.itjust.works 31 points 2 months ago (2 children)

OpenAI on that enshittification speedrun any% no-glitch!

Honestly though, they're skipping right past the "be good to users to get them to lock in" step. They can't even use the platform capitalism playbook because it costs too much to run AI platforms. Shit is egregiously expensive and doesn't deliver sufficient return to justify the cost. At this point I'm ~80% certain that AI is going to be a dead tech fad by the end of this decade because the economics just don't work now that the free money era has ended.

[–] CountVon@sh.itjust.works 13 points 2 months ago* (last edited 2 months ago) (1 children)

I think you're referring to FlareSolverr. If so, I'm not aware of a direct replacement.

Main issue is it’s heavy on resources (I have an rpi4b)

FlareSolverr does add some memory overhead, but otherwise it's fairly lightweight. On my system FlareSolverr has been up for 8 days and is using ~300MB:

NAME           CPU %     MEM USAGE
flaresolverr   0.01%     310.3MiB

Note that any CPU usage introduced by FlareSolverr is unavoidable because that's how CloudFlare protection works. CloudFlare creates a workload in the client browser that should be trivial if you're making a single request, but brings your system to a crawl if you're trying to send many requests, e.g. DDOSing or scraping. You need to execute that browser-based work somewhere to get past those CloudFlare checks.

If hosting the FlareSolverr container on your rpi4b would put it under memory or CPU pressure, you could run the docker container on a different system. When setting up Flaresolverr in Prowlarr you create an indexer proxy with a tag. Any indexer with that tag sends their requests through the proxy instead of sending them directly to the tracker site. When Flaresolverr is running in a local Docker container the address for the proxy is localhost, e.g.:

If you run Flaresolverr's Docker container on another system that's accessible to your rpi4b, you could create an indexer proxy whose Host is "http://<other_system_IP>:8191". Keep security in mind when doing this, if you've got a VPN connection on your rpi4b with split tunneling enabled (i.e. connections to local network resources are allowed when the tunnel is up) then this setup would allow requests to these indexers to escape the VPN tunnel.

On a side note, I'd strongly recommend trying out a Docker-based setup. Aside from Flaresolverr, I ran my servarr setup without containers for years and that was fine, but moving over to Docker made the configuration a lot easier. Before Docker I had a complex set of firewall rules to allow traffic to my local network and my VPN server, but drop any other traffic that wasn't using the VPN tunnel. All the firewall complexity has now been replaced with a gluetun container, which is much easier to manage and probably more secure. You don't have to switch to Docker-based all in go, you can run hybrid if need be.

If you really don't want to use Docker then you could attempt to install from source on the rpi4b. Be advised that you're absolutely going offroad if you do this as it's not officially supported by the FlareSolverr devs. It requires install an ARM-based Chromium browser, then setting some environment variables so that FlareSolverr uses that browser instead of trying to download its own. Exact steps are documented in this GitHub comment. I haven't tested these steps, so YMMV. Honestly, I think this is a bad idea because the full browser will almost certainly require more memory. The browser included in the FlareSolverr container is stripped down to the bare minimum required to pass the CloudFlare checks.

If you're just strongly opposed to Docker for whatever reason then I think your best bet would be to combine the two approaches above. Host the FlareSolverr proxy on an x86-based system so you can install from source using the officially supported steps.

[–] CountVon@sh.itjust.works 37 points 3 months ago (2 children)

It's likely CentOS 7.9, which was released in Nov. 2020 and shipped with kernel version 3.10.0-1160. It's not completely ridiculous for a one year old POS systems to have a four year old OS. Design for those systems probably started a few years ago, when CentOS 7.9 was relatively recent. For an embedded system the bias would have been toward an established and mature OS, and CentOS 8.x was likely considered "too new" at the time they were speccing these systems. Remotely upgrading between major releases would not be advisable in an embedded system. The RHEL/CentOS in-place upgrade story is... not great. There was zero support for in-place upgrade until RHEL/CentOS 7, and it's still considered "at your own risk" (source).

[–] CountVon@sh.itjust.works 28 points 4 months ago* (last edited 4 months ago)

Anything that pushes the CPUs significantly can cause instability in affected parts. I think there are at least two separate issues Intel is facing:

  • Voltage irregularities causing instability. These could potentially be fixed by the microcode update Intel will be shipping in mid-August.
  • Oxidation of CPU vias. This issue cannot be fixed by any update, any affected part has corrosion inside the CPU die and only replacement would resolve the issue.

Intel's messaging around this problem has been very slanted towards talking as little as possible about the oxidation issue. Their initial Intel community post was very carefully worded to make it sound like voltage irregularity was the root cause, but careful reading of their statement reveals that it could be interpreted as only saying that instability is a root cause. They buried the admission that there is an oxidation issue in a Reddit comment, of all things. All they've said about oxidation is that the issue was resolved at the chip fab some time in 2023, and they've claimed it only affected 13th gen parts. There's no word on which parts number, date ranges, processor code ranges etc. are affected. It seems pretty clear that they wanted the press talking about the microcode update and not the chips that will have the be RMA'd.

[–] CountVon@sh.itjust.works 52 points 6 months ago

He was a raging alcoholic who hid his illness from the medical professionals who examined him as part of his Super Size Me "experiment." A lifetime of booze did way more damage than 30 days of McDs possibly could.

[–] CountVon@sh.itjust.works 2 points 8 months ago* (last edited 8 months ago) (1 children)

I'm sure there would be a way to do this with Debian, but I have to confess I don't know it. I have successfully done this in the past with Clover Bootloader. You have to enable an NVMe driver, but once that's done you should see an option to boot from your NVMe device. After you've booted from it once, Clover should remember and boot from that device automatically going forward. I used this method for years in a home theatre PC with an old motherboard and an NVMe drive on a PCIe adapter.

[–] CountVon@sh.itjust.works 38 points 9 months ago (1 children)

Elon broke the seal on firing huge swaths of a tech workforce to make your numbers look better.

Don't give him too much credit, it's hardly the first time the tech sector has gone through this cycle. Elon had to do it because he massively overpaid for Twitter. The fact that his layoffs came at the front of this wave is probably just coincidence.

view more: next ›