OLPC doesn't care about Sugar -- or at least Nicholas Negroponte doesn't. Per the article:
The whole "we're investing into Sugar, it'll just run on Windows" gambit is sheer nonsense. Nicholas knows quite well that Sugar won't magically become better simply by virtue of running on Windows rather than Linux. In reality, Nicholas wants to ship plain XP desktops. He's told me so. That he might possibly fund a Sugar effort to the side and pay lip service to the notion of its "availability" as an option to purchasing countries is at best a tepid effort to avert a PR disaster.
This leaves me wondering if there will be any official releases beyond the Update.1 release candidate posted on the OLPC Wiki. Heck, at the rate its going, Update.1 might not even make it out. Which would really be a shame, since its much improved over the builds that shipped with the G1G1 laptops.
I got a 65 in the SeaMonkey (2.0) nightly. Build string for the nightly:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030501 SeaMonkey/2.0a1pre
The Firefox nightly should be pretty close to that since that's also using Gecko 1.9b.
For what its worth, I tried to reproduce this on a clean copy of Firefox 2.0.0.9 and Seamonkey 1.1.6 (with Adblock Plus) on Windows XP. The "local ISP webmail" has been substituted for an AIM mail tab.
Current memory usage on Firefox: 102MB
Current memory usage on Seamonkey: 135MB -- have at least 5 other windows open in Seamonkey
CPU usage on each browser is about 10-20% on a 2.0Ghz P4 with 512MB RAM.
This leads me to believe you (or the bug reporter) either have an extension doing something dodgy, or that local webmail app has some interesting code inside which makes the browser hang up.
As the one comment to that bug asks, do these problems exist in Firefox safe mode as well?
Re:NASA uses 30-year old UNIX derivative
on
ISS Computer Failure
·
· Score: 3, Informative
Many of NASA computers on spacecraft use a long-tested version of realtime UNIX called VxWorks from Charles River. It doesnt nexcessarily have the fancy stuff in modern *nix's, but is fairly reliable. Even that has been known to fail.
VxWorks isn't a UNIX, it is a real time operating system from Wind River. Its has POSIX compliance in a decent number of areas so writing a thread / task is similar to programming for UNIX, but it can be quite a different beast when it comes to actually running the software. My experience is that once you have the various application tasks debugged, it'll run practically forever. Though as the parent noted, a bad driver can spoil that in unexpected ways.
Slashdot Mirror
Well, shit, because I still have a PowerPC Mac on my desk. It's stuck with Firefox 3.6 because they dropped PowerPC support in Firefox 4.
Firefox is being kept alive on PowerPC:
http://code.google.com/p/tenfourfox/
http://tenfourfox.blogspot.com/
I got a 65 in the SeaMonkey (2.0) nightly. Build string for the nightly:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030501 SeaMonkey/2.0a1pre
The Firefox nightly should be pretty close to that since that's also using Gecko 1.9b.
For reference, SeaMonkey 1.1.8 scored 49.
For what its worth, I tried to reproduce this on a clean copy of Firefox 2.0.0.9 and Seamonkey 1.1.6 (with Adblock Plus) on Windows XP. The "local ISP webmail" has been substituted for an AIM mail tab.
Current memory usage on Firefox: 102MB
Current memory usage on Seamonkey: 135MB -- have at least 5 other windows open in Seamonkey
CPU usage on each browser is about 10-20% on a 2.0Ghz P4 with 512MB RAM.
This leads me to believe you (or the bug reporter) either have an extension doing something dodgy, or that local webmail app has some interesting code inside which makes the browser hang up.
As the one comment to that bug asks, do these problems exist in Firefox safe mode as well?
VxWorks isn't a UNIX, it is a real time operating system from Wind River. Its has POSIX compliance in a decent number of areas so writing a thread / task is similar to programming for UNIX, but it can be quite a different beast when it comes to actually running the software. My experience is that once you have the various application tasks debugged, it'll run practically forever. Though as the parent noted, a bad driver can spoil that in unexpected ways.