I know a lot of security researchers will disagree with this notion, but I personally think that security (& privacy, I'm going to refer to both as "security" for brevity here) are an overhead. I think that's why it needs to exist *and be discussed* as a sliding scale. I do find a lot of people in this space chase some ideal without a consideration for practicality.

Mind, I'm not talking about financial overhead for the company/developer(s), but rather an UX overhead for the user. It often increases friction and might even need education/training to even make use the software it's attached to. It's much like how body armor increases the weight one has to carry and decreases mobility, security has (conceptually) very similar tradeoffs (cognitive instead of physical overhead, and time/interactions/hoops instead of mobility). Likewise, sometimes one might pick a lighter Kevlar suit, whereas othertimes a ceramic plate is appropriate.

Now, body armor is still a very good idea if you're expecting to be engaged in a fight, but I think we can all agree that not everyone on the street in, say, a random village in Austria, needs to wear ceramic plates all the time.

The analogy does have its limits, of course ... for example, one issue with security (which firmly slides it towards erring on the safe side) as compared to warfare is that you generally know if someone shot at you and body armor saved you; with security (and, again, privacy), you often won't even know you needed it even if it helped you. And both share the trait that if you needed it and didn't have it, it's often too late.

Nevertheless, whether worth it or not (and to be clear, I think it's very worth it), I think it's important that people don't forget that this is not free. There's no free lunch --- security & privacy are no exception.

Ultimately, you can have a super-secure system with an explicit trust system that will be too much for most people to use daily; or something simpler (e.g. Signal) that sacrifices a few guarantees to make it easier to use ... but the lower barrier to entry ensuring more people have at least a baseline of security&privacy in their chats.

Both have value and both should exist, but we shouldn't pretend the latter is worthless because there are more secure systems out there.

The thing with zero bugs is that software is very complicated not due it being harder than hardware but by simply that get some devs, POs, sys admins, devops and stuff and zero bugs will be defined entirely different.

For example, in theory the only real system with zero bugs would be one you use exactly always the same way, at the same place for the same exact goal and never change that.

Its a bit related to the old saying in cybersec " the msot secure system is the one who isnt used at all and not connected to anything" so basically a tradeoff with UX always. But who would want that?

I think thats why software on more actual mission critical systems are way more stable and bug free... still hate the word. Because it cant be avoided, since you see bugs sometiems are just situations when your uncontrolled actors (users, other services) use the system in a non-intented way so you try plan for that such us retry mechanisms, logging, backups etc.

Because when we further think about it, have you ever witnessed a system in real life thats bug free? Humans have bugs all around, buildings, cars, even nature. So how would you expect we could do that, esp each random company? Also do we want that? What if we said there is a 100% defiend system we can make perfect in 100 years... Good, but whats the point?

> utility of the product falling down to 0.

Today a bank really sent me a legitimate email about trying their new site. Went over, it was their site alright, logged in with correct username and password - poof, instantly blocked for suspicious access (from my usual home machine), call helpline to fix.

Now that's safe ... and useless. But safe.

Thats very true and I think about often because even in everyday task e.g. "We need a new feature to download reports" then you get a ticket but still depending how much that is used, desired, invested in or marketed and all those things, how flexible should I make, whats all the errors, whats the data, how secure and million other small or bigger decisions.

The point isn't how user stories are written, but realizing that everything is a compromise for practicality since if I wanted it to be the most secure thing ever, Id say "Lets just not offer that feature at all".

But now back to cars, I like that I heard some companies promised or started to build cars again with real buttons. In our world its when I try to use more and support the tools which aren't build on Electron (and slow as hell) but actually care about performance. Open source and decent enough security is already the minimum requirement.

Sometimes I want VSCode and sometimes I want Notepad.

Well.. except that I never want either of those. So sometimes I want Kate editor and sometimes I want Akelpad.

JVM is fast for certain use cases but not for all use cases. It loads slowly, takes a while to warm up, generally needs a lot of memory and the runtime is large and idiosyncratic. You don't see lots of shared libraries, terminal applications or embedded programs written in Java, even though they are all technically possible.

The JVM has been extremely fast for a long long time now. Even Javascript is really fast, and if you really need performance there’s also others in the same performance class like C#, Rust, Go.

Hot take, but: Performance hasn’t been a major factor in choosing C or C++ for almost two decades now.

I was qmail fanbois back in the day and loved how djb wrote his own string handling library. I built things with qmail that were much more than an email server (think cgi-bin for web servers) and knew the people who ran the largest email installation in the world (not sure how good they were about opt-in…)

Djb didn’t allow forking and repackaging so quail did not keep up with an increasingly hostile environment where it got so bad that when the love letter virus came out it was insufficient to add content filtering to qmail and I had to write scripts that blocked senders at the firewall. Security was no longer a 0 and 1 problem, it was certainly possible to patch up and extend qmail to survive in that environment but there was something to say for having it all in one nice package…. And once the deliverability crisis started, I gave up on running email servers entirely.