By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,715 Members | 1,815 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,715 IT Pros & Developers. It's quick & easy.

Python Operating System???

P: n/a
Hello. I recently came across a free operating system called Unununium (or
something like that) and it was developed in Python and Assembly.

Now, I have been looking for a way to make an operating system for a long
long time and the only possibilities I could find were C++ and assembly. I
don't mind assembly so much if I don't have to use it very often. But C++ is
so complicated and errors are pretty much impossible to find in the code for
me.

So, I was wondering if it would be possible to find a bootloader that loads
a python file at startup or something...

Is there an example somewhere of a Python OS?

Thanks!
Jul 18 '05 #1
Share this Question
Share on Google+
32 Replies


P: n/a
David Brown wrote:
Hello. I recently came across a free operating system called Unununium (or
something like that) and it was developed in Python and Assembly.

Now, I have been looking for a way to make an operating system for a long
long time and the only possibilities I could find were C++ and assembly. I
don't mind assembly so much if I don't have to use it very often. But C++ is
so complicated and errors are pretty much impossible to find in the code for
me.

So, I was wondering if it would be possible to find a bootloader that loads
a python file at startup or something...

Is there an example somewhere of a Python OS?

Thanks!


Hasn't there been numerous discussions about this in the past??
Jul 18 '05 #2

P: n/a
David Brown wrote:
Hello. I recently came across a free operating system called Unununium (or
something like that) and it was developed in Python and Assembly.

Now, I have been looking for a way to make an operating system for a long
long time and the only possibilities I could find were C++ and assembly. I
don't mind assembly so much if I don't have to use it very often. But C++ is
so complicated and errors are pretty much impossible to find in the code for
me.

So, I was wondering if it would be possible to find a bootloader that loads
a python file at startup or something...

Is there an example somewhere of a Python OS?

Thanks!

People don't make Python OSs because it's a serious pain in the
Deng-Xiao-ping. J/k, I am half kidding. Go to google groups, and
search for Python OS. You will find that this topic has been discussed
numerous times. There was another project other than Unununium which
was Python based, but it is not being developed any longer and I fail to
remember what it was called. So search away, you will find many
results! Alternatively you could contact the Unununium folks for help.

Note also that there are Java OSs as well (and probably others). But
then again, if you don't like C++, you probably won't like Java. They
can be very different languages, but in my experience, the reasons why
one does not like C++ is usually due to a quality/flaw that can also be
found in Java.
Jul 18 '05 #3

P: n/a
Arich Chanachai wrote:
But
then again, if you don't like C++, you probably won't like Java. They can be very different languages, but in my experience, the reasons why one does not like C++ is usually due to a quality/flaw that can also be found in Java.


Oh, brother.

The Zen of Python says that "simple is better than complex" and
"complex is better than complicated". Java does pretty well here. C++
didn't even get "complicated is better than convoluted" right. There's
are a ton of flaws in C++ not found in Java.
--
CARL BANKS

Jul 18 '05 #4

P: n/a
The bootloader would have to be a 'python-core'. Ideally a fast
implementation of just the python syntax and language features. Now
*that* would be an excellent basis for a restricted mode python
interpreter - which could make 'python applets' closer to a reality. It
would also make python for embedded systems and embedding python in
larger programs easier as well. A purely 'core language' implementation
with no libraries.....

Obviously you'd need file systems, drivers, and something to create the
functionality of the os and sys libraries. Basing it on the existing
Linux kernel would seem like a much more sensible idea....

There is/was a project (Peter Hansen ?) to produce a pure python file
system. that could be an interesting component.

Regards,

Fuzzy
http://www.voidspace.org.uk/python/index.shtml

David Brown wrote:
Hello. I recently came across a free operating system called Unununium (or something like that) and it was developed in Python and Assembly.

Now, I have been looking for a way to make an operating system for a long long time and the only possibilities I could find were C++ and assembly. I don't mind assembly so much if I don't have to use it very often. But C++ is so complicated and errors are pretty much impossible to find in the code for me.

