5 ms·

An excellent product doesn't need maintenance if it doesn't rely on any online services. Once it's done, it's done. It does everything it needs and nothing it d

An excellent product doesn't need maintenance if it doesn't rely on any online services. Once it's done, it's done. It does everything it needs and nothing it doesn't need. Engineering projects usually have a finished state. Software engineering is no different, no matter how much the industry wants you to believe otherwise.

steveBK123 3y ago
Completely incorrect. Underlying hardware/OS/firmwares/JVM/etc change. Dependencies break. Security updates. Etc. Engineering projects usually hand off maintenance to their owner. Your house/car need maintenance. Your cities roads/bridges/tunnels need maintenance. The difference with software is that maintenance is done by the producers as they own the code.
- grishka 3y ago
  > Underlying hardware/OS/firmwares/JVM/etc change. OSes also can be "excellent products". They don't need yearly updates, there's nothing inherent to them that would prevent them from being made perfect, finished and never updated again. The only case when an otherwise perfect OS would truly need to update is when new hardware capabilities require OS-level changes to support. Sometimes it may be beneficial to expose these new hardware capabilities as APIs for apps to consume. But again, adding new APIs shouldn't break the existing ones. For example, on phones, this would include things like notched screens, fingerprint readers or multiple rear-facing cameras. > Dependencies break. Don't update dependencies. Pick one version that serves you well and stick with it forever. I'm serious. > Security updates. It seems like we've already realized that writing code that deals with complex data structures received from untrusted parties in memory-unsafe languages like C is a terrible idea. If you exclude memory safety vulnerabilities, the attack surface shrinks drastically. You'd run out of security vulnerabilities pretty fast if you'd have any to begin with. > Your house/car need maintenance. Your cities roads/bridges/tunnels need maintenance. Houses, cars, and road infrastructure are made out of atoms and exposed to elements and stress of our imperfect real world. They wear out. Code doesn't. In 100 years, the bits would be the same they are today (as long as you use a reliable enough storage medium).
  - nemo 3y ago
    This all sounds fine hypothetically, you might want to take a look around at the world for a while to see why it doesn't fit your model. Obviously your idea hasn't happened, and there's good reasons why this is the case that you could readily discover if you took a look at reality instead of your model of reality.
  - steveBK123 3y ago
    > there's nothing inherent to them that would prevent them from being made perfect, finished and never updated again. theres this thing called the internet, to which the OS connects, filled with adversarial actors, so no this is not correct at all
    - chromoblob 3y ago
      > this is not correct at all Why? There's a thing called formal verification of software.
    - grishka 3y ago
      And? How do updates help any of this? Firewalls are a thing. Memory-safe languages are a thing. Unit tests are a thing. Fuzzing is a thing. And it is not an OS's job to protect the user from themselves (i.e. social engineering). If you've installed malware, you deserve the consequences and you will be more careful next time. It's okay for powerful technologies to require a minimum level of education.
  - duckmysick 3y ago
    I'd rather use an imperfect product that does a good-enough job instead of waiting for a perfect product. The perfect OS doesn't exist yet. Right now, I'd rather use some OS than no OS. Why a perfect OS doesn't exist? Good question. Maybe because the programming field is relatively immature so we're still figuring things out and we don't apply formal verification to everything. Compare that to say, architecture, where we can calculate how much weight a structure can withstand. Or the other way around: what do we need to do to support an X amount of load. I guess the stakes are lower too. I wouldn't walk on a wobbly bridge, but I don't mind if a desktop app I use crashes occasionally under unusual circumstances. Critical software (say, aviation) is generally written with more care but it's still not perfect.
inglor_cz 3y ago
Uh, look at curl. It is an excellent product, no doubt about it (or if you do, I wonder what your standards for excellence are), and yet we are here, at version 8.0, 27 years after its first release. Edit: "if it doesn't rely on any online services" That is a big IF. How many things don't, at least indirectly? (e.g. by relying on HTTPS, which requires TLS, which requires keeping up with current cryptographic standards.)
- grishka 3y ago
  If cryptography can't possibly be figured out once and for all and must remain a moving target forever, I'd separate TLS into a module that can be updated independently of the rest of the system.
vel0city 3y ago
Engineering projects have a finished state? So once they build a road or bridge or dam, nobody needs to touch it again forever? It's finished right, no more work anymore. Even in electronic hardware there's often continuation of design and refinement. Have you never seen a board with a revision number on it?
- grishka 3y ago
  > It's finished right, no more work anymore. Real-world objects like these wear out. Code doesn't. > Have you never seen a board with a revision number on it? Of course I have. There's a difference though. You can't ship an electronic device that's unfinished with a promise to "fix it later". Yet this is what routinely happens with software these days. Also, if your device serves its purpose well, you'd probably have a "final" board revision with all flaws fixed. If you want to add features to an electronic device, you'd make it a different model, possibly sold concurrently with your existing one to serve people with different needs and budgets.
  - vel0city 3y ago
    > Real-world objects like these wear out You just said "engineering". Bridges and roads are engineering as well buddy. And it's not even just the wear, it's the continued refinement and upgrade of these structures which is a constant engineering effort. > Engineering projects usually have a finished state This is the statement I'm addressing. And it's just not entirely accurate. Things change, assumptions get proven wrong, there's always a newer and better way to do something, etc. Sure your widget was probably about as good as you could do at the time you first launched it, but several years later there's better components available. Or maybe a supplier stops making some part you were using. Or a few years later you start getting parts back failing early in their service life and need to make an update. What was once your finished state now isn't.
