- Posts
- 0
- Comments
- 119
- Joined
- 3 yr. ago
- Posts
- 0
- Comments
- 119
- Joined
- 3 yr. ago
Oh I'm streets ahead, I never took him at his word in the first place.
I'm all for de-Googling, but... is it possible that Restricted in this context mean those apps have no data usage because they're restricted from using it? It could be trying to say that the app is restricted, not that you're restricted.
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.
- Brian Cantrill (https://youtu.be/-zRN7XLCRhc?t=33m1s)
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.
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.
Private State Tokens are Google's implementation of the IETF Privacy Pass protocol. Apple has another implementation of the same protocol named Private Access Tokens. Mozilla has taken a negative position against this protocol in its current form, and its existing implementations in their current forms. See here for their blog post on the subject, and here for their more in-depth analysis.
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.3MiBNote 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.
From https://www.githubstatus.com/ (emphasis mine):
We suspect the impact is due to a database infrastructure related change that we are working on rolling back.
If you fuck up the database, you fuck up errythang.
They smell like plastic, metal, complex hydrocarbons, and death.
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).
That's exactly it. If affluent countries can get on the same page, they can neutralize the "wealth flight" argument and we can start shifting the balance back toward something that remotely resembles equality.
Billionaires, as a class, are likely already spending that much or more on lobbying for lower taxes. Or really lobbying for the status quo, since existing loopholes allow them to achieve an ultra low or even 0% effective tax with alarming regularity. The threat they make is wealth flight. "If you raise our taxes we'll take all our wealth somewhere else!" As a result taxes on the ultrarich have essentially been a global race to the bottom for decades. At least now there finally seems to be some indications that wealth inequality cannot be ignored the way it has been for so long. My hope is that we'll eventually see some international framework that effectively raise the tax floor for the 1%. It won't cover every nation, but if it encompasses the EU, US, Commonwealth and other aligned countries then that would go a long way.
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.
Am I understanding this right that the scalper buys a legit ticket to extract the token, then it can be used any number of times to get in a venue? I thought their system should be able to identify a token/ticket has already been scanned after it’s first used? That’s why there are no re-entry rules at most venues.
I don't think the intent of the scalpers is to allow ticket reuse. Like you say, there are likely additional checks at the gate when a bar code is scanned. If a rotating barcode is cloned, only the first person to scan is going to get in. Everyone else who tries to use a clone of that now-used barcode is going to get denied entry because the door staff's scanner is going to throw a "ticket already used" error of some kind. So while it's technically possible to clone one of these rotating barcodes, just like it's possible to have multiple authenticators producing the same OTPs, there's no point in doing so.
What the scalpers are after is a platform that allows them to resell tickets without giving TicketMaster a cut. TicketMaster allows their rotating-bardcode tickets to be transferred to a wallet app like Google Wallet. Wallet apps like Google Wallet have features to allow you to transfer tickets to another user's wallet, but the wallet specification also includes a flag for whether wallet-to-wallet transfers are allowed. TicketMaster sets that flag so you cannot give (or sell) your ticket to someone else using your own wallet, instead you have to go through something that TicketMaster controls. For transfers to friends and family, TicketMaster forces you to use their app. For reselling tickets, TicketMaster forces you to use their reselling site. TicketMaster's primary motive is obvious: they want to take a cut of ticket resales, and this is how they do that.
The whole thing is a legal fight between two utterly shitty groups, TicketMaster and scalpers. Here's hoping they somehow both lose.
The money came from products they sold online as well as their OnlyFans sites
Why do these guys have OnlyFans revenue? I doubt they're selling pics of themselves. Why would the models featured in those sites not cut out the Tate brothers and just deal with OnlyFans directly? The models provide the content, OnlyFans provides the platform... so what value do the Tate brothers provide? I have to imagine the answer to the first question is "threats" and the answer to the second is "nothing." These guys are just digital pimps.
I'll second this. If you look at commercial top-sliced hot dog buns, they're basically elongated pull-apart rolls that aren't baked brown on the sides because they were baked right next to a bunch of other rolls. I found this blog post that has a good pic of what I think would be the ideal spacing:
The parchment paper is almost certainly optional. Neat trick to keep the buns separate but likely not necessary.
Because the toxins your body is reacting to are already in your bloodstream. It'll take time for those to get metabolized by your liver, and how much or little you vomit won't change how much work your liver has to do.
Is it exploitation? I'd argue slave or prison labor is exploitation because the workers have no freedom of choice. Bees are free to leave, and the queen will in fact do so if not content with the conditions in the hive. If the queen leaves, all of the bees will swarm with her and you'd be left with an empty box.
Beekeeping strikes me more as symbiosis. The beekeeper provides ideal conditions, far better than the average location that would be found in the wild, and can help protect the hive against threats like mites. In exchange the beekeeper receives a share of the honey produced by the hive.
No beekeeper takes all of the honey from the hive. Only the top box (the "honey super") of a typical hive stack is harvested. A grate below the top box (a "queen excluder") prevents the queen from entering it so no larva are laid in the top box. The workers bee are smaller and can pass through the grate to build out comb and produce honey. The comb and honey in the bottom boxes are left to the hive to feed its workers and produce the next generation of bees, ensuring the survival of the hive.
A queen excluder cannot be used to prevent swarming long-term as the drones that gather the pollen also won't for through the grate! An excluder might be used to delay swarming and buy time so the beekeeper can offer another solution, like adding more boxes to the hive or splitting it into two hives. Better beekeepers proactively manage their hives, e.g. by setting up an empty hive in advance to essentially offer a swarming hive a new ideal home whenever they're ready for it.