journal is hard + sugar and the digital age

Tomeu Vizoso 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
right format.

Some related pointers regarding roadmaps:

http://sugarlabs.org/go/ReleaseTeam/Roadmap/0.84#Goals
http://sugarlabs.org/go/DevelopmentTeam/0.84/Reliability#Datastore_rework
http://sugarlabs.org/go/DevelopmentTeam/0.84/Ideas#Journal

Thanks,

Tomeu

> 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
>>
>> >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
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
>



More information about the Devel mailing list