• 0 Posts
  • 51 Comments
Joined 2 years ago
cake
Cake day: June 12th, 2023

help-circle
  • Not the person you replied to, but I’m in agreement with them. I did tech hiring for some years for junior roles, and it was quite common to see applicants with a complete alphabet soup of certifications. More often than not, these cert-heavy applicants would show a complete lack of ability to apply that knowledge. For example they might have a network cert of some kind, yet were unable to competently answer a basic hypothetical like “what steps would you take to diagnose a network connection issue?” I suspect a lot of these applicants crammed for their many certifications, memorized known answers to typical questions, but never actually made any effort to put the knowledge to work. There’s nothing inherently wrong with certifications, but from past experience I’m always wary when I see a CV that’s heavy on certs but light on experience (which could be work experience or school or personal projects).


  • I also unplugged the psu for a while. It makes a slight buzzy noise after powering the computer, but I do not know if this is normal.

    I’d recommend starting with the PSU. A buzzing noise is not a good sign. This article has details on how you can test your PSU: https://www.howtogeek.com/172933/how-can-i-test-my-computers-power-supply/

    You can perform a basic test with just a paper clip or a bit of 16 or 18 gauge wire.

    It sounds like the PSU is giving some power, given that the keyboard lights up. The issue could be isolated to one or more rails, e.g. it’s not delivering anything / enough on the 12V or 3.3V rail. I’m guessing 5V is OK since that’s USB voltage and your USB keyboard gets power. You’d need a multimeter to check individual power pins on the PSU connector.

    Edit: if you have access to a second PC, you can swap PSUs between them. If the problem follows the PSU then that’s the faulty component. If the problem stays with the original PC then it’s likely motherboard, CPU or RAM.

    If you can determine that the PSU is OK then the next step is to try booting with the bare minimum amount of hardware. That’s motherboard, CPU and one stick of RAM. If that won’t boot then you try with a different RAM. If it still won’t boot then the issue is motherboard or CPU. Before you replace either of those expensive components, try replacing the cheap CMOS battery as another poster recommended.


  • However, it’s worth mentioning that WireGuard is UDP only.

    That’s a very good point, which I completely overlooked.

    If you want something that “just works” under all conditions, then you’re looking at OpenVPN. Bonus, if you want to marginally improve the chance that everything just works, even in the most restrictive places (like hotel wifi), have your VPN used port 443 for TCP and 53 for UDP. These are the most heavily used ports for web and DNS. Meaning you VPN traffic will just “blend in” with normal internet noise (disclaimer: yes, deep packet inspection exists, but rustic hotel wifi’s aren’t going to be using it ;)

    Also good advice. In my case the VPN runs on my home server, there are no UDP restrictions of any kind on my home network and WireGuard is great in that scenario. For a mobile VPN solution where the network is not under your control and could be locked down in any number of ways, you’re definitely right that OpenVPN will be much more reliable when configured as you suggest.


  • I use WireGuard personally. OpenVPN has been around a long time, and is very configurable. That can be a benefit if you need some specific configuration, but it can also mean more opportunities to configure your connection in a less-secure way (e.g. selecting on older, less strong encryption algorithm). WireGuard is much newer and supports fewer options. For example it only does one encryption algorithm, but it’s one of the latest and most secure. WireGuard also tends to have faster transfer speeds, I believe because many of OpenVPN’s design choices were made long ago. Those design choices made sense for the processors available at the time, but simply aren’t as performant on modern multi core CPUs. WireGuard’s more recent design does a better job of taking advantage of modern processors so it tends to win speed benchmarks by a significant margin. That’s the primary reason I went with WireGuard.

    In terms of vulnerabilities, it’s tough to say which is better. OpenVPN has the longer track record of course, but its code base is an order of magnitude larger than WireGuard’s. More eyes have been looking at OpenVPN’s code for more time, but there’s more than 10x more OpenVPN code to look at. My personal feeling is that a leaner codebase is generally better for security, simply because there’s fewer lines of code in which vulnerabilities can lurk.

    If you do opt for OpenVPN, I believe UDP is generally better for performance. TCP support is mainly there for scenarios where UDP is blocked, or on dodgy connections where TCP’s more proactive handling of dropped packets can reduce the time before a lost packet gets retransmitted.






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


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


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



  • Jesus, what a bunch of needless “security”

    I disagree with this part. Ticket theft is an actual issue, there are lots of ways to get a copy of someone else’s barcode and either use it before they do or (more likely) sell it to someone else online. TicketMaster’s marketing is talking up the increased security to distract from their true purpose, which is of course to find more ways to take more money from fans. Of course it’s debatable whether the increased security is worth the decreased convenience for ticketholders. That is the inevitable tension when it comes to security, where any increase in security always incurs at least some cost in terms of convenience.

    This is all for personal data mining.

    TicketMaster might be selling user data, but I don’t think that’s their main aim. They want control of the resale market so they can take a cut when tickets are resold. Note how they don’t allow direct transfers between two mobile wallets, they only allow transfers using their app. That’s so they can monitor transfers. If they see someone transferring dozens or hundreds of tickets to many other TicketMaster users then that person is likely reselling and they can clamp down on their account. TicketMaster’s true intent is to force all resales onto their ticket marketplace, because that’s where they get to take a cut of resales.


  • Oh yes, I don’t mean to absolve them of any blame. They treated it as an expensive lesson, which is probably the best way for them to process it.

    Also while TicketMaster is going to sell this as being an “enhanced security” thing, it’s pretty obvious that increased security is only a side benefit for them. Their angle in this is getting more control over the tickets they sell. As long as there are many people who want to go than can physically fit in a venue, there will be a reselling market for event tickets. TicketMaster wants to take a cut of these downstream transactions.

    While the security of rotating barcodes does hinder outright scams, mobile wallets normally allow wallet users to transfer items like tickets to another user if the ticket issuer allows it. TicketMaster does not allow this for their tickets, of course, because it could allow someone to resell tickets while cutting TicketMaster out of the transaction. Currently TM allows transfers using their app, but I’m sure they monitor usage of the feature and clamp down on anyone transferring many tickets. In other words if you try to resell in bulk without using TicketMaster’s own platform (where they get to take a cut), they drop the hammer on you.


  • The reason you can’t use screenshots or printouts is because they’re now using rotating barcodes. Much like the rotating codes in an authenticator app, the number values behind the barcode are changing on some regular cadence. Only the most recent barcode value is considered valid.

    The only other option is to use a mobile wallet, but that prevents me from sending my friends their tickets, since I purchased them all together.

    Some ticket sellers allow you to transfer tickets from one wallet to another wallet, but of course TicketMaster isn’t one of them because they’re fucking TicketMaster. What TicketMaster does allow is transfers from one TicketMaster account to another. Of course then everyone needs to have a TicketMaster account, needs to have the app, etc. It’s either that or leave all the tickets in your app or wallet and go in together. If you tell the door person “I have the tickets for these X people,” they’ll be able to handle that.


  • Yes because the security of barcodes and screenshotted tickets were such a huge problem before.

    I think what you just described is actually a problem. Friends of my parents were visiting somewhere, bought tickets to a show from a reseller, met up with the seller (normal looking guy, no red flags, gave some plausible story why he was selling) and paid cash for printed out tickets with barcodes. Printouts looked legit, dates on the printouts were correct, etc. Went to the doors, tried to scan their tickets, got told that unfortunately they’d just been scammed. The impression they get from the box office worker is that this sort of bad news is something they’ve had to deliver frequently. Anecdotal, but I doubt those friends of my parents were the only ones to get scammed in this way. TicketMaster still sucks as an organization but the extra security of rotating barcodes does serve a legitimate security purpose, just like the rotating security codes generated by an authenticator app.

    Airlines have recently been having problems with stowaways using screenshots of boarding pass barcodes or QR codes too. Such stowaways should get caught before departure by passenger headcounts or boarding ID checks, but clearly there are gaps or breakdowns in these procedures because some of these stowaways are getting caught at the destination. Others may have successfully flown for free. If it keeps happening I bet we’ll see rotating barcodes come to mobile boarding passes too, if that hasn’t already happened.


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