> reasonably robust > obviously used mechanism OK... > If you are running "mission critical" software, you need to be using a packaging mechanism (c.f. Docke

> reasonably robust > obviously used mechanism OK... > If you are running "mission critical" software, you need to be using a packaging mechanism (c.f. Docker) which lives at a lower level and provides harder guarantees about what you're running. Those solutions exist, they just aren't Snappy. What? No it doesn't live at lower level. Docker uses same Linux APIs as Snappy. The only upside of Docker when compared to Snappy is that it doesn't turn your hardware into zombie execution unit constantly pulling code from mothership (Canonical). > In that realm, the aggregate benefit to society of having everyone running current software outweighs the annoyance of the specialists, sorry. It's always been this way. There's in fact an easy way to satisfy both groups, but for some weird reason Canonical chose to turn every user into zombie execution unit, no matter the level of proficiency. It's not like a patch to disable this malware behavior would be hard to submit, but it's crystal clear it'd be rejected. And it's clearly not for causal user benefit. They have documented switches to postpone calls to mothership. That's command line realm for experienced users. I honestly wonder what their real motivation is. Those who seek to take back the control are people who want to control their own machines. The only thing that comes to mind is that sometime in future blog posts recommending to disable automatic updates would crop up and those dumb pesky users would just copy paste it into console without much thinking.