<div dir="ltr"><br><br><div class="gmail_quote">On Tue, Jul 22, 2008 at 8:46 PM, Michael Stone <<a href="mailto:michael@laptop.org">michael@laptop.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="Ih2E3d">On Tue, Jul 22, 2008 at 08:31:24PM -0400, Benjamin M. Schwartz wrote:<br> > Michael Stone wrote:<br> > | 5) Sugar is built on technologies that incentivize its developers to<br> > | recompute prior results which could be cached across boots.<br> ><br> > Sugar was intended to write to disk absolutely as little as possible, and<br> > also to reboot as infrequently as possible.<br> <br> </div>Interesting. Do you think that these remain worthy design goals?<br> <div class="Ih2E3d"><br> > Regarding the majority of your points, I would say:  Sugar has been, and<br> > continues to be, in a constant rush just to implement the desired<br> > functionality, regardless of efficiency. The question has long been<br> > "how can we code this as fast as possible", not "what is the ideal way<br> > to implement this".<br> <br> </div>In my opinion, this is a missed opportunity. (see below).<br> <div class="Ih2E3d"><br> > I think that is a good thing.<br> <br> </div>I disagree because I think that the approach we have taken has made it<br> much harder for others to help us. For a project like Sugar, this<br> ultimately results is less software of less quality in the same<br> timeframe. At least, that's what I take away from the Trac and xmonad<br> examples. (When you examine your own "notoriously easy-to-contribute-to<br> projects", do your conclusions match mine?)<br> <div class="Ih2E3d"></div></blockquote><div><br></div><div>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 decisions.</div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d"><br> > I think we will need retain this mindset through 9.1, in order to<br> > finally deliver a Sugar that has the features required for usability.<br> <br> </div>In my opinion, 9.1 is unlikely to contain the features and quality<br> required for the level of usability Sugar was sold on. (It will be<br> substantially better than 8.2, but we set the initial goal REALLY high.)</blockquote><div><br></div><div>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.</div> <div><br></div><div>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 years ago.</div><div><br></div><div>- Eben</div> <div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br> <br> Regards,<br> <font color="#888888"><br> Michael<br> </font><div><div></div><div class="Wj3C7c">_______________________________________________<br> Devel mailing list<br> <a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a><br> <a href="http://lists.laptop.org/listinfo/devel" target="_blank">http://lists.laptop.org/listinfo/devel</a><br> </div></div></blockquote></div><br></div>