So, I was wondering if it would be possible to find a bootloader that loads a python file at startup or something...

Is there an example somewhere of a Python OS?

Thanks!


Jul 18 '05 #5

P: n/a
On Thu, 06 Jan 2005 16:12:54 -0800, Carl Banks wrote:
Arich Chanachai wrote:
But
then again, if you don't like C++, you probably won't like Java.

They
can be very different languages, but in my experience, the reasons

why
one does not like C++ is usually due to a quality/flaw that can also

be
found in Java.


Oh, brother.

The Zen of Python says that "simple is better than complex" and
"complex is better than complicated". Java does pretty well here. C++
didn't even get "complicated is better than convoluted" right. There's
are a ton of flaws in C++ not found in Java.


Still, Java feels like C++ done right, while being more wrong >:-[

--
Christopher

If there was a scheme for Lisp world domination...

Jul 18 '05 #6

P: n/a
What exactly do you mean by an operating system?

If you don't want to program in C/C++ then you're going to have a hard time.
I don't want to be too discouraging, but with that attitude I doubt you
would get very far.

It sounds like you want to make more of an OS shell -- no? You can
implement a shell on top of any OS and probably do it in a language like
Python.

But if it is going to be a complete OS in pure Python, uh, it won't be!
You'll have to do a lot of stuff in C, at the least interface with the
hardware.

"David Brown" <da***@graydragon.net> wrote in message
news:10*************@corp.supernews.com...
Hello. I recently came across a free operating system called Unununium (or
something like that) and it was developed in Python and Assembly.

Now, I have been looking for a way to make an operating system for a long
long time and the only possibilities I could find were C++ and assembly. I
don't mind assembly so much if I don't have to use it very often. But C++ is so complicated and errors are pretty much impossible to find in the code for me.

So, I was wondering if it would be possible to find a bootloader that loads a python file at startup or something...

Is there an example somewhere of a Python OS?

Thanks!

Jul 18 '05 #7

P: n/a
Fuzzyman wrote:
There is/was a project (Peter Hansen ?) to produce a pure python file
system. that could be an interesting component.


Good memory... uh, sort of. :-) It was probably me you're
thinking of, but the point of the project was solely a
"virtual" file system, to be used exclusively as a tool
for supporting automated testing. It has no concept of
persistence, no support for it in the design, and wouldn't
be what would help anyone in this respect. Sorry.

(Work on it has actually not progressed lately, because
there is no additional requirement driving the work.
The primitive initial state of the tool suffices so far.)

-Peter
Jul 18 '05 #8

P: n/a
Roose wrote:
What exactly do you mean by an operating system?

If you don't want to program in C/C++ then you're going to have a hard time.
I don't want to be too discouraging, but with that attitude I doubt you
would get very far.

Indeed, this is very true.
It sounds like you want to make more of an OS shell -- no? You can
implement a shell on top of any OS and probably do it in a language like
Python.

He should just build around a linux core or use OS kit (if he is
serious/determined).
But if it is going to be a complete OS in pure Python, uh, it won't be!
You'll have to do a lot of stuff in C, at the least interface with the
hardware.

He could use something like O' caml or Oz no? I might be confused, but
I understood them to be C/C++ comparable in terms of power and in that
they both compile vs. VMs and interpreters (for O' caml this is optional
I think). Or what about D?
Jul 18 '05 #9

P: n/a

"David Brown" <da***@graydragon.net> wrote in message
news:10*************@corp.supernews.com...
Hello. I recently came across a free operating system called Unununium (or
something like that) and it was developed in Python and Assembly.

Now, I have been looking for a way to make an operating system for a long
long time and the only possibilities I could find were C++ and assembly. I
don't mind assembly so much if I don't have to use it very often. But C++
is
so complicated and errors are pretty much impossible to find in the code
for
me.

So, I was wondering if it would be possible to find a bootloader that
loads
a python file at startup or something...

