GNOME 3.4 Accessibility Crashes and Atom processors?
- Login o registrati per inviare commenti
Hi,
This netbook has a duel-core Atom cpu, Intel graphics, 1 GB ram, Atharos
wifi, etc. It ran Trisquel 5.0 and 5.5 with some bugs in the Orca
screen reader, but was stable. In early versions of Trisquel 6, I began
having occasional crashes of the accessibility, especially when using
abrowser on sites with lots of dynamically-changing content of parts of
the site, that doesn't reload the entire page. Since abrowser updated
to version 19, the problem is much worse. A small amount of browsing in
youtube is a sure way to crash the accessibility. This happens with a
"regular" Ubuntu 12.04, Fedora 17, and Debian Wheezy, as well; these all
have GNOME 3.4.2 in common. Interestingly, it doesn't happen on
Opensuse 12.2, which uses the same GNOME. GNOME 3.6, as packaged in
Opensuse 12.3, also does not exhibit this trouble. The accessibility
forums are silent on this. I found references, in launchpad, to a bug
regarding the Atom cpu mentioning that the 'lscpu' command throws a
floating point exception. This does happen; I've confirmed it. Does an
error in the Atom processor make the accessibility fragile? If I could
apply a fix for this problem, I'd return to using and recommending
Trisquel 6.0, especially for its accessibility, small footprint, ease of
use, etc...
Any ideas?
-Dave H.
I also use an Atom netbook (but only single core with 2 processes) and found browsing via Mozilla version 19 to be much faster when disabling most JavaScript via NoScript and RequestPolicy (LibreJS didn't work when I tried it - it was too CPU intensive).
For YouTube I use either SMPlayer (which also includes a YouTube browser - you need to install the package "smtube" for it to work) or youtube-dl. youtube-dl can fetch the link without downloading when using "-g" so you can copy the link into your favorite video player (it is best to download or view the unencumbered format VP8/WebM - for this run youtube-dl with "-F" then run with youtube-dl with the code for the WebM resolution you desire if WebM is available, e.g. "-f 43").
Lightspark I usually disable and only enable briefly when needed. I use UnPlug to get video URLs on some other websites, e.g BBC news, and it usually works without Lightspark but it does sometimes require running some JavaScript.
Here is the output of lscpu command. It seems to work fine but maybe that's because I'm using Parabola which includes newer versions of packages than Trisquel. A brief internet search suggests that the problem lies with the "util-linux" package. Perhaps you should try updating it (by compiling the source code).
lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 2
Core(s) per socket: 0
Socket(s): 2
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 28
Stepping: 10
CPU MHz: 1667.000
BogoMIPS: 3334.53
L1d cache: 24K
L1i cache: 32K
L2 cache: 512K
NUMA node0 CPU(s): 0,1
Hopefully these suggestions will improve Orca's performance enough to make it usable.
Thanks; I'll hang onto these suggestions and try them on a reinstalled
Trisquel. My problem isn't one of speed, though, it seems to be
something with the dynamic content and the accessibility structure. The
crashes in question happen while moving around on the pages, not while
watching videos. Maybe I'll also try disabling hardware accelleration
in the browser. Even if some combination of work-arounds makes
accessibility seem stable, the bug involving the Atom chip is still
there. Maybe it's race conditions, something to do with process
scheduling, or whatever? The orca user community's basic response to my
questions is either "don't use GNOME 3.4" or "Get another machine"; no
help there.
Thanks,
Dave
- Login o registrati per inviare commenti