That's what I'm saying, in part. Mr. Moolenaar's reports on his own on-the-grounds activities are quite clear (from what I remember now, a bunch of years later), and the goal of ‘build some schools’ doesn't make me wonder ‘what exactly does that mean’.
Moreover, the encouragement to donate to that charity is written into the license of Vim, and still I never went ‘ugh, why does he pollute the software with politics’ or anything like that.
Gotta say, when I read about how Bram Moolenaar, the author and maintainer of Vim, works sometimes to build schools in remote areas of Uganda and encourages users to donate to that cause—not once did I question how that is helpful or what he's doing with people's money.
Exactly, it's very easy to see how Google doesn't leave the user unspammed. YouTube's search works the same way, and even if there are useful results on top, they quickly trail off into clickbait garbage. Plus the unrelated lists of ‘people also watch’, injected every few items. The search filters are barely enough to dial in when you want to skip obvious trash, but give up on anything slightly complicated. On Play Store, it's worse: you just get troves of what Google thinks you should be getting, with no control on your side—because if people could skip apps with payment inside, they would, and who in Google wants that.
Well, every database already optimizes disk access (at least until the recent years with the ‘just add SSDs’ attitude). However, they tend to assume that indexes should be loaded into memory. For this use-case, you'd want a database that can use indexes themselves from disk and treat them like partitioned storage: e.g. when reading data for years 2019 to 2021, only request parts corresponding to that, and not previous years. Dunno whether SQLite can have indexes partially in memory—with its niche of low-end devices and apps, it's quite possible that it can.
Actually, this sort of partial access (i.e. partitioning) is rather easy to implement by addressing separate data files by name, instead of using numeric ranges into a database. Basically just put the data into files named by the years (in my example); or bucket the data into chunks of arbitrary size and use the chunks as files. Elementary to extend this to multiple fields in the index. In short, partitioning based on actual field values can be much easier in the static-http approach than using opaque ranges. Probably also more effective if something like http2 allows requesting several files in one request—since you can avoid requesting too little or too much.
That would be equivalent to always putting your data in b-trees or other structures, according to the request patterns, without keeping the tables themselves. Sort of how you need to do that in Redis for any kind of sane request strategy other than key-value lookups.
I kept thinking that all the laments about Ubiquiti and others are enterprise-level stuff and are sysadmins' headaches, so was thankful I don't need to worry about it. But more and more I wonder how I managed to choose an Asus 5 GHz router by reviews, bought it secondhand, and now have it chugging along for something like eight years with only some hiccups in summers from heat. With no ‘cloud’ shenanigans.
Also, there are DD-WRT, OpenWRT and such. How comes people don't use those instead of whatever broken software the manufacturer bestows on them?
Weirdly, on an older-ish Mac I'm having lots of trouble making 90s games work in Wine—basically, out of a dozen games only ‘Grand Prix Legends’ runs, since it kept being patched by the community for the past twenty years. Judging by the app db, Wine has some special relationship with Linux and Nvidia. Mac and Intel, not so much—I can have desktop software and not much else. Otherwise I'm stuck with PS1 emulation.
I have craving for SWAT 2 and I must satisfy it, even if it means installing Windows 98 on the NAS.
As usual, when someone makes a move towards the Coveted Feature, people promptly insist that gradual progress is impossible and the only way is with every problem being solved at once in the hundred million modules—each somehow taking a year to undo the use of global variables. I.e. same as it was for the past twenty years when gradual progress could've been made. Deference is again made towards Numpy, the de-facto implementation of Python. No trace of choice is offered to users who would perhaps use a handful of modules from those that happen to be converted at a point in time, or use Python in ways that aren't practical now.
The actual problem, of course, is that multi-threading Python would still be slow, and those who see it as just a shell to run C modules, do have a point.
> A sufficiently sophisticated operation could use canned footage to fake the apparent call and response here
I mean, if the tech reaches such heights that a customer can't tell it from a human, does it even matter for the customer?
(Actually I think that on an emotional level it does, but realistically it's a question of inputs to the brain, i.e. the whole Matrix mind-body thing. Anyway, I'm sure this is firmly in the AGI territory.)
Same here, I've gotten used to moving thousands of records a second even with MySQL's InnoDB on spinning metal. Then tried Neo4j and, I think, one other software—and that was the end of my experience with graph dbs.
If I were interested in them again now, I would try new and fancy solutions first, to see if there are nosql-level performance improvements in the graph db space.
Moreover, the encouragement to donate to that charity is written into the license of Vim, and still I never went ‘ugh, why does he pollute the software with politics’ or anything like that.