Surely a receipt or an invoice is the bare minimum they should do. Awfully scummy of them.
771 karma · joined August 24, 2012
https://keyoxide.org/aspe:keyoxide.org:JOZYSIWAWQBFZ6CS4PSCOXUTIE
Surely a receipt or an invoice is the bare minimum they should do. Awfully scummy of them.
Based on some other road details, like the barriers, bollards and road signs, I'd say it was modelled fairly realistically on UK roads.
I use it even when online because it's simply much quicker and a coherent UI across many languages.
It's a tiny dedicated server that should be plenty sufficient. I run all my personal infra on these (and the higher spec ones) and they're great for the price.
Intel ATOM N2800 2c/4t 1.86GHz 4GB DDR3 1066MHz 1TB 100 Mbps
CBL is backed largely by Sqlite with features layered on top. Local query support, server replication and a bunch of other nice features useful for an offline/P2p database.
Disclaimer: Employee working on the server-side Sync Gateway component for Couchbase Mobile.
The downside is of course, that users see this process name chewing up 500%+ of CPU, google "kernel_task cpu", and find the commands to disable the thermal throttling to "fix" the issue!
https://eclecticlight.co/2019/02/25/playing-with-fire-dealin...
https://www.quora.com/How-did-the-odd-size-of-88x31-become-a...
https://github.com/vim/vim/actions?query=workflow%3A%22GitHu...
I see lots of posts complaining about the stack in the post, but all of the alternatives posed don't really explain why.
It's easy to write something small and correct from scratch (like a greenfield microservice). It's far harder to maintain that over several years and several changes of hands.
You can't know what the ID will be ahead-of writing the item to the database, nor store the item in a shopping cart without retrieving the item via a different piece of information (which is pretty likely to be SKU in this case)
There's no stopping you from storing item IDs in a theoretical shopping cart table without FK constraints though. It's just that the onus is on your application to provide the guarantee that the item exists.
This becomes a little clearer if your item IDs are not simply auto-incrementing IDs (which have their own challenges in a large distributed system), but instead are SKUs, or things which have actual meaning.
The difficulties with Sgr A* are twofold:
- The black hole moves too much during an observation (because it's much closer, and parallax is a thing)
- Sgr A* is much smaller than M87* by mass, so even though it's much closer, the angular diameter is almost the same, and the accretion disk is dimmer.
[0] http://store.steampowered.com/app/585040/Dry_Erase_Infinite_...
[1] https://steamcommunity.com/app/585040/discussions/0/14584554...
A shame I can't easily put Linux on it though for further longevity.
Excellent resource.
There's a random chance that your scanner will be audited by a human against the contents of your shopping cart. Usually the first time you use it, then it backs off.
E.g. users[].id
I'd rather be on an Open Source password manager, but I've found the sync is always too painful to do yourself.
If you threaten them with reporting to the TPS (Telephone preference service) and they're not just a robot, they sometimes stop bothering you.