1:12 p.m.
With the move to more mobile devices (laptops, etc.), we're more likely to
have very long-running sessions that are just suspended and resumed, as
opposed to a workstation that is logged out every day.
This means that for me on rawhide, my session is often much longer-lived than my
software set, as I'll have a two-week session that is running older code
that I've long since upgraded past. Even for those on an actual release,
this can be an issue given our update stream.
For system-level services, we have the idea of try-restart on upgrades; if
the service is running, we automatically restart it on upgrade. How can
we implement this sanely for session/desktop services? For example, in
my session I see:
gvfsd
obex-client/obex-data-server
evolution-data-server
packagekitd
notification-daemon
any number of status icons (volume control, gpk, g-p-m, etc.)
... and more I'm forgetting ...
Since very few of these have state, can't we implement a framework where
they automatically get restarted on upgrade?
Bill
1:24 p.m.
On Tue, Sep 29, 2009 at 8:12 PM, Bill Nottingham <notting(a)redhat.com> wrote:
With the move to more mobile devices (laptops, etc.), we're more
likely to
have very long-running sessions that are just suspended and resumed, as
opposed to a workstation that is logged out every day.
This means that for me on rawhide, my session is often much longer-lived than my
software set, as I'll have a two-week session that is running older code
that I've long since upgraded past. Even for those on an actual release,
this can be an issue given our update stream.
For system-level services, we have the idea of try-restart on upgrades; if
the service is running, we automatically restart it on upgrade. How can
we implement this sanely for session/desktop services? For example, in
my session I see:
gvfsd
Wouldn't this affect current mounts?
1:33 p.m.
On Tue, 2009-09-29 at 14:12 -0400, Bill Nottingham wrote:
With the move to more mobile devices (laptops, etc.), we're more
likely to
have very long-running sessions that are just suspended and resumed, as
opposed to a workstation that is logged out every day.
This means that for me on rawhide, my session is often much longer-lived than my
software set, as I'll have a two-week session that is running older code
that I've long since upgraded past. Even for those on an actual release,
this can be an issue given our update stream.
For system-level services, we have the idea of try-restart on upgrades; if
the service is running, we automatically restart it on upgrade. How can
we implement this sanely for session/desktop services? For example, in
my session I see:
gvfsd
obex-client/obex-data-server
evolution-data-server
packagekitd
notification-daemon
any number of status icons (volume control, gpk, g-p-m, etc.)
... and more I'm forgetting ...
Since very few of these have state, can't we implement a framework where
they automatically get restarted on upgrade?
Brainstorming: perhaps when rpm updates/deletes a file it could look at
what processes are mapping that file (in particular ELF files), and thus
build a list for a transaction of all PIDs that now have stale data
(e.g. using old versions of a .so file that now has a security fix in
the new on-disk version).
No idea how to pass this information up through yum/PackageKit in a
useful way though.
Hope this is helpful
Dave
1:40 p.m.
On Tue, 29 Sep 2009, David Malcolm wrote:
> gvfsd
> obex-client/obex-data-server
> evolution-data-server
> packagekitd
> notification-daemon
> any number of status icons (volume control, gpk, g-p-m, etc.)
> ... and more I'm forgetting ...
>
> Since very few of these have state, can't we implement a framework where
> they automatically get restarted on upgrade?
Brainstorming: perhaps when rpm updates/deletes a file it could look at
what processes are mapping that file (in particular ELF files), and thus
build a list for a transaction of all PIDs that now have stale data
(e.g. using old versions of a .so file that now has a security fix in
the new on-disk version).
No idea how to pass this information up through yum/PackageKit in a
useful way though.
at the risk of getting myself in trouble - you don't have to do it at the
rpm layer... You could do it in yum or in a yum plugin and then not have
to worry about propagating it up the stack.
-sv
1:42 p.m.
Seth Vidal (skvidal(a)fedoraproject.org) said:
at the risk of getting myself in trouble - you don't have to do
it
at the rpm layer... You could do it in yum or in a yum plugin and
then not have to worry about propagating it up the stack.
The alternative is to have apps set inotify watches on their own
binaries, I suppose. (There was something in Fedora that used to
do this.)
Bill
1:44 p.m.
On Tue, 29 Sep 2009, Bill Nottingham wrote:
Seth Vidal (skvidal(a)fedoraproject.org) said:
> at the risk of getting myself in trouble - you don't have to do it
> at the rpm layer... You could do it in yum or in a yum plugin and
> then not have to worry about propagating it up the stack.
The alternative is to have apps set inotify watches on their own
binaries, I suppose. (There was something in Fedora that used to
do this.)
wow, that would be, umm, special.
How well does inotify cope with THOUSANDS of watches?
-sv
1:46 p.m.
On Tue, Sep 29, 2009 at 8:44 PM, Seth Vidal <skvidal(a)fedoraproject.org> wrote:
On Tue, 29 Sep 2009, Bill Nottingham wrote:
> Seth Vidal (skvidal(a)fedoraproject.org) said:
>>
>> at the risk of getting myself in trouble - you don't have to do it
>> at the rpm layer... You could do it in yum or in a yum plugin and
>> then not have to worry about propagating it up the stack.
>
> The alternative is to have apps set inotify watches on their own
> binaries, I suppose. (There was something in Fedora that used to
> do this.)
wow, that would be, umm, special.
How well does inotify cope with THOUSANDS of watches?
There is a 8k limit for non root users, besides that sounds racy (what
if the binary changed but some lib is still not updated and the soname
got bumped?) so it will restart itself while the upgrade process is
still running an fail.
3:42 p.m.
tis 2009-09-29 klockan 20:46 +0200 skrev drago01:
There is a 8k limit for non root users, besides that sounds racy
(what
if the binary changed but some lib is still not updated and the soname
got bumped?) so it will restart itself while the upgrade process is
still running an fail.
Hmm, true.
When rpm is done with a transaction, it provides a list of files it
modified. The next step is to send a signal to all processes that has
any of those files open and has indicated that it is capable of dealing
with such signals, so that the process can take appropriate action. That
should catch the binary and all loaded libraries. Should be enough,
right?
Maybe DBus is the right way to broadcast that list of files? Either send
the whole list to all recipients that asks for it or filter it for each
process based on its open files.
In the case of shared roots, you want to do this on each machine that
has this filesystem mounted. Can't it just be a program that takes a
list of paths on stdin and broadcasts it? Normally run directly by rpm
or yum but in some cases triggered by other means, like manually when
the sysadmin released an update to the shared root?
/abo
1:46 p.m.
On Tue, Sep 29, 2009 at 6:12 PM, Bill Nottingham <notting(a)redhat.com> wrote:
This means that for me on rawhide, my session is often much longer-lived
than my
software set, as I'll have a two-week session that is running older code
that I've long since upgraded past. Even for those on an actual release,
this can be an issue given our update stream.
Note we should optimize the system for the main release, not rawhide. Not
that a good rawhide experience isn't useful, but it's a rather extreme case.
For system-level services, we have the idea of try-restart on upgrades; if
the service is running, we automatically restart it on upgrade.
How does that work? Obviously you can't restart packagekitd while it's in
the middle of upgrading. Another one you obviously can't just kill and
restart is libvirtd.
How can
we implement this sanely for session/desktop services? For example, in
my session I see:
I think this ends up being a case by case thing. If someone wants to
implement things so that a live upgrade works, that's all well and good.
The default state though must be reliable; so any generic mechanism that
kills processes blindly is just not going to work.
If someone wanted to work on this, packagekit may already have a signal for
when things are upgraded, and it could make sense to just listen to that.
The live replace files on disk part of upgrade is also problematic, and is
actually the most broken thing relating to updates we have right now. For
this reason among others I think we should move to installing updates
immediately before logout/reboot.
1:51 p.m.
Colin Walters (walters(a)verbum.org) said:
For system-level services, we have the idea of try-restart on
upgrades; if
> the service is running, we automatically restart it on upgrade.
How does that work? Obviously you can't restart packagekitd while it's in
the middle of upgrading. Another one you obviously can't just kill and
restart is libvirtd.
Actually, libvirtd does restart on upgrade. It's implemented in the
init scripts.
The live replace files on disk part of upgrade is also problematic,
and is
actually the most broken thing relating to updates we have right now. For
this reason among others I think we should move to installing updates
immediately before logout/reboot.
Really? I think we're moving more towards a model on mobile devices where
there *is* no logout/reboot except by accident in a large number of cases.
Bill
1:08 p.m.
On Tue, 29 Sep 2009 14:51:29 -0400, Bill Nottingham <notting(a)redhat.com>
wrote:
I think the mobility argument is a very valid one, but it isn't truly
specific to mobile devices. I log out/log back in on my desktop or laptop
about as much as my phone runs out of juice, sorta speak (unless I forget
my phone in Rheinfelden, that is).
What we have to remember is the type of security issue you would want to
require a reboot/restart for. If it's a memory leak, for instance, then hey
all of a sudden my device isn't going to work the way I want it. I'll
restart the application myself, or reboot my device. Either one is pretty
much intuitive to a no-know, including my girlfriend (in fact it's the
first thing she does and *then* she calls me her PC was sooooo slow, and
she's glad a reboot solved the problem *sigh*).
If it's a majorly important
"you-are-going-to-be-hacked-standing-too-close-to-starfucks" type of
security issue, then hey... your call drops, your application restarts, and
maybe you lose a session where you had this amazing one-liner with all
kinds of ifs and fors and whiles and awks and seds. There's a price either
way for these kinds of bugs, right?
-- Jeroen
Really? I think we're moving more towards a model on mobile
devices where
there *is* no logout/reboot except by accident in a large number of
cases.
2:19 p.m.
On Tue, Sep 29, 2009 at 6:51 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Colin Walters (walters(a)verbum.org) said:
> For system-level services, we have the idea of try-restart on upgrades;
if
> > the service is running, we automatically restart it on upgrade.
>
>
> How does that work? Obviously you can't restart packagekitd while it's
in
> the middle of upgrading. Another one you obviously can't just kill and
> restart is libvirtd.
Actually, libvirtd does restart on upgrade. It's implemented in the
init scripts.
But...hm, ok, so all of the state is in the config data/cache, and child
qemu processes I guess. The real point here is the qemu processes.
The live replace files on disk part of upgrade is also problematic,
and is
> actually the most broken thing relating to updates we have right now.
For
> this reason among others I think we should move to installing updates
> immediately before logout/reboot.
Really? I think we're moving more towards a model on mobile devices where
there *is* no logout/reboot except by accident in a large number of cases.
The update system should prompt to start installing updates and
automatically do a logout/reboot as necessary.
2:23 p.m.
On Tue, 29 Sep 2009, Colin Walters wrote:
On Tue, Sep 29, 2009 at 6:51 PM, Bill Nottingham
<notting(a)redhat.com> wrote:
Colin Walters (walters(a)verbum.org) said:
> For system-level services, we have the idea of try-restart on upgrades; if
> > the service is running, we automatically restart it on upgrade.
>
>
> How does that work? Obviously you can't restart packagekitd while
it's in
> the middle of upgrading. Another one you obviously can't just kill and
> restart is libvirtd.
Actually, libvirtd does restart on upgrade. It's implemented in the
init scripts.
But...hm, ok, so all of the state is in the config data/cache, and child qemu processes I
guess. The real point here is
the qemu processes.
> The live replace files on disk part of upgrade is also problematic, and is
> actually the most broken thing relating to updates we have right now. For
> this reason among others I think we should move to installing updates
> immediately before logout/reboot.
Really? I think we're moving more towards a model on mobile devices where
there *is* no logout/reboot except by accident in a large number of cases.
The update system should prompt to start installing updates and automatically do a
logout/reboot as necessary.
And I think what Bill is saying is that a lot of users will not want to
logout. They will want to just restart the app in question, if they are
told which apps are impacted.
I don't expect to have to reboot just b/c of an issue in the sound server.
-sv
2:28 p.m.
On Tue, Sep 29, 2009 at 7:23 PM, Seth Vidal <skvidal(a)fedoraproject.org>wrote:
And I think what Bill is saying is that a lot of users will not want to
logout. They will want to just restart the app in question, if they are told
which apps are impacted.
This is what I meant in saying it's case by case, not something where one
policy applies to all software. If you just updated Firefox, then yes, we
can and should have a system which knows how to restart just that
application.
The discussion started about infrastructure bits, like:
I don't expect to have to reboot just b/c of an issue in the
sound server.
Not reboot for this one but relogin. Well, you can choose not to of course,
but the point of an update is to actually update what's running on people's
computers. If the system doesn't reliably get us there it's not working..
2:32 p.m.
On Tue, 29 Sep 2009, Colin Walters wrote:
On Tue, Sep 29, 2009 at 7:23 PM, Seth Vidal
<skvidal(a)fedoraproject.org> wrote:
And I think what Bill is saying is that a lot of users will not want to logout. They will
want to just restart the
app in question, if they are told which apps are impacted.
This is what I meant in saying it's case by case, not something where one policy
applies to all software. If you just
updated Firefox, then yes, we can and should have a system which knows how to restart
just that application.
The discussion started about infrastructure bits, like:
I don't expect to have to reboot just b/c of an issue in the sound server.
Not reboot for this one but relogin. Well, you can choose not to of course, but the
point of an update is to actually
update what's running on people's computers. If the system doesn't reliably
get us there it's not working..
So what was suggested by dmalcolm was tracking down which programs in use
are being updated/changed and telling the user 'this application that is
currently in use by [userid] needs to be restarted to take advantage of
this update'.
I was suggesting we could get that info in yum and make it available.
-sv
2:45 p.m.
On Tue, Sep 29, 2009 at 7:32 PM, Seth Vidal <skvidal(a)fedoraproject.org>wrote:
So what was suggested by dmalcolm was tracking down which programs in use
are being updated/changed and telling the user 'this application that is
currently in use by [userid] needs to be restarted to take advantage of this
update'.
By program do you mean package, or .desktop file? There's a big difference,
in that we expect all desktop users to know roughly what the things are
named by .desktop, but if we have a UI with packages it's going to contain
incomprehensible stuff (what is gvfs? what is pulseaudio? What is...).
All of this should basically all be grouped under "Operating System" with a
"Details |>" expander to see the packages for power users.
We could probably implement generic application restart using
http://live.gnome.org/GnomeShell/ApplicationBased
by sending a close event to the app's windows. It wouldn't be awful to
backport this to GNOME 2.
But there's just no way you can have some generic system for the
infrastructure, and we need the logout/reboot system for that.
3:05 p.m.
On Tue, 2009-09-29 at 15:32 -0400, Seth Vidal wrote:
On Tue, 29 Sep 2009, Colin Walters wrote:
> On Tue, Sep 29, 2009 at 7:23 PM, Seth Vidal <skvidal(a)fedoraproject.org>
wrote:
>
> And I think what Bill is saying is that a lot of users will not want to logout. They
will want to just restart the
> app in question, if they are told which apps are impacted.
>
>
> This is what I meant in saying it's case by case, not something where one policy
applies to all software. If you just
> updated Firefox, then yes, we can and should have a system which knows how to
restart just that application.
>
> The discussion started about infrastructure bits, like:
>
> I don't expect to have to reboot just b/c of an issue in the sound
server.
>
>
> Not reboot for this one but relogin. Well, you can choose not to of course, but the
point of an update is to actually
> update what's running on people's computers. If the system doesn't
reliably get us there it's not working..
>
So what was suggested by dmalcolm was tracking down which programs in use
are being updated/changed and telling the user 'this application that is
currently in use by [userid] needs to be restarted to take advantage of
this update'.
I was suggesting we could get that info in yum and make it available.
My thought was to do it at the level of ELF files i.e. both binaries and
the libraries consuming them. That way, if e.g. there's a libldap
update, you know which PIDs are still mapping the old implementation of
that file on disk.
FWIW, here's some python code that tells you files per PID and PIDs per
file; this code also spots e.g. .mo files, shared fontconfig caches,
etc:
import os
import re
from pprint import pprint
pids_per_file = {}
print "Files per PID:"
for pid in os.listdir('/proc'):
if re.match('([0-9]+)', pid):
pid = int(pid)
files = set()
for line in open(os.path.join('/proc', str(pid), 'maps')):
# Expect lines of the form:
# '00101000-0023e000 r-xp 00000000 fd:00 1835017 /lib/libc-2.5.so'
fields = line.split()
if len(fields) > 5:
file = fields[5]
if file.startswith('/'):
files.add(file)
if file in pids_per_file:
pids_per_file[file].append(pid)
else:
pids_per_file[file] = [pid]
print pid, files
print
print "PIDS per file:"
pprint(pids_per_file)
2:48 p.m.
On Tue, Sep 29, 2009 at 9:46 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Colin Walters (walters(a)verbum.org) said:
> > I don't expect to have to reboot just b/c of an issue in the sound server.
>
> Not reboot for this one but relogin.
How so? PA could in theory restart itself at some point when all streams
are idle, could it not?
The apps would have to reconnect to pa.
3:43 p.m.
On Tue, 2009-09-29 at 21:48 +0200, drago01 wrote:
On Tue, Sep 29, 2009 at 9:46 PM, Bill Nottingham
<notting(a)redhat.com> wrote:
> Colin Walters (walters(a)verbum.org) said:
>> > I don't expect to have to reboot just b/c of an issue in the sound
server.
>>
>> Not reboot for this one but relogin.
>
> How so? PA could in theory restart itself at some point when all streams
> are idle, could it not?
The apps would have to reconnect to pa.
Which they manage to do every time I have to killall -9 pulseaudio when
it gets wedged. Seems like we already have support for pulse going away
and coming back.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:46 p.m.
On Tue, Sep 29, 2009 at 10:43 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
On Tue, 2009-09-29 at 21:48 +0200, drago01 wrote:
> On Tue, Sep 29, 2009 at 9:46 PM, Bill Nottingham <notting(a)redhat.com> wrote:
> > Colin Walters (walters(a)verbum.org) said:
> >> > I don't expect to have to reboot just b/c of an issue in the sound
server.
> >>
> >> Not reboot for this one but relogin.
> >
> > How so? PA could in theory restart itself at some point when all streams
> > are idle, could it not?
>
> The apps would have to reconnect to pa.
>
Which they manage to do every time I have to killall -9 pulseaudio when
it gets wedged. Seems like we already have support for pulse going away
and coming back.
well the volume-applet in F11 sure does not do that which is annoying
as hell (fixed in F12 though).
9:47 a.m.
On Tue, 2009-09-29 at 22:46 +0200, drago01 wrote:
On Tue, Sep 29, 2009 at 10:43 PM, Jesse Keating
<jkeating(a)redhat.com> wrote:
> On Tue, 2009-09-29 at 21:48 +0200, drago01 wrote:
>> On Tue, Sep 29, 2009 at 9:46 PM, Bill Nottingham <notting(a)redhat.com>
wrote:
>> > Colin Walters (walters(a)verbum.org) said:
>> >> > I don't expect to have to reboot just b/c of an issue in the
sound server.
>> >>
>> >> Not reboot for this one but relogin.
>> >
>> > How so? PA could in theory restart itself at some point when all streams
>> > are idle, could it not?
>>
>> The apps would have to reconnect to pa.
>>
>
> Which they manage to do every time I have to killall -9 pulseaudio when
> it gets wedged. Seems like we already have support for pulse going away
> and coming back.
well the volume-applet in F11 sure does not do that which is annoying
as hell (fixed in F12 though).
It's also fixed in F-11, seeing as it ships the same version as F-12...
11:44 a.m.
On Wed, 2009-09-30 at 15:47 +0100, Bastien Nocera wrote:
On Tue, 2009-09-29 at 22:46 +0200, drago01 wrote:
> On Tue, Sep 29, 2009 at 10:43 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
> > On Tue, 2009-09-29 at 21:48 +0200, drago01 wrote:
> >> On Tue, Sep 29, 2009 at 9:46 PM, Bill Nottingham <notting(a)redhat.com>
wrote:
> >> > Colin Walters (walters(a)verbum.org) said:
> >> >> > I don't expect to have to reboot just b/c of an issue in
the sound server.
> >> >>
> >> >> Not reboot for this one but relogin.
> >> >
> >> > How so? PA could in theory restart itself at some point when all
streams
> >> > are idle, could it not?
> >>
> >> The apps would have to reconnect to pa.
> >>
> >
> > Which they manage to do every time I have to killall -9 pulseaudio when
> > it gets wedged. Seems like we already have support for pulse going away
> > and coming back.
>
> well the volume-applet in F11 sure does not do that which is annoying
> as hell (fixed in F12 though).
It's also fixed in F-11, seeing as it ships the same version as F-12...
It certainly wasn't for me a couple weeks ago before I upgraded to F12.
Zack
2:50 p.m.
On Tue, Sep 29, 2009 at 7:46 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Colin Walters (walters(a)verbum.org) said:
> > I don't expect to have to reboot just b/c of an issue in the sound
server.
>
> Not reboot for this one but relogin.
How so? PA could in theory restart itself at some point when all streams
are idle, could it not?
Sure. Though how long do you wait? Is it conditional on update urgency?
And pulse has a similar problem in that the stream source identification
needs the same infrastructure we're doing for the shell, so it could tell
you what applications are using it.
This is highly specific to pulse, which gets back to my point: If someone
wants to work on case-by-case for individual daemons I think that's great.
However, it's not a substitute for a default-reliable update system.
10:38 p.m.
Hey Bill,
On Tue, Sep 29, 2009 at 2:51 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Colin Walters (walters(a)verbum.org) said:
> For system-level services, we have the idea of try-restart on upgrades; if
> > the service is running, we automatically restart it on upgrade.
>
>
> How does that work? Obviously you can't restart packagekitd while it's in
> the middle of upgrading. Another one you obviously can't just kill and
> restart is libvirtd.
Actually, libvirtd does restart on upgrade. It's implemented in the
init scripts.
> The live replace files on disk part of upgrade is also problematic, and is
> actually the most broken thing relating to updates we have right now. For
> this reason among others I think we should move to installing updates
> immediately before logout/reboot.
Really? I think we're moving more towards a model on mobile devices where
there *is* no logout/reboot except by accident in a large number of cases.
Yes and no. My (linux based) phone, for example, reboots
automatically as part of the update process. However, the OS update
is bundled and occurs, so far, only once a month.
Personally, I've been advocating for our next generation update system
to do something similar.
Jon
1:51 p.m.
On Tue, Sep 29, 2009 at 8:46 PM, Colin Walters <walters(a)verbum.org> wrote:
The live replace files on disk part of upgrade is also problematic,
and is
actually the most broken thing relating to updates we have right now. For
this reason among others I think we should move to installing updates
immediately before logout/reboot.
We could just do:
1) switch to brtfs
2) have a separte /home by default
When updating:
1) create a snapshot of /
2) mount it
3) update stuff there
4) prompt for reboot
5) on reboot switch to the new snapshot
We could even keep the last one for rollback reasons.
2:20 p.m.
On Tue, 2009-09-29 at 18:46 +0000, Colin Walters wrote:
For this reason among others I think we should move to installing
updates immediately before logout/reboot.
Completely agree. FWIW, this is what most mobile "computers" such as the
iPhone and Android does. And, for the record, how OS X works too (unless
the only update is for an application like iTunes). They can of course
do this because they don't issue updates almost _every day_ (or what
feels like every day, anyway) like we do in Fedora.
So I segwayed nicely into this: I think another huge (and, I think,
well-known too) problem, which is related to this, is that we issue
updates way too often. A cause and/or effect of this is that our updates
(and main release) aren't really well-tested, at least not in my
experience. Another problem is that we're very militant in Fedora and
other distros with dynamic linking - while this sounds great on paper
(especially in 1990 when RAM was scarce), it does mean that if you
update a shared library you end up breaking many applications. There are
other downsides too, e.g. app folders. So it puts even more load on QA
that we don't really have.
Sorry if what I said sounds ranty and insulting to the Fedora community.
If it did, I didn't mean it. But I really really think that "how can we
make daemons survive lots of updates?" is the wrong question. The right
question, IMO, is "how can we ship software that doesn't need many
updates?". Which, of course, is harder to solve (the solution may
include a longer, more realistic release-cycle). But solving it brings
other benefits too.
These are tough questions. Not flamebait. Thanks.
David
2:57 p.m.
On Tue, 29 Sep 2009 15:20:01 -0400, David Zeuthen <davidz(a)redhat.com>
wrote:
On Tue, 2009-09-29 at 18:46 +0000, Colin Walters wrote:
> For this reason among others I think we should move to installing
> updates immediately before logout/reboot.
Completely agree. FWIW, this is what most mobile "computers" such as the
iPhone and Android does. And, for the record, how OS X works too (unless
the only update is for an application like iTunes). They can of course
do this because they don't issue updates almost _every day_ (or what
feels like every day, anyway) like we do in Fedora.
The major difference obviously being, that OS X is not a version of rawhide
with a release number attached to it. It is more like, dare I say it, RHEL
(in that aspect).
The ultimate problem though is not the number of updates. One can cron a
yum -y update every 5 minutes without it (euh, the updates being applied)
interrupting (m)any of the services or applications running on the system
(as long as they are running, that is).
The ultimate challenge is; how, if at all, can we make sure a running
daemon picks up the new blobs so that we can seamlessly update/upgrade,
especially with regards to "i'm in ur board eating your keez" security
issues.
Making the release cycle longer (including the development cycle) works two
ways;
1) you have more time to perform QA
2) everytime you perform QA the amount of changes is going to be bigger (53
features in 6 months anyone?)
Also, the militant attitude of Fedora against static linking works two
ways;
1) my blob runs on its own
1a) ignoring updates (security fixes anyone?) to the statically linked
other blobs. Weeeee!
1b) putting the load on all packagers of blobs depending on blob, and/or
vice-versa
2) my blob runs with the help of other blobs
And, to not continue on why it would be bad, how much RAM does your Android
have? Your iPhone? Your HTC X7500? Your HTC Touch? Is it... scarse?
Still though, the interesting question is how we can ship software that
doesn't need as many updates... like you said ;-)
-- Jeroen
4:19 p.m.
tis 2009-09-29 klockan 21:57 +0200 skrev Jeroen van Meeuwen:
And, to not continue on why it would be bad, how much RAM does your
Android
have? Your iPhone? Your HTC X7500? Your HTC Touch? Is it... scarse?
It is definitely scarce on my N810.
I don't understand why dynamic linking is a problem in this context, if
that's what you're saying.
/abo
4:44 p.m.
On Tue, 2009-09-29 at 23:19 +0200, Alexander Boström wrote:
I don't understand why dynamic linking is a problem in this context, if
that's what you're saying.
It is not a problem per se, but it a major source of our deeply nested
dependencies graphs, which make updating, installing and removing
applications harder than it would be with, say, an appfolder-like
approach. Of course, that has its own downsides...
2:57 p.m.
On Tue, 2009-09-29 at 15:20 -0400, David Zeuthen wrote:
On Tue, 2009-09-29 at 18:46 +0000, Colin Walters wrote:
> For this reason among others I think we should move to installing
> updates immediately before logout/reboot.
Completely agree. FWIW, this is what most mobile "computers" such as the
iPhone and Android does. And, for the record, how OS X works too (unless
the only update is for an application like iTunes). They can of course
do this because they don't issue updates almost _every day_ (or what
feels like every day, anyway) like we do in Fedora.
One of the things Those Other OSes do is to batch updates into larger
Service Pack / point-release updates, and only offer the individual
pieces as "hotfixes" to those who really, really need (or want) them.
If we were just trying to improve the *perception* that there's too many
updates (and they're not that useful), the simplest solution would be to
batch updates and release them as point-release updates along with
release notes and an appropriate amount of fanfare about new features
and fixes.
A cause and/or effect of this is that our updates
(and main release) aren't really well-tested, at least not in my
experience.
Well, batching updates would also mean that they'd spend more *required*
time in the testing repository. Which is a necessary step to get better
manual QA on updates. It's not sufficient to guarantee better QA -
"spends time in the testing repo" does not necessarily imply "has been
tested" - but it can't really hurt.
Furthermore, while it's obvious simpler to test a single package than a
whole load of 250 packages, it's *much* easier to test one large update
payload than each possible combination of 250 individual updates.
[snip]
So it puts even more load on QA that we don't really have.
Sorry if what I said sounds ranty and insulting to the Fedora
community.
If it did, I didn't mean it. But I really really think that "how can we
make daemons survive lots of updates?" is the wrong question. The right
question, IMO, is "how can we ship software that doesn't need many
updates?". Which, of course, is harder to solve (the solution may
include a longer, more realistic release-cycle). But solving it brings
other benefits too.
No, I totally agree - making the daemons survive updates better is
probably not the most pressing problem with the Fedora update system.
On the other hand, it's a problem that can be solved with code rather
than needing long bikesheddy discussions and policy arguments. And I
think we all know that, as a group, we're way better with code than
talk.
Still, I think it's worth trying to get some *data* about what the
*actual* problems are with the update system and see if we can't have
some good, productive discussions that lead to actual positive change.
So, uh, let's.. just.. go ahead and do that, then.
-w
5318
days inactive
5320
days old
desktop@lists.fedoraproject.org
31 comments
15 participants
participants (15)
-
Alexander Boström -
Bastien Nocera -
Bill Nottingham -
Colin Walters -
David Malcolm -
David Zeuthen -
drago01 -
Jeroen van Meeuwen -
Jesse Keating -
Matthias Clasen -
Richard Hughes -
Seth Vidal -
Will Woods -
William Jon McCann -
Zack Cerza