-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 23 Oct 2014 10:56:00 +0200
Miroslav Suchý msu...@redhat.com wrote:
On 10/22/2014 09:07 PM, Michael Stahl wrote:
the important point in that case is not reboot after upgrading
Firefox but*before* upgrading Firefox, which means that at
On Wed, Oct 22, 2014 at 11:35:00PM +0100, Ian Malone wrote:
On 22 October 2014 20:07, Michael Stahl mst...@redhat.com wrote:
On 17.09.2014 13:58, Miroslav Suchý wrote:
On 09/17/2014 11:54 AM, Bastien Nocera wrote:
All those OSes require reboots when updating the OS.
Define OS.
On 10/23/2014 12:57 PM, Reindl Harald wrote:
The upgrade can last one hour (more or less).
An hour?! Most of my offline updates take a few tens of seconds with
F21. Is this on fairly up-to-date SSD hardware? Are any specific
packages taking longer than the others?
an hour was surely
On Fri, 2014-10-24 at 12:00 +0200, Miroslav Suchý wrote:
I'm not updating daily. I upgraded my machine IIRC 2-3 weeks ago. So lets
benchmark it and provide you real data.
My machine have classic magnetic disk, however in SW RAID1.
Timing cached reads: 12236 MB in 2.00 seconds = 6124.59
On 24 October 2014 11:00, Miroslav Suchý msu...@redhat.com wrote:
I run dnf upgrade and I have been offered 853 packages and 1.3 GB to
download.
I'm pretty sure F21 for the last few weeks is not representative of a
normal installed system over a 2 week period. 853 must be close to
every package
Am 24.10.2014 um 12:02 schrieb Mathieu Bridon:
On Fri, 2014-10-24 at 12:00 +0200, Miroslav Suchý wrote:
I'm not updating daily. I upgraded my machine IIRC 2-3 weeks ago. So lets
benchmark it and provide you real data.
My machine have classic magnetic disk, however in SW RAID1.
Timing
On 10/24/2014 12:59 PM, Richard Hughes wrote:
853 must be close to
every package on your box...
Nope.
$ rpm -qa |wc -l
4337
--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
devel mailing list
devel@lists.fedoraproject.org
On 10/22/2014 09:07 PM, Michael Stahl wrote:
the important point in that case is not reboot after upgrading Firefox
but*before* upgrading Firefox, which means that at the time of the
upgrade no Firefox will be running and potentially crashing because one
of the 100s of DSOs it loads on-demand
On 23 October 2014 09:56, Miroslav Suchý msu...@redhat.com wrote:
The upgrade can last one hour (more or less).
An hour?! Most of my offline updates take a few tens of seconds with
F21. Is this on fairly up-to-date SSD hardware? Are any specific
packages taking longer than the others?
Richard
On Thu, Oct 23, 2014 at 11:43:29AM +0100, Richard Hughes wrote:
On 23 October 2014 09:56, Miroslav Suchý msu...@redhat.com wrote:
The upgrade can last one hour (more or less).
An hour?! Most of my offline updates take a few tens of seconds with
F21. Is this on fairly up-to-date SSD
Am 23.10.2014 um 12:43 schrieb Richard Hughes:
On 23 October 2014 09:56, Miroslav Suchý msu...@redhat.com wrote:
The upgrade can last one hour (more or less).
An hour?! Most of my offline updates take a few tens of seconds with
F21. Is this on fairly up-to-date SSD hardware? Are any specific
Am 23.10.2014 um 12:52 schrieb Daniel P. Berrange:
On Thu, Oct 23, 2014 at 11:43:29AM +0100, Richard Hughes wrote:
On 23 October 2014 09:56, Miroslav Suchý msu...@redhat.com wrote:
The upgrade can last one hour (more or less).
An hour?! Most of my offline updates take a few tens of seconds
On 10/21/2014 10:08 PM, Lennart Poettering wrote:
Offline updates are more for the cases where things need to be
reliable, because no well educated admin is available to instantly fix
things.
I will print it an pin up on my notice board.
And the implication is that offline updates are not for
On Tue, 16.09.14 13:35, Petr Pisar (ppi...@redhat.com) wrote:
On 2014-09-16, Richard Hughes hughsi...@gmail.com wrote:
The much bigger issues is if you're using a D-Bus service
like most applications seem to do (and most use quite a few system and
session, directly and indirectly) then
On Wed, 17.09.14 13:58, Miroslav Suchý (msu...@redhat.com) wrote:
On 09/17/2014 11:54 AM, Bastien Nocera wrote:
All those OSes require reboots when updating the OS.
Define OS.
Firefox is definitely not OS. While systemd is OS.
I am fine with reboot after systemd upgrade, but not after
On Wed, Oct 22, 2014 at 08:48:59AM +0200, Miroslav Suchý wrote:
Offline updates are more for the cases where things need to be
reliable, because no well educated admin is available to instantly
fix things.
I will print it an pin up on my notice board.
And the implication is that offline
On 10/21/2014 10:02 PM, Lennart Poettering wrote:
Maybe
that's actually a strategy to adopt here: upload the encryption keys
into the firmware as efi vars, and then pull them out on next boots or
so (assuming that efi vars can be marked to survive soft reboots
without making them fully
On Wed, 22.10.14 14:11, Roberto Ragusa (m...@robertoragusa.it) wrote:
On 10/21/2014 10:02 PM, Lennart Poettering wrote:
Maybe
that's actually a strategy to adopt here: upload the encryption keys
into the firmware as efi vars, and then pull them out on next boots or
so (assuming that
On 22 October 2014 04:31, Lennart Poettering mzerq...@0pointer.de wrote:
On Wed, 17.09.14 13:58, Miroslav Suchý (msu...@redhat.com) wrote:
On 09/17/2014 11:54 AM, Bastien Nocera wrote:
All those OSes require reboots when updating the OS.
Define OS.
Firefox is definitely not OS.
On 10/22/2014 06:31, Lennart Poettering wrote:
It would be great if we could nicely isolate the apps from the OS so
that we can restart the apps independently from the OS, but this
requires isolating things first.
Isn't the differentiation between kernel space and user space sufficient
for
On Wed, Oct 22, 2014 at 4:45 PM, Tom Rivers t...@impact-crater.com wrote:
On 10/22/2014 06:31, Lennart Poettering wrote:
It would be great if we could nicely isolate the apps from the OS so that
we can restart the apps independently from the OS, but this requires
isolating things first.
On 10/22/2014 10:58, drago01 wrote:
No the OS is more than just a kernel.
Kernel Space contains more than just the kernel. It also contains
device drivers, kernel extensions, and other privileged processes that
require full system access. User Space exists as a barrier to keep
On 17.09.2014 13:58, Miroslav Suchý wrote:
On 09/17/2014 11:54 AM, Bastien Nocera wrote:
All those OSes require reboots when updating the OS.
Define OS.
Firefox is definitely not OS. While systemd is OS.
I am fine with reboot after systemd upgrade, but not after upgrading Firefox.
the
On 22 October 2014 20:07, Michael Stahl mst...@redhat.com wrote:
On 17.09.2014 13:58, Miroslav Suchý wrote:
On 09/17/2014 11:54 AM, Bastien Nocera wrote:
All those OSes require reboots when updating the OS.
Define OS.
Firefox is definitely not OS. While systemd is OS.
I am fine with reboot
On Mon, 2014-10-13 at 11:26 -0400, Stephen Gallagher wrote:
On Thu, 2014-10-02 at 07:53 -0400, Stephen Gallagher wrote:
On Fri, 2014-09-12 at 10:46 -0400, Stephen Gallagher wrote:
== The Problem ==
It is very common for users to have systems with encrypted root
On Fri, 12.09.14 10:46, Stephen Gallagher (sgall...@redhat.com) wrote:
It is very common for users to have systems with encrypted root
partitions (or even just /var and /etc). This may be due to a
personal
Nitpicking: we currently do not support split-off /etc on
Fedora/Dracut. /var may be
On Fri, 12.09.14 18:37, Reindl Harald (h.rei...@thelounge.net) wrote:
Am 12.09.2014 um 18:33 schrieb Nathanael d. Noblet:
So I don't use Firefox anymore but I do know back in the day if we had
FF open when we updated it would do a double request for each page/form.
However when updating
Am 21.10.2014 um 22:08 schrieb Lennart Poettering:
On Fri, 12.09.14 18:37, Reindl Harald (h.rei...@thelounge.net) wrote:
1 out of a million cases needs offline updates
really - the only good at it is that you can stick
at using YUM and decide what you have to do at your
own - rarely updates
On Thu, 2014-10-02 at 07:53 -0400, Stephen Gallagher wrote:
On Fri, 2014-09-12 at 10:46 -0400, Stephen Gallagher wrote:
== The Problem ==
It is very common for users to have systems with encrypted root
partitions (or even just /var and /etc). This may be due to a personal
On Fri, 2014-09-12 at 10:46 -0400, Stephen Gallagher wrote:
== The Problem ==
It is very common for users to have systems with encrypted root
partitions (or even just /var and /etc). This may be due to a personal
concern for their data or a corporate policy mandating full-disk
- Original Message -
Dne 16.9.2014 v 17:29 Matthias Clasen napsal(a):
On Tue, 2014-09-16 at 16:21 +0200, Zdenek Kabelac wrote:
Has Fedora given up Unix ??
This thread has gone quite far out into the weeds. It started with a
fairly concrete question: can we improve the
On 09/17/2014 11:54 AM, Bastien Nocera wrote:
All those OSes require reboots when updating the OS.
Define OS.
Firefox is definitely not OS. While systemd is OS.
I am fine with reboot after systemd upgrade, but not after upgrading Firefox.
And there we have lots of packages in between those
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/16/2014 04:02 PM, Lukáš Tinkl wrote:
Dne 16.9.2014 v 17:29 Matthias Clasen napsal(a):
On Tue, 2014-09-16 at 16:21 +0200, Zdenek Kabelac wrote:
Has Fedora given up Unix ??
This thread has gone quite far out into the weeds. It started
On 15 September 2014 13:06, Miroslav Suchý msu...@redhat.com wrote:
But *I* do not want to reboot after each upgrade. Those crashes will be
0.1% of all crashes on my workstation
I think you might change your mind when it's you're the one that has
to triage those ABRT-reported bugs. Also,
Am 16.09.2014 um 10:50 schrieb Richard Hughes:
On 15 September 2014 13:06, Miroslav Suchý msu...@redhat.com wrote:
But *I* do not want to reboot after each upgrade. Those crashes will be
0.1% of all crashes on my workstation
I think you might change your mind when it's you're the one
On 09/12/2014 05:47 PM, Richard Hughes wrote:
That's just not safe. Have you ever had firefox open and done a
firefox update? Widgets start disappearing, redraws start having weird
artifects and then after a little while it just crashes. Other
applications like LibreOffice behave the same.
On 16 September 2014 10:36, Roberto Ragusa m...@robertoragusa.it wrote:
If applications would just use libraries correctly, the kernel
would be able to let parts of deleted files be available for lazy
loading.
Sure, as long as all[1] the resources were either open()d when the
user started the
Dne 16.9.2014 v 11:48 Richard Hughes napsal(a):
On 16 September 2014 10:36, Roberto Ragusa m...@robertoragusa.it wrote:
If applications would just use libraries correctly, the kernel
would be able to let parts of deleted files be available for lazy
loading.
Sure, as long as all[1] the
On 16 September 2014 10:55, Zdenek Kabelac zkabe...@redhat.com wrote:
Just a thought - but wouldn't be better spend time to enlighten
Gnome/Firefox developers how to write applications in a way the could be
upgraded runtime
So, it's not just the application, it's every application and D-Bus
Am 16.09.2014 um 12:21 schrieb Richard Hughes:
On 16 September 2014 10:55, Zdenek Kabelac zkabe...@redhat.com wrote:
Just a thought - but wouldn't be better spend time to enlighten
Gnome/Firefox developers how to write applications in a way the could be
upgraded runtime
So, it's not just
On 16 September 2014 11:26, Reindl Harald h.rei...@thelounge.net wrote:
and the other side of the story are some hundret dist-upgrades i
made in the past years with YUM (in a screen session for safety)
while just continue to browse the web and read / answer email
So you're saying my technical
On 09/16/2014 06:33 AM, Richard Hughes wrote:
I've triaged many bugs to do with online and offline update failures,
and if we're going to say that we actually care about the users data,
it becomes increasingly hard to defend the old way of doing it. I'm
sure I could find numerous bugs numbers
On Tue, Sep 16, 2014 at 8:29 AM, Przemek Klosowski
przemek.klosow...@nist.gov wrote:
On 09/16/2014 06:33 AM, Richard Hughes wrote:
I've triaged many bugs to do with online and offline update failures, and
if we're going to say that we actually care about the users data, it becomes
On 16 September 2014 13:29, Przemek Klosowski
przemek.klosow...@nist.gov wrote:
OK, but this is means that we painted ourselves in the corner---something is
wrong if my Android phone, which I don't have to reboot for updates, has
higher uptime than my computer.
Right, we certainly have. By
On 2014-09-16, Richard Hughes hughsi...@gmail.com wrote:
The much bigger issues is if you're using a D-Bus service
like most applications seem to do (and most use quite a few system and
session, directly and indirectly) then you've also got to co-ordinate
and handle changing D-Bus API (which
Dne 16.9.2014 v 12:21 Richard Hughes napsal(a):
On 16 September 2014 10:55, Zdenek Kabelac zkabe...@redhat.com wrote:
Just a thought - but wouldn't be better spend time to enlighten
Gnome/Firefox developers how to write applications in a way the could be
upgraded runtime
So, it's not just the
- Original Message -
Dne 16.9.2014 v 12:21 Richard Hughes napsal(a):
On 16 September 2014 10:55, Zdenek Kabelac zkabe...@redhat.com wrote:
Just a thought - but wouldn't be better spend time to enlighten
Gnome/Firefox developers how to write applications in a way the could be
Dne 16.9.2014 v 16:39 Miloslav Trmač napsal(a):
- Original Message -
Dne 16.9.2014 v 12:21 Richard Hughes napsal(a):
On 16 September 2014 10:55, Zdenek Kabelac zkabe...@redhat.com wrote:
Just a thought - but wouldn't be better spend time to enlighten
Gnome/Firefox developers how to
- Original Message -
Well, what we would need is:
1. Ability to keep multiple versions (both ABI-compatible and
ABI-incompatible) of a single application or library or service installed
and running at the same time.
Other distributions allow to install multiple version of same
Dne 16.9.2014 v 17:08 Miloslav Trmač napsal(a):
- Original Message -
Well, what we would need is:
1. Ability to keep multiple versions (both ABI-compatible and
ABI-incompatible) of a single application or library or service installed
and running at the same time.
Other distributions
On Tue, 2014-09-16 at 16:21 +0200, Zdenek Kabelac wrote:
Has Fedora given up Unix ??
This thread has gone quite far out into the weeds. It started with a
fairly concrete question: can we improve the offline update experience
by requiring only a single reboot, instead of two ?
I'd still be
- Original Message -
Dne 16.9.2014 v 17:08 Miloslav Trmač napsal(a):
- Original Message -
Well, what we would need is:
1. Ability to keep multiple versions (both ABI-compatible and
ABI-incompatible) of a single application or library or service installed
and running at
Dne 16.9.2014 v 17:36 Miloslav Trmač napsal(a):
- Original Message -
2. Ability to detect which processes depend on which versions of which
components.
We already managed to brought in systemd
I can’t see how systemd helps. See the other discussions about Python/Ruby
modules
Dne 16.9.2014 v 17:29 Matthias Clasen napsal(a):
On Tue, 2014-09-16 at 16:21 +0200, Zdenek Kabelac wrote:
Has Fedora given up Unix ??
This thread has gone quite far out into the weeds. It started with a
fairly concrete question: can we improve the offline update experience
by requiring only
On 09/12/2014 07:09 PM, Reindl Harald wrote:
never worked relieable here on multiple machines
it often showed nothing where i knew the thing
which should be restarted without looking and
lsof proved it
I am one of those guys who refuse to reboot after each upgrade (and it works for me) and
On Mon, Sep 15, 2014 at 09:50:36AM +0200, Miroslav Suchý wrote:
On 09/12/2014 07:09 PM, Reindl Harald wrote:
never worked relieable here on multiple machines
it often showed nothing where i knew the thing
which should be restarted without looking and
lsof proved it
I am one of those guys
On 09/15/2014 10:06 AM, Richard W.M. Jones wrote:
It wasn't clear to me how tracer works for non-C programs.
https://github.com/FrostyX/tracer/commit/4abfc4ecbc6d1d4cd89b7162e1ba3f63088db3ff
Which basicaly checkout output of `ps` and if there is e.g. python as
executable, it will check for
Every of the script is based on assumption that you already read some
library/unit whatever. But that is not enough. I wonder how you want to
detect that you need restart in case that I have something like this:
$ ls
foo.rb
bar.rb
$ cat foo.rb
def some_function
require 'bar'
end
And now
1)
On 09/15/2014 10:57 AM, Vít Ondruch wrote:
Every of the script is based on assumption that you already read some
library/unit whatever. But that is not enough. I wonder how you want to
detect that you need restart in case that I have something like this:
$ ls
foo.rb
bar.rb
$ cat foo.rb
def
On Mon, Sep 15, 2014 at 10:57:13AM +0200, Vít Ondruch wrote:
Every of the script is based on assumption that you already read some
library/unit whatever. But that is not enough. I wonder how you want to
detect that you need restart in case that I have something like this:
$ ls
foo.rb
Am 15.09.2014 um 14:28 schrieb Richard W.M. Jones:
On Mon, Sep 15, 2014 at 10:57:13AM +0200, Vít Ondruch wrote:
1) I run some application, which loads my foo.rb file.
2) I later update the package which removes bar.rb file.
3) And I call some_function which fails due to missing bar.rb
How
On Mon, Sep 15, 2014 at 02:40:34PM +0200, Reindl Harald wrote:
Am 15.09.2014 um 14:28 schrieb Richard W.M. Jones:
On Mon, Sep 15, 2014 at 10:57:13AM +0200, Vít Ondruch wrote:
1) I run some application, which loads my foo.rb file.
2) I later update the package which removes bar.rb file.
Am 15.09.2014 um 14:44 schrieb Richard W.M. Jones:
On Mon, Sep 15, 2014 at 02:40:34PM +0200, Reindl Harald wrote:
Am 15.09.2014 um 14:28 schrieb Richard W.M. Jones:
On Mon, Sep 15, 2014 at 10:57:13AM +0200, Vít Ondruch wrote:
1) I run some application, which loads my foo.rb file.
2) I
On Mon, Sep 15, 2014 at 02:49:34PM +0200, Reindl Harald wrote:
Am 15.09.2014 um 14:44 schrieb Richard W.M. Jones:
On Mon, Sep 15, 2014 at 02:40:34PM +0200, Reindl Harald wrote:
Am 15.09.2014 um 14:28 schrieb Richard W.M. Jones:
On Mon, Sep 15, 2014 at 10:57:13AM +0200, Vít Ondruch
Dne 15.9.2014 14:28, Richard W.M. Jones napsal(a):
On Mon, Sep 15, 2014 at 10:57:13AM +0200, Vít Ondruch wrote:
Every of the script is based on assumption that you already read some
library/unit whatever. But that is not enough. I wonder how you want to
detect that you need restart in case
On Mon, Sep 15, 2014 at 04:07:39PM +0200, Vít Ondruch wrote:
Dne 15.9.2014 14:28, Richard W.M. Jones napsal(a):
On Mon, Sep 15, 2014 at 10:57:13AM +0200, Vít Ondruch wrote:
Every of the script is based on assumption that you already read some
library/unit whatever. But that is not enough. I
On Sat, Sep 13, 2014 at 3:32 AM, Chris Murphy li...@colorremedies.com
wrote:
On Sep 12, 2014, at 9:47 AM, Richard Hughes hughsi...@gmail.com wrote:
The *only* way to do this
securely and safely in the system we have now is in a clean pre-boot
environment,
Mostly clean post-boot
On 09/13/2014 03:59 AM, Fred New wrote:
One step up from this would be something like a kpatch process in rpm
combined with packaged metadata that replaces in-memory modules so that
reboots wouldn't be necessary. Yeh, probably impossible.
This has almost certainly already been considered by
the keys are in kernelspace IIRC and thus updated / passed on initrd
/initramfs updates and kernel updates
Corey W Sheldon
Freelance IT Consultant, Multi-Discipline Tutor
310.909.7672
www.facebook.com/1stclassmobileshine
On Sat, Sep 13, 2014 at 7:01 PM, Ian Pilcher arequip...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
== The Problem ==
It is very common for users to have systems with encrypted root
partitions (or even just /var and /etc). This may be due to a personal
concern for their data or a corporate policy mandating full-disk
encryption. Disk encryption
On 12 September 2014 16:16, Nathanael d. Noblet nathan...@gnat.ca wrote:
Yeah, I almost never use the reboot install method. 90% of the
packages being installed/updated seem foolish to need a reboot to
update.
I've been called worse that foolish I guess...
I typically do a yum update
Am 12.09.2014 um 18:33 schrieb Nathanael d. Noblet:
So I don't use Firefox anymore but I do know back in the day if we had
FF open when we updated it would do a double request for each page/form.
However when updating we just restarted FF and it would work fine after
that. I've never noticed
On Fri, 2014-09-12 at 16:47 +0100, Richard Hughes wrote:
On 12 September 2014 16:16, Nathanael d. Noblet nathan...@gnat.ca wrote:
Yeah, I almost never use the reboot install method. 90% of the
packages being installed/updated seem foolish to need a reboot to
update.
I've been called
On Fri, Sep 12, 2014 at 06:37:07PM +0200, Reindl Harald wrote:
* lsof | grep DEL | grep /usr and restart services on servers
There is a convenient script called needs-restarting to do this.
Checkrestart on debian even suggest potential init scripts that can be
used to restart the services.
--
Am 12.09.2014 um 18:58 schrieb Till Maas:
On Fri, Sep 12, 2014 at 06:37:07PM +0200, Reindl Harald wrote:
* lsof | grep DEL | grep /usr and restart services on servers
There is a convenient script called needs-restarting to do this.
Checkrestart on debian even suggest potential init
On Fri, Sep 12, 2014 at 10:33:13AM -0600, Nathanael d. Noblet wrote:
I am curious though. Everyone says the only way to do it securely and
safely is with nothing running. Why can't updates be applied with stuff
running prior to a reboot?
There's no reason, apart from the kernel. You're doing
Am 12.09.2014 um 23:36 schrieb Richard W.M. Jones:
On Fri, Sep 12, 2014 at 10:33:13AM -0600, Nathanael d. Noblet wrote:
I am curious though. Everyone says the only way to do it securely and
safely is with nothing running. Why can't updates be applied with stuff
running prior to a reboot?
On Sep 12, 2014, at 9:47 AM, Richard Hughes hughsi...@gmail.com wrote:
The *only* way to do this
securely and safely in the system we have now is in a clean pre-boot
environment,
Mostly clean post-boot environment, with the system we have now?
What we could do is do updates on shutdown by
78 matches
Mail list logo
