[sugar] Remarks on the Work of Sugar
eben.eliason at gmail.com
Tue Jul 22 20:57:52 EDT 2008
On Tue, Jul 22, 2008 at 8:46 PM, Michael Stone <michael at laptop.org> wrote:
> On Tue, Jul 22, 2008 at 08:31:24PM -0400, Benjamin M. Schwartz wrote:
> > Michael Stone wrote:
> > | 5) Sugar is built on technologies that incentivize its developers to
> > | recompute prior results which could be cached across boots.
> > Sugar was intended to write to disk absolutely as little as possible, and
> > also to reboot as infrequently as possible.
> Interesting. Do you think that these remain worthy design goals?
> > Regarding the majority of your points, I would say: Sugar has been, and
> > continues to be, in a constant rush just to implement the desired
> > functionality, regardless of efficiency. The question has long been
> > "how can we code this as fast as possible", not "what is the ideal way
> > to implement this".
> In my opinion, this is a missed opportunity. (see below).
> > I think that is a good thing.
> I disagree because I think that the approach we have taken has made it
> much harder for others to help us. For a project like Sugar, this
> ultimately results is less software of less quality in the same
> timeframe. At least, that's what I take away from the Trac and xmonad
> examples. (When you examine your own "notoriously easy-to-contribute-to
> projects", do your conclusions match mine?)
You say that, but you weren't here for the first year of development, right?
It was all about "build this new OS, and do it in 9 months." We didn't have
the liberty to wait and try to do stuff right, because if we had, we
wouldn't have shipped /anything/, and there wouldn't even be a platform
worth arguing about volunteer support for. This hurt us, but it was the
only way to get something worth shipping in the time alloted, and we were
basically forced to operate on a hardware deadline. We're still, to a
certain extent, trying to dig out of the "needs to be working to at least
some degree" hole and to a place where we can make good future-proof
> > I think we will need retain this mindset through 9.1, in order to
> > finally deliver a Sugar that has the features required for usability.
> In my opinion, 9.1 is unlikely to contain the features and quality
> required for the level of usability Sugar was sold on. (It will be
> substantially better than 8.2, but we set the initial goal REALLY high.)
True, but we're still lacking some basic primitives, many of which could
arrive in 9.1. Direct object transfer. Visual clipboard. Groups for
collaboration. These and more are desperately needed in practice in the
field. And some of the bigger pieces (Journal/DS, for instance), ARE waiting
on something to be "done right" before we hack about more, and that's
costing us dearly too.
In short, I think we're all about as dissatisfied as you are. And we're all
still working damn hard to get closer to the goal we all envisioned 2.5
> Devel mailing list
> Devel at lists.laptop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel