Yes!
JWTs in the browser are a total pain. You need a way to revoke them (when a user is fired, etc). Or you need to make them crazy short lived (5 minutes). Users need to stay logged in without the tab open for a lot longer than 5 minutes, so you need a way to make that work. They tend to be really large, which slows down your load times a lot due to TCP slow-start and people just having weak upload speeds. And they can easily get too large to store as a cookie. Also, people forget that anyone can read the data stored in the JWT. They just cause more problems than they solve and there's a lot of edge-cases and footguns.
Old links to your site might still be http - HSTS prevents that request being in the clear. Also, if you have a man-in-the-middle attack, it doesn't matter if you return a redirect or not as the attacker has already replaced your site with a phishing attack instead of a redirect. HSTS prevents this.
It does sound like each server is its own process. I think you're correct that it would be a little faster if all games shared a single process. That said, then if one crashed it'd bring the rest down.
This is one of those things that might take weeks just to _test_. Personally I suspect the speedup by merging them would be pretty minor, so I think they've made the right choice just keeping them separate.
I've found context switching to be surprisingly cheap when you only have a few hundred threads. But ultimately, no way to know for sure without testing it. A lot of optimization is just vibes and hypothesize.
I think the jist of it is, you probably have sufficiently low requests/second (<1000) that using postgres as a cache is totally reasonable - which it is. If your hitting your load tests and hardware spend, no need to optimise more.
Weirder still, the discounts stack! So blind people can benefit from buying a black-and-white TV for an additional discount.
I've given this a lot of thought in the past. The best I could come up with is that "legally blind" could still allow for someone with _very poor_ (colour) vision...
Ehhh. Feel like CAP theorem is a bit overrated. It's correct from a theoretical purist point of view, but you can still solve many of these kinds of issues in practice. (Similarly, people overstate the halting problem - which can be solved for computers with finite memory.)
I used these in London and they were magical and extremely convenient. I would show them to visiting friends as if they were one of London's main tourist attractions!
I knew they relied on some manual labor (bills were delayed), but assumed this was only an intermediate step to collect more real-world training data (until they sorted out the AI).
I still think this is the future though. They could reduce staffing costs and free-up floor space that would otherwise be used for self-checkouts. All the while actually drastically improving the customer experience too.
If someone cracks it, it may make it impossible for other supermarkets to complete economically.
As a fun aside, all the stores were incredibly over-staffed and helpful. If you couldn't install the app they had a browser-based fallback (type "fresh code" into the amazon searchbar on a mobile). They could also lend you a battery bank if you were low on battery. I think they even had phones to lend out to those without smartphones. It was all very optimized around customer experience first and foremost and with no real attempt for the stores to be profitable.
We had a bug on the 1st of this month. Some billing code liked to invoice on the last day of the month and failed to account for this month having an extra day. Interesting it happened as soon as the "leap month" started. Easily fixed though.
This is for cracking password _hashes_. Most websites won't store a user's plain-text password but will only store the hash of it. Then a hack/exploit might later reveal the website's password hashes. This program helps you turn the hash back into the original password. Assuming you have a hash already, you own the hash, so it's not possible for anyone to impose a rate limit on how quickly you can attempt to break it.
My cousin runs a very small home-made html blog. I really like it and it gives me that early 2000s nostalgia. I'm sure he'd be psyched if some people here were to read it.
I doubt it. My guess is that you have speakers/headphones connected to your dock and they're picking up some kind of transients when you plug it in. Capacitors charging can also have some sound, but it's usually quite high pitched. If you're docking station has an external power source, you might find that adding/removing/changing it helps. Or connecting speakers/headphones via a usb DAC.
Interestingly, because your program runs on Linux and is run 5 times, Linux will almost certainly cache the 12gb file to RAM on the first invocation.
This means that future invocations don't have to load the file from disk. This also makes it pretty critical that your program doesn't use more than 16gb of ram itself (out of the server's 32gb) or it'll push the file out of cache making future invocations of your program slower.