j1elo 3y ago
Software engineering is like if a car was built and thus "finished", but the systems it depends on (like roads, and gas stations) changed every N years (with N < 10). Imagine the gas stations (operating system) changed the kind of fuel they dispense every few years. No, by no means a car (software) that is fully finished today would be able to continue doing its thing tomorrow, without ongoing updates. This also happens in the real world, it's just that changes are more likely in the decades or centuries, so we as humans don't perceive them so well. The fact that Microsoft spends a whole lot of money to avoid this, is circumstantial. Apple doesn't so much, and at some point your finished software will stop working with newer MacOS releases if you don't update it to the newer system versions. Linux is even more of a moving target. Good luck having a perfectly well working compiled program today, and trying to run it in 10 years time.
- grishka 3y ago
  Is there any reason — other than "we're paying our graphic designers full-time salaries so we better get our money's worth" — why OSes have to change so drastically and can't be finished as well, only ever updated to add new APIs for apps and drivers to support new hardware features?
  - jwells89 3y ago
    Security is probably the biggest reason. With attacks growing continually more sophisticated, it’s not enough to just patch holes as they’re found — you have to engineer entirely new systems to not be drowned in holes. This unfortunately has compatibility implications. Look at macOS for example, which over the years has gained app sandboxing and mobile-like access permissions. Software pre-dating these additions that assumes that it has access to everything all the time will have its functionality impaired. Devs had to update their software to not make such huge assumptions and to handle no access cases gracefully.
    - grishka 3y ago
      So, how secure is "secure enough"? Android's security model is okay, and Google knows it, so they just keep redesigning the UI without substantial API changes because the updates have to be coming out with each lap the planet makes around its star. > Devs had to update their software to not make such huge assumptions and to handle no access cases gracefully. Sure. But at some point it will reach the "secure enough" state, won't it? (Actually, macOS permissions work mostly transparently API-wise. Apps can request access explicitly so it better fits their particular UX, but the prompt would also pop up the first time the protected resource is accessed. No code-level changes are necessary to support this.)

steveBK123 3y ago

Completely incorrect. Underlying hardware/OS/firmwares/JVM/etc change. Dependencies break. Security updates. Etc. Engineering projects usually hand off maintenance to their owner. Your house/car need maintenance. Your cities roads/bridges/tunnels need maintenance. The difference with software is that maintenance is done by the producers as they own the code.

grishka 3y ago
> Underlying hardware/OS/firmwares/JVM/etc change. OSes also can be "excellent products". They don't need yearly updates, there's nothing inherent to them that would prevent them from being made perfect, finished and never updated again. The only case when an otherwise perfect OS would truly need to update is when new hardware capabilities require OS-level changes to support. Sometimes it may be beneficial to expose these new hardware capabilities as APIs for apps to consume. But again, adding new APIs shouldn't break the existing ones. For example, on phones, this would include things like notched screens, fingerprint readers or multiple rear-facing cameras. > Dependencies break. Don't update dependencies. Pick one version that serves you well and stick with it forever. I'm serious. > Security updates. It seems like we've already realized that writing code that deals with complex data structures received from untrusted parties in memory-unsafe languages like C is a terrible idea. If you exclude memory safety vulnerabilities, the attack surface shrinks drastically. You'd run out of security vulnerabilities pretty fast if you'd have any to begin with. > Your house/car need maintenance. Your cities roads/bridges/tunnels need maintenance. Houses, cars, and road infrastructure are made out of atoms and exposed to elements and stress of our imperfect real world. They wear out. Code doesn't. In 100 years, the bits would be the same they are today (as long as you use a reliable enough storage medium).
- nemo 3y ago
  This all sounds fine hypothetically, you might want to take a look around at the world for a while to see why it doesn't fit your model. Obviously your idea hasn't happened, and there's good reasons why this is the case that you could readily discover if you took a look at reality instead of your model of reality.
- steveBK123 3y ago
  > there's nothing inherent to them that would prevent them from being made perfect, finished and never updated again. theres this thing called the internet, to which the OS connects, filled with adversarial actors, so no this is not correct at all
  - chromoblob 3y ago
    > this is not correct at all Why? There's a thing called formal verification of software.
  - grishka 3y ago
    And? How do updates help any of this? Firewalls are a thing. Memory-safe languages are a thing. Unit tests are a thing. Fuzzing is a thing. And it is not an OS's job to protect the user from themselves (i.e. social engineering). If you've installed malware, you deserve the consequences and you will be more careful next time. It's okay for powerful technologies to require a minimum level of education.
