But that wouldn't have looked like a bash script, only a random sequence of characters. The shebang at the start definitely contributes to the geek factor.
Yeah, that "extreme low pressure" part of the article had me scratching my head. Even a complete vacuum at the top will not suck water up more than 10 meters! The author was probably oversimplifying for a lay audience.
If most archers start shooting as soon as targets enter the range, and if their individual ranges are clustered around the average, wouldn't that result in a relatively high density of shooting when the distance to a moving group of targets coincides with their average range?
Some movies actually provide a plausible-sounding explanation for the volley fire thing. A dude in charge commands everyone to wait until the unsuspecting enemy enters the kill zone. But even in that case, I guess the archers won't wait with their bows drawn.
It's not just about long vs. short passwords. IMO the greatest benefit of having a password manager -- whether it's a bloated Electron app or just a text file on your computer -- is that it enables you to juggle hundreds of different passwords, randomly generated for each site. It's the best way we know of to limit the blast radius when (not if!) some of those sites inevitably get hacked.
> as (generally speaking) all data stored in Redis is usually regarded as volatile because of what Redis actually is.
If you know this already, then you didn't need to read OP or any of this thread. :)
The problem is that Redis tries very hard to position itself as a persistent data store, with defaults that lean toward persistence (no default eviction policy). Beginners need to fight these defaults every step of the way if all they want is a cache.
Redis works great as a cache, but there are a few things you need to do in order to use it reliably as a cache.
1) Wrap your client library so that it's impossible to store anything without an expiry date. You don't want 6-months-old data suddenly coming up in your app!
2) Either turn off persistence, or use a separate database for the cache. In other words, don't mix volatile data with stuff you actually care about.
3) Set up a reasonable maxmemory value with an appropriate maxmemory-policy, so that Redis doesn't eat up all your RAM.
4) Resist the urge to use complex data structures. If you try to update a single field on an expired hash, you will end up with an incomplete object.
If you don't want all that hassle, then yes, Memcached probably works better out of the box.
But it's a hefty upfront investment for people who just want to experiment. The good thing about $200/month subscriptions is that you can cancel them any time and cut your losses. Not so with a $4000 computer that loses half of its resale value as soon as you plug it in.
I think the current sweet spot for people who don't already own a high-end gaming PC is to rent a server with a beefy GPU from Hetzner et al. and run local models there.
Not while the hardware required to run a local model at an acceptable speed costs way more than $200.
Guess what, the big players are hoarding all the RAM and GPUs so that other people can't afford decent hardware. It's working out beautifully for them!
Humanoid (or dogoid) robot hardware on its own offers no benefits over non-humanoid factory machines. It just has fancy firmware controlling its motions.
Humanoid robots loaded with an AI agent, on the other hand, could actually make you a sudo sandwich, do your laundry, or help you with that weekend project in the backyard. They're finally about to get useful.
I'm not a fan of humanoid robots personally (they creep me out), but I'd love to have a functional R2-D2 with me.
SEO and accessibility laws have always been the most effective way to convince someone to build clean, well-structured webpages. Guess what, both are measures of how easy it is for a machine to extract content from your pages. AI is just the latest machine that wants to slurp up your soup of tags.
Homepage: https://www.kijinsung.com Business: https://www.poesis.org
GitHub: https://github.com/kijin E-mail: [email protected]