Monthly Updates versus Monthly Images

[Robert Collins]

On 6 March 2013 12:20, Scott Kitterman <ubuntu at kitterman.com> wrote:


>> critical updates.  I think leveraging phased-updates to that end is a
>> fairly simple, lightweight, and elegant solution that completely avoids the
>> harm and complexity of any of the proposed monthly updates schemes.
>
> I think for phased updates to be meaningful in this context it would have to
> be a bit different.  As (IIRC) Highvoltage mentioned, he wants to be at the
> back of the iceberg:
>
> http://hellenicpolytheist.files.wordpress.com/2012/07/killer_whale_eating_penguins-
> jump-in-air.jpg
>
> What's needed is not only show me updates every X days, but only show me non-
> critical updates that are at least X days old.  I don't think we have a way to
> express that.

I think this is backwards: we're trying to cross the chasm; users
don't want to have to care about updates *ever* - the industry is
moving to a model where knowing that something has updated, or not, is
quaint. First websites started to evolve rapidly, with occasional
'whats new' dialogues, a long time back now virus scanners and other
critical time-sensitive components on other operating systems started
just keeping themselves up to date all the time, and less critical
components prompt.

Most users *do not have* the knowledge about our development practices
and the reliability we achieve to reason about 'should I update daily,
weekly, monthly or 2 years'. It is a nonsensical question. They can
reason about how much risk they are willing to take: 'No risk at all
of new things breaking but I may get cracked and nothing gets better'
/ 'Low risk of things breaking but I get security updates to avoid
crackers - but nothing gets better' / 'Things might break but I get
security updates and the software gets better.'

Exact frequency is *only* meaningful because we have bugs in our
delivery infrastructure: we routinely ship 10 or 100 times as much
data as is needed (no binary deltas); we ship 10 to 100 times as much
metadata as is needed by most users (complete archive index for
everyone all the time, and no archive deltas); installation of package
updates reads again, 10 to 100 times as much data as is being altered
(change 10 packages on a system with 1000 installed, but we read the
full dpkg status file, the complete list of all files installed by any
package...); dpkg is slow (because it works very hard to be atomic).

Now clearly we can't wave a hand and just fix all those issues (and
there probably will even be debate about whether they are all in fact
issues :p) - but when we design what we want to achieve, lets design
around our users, what we can reasonably expect them to know and care
about, rather than around the plumbing we happen to have today, which
they assuredly are not interested in.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Cloud Services