On 6 March 2013 12:20, Scott Kitterman <[email protected]> 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 <[email protected]> Distinguished Technologist HP Cloud Services -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