Is there an example somewhere of a Python OS?
As far as I know, there's no working example. Unununium is still
very early development, and it's going off in a quite interesting
direction that is hardly standard.

Writing an operating system is a lot of work. The approach I'd
take would be to start out with an existing micro-kernel and
enhance it with a kernel level Python system so that you wouldn't
need any C or Asm level code in a typical process.

Then I'd pursue a restricted subset of Python that could be
compiled directly to machine code, and start recoding the
various C and Asm parts in that. See the PyPy project for
the direction they're taking for writing the Python system in
Python.

Have fun with the project!

John Roth


Thanks!


Jul 18 '05 #10

P: n/a
Arich Chanachai <ma*******@fastmail.fm> writes:
He should just build around a linux core or use OS kit (if he is
serious/determined).


There's Ubuntu Linux, a Debian-based distro with commercial backing
and a regular release schedule. One of the neat things about Ubuntu is
that Python use is encouraged. "Python scripting everywhere" is a
stated goal, and they have a number of bounties that concentrate on
deepening the use of Python in the OS:

http://www.ubuntulinux.org/community/bounties

I've been using it on a couple of desktops, and I've been impressed by
the overall quality of the distro. One thing I especially like is that
the root account is disabled by default, administrative tasks are
performed with sudo by users in the appropriate group (much like it is
in Mac OS X 10.3).

Nick

--
# sigmask || 0.2 || 20030107 || public domain || feed this to a python
print reduce(lambda x,y:x+chr(ord(y)-1),' Ojdl!Wbshjti!=obwAcboefstobudi/psh?')
Jul 18 '05 #11

P: n/a
In message <pa****************************@chello.at>, Christopher
Koppler <kl******@chello.at> writes
Still, Java feels like C++ done right, while being more wrong >:-[


Couldn't disagree more. Just about anything you want to do that is
low-level, is impossible in Java. Anyway this is off-topic.

Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk
RSI Information: http://www.objmedia.demon.co.uk/rsi.html
Jul 18 '05 #12

P: n/a
In message <ma**************************************@python.o rg>, Arich
Chanachai <ma*******@fastmail.fm> writes
think). Or what about D?


Digital Mars have a D compiler.
http://www.digitalmars.com

Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk
RSI Information: http://www.objmedia.demon.co.uk/rsi.html
Jul 18 '05 #13

P: n/a
David Brown <da***@graydragon.net> wrote:
Hello. I recently came across a free operating system called Unununium (or
something like that) and it was developed in Python and Assembly.

Now, I have been looking for a way to make an operating system for a long
long time and the only possibilities I could find were C++ and assembly.


The problem when using Python instead of C for OS development is that
C was *specifically designed* to create an OS, while Python was designed
for completely different purposes. If you want to write an OS, it would
be wise to use a language that is suited for that purpose. If you
dislike C so much and prefer Python so much more, your first step should
be to design a Python dialect that is more appropriate for writing OS's.

(I know that you mentioned C++, not C, but I decided to setup C as a
straw-man to make my argument.)

- Mike

Jul 18 '05 #14

P: n/a
mi**@hobbshouse.org (Michael Hobbs) writes:
The problem when using Python instead of C for OS development is that
C was *specifically designed* to create an OS, while Python was designed
for completely different purposes. If you want to write an OS, it would
be wise to use a language that is suited for that purpose. If you
dislike C so much and prefer Python so much more, your first step should
be to design a Python dialect that is more appropriate for writing OS's.


But I thought Python was an all-purpose language. After all, OS's
have been written in Lisp before too.
Jul 18 '05 #15

P: n/a
On Fri, 07 Jan 2005 16:34:48 -0000, mi**@hobbshouse.org (Michael Hobbs) wrote:
David Brown <da***@graydragon.net> wrote:
Hello. I recently came across a free operating system called Unununium (or
something like that) and it was developed in Python and Assembly.

Now, I have been looking for a way to make an operating system for a long
long time and the only possibilities I could find were C++ and assembly.


