9:38 p.m.
A recent discussion on Fedora forums raised the need to logout and back
after a KDE version update. I've noticed that the system becomes unstable,
last time I got a plasma crash, and others reported similar things. Is this
common or just a few people?
It was suggested that a bug should be raised for it.
9:52 p.m.
On 07/20/2011 10:38 PM, Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and
back
after a KDE version update. I've noticed that the system becomes
unstable, last time I got a plasma crash, and others reported similar
things. Is this common or just a few people?
It was suggested that a bug should be raised for it.
I have same problem.
Any update that touches kde seems to crash plasma-desktop - and
logout/login is required ..
fully updated F15 here ... did you file a bug?
9:59 p.m.
On 21 July 2011 12:52, Genes MailLists <lists(a)sapience.com> wrote:
On 07/20/2011 10:38 PM, Jim Dean wrote:
> A recent discussion on Fedora forums raised the need to logout and back
> after a KDE version update. I've noticed that the system becomes
> unstable, last time I got a plasma crash, and others reported similar
> things. Is this common or just a few people?
> It was suggested that a bug should be raised for it.
>
>
I have same problem.
Any update that touches kde seems to crash plasma-desktop - and
logout/login is required ..
fully updated F15 here ... did you file a bug?
Not yet. Wanted to see what others thought.
_______________________________________________
kde mailing list
kde(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kde
New to KDE4? - get help from http://userbase.kde.org
2:16 a.m.
Jim Dean <jdean55(a)gmail.com> wrote:
A recent discussion on Fedora forums raised the need to logout and
back
after a KDE version update. I've noticed that the system becomes
unstable, last time I got a plasma crash, and others reported similar things. Is this
common or just a few people?
It was suggested that a bug should be raised for it. mailing list
FWIW, I have not seen this problem. Last update, I waited 2 days before a logout/login.
--
Sent from my Android tablet with K-9 Mail.
8:29 a.m.
On 2011/07/21 15:16 (GMT+0800) Ed Greshko composed:
Jim Dean wrote:
> A recent discussion on Fedora forums raised the need to logout
and back
> after a KDE version update. I've noticed that the system becomes
> unstable, last time I got a plasma crash, and others reported similar things. Is
this
> common or just a few people?
FWIW, I have not seen this problem. Last update, I waited 2 days
before a logout/login.
I find it difficult for anyone to expect updates to complex interdependent
running binaries to continue to function correctly while and after updates to
them are applied. I always turn off automatic desktop updaters and update
notifiers, usually exit X before applying updates, and when not, restart
immediately after application completes, if not reboot the system.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
8:32 a.m.
On 07/21/2011 08:29 AM, Felix Miata wrote:
On 2011/07/21 15:16 (GMT+0800) Ed Greshko composed:
> Jim Dean wrote:
>> A recent discussion on Fedora forums raised the need to logout and back
>> after a KDE version update. I've noticed that the system becomes
>> unstable, last time I got a plasma crash, and others reported similar things. Is
this
>> common or just a few people?
> FWIW, I have not seen this problem. Last update, I waited 2 days before a
logout/login.
I find it difficult for anyone to expect updates to complex interdependent
running binaries to continue to function correctly while and after updates to
them are applied. I always turn off automatic desktop updaters and update
notifiers, usually exit X before applying updates, and when not, restart
immediately after application completes, if not reboot the system.
nod, one thing I'm looking forward to presumably coming in packagekit
soonish, is the ability to apply updates on shutdown.
-- rex
9:25 a.m.
On 07/21/2011 09:32 AM, Rex Dieter wrote:
> I find it difficult for anyone to expect updates to complex
interdependent
> running binaries to continue to function correctly while and after updates to
> them are applied. I always turn off automatic desktop updaters and update
> notifiers, usually exit X before applying updates, and when not, restart
> immediately after application completes, if not reboot the system.
nod, one thing I'm looking forward to presumably coming in packagekit
soonish, is the ability to apply updates on shutdown.
sort of ... a running program -typically will continue to function
just fine even if it is unlinked and a new one put in place - its
possible paging from the file may be an issue but far more likely is
that a subordinate program gets started which is not new and now in some
way conflicts.
none of this explains why plasma-desktop crashes and burns. This seems
far more likely to be a bug to me - it should function fine during and
after an update - if logout is necessary, or a reboot (on very odd
occasions) fine ... don't crash the desktop before that happens.
Also
10:33 a.m.
On 07/21/2011 10:25 AM, Genes MailLists wrote:
sort of ... a running program -typically will continue to function
just fine even if it is unlinked and a new one put in place - its
possible paging from the file may be an issue but far more likely is
that a subordinate program gets started which is not new and now in some
^^^^^^^^^^^^^^^^^
should be which is new and now conflicts
5:41 a.m.
Genes MailLists wrote:
sort of ... a running program -typically will continue to function
just fine even if it is unlinked and a new one put in place - its
possible paging from the file may be an issue but far more likely is
that a subordinate program gets started which is not new and now in some
way conflicts.
none of this explains why plasma-desktop crashes and burns. This seems
far more likely to be a bug to me - it should function fine during and
after an update - if logout is necessary, or a reboot (on very odd
occasions) fine ... don't crash the desktop before that happens.
Plasma loads plugins at runtime. If the version of the plugin on disk
doesn't match the version of the main program in memory, it will fail to
load. This also affects some other KDE programs.
Kevin Kofler
12:20 a.m.
Am 21.07.2011 15:32, schrieb Rex Dieter:
On 07/21/2011 08:29 AM, Felix Miata wrote:
> On 2011/07/21 15:16 (GMT+0800) Ed Greshko composed:
>
>> Jim Dean wrote:
>
>>> A recent discussion on Fedora forums raised the need to logout and back
>>> after a KDE version update. I've noticed that the system becomes
>>> unstable, last time I got a plasma crash, and others reported similar things.
Is this
>>> common or just a few people?
>
>> FWIW, I have not seen this problem. Last update, I waited 2 days before a
logout/login.
>
> I find it difficult for anyone to expect updates to complex interdependent
> running binaries to continue to function correctly while and after updates to
> them are applied. I always turn off automatic desktop updaters and update
> notifiers, usually exit X before applying updates, and when not, restart
> immediately after application completes, if not reboot the system.
nod, one thing I'm looking forward to presumably coming in packagekit
soonish, is the ability to apply updates on shutdown.
It would be great as well if shutdown is not possible during update. I
once shut down my system during update and afterwards there were some
problems. Windows tells the user not to turn of the system until update
is finished.
Martin
-- rex
_______________________________________________
kde mailing list
kde(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kde
New to KDE4? - get help from http://userbase.kde.org
5:42 a.m.
Martin (KDE) wrote:
It would be great as well if shutdown is not possible during update.
I
once shut down my system during update and afterwards there were some
problems. Windows tells the user not to turn of the system until update
is finished.
PackageKit is actually supposed to block shutdowns…
Kevin Kofler
10:51 a.m.
On Thu, 2011-07-21 at 09:29 -0400, Felix Miata wrote:
On 2011/07/21 15:16 (GMT+0800) Ed Greshko composed:
> Jim Dean wrote:
>> A recent discussion on Fedora forums raised the need to logout and back
>> after a KDE version update. I've noticed that the system becomes
>> unstable, last time I got a plasma crash, and others reported similar things. Is
this
>> common or just a few people?
> FWIW, I have not seen this problem. Last update, I waited 2 days before a
logout/login.
I find it difficult for anyone to expect updates to complex interdependent
running binaries to continue to function correctly while and after updates to
them are applied. I always turn off automatic desktop updaters and update
notifiers, usually exit X before applying updates, and when not, restart
immediately after application completes, if not reboot the system.
See the recent thread on "needs-updating" on the Users list.
Updating the on-disc binary of a running process has no effect on said
process, it simply creates a new file. New execs of the program will
execute from that file rather than the old one, but the old one will
persist until the last running instance of it dies. Of course problems
can in theory arise if a set of interacting processes are partially
updated, depending on exactly when each of them executes, but in
practice I've rarely seen any problems with this (mainly I think because
apps don't tend to change radically from one version to the next,
especially in their external interfaces).
The main reason for restarting a session is to get the new version of
long-running components, which would include plasma and the like.
poc
10:39 p.m.
On Thursday 21 July 2011 16:51:17 Patrick O'Callaghan wrote:
Updating the on-disc binary of a running process has no effect on
said
process, it simply creates a new file. New execs of the program will
execute from that file rather than the old one, but the old one will
persist until the last running instance of it dies. Of course problems
can in theory arise if a set of interacting processes are partially
updated, depending on exactly when each of them executes, but in
practice I've rarely seen any problems with this (mainly I think because
apps don't tend to change radically from one version to the next,
especially in their external interfaces).
What about this scenario: an app A occasionally loads a library B in order to
use some code from there. Suppose that while A is running (and did not load B
yet because user interaction didn't require it so far) there is an update to
both A and B (which goes to disk). After this happens, the system is in a
potentially inconsistent state --- if a user interacts with A so that A asks
to load B, the *updated* library B will be loaded, which can break A badly,
depending on the difference between old and new B. If A is restarted,
everything will be ok, of course, but until then the *old* A is running from
memory, and loading the new B is a gamble, in general.
For system daemons and services (and even for init AFAIK) this is being solved
by the automatic restart of the service after the update (I guess this is in
the rpm's "post"-part of the install), so the system is kept in consistent
state.
For DE and its apps, the story is different, since rpm cannot "restart" the
whole DE while the user is logged in. So there is no way for a system to keep
the DE and its apps in a consistent state after the update, if the user is
still working in it.
This happens fairly often, in the case of firefox I would say regularly ---
every time I see firefox being updated in the yum listing, I save all tabs
before the update begins, close it and reopen it after the update. Every time
I miss to do that, I get burned by the running version of firefox starting to
malfunction in all sorts of weird ways.
Aside from firefox crashing/misbehaving regularly after an update, I remember
that this happened once with ktorrent as well. It was updated while running
(in the background), and it crashed when I opened up its window again. A
simple restart fixed it.
All that said, on F14 plasma never crashed on me, updates or otherwise. Of
course, if I see kde* packages being updated in the yum listing, I either
postpone the update for later, or save my data, logout and login after the
update. I am not saying that this is a big issue, it rarely happens, but if
you don't want nasty surprises, it's better to be on the safe side.
HTH, :-)
Marko
9:49 a.m.
On Fri, 2011-07-22 at 04:39 +0100, Marko Vojinovic wrote:
On Thursday 21 July 2011 16:51:17 Patrick O'Callaghan wrote:
> Updating the on-disc binary of a running process has no effect on said
> process, it simply creates a new file. New execs of the program will
> execute from that file rather than the old one, but the old one will
> persist until the last running instance of it dies. Of course problems
> can in theory arise if a set of interacting processes are partially
> updated, depending on exactly when each of them executes, but in
> practice I've rarely seen any problems with this (mainly I think because
> apps don't tend to change radically from one version to the next,
> especially in their external interfaces).
What about this scenario: an app A occasionally loads a library B in order to
use some code from there. Suppose that while A is running (and did not load B
yet because user interaction didn't require it so far) there is an update to
both A and B (which goes to disk). After this happens, the system is in a
potentially inconsistent state --- if a user interacts with A so that A asks
to load B, the *updated* library B will be loaded, which can break A badly,
depending on the difference between old and new B. If A is restarted,
everything will be ok, of course, but until then the *old* A is running from
memory, and loading the new B is a gamble, in general.
That could happen but it would depend on how the library is loaded. I'm
not sufficiently au fait with the details of Linux dynamic library
management to have a well-founded opinion, but AFAIK the loader normally
checks that all libraries exist before allowing the process to execute.
Whether that means the library files are open or not is another matter.
To put it another way: will the process die if the .so file is deleted
while it's still running? If it does, then the problem you mention could
arise, and if not, not. Testing this is left as an exercise for the
reader :-)
poc
5:44 a.m.
Patrick O'Callaghan wrote:
That could happen but it would depend on how the library is loaded.
I'm
not sufficiently au fait with the details of Linux dynamic library
management to have a well-founded opinion, but AFAIK the loader normally
checks that all libraries exist before allowing the process to execute.
That's only true if the library is linked directly, not if dlopen is used.
Plugins are loaded through dlopen.
Kevin Kofler
11:48 a.m.
On Tue, 2011-07-26 at 12:44 +0200, Kevin Kofler wrote:
Patrick O'Callaghan wrote:
> That could happen but it would depend on how the library is loaded. I'm
> not sufficiently au fait with the details of Linux dynamic library
> management to have a well-founded opinion, but AFAIK the loader normally
> checks that all libraries exist before allowing the process to execute.
That's only true if the library is linked directly, not if dlopen is used.
Plugins are loaded through dlopen.
Good point.
poc
1:12 p.m.
On 07/26/2011 12:48 PM, Patrick O'Callaghan wrote:
On Tue, 2011-07-26 at 12:44 +0200, Kevin Kofler wrote:
> Patrick O'Callaghan wrote:
>> That could happen but it would depend on how the library is loaded. I'm
>> not sufficiently au fait with the details of Linux dynamic library
>> management to have a well-founded opinion, but AFAIK the loader normally
>> checks that all libraries exist before allowing the process to execute.
>
> That's only true if the library is linked directly, not if dlopen is used.
> Plugins are loaded through dlopen.
Good point.
poc
_______________________________________________
Only up to a point - this is a possible explanation but not a valid
reason.
Usually, calls to dlopen use some kind of version indicator to ensure
compatibility before blindly executing code which may not be compatible
- this allows graceful 'please logout to pick up new libraries'
notification to the user (or whatever).
dlopen() needs some protection - if its not doing this, I'd claim its
still a bug (badly written).
The GUI needs to be graceful and not just 'hang' coz an update took
place.
One could even keep both (or more) sets of libraries in place until
the next reboot/KDE restart or whatever - so that things could just keep
working.
Crashing is never excusable ... and certainly using dlopen() poorly
is not a good excuse - its merely an explanation of the bug.
11:24 a.m.
On 07/21/2011 09:29 PM, Felix Miata wrote:
On 2011/07/21 15:16 (GMT+0800) Ed Greshko composed:
> Jim Dean wrote:
>> A recent discussion on Fedora forums raised the need to logout and back
>> after a KDE version update. I've noticed that the system becomes
>> unstable, last time I got a plasma crash, and others reported similar things. Is
this
>> common or just a few people?
> FWIW, I have not seen this problem. Last update, I waited 2 days before a
logout/login.
I find it difficult for anyone to expect updates to complex interdependent
running binaries to continue to function correctly while and after updates to
them are applied. I always turn off automatic desktop updaters and update
notifiers, usually exit X before applying updates, and when not, restart
immediately after application completes, if not reboot the system.
I agree with you, in the sense that it is probably unrealistic to expect
that a session will continue to run for an infinite time after
components have been updated. I have not, so far, had a session
deteriorate due to updates being performed but lacking a logout/login
session.
--
Even if you do learn to speak correct English, whom are you going to
speak it to? -- Clarence Darrow
3:21 a.m.
On 21/07/11 03:38, Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and
back
after a KDE version update. I've noticed that the system becomes
unstable, last time I got a plasma crash, and others reported similar
things. Is this common or just a few people?
It was suggested that a bug should be raised for it.
This doesn't seem to be a problem for us on F14 usually, although things
did go a bit odd after the kde 4.5.x to 4.6 update until we logged out
and in again.
Roderick
5:17 a.m.
On 21/07/11 09:21, Roderick Johnstone wrote:
On 21/07/11 03:38, Jim Dean wrote:
> A recent discussion on Fedora forums raised the need to logout and back
> after a KDE version update. I've noticed that the system becomes
> unstable, last time I got a plasma crash, and others reported similar
> things. Is this common or just a few people?
> It was suggested that a bug should be raised for it.
>
This doesn't seem to be a problem for us on F14 usually, although things
did go a bit odd after the kde 4.5.x to 4.6 update until we logged out
and in again.
Roderick
A post on Fedora-users (poc, 28/06/11 17:22) drew my attention to
needs-restarting, which is part of the yum-utils package.
[John@localhost ~]$ needs-restarting --help
Usage:
needs-restarting: Report a list of process ids of programs that
started running before they or some component they use were updated.
Options:
-h, --help show this help message and exit
-u, --useronly show processes for my userid only
[John@localhost ~]$
Null output suggests that all should be ok.
I haven't used this because I thought it might be yum-specific, and I
normally use smart, but this --help info makes it look depsolver agnostic.
John P
6:54 a.m.
On 07/21/2011 06:17 AM, John Pilkington wrote:
I don't use f14 so for me its f15 only. Also, if I have a new kernel -
i should restart - but this has nothing to do with plasma-desktop
freezing up nor should it be a problem if I don't reboot for that matter.
existing windows (terminal for example) work - but the desktops are
all collapsed into 1 - and nothing on any panel responds to anything.
10:53 a.m.
On Thu, 2011-07-21 at 11:17 +0100, John Pilkington wrote:
On 21/07/11 09:21, Roderick Johnstone wrote:
> On 21/07/11 03:38, Jim Dean wrote:
>> A recent discussion on Fedora forums raised the need to logout and back
>> after a KDE version update. I've noticed that the system becomes
>> unstable, last time I got a plasma crash, and others reported similar
>> things. Is this common or just a few people?
>> It was suggested that a bug should be raised for it.
>>
>
> This doesn't seem to be a problem for us on F14 usually, although things
> did go a bit odd after the kde 4.5.x to 4.6 update until we logged out
> and in again.
>
> Roderick
A post on Fedora-users (poc, 28/06/11 17:22) drew my attention to
needs-restarting, which is part of the yum-utils package.
[John@localhost ~]$ needs-restarting --help
Usage:
needs-restarting: Report a list of process ids of programs that
started running before they or some component they use were updated.
Options:
-h, --help show this help message and exit
-u, --useronly show processes for my userid only
[John@localhost ~]$
Null output suggests that all should be ok.
I haven't used this because I thought it might be yum-specific, and I
normally use smart, but this --help info makes it look depsolver agnostic.
It has nothing to do with yum, or indeed with depsolvers of any sort. It
just looks at the actual running binary and checks the file(s) it came
from. Which is pretty cool IMHO. The code is a page or two of Python and
is very educational to read.
poc
12:29 p.m.
On 21/07/11 16:53, Patrick O'Callaghan wrote:
On Thu, 2011-07-21 at 11:17 +0100, John Pilkington wrote:
> On 21/07/11 09:21, Roderick Johnstone wrote:
>> On 21/07/11 03:38, Jim Dean wrote:
>>> A recent discussion on Fedora forums raised the need to logout and back
>>> after a KDE version update. I've noticed that the system becomes
>>> unstable, last time I got a plasma crash, and others reported similar
>>> things. Is this common or just a few people?
>>> It was suggested that a bug should be raised for it.
>>>
>>
>> This doesn't seem to be a problem for us on F14 usually, although things
>> did go a bit odd after the kde 4.5.x to 4.6 update until we logged out
>> and in again.
>>
>> Roderick
>
> A post on Fedora-users (poc, 28/06/11 17:22) drew my attention to
> needs-restarting, which is part of the yum-utils package.
>
> [John@localhost ~]$ needs-restarting --help
> Usage:
> needs-restarting: Report a list of process ids of programs that
> started running before they or some component they use were updated.
>
> Options:
> -h, --help show this help message and exit
> -u, --useronly show processes for my userid only
> [John@localhost ~]$
>
> Null output suggests that all should be ok.
>
> I haven't used this because I thought it might be yum-specific, and I
> normally use smart, but this --help info makes it look depsolver agnostic.
It has nothing to do with yum, or indeed with depsolvers of any sort. It
just looks at the actual running binary and checks the file(s) it came
from. Which is pretty cool IMHO. The code is a page or two of Python and
is very educational to read.
poc
I looked at it and had my doubts; the script includes what looked to me
like a reference to the yum cache but I didn't work out how essential
this is to its operation. And I suppose it's best run as root?
John P
2:01 p.m.
On Thu, 2011-07-21 at 18:29 +0100, John Pilkington wrote:
On 21/07/11 16:53, Patrick O'Callaghan wrote:
> On Thu, 2011-07-21 at 11:17 +0100, John Pilkington wrote:
>> On 21/07/11 09:21, Roderick Johnstone wrote:
>>> On 21/07/11 03:38, Jim Dean wrote:
>>>> A recent discussion on Fedora forums raised the need to logout and back
>>>> after a KDE version update. I've noticed that the system becomes
>>>> unstable, last time I got a plasma crash, and others reported similar
>>>> things. Is this common or just a few people?
>>>> It was suggested that a bug should be raised for it.
>>>>
>>>
>>> This doesn't seem to be a problem for us on F14 usually, although
things
>>> did go a bit odd after the kde 4.5.x to 4.6 update until we logged out
>>> and in again.
>>>
>>> Roderick
>>
>> A post on Fedora-users (poc, 28/06/11 17:22) drew my attention to
>> needs-restarting, which is part of the yum-utils package.
>>
>> [John@localhost ~]$ needs-restarting --help
>> Usage:
>> needs-restarting: Report a list of process ids of programs that
>> started running before they or some component they use were updated.
>>
>> Options:
>> -h, --help show this help message and exit
>> -u, --useronly show processes for my userid only
>> [John@localhost ~]$
>>
>> Null output suggests that all should be ok.
>>
>> I haven't used this because I thought it might be yum-specific, and I
>> normally use smart, but this --help info makes it look depsolver agnostic.
>
> It has nothing to do with yum, or indeed with depsolvers of any sort. It
> just looks at the actual running binary and checks the file(s) it came
> from. Which is pretty cool IMHO. The code is a page or two of Python and
> is very educational to read.
>
> poc
>
I looked at it and had my doubts; the script includes what looked to me
like a reference to the yum cache but I didn't work out how essential
this is to its operation. And I suppose it's best run as root?
I spoke too soon. It looks at the RPM database to discover if any of a
process' open files belong to some package that was installed after the
process started. This would of course include the binary executable of
the process itself and those of any libraries it has loaded.
poc
11:07 a.m.
On Thursday, July 21, 2011 09:21:38 AM Roderick Johnstone wrote:
On 21/07/11 03:38, Jim Dean wrote:
> A recent discussion on Fedora forums raised the need to logout and back
> after a KDE version update. I've noticed that the system becomes
> unstable, last time I got a plasma crash, and others reported similar
> things. Is this common or just a few people?
> It was suggested that a bug should be raised for it.
This doesn't seem to be a problem for us on F14 usually, although things
did go a bit odd after the kde 4.5.x to 4.6 update until we logged out
and in again.
Fedora 14 here. I always log out after updates affect KDE packages. Mostly
it works without a problem, but I have seen a couple of cases where a hard
reboot was necessary. I don't consider it to be enough to make an issue of
it.
Anne
--
New to KDE Software? - get help from http://userbase.kde.org
8:11 a.m.
On 07/20/2011 09:38 PM, Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and
back
after a KDE version update. I've noticed that the system becomes
unstable, last time I got a plasma crash, and others reported similar
things. Is this common or just a few people?
Even minor kde-4.x.y updates (where y increments), a session restart is
recommended. for major (x increments) updates, we set the flag to
request a reboot. These session or restart recommendations are exposed
via PackageKit (and kpackagekit) when applying updates.
-- rex
5:50 a.m.
Rex Dieter wrote:
Even minor kde-4.x.y updates (where y increments), a session restart
is
recommended. for major (x increments) updates, we set the flag to
request a reboot.
Is this still necessary? KPackageKit is supposed to detect running apps and
request a session restart, for me it normally does. A full reboot is not
actually required, and we've had trouble with the "request reboot" flag in
the past (the flag would infect all further updates, even just of one of the
packages). I don't think we should be setting "request reboot" for any KDE
update anymore.
Kevin Kofler
9:38 a.m.
On 07/21/2011 03:38 AM, Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and
back after a KDE version update. I've noticed that the system becomes
unstable, last time I got a plasma crash, and others reported similar
things. Is this common or just a few people?
It was suggested that a bug should be raised for it.
What is so surprising about that? :-)
You are changing the whole system behind the carpet and you expect it to
just work?
The only solution for it to work would be to have everything loaded on
memory.
--
José Matos
10:54 a.m.
On Thu, 2011-07-21 at 15:38 +0100, José Matos wrote:
On 07/21/2011 03:38 AM, Jim Dean wrote:
> A recent discussion on Fedora forums raised the need to logout and
> back after a KDE version update. I've noticed that the system becomes
> unstable, last time I got a plasma crash, and others reported similar
> things. Is this common or just a few people?
> It was suggested that a bug should be raised for it.
What is so surprising about that? :-)
You are changing the whole system behind the carpet and you expect it to
just work?
Mostly yes, I do. This isn't Windows.
poc
12:51 p.m.
On Thursday, July 21, 2011 04:54:19 PM Patrick O'Callaghan wrote:
On Thu, 2011-07-21 at 15:38 +0100, José Matos wrote:
> On 07/21/2011 03:38 AM, Jim Dean wrote:
> > A recent discussion on Fedora forums raised the need to logout and
> > back after a KDE version update. I've noticed that the system becomes
> > unstable, last time I got a plasma crash, and others reported similar
> > things. Is this common or just a few people?
> > It was suggested that a bug should be raised for it.
>
> What is so surprising about that? :-)
>
> You are changing the whole system behind the carpet and you expect it to
> just work?
Mostly yes, I do. This isn't Windows.
I'm thankful that it manages things well enough for me to always finish
whatever I was doing. However, my thinking is that if I start anything new
that calls one of the new packages I am asking for a conflict with the old
packages that I'm still running. It simply isn't worth the risk. And after
all, a logout is nowhere near the same as a Windows reboot.
Anne
--
New to KDE Software? - get help from http://userbase.kde.org
2:05 p.m.
On Thu, 2011-07-21 at 18:51 +0100, Anne Wilson wrote:
On Thursday, July 21, 2011 04:54:19 PM Patrick O'Callaghan
wrote:
> On Thu, 2011-07-21 at 15:38 +0100, José Matos wrote:
> > On 07/21/2011 03:38 AM, Jim Dean wrote:
> > > A recent discussion on Fedora forums raised the need to logout and
> > > back after a KDE version update. I've noticed that the system becomes
> > > unstable, last time I got a plasma crash, and others reported similar
> > > things. Is this common or just a few people?
> > > It was suggested that a bug should be raised for it.
> >
> > What is so surprising about that? :-)
> >
> > You are changing the whole system behind the carpet and you expect it to
> > just work?
>
> Mostly yes, I do. This isn't Windows.
>
I'm thankful that it manages things well enough for me to always finish
whatever I was doing. However, my thinking is that if I start anything new
that calls one of the new packages I am asking for a conflict with the old
packages that I'm still running. It simply isn't worth the risk. And after
all, a logout is nowhere near the same as a Windows reboot.
I do the same, not so much because I think anything will go wrong if I
don't but for general motives of paranoia. When I say this isn't
Windows, I mean that Linux gives you great leeway in deciding when to do
it while Windows frequently demands a reboot even for trivial changes.
The underlying reason has much to do with the very elegant Unix file
model, which IMHO Mr. Gates totally failed to understand when he started
selling MS-DOS, but that's another story.
poc
1:12 p.m.
On 07/21/2011 04:54 PM, Patrick O'Callaghan wrote:
Mostly yes, I do. This isn't Windows.
poc
Please, let us keep this discussion on a polite level. ;-)
I still remember the .la files that were libraries loaded on demand by
kde. If that is the case it is asking for trouble to have the
infrastructure with one version and the (new) loaded libraries with
another since they do not match any more.
--
José Matos
4656
days inactive
4661
days old
31 comments
13 participants
participants (13)
-
Anne Wilson -
Ed Greshko -
Felix Miata -
Genes MailLists -
Jim Dean -
John Pilkington -
José Abílio Matos -
Kevin Kofler -
Marko Vojinovic -
Martin (KDE) -
Patrick O'Callaghan -
Rex Dieter -
Roderick Johnstone