Exactly this. I wrote a blog (at https://www.crittercism.com/blog/scaling-with-eventual-consi...) about why my company designs for eventually consistent stores from the beginning. There are a lot of use cases - and the number is growing as companies deploy large, scaleable systems - where a consistent store just isn't practical or even needed.
You can't just use an eventually consistent store as an ACID system and expect it to work, and it's almost always a Really Bad Idea to try to implement ACID on top of EC. Understand how your database works and design to its strengths instead of trying to pretend that its weaknesses don't exist.
I got tired of hearing friends saying that they'd rewritten their frontend in [trendy language of choice] because their backend was slow.
Bleem is a placeholder for these conversations. If replacing everything in an infinitely fast, no-resource-using language won't fix your performance issues, then maybe you need to take another look at your architecture.
"Our API servers that make 1,000 concurrent requests to MySQL are slow. We're thinking of replacing them."
"Would Bleem fix that?"
"I guess not."
On OS X, I use DEVONthink Pro Office with a ScanSnap iX500 scanner, and does pretty much what you're describing. OCR is really good.
While it manages the directory structure, all documents are stored "bare" in its filesystem folder. That is, you can create a Foo.pdf in DEVONthink and then access it from ~/Documents/whatever/PDFS/Foo.pdf (or however it names the directories).
Machine learning classifies incoming documents and can suggest relationships between them.
I'm not related to them, I promise. :-) I'd bought DT a while back but hadn't used it much until I got Doo as part of a software bundle. I played with it a while, realized I already had DT which was much more powerful, and started using it more.
DEVONthink Pro Office doesn't have the beauty of Doo or a name that's even remotely decent from a marketing point of view, but it is a workhorse of a doc processing engine. And it even syncs between multiple computers and Dropbox for your own private cloud.
The only thing I'm missing now is an Android "client" for it.
It's still ludicrous. I'm not a civil engineer, but I was discussing this with my friends who are. In summary, the amount of damage that a vehicle does to a road is proportional to the fourth power of its weight.
If NC is being honest about their reasons for taxing electric vehicle owners, then the Yukon owner is being subsidized about $225 a year (should pay: $775, will pay: $550) for driving a more polluting, more damaging vehicle. That's assuming that electricity is completely untaxed in NC so that the Leaf driver is paying only that $100 tax.
TL;DR This isn't about fundraising. It's about protecting gas-burning vehicle markets.
I do generally agree, but it's worth noting that in many states (including Colorado, a state which also charges a $50 EV fee), registration cost is based on vehicle weight and so the Yukon owner will pay a (still disproportionately low) greater amount.
In more northern states tires play a huge factor in road damage as well. The most noticeable road damage here in the Washington/Idaho/Montana area is from studded tires. The ruts from those tires are often an inch or more deep when they finally start repairs.
White noise is an enormous source of entropy, by definition. For example, take a stream of samples and record whether the least significant bit is 0 or 1. That'd be almost impossible to predict or influence from outside the system.
I've known people who made the same decision for many of the same reasons, and the universal experience I've heard was "it was all nice until we had to scale, and then it got expensive quickly". If your stack works for you, great! That's the important part! But if your traffic and income scaled by a factor of 100, would you be turning a profit or desperately looking for financing? You're the only one who can answer that, and it's something to consider.
As far as I can tell from my software timings,
likely revenue from ads as I need to scale, and Microsoft's
prices, I should be able to afford Microsoft
as I scale.
But at some point, if Microsoft's charges to me are so
high I could hire a good team to
refactor and convert my code to
Linux and OSS, then I could save money.
I have to believe that Microsoft has seen
that issue before and has responses to it.