Comment by psychoslave | Hacker News Reader

Comment by psychoslave | Hacker News Reader

Parent Full thread

>software that used to follow the "release-then-go-back-to-cave" model will have to change to start dealing with maintenance for real, or to just stop being proposed to the world as the ultimate-tool-for-this-and-that because every piece of software becomes a target.

Actually, some software are running the water-heater/heat-pump system in my basement. There is a small blue light screen, it keeps logs of consumed electricity/produced heat and can make small histograms. Of course there is a smart option to make it internet connected. The kind of functionality I’m glad it’s disabled by default and not enforced to be able to operate. If possible, I’ll never upgrade it. Release then go back to the cave has definitely its place in many actual physical product in the world.

I’ll deal with enough WTF software security in my daily job during my career. Sparing some cognitive load of whatever appliance being turned into a brick because the company that produced it or some script-kiddy-on-ai-steroid decided it was desirable to do so, that’s more time to do whatever other thing cosmos allows to explore.

There's an anecdote I remember reading somewhere: When an 'embedded systems' engineer was to present a web-based product they were tasked to build, the managers/reviewers were puzzled they couldn't find any bugs. Asked about this, the engineer replied: "I didn't know that was an option".

Definitely a different mindset/toolset is required when it comes to building systems that have to be working autonomously without "quick fixes" from the web.

Yes but I would push back a little on the idea that you simply put yourself in a "mindset of writing bug-free code."

Simpler code has fewer bugs. Embedded code tends to be simpler and more targeted in its role. Of course, putting yourself in the mindset of writing simpler code is great too - if you have the time to do so, and the problem you are solving is itself sufficiently simple.

Embedded code is also simpler because it has to be. When you are confined to a microcontroller, there isn't room for bloated app frameworks, hundreds of NPM packages, etc.

Depends on whether there's room in the budget to integrate something like a full-fat Raspberry Pi board, at which point, your light switches and thermostats can be full-fledged Kubernetes nodes if you like.

Never underestimate software developers' ability to simultaneously over- and underengineer a solution, especially if the only limitation is hardware cost (read: somebody else's problem).

The embedded engineering mindset is not a mindset of "writing bug-free code"; it's a mindset of treating the first ~20% of the time budget you're given for the project as time spent designing and writing code (and constraining scope appropriately); and then treating the rest of your time budget as time spent coming up with every possible way to validate/static-analyze/fuzz/etc your code you can, and then debugging all the resulting failures. (Which also implies structuring your code so that it remains at all times extremely testable, whether you are writing tests just then or not.)

Web interfaces in embedded systems are very common remote exploit mechanisms, so this anecdote for sure isn't the typical experience.

My gut feeling and expectation is that people will be turning their internet off at night, and at all times. At least for a while until this whole new security situation somehow settles with newly invented automation.

May sound weird, but as author of previous comment noted - a lot of appliances need not be connected ever and still benefit humanity.

Reply on news.ycombinator.com