imho this should be useful for driving/flight sims, giving the player the ability to lean inside the vehicle, changing their viewpoint on the surroundings.
the ultimate laptop bag is an inflatable orange swimming tow float bag:
1. it looks nothing like a laptop bag
2. it will protect your laptop from water, even completely submerged.
3. it will protect your laptop from falling when side pockets are inflated.
4. you can take your laptop to the beach and not worry about it getting stolen.
5. you can use it as a pillow when hiking or at the beach.
6. much cheaper than a laptop bag.
mine's a Decathlon OWS 500, but i guess that it's as good as any.
warning: all tow floats do leak in the storage compartment, especially if you do swim with it (as opposed to sitting on the beach), so if you really intend to put a laptop in, make sure to put it into a proper water tight sleeve/ziplock bag, e.g. an aloksak.
I believe they were working under the assumption it would be a walk in the park, once the central government was captured or killed.
To strengthen this assumption here's a canned article which was likely meant to be published had things gone according to plan, but pulled, since they hadn't.
Why precisely they thought they'd meet no serious opposition in their attempted airdrop near Kyiv is anyone's guess. Mine is that Putin started believing his own tales about Nazis taking Ukraine hostage, assuming the populace is dying to be liberated from them.
Things crumbled once this met a different reality on the ground, and now they're trying to raise the stakes, and have become desperate enough to begin indiscriminately shelling population centres, Kharkiv most notably.
> Why precisely they thought they'd meet no serious opposition...
Isn't that what everybody thought?
Didn't NATO also think that?
Isn't that why the US and friends categorically refused boots on the ground, no-fly-zones or even just strategic ambiguity?
Or maybe, things are just slow, because they are slow..
Funny how westerners are surprised by this. Not telling the grunts what they are going into has been Russian modus operandi since forever... Just like throwing bodies at the problem, sending conscripts from Central Asia first (throwing actual Russians into the meat grinder might prove unpopular), rampant looting (including of the most absurd stuff like toilets in Georgia 2008), etc, etc.
Somehow most of the pundits and analysts have been blindsided by this stuff, even though it's common knowledge in Eastern Europe.
I just wrote the exact same thing before seeing your comment, just not so eloquently. I think you are spot on, that really is the only "rational" explanation.
If you use this, also take a look at GraphQL, AWS has a hosted GraphQL service called Appsync, and if you look into self hosted you can also use Prisma.
It's highly customisable, works directly with postgresql row levels security and the performance is quite good. It has a custom GraphiQL gui to work on queries/mutations.
To really see how it all works together checkout the starter project: https://github.com/graphile/starter it has migrations, job queue, graphql-codegen etc.
tried GraphQL, not sure I'm sold on it viability. Sure it is very uniformed, however for nested queries it is very slow. We already have SQL don't need another querying language in js. If I really want get fancy then prolog would be much more preferred. On top of that FB is backing the project make me feel very uneasy, the same exact reason why I won't want to use React with a 10 foot pole.
(disclaimer: not feeling totally authoritative on this, have not used graphql in production).
i feel that the choice between postgrest & postgraphile / another graphql solution revolves around whether you're a front-end dev who doesn't get to arbitrarily change/expose data schema. if this is true, and you are collaborating with other devs on the code then the added flexibility in querying probably outweighs the inferred complexity of this complex data abstraction.
if, however, you control both back and front-end, graphql isn't really needed, as you can expose whatever views you fancy by means of SQL (via views, table/row permissions, rpc functions exposed by postgrest, etc)
./pg_schema_dump.sh breaks down the schema into an entity-per-file structure at ./sql/schema, while.
./db_init.sh knows how to create a fresh database schema from this dump.
the per-file breakdown allows to nicely version the schema in git.
i wonder if it's possible to plug any kind of streaming replication onto this. i don't have much sqlite experience, but maybe someone here has an idea if it would be possible to run litestream or something of the sort, as both master and slave - in the browser.
that would solve the safari indexeddb 7 day ttl issue to start with.
and if replication could be made to work on top of something like webrtc we're looking at a great foundation to start building distributed, decentralized browser apps.
i must say that the experience is quite horrible - that torture of having to write map/reduce functions, added with some erratic behavior in regards to data integrity (inserted entries silently discarded, sync to the remote couchdb instance working somewhat whimsically). as soon as your dataset is sizable in any regard (tens of thousands of records in a collection, if i recall the terminology) it begins to just break apart.
was writing a browser extension, and used pouch with the hope of keeping its persistence local and avoid needing a server. seeing that it leaks tried to trade it for a couchdb server. seeing how bad sync is, and that couch is not very comfortable to work with either ended up throwing the thing in favor of a postgresql+postgrest backend.
performance wise, postgrest is written in haskell and is extremely snappy and stable. so your bottlenecks in essence are your data access patterns & how much you've optimized your postgresql schema for that.
Back in 2004 or so, I was building a distributed CMS with the goal of creating artificial "link pyramids" with the purpose of SEO, which was a rather new thing at the time.
Content generation was one of our bottlenecks, and as Google was already rather successful at detecting duplicate content, we were looking for a way to "uniqify" posts that would be used to stuff sites intended for googlebot, but not humans.
One of the methods that worked was taking source English content, running it through Babelfish, the Altavista translator to French, Spanish or German, and then using the same method to translate it back to English.
This resulted in texts that did not make much sense to humans, were full of precisely such "tortured phrases" but which were considered unique by Google.
source code at https://github.com/guyromm/Window
imho this should be useful for driving/flight sims, giving the player the ability to lean inside the vehicle, changing their viewpoint on the surroundings.