2. K8S DaemonSet, PVC backed by probably Ceph

3. Just..don't care? Do maintenance outside of working hours, fix issues quickly and explain things nicely to your customers. Not everything is google-scale. Most people can deal with some downtime.

And it's not like you won't have downtime in let's say a postgres-backed app. But now you have two "servers" to deal with.

Those database containers get a PVC/volume/mount for their data dirs. The only thing ever connecting to them is their "owner" application container. So at that point, why not drop the postgres container and PVC mount a sqlite directory in the app container? The result is the same.

Don't get me wrong, I've worked with plenty of server-based databases, including proper dedicated database servers. It's great tech and often the best tool for the job. But not always and I'd argue not in the majority of uses.

Proper security requires authentication and freedom-preserving authentication has to have owner-controlled credentials. That's the only way forward. Who cares where they run which bus. Encrypt/authenticate everything and give the owner a way to set their own key. Now we just need to figure out a way to make this a law...

What makes you think they will give us this magical hypervisor capability? It's more effort, increases the chances someone finds a bypass and takes power away from the incumbent online platforms. It's so much easier to just prevent it all. The only reason it hasn't happened yet is the amount of devices without this ability in circulation. But that number is shrinking rapidly.

Sure, call the style bad or even similar to LLMs, but there's no reason to believe the style came from LLMs. It existed before and people who used it before still exist and still use it now.

Hell, this person seems to be a web(site) developer, that's a very marketing-speak-heavy field. It's far morely likely that's where they "caught" thos style. It happened to me too back when I was still in it.

This is why Electron app devs prefer NodeJS libs to Web APIs and consequently have no impact on the adoption of a large chunk of the new Web APIs (not counting DOM and CSS things because those are rarely controversial and usually broadly implemented).

So yes, those devs don't care about these kinds of new web "standards", because they don't work with them. The people who use them are the ones who are dangerous and that's almost exclusively web app authors, because they can't just pull in a native library to do the same things.

But absolutely on the second point. A standard with one implementation is not a standard. Regardless of market share, in a market with three providers, if two out of three don't support something, you have no business using it. It unhealthy for everyone involved.

If you don't find the open source model sustainable and you've really tried, sure, go closed source, we'll understand. But please don't lie to everyone that it was all about security.

The assault on your attention is way worse these days, it's just (mostly) contained to the viewport.

1-4. Google, find, read... this is the same for web apps. 2. Click download and wait a few seconds. Not enough time to give up because native apps are small. Heavy JS web apps might load for longer than that. 3. Click on the executable that the browser pops up in front of you. No closing the browser or looking for your downloads folder. It's right there! 3.5. You probably don't need an installer and it definitely doesn't need a multi-step wizard. Maybe a big "install" button with a smaller "advanced options". 3.6. Your installer (if you even have it) autostarts the program after finishing 4. The user uses it and is happy. 5. Some time later, the program prompts the user to pay, potentially taking them directly onto the payment form either in-app or by opening it in a browser. 6. They enter their details and pay.

That's one step more than a web app, but also a much bigger chance the user will come back to pay (you can literally send them a popup, you're a native app!).

The comparison to ID checks when buying cigarettes is missing the point. Human ID checks have few downsides and are relatively high cost to fool.

In the real world, you show your ID to a human and they look at the date of birth and photo. They don't copy or photograph it, they surely won't read let alone remember anything else from your ID, it would be very obvious, costly and dangerous for a criminal to install a hidden camera and secretly record everyone and their IDs. We also don't attach the ID physically to your body and assign an individual police offier to follow you around 24/7 so you don't try to tamper with it somehow.

On the Internet, a securely (safe from bypasses) implemented age verification system makes sure your device is owned and used only by you, that you can't lend it to somebody, that you can't modify or inspect it... It also enables some level of reidentification for catching and prosecuting you if enable access to a minor despite this.

These are two wildly different situations.