journal is hard + sugar and the digital age

Michael Stone michael at laptop.org
Thu Oct 9 14:30:47 EDT 2008


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 

>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



More information about the Devel mailing list