5 ms·

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.

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()

pabs3 4y 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.
klodolph 4y ago
(I think it would be strcat() → strlcat(), since strncat() is not really safer / newer.)
- david2ndaccount 4y ago
  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.
  - klodolph 4y ago
    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.
    - kevin_thibedeau 4y ago
      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.
- torstenvl 4y ago
  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://man.openbsd.org/strncat.3 https://en.wikipedia.org/wiki/Version_7_Unix https://en.wikipedia.org/wiki/Version_7_Unix
- cpeterso 4y ago
  btw, strlcpy() is now being removed from Linux kernel code. strscpy() is the latest "secure" string copy function: https://lwn.net/Articles/905777/ https://lwn.net/Articles/905777/
moffkalast 4y ago
Meanwhile Canonical: "Let's fix what ain't broke at least once every 2 years."
- gw99 4y ago
  At least it's not Gnome "Let's rewrite again what we didn't get around to finishing and fixing 2 years ago"
proc0 4y ago
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.
- kqr 4y ago
  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.
  - foobiekr 4y ago
    How does this line of thinking address security?
  - bbjJqJmxFNbAcg9 4y ago
    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...)
  - proc0 4y ago
    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.

pabs3 4y 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.

klodolph 4y ago

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

david2ndaccount 4y ago
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.
- klodolph 4y ago
  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.
  - kevin_thibedeau 4y ago
    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.
torstenvl 4y ago
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://man.openbsd.org/strncat.3 https://en.wikipedia.org/wiki/Version_7_Unix https://en.wikipedia.org/wiki/Version_7_Unix
cpeterso 4y ago
btw, strlcpy() is now being removed from Linux kernel code. strscpy() is the latest "secure" string copy function: https://lwn.net/Articles/905777/ https://lwn.net/Articles/905777/

moffkalast 4y ago

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

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

proc0 4y ago

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.

kqr 4y ago
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.
- foobiekr 4y ago
  How does this line of thinking address security?
- bbjJqJmxFNbAcg9 4y ago
  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...)
- proc0 4y ago
  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.