journal is hard + sugar and the digital age
tomeu at tomeuvizoso.net
Sat Oct 11 06:06:30 EDT 2008
2008/10/9 Carol Hussein Lerche <cafl at msbit.com>:
> 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.
I agree with your analysis and with the solution you propose, now we
just need to find people that helps us put this information in the
Some related pointers regarding roadmaps:
> 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
>> >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  since this topic
>> has been dealt with before by others.
>> : 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,
>> Devel mailing list
>> Devel at lists.laptop.org
> "The water won't clear up 'til we get the hogs out of the creek." -- Jim
> Devel mailing list
> Devel at lists.laptop.org
More information about the Devel