errors getting python up-and-running

lkcl luke.leighton at gmail.com
Sat Nov 27 09:39:47 CET 2010




John van V.-2 wrote:
> 
> No need to apologize.  I am not working on the technology level
> (counseling
> actually), but I am following the list, and I have perceived a surge in
> posts.  I suppose the "solution" is to create specifically focused lists
> ---
> but I hardly see that as a problem; it is really good news.
> 
> My personal hope is to see L4 as drop-in replacement for Linux, and
> distributed in a format something like Ubuntu uses, with driver and
> porting
> kits supplied to peripheral and hardware manufacturers so that we can
> finally kiss off M$, and possibly the entire proprietary structure.
> 
> From there, I suppose, it would be a fairly quick segue to a native L4
> platform.  My hope is for interest in data-centricity that is "appless"
> and
> works within the OS through open VMs and with dynamic desktop windows (
> http://thinman.com).
> 
> Genuine regards, John
> 

john, hi, replied to you earlier but i thought it was a private message,
so here's a rehash.

it's very ironic that, far from trying to "beat m$", the competition
is now actually linux :)

L4 has great potential in the embedded arena, i hope to be able to
demonstrate that by porting an entire web browser to it: already
i've shown that WebkitDFB can start up in one second on only a
400mhz ARM926EJS.  if linux is cut from the equation then i believe
that using e.g. L4 a startup target time of 1.5 seconds would be
perfectly reasonable.

for L4 to be a viable alternative to linux it's imperative to not confuse
linux with gnu/linux.  i.e. it's important to drum into people the
difference
between an OS and a kernel.  L4 and Linux are kernels, not OSes.

with that in mind, L4RE modules must be available that are a drop-in
replacement for the linux _kernel_, thus making it feasible for people
to simply run the OS that they are *ALREADY* running.  once that
has been proven and demonstrated, packaging it is actually very
straightforward: it's already been done for BSD (kfreebsd) so yeah
hell why not L4RE as well.

just to reiterate: that's correct, i did state that you can run a BSD
kernel on debian.  no linux kernel is involved:

$ apt-cache search kfreebsd
kfreebsd-source-6.3 - source code for kernel of FreeBSD 6.3 with Debian
patches
kfreebsd-source-7.0 - source code for kernel of FreeBSD 7.0 with Debian
patches
freebsd-buildutils - Utilities for building FreeBSD sources
freebsd-manpages - Manual pages for a GNU/kFreeBSD system
kfreebsd-source-8.1 - source code for kernel of FreeBSD 8.1 with Debian
patches

so, actually, l4linux+L4RE actually qualifies as being a drop-in
replacement,
but i don't believe that's what you meant: i believe you meant that you'd
like to see a complete alternative to linux entirely.

the problem with that is: device drivers.  the expertise and state-of-play
is encoded and enshrined in the device driver tree, _not_ the actual
core "linux scheduler" which is what.. only 100,000 lines of code (vs
millions for the device drivers).  thus, you still need OSKit, really,
which is "linux minus the linux scheduler" as you're no doubt already
aware.  to do anything else but make use of OSKit would be...
a massive undertaking beyond sensible resources at the present time.

ok looking into this further, oskit was already done with fiasco, but it
was 1999 (!).  but you get the point i am sure.

ok enough :)

l.
-- 
View this message in context: http://old.nabble.com/errors-getting-python-up-and-running-tp30308895p30317302.html
Sent from the L4 mailing list archive at Nabble.com.





More information about the l4-hackers mailing list