- duckmysick 3y ago
  I'd rather use an imperfect product that does a good-enough job instead of waiting for a perfect product. The perfect OS doesn't exist yet. Right now, I'd rather use some OS than no OS. Why a perfect OS doesn't exist? Good question. Maybe because the programming field is relatively immature so we're still figuring things out and we don't apply formal verification to everything. Compare that to say, architecture, where we can calculate how much weight a structure can withstand. Or the other way around: what do we need to do to support an X amount of load. I guess the stakes are lower too. I wouldn't walk on a wobbly bridge, but I don't mind if a desktop app I use crashes occasionally under unusual circumstances. Critical software (say, aviation) is generally written with more care but it's still not perfect.

inglor_cz 3y ago

Uh, look at curl. It is an excellent product, no doubt about it (or if you do, I wonder what your standards for excellence are), and yet we are here, at version 8.0, 27 years after its first release. Edit: "if it doesn't rely on any online services" That is a big IF. How many things don't, at least indirectly? (e.g. by relying on HTTPS, which requires TLS, which requires keeping up with current cryptographic standards.)

grishka 3y ago
If cryptography can't possibly be figured out once and for all and must remain a moving target forever, I'd separate TLS into a module that can be updated independently of the rest of the system.

vel0city 3y ago

Engineering projects have a finished state? So once they build a road or bridge or dam, nobody needs to touch it again forever? It's finished right, no more work anymore. Even in electronic hardware there's often continuation of design and refinement. Have you never seen a board with a revision number on it?

grishka 3y ago
> It's finished right, no more work anymore. Real-world objects like these wear out. Code doesn't. > Have you never seen a board with a revision number on it? Of course I have. There's a difference though. You can't ship an electronic device that's unfinished with a promise to "fix it later". Yet this is what routinely happens with software these days. Also, if your device serves its purpose well, you'd probably have a "final" board revision with all flaws fixed. If you want to add features to an electronic device, you'd make it a different model, possibly sold concurrently with your existing one to serve people with different needs and budgets.
- vel0city 3y ago
  > Real-world objects like these wear out You just said "engineering". Bridges and roads are engineering as well buddy. And it's not even just the wear, it's the continued refinement and upgrade of these structures which is a constant engineering effort. > Engineering projects usually have a finished state This is the statement I'm addressing. And it's just not entirely accurate. Things change, assumptions get proven wrong, there's always a newer and better way to do something, etc. Sure your widget was probably about as good as you could do at the time you first launched it, but several years later there's better components available. Or maybe a supplier stops making some part you were using. Or a few years later you start getting parts back failing early in their service life and need to make an update. What was once your finished state now isn't.

j1elo 3y ago

Software engineering is like if a car was built and thus "finished", but the systems it depends on (like roads, and gas stations) changed every N years (with N < 10). Imagine the gas stations (operating system) changed the kind of fuel they dispense every few years. No, by no means a car (software) that is fully finished today would be able to continue doing its thing tomorrow, without ongoing updates. This also happens in the real world, it's just that changes are more likely in the decades or centuries, so we as humans don't perceive them so well. The fact that Microsoft spends a whole lot of money to avoid this, is circumstantial. Apple doesn't so much, and at some point your finished software will stop working with newer MacOS releases if you don't update it to the newer system versions. Linux is even more of a moving target. Good luck having a perfectly well working compiled program today, and trying to run it in 10 years time.

grishka 3y ago
Is there any reason — other than "we're paying our graphic designers full-time salaries so we better get our money's worth" — why OSes have to change so drastically and can't be finished as well, only ever updated to add new APIs for apps and drivers to support new hardware features?
- jwells89 3y ago
  Security is probably the biggest reason. With attacks growing continually more sophisticated, it’s not enough to just patch holes as they’re found — you have to engineer entirely new systems to not be drowned in holes. This unfortunately has compatibility implications. Look at macOS for example, which over the years has gained app sandboxing and mobile-like access permissions. Software pre-dating these additions that assumes that it has access to everything all the time will have its functionality impaired. Devs had to update their software to not make such huge assumptions and to handle no access cases gracefully.
  - grishka 3y ago
    So, how secure is "secure enough"? Android's security model is okay, and Google knows it, so they just keep redesigning the UI without substantial API changes because the updates have to be coming out with each lap the planet makes around its star. > Devs had to update their software to not make such huge assumptions and to handle no access cases gracefully. Sure. But at some point it will reach the "secure enough" state, won't it? (Actually, macOS permissions work mostly transparently API-wise. Apps can request access explicitly so it better fits their particular UX, but the prompt would also pop up the first time the protected resource is accessed. No code-level changes are necessary to support this.)