The problem when using Python instead of C for OS development is that
C was *specifically designed* to create an OS, while Python was designed
for completely different purposes. If you want to write an OS, it would
be wise to use a language that is suited for that purpose. If you
dislike C so much and prefer Python so much more, your first step should
be to design a Python dialect that is more appropriate for writing OS's.

(I know that you mentioned C++, not C, but I decided to setup C as a
straw-man to make my argument.)

I'd say look at Ada for HLL inspiration, if you want to deal with OS level stuff
in Python.

Regards,
Bengt Richter
Jul 18 '05 #16

P: n/a
Paul Rubin wrote:
mi**@hobbshouse.org (Michael Hobbs) writes:

The problem when using Python instead of C for OS development is that
C was *specifically designed* to create an OS, while Python was designed
for completely different purposes. If you want to write an OS, it would
be wise to use a language that is suited for that purpose. If you
dislike C so much and prefer Python so much more, your first step should
be to design a Python dialect that is more appropriate for writing OS's.


But I thought Python was an all-purpose language. After all, OS's
have been written in Lisp before too.

Pure Lisp? Or a Lisp/C/Asm combo? Lisp has a compiled flavor by the way.
Jul 18 '05 #17

P: n/a
Arich Chanachai <ma*******@fastmail.fm> writes:
But I thought Python was an all-purpose language. After all, OS's
have been written in Lisp before too.

Pure Lisp? Or a Lisp/C/Asm combo? Lisp has a compiled flavor by the way.


Compiled flavor? Lisp has been compiled since the 1950's.

No, there was no C code on Lisp machines. There was some low-level
code at the bottom whose capabilities were such that you could
accurately call it asm, but it was Lisp too, just a very restricted
form.
Jul 18 '05 #18

P: n/a

"Michael Hobbs" <mi**@hobbshouse.org> wrote in message
news:10*************@corp.supernews.com...
David Brown <da***@graydragon.net> wrote:
Hello. I recently came across a free operating system called Unununium (or something like that) and it was developed in Python and Assembly.

Now, I have been looking for a way to make an operating system for a long long time and the only possibilities I could find were C++ and assembly.


The problem when using Python instead of C for OS development is that
C was *specifically designed* to create an OS, while Python was designed
for completely different purposes. If you want to write an OS, it would
be wise to use a language that is suited for that purpose. If you
dislike C so much and prefer Python so much more, your first step should
be to design a Python dialect that is more appropriate for writing OS's.


Yes, that sounds pretty realistic : ) For someone who is choosing the wrong
language to write an OS, and who I would guess doesn't understand interrupt
programming and the like -- their first task should be to redesign Python!!

Jul 18 '05 #19

P: n/a
But I thought Python was an all-purpose language. After all, OS's
have been written in Lisp before too.


It is a general purpose APPLICATION language. I am surprised that this
hasn't been mentioned on this thread.

An OS is NOT an application. It is a completely different kind of program.
Do you guys understand the difference between user and kernel mode? Do you
know what address spaces and hardware interrupts are? Python is not
equipped to handle these things. You would end up doing so much in C
extensions that it could barely be called Python.

I am not trying to be insulting... but unless someone would like to educate
me otherwise, the idea of an OS written in Python is almost ludicrous. As I
said, I think you might mean an OS SHELL, which would be a reasonable
(although maybe unconventional) thing to write in python.

Also I am no threading expert, but I would imagine it would be very hard to
write a task scheduler in Python given that it has the whole GIL thing. (As
I said that isn't my domain of expertise but I'm sure someone here could
expound on that.)
Jul 18 '05 #20

P: n/a
"Roose" <b@b.b> writes:
An OS is NOT an application. It is a completely different kind of program.
Do you guys understand the difference between user and kernel mode? Do you
know what address spaces and hardware interrupts are? Python is not
equipped to handle these things. You would end up doing so much in C
extensions that it could barely be called Python.
You'd need some library functions to let Python access device registers
and you'd need some low level code to dispatch interrupts into Python code.
I am not trying to be insulting... but unless someone would like to educate
me otherwise, the idea of an OS written in Python is almost ludicrous.
Is an OS written in Lisp also ludicrous? Because it's been done.

