4 ms·

I had one back in the day, and it was the worst computing experience I can remember. The keyboard was like what you'd find on a speak-and-spell, and the system

I had one back in the day, and it was the worst computing experience I can remember. The keyboard was like what you'd find on a speak-and-spell, and the system had the performance of a low-end 486 under heavy swap. I still don't understand why the system performed so poorly, I know a lot of Sugar was written in Python, but there must have been some very fundamental problems with it. Switching to an existing lightweight X window manager was a much better (but still not good) experience.

floren 9y ago
> I still don't understand why the system performed so poorly, I know a lot of Sugar was written in Python, but there must have been some very fundamental problems with it. Fundamental problem identified. I believe the Inferno port tended to run better.
- avhon1 9y ago
  > the Inferno port tended to run better. Cool. I hadn't heard about this! It looks like it's being actively maintained on bitbucket, too! [0] It looks like someone else also got Plan9 booting on the OLPC [1]. [0] https://bitbucket.org/inferno-os/inferno-os/ https://bitbucket.org/inferno-os/inferno-os/ [1] http://gsoc.cat-v.org/people/ameya/blog/2007/08/19/1_Plan9_Kernel_Booting_on_OLPC/ http://gsoc.cat-v.org/people/ameya/blog/2007/08/19/1_Plan9_K...
bitwize 9y ago
Sugar wasn't just written in Python. Parts of it were literally coded in the worst way possible. We're talking Daily WTF levels. For example, the icon for each Sugar "activity" was an SVG file. When you started an activity, its icon would "throb" in the center of the screen, fading in and out. Guess how the throbbing was implemented. That's right, it would perform string substitution on the SVG file, filling in the actual colors for macros embedded in the SVG, then reparse and redisplay the SVG. For each frame. Had it been a simple matter of being written in Python, Sugar might've been usable. But it was shitty Python and that's what killed it.
- jancsika 9y ago
  > That's right, it would perform string substitution on the SVG file, filling in the actual colors for macros embedded in the SVG, then reparse and redisplay the SVG. For each frame. That's intriguing! I can imagine a path to how they got there: 1. PyGTK (or whatever they were using) has methods to load and display an image. 2. A supported image type is svg+xml 3. SVG is vector graphics. Awesome! Let's use that. 4. Animation is needed, so we consider just ramping the opacity attribute, scaling attribute, etc. 5. We don't have any methods for DOM access. Oops. 6. However, we do have our loaded SVG file which is just plain text. 7. Well, we can just s/OPACITY/RAMP_VALUE or whatever and display that for our animation. That at least doesn't require a read from the harddrive for each frame. :) Speaking of which-- I've seen developers do animation by repeatedly reading a file from the harddrive in the same process/thread as a realtime audio engine. Edit: clarification
  - bitwize 9y ago
    I uh...I don't remember for sure, but I can't guarantee that the Sugar code didn't reload the SVG file from disk for each frame. The whole thing was madness, all the way down. It's a wonder it worked at all.
    - jancsika 9y ago
      At 24 FPS that gives you a total of 41.67 milliseconds to fetch the file from the harddrive, parse it, and display it. The harddrive was flash memory, no? So we're probably talking hundreds of microseconds to read the file into memory. Let's say 670 microseconds for a rough guess. That still leaves 41 milliseconds to parse and display the file. Of course the animation is happening at an arbitrary program's load time which is probably particularly CPU heavy. But OLPC apparently had two cores, so the process controlling the SVG animation should have been able to safely hit its deadlines. I'm going to guess that the animation was smooth when trivial consumer single-process apps were loaded and janky when something like an office application was opened. Am I right, or was it always janky?
      - 9y ago
avhon1 9y ago
The keyboard is probably a lot nicer to use if you can fit all of your fingers on it. (I usually use my IBM model M with my XO-1 laptops.) Also, the newer models are available with a chiclet-style keyboard. As bitwize said, not only is Sugar written in Python, but it's also badly written. In one of my other comments in this thread, I mentioned the memory leak [0] which has been a problem in Sugar since 2013. Without Sugar, the experience is better. I run dwm in debian, and it works well as long as I don't have any complicated web pages open. 400 MHz i586 and 256 MB of memory is enough to be useful. The keyboard provides ESC and F1-F12. It's just a little, weird-looking laptop with a transflective display.
blackrock 9y ago
As much as I like Python for data analysis, I do not understand why a very high level language was chosen to write a GUI window manager. Was Python chosen as the technology stack by someone inexperienced in developing operating systems?

