[EROS-Arch] a brief chat with a friend

[Kragen Sitaker]

I chatted with my friend Matthew about EROS; he hadn't heard of it
before.  Here's an edited transcript of our conversation.

I have a couple of questions:
- did I get anything wrong?  Some of the answers refer to things that
  haven't been built yet in EROS, so I tried to answer them to the best
  of my ability with what I think KeyKOS did.
- is there any document to which I could have referred him that would
  have answered his questions?

<matthew> Okay, I've read about capabilities and persistence.
> what do you think?
<matthew> It sounds great.
<matthew> The things I read don't really address the technical difficulties in what they're doing.
<matthew> so I'm not sure why EROS isn't already up and kicking
> like what?
> oh.
> EROS runs.
> writing useful software is always hard.
> writing a useful OS means writing enough useful software that you can run e.g. Emacs,
> or writing the useful software (text editors, compilers, etc.) yourself for the OS.
> both are lots of work compared to the amount of effort needed to publish academic papers about [...] EROS [...].
<matthew> oh, I see.  that's a good point.
> which I guess is why RMS gets so pissy about people pronouncing Leenooks as Leenooks.
<matthew> Are capabilities and persistence somehow incompatible w/ the idea of writing a system that boots, emacs, and gcc and letting people go to town?
> no.
> but gcc needs, basically, Unix.
> or lots of hacking to make it run on something non-Unixy.
> Emacs too.
<matthew> you should port Emacs and gcc to EROS
[...]
> I did the first bits of work on Emacs: analyzing strace output to see what system calls and ioctls it uses for a minimal run.
[...]
> I think I'd like to do Python first, though.
[...]
> see, if I got the Python interpreter to run on EROS, which would probably be worlds easier than getting Emacs running on EROS, I could run useful programs.
> and especially if I got network code working, I could get Zope running on EROS.
<matthew> Now one thing that confuses me.  I have a file and I only have the capability to work with this file when I'm in what they call a "special-compartment".  When I'm removed from that compartment I can't access those files anymore.  But while I'm in the compartment they claim I can't copy the files out as I could if I was just in a standard "group".  But if I can read the data what's to stop me from transferring its contents?  If I read the word "foo" f
<matthew> "foo" somewhere else.  Maybe I don't understand the totality of the capabilities system.  I understand they can prevent network access for certain programs.  But I don't understand how they prevent me from reading in data, manipulate that data and still expect to stop me from doing new things with that data (maybe like moving it to a new file or sending it over the network).  The only way I could see them doing this is if they somehow tagged the dat
<matthew> do you understand what I'm saying?
<matthew> can you explain what I'm missing if you do.
> I lost some text.
> the word "foo" f ...
> "foo" somewhere else.
> so you can't confine people inside a computer.  You can only confine computer programs inside a computer.
> Confining people requires other measures which have other problems.
> You can, however, prevent people from using the computer as a convenient way to move data out of its compartment.  If you don't have write access to anything outside of compartment A while you're allowed to read compartment A, then once your compartment
> A access is revoked, you can no longer access any notes you made on the computer while you had access to compartment A.
<matthew> "foo" from a file I can then transfer the word
<matthew> then the next line was: "foo" somewhere else....
> yes.
> but it's still useful to be able to confine computer programs, even if you can't confine people.
<matthew> okay, that makes sense.  I understand.
<matthew> I was thinking in the old style.  Knowing what permissions you have though seems like it would get confusing.  I know it's the "programs" that really have the permissions but one program might be constrained in such a way with some objects and not some way w/ other objects.  it seems like it would dissolve the idea of "i own this"
<matthew> maybe that's just ACL thinking getting in the way
> well, it's just that you control your files, not your programs.
> your programs may have their own files, like gcc with its temp files.
> but things like C programs should belong to you, and editors and compilers should only be able to access them when you want them to.
> your UI should be able to access them all the time, of course.
<matthew> yeah, okay.  So programs like spell checkers and their dictionaries wouldn't really be "owned" by anyone.  right?  the dictionaries would be owned by a the program but the program in turn isn't owned by anyone, right ?
> the program should be accessible from a system-wide directory of useful programs.
> which ordinary users would have access to.
> dictionaries too.
> also, closures binding the program to a particular dictionary should be accessible from the system-wide directory.  These are what you'd normally invoke on your data.
> They'd create a spell-check process which would check your spellings and then exit.
> You might want to make a less-discreet closure that bound one of the system closures with a mutable personal dictionary of yours.
<matthew> hmm, maybe my fault lies in understanding what a program is under EROS
> well, just like in Unix, there are two forms of a program:
<matthew> in UNIX i think of a program as a binary file that when run is loaded into memory.  In EROS is a program just a file?  from something I just read in their FAQ i think the answer is no.
> there are program instances, many of which are short-lived --- you create one to do a job, then destroy it when you're done;
> and there are program factories, which are the output of the linker.
> you invoke a program factory to get a program instance.
> the program factory can actually be thought of as a long-running program that spawns other processes.
> or you can think of it as a binary file in the Linux filesystem.
<matthew> oh, so all programs are always "running" in that sense.
> right.  but they're also nearly always "swapped out".
<matthew> yeah, that makes sense.
<matthew> what about a server?  say, httpd.  is it a program instance or is it a factory that spawns an instance when something tries to connect?
> factories don't normally have capabilities to mutable things like listening sockets.
<matthew> so httpd would be a program instance?
> it's probably a good idea to have a standard httpd factory that you use to generate httpd instances.
> because that means, among other things, that you can use your normal compilation tools to build httpd.
<matthew> a good idea?  the way I was understanding it was that *every* program has an associated program factory.  is that wrong?
> and since httpd is big and probably buggy, you don't want httpd instances to live forever.  in fact, apache already discards httpd instances after a number of requests.
> well, there are some programs that are always running and never get started.
> they don't need factories.
<matthew> you mean program factories actually compile the program for you?
> and not every new process has to be created by a factory.
> no, the compiler produces a factory as output.
<matthew> which programs are these?  some very special services?
> yes, some of the stuff in the tcb.
<matthew> if a new process isn't created by a factory where did it come from?
<matthew> if it wasn't just "always there"
> well, anybody can create a new process if they have access to the resources.
> just like in Unix, any process can call fork().
> and once you call fork(), the child can rearrange itself however it likes.
<matthew> s/program/process/
> actually, factories create new processes by program mitosis too.  unlike in unix, where the equivalent of a factory is a binary file.
<matthew> Many people seem to have the idea that EROS should be given away in the style of Linux or the various BSD-like systems. These people are entitled to their opinions. I do not share them.
<matthew> what's up w/ that quote?
> also, the creation of a new process is fairly different in EROS; you basically specify what you want the new process to have in it.
> it's out of date.
> what page is it on now?
<matthew> ok.  http://www.eros-os.org/faq/avail.html#when-release
> yeah, Jonathan got his Ph.D. several years ago :)
> the code base has been released for several years.
> as you see, that question was last updated in 1998 :)
<matthew> do you know Jonathan personally?
> shortly after that, he decided to license the code under the MPL.
> Later the GPL.
> I haven't met him in person.
<matthew> hmm what does EROS stand for?
> 'extremely reliable operating system'.
<matthew> oh, duh
<matthew> it was on the top of the main page :)
<matthew> that's cute they use cupid all over the pages
> or, as the greeks knew him, eros :)
<matthew> yeah, whatever.  :)
<matthew> how up to speed to you on EROS?
> not tremendously.
<matthew> you understand most of the theory though, right?  just not the implemenation details, yet?
> right.
<matthew> how big is EROS?
[...]
<matthew> "Building the EROS system requires G++ 2.7.2 or later. Because EGCS has broken for years, we use cross compilers rather than reusing the native Linux compiler."
<matthew> what does that mean?
<matthew> I know it's probably out of date, but still
> building a kernel is not like building a user program.
> user programs get loaded by ld.so.
> kernels get loaded by boot loaders.
> egcs kept changing what it was outputting in ways that broke the boot loader.
> that was my recollection, anyway.
<matthew> so you need to do special things to get gcc to output a kernel image?
> aha.  So the EROS source is 179,000 lines or so, or 6.6 megs.
<matthew> you can digest that in an afternoon
> haha
> that was a year ago.
> and my 'built source tree' comments were wrong.  I was looking at the wrong palce.
> I can't really remember the problems jonathan was having with egcs.
> http://www.eros-os.org/~majordomo/cap-talk/0155.html: this was the real watershed email.
> where Jonathan decided to get serious about developing EROS.
<matthew> that was a long time ao
> that was fifteen months ago.  and the difference between then and now is amazing.
> from what I see on the mailing lists.
> and bugzilla.
<matthew> cool.  you keeping up to date on the project?
<matthew> Are you active on the Mailing Lists?
> yes.  no.
[...]
<matthew> What about all the metaprogramming, reflection, reification craziness of Tunes?  Is EROS influenced by any of that?
> no.
<matthew> Tunes is so funny
> yes.  inspiring.
> not strange funny, inspiring funny.  like remy charlip and wavy gravy.
> I'm getting sleepy, so ignore me.
<matthew> ok
> ;)

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
Perilous to all of us are the devices of an art deeper than we possess
ourselves.
       -- Gandalf the White [J.R.R. Tolkien, "The Two Towers", Bk 3, Ch. XI]