When Unix was first written, people thought implementing an OS in C
was ludicrous. Everyone knew OS's had to be written in assembler.
Also I am no threading expert, but I would imagine it would be very hard to
write a task scheduler in Python given that it has the whole GIL thing. (As
I said that isn't my domain of expertise but I'm sure someone here could
expound on that.)


The GIL is not part of the Python language. It's just an artifact of
one particular implementation.
Jul 18 '05 #21

P: n/a
So how would I make an OS Shell?
Jul 18 '05 #22

P: n/a
Paul Rubin wrote:
When Unix was first written, people thought implementing an OS in C
was ludicrous. Everyone knew OS's had to be written in assembler.


Actually, when Unix was first written that belief was entirely
correct, and OSes *did* have to be written in assembler.

That is, pure C did not have the capability to handle all
that was required. I recall it taking a good decade before it
became *common* to find C compilers with, for example, @interrupt
support to let the compiler generate code that properly saved
all registers and used RTI instead of RTS (or whatever it might
have been called one one's particular flavour of CPU).

Now, once you added a few tiny interrupt handlers, and some context
switching (stack manipulation) routines, pretty much everything else
*could* be done in C, but that doesn't invalidate the point.

I think it's safe to say that none of pure C, pure Lisp, or pure Python
are really capable of being used as the *sole* language to build
an operating system.

It's also safe to say that this is a largely irrelevant point.
It would probably only be of academic interest to try to do
something like that. Any practical attempt would not think more
than twice of resorting to a little "glue" in assembler or in
the form of "canned" byte sequences built by hand and stuck
into the appropriate places in memory...

-Peter
Jul 18 '05 #23

P: n/a
Peter Hansen wrote:
Paul Rubin wrote:
When Unix was first written, people thought implementing an OS in C
was ludicrous. Everyone knew OS's had to be written in assembler.

Actually, when Unix was first written that belief was entirely
correct, and OSes *did* have to be written in assembler.


*nods*

That is, pure C did not have the capability to handle all
that was required. I recall it taking a good decade before it
became *common* to find C compilers with, for example, @interrupt
support to let the compiler generate code that properly saved
all registers and used RTI instead of RTS (or whatever it might
have been called one one's particular flavour of CPU).
If my memory serves me, you are entirely correct.

Now, once you added a few tiny interrupt handlers, and some context
switching (stack manipulation) routines, pretty much everything else
*could* be done in C, but that doesn't invalidate the point.
*nods*

I think it's safe to say that none of pure C, pure Lisp, or pure Python
are really capable of being used as the *sole* language to build
an operating system.
*nods*

It's also safe to say that this is a largely irrelevant point.
It would probably only be of academic interest to try to do
something like that. Any practical attempt would not think more
than twice of resorting to a little "glue" in assembler or in
the form of "canned" byte sequences built by hand and stuck
into the appropriate places in memory...

-Peter


Indeed indeed. Once must remain focused and ask oneself what he/she is
attempting to achieve. In all likelihood, a little asm/c/python glue
work won't hurt the objective, especially given that doing otherwise
would entail a very _low level_ reworking of Python that would take as
much and likely more effort and skill than to resort to asm/c when
Python falls incapable. One could do a Python-Lisp OS w/ Lisp used for
the Python incapable areas, but you would near entirely loose the
benefits of Lisp in that respect--- it would have to be so low-level,
could you call it Lisp? (A question someone else here posed in this
thread.)

- Arich
Jul 18 '05 #24

P: n/a
Is an OS written in Lisp also ludicrous? Because it's been done.


Can you point me to this? I'd like to see how "truly" Lisp it is.

My first guess would be -- not very. And I'd like to install it on my PC.
Jul 18 '05 #25

P: n/a
Well can you describe what kind of things you want to do exactly?

My guess is you are not out to develop a new algorithm for virtual memory or
task scheduling.

There are many parts to an OS shell. An example is the command line, i.e.
bash and the like in Unix, and cmd.exe in Windows. In Windows, Windows
Explorer could be considered part of the shell, as well as the start menu
and all that user-specific stuff.

Basically you need to pick your OS, and then find out what the API to
program the shell to would be. e.g. in Windows you would do it with the
Win32 API. This will let you do things like delete and create files,
interact with user structures, the registry, etc.

OR, as a first stab -- I would just write a prototype. i.e., don't tie it
to a real OS. Just pretend you have your own "users", your own "file
system", your own display space, etc. This will help you get a much better
idea of what you want to do.
"David Brown" <da***@graydragon.net> wrote in message
news:10*************@corp.supernews.com...
So how would I make an OS Shell?

Jul 18 '05 #26

P: n/a
My experiment, Cleese, was making progress before I got distracted by
other things.

The approach was a micro-kernel in C made up of the CPython bytecode
interpreter with the file-related calls to libc ripped out and some
bare-metal port read/writes and memory operations exposed to Python as
built-in functions.

Everything else could then be written in pure Python. Dave Long was
able to write a VGA driver in Python and an implementation of Sokoban
that used it. You could then boot your machine to Sokoban :-)

I should probably get back to it at some stage.

see http://cleese.sourceforge.net/
James Tauber
http://jtauber.com/blog/

Jul 18 '05 #27

P: n/a
"Roose" <b@b.b> writes:
Is an OS written in Lisp also ludicrous? Because it's been done.
Can you point me to this? I'd like to see how "truly" Lisp it is.


http://en.wikipedia.org/wiki/Lisp_machine
My first guess would be -- not very. And I'd like to install it on my PC.


Although written with federal funds at a university, it was never
released to the public, but was instead offered for sale from some
companies. The conflicts over this led to the birth of the free
software movement.

Also, it was never intended to run on PC's (which didn't exist at that
time). It needed special hardware that was built for the purpose of
running Lisp. Lately there are people trying to program PC's to
simulate the Lisp hardware and to get the Lisp Machine software
released (now that the commercial market for it has long since dried
up). However, both of those projects have a ways to go.
Jul 18 '05 #28

