People are less likely to commit crimes if they know the state has the tools to identify and prosecute them. Surveillance provides that capability, and reducing it makes solving and deterring crime much harder.
The cost is manageable as long as it's used for the right reasons and that the data is kept secure. The benefits of deterring violence outweigh those risks.
Billionaires may be a bigger threat but criminals are a threat nonetheless.
And I don't understand the obsession with server-based databases for single apps. Especially in containerised setups, every "app" gets its own database anyways, and if the app is further broken down into services, they usually communicate between each other and not with a shared database. So in those cases, what do you gain by pulling the database out of the "process" and onto the other end of a socket? In most cases, absolutely nothing. So why bother?
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.
“Especially in containerised setups, every "app" gets its own database anyways, and if the app is further broken down into services, they usually communicate between each other and not with a shared database. “
You seem to be talking about a vastly different use case.
Containerized apps having their own database? What? Aren’t these types of containers stateless? I always very much try to keep state out of app containers.
If an app needs a database, it gets a database server container, instead of getting a user and database on a shared database server as things used to be done. Every little django app has its own postgres container. Every wordpress site gets its own mysql container. That is the modern way.
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.
Yeah this is the part I don’t get. It seems like people are talking about 1 distinct app = 1 container and this is the new normal? We’re back to managing cows instead of cattle again?
How do you do server maintenance or handle hardware failure if your database is SQLite? You are going to have to take downtime, even in the best scenario.
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 first two options add more complexity than just using an external database.
I guess I am just not used to downtime being acceptable. Spent most of my career working for a CDN, any sort of downtime was simply unacceptable. I can't stop myself from that sort of thinking now.
It's complexity you already have. You need some sort of HA for your app server and some sort of resilient storage for your database server. Using sqlite just means the storage is used by the app server directly, nothing more.
Yes? Well, every "app", as I quite explicity wrote. Look up the docker compose file or helm chart for basically any app. I'm running dozens of apps, each with their own postgres, redis and nginx containers alongside the main application server. That's what the stack is designed for.
The Compose file is written like that so you can quickly try the app without setting up extra dependencies. Usually not for production use.
Especially since in production you might want to scale the parts separately. I like to have a Postgres cluster to connect where backup is already handled, and the app then doesn’t have any persistent data, doesn’t need any network volume mounts.
This design still screams Claude to me, but a newer version than what you're thinking of. At some point they added a markdown file that tells it to use obviously AI designs like lots of blue/purple and gradients. Since then, this is its new style.
Ok so what do you propose? Split the CAN bus into multiple, put security-critical parts on its own isolated network that you can't write to... Well now you've made the situation even worse for the owner than it currently is. Almost anything interesting on the bus can be considered security critical, so the owners would get access to nothing but boring telemetry....exactly what they get through the read-only gateway.
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...
We don't live in the same world as they do. Saying AI out loud makes line go up, not down. Investors are still eating this shit up, for now at least...
How about being banned from online banking, government services and all social networking / communication platforms? Because that's the road we're already heading down.
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.
>How about being banned from online banking, government services and all social networking / communication platforms?
You aren't banned. You just have to use a secure device. It's like saying that a store banned you because they stopped taking checks and started requiring a credit card since they are more secure and harder to commit fraud with. As a person you didn't lose any freedom. Freedom does not mean someone has to be able to force their will on another person. That sounds like the opposite of freedom to me.
>What makes you think they will give us this magical hypervisor capability?
It's not magical. Look at Windows WSL2 which already works like that.
It's not about being secure. Google allows devices with up to 10 years without any patches to pass their integrity API. Meanwhile Graphene OS, which is very secure and up-to-date, doesn't pass.
This. Plus if I want to access my bank account on a device I trust, the bank shouldn’t say “hey we don’t trust it so buzz off”. It’s my money in that account.
I understand there’s some stupid compliance thing that makes banks do this, but it clearly isn’t a hard requirement, as there’s still plenty of banks that don’t participate in this security theatre.
I’d very much love to have an option to waive that cover though! Just give me a scary warning “hey, we’ve determined your device is unsafe; so if you get hacked through that device, you agree not to hold us liable for that. proceed? [y/N]”
For more specific mitigations, they could issue shorter-living tokens to such devices, in case it gets stolen and it didn’t store the token properly (say, the user did something stupid like “hey I’ll substitute secure enclave with a shim that writes secrets to an SD card”). And they could limit certain critical functions that do require attestation for some reason (e.g. Host Card Emulation, aka “tap your phone to pay”, which they usually delegate to Google Wallet/Pay/Wallet anyway).
Wise seems to do it correctly. It works on rooted phones, even, just gives a scary warning and blocks some app functions. They also have a fully functional webapp, so you mostly don’t need the app anyway. Revolut, on the other hand, has outright blocked me from my account – so I’m not using it anymore.
You may waive that cover, but when (not if) you get hacked and your money gets stolen, someone still has to pay it back or you will die. Neither of those options are okay with the government and only one is okay with your bank.
They allow old devices to report to Play Integrity. That doesn't mean the service provider requesting attestation has to allow such devices. These things usually give just a risk grade to the service provider and it's up to them to make the decision.
Graphene OS says they are secure, but the definition of secure they're using isn't the same one the service providers are using, so that doesn't help much.
The best route forward here is to push for a separation of certification types. Ideally it would be possible to pass the security related aspects of Google's CTS test suite and get approved by Play Integrity without triggering the other parts of Android certification.
No, you have to use government backdoored device. I.e. the most secure android rom (at least the only rom we know is not penetrable by state-sponsored celebrite based malware) is not covered by google's play protect, while bunch of outdated CVEd phones are.
Same will go with many hardened Linux machines, QubesOS, Whonix stations, you name it. I'd argue they are far more secure than any average windows/macos installation.
Hardware attestation has nothing to do with security, it's censorship.
>QubesOS, Whonix stations, you name it. I'd argue they are far more secure than any average windows/macos installation.
OK, then let's see you argue it.
Most of the people who claim Linux is more secure have simplistic one-sentence arguments (e.g., "Linux is open-source, and many eyeballs make bugs shallow including bugs that are security holes") whereas those who say that MacOS and ChromeOS are more secure go into great technical detail as to why they think that.
Secure as defined by a duo of monopolists. It's a contractual concept and doesn't have a firm relation to security-related characteristics. I'd trust GrapheneOS to be as secure as anything Google is capable of releasing, but that doesn't help them if Google refuses to vouch for a device running their OS. Which is also why your check/credit card analogy falls flat.
LLMs don't "own" this writing style. By definition they can't - they were trained on human writing after all! People wrote like this before and that's fine. You might not like the style, but saying it's because LLM writing has infested their brain is wrong, dismissive and dehumanising.
Any style can cross the border into bad and get in the way of itself when it's turned up to 11, no matter who wrote it.
There've been stylistic fads before LLMs where a thing, with results just as chalkboard-screech-inducing as the current one. That this one is just a button-push away does make it worse, though, because it proliferates so greedily.
Bad writing is bad writing, and writing like an LLM is writing like an LLM. We should be able to call this out. In fact, calling out the human responsibility in it is the very opposite of dehumanizing to me.
Yes, definitely, but the parent post was quite explicitly saying it was either LLM generated or the person's style was influenced by consuming LLM content.
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.
I think the original comment is much more open-minded towards the author of the TFA than you are to the commenter.
> explicitly saying it was either LLM generated or the person's style was influenced by consuming LLM content
We might disagree here, but if we're strict they did not say "either/or", especially not explicitly. They raised two possibilities, but didn't exclude others.
> there's no reason to believe the style came from LLMs
They say "might" and "plausibly". I think there's no belief there until you assume it.
And even if: It's not unlikely that a contemporary author's mind is influenced by the prevalent LLM style. We are influenced by what we read. This has been happening to everyone for ages, without anyone questioning the agency of writers. There's nothing wrong with suggesting like that could be the case here. It's entirely human.
I know it's easy for one's mind to jump to conclusions, but I am not a fan of taking that as far as accusing someone of "dehumanizing" others. Such an escalation should ideally cause a pause and a think, before pressing submit.
Nah, the two possibilities were in fact exclusive in my mind (subject of course to the usual likelihood of any one thing I say being completely wrong, but that’s always in the background and not that useful to constantly point out). And it might be fair to say that it is unwise to attempt this kind of amateur psychoanalysis in public. It’s just that I don’t see being influenced by things you read as a big deal, let alone an accusation, let alone a dehumanizing one. See my neighbouring comment[1] for more on the last point.
I wonder how much marketing copy has poisoned the "default" writing style of LLMs, it surely has those undertones of pitching a sale in an uncanny valley way.
LLMs don’t own these expressions in the same sense that McDonald’s doesn’t own salt: they are undoubtedly making use of a strong reaction that humans have had—have been having—long before; but they did develop a way to mash that button on an industrial scale like few before them. (With of course a great deal of help from humans, be it via customer surveys or RLHF; or you could call it help from Moloch[1] in that the humans unwittingly or negligently assembled themselves into a runaway optimizer.) So I think it’s fair to say that LLMs do own this style, as in the balance of ingredients, even if they do not own the ingredients themselves. And anyway nothing in the social perception of language cares about fairness: low-class English speakers did not invent negative agreement (“double negatives”), yet it will still sound low-class to you and even me (and my native language requires negative agreement).
As for being dehumanizing, perhaps I did commit the sin of psychoanalysis at a distance here, but I’ve felt enough loose wires sticking out of my brain’s own language production apparatus that I don’t think pointing out the mechanistic aspects reduces anyone’s humanity.
For instance, nobody can edit their own writing until they forget what’s in it—that’s why any publishing pipeline needs editors, and preferably two layers of them, because the first one, who edits for style and grammar, consequently becomes incapable of spotting their own mechanical mistakes like typos, transposed or merged words, etc. Ever spotted a bug in a code-review tool that you’ve read and overlooked a dozen times in your editor? Why does a change in font or UI cause a presumably rational human being to become capable of drawing logical inferences they were not before? In either case, there seems to be a conclusion cache of sorts that we can’t flush and can’t disable, requiring these sorts of actually quite expensive hacks. I don’t think this makes us any less human, and it pays to be aware of your own imperfections. (Don’t merge your copy- and line editors into a single position, please?..)
As for syntactic patterns, I’ve quite often thought of a slick way to phrase things and then realized that I’d used it three times in as many sentences. On some occasions I’ve needed to literally grep every linking word in my writing to make sure I haven’t used a single specific one five times in a row. If you pay attention during meetings or presentations, you’ll notice that speakers (including me!) will very often reuse the question’s phrasing word for word regardless of how well it fits, without being aware of it in the slightest. (I’m now wondering if lawyers and witnesses train to avoid this.) Language production is stupidly taxing on the brain (or so I’ve heard), so the brain will absolutely take every possible shortcut whether we want it to or not.
Thus I expect that the priming effect I’m alleging can be very real even before getting into equally real intangibles like “taste”. I don’t think it dehumanizes anyone; you could say it dehumanizes everyone equally instead, but my point of view is that being aware of these mechanical realities of the mind is essential to competent writing (or thinking, or problem solving) in the same way that being aware of mechanical realities of the body is essential to competent dancing (or fighting, or doing sports). A bit of innocence lost is a fair trade for the wisdom gained.
(Not that I claim to be a particularly good writer.)
I think you are blaming Valve for forces way beyond Valve's control. Valve isn't perfect, but it is a way better steward for PC gaming and PC gamers than any other American tech company would be.
It's harder to say that when they invented loot crates. Sure everyone's doing it now, and someone else would've done it eventually, but Valve pioneered it.
I suppose, yeah, some things would be a lot worse without Steam, so there's that.
Yes, I was there. I sat through a presentation about their original concept for selling content in Team Fortress. Trust me when I say that it turned out nothing like they originally conceived of-- which is a whole different story. The whole idea that they "invented" loot crates is weird because the idea goes back to collectable card games and other things. I am not saying they are without fault.
Yeah, because that would be like selling packs of baseball cards to kids with enticements like chewing gum, a practice that was outlawed in the United States in the 1950's.
That is not true. Gachapon mechanics existed long before, valve only took it to western market, not knowing the consequences. Remember this is way before gambling sites. It was a way to earn a cool random hat on TF2.
I'm aware of what Korean MMOs were doing years earlier, but it feels different, in a way I can't quite put into words. I suspect there's a psychological aspect to earning the chest and buying the key.
But yeah, maybe I'm pushing a distinction that doesn't exist, and it's all just forms of trading cards (which themselves were popularized by tobacco companies).
I feel like it's innocent and we made it into what it is. If valve was the first one to bring cactus plant to the people and we started pleasuring ourself with it. It wouldn't be Valve's fault.
In the end it's like trading cards. Way to collect a cool cosmetic that doesn't break the game and trade it with people, making a community and new friends.
Yeah right, they just accidentally massively profit from it. Come on dude, Valve has behavioral psychologists on staff. They don't just accidentally abuse players.
They are for profit business. Even grocery chains have behavioral psychologists. Valve doesn't run the gambling sites, they even tried to stop it multiple times. [1][2]
Valve doesn't pocket anything from the direct trade. Their cut is the same regardless the selling price of an item, except when traded through steam marketplace.
The only benefit valve stands to gain from this is the free marketing. Their business in this sense is not much different from trading cards, except the goods are digital.
As much as I like Valve, it's difficult to ignore how large a part they played in shifting the PC market towards F2P.
I bought TF2 with the Orange Box, and for a few years it was amazing. Then it went F2P with hats, and overnight the player base turned into a cesspit (and the hats themselves completely ruined the aesthetic that they spent years painstakingly crafting).
I really don't see how Electron is connected here. When you're an Electron app, you really don't have to care about which web APIs Chrome implements, you can just use the native NodeJS equivalents, which will usually give you a better UX anyways.
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 those devs cared about Web standards, it would be a pure Web application, or an headless executable, system/daemon conecting to the system's browser.
I'm not saying the Electron UX is better than a native app. I'm saying Electron apps using NodeJS libs have better UX to Electron apps using Web APIs. At best there's no difference for the user, but at worst, they get permission popups and limited access just like they would in a browser.
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.
reply