I am unconvinced that this is a good idea. Shouldn’t the default deployment behavior minimize surprise, which is almost impossible with automatic updates?
I’m not sure the tail of cloud deployments should be wagging the dog.
These devices are essentially appliances and fall under the model of the manufacturer ensuring firmware updates. It’s still something that needs to be planned and engineered, not left to chance.
Moreover, the trend in cloud is for immutable, stateless servers that never have an uptime of more than a few days before they’re destroyed. In this context, it makes even less sense.
In that situation, automatic upgrades are irrelevant. They’ll be blown away / rolled up in the next release. So it’s not really an argument for or against.
You could certainly end up getting unexpected updates while the servers are alive if you don’t proactively disable it in your image, so yes it is still a concern.
Agreed. I’ve thought about adding an “apt-get update && apt-get dist-upgrade” cron job for years now, but never do because I just like to know when and what things are changing.
Shouldn’t the default deployment behavior minimize surprise
I’d think so, but this is Debian. They do a lot of surprising things already, so it fits the mindset. People who don’t like surprises probably aren’t running Debian.
What you consider “surprising” is consistency and reliability, the reasons why people who don’t like surprises do run Debian en masse.
I’m suspicious of automatic updates, but less so with Debian than anything else, because their release management is so good that their unstable branch is more stable than some people’s releases. But I think the current system of just auto-installing security updates and packages from the updates suite (contains things like tzdata, spamassassin, clamav… things that are only useful if they’re up to date) is good enough for me :)
I am unconvinced that this is a good idea. Shouldn’t the default deployment behavior minimize surprise, which is almost impossible with automatic updates?
I’m not sure the tail of cloud deployments should be wagging the dog.
They also mention IoT. Not sure how much of that runs Debian but such devices tend to run unattended anyway.
These devices are essentially appliances and fall under the model of the manufacturer ensuring firmware updates. It’s still something that needs to be planned and engineered, not left to chance.
Moreover, the trend in cloud is for immutable, stateless servers that never have an uptime of more than a few days before they’re destroyed. In this context, it makes even less sense.
In that situation, automatic upgrades are irrelevant. They’ll be blown away / rolled up in the next release. So it’s not really an argument for or against.
You could certainly end up getting unexpected updates while the servers are alive if you don’t proactively disable it in your image, so yes it is still a concern.
A compromised machine is surprising.
Agreed. I’ve thought about adding an “apt-get update && apt-get dist-upgrade” cron job for years now, but never do because I just like to know when and what things are changing.
I’d think so, but this is Debian. They do a lot of surprising things already, so it fits the mindset. People who don’t like surprises probably aren’t running Debian.
What you consider “surprising” is consistency and reliability, the reasons why people who don’t like surprises do run Debian en masse.
I’m suspicious of automatic updates, but less so with Debian than anything else, because their release management is so good that their unstable branch is more stable than some people’s releases. But I think the current system of just auto-installing security updates and packages from the updates suite (contains things like tzdata, spamassassin, clamav… things that are only useful if they’re up to date) is good enough for me :)