Product appears to have nothing to do with Redis and isn't even remotely compatible. Marketer uses buzzword to attempt to get credibility and hence immediately loses all credibility with actual market.
I don't think you understand Redis. Redis is also a key-value store, but implements a variety of structures, not just RTree, and has a large number of operations on those data structures (http://redis.io).
Spacebase appears to be a significantly more primitive KV store that implements RTree. Not that that's bad; looks interesting, even though it appears that the product won't be free, and so in my opinion is probably doomed.
Using 'Redis' in the title is just embarrassing for Spacebase and, by extension, for YC too. No need to troll the professional developer community with ridiculous comparisons.
The comparison is meant to be functional - not technical. Most people use Redis as a low-latency key-value store either for write-heavy uses, short-term storage or as a cache. SpaceBase is, indeed, not a key-value store, but it can now serve the same purpose Redis does, namely, a low-latency, write-heavy data-store, only for spatial indexing rather than key indexing. I think I've made an apt, fair analogy.
Redis is a particular product, not a catch-all for low latency in-memory data stores. So saying your product is a Redis (which you did, rather than making an analogy) was merely embarrassing attention grabbing marketing palaver which does discredit to your product and suggests that you don't have the attention to detail and critical thinking skills required to properly implement a product in this space. See: MongoDB.
Yeah, it's configurable between "Demand my password again if 15 minutes has passed" and "Demand my password again immediately." You can tell you're going in the wrong direction when you first have to "enable restrictions" hoping to relax the restriction. I take it you've never actually tried to configure this option.
It depends on the app but at least in the areas I work (business apps relating to tracking money) I wouldn't assume that device authentication is sufficient.
But for biometrics, keep in mind that biometric systems are currently seen as the most subject to false positives of any authentication system out there with the possible exception of improperly maintained and insufficiently strong passwords.
Maybe it's just me, but I find the e-paper Kindles to be absolutely terrible reading experiences. The text is still relatively low contrast, but the real deal killer is the refresh flash. It's jarring and disruptive and it is nothing like a page turn.
I disagree strongly about the text, I find e-ink wonderful to read from. When I 1st used my e-ink kindle and noticed the refresh flash I actually thought it was a problem. I asked a friend who had one prior to me if his did the same and initially he said no. Then he went to check and realised that yes, it does. He then yelled at me for pointing it out as it wasn't something he'd even taken notice of in the past but now couldn't avoid focusing on every time he turned a page.
For me, I got used to the refresh flash and it doesn't bother me in the slightest or disrupt my reading. I don't really see the need for a page turn metaphor. The fact the next/previous buttons are right where I'm holding the device is a huge plus in my mind. Devices where you need to swipe the screen to turn a page seem to be missing out on the huge advantage.
The one thing which I absolutely needed to learn how to hack was the margin size. It struck me of a waste of space to have a 20mm margin on the screen. I found a guide to edit a config file on the device and changed to 5mm margin and love it.
I disagree with you. You start ignoring the refresh flash and it is not distracting at all once you get used to it. Really the fancy page turn animation does not add any value to my reading experience. I would care less. What I care about is I can read my book outdoors in bright sunlight and go without charging for a month. And, my eyes don't get tired after long hours of reading.
Reading between the lines from both the posted note and their persistent failure to provide correct statuses: the ops guys over there are in full CYA desperation mode somewhere around 100% of the time, and a culture of 'it wasn't me', fuelled either by job fear, or promotion fear, or fear of being noticed by bezos, is in full bloom.
They didn't choose Python, or Ruby, or Java, because none of those languages are as expressive or shut-up-and-get-out-of-my-way as PHP. Just because a high schooler can write PHP doesn't mean it's a toy not also meant for world class engineers.
I would say there's a difference. PHP is bad because it has a wide variety of objectively awful design flaws, its standard library is a conflicted mess, and it's unperformant. Implementing it into a modern architecture is highly correlated with sloppiness and technical debt.
ORM is bad because the impedance mismatch between an object and a relational model is very difficult to get right.
Frequently, for example, one iterates over collections of objects in the OO paradigm. A naively written ORM, or one without sufficient introspection into the loop intent, can translate that into N select statements, each incurring a network round trip.
The end result is that OO programmers have to understand not only their object code, but also the relational model, and finally too the ORM's peculiarities and suboptimalities. So in attempting to solve one problem, most of the time you end up with three.
That said, there is a sweet spot in ORMs for simple code (e.g. most web apps, where ActiveRecord and Sequel and the like are fine). But there's no sweet spot for PHP code. Every line written is technical debt.
Beyond the other listed benefits: Percona also provides support contracts quite inexpensively, which can be worth their weight in diamonds. I bought a support contract after our Percona instance started to slow down, and the level of quality of the analysis and the results blew my mind. And I've been doing SQL for 25 years.