5 ms·

Android is probably a good example of the update problem in action, but it's hard to blame Linux directly for this. Rather it is indeed the product cycle that s

by drvdevd 10y ago

Android is probably a good example of the update problem in action, but it's hard to blame Linux directly for this. Rather it is indeed the product cycle that seems to be driving the problem as you point out in #2 there. But then again, isn't it reasonable to expect some sort of deprecation or end of life for most products? Also, even if manufacturers are held to account more, we will still see severe bugs, IMO, in Linux or even some hypothetically more secure, future OS. As it's framed in this article at least, I think the automotive manufacturer metaphor falls down at some point (even if most cars now run Linux too). I think software is just vastly more complex and we are just now learning how to cope with that complexity.

FussyZeus 10y ago
> But then again, isn't it reasonable to expect some sort of deprecation or end of life for most products? In a cell phone? Sure, because the replacement process is a somewhat annoying sales appointment at $carrier. In a thermostat? No, because it should last years. Maybe decades if it's a good one. IoT falls apart in this arena because the hardware is designed to be replaced often, and that's exactly what house hardware should not be. And if the software is too complex, then don't do it. Do it right or don't bother.
- caf 10y ago
  I wonder if the solution for IoT things like the network-connected door lock mentioned in the article is the emergence of third-party companies that are contracted by the initial manufacturer to provide ongoing updates for the expected product life (eg 15 years). The idea being that these patching companies would become recognised brands, and the manufacturer would get to put a "Supported by FooCorp until 2031" badge on their packaging, and consumers would start to expect to see this.
  - FussyZeus 10y ago
    My other thought relating to what you said would be why on Earth does a door lock need Linux? This is not exactly a massively complicated device, it controls a 2-state mechanism and needs to work at about a five foot radius. The fact that something like that, in an IoT mindset, needs an entire webserver is ridiculous. This is much more suited to a micro-controller with custom firmware and a tiny attack surface. No, maybe you won't be able to set it up with a smartphone and 2 minutes, but it also might WORK BETTER if it wasn't able to do that.
pjmlp 10y ago
> I think software is just vastly more complex and we are just now learning how to cope with that complexity. If an engineer builds a bridge and it falls down, s/he will get punished for it. If a doctor or a lawyer makes a similar hard mistake, s/he will get punished for it. The same needs to happen to software engineering, specially given that in most countries software engineering is a degree with the respective Engineering Order.
- drvdevd 10y ago
  I agree that liability has its' place in software engineering. But I don't think, at this point in history at least, we can apply it broadly across the many subdomains thereof. For example, we can't hold Linus Torvalds liable when the Linux Kernel has a bug (perhaps not even if it was deliberate!). If we even tried to, the entire project would likely come to a screeching halt. How is this model of liability compatible with large open source codebases?
  - pjmlp 10y ago
    No, not Linus but the ones that caused the failure.
  - FussyZeus 10y ago
    Why would Linus be responsible? That would be like holding Sir Henry Bessemer (inventor of steel) responsible for the Tacoma Narrows bridge. Of course it wasn't his fault: his contribution was used incorrectly, as Linux is frequently used incorrectly by IoT companies. And frankly, if your thermostat malfunctions and runs your heat full bore for a weekend while you're out of town, I don't think it's unreasonable to say that, assuming basic requirements were present for functionality (power, connectivity to the furnace, etc.) that the company should be responsible if their system went wrong solely because of poorly designed software. If for nothing else than your outrageous heating bill. And again, if a company's response is "well we don't want to be responsible for your furnace" then my response is "then don't be making fraking thermostats, because that's what they're FOR!"
    - 10y ago

by drvdevd 10y ago

FussyZeus 10y ago

> But then again, isn't it reasonable to expect some sort of deprecation or end of life for most products? In a cell phone? Sure, because the replacement process is a somewhat annoying sales appointment at $carrier. In a thermostat? No, because it should last years. Maybe decades if it's a good one. IoT falls apart in this arena because the hardware is designed to be replaced often, and that's exactly what house hardware should not be. And if the software is too complex, then don't do it. Do it right or don't bother.

caf 10y ago
I wonder if the solution for IoT things like the network-connected door lock mentioned in the article is the emergence of third-party companies that are contracted by the initial manufacturer to provide ongoing updates for the expected product life (eg 15 years). The idea being that these patching companies would become recognised brands, and the manufacturer would get to put a "Supported by FooCorp until 2031" badge on their packaging, and consumers would start to expect to see this.
- FussyZeus 10y ago
  My other thought relating to what you said would be why on Earth does a door lock need Linux? This is not exactly a massively complicated device, it controls a 2-state mechanism and needs to work at about a five foot radius. The fact that something like that, in an IoT mindset, needs an entire webserver is ridiculous. This is much more suited to a micro-controller with custom firmware and a tiny attack surface. No, maybe you won't be able to set it up with a smartphone and 2 minutes, but it also might WORK BETTER if it wasn't able to do that.

pjmlp 10y ago

> I think software is just vastly more complex and we are just now learning how to cope with that complexity. If an engineer builds a bridge and it falls down, s/he will get punished for it. If a doctor or a lawyer makes a similar hard mistake, s/he will get punished for it. The same needs to happen to software engineering, specially given that in most countries software engineering is a degree with the respective Engineering Order.

drvdevd 10y ago
I agree that liability has its' place in software engineering. But I don't think, at this point in history at least, we can apply it broadly across the many subdomains thereof. For example, we can't hold Linus Torvalds liable when the Linux Kernel has a bug (perhaps not even if it was deliberate!). If we even tried to, the entire project would likely come to a screeching halt. How is this model of liability compatible with large open source codebases?
- pjmlp 10y ago
  No, not Linus but the ones that caused the failure.
- FussyZeus 10y ago
  Why would Linus be responsible? That would be like holding Sir Henry Bessemer (inventor of steel) responsible for the Tacoma Narrows bridge. Of course it wasn't his fault: his contribution was used incorrectly, as Linux is frequently used incorrectly by IoT companies. And frankly, if your thermostat malfunctions and runs your heat full bore for a weekend while you're out of town, I don't think it's unreasonable to say that, assuming basic requirements were present for functionality (power, connectivity to the furnace, etc.) that the company should be responsible if their system went wrong solely because of poorly designed software. If for nothing else than your outrageous heating bill. And again, if a company's response is "well we don't want to be responsible for your furnace" then my response is "then don't be making fraking thermostats, because that's what they're FOR!"
  - 10y ago