[olpc-software] sugar - patch

[Dan Williams]

On Wed, 2006-06-07 at 21:01 +0100, Mike Hearn wrote:
> I don't necessarily disagree but feel a devils advocate argument might
> be useful.
> 
> On 6/7/06, Dan Williams <dcbw at redhat.com> wrote:
> > It's all about the trade-offs, yes.  For not being as memory and CPU
> > efficient as C, we get to (a) not care as much about buffer overflows,
> 
> ExecShield ASLR seems to solve this for the desktop case ...

Well, except that it terminates our program, as do the other glibc
security checks that have been introduced in the past year.  We'd rather
just not have to deal with buffers at all;  you simply cannot
maliciously overflow buffers in Python, just like mono/java/etc.  The
wrong way to handle that is a process termination, the right way is to
catch the exception.

But for glibc and C code, there's chance in hell, at least as I
understand it, to recover from this situation without being
unceremoniously killed.

> > (b) rapidly prototype features
> > (c) allow children to easily make their own activities,
> 
> Make sense.
> 
> > (d) use all the C code that is very efficient through bindings,
> 
> I used to agree with this line of reasoning but practical experience
> with optimisation has made me disillusioned with it. If you want to
> write tight software it's pretty uncommon to have a small set of
> hotspots unless it's an extreme case like a GUI over some kind of
> maths problem. Sometimes slowness is a big, overarching problem (eg
> with Java desktop apps ....)
> 
> > and (e) not care at all about C/C++ ABI/API issues.
> 
> Python has ABI and compatibility problems too, I had to investigate
> this recently for autopackage. So I would say this is not really an
> advantage.

Right; but we're shipping _one_ version of python on the laptop.  That
version is not going to change.  Just like we're not going to break
ABI/API of glibc on the laptop either.  I know Python ABI changes every
now and again, more or less when Guido waves his wand, but we don't have
to upgrade to those versions.  We may need to do versioning of bytecode
transfers, but who knows.

> > Again, if there are efficiency issues with parts of the environment, we
> > may well end up recoding them in C.  We're certainly not going to do
> > window-manager-like bits in Python.
> 
> Well, ok, you're the guys doing the work ... I just worry it'll end up
> with the same problem Chandler had (where it takes 20 seconds to start
> for no particularly good reason).

Haha.  Yeah, chandler.  Enough said.  I think the idea here is not to
write a ton of python code, but to write a framework that allows other
people to shoot themselves in the foot if they want to :)  I know we'll
try hard _not_ to.  And right now, sugar is completely the wrong
platform for chandler-class apps.

Also, remember that nothing requires activities to be in Python.  The
shell currently hands you an Activity ID, an Xembed window ID, and
exports a dbus service which the activity can use for further
communication.  So as long as you can speak X11 and use dbus, you can
write an activity in whatever language you'd like, no python required.

Dan