Hacker News Reader

Comment by torstenvl | Hacker News Reader

Simple: Release Early. Release Often until it Ain't Broke. Don't change things that Ain't Broke.

I don't think there's much consternation over actual bugfixes. There's consternation over constantly-shifting UIs and APIs.

The only time there's any tension between those two things is when people conflate bugs with poor design. The messy but correct thing to do when you've correctly implemented a poor design is to maintain backward compatibility while also offering the option to use the newer, more correct behavior. See, e.g., strcat() → strncat() → strlcat()

View on HN

The line of when it's ready to be used is not clear and I think it has been pushed forward such that the user increasingly becomes the tester. This is unacceptable in hardware products, imagine if kitchen appliances were sold with issues, and you had to take it back to the store for fixes and updates. Unfortunately, users don't know any better, and I think that's why so much of the industry gets away with serving them a bad user experience that is bad because in essence you are testing it.

The software we write is far more complex than a kitchen appliance.

For simple systems, yes, test all components, build in redundancies, etc. All those things that made reliable system design possible in the 1950s.

For complex systems you're quickly wasting your time on diminishing returns. The failure modes of complex systems lie in obscure interactions between components conditional on rare input combinations. You have to find that stuff out in production. You have to make users into testers.

However, there are better and worse ways to do this. Ideally, a failure should only be experienced by a user with a fallback solution, not a plain failure to accomplish the task entirely.

How does this line of thinking address security?

That's a tautology. You're saying that we shouldn't fix the complexity and bloat that gives rise to bugs because we'd have to fix the complexity and bloat that gives rise to bugs.

We landed on the moon with a reliable computer and reliable software in the 1950s. What software that you've written is "far more complex" than that?

(Personally, I'd posit that a lot of the complexity is the ten or fifty layers of framework and language and library between the programmer and the computer. But I digress...)

Sure, there could be exceptions like parts of security systems that would have to be tested in production because of limitations of data/threat modeling. I'm thinking mostly end user software, UI's, games, etc. that increasingly ship things expecting to patch it along the way.

Meanwhile Canonical: "Let's fix what ain't broke at least once every 2 years."

At least it's not Gnome "Let's rewrite again what we didn't get around to finishing and fixing 2 years ago"

Preferably also provide assistance to people using the old things, in the form of making the old API a wrapper for the new API where possible, adding warnings for the old API, adding migration tools etc.

(I think it would be strcat() → strlcat(), since strncat() is not really safer / newer.)

Just always use memcpy, you should always know the size of your buffers and if you don’t you will get a buffer overflow at some point.

I've heard this advice before, and the problem with this advice is that people who just use memcpy in practice often write code with bugs in it. So the advice is bad advice. Good advice will result in code that has fewer bugs, or bugs with lower severity.

It can also lead to accidentally quadratic behavior which is why the modernized string ops that get so much hate these days rely on one iteration over the input.

Definitely not safer (perhaps even more dangerous due to its unexpected semantics), but I do think it's slightly newer. It doesn't appear in K&R 1st edition, released in 1978, but does appear in K&R 2nd edition from 1988.

OpenBSD claims it first appeared in Version 7 Unix, which was released in 1979.

https://man.openbsd.org/strncat.3 https://en.wikipedia.org/wiki/Version_7_Unix

btw, strlcpy() is now being removed from Linux kernel code. strscpy() is the latest "secure" string copy function:

https://lwn.net/Articles/905777/

Reply on news.ycombinator.com