Absolutely. If updates are not triggered by the user, they should be as
non-invasive as possible. I think ChromeOS is currently setting the bar in
that regard, where updates are fetched in the background, and eventually a
notification prompts users to restart into the new system, which only takes
a few seconds.
On Thu, Aug 29, 2019 at 9:24 AM Nex Adn <nexadn@xxxxxxx> wrote:
This would be a nice idea at least to pre-download updates. I don't
think this feature will be that useful for installing new software, as
this won't happen that often on most systems–at least not often enough
for some algorithm to determine which software the user might want to
install next, but for updates (especially large packages) it might be
extremely useful.
If such a mechanism would be implemented, it'd also need a bandwidth
limit to use only as much bandwidth as currently isn't used by the user
themself.
Am Mittwoch, den 28.08.2019, 14:50 -0600 schrieb Boris Verkhovskiy:
What's faster than waiting a few seconds to install ack? Having to
wait
only a few milliseconds because the latest version was already
downloaded
but hidden from the system until the user explicitly asked for it to
be
installed.
It would be cool if I could set a certain "cache" size (like maybe 5-
10GB)
for software that I might download. How distri would populate this
"cache"
is a fun question. Easiest would be to have analytics keeping track
of what
people download (like Homebrew does) (or a hand curated sorting of
all the
packages informed by analytics someone else did) and downloading as
many of
the most downloaded packages as you can fit. Another way might be
some
statistical model that predicts the next program a user will install
based
on what they've installed already (preferably running on the client).
It would be quite a bit of complexity and you'd use a lot of
resources to
keep the software in the cache up to date, but it could be a major
improvement for real world user-percived package manager speed.