P: n/a
On Sat, 08 Jan 2005 08:28:12 GMT, "Roose" <b@b.b> wrote:
I am not trying to be insulting... but unless someone would like to educate
me otherwise, the idea of an OS written in Python is almost ludicrous. As I
said, I think you might mean an OS SHELL, which would be a reasonable
(although maybe unconventional) thing to write in python.


That's a crazy idea I once had - what if a user could run Python as
a shell of Linux/other free U**x, and access every single subsystem
and piece of data in the object-like manner?

Sure, things like pipes and immediate access to files without having
to open() them and the whole filesystem hierarchy would have to be
added. Quite a lot of plumbing work would have to be done,
but once it were done, it would be like an object operating
system, everything organized nicely in predictable object hierarchies
with dot access.

System scripts would no longer be a mess that breaks every now and
then depending on slight differences in filesystem hierarchy. Python
dictionaries with their ability to quickly bind names to various
objects would make it possible to keep such hierarchy stable, even
with data moving around on different physical disk partitions and
folders. Instead of saying:

# cp /etc/postfix/main.cf /mnt/floppy

the user could say e.g.

..>>> copy system[config][mta] floppy

or

..>>> copy system.config.mta floppy

In an "object system" like Python it could be reasonable to
consider writing a class that would implement at least a
subset of generic interface to the equivalent functionalities
of various MTAs. Maybe. With traditional filesystems trying
smth like that is not really reasonable, because 99% of
the time it would work, but 1% of the time it would fail
and that 1% would ruin the whole venture, as handling
low-level OS complexity for a non-tech user has to be
more reliable than that - in two cases when I installed
Linux for free for someone the installation was finally
deleted by those users because the desktop shortcuts
to devices like floppy and CD ultimately failed to work
for some reason and using 'mount -t iso9660 ...' was
not an option that they would consider learning and
using really.

