nanogui: nanogui and pk


Previous by date: 28 Sep 1999 20:34:08 -0000 Re: nanogui and pk, Greg Haerr
Next by date: 28 Sep 1999 20:34:08 -0000 Re: nanogui and pk, Alex Holden
Previous in thread: 28 Sep 1999 20:34:08 -0000 Re: nanogui and pk, Greg Haerr
Next in thread: 28 Sep 1999 20:34:08 -0000 Re: nanogui and pk, Alex Holden

Subject: Re: nanogui and pk
From: "Frank W. Miller" ####@####.####
Date: 28 Sep 1999 20:34:08 -0000
Message-Id: <199909282017.QAA28038@macalpine.cornfed.com>

> 	Great - let me know and I'll pick it up.  BTW, does pk run executables?
> Are they linked in, or does pk have a filesystem?
> 

Well, since you asked...  =)

Here's a little history, with a little angst mixed in for good measure...

In the beginning there was Fairchild.  This was a simple 32-bit protected
mode real-time kernel with no memory protection.  This was in like about
1989.  I wrote this thing and discovered two things, first, that I really
liked doing it, and second, I could do it.  As the years passed, I brought
it up on a bare x86 machine and started adding a file system.  Then came
grad school.  Somehow I wanted to find some research that would allow me
to keep working on it.  Data streaming was the ticket, my advisor rechristened
the system as Roadrunner and let me continue working on the I/O system.
There was some talk at that time of adding support for virtual addressing
but hey, theres only so many hours in the day, and the I/O system looked
more interesting research-wise.  So its now the late 90's, Roadrunner has
a file system, TCP/IP, web server, runs a.outs, etc.  Its starting to look
like a real OS, and I'm thinking, "gee, wouldnt it be great if I could make
my living doing this?"  But there was this one big hole, memory protection
that potential customers kept asking about.  About this time, the research
funds dried up (aka I graduated) and rather than starve, I decided to get
a job.  Well, I made the mistake of going to work for a startup, you know,
the kind where you just basically move in.  The worst part was, they made
me sort of give working on  Roadrunner.  Well, after working on something
for that amount of time, you cant just walk away from it.  So I devised this
scheme to make everyone happy.  I decided to start writing a new kernel,
called pk, that would implement the memory protection I had been wanting for
a while.  This was good, I was living up to the letter of the law with my
job, I was still adding to Roadrunner, and I was adding memory protection
and a POSIX pthreads API.  Now, theres one more thing, part of my charade
to make "them" think I wasnt working on Roadrunner was that I released pk
under a BSD-style copyright.  So, now its late 1999 and pk is at its BETA
release stage.  I'm pretty happy with the design and have gotten to the point
where I am ready to port the upper layers of Roadrunner to pk.  There are a
couple of problems.  First, a port will mean I'm working on Roadrunner again
and my mgmt won't like that.  But they need me now to maintain the code I've
written so thats not as big a problem as it used to be.  Second, theres this
damn license thing.  pk is BSD'd and I'm not going to change that.
Roadrunner is commercial and I dont want to change that since I still have
these crazy dreams of being able to support myself and my family by doing
what I want to do, call me crazy.  Trouble is, there seems to be a lot of
interest in pk, which is quite gratifying and I want to continue supporting
it.  So, to sum up, the answer to your question is, yes and no.  There is
file system, and TCP/IP, and executable execution and a shell, and vi,
but they all belong to Roadrunner, not to pk.

Whew, sorry bout that...

Later,
FM


--
Frank W. Miller
Cornfed Systems Inc
www.cornfed.com

Previous by date: 28 Sep 1999 20:34:08 -0000 Re: nanogui and pk, Greg Haerr
Next by date: 28 Sep 1999 20:34:08 -0000 Re: nanogui and pk, Alex Holden
Previous in thread: 28 Sep 1999 20:34:08 -0000 Re: nanogui and pk, Greg Haerr
Next in thread: 28 Sep 1999 20:34:08 -0000 Re: nanogui and pk, Alex Holden


Powered by ezmlm-browse 0.20.