(solved) ps that used to work no longer do

[tobiaus]

booting tc cloud from cd, installing kompozer (tce?) from appbrowser. used to work, now crashes immediately, even when it's the only thing installed. (unless it was fixed in the past 2 weeks.) ram: 512mb minus whatever tcb uses.

booting tc as guest os in qemu, (cloud mode) full inkscape (tcel) used to work, now crashes the moment you try to use it, even if it's the only thing installed. ram: 128mb minus whatever tcb uses.

booting tc as guest os in qemu, (cloud mode) inkscapelite (tce) used to work, now refuses to load. says it needs libart_gpl2.so.2. (this one works, see next paragraph.)

i have old copies of these apps that probably still work (but since they've been updated, the source is probably gone,) but if anyone can... okay i've installed libart, so inkscapelite seems to be ok. .info or .dep should be updated for inkscape lite.

for the other two apps, if anyone gets them working (even by using tcz instead of tce...) in their copy of tc (booted with base norestore or whatever the code is...) i'd like to hear about it, and any details that you think might be relevant.

[Jason W]

Kompozer and inkscapelite were overlooked in the gtk2 upgrade, but now their .dep files have been corrected.  Inkscape full opened for me, but I did see a segfault in Kompozer but the dep file is  now correct.  Inkscapelite already has libart.tcel in it's dep file.

[Jason W]

On a related note, "crashing" may be seen in low memory environments due to the mysterious OOM killer.  I have seen the OOM killer in action in both the 2.6.26 and 2.629.1 kernels,  One time I was compiling the kernel while watching youtube, and Firefox suddenly exited with the error message "Killed".  I looked in dmesg and saw this entry:

Code: [Select]

Out of memory: kill process 944 (firefox-bin) score 14782 or a child
Killed process 944 (firefox-bin)

My kernel compile kept happily chugging along.  I was able to duplicate this behavior on another machine and with different circumstances.

So if you have a modest amount of RAM, there is a chance that the OOM killer will strike down a memory hungry app when RAM is tight.  Running the app from a terminal as well as checking dmesg in the case of an unexpected exit will help determine if it is really a crash or the OOM killer trying to prevent a lockup.

[tobiaus]

On a related note, "crashing" may be seen in low memory environments due to the mysterious OOM killer.  I have seen the OOM killer in action in both the 2.6.26 and 2.629.1 kernels,  One time I was compiling the kernel while watching youtube, and Firefox suddenly exited with the error message "Killed".  I looked in dmesg

if i'm having trouble with an extension i run from term to see the messages. indeed, inkscape full said "killed" when i tried to run it, but that is not reasonable on a setup running nothing but tc base with 512m of ram and full inkscape.

Inkscapelite already has libart.tcel in it's dep file.

inkscapelite seems to have been an anomoly. i just did another cloud boot in qemu, and the last time it said "there was a problem try again later" (or the like.) and obviously libart was the problem. this time i watched it download libart automatically and sure enough it runs without any extra installs. note i've never had that experience in tc before, other people are probably more familiar.

[mikshaw]

Sounds like a server hiccup, maybe.
Cloud computing is indeed an interesting concept, but it seems to continue suffering from these types of problems.

[tobiaus]

Cloud computing is indeed an interesting concept, but it seems to continue suffering from these types of problems.

oh i find it to be the most reliable way to run tc, not always the most convenient. it hurts a lot when there is a gtk upgrade and the other extensions do not all conform to it. the second most reliable is ppr/tce because at any given time there tend to be more working tce packages than tcz, but tcz is better for any package that works properly (most!) i don't mess with any of the other modes, i think they are more likely to complicate the process of using tc. i'm glad they exist because for some people they're something i'm willing to use the word "necessity" for, but they can be trouble.

[mikshaw]

Choice is nice =o)

To clear up my comment, I wasn't talking about cloud computing in tc, but cloud computing in general.  If your connection to the wuhwuhweb is not completely reliable, you can find yourself in a situation where you can't access your applications and data.
 I suppose this is improving over time, and will eventually (hopefully) not be an issue.

[tobiaus]

...computing in general.  If your connection to the wuhwuhweb is not completely reliable, you can find yourself in a situation where you can't access your applications and data.
 I suppose this is improving over time, and will eventually (hopefully) not be an issue.

actually i agree with you on the concept, and though it may improve, i don't think cloud computing is something people should ever rely on. stallman goes so far as to say that it's foolish to use any software that is controlled by someone else, such as google docs, but extends his argument to ajax, etc. i can't imagine he's big on cloud computing- i think though there's a fine line between cloud mode in tc and installing software with apt-get. if you run cloud mode 100 times, once a day, it's about the same as installing from apt-get on 100 machines, one per day.