Think about all the potential! On top of clean, stable
system interface a user could use map, filter and reduce
functions on various system objects. Handlers for
files with known structure could be written, so
dot or list or dictionary access would allow manipulating
data inside the files, like file[rownumber]='spam', or
spreadsheet_file['A2', 100]. Or you could issue commands
like browser.go('somewhere') or desktop.edit('hello.txt').

I was considering writing smth like this myself but it's
way over my head re low-level OS and kernel stuff. :-(

IMHO Linux problem has long been that in its lower level
interface (above kernel and below GUI) is way too much like
traditional UNIX. Sure someone with sysadmin experience
can use it - but in my experience it's way over the head of
the typical user. Trying to teach them about mknod and
/dev/* hierarchy is hopeless and too hard for them.

--
It's a man's life in a Python Programming Association.
Jul 18 '05 #29

P: n/a
Paul Rubin:
Lately there are people trying to program PC's to
simulate the Lisp hardware and to get the Lisp Machine software
released (now that the commercial market for it has long since dried
up). However, both of those projects have a ways to go.


There's a video of someone demoing how to use a Lisp Machine at
http://lemonodor.com/archives/000103.html

Andrew
da***@dalkescientific.com

Jul 18 '05 #30

P: n/a
"Roose" <b@b.b> writes:
Well, then of course you know I have to say: An OS does not run inside a
browser. There's a sentence I never thought I'd utter in my lifetime.

So that is an irrelevant example, since it obviously isn't a task scheduler
in the context of this thread.


Huh? I'm just baffled why you think writing a scheduler in an OS is
harder than writing one in an application. You have some means of
doing a coroutine switch in one situation, and some means of doing a
hardware context switch in the other. Aside from that the methods are
about the same.

Why do you think there's anything difficult about doing this stuff in
Python, given the ability to call low level routines for some hardware
operations as needed?
Jul 18 '05 #31

P: n/a
Huh? I'm just baffled why you think writing a scheduler in an OS is
harder than writing one in an application. You have some means of
doing a coroutine switch in one situation, and some means of doing a
hardware context switch in the other. Aside from that the methods are
about the same.
Because of performance. Task schedulers and device drivers tend to be
timing sensitive. Go look up "task schedular latency". The longer your
scheduler spends trying to figure out which thread to run, the longer the
latency will be.

I mean in the worst case, if you are interpreting everything, what if you
change the task scheduler code? Then an interrupt happens, and oh shit we
have to parse and recompile all the scheduling code. Oh wait now we ran out
of kernel memory -- now we have to run the garbage collector! Let your
interrupt wait, no?

It just seems nonsensical. Maybe not impossible, as I've already said. I
haven't tried it. But go ahead and try it -- I would honestly be interested
in the results, all kidding aside. It shouldn't be too time-consuming to
try, I suppose. Get Python running in the Linux kernel, and then replace
the task scheduling algorithm with some Python code. See how it works. I
suspect you will degrade the performance of an average system significantly
or unacceptably. But who knows, I could be wrong.

Of course, hardware is getting faster as you say. But multitasking
performance is still an active and important area of OS research, and I
doubt that any designer of an OS (that is actually meant to be used) would
spend any cycles to have their task scheduler in Python -- and that will be
probably be true for a very long time. Or maybe I'm wrong -- go bring it up
on comp.os.linux or whatever the relevant newsgroup is. I'd like to hear
what they have to say.


Why do you think there's anything difficult about doing this stuff in
Python, given the ability to call low level routines for some hardware
operations as needed?


Jul 18 '05 #32

P: n/a
jtauber schreef:
see http://cleese.sourceforge.net/


There is not much to see there, most of the wiki is filled with spam...

--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9
Jul 18 '05 #33

This discussion thread is closed

Replies have been disabled for this discussion.