floren 9y ago

> I still don't understand why the system performed so poorly, I know a lot of Sugar was written in Python, but there must have been some very fundamental problems with it. Fundamental problem identified. I believe the Inferno port tended to run better.

avhon1 9y ago
> the Inferno port tended to run better. Cool. I hadn't heard about this! It looks like it's being actively maintained on bitbucket, too! [0] It looks like someone else also got Plan9 booting on the OLPC [1]. [0] https://bitbucket.org/inferno-os/inferno-os/ https://bitbucket.org/inferno-os/inferno-os/ [1] http://gsoc.cat-v.org/people/ameya/blog/2007/08/19/1_Plan9_Kernel_Booting_on_OLPC/ http://gsoc.cat-v.org/people/ameya/blog/2007/08/19/1_Plan9_K...

bitwize 9y ago

Sugar wasn't just written in Python. Parts of it were literally coded in the worst way possible. We're talking Daily WTF levels. For example, the icon for each Sugar "activity" was an SVG file. When you started an activity, its icon would "throb" in the center of the screen, fading in and out. Guess how the throbbing was implemented. That's right, it would perform string substitution on the SVG file, filling in the actual colors for macros embedded in the SVG, then reparse and redisplay the SVG. For each frame. Had it been a simple matter of being written in Python, Sugar might've been usable. But it was shitty Python and that's what killed it.

jancsika 9y ago
> That's right, it would perform string substitution on the SVG file, filling in the actual colors for macros embedded in the SVG, then reparse and redisplay the SVG. For each frame. That's intriguing! I can imagine a path to how they got there: 1. PyGTK (or whatever they were using) has methods to load and display an image. 2. A supported image type is svg+xml 3. SVG is vector graphics. Awesome! Let's use that. 4. Animation is needed, so we consider just ramping the opacity attribute, scaling attribute, etc. 5. We don't have any methods for DOM access. Oops. 6. However, we do have our loaded SVG file which is just plain text. 7. Well, we can just s/OPACITY/RAMP_VALUE or whatever and display that for our animation. That at least doesn't require a read from the harddrive for each frame. :) Speaking of which-- I've seen developers do animation by repeatedly reading a file from the harddrive in the same process/thread as a realtime audio engine. Edit: clarification
- bitwize 9y ago
  I uh...I don't remember for sure, but I can't guarantee that the Sugar code didn't reload the SVG file from disk for each frame. The whole thing was madness, all the way down. It's a wonder it worked at all.
  - jancsika 9y ago
    At 24 FPS that gives you a total of 41.67 milliseconds to fetch the file from the harddrive, parse it, and display it. The harddrive was flash memory, no? So we're probably talking hundreds of microseconds to read the file into memory. Let's say 670 microseconds for a rough guess. That still leaves 41 milliseconds to parse and display the file. Of course the animation is happening at an arbitrary program's load time which is probably particularly CPU heavy. But OLPC apparently had two cores, so the process controlling the SVG animation should have been able to safely hit its deadlines. I'm going to guess that the animation was smooth when trivial consumer single-process apps were loaded and janky when something like an office application was opened. Am I right, or was it always janky?
    - 9y ago

avhon1 9y ago

The keyboard is probably a lot nicer to use if you can fit all of your fingers on it. (I usually use my IBM model M with my XO-1 laptops.) Also, the newer models are available with a chiclet-style keyboard. As bitwize said, not only is Sugar written in Python, but it's also badly written. In one of my other comments in this thread, I mentioned the memory leak [0] which has been a problem in Sugar since 2013. Without Sugar, the experience is better. I run dwm in debian, and it works well as long as I don't have any complicated web pages open. 400 MHz i586 and 256 MB of memory is enough to be useful. The keyboard provides ESC and F1-F12. It's just a little, weird-looking laptop with a transflective display.

blackrock 9y ago

As much as I like Python for data analysis, I do not understand why a very high level language was chosen to write a GUI window manager. Was Python chosen as the technology stack by someone inexperienced in developing operating systems?