[IAEP] Early Sugar Design Documentation?

[Dave Crossland]

Hi

Trawling the depths of the OLPC/Sugar history again today, I came across
http://www.mail-archive.com/fonc@vpri.org/msg04503.html in which Alan Kay
opines on how Apple and Microsoft’s “app” based OS designs in the 80s
introduced fundamental flaws that persist to Android and iOS today.

To what extent can the objects in Sugar be passed between Activities?

Generally I am curious about the early Sugar design work, that was done
inside OLPCF with Pentagram and Red Hat in the 2005 (?) to 2007 period. Is
any of the material produced during that time available online?

I thought this discussion from my facebook about the above AK email might
be interesting:

DC: Is AK in http://www.mail-archive.com/fonc@vpri.org/msg04503.html
basically correct?

Thomas Lord: "Basically", yes. Do you get what he's saying there? Example:
In the OS+apps world you might have some files: a word processor document,
some image files, and a little database file with a list of your favorite
stocks. You open a word processor to work on the document. You run a ticker
app to look at real time quotes on your stocks. You use Gimp or whatever to
edit the image files. If you are writing a report you do a lot of saving
stuff to files in one app and importing it to files in another app.

In Smalltalk-style worlds you might instead create a project. OK, you
through a rich-text object in there and you can edit the text, view it,
whatever. So far your "project" acts like a word processor. Then you throw
in a ticker object. Maybe it just sits there next to the text object or
maybe it goes "inside" and a live ticker flows with the text like an active
diagram. Same with image objects -- there's no separate editor app that you
work with by saving and importing image files. The object is there. You can
throw the interface to the object into an edit mode. Your Gimp-like image
editor is just a capability all images, in every context they appear,
happen to have.

DC: Yes; in Mac OS X there was a "services" API which allowed you to do
that kind of inter-app stuff which I remember being told at the time (13-14
years ago) was a smalltalk remnant from the NeXTStep days

DC: Also I wonder that this is what RMS was talking about when he said that
UNIX wasn't a particularly great OS design to replicate as libre, but it
was known to be useful and was proven to be widely portable so that it
would still be working on whatever machines were in use in the years it
would take to complete GNU.

Thomas Lord: "services" APIs are a poor and vastly incomplete attempt to do
this. The big problem with them is related to the commodification of apps.
Namely, some central platform provider fixes the interface between apps and
THATS IT. If some hacker writing software for the platform wants to combine
"apps" in a way the platform vendor didn't think of ... well tough shit.

On a lisp machine, or a smalltalk machine, there's nothing special about
any interface. All the source is there. There's no imposed limits on who
gets to hack what parts.

GNU Emacs comes with one "app" (really, a lisp library) that gives you an
email reader. It comes with another "app" that gives you an info reader to
view on-line documentation. Suppose some hacker wants to be able to click
on a term he sees in email from some dev list, and be taken to the info
reader.

The hacker does not have to worry about whether some "services" API makes
that cross-"app" function possible. He can hack without boundaries.

There is a social question whether or not the upstream maintainers of the
mailreader library and the info reader library -- if those maintainers will
put his changes in their upstream copy. But that's not the same as the
commercial confinement to "services" APIs.

UNIX was a pragmatic choice because of some correct guesses about where
things were headed in the world of commercial hardware and software.

And software can be morphed over time so (failed part of GNU) if we got to
widely ported 100% libre GNU-like-unix, then we have a starting point from
where to go wherever good taste in software takes us.


-- 
Cheers
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/iaep/attachments/20160417/f628efb2/attachment.html>