journal is hard + sugar and the digital age

Thu Oct 9 15:09:22 EDT 2008

I think a lot of the frustration around the journal could be abated by
publishing a roadmap with actual projected times when each feature is
planned to be available for testing in a joyride and then projected release
number.  Many of the experiments and research-type proposals have sounded
excellent as fixes or at least mitigations for the journal's underlying
problems.  But from the outside perspective what I see reading conversations
about this on the list is a sense that there are true believers inside the
olpc and sugar development team that hold to a belief that a great day is
coming for the journal, but without a concrete roadmap making that belief
real to those only experiencing the difficulty in dealing with what is there
right now, they sometimes sound a bit delusional.  (Not saying that they
are...it's just a big mismatch between pie-in-the-sky pictures of a cloudy
goal and no visible stepping stones to that goal).

One thing that might help is a wiki FAQ about the journal collecting a
roadmap and pointers to the work that has taken place already in one place.

On Thu, Oct 9, 2008 at 11:30 AM, Michael Stone <michael at laptop.org> wrote:

> On Thu, Oct 09, 2008 at 12:55:43PM -0400, Erik Garrison wrote:
> >You acknowledge that the system is not functioning as well as it should
> >be in its curren state.  Please stop saying "we are going to do this"
>
> Instead, please stop saying "we are going to do this" and just do it and
> be done with it!
>
> >and look for the simplest way to achieve a usable system for our usesr.
>
> Your arguments are impassioned but not persuasive. Please accept the
> fact that a cadre of People Who Have Shipped Software believe that
> making a good Journal is worth attempting one more time. If their choice
> proves faulty over the next six months, then you will be in a stronger
> position to argue your case; if not, then I believe the issue will be
> moot.
>
> >I will gladly help in this endeavor, but I am concerned by our security
> >system and the frequent implications that we are holding to old designs
> >that my ideas and motivation have no place in this effort.
>
> Either cite specific concerns or desist from raising this issue.
>
> >I don't think we can incorporate the concept of memory and forgetting
> >into the Journal in a programmatic way.  Forgetting is as much a learned
> >skill as remembering, and attempting to replicate it in software seems
> >like a very difficult, if impossible, task.
>
> Attendees of the previous Journal Summit: please write down the
> algorithm you constructed for forgetting so that Erik can evaluate it.
>
> Erik: in the mean time, please tender opinions on [1] since this topic
> has been dealt with before by others.
>
> [1]: http://www.cs.ubc.ca/~feeley/papers/1999-4.pdf<http://www.cs.ubc.ca/%7Efeeley/papers/1999-4.pdf>
>
> >I feel that we are tilting at windmills if we believe we can reliably
> >produce something so incredible in any conceivable timeframe.
>
> I believe that we have already produced something incredible, including
> but not limited to shipping or making available
>
>   * power management capable of yielding 10-hour battery life
>   * essentially all activities filesystem-isolated by default
>   * a bandwidth-efficient atomic update system w/ rollback
>   * a first-boot activation and passive-kill system which still permits
>     the laptops to be fully unlocked at user request
>   * a document-centric paradigm which was sufficiently compelling to
>     inspire a document-centric GNOME summit
>   * a distribution with a deep commitment and impressive support for
>     multi-locale usage and for usage by illiterate users.
>   * an implementation of the 802.11(s) draft spec
>
> to an installed user base on the order of 500K users.
>
> We have also constructed but not yet shipped or shipped demo-quality
> implementations of:
>
>   * demo-quality networked collaboration software good enough to spur
>     real interest
>   * a revised Journal,
>   * an indexed versioned content-addressed filesystem,
>   * network isolation,
>   * efficient multicast wireless data and presence transport,
>   * server-side jabber event filtering and searching
>
> Finally, we have substantial design and requirements documents waiting
> for implementation in each of security, networking, and the UI.
>
> In conclusion, given how far we've come in the past two years, I
> sincerely hope that we continue to attempt the same task for the next
> two years. Where is your evidence that we're taking on too much?
>
> >I am furthermore frustrated by the tight integration of the Journal into
> >the window manager.
>
> Please point to the integration between the journal and the window
> manager which bothers you. I do not believe any substantive integration
> exists between those components (though I acknowledge the integration
> between the shell and the window manager and between the shell and
> the journal).
>
> >In particular, our security model has the effect of preventing work on
> >this issue that isn't supported by all the core developers.
>
> Scott seems to be suffering from no impediment from our security model
> so please explain your complaint in more detail or
>
>   rm /etc/olpc-security
>
> and get on with life.
>
> > We can only have one file management application.
>
> We presently intend to _ship_ only one filer. We'd be happy to have a
> choice about which one to ship, though.
>
> > I am afraid that I or another interested developer will implement such
> >systems but find they are rejected by the core developers,
>
> Shall I quote Roosevelt or Palpatine?
>
> > and it will be impossible even for users desire to use them to easily
> > do so.
>
> This is a separate problem; please treat it as such.
>
> (Mildly) frustratedly yours,
>
> Michael
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>

-- 
"The water won't clear up 'til we get the hogs out of the creek." -- Jim
Hightower
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20081009/3fdcec83/attachment.html>