• 0 Posts
  • 64 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle

  • Tl;Dr the protocol requires there to be trusted token providers that issue the tokens. Who do you suppose are the trusted providers in the Google and Apple implementations? Google and Apple respectively, of course. Maybe eventually there would be some other large incumbents that these implementers choose to bless with token granting right. By its nature the protocol centralizes power on the web, which would disadvantage startups and smaller players.



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



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




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




  • If you look at the Steam player charts for the game you’ll see when it’s working vs. when it’s not. Off-peak it works fine, but right now the player base is ramming up against their temporary player cap for hours at a time on-peak. If you try to connect when there are thousands of others also trying to connect, that’s when things go south. That was the case for much of the weekend.

    Edit: Here’s a chart illustrating what I mean:

    In the last 48 hours, player counts hit 400k at about 7pm Eastern UTC and just stayed there for 6-ish hours. That isn’t normal, almost all other player count charts show a gradual rise and fall over the course of a day. The devs implemented an artificial cap after they found that their servers bog down when there are too many active players, basically sacrificing the peak time login experience to preserve the in-game experience. If you try to connect while the active player count is pegged, you’re essentially joining a swarm of other players who are also trying to connect at the same time. That swarm is likely DOSing some aspect of their own login systems.




  • People here seem partial to Jellyfin

    I recently switched to Jellyfin and I’ve been pretty impressed with it. Previously I was using some DLNA server software (not Plex) with my TV’s built-in DLNA client. That worked well for several years but I started having problems with new media items not appearing on the TV, so I decided to try some alternatives. Jellyfin was the first one I tried, and it’s working so well that I haven’t felt compelled to search any further.

    the internet seems to feel it doesn’t work smoothly with xbox (buggy app/integration).

    Why not try it and see how it works for you? Jellyfin is free and open source, so all it would cost you is a little time.

    I have a TCL tv with (with google smart TV software)

    Can you install apps from Google Play on this TV? If so, there’s a Jellyfin app for Google TVs. I can’t say how well the Google TV Jellyfin app works as I have an LG TV myself, so currently I’m using the Jellyfin LG TV app.

    If you can’t install apps on that TV, does it have a DLNA client built in? Many TVs do, and that’s how I streamed media to my TV for years. On my LG TV the DLNA server shows up as another source when I press the button to bring up the list of inputs. The custom app is definitely a lot more feature-rich, but a DLNA client can be quite functional and Jellyfin can be configured to work as a DLNA server.




  • This shit has been going on since the 80s. It’s mostly bullshit instigated by US lumber companies. Available softwood lumber in the US is mainly on privately owned land, and the owners of that land want the price of lumber to be as high as possible so they can make more money. The softwood lumber companies in the US are effectively acting as an oligopoly, and they lobby US politicians for legislation in their interests.

    Softwood lumber in Canada is mainly on public land, called “crown land” here in Canada. A lumber oligopoly isn’t possible in Canada because the government would never sell all of that land to a handful of lumber companies. Instead lumber producers in Canada are charged a fee for the logs they cut, that fee is set by the Canadian government, and it is less per log than what US lumber producers want to charge.

    Instead of competing on price, US lumber companies lobby congress to impose softwood lumber tariffs for the umpteenth time. When the US lumber companies don’t need to compete with Canadian lumber, they can jack up their prices. When they do that the only people who benefit are the US lumber companies and the politicians they’ve lobbied. Americans pay more for lumber, Canadian lumber companies and their workers suffer.



  • How did this happen? Isn’t there usually a flight attendant standing right there as you board the plane?

    Yes, but the 777 has two aisles. Here’s the Air Canada seat map. The flight attendant greeting passengers would be by the first aisle, directing passengers down the correct aisle for their seat. This passenger might have been directed to the second aisle, and rather than turning down the aisle they went straight across to opposite exit door. Or they might have used one of the other doors. The 777 has 10 full-sized doors, 5 on each side of the plane. Two of those doors open onto the wings, one of those would have been used for boarding, maybe two if first-class passengers get a separate air bridge, but that still leaves 6 or 7 doors where there isn’t likely to be a flight attendant to notice a passenger doing something stupid.