I made a promise to myself, and the world, that when Fedora 10 came out, I would become a full-time Sugar user.
This week I am at SugarCamp in Boston, with most of the Sugar engineers all around me in a big room, so even though we’re still several days away from the launch of F10, I figured I’d get a head start.
I’m running entirely on USB key on my T42. It’s a 2 Gig key running Sebastian’s pre-F10 spin of Sugar, with 1 Gig of overlay space set aside. So far, I would say, it works “well enough” so that when Fedora 10 is actually released, I’ll be able to muddle through any issues. Browse works well enough; Write works well enough; XoIRC works well enough; Terminal will give me pine. That’s all I really need.
There are so many things to comment about: so many interesting things, so many still-broken things, so many possibilities. I’ve already got pages of notes from my first four hours of using Sugar, and there’s no way I can hit them all at once. Therefore, I will talk about one good thing and one bad thing. With luck, I can make this a habit. 🙂
The good thing: the journal. The journal is one of those things that I didn’t really “get” at first. I’m a command-line guy. When I need to find something, I use some combination of ls, find, xargs and grep. I like hierarchical file systems. I figured the journal would be an annoyance that I’d have to suffer through as I learned it.
So when I started my system today, I wanted to bring up my daily TODO list, my “using Sugar” notes, and a browser.
It was exactly three clicks in my journal. Wow! I get it now, and I’m liking it a lot. At least, this morning. When it bites me, as it surely will, I will surely talk about it.
Now the bad thing — or perhaps more fairly, the challenging thing: the notion of packaging.
One of the purposes of the Fedora XO project is to package all necessary Sugar activities for use in Fedora. In my view, there are two real wins achieved by the Linux model of software packaging: first, the ability to define software dependencies and satisfy them at install time, thus encouraging software modularity; and second, the ability to know conclusively what software is running on any given system. Both of these wins have to do with managing complexity, and have contributed to Linux’s stratospheric rise in the back office.
When I look at the relationship between Sugar and its activities, though, I see a model that has much more in common with the Mozilla add-ons model than the Linux packaging model. Mozilla add-ons assume a homogenous platform, in Mozilla, and the activities can safely depend on the libraries provided by that platform: no more and no less. Defining “dependencies” in the Mozilla world is nonsensical. Why shouldn’t Sugar be the same way?
This question will become more acute if we are successful in creating an effective activities repository for Sugar, like addons.mozilla.org. When there are only twenty viable Sugar activities, it’s an easy matter of packaging them for Fedora or Debian. But what happens when there are 200 viable Sugar activites? Or 2000? At some point, the overhead of repackaging all of these activities will look an awful lot like wasted effort — effort that could be much more effectively spent in making a stable Sugar platform that is sufficiently identical across all distros to render activity “packaging” moot.