On Sat, Mar 17, 2018 at 03:09:55PM +0000, Dimitri John Ledkov wrote: > On 16 March 2018 at 22:13, Steve Langasek <steve.langa...@ubuntu.com> wrote: > > In other words: if we want to make this the default, we should quantify > > Daniel's remark that he would prefer a 6% faster download over a 10% faster > > unpack.
> Well, I think it does not make sense to think about this in absolute > terms. Thinking about user stories is better. Sure. > A stable series user will be mostly upgrading packages from -security > and -updates. The download speed and/or size of debs does not matter > much in this case, as these are scheduled to be done in the background > over the course of the day, via unattended upgrades download timer. > Installation speed matters, as that is the window of time when the > system is actually somewhat in a maintenance mode / degraded > performance (apt is locked, there are CPU and disk-io loads). Does unattended upgrades download both -security and -updates, or does it only download -security? From what I can see in /usr/bin/unattended-upgrade, the allowed-origins check applies to both the downloads and the installation. So by default, increases in the download time of non-security SRUs would be perceivable by the user (though perhaps not of interest). > New instance initialization - e.g. spinning up a cloud instance, with > cloud-init, and installing a bunch of things; deploying juju charm / > conjure-up spell; configuring things with puppet / ansible / etc => > these are download & install heavy. However, users that do that > heavily, will be in a corporate / bussiness / datacentre environment > and thus it is reasonable to expect them to have either a fat internet > pipe, and/or a local mirror. Meaning download speed & size, are not > critical. Generally agreed (but the assertion should still be tested, not assumed). > Then there are devel series users, developers who do sbuild builds, > etc. These users are most likely to be on slower home-user connections > and watch things a lot more closely interactively, who indeed care > about the total download+install time. These users, are most likely > very vocal / visible, but are not ultimately the target audience as to > why we develop Ubuntu in the first place. Thus I would be willing to > trade personal developer/devel-series user experience, in favor of the > stable series user. I'm not sure how much it makes sense to > proxy/cache/local-mirror devel series, if it is only a single machine > in use. I disagree that we don't develop Ubuntu for developers. The developer desktop continues to be an important use case, and while it shouldn't necessarily dominate every time there is tension between the desktop and server use cases, it also shouldn't be ignored. But furthermore, I think there's a separate use case you've not included here, which is "client user selects a piece of software for installation and wants to use it immediately". In that case, the total clock time from expression of intent, to when the package can be used, does matter. And it's not limited to developers of Ubuntu or people tracking the devel series; this is relevant to the usability of the desktop in stable releases. It is also, I would argue, the use case that is most important in terms of its impact on user satisfaction, because it's precisely in the critical path of a task that has the user's attention; whereas improvements to the other use cases may improve overall efficiency, but have little or no proximate benefit to the human user. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel