Interval Smalltalk redux (was "SqueakOS")

Craig Latta craig.latta at netjam.org
Thu Oct 3 23:50:05 UTC 2002


	Daniel writes:

> And of course, this wonderful code is buried somewhere to never be
> used again.

short answer: It's not as bad as that.

long answer:

        I'm sure the following is in the Google archives somewhere, but
I'm too lazy to look it up... anyone please feel free to correct me.

        I was on the Interval Smalltalk team. Our system was part of a
local media network system (homes, cars, etc.) which used a novel
networking protocol ("MediaWire") that was cheap (ran over phone wire),
synchronous, could support variable bitrates, and was, for the time,
fast (100Mb). We worked on the "MediaPad", a sort of glorified remote
control, a letter-sized touchscreen device with which you could control
all the connected devices, make new composite devices, etc. It was
similar in appearance to the failed crop of "web pads" which kept
appearing later :). Tim and I showed off a couple of them at OOPSLA '99.
I designed the device driver framework (a precursor to Flow).

        At the end of the project, we got permission to release all the
non-MediaWire-specific software (pretty much the whole virtual machine,
and most of the object memory). The catch is that only two of us had
working MediaPad-building environments at the end (the end came
suddenly). A different two of us (Tim and myself) had working MediaPads.
Unfortunately, we've never been motivated enough collectively to get all
the bits and hardware back together. Doing so would be some non-trivial
amount of work, and we've all been busy with other things since. I
actually have been releasing parts of the object memory over time,
starting with the exception-handling framework I wrote (when Squeak
didn't have one), then moving on to the device stuff. It's generally
slow going though, because writing and performing music always gets more
of my time.

        I expect the complete system would take a non-trivial amount of
rework to retarget to different hardware. The MediaPad was always a
home-grown prototype (based on the StrongARM 1100, and custom ASICs, at
no small cost). The native code generator wouldn't be immediately useful
to all Squeakers, for example. Some of the ARM development tools we used
are not open-source. Another problem not to be underestimated is that
both Tim and I have so far been too paranoid to attempt rewriting either
of the MediaPad ROMs, for fear of the population of known demo-able
MediaPads dropping by half. :)  Also, the system got basic testing, but
the project died before we could really pound it in actual homes.

        Anyway, the software is not closed as far as I know, but it's
not in a state where it can meaningfully be distributed as a single
coherent system. I think it's fair to say that most of us wouldn't feel
right distributing something that people can't just fire up and use
(leftover pride I suppose :). That mostly explains why the occasional
"why doesn't the Interval Smalltalk system get released?" query is met
with relative silence.

        I've always wanted to eventually get the whole thing released,
though, and I plan to keep at it. I think a proper revival of the
project would be a lot of fun and still very useful, too, but we'd have
to solve the hardware environment problem first. I'm game. :)

	John writes:

> The Interval project was a special case. They were building their
> own custom hardware, so they HAD to write their own device drivers...

	Well, that was just the MediaPad and assorted networking glue
(standalone clocks, hubs, etc.); the situation was a little more...
interesting. Part of the plan was to collaborate with the major consumer
electronics firms to establish MediaWire as a common interconnection
technology (e.g., you'd find MediaWire ports on next-generation TVs, CD
players, etc.). We were going for all the traditional closed-spec
devices in addition to our own stuff, by being part of the specs. It was
Big. :)  The Japanese financial crisis in 1998 took most of the wind out
of those sails (the biggest potential collaborators were deeply
affected). I tend to agree with Tim that Mr. Bill finished it off.

> ...and they had a large team of both hardware and software engineers.

	It wasn't that large, really. The comparison we liked to bat around was
the fifteen of us versus the thousand people developing WinCE. :)

	Tim writes:

> I'm pretty much convinced [implementing everything, including device
> drivers, in Smalltalk] isn't really worth it. At least, not unless
> one can fairly seriously rejig things to provide useful OS type
> facilities like protection of one application's memory from another,
> all that stuff.

	Indeed... and I thought we were well on our way. :)  I thought having
everything written in Squeak was fantastic. It made debugging things
easier, and it was much simpler to explain the overall system
architecture to newcomers. It afforded a great deal of useful technical
control. And it was just more fun, which does have value.

	At the same time, I'm all for creating the illusion of object memory
anywhere it's useful, including OSKit and the "commodity" OS platforms.
The trick is where to stop... in Interval's case, there were very good
technical and business reasons for "going deep". Most of the time, as a
single individual with a limited lifespan, I'm content to get on with
higher priorities as long as the supporting stuff isn't too distracting.

> I agree with Dan's old aphorism about the OS but I think a better
> interpretation of it is that nothing in the OS should be unreachable
> from your language - not that there shouldn't be the OS there at all.

	To a large degree I view The Aphorism as a statement of that time, when
the technology wasn't as pervasive and things were more open to change.
And somewhere there should be a footnote: "Things get weird when
billionaires are nearby."  :)


-C

--
Craig Latta
improvisational musical informaticist
craig at netjam.org
www.netjam.org/resume
Smalltalkers do: [:it | All with: Class, (And love: it)]



More information about the Squeak-dev mailing list