6:50 p.m.
OK I'm going to display some total KDE ignorance here, hopefully a KDE
user can answer this.
On GNOME, gnome-software + packagekit + systemd work together to make
the user aware of software updates. This includes any installed
applications, as well as OS + kernel updates. The user clicks on
Restart & Install in gnome-software, or chooses that option in the
reboot/poweroff panel. The system reboots, a special systemd offline
updates target is triggered, and packagekit installs all the
previously downloaded rpms with a progress indicator, then reboots
(again).
So I'm wondering what the equivalent is on KDE, with about that much detail.
Thanks,
--
Chris Murphy
7:47 p.m.
On 03/24/2015 05:39 PM, Patrick O'Callaghan wrote:
So updating any package, no matter how trivial, means rebooting?
Speaking as someone who has never been a Gnome user, thanks for the
clarification. KDE certainly does not do this. I don't know if any other
DE does.
That's right if, and only if you use Gnome's built in package updater.
If you use yum, yumex or dnf, you're not forced to reboot.
12:14 p.m.
On Fri, 2015-03-27 at 00:54 +1030, Tim wrote:
On Thu, 2015-03-26 at 12:58 +0000, Patrick O'Callaghan wrote:
> What would be genuinely useful would be a tool to tell you how to get
> to a clean system with minimum fuss, e.g. one of:
>
> * restart the following user processes: a b c ...
> * log out and in again
> * reboot the system
Rather than tell you how to do it, it ought to ask you whether its
allowed to do what it needs to. i.e. Tell you that it needs to restart
the following listed services, and you'd allow or defer it.
I meant the list to be read as a menu to be clicked on.
And if there was a mixture, such as restarting Apache, re-logging to
apply things to pertaining to your desktop, and rebooting for a new
kernel. You'd individually authorise each step, skip any you want to
defer, or just go for a reboot to avoid typing in "y" a dozen times.
More complicated but sure.
It's the computer, not you, let it do the damn work.
Exactly.
poc
9:24 a.m.
On Thu, 2015-03-26 at 12:58 +0000, Patrick O'Callaghan wrote:
What would be genuinely useful would be a tool to tell you how to
get
to a clean system with minimum fuss, e.g. one of:
* restart the following user processes: a b c ...
* log out and in again
* reboot the system
Rather than tell you how to do it, it ought to ask you whether its
allowed to do what it needs to. i.e. Tell you that it needs to restart
the following listed services, and you'd allow or defer it.
And if there was a mixture, such as restarting Apache, re-logging to
apply things to pertaining to your desktop, and rebooting for a new
kernel. You'd individually authorise each step, skip any you want to
defer, or just go for a reboot to avoid typing in "y" a dozen times.
It's the computer, not you, let it do the damn work.
--
tim@localhost ~]$ uname -rsvp
Linux 3.18.9-100.fc20.i686 #1 SMP Mon Mar 9 17:04:05 UTC 2015 i686
All mail to my mailbox is automatically deleted, there is no point trying
to privately email me, I will only read messages posted to the public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
7:58 a.m.
On Thu, 2015-03-26 at 14:29 +1030, Tim wrote:
Any package that needs a restart (whether that be an update of the
thing itself, or an update of a library for a package that will
require the thing to be restarted) can have a flag in its RPM that
lets the system know. We already have that feature, don't we? Put
the onus on the package maintainers to determine if a restart is
needed, and pour scorn on those who stupidly just enable it when it's
not needed.
needs-restarting already detects automatically when a running process is
using an obsoleted component, except for the kernel, and since most
people keep at least 2 or 3 kernels around, you can usually (always?)
put off rebooting a new kernel until you're ready.
What would be genuinely useful would be a tool to tell you how to get to
a clean system with minimum fuss, e.g. one of:
* restart the following user processes: a b c ...
* log out and in again
* reboot the system
You could even wrap it in a GUI to keep the CLI-challenged happy.
poc
3:21 a.m.
On 26 March 2015 at 01:25, Marko Vojinovic <vvmarko(a)gmail.com> wrote:
On Thu, 26 Mar 2015 01:01:36 +0000
Patrick O'Callaghan <pocallaghan(a)gmail.com> wrote:
> On Wed, 2015-03-25 at 16:42 -0700, Rick Stevens wrote:
> > If you update libraries a running program uses, it won't get the new
> > libraries until it is restarted since it's already got a copy. In
> > fact, I think any program that starts and wants that updated library
> > will get the old version as it's already in memory.
>
> Are you sure of that? I always assumed that shared libraries are just
> files and once a file is replaced the normal rules apply, i.e.
> anything that opened it before the replacement gets the old version,
> anything that opens it afterwards gets the new one. That's how
> inconsistencies can arise.
I'd second that question. I can easily imagine a running program which
loads a library on *demand*, not on its start-up. So a program may
start regularly, work for a while, and then try to load some library ---
only to find out that the library was updated to an incompatible version
in the meantime.
Yum will of course make sure that there is a new version of the program
itself which is compatible with the new library, but that is not
necessarily the version of the program currently running in memory.
At least, that's how I tend to explain firefox-updating glitches to
myself. :-)
It may be that firefox is one of a few applications that work this
way. My understanding, which could be wrong, is that linked dynamic
libraries (those that get found by the compiler and linked while
building, because they are used by a program in a normal 'call this
function' way and without which available it will not build) get found
and loaded at start time. There are system calls to allow you to read
in functions from libraries at run time, these are less commonly used
as it's harder work and only needed for things like providing module
support. Applications doing that are still likely to search for and
load their modules at start-up, but could still try to load more
functions later. Not sure what firefox is having to do to keep tabs
separate from each other, may be loading separate instances of
libraries for that.
--
imalone
http://ibmalone.blogspot.co.uk
8:25 p.m.
On Thu, 26 Mar 2015 01:01:36 +0000
Patrick O'Callaghan <pocallaghan(a)gmail.com> wrote:
On Wed, 2015-03-25 at 16:42 -0700, Rick Stevens wrote:
> If you update libraries a running program uses, it won't get the new
> libraries until it is restarted since it's already got a copy. In
> fact, I think any program that starts and wants that updated library
> will get the old version as it's already in memory.
Are you sure of that? I always assumed that shared libraries are just
files and once a file is replaced the normal rules apply, i.e.
anything that opened it before the replacement gets the old version,
anything that opens it afterwards gets the new one. That's how
inconsistencies can arise.
I'd second that question. I can easily imagine a running program which
loads a library on *demand*, not on its start-up. So a program may
start regularly, work for a while, and then try to load some library ---
only to find out that the library was updated to an incompatible version
in the meantime.
Yum will of course make sure that there is a new version of the program
itself which is compatible with the new library, but that is not
necessarily the version of the program currently running in memory.
At least, that's how I tend to explain firefox-updating glitches to
myself. :-)
Best, :-)
Marko
8:01 p.m.
On Wed, 2015-03-25 at 16:42 -0700, Rick Stevens wrote:
If you update libraries a running program uses, it won't get the
new
libraries until it is restarted since it's already got a copy. In
fact, I think any program that starts and wants that updated library
will get the old version as it's already in memory.
Are you sure of that? I always assumed that shared libraries are just
files and once a file is replaced the normal rules apply, i.e. anything
that opened it before the replacement gets the old version, anything
that opens it afterwards gets the new one. That's how inconsistencies
can arise.
poc
6:42 p.m.
On 03/25/2015 03:39 PM, Martin Cigorraga wrote:
Hello Richards,
Quite interesting to actually talk to someone who actually has his hands
dirty and can talk about this issue :)
I remember reading a Lennart's post on his blog about a future when
packages will be installing in their own spaces and all of this managed
by systemd.
That exists in two forms: docker and CoreOS. Both really designed for
virtualization stuff (like AWS). Indeed, setting up CoreOS on real
hardware is a right pain in the arse.
Now my question (may be an innocent one, I'm full aware
of that) is:
Why a core technology piece like the kernel can be patched in place
(and I hope we see this awesome feature implemented in the neigh time)
but on the contrary there is so much trouble when trying to upgrade other
'simpler' (if you allow me) pieces of software?
Damn, I believe that even systemd is designed in a way it can be
hot-upgraded too without the need of rebooting the system...
Thanks for your time.
I can't say exactly what the criteria are for Linux (a lot of my
experience goes back to other OSes), but I'll take a whack at it.
In my experience, it's very dangerous to try to patch the _running_
kernel. One could snapshot it into another chunk of RAM, patch that
copy, then switch control to it by poking address registers on the CPU.
I'd say it's very involved and still prone to problems (and note I said
patching, not installing a new kernel).
Updating software that isn't running is trivial. Updating software that
_is_ running also is trivial as long as you keep in mind that the
running program is the program BEFORE the update. It's already loaded
into RAM, pulled in the libraries it wants loaded along with their
private data areas (BSS and data segments). You'd need to stop the
currently running program and reload the image from disk (re-run) to
get the new version.
If you update libraries a running program uses, it won't get the new
libraries until it is restarted since it's already got a copy. In fact,
I think any program that starts and wants that updated library will get
the old version as it's already in memory.
Some programs demand that they be restarted when updated (actually,
that's usually part of the package manager's "postinstall" stuff),
typically because the patches or whatever fix a really bad bug or
security issue. Some maintainers are a bit overly zealous in this
area and insist on restarts even for minor fixes.
There are cases where even a library update might mandate a reboot. For
example, let's say there's a big security fix in glibc. I can easily
see that insisting on a reboot since pretty much EVERYTHING uses glibc.
To ensure everything is using the new library, you really would need a
reboot. If you're truly paranoid, a full-tilt hard (power-off, wait,
power-on) reboot to make sure RAM is clean of any potential evil code
still lurking around.
"Just because I'm paranoid doesn't mean they AREN'T out to get me!"
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- Trying to make digital files uncopyable is like trying to make -
- water not wet. -- Bruce Schneier -
----------------------------------------------------------------------
6 p.m.
On 03/25/2015 03:52 PM, Kevin Cummings wrote:
Yes, I know that.*My* response was to another user's question of
why
Fedora has a needs-updating program (which you removed), which I could
not find, but I*did* find a needs-restarting program....
Ah. It looked to me as though you were simply expressing surprise that
such a program exists.
5:52 p.m.
On 03/25/2015 06:35 PM, Joe Zeff wrote:
On 03/25/2015 02:38 PM, Kevin Cummings wrote:
>
> needs-restarting?
>
Yes. It's part of yum-utils and will give you a list of every program
(except the kernel) that needs to be restarted because of an update. starting
will throw a large number of spurious errors about not being able to
examine parts of /proc if run as a regular user, but still give the
right answers. Much simpler to run it as root.
Yes, I know that. *My* response was to another user's question of why
Fedora has a needs-updating program (which you removed), which I could
not find, but I *did* find a needs-restarting program....
--
Kevin J. Cummings
kjchome(a)verizon.net
cummings(a)kjchome.homeip.net
cummings(a)kjc386.framingham.ma.us
Registered Linux User #1232 (http://www.linuxcounter.net/)
5:39 p.m.
Hello Richards,
Quite interesting to actually talk to someone who actually has his hands
dirty and can talk about this issue :)
I remember reading a Lennart's post on his blog about a future when
packages will be installing in their own spaces and all of this managed
by systemd. Now my question (may be an innocent one, I'm full aware
of that) is:
Why a core technology piece like the kernel can be patched in place
(and I hope we see this awesome feature implemented in the neigh time)
but on the contrary there is so much trouble when trying to upgrade other
'simpler' (if you allow me) pieces of software?
Damn, I believe that even systemd is designed in a way it can be
hot-upgraded too without the need of rebooting the system...
Thanks for your time.
-Martin
On Wed, Mar 25, 2015 at 8:36 AM, Richard Hughes <hughsient(a)gmail.com> wrote:
On 25 March 2015 at 04:22, Tim <ignored_mailbox(a)yahoo.com.au>
wrote:
> Jeez, but that sounds such a crap encumbrance. Even just a log out and
> log back in again is a severe nuisance. It's beginning to sound a lot
> like Windows; built for morons, by morons.
Michael is right. Updating online works 99.8% of the time. The 0.1%
time it will corrupt random bits of your file-system, and 0.1% of the
time it will leave you vulnerable to the security issue you thought
you just "fixed". The only way to fix this so that online updates are
safe is to redesign the centralised shared package model we use for
distributing applications. The workaround is to use offline updates.
This moron has spent about 10 years working on the issue.
Richard
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
5:35 p.m.
On 03/25/2015 02:38 PM, Kevin Cummings wrote:
needs-restarting?
Yes. It's part of yum-utils and will give you a list of every program
(except the kernel) that needs to be restarted because of an update. It
will throw a large number of spurious errors about not being able to
examine parts of /proc if run as a regular user, but still give the
right answers. Much simpler to run it as root.
4:38 p.m.
On 03/25/2015 04:27 PM, Patrick O'Callaghan wrote:
On Wed, 2015-03-25 at 13:34 +0000, Richard Hughes wrote:
> On 25 March 2015 at 13:01, Patrick O'Callaghan <pocallaghan(a)gmail.com>
wrote:
>> Even for updates to running
>> programs, or the DE itself, rebooting is often not necessary.
>
> If you find a reliable race-free way of working out which packages can
> safely be updated at runtime, please let me know. Also, any solution
> that relies on just looking at what binary links a certain shared
> library will be referred to the D-Bus homepage.
So why does Fedora provide a command called "needs-updating"?
needs-restarting?
poc
--
Kevin J. Cummings
kjchome(a)verizon.net
cummings(a)kjchome.homeip.net
cummings(a)kjc386.framingham.ma.us
Registered Linux User #1232 (http://www.linuxcounter.net/)
3:27 p.m.
On Wed, 2015-03-25 at 13:34 +0000, Richard Hughes wrote:
On 25 March 2015 at 13:01, Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
> Even for updates to running
> programs, or the DE itself, rebooting is often not necessary.
If you find a reliable race-free way of working out which packages can
safely be updated at runtime, please let me know. Also, any solution
that relies on just looking at what binary links a certain shared
library will be referred to the D-Bus homepage.
So why does Fedora provide a command called "needs-updating"?
poc
1:28 p.m.
On 15-03-25 07:36:08, Richard Hughes wrote:
On 25 March 2015 at 04:22, Tim <ignored_mailbox(a)yahoo.com.au>
wrote:
> Jeez, but that sounds such a crap encumbrance. Even just a log out
and
> log back in again is a severe nuisance. It's beginning to sound a
lot
> like Windows; built for morons, by morons.
Michael is right. Updating online works 99.8% of the time. The 0.1%
time it will corrupt random bits of your file-system,
...
Wow! Can you give an example where this happened?
--
____________________________________________________________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>
8:34 a.m.
On 25 March 2015 at 13:01, Patrick O'Callaghan <pocallaghan(a)gmail.com> wrote:
Even for updates to running
programs, or the DE itself, rebooting is often not necessary.
If you find a reliable race-free way of working out which packages can
safely be updated at runtime, please let me know. Also, any solution
that relies on just looking at what binary links a certain shared
library will be referred to the D-Bus homepage.
Richard
8:01 a.m.
On Wed, 2015-03-25 at 12:07 +0100, Michael Schwendt wrote:
On Wed, 25 Mar 2015 14:52:11 +1030, Tim wrote:
> Patrick O'Callaghan:
> >> So updating any package, no matter how trivial, means rebooting?
> >> Speaking as someone who has never been a Gnome user, thanks for the
> >> clarification. KDE certainly does not do this. I don't know if any
other
> >> DE does.
>
> Joe Zeff:
> > That's right if, and only if you use Gnome's built in package updater.
> > If you use yum, yumex or dnf, you're not forced to reboot.
>
> Jeez, but that sounds such a crap encumbrance. Even just a log out and
> log back in again is a severe nuisance. It's beginning to sound a lot
> like Windows; built for morons, by morons.
How do you restart already running processes after an upgrade of system
libraries and/or services, for example?
I type "systemctl restart <whatever>". Isn't that supposed one of the
selling points of systemd?
And to repeat (again): many updates are not to running software, so why
should the user be forced to reboot? Even for updates to running
programs, or the DE itself, rebooting is often not necessary.
poc
7:56 a.m.
On Tue, 2015-03-24 at 17:47 -0700, Joe Zeff wrote:
On 03/24/2015 05:39 PM, Patrick O'Callaghan wrote:
> So updating any package, no matter how trivial, means rebooting?
> Speaking as someone who has never been a Gnome user, thanks for the
> clarification. KDE certainly does not do this. I don't know if any other
> DE does.
That's right if, and only if you use Gnome's built in package updater.
If you use yum, yumex or dnf, you're not forced to reboot.
Of course, but in that case the DE is immaterial.
poc
6:36 a.m.
On 25 March 2015 at 04:22, Tim <ignored_mailbox(a)yahoo.com.au> wrote:
Jeez, but that sounds such a crap encumbrance. Even just a log out
and
log back in again is a severe nuisance. It's beginning to sound a lot
like Windows; built for morons, by morons.
Michael is right. Updating online works 99.8% of the time. The 0.1%
time it will corrupt random bits of your file-system, and 0.1% of the
time it will leave you vulnerable to the security issue you thought
you just "fixed". The only way to fix this so that online updates are
safe is to redesign the centralised shared package model we use for
distributing applications. The workaround is to use offline updates.
This moron has spent about 10 years working on the issue.
Richard
6:07 a.m.
On Wed, 25 Mar 2015 14:52:11 +1030, Tim wrote:
Patrick O'Callaghan:
>> So updating any package, no matter how trivial, means rebooting?
>> Speaking as someone who has never been a Gnome user, thanks for the
>> clarification. KDE certainly does not do this. I don't know if any other
>> DE does.
Joe Zeff:
> That's right if, and only if you use Gnome's built in package updater.
> If you use yum, yumex or dnf, you're not forced to reboot.
Jeez, but that sounds such a crap encumbrance. Even just a log out and
log back in again is a severe nuisance. It's beginning to sound a lot
like Windows; built for morons, by morons.
How do you restart already running processes after an upgrade of system
libraries and/or services, for example?
Log out and log back in is not enough.
2:23 a.m.
On 03/25/2015 12:18 AM, Tim wrote:
On Tue, 2015-03-24 at 17:33 +0000, Patrick O'Callaghan wrote:
> quite frequently I can update packages without restarting anything, so
> forcing a restart would be overkill.
Thus far, I can only remember finding Firefox to foul up if you try
to
keep using it when an update has been installed. Obviously you need to
fully quit and restart it to use the new version, but not so obvious is
that it doesn't always fully quit when you think it should have.
I'm pretty sure that Thunderbird suffers from the same affliction,
though maybe not as severely.
--
Kevin J. Cummings
kjchome(a)verizon.net
cummings(a)kjchome.homeip.net
cummings(a)kjc386.framingham.ma.us
Registered Linux User #1232 (http://www.linuxcounter.net/)
11:22 p.m.
Patrick O'Callaghan:
> So updating any package, no matter how trivial, means rebooting?
> Speaking as someone who has never been a Gnome user, thanks for the
> clarification. KDE certainly does not do this. I don't know if any other
> DE does.
Joe Zeff:
That's right if, and only if you use Gnome's built in package
updater.
If you use yum, yumex or dnf, you're not forced to reboot.
Jeez, but that sounds such a crap encumbrance. Even just a log out and
log back in again is a severe nuisance. It's beginning to sound a lot
like Windows; built for morons, by morons.
--
tim@localhost ~]$ uname -rsvp
Linux 3.18.9-100.fc20.i686 #1 SMP Mon Mar 9 17:04:05 UTC 2015 i686
All mail to my mailbox is automatically deleted, there is no point trying
to privately email me, I will only read messages posted to the public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
11:18 p.m.
On Tue, 2015-03-24 at 17:33 +0000, Patrick O'Callaghan wrote:
quite frequently I can update packages without restarting anything,
so
forcing a restart would be overkill.
Likewise... Though, these days, I'm running Mate on a current release,
rather than Gnome (I'm using Gnome on some out-of-date installs).
Thus far, I can only remember finding Firefox to foul up if you try to
keep using it when an update has been installed. Obviously you need to
fully quit and restart it to use the new version, but not so obvious is
that it doesn't always fully quit when you think it should have.
Though I don't use a great deal of software, it's rare that I'm using
much more than a web browser, mail client, IM client, text editor, and a
command line terminal. A few other things get started, from time to
time, but those are the few that will be running nearly any time I'm
logged in.
Over the years, I've been pleasantly surprised at how well most things
(just about everything) handled updates being applied while they were
running.
--
tim@localhost ~]$ uname -rsvp
Linux 3.18.9-100.fc20.i686 #1 SMP Mon Mar 9 17:04:05 UTC 2015 i686
All mail to my mailbox is automatically deleted, there is no point trying
to privately email me, I will only read messages posted to the public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
7:39 p.m.
On Tue, 2015-03-24 at 18:24 -0600, Chris Murphy wrote:
> That's fine. It's just that from your description I had
the
impression
> that the only way to apply updates was from this Restart & Install
> action.
If you're using the graphical package manager, yes, this is the only
way.
So updating any package, no matter how trivial, means rebooting?
Speaking as someone who has never been a Gnome user, thanks for the
clarification. KDE certainly does not do this. I don't know if any other
DE does.
poc
7:24 p.m.
On Tue, Mar 24, 2015 at 5:57 PM, Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
On Tue, 2015-03-24 at 11:40 -0600, Chris Murphy wrote:
> On Tue, Mar 24, 2015 at 5:14 AM, Patrick O'Callaghan
> <pocallaghan(a)gmail.com> wrote:
> > On Mon, 2015-03-23 at 17:50 -0600, Chris Murphy wrote:
> >> OK I'm going to display some total KDE ignorance here, hopefully a KDE
> >> user can answer this.
> >
> > Note that there's a Fedora-KDE list at
> > https://admin.fedoraproject.org/mailman/listinfo/kde
> >
> >> On GNOME, gnome-software + packagekit + systemd work together to make
> >> the user aware of software updates. This includes any installed
> >> applications, as well as OS + kernel updates. The user clicks on
> >> Restart & Install in gnome-software, or chooses that option in the
> >> reboot/poweroff panel. The system reboots, a special systemd offline
> >> updates target is triggered, and packagekit installs all the
> >> previously downloaded rpms with a progress indicator, then reboots
> >> (again).
> >
> > You mean Gnome makes you reboot for every update? I must be
> > misunderstanding what you're saying.
>
> OS updates yes. If it's strictly an application update or install, no.
That's fine. It's just that from your description I had the impression
that the only way to apply updates was from this Restart & Install
action.
If you're using the graphical package manager, yes, this is the only way.
--
Chris Murphy
6:57 p.m.
On Tue, 2015-03-24 at 11:40 -0600, Chris Murphy wrote:
On Tue, Mar 24, 2015 at 5:14 AM, Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
> On Mon, 2015-03-23 at 17:50 -0600, Chris Murphy wrote:
>> OK I'm going to display some total KDE ignorance here, hopefully a KDE
>> user can answer this.
>
> Note that there's a Fedora-KDE list at
> https://admin.fedoraproject.org/mailman/listinfo/kde
>
>> On GNOME, gnome-software + packagekit + systemd work together to make
>> the user aware of software updates. This includes any installed
>> applications, as well as OS + kernel updates. The user clicks on
>> Restart & Install in gnome-software, or chooses that option in the
>> reboot/poweroff panel. The system reboots, a special systemd offline
>> updates target is triggered, and packagekit installs all the
>> previously downloaded rpms with a progress indicator, then reboots
>> (again).
>
> You mean Gnome makes you reboot for every update? I must be
> misunderstanding what you're saying.
OS updates yes. If it's strictly an application update or install, no.
That's fine. It's just that from your description I had the impression
that the only way to apply updates was from this Restart & Install
action.
poc
12:40 p.m.
On Tue, Mar 24, 2015 at 5:14 AM, Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
On Mon, 2015-03-23 at 17:50 -0600, Chris Murphy wrote:
> OK I'm going to display some total KDE ignorance here, hopefully a KDE
> user can answer this.
Note that there's a Fedora-KDE list at
https://admin.fedoraproject.org/mailman/listinfo/kde
> On GNOME, gnome-software + packagekit + systemd work together to make
> the user aware of software updates. This includes any installed
> applications, as well as OS + kernel updates. The user clicks on
> Restart & Install in gnome-software, or chooses that option in the
> reboot/poweroff panel. The system reboots, a special systemd offline
> updates target is triggered, and packagekit installs all the
> previously downloaded rpms with a progress indicator, then reboots
> (again).
You mean Gnome makes you reboot for every update? I must be
misunderstanding what you're saying.
OS updates yes. If it's strictly an application update or install, no.
--
Chris Murphy
12:33 p.m.
On Tue, 2015-03-24 at 15:38 +0100, Michael Schwendt wrote:
On Tue, 24 Mar 2015 12:45:26 +0000, Patrick O'Callaghan wrote:
> I don't use Gnome so my understanding of this is based only on a literal
> reading. It appears to say that packages are updated with a tool which
> among other things causes two reboots. Obviously I know that the user
> might just employ yum as I do myself (on KDE) but the description of the
> GUI tool is quite specific. Which is why I asked if that's what really
> happens. Call it a rhetorical question.
You sound as if you're surprised that an update tool applies offline
updates with the help of rebooting.
The way the description was phrased is not specifically limited to
offline updates (they are only mentioned in the message Subject), but
rather makes it sound as if this was how *all* updating is normally done
under Gnome. I still don't know if that's the case or not. Makes it
sound like Windows.
It has never been entirely safe to update/upgrade with Yum. Simply
because Yum does not take any precautions, such as making sure the
user doesn't use a program while upgrading it, or killing and
restarting services in a way it doesn't harm the runtime environment.
Offline updates remove some of the pitfalls.
Of course. Every time I use yum I check (using needs-restarting) to see
what has to be done. However quite frequently I can update packages
without restarting anything, so forcing a restart would be overkill. But
as I say, I still don't know of that is what is being said.
poc
11:49 a.m.
On Tue, 24 Mar 2015, Patrick O'Callaghan wrote:
On Mon, 2015-03-23 at 17:50 -0600, Chris Murphy wrote:
> OK I'm going to display some total KDE ignorance here, hopefully a KDE
> user can answer this.
Note that there's a Fedora-KDE list at
https://admin.fedoraproject.org/mailman/listinfo/kde
Hey! Thanks. I didn't know that.
billo
9:38 a.m.
On Tue, 24 Mar 2015 12:45:26 +0000, Patrick O'Callaghan wrote:
I don't use Gnome so my understanding of this is based only on a
literal
reading. It appears to say that packages are updated with a tool which
among other things causes two reboots. Obviously I know that the user
might just employ yum as I do myself (on KDE) but the description of the
GUI tool is quite specific. Which is why I asked if that's what really
happens. Call it a rhetorical question.
You sound as if you're surprised that an update tool applies offline
updates with the help of rebooting.
It has never been entirely safe to update/upgrade with Yum. Simply
because Yum does not take any precautions, such as making sure the
user doesn't use a program while upgrading it, or killing and
restarting services in a way it doesn't harm the runtime environment.
Offline updates remove some of the pitfalls.
7:45 a.m.
On Tue, 2015-03-24 at 12:44 +0100, Michael Schwendt wrote:
On Tue, 24 Mar 2015 11:14:46 +0000, Patrick O'Callaghan wrote:
> You mean Gnome makes you reboot for every update? I must be
> misunderstanding what you're saying.
Why? Would you mind explaining your thoughts?
To quote the OP:
On GNOME, gnome-software + packagekit + systemd work together to make
the user aware of software updates. This includes any installed
applications, as well as OS + kernel updates. The user clicks on
Restart & Install in gnome-software, or chooses that option in the
reboot/poweroff panel. The system reboots, a special systemd offline
updates target is triggered, and packagekit installs all the
previously downloaded rpms with a progress indicator, then reboots
(again).
I don't use Gnome so my understanding of this is based only on a literal
reading. It appears to say that packages are updated with a tool which
among other things causes two reboots. Obviously I know that the user
might just employ yum as I do myself (on KDE) but the description of the
GUI tool is quite specific. Which is why I asked if that's what really
happens. Call it a rhetorical question.
poc
6:14 a.m.
On Mon, 2015-03-23 at 17:50 -0600, Chris Murphy wrote:
OK I'm going to display some total KDE ignorance here, hopefully
a KDE
user can answer this.
Note that there's a Fedora-KDE list at
https://admin.fedoraproject.org/mailman/listinfo/kde
On GNOME, gnome-software + packagekit + systemd work together to
make
the user aware of software updates. This includes any installed
applications, as well as OS + kernel updates. The user clicks on
Restart & Install in gnome-software, or chooses that option in the
reboot/poweroff panel. The system reboots, a special systemd offline
updates target is triggered, and packagekit installs all the
previously downloaded rpms with a progress indicator, then reboots
(again).
You mean Gnome makes you reboot for every update? I must be
misunderstanding what you're saying.
poc
8:45 p.m.
Chris Murphy wrote:
OK I'm going to display some total KDE ignorance here, hopefully
a KDE
user can answer this.
On GNOME, gnome-software + packagekit + systemd work together to make
the user aware of software updates. This includes any installed
applications, as well as OS + kernel updates. The user clicks on
Restart & Install in gnome-software, or chooses that option in the
reboot/poweroff panel. The system reboots, a special systemd offline
updates target is triggered, and packagekit installs all the
previously downloaded rpms with a progress indicator, then reboots
(again).
So I'm wondering what the equivalent is on KDE, with about that much
detail.
KDE's packagekit client, apper, does not support offline updates, as far as
I'm aware.
-- Rex
7:02 p.m.
Hello Chris,
It's been awhile since I used KDE for last time but IIRC, both Apper (which
I tried back on Arch) and Muon (Kubuntu's package manager) supports offline
updates.
However at that time none of those systems where using systemd...
I will ask to my friends and let you know.
-M.
10:59 p.m.
Tim:
> Jeez, but that sounds such a crap encumbrance. Even just a log
out
> and log back in again is a severe nuisance. It's beginning to sound
> a lot like Windows; built for morons, by morons.
Michael Schwendt:
How do you restart already running processes after an upgrade of
system libraries and/or services, for example?
Log out and log back in is not enough.
Some of us abandoned crap OSs, like Windows, because we were sick of its
reboot disease. Going down that route is seriously annoying. It means
you can't do an update without having to set aside time to waste as you
go through at least one reboot. And, with Windows, their "reboot all
the time" attitude can mean several reboots, as it just doesn't seem to
cope with doing everything in one step. Oh look, something changed,
better reboot...
Are we, now, going to have that same problem as some things can't handle
a state change, that are going to get upset while you're trying to
reboot? I've certainly seen Windows get stuck in a prolonged reboot
loop. Hell, I've even watched an entire movie while waiting for Windows
to finish an update cycle.
Any package that needs a restart (whether that be an update of the thing
itself, or an update of a library for a package that will require the
thing to be restarted) can have a flag in its RPM that lets the system
know. We already have that feature, don't we? Put the onus on the
package maintainers to determine if a restart is needed, and pour scorn
on those who stupidly just enable it when it's not needed.
The update routine could retrigger the restart at the appropriate time.
Far better to have the update routines restart a few processes while the
computer carries on, than require me to be doing nothing on the PC while
its updating, and then waste more time with reboots. And far better,
for us, to not have restarts and reboots inflicted upon us if we do not
really need them.
--
tim@localhost ~]$ uname -rsvp
Linux 3.18.9-100.fc20.i686 #1 SMP Mon Mar 9 17:04:05 UTC 2015 i686
All mail to my mailbox is automatically deleted, there is no point trying
to privately email me, I will only read messages posted to the public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
3319
days inactive
3322
days old
37 comments
14 participants
participants (14)
-
Chris Murphy -
Ian Malone -
Joe Zeff -
Kevin Cummings -
Marko Vojinovic -
Martin Cigorraga -
Michael Schwendt -
Patrick O'Callaghan -
Rex Dieter -
Richard Hughes -
Rick Stevens -
Tim -
Tony Nelson -
William Oliver