From: Paul Guyot (pguyot_at_kallisys.net)
Date: Mon Sep 13 2004 - 00:20:59 PDT
On Sun, 12 Sep 2004, Mike Grauer wrote:
> I am surprised that Slashdot.org has not picked up on Einstein yet.
Slashdot only publishes stories that are submitted.
Plus Einstein only is a proposition so far. Nothing you can download or
whatever.
To reply to Robert's request to develop on the possibilities we
enumerated, let me explain why I would personally prefer a POSIX kernel
and Einstein built at the top, either with JIT or with native execution.
Soon, the Internet will transition to IPv6.
We also need SSH and SSL. You simply cannot use hotspots in cafes in Paris
on your Newton because it requires SSL.
Both these elements, among others, are already available from open source
software designed for POSIX. They are often badly written in the meaning
that they use global variables, something that isn't allowed in NewtonOS
native code runtime architecture. So to port SSH/SSL, you not only have to
compile a library providing these features (such as openssl/openssh or
lsh), but you also have to fix the libraries by removing all the global
variables. Compiling is just a third of the work (but it's not trivial
nevertheless).
Now, imagine that we have Einstein running on top of a modified Linux or
NetBSD (my preference) core system. I say modified because if Einstein
runs with native code, we'll have to modify the core system and somehow
vampirise it, the platform would then be the core system + the Einstein
runtime. So if we did so, we'd have SSH/SSL, IPv6 but also routing,
802.11g drivers and whatever is a pain to do on the Newton for free.
Please note, however, that if we have even just 2K users of Einstein, that
Einstein will be a big weight in the platform, whether it is NetBSD-arm-be
(NetBSD on ARM big endian, something that doesn't exist yet) or
Linux-arm-be. I think this is a key element for picking the POSIX core and
the reason why I prefer NetBSD is that it's a BSD license (we won't be
scared of mixing closed source stuff with it) and that the NetBSD
community is open to native code emulation projects with their Linux,
MacOS X and Solaris native code emulation tools (please note that Einstein
is much more complex than all these projects, though).
Another option is JIT. JIT will mean a small performance hit, but much
better portability. The performance hit won't be significant. And the
thing could run on non ARM-based PDAs. And the interaction with the host
OS will be much simpler. And we actually won't really depend on the host
OS. But the integration might be less tight. While with native code on top
of a POSIX core, the target PDA won't really run the host OS. We'll be
able to make changes in the kernel to get a better power saving method. I mean,
considering the changes that will be required in the kernel to get native
code to work, it won't be much work to also improve power saving from how
the Newton does it. Or if you prefer, it won't really be Einstein as a
process on top of Unix. Instead, both systems would be intermixed and
we could let NewtonOS drive some hardware processes such as putting the
system to sleep.
Hardware integration would be even better if we simply ported NewtonOS to
another platform. This is the third possibility we've been thinking about.
The big drawback of this in my opinion is that we won't benefit from OSS
drivers and hardware knowledge. In other words, what is great about NetBSD
or Linux is that some people got it running on the PDAs. So they figured
out how to interact with these PDA's hardware. If we do port NewtonOS,
we'll have to look how they did it and duplicate their effort somewhat.
Additionally, we'll have to modify the NewtonOS native runtime
architecture to solve the SSH/SSL problem. And rewrite an IP stack. Two
things I've considered in the past that are doable, but I'd prefer not to
do them.
The reason why I didn't state my point of view immediatly is that I'm
biased and it would be like asking someone's advice without taking it into
account. I think Nicolas wants to discuss the possiblities further.
Please note, actually, that we probably won't start working on Einstein
again right now. I personally want to release ATA Support 1.0 first before
resuming work on Einstein. It's been too long since this project was
suspended. Then I want to release a fixed, working version
of Escale with synchronization. And then, my plan is to use Einstein
to fix the -10061 bug. Nicolas is very busy with the job that pays his
rent at the moment and he seriously needs vacation. I wish him to be able
to go to the South of France for a month as he planned in October.
Paul
-- This is the NewtonTalk list - http://www.newtontalk.net/ for all inquiries Official Newton FAQ: http://www.chuma.org/newton/faq/ WikiWikiNewt for all kinds of articles: http://tools.unna.org/wikiwikinewt/
This archive was generated by hypermail 2.1.5 : Mon Sep 13 2004 - 04:00:02 PDT