Re: My broken dream.

[Alan Grimes]

William Leslie wrote:
> 2009/9/18 Alan Grimes <address@hidden>:
>> William Leslie wrote:
>> People who write such complaints about L4 simply don't understand it. In
>> any event, nothing can be slower than my computer these days. Seamonkey
>> "pauses" all the time for no reason (any mouse or keyboard input of any
>> kind is sufficient to trigger such a "pause"). and consumes 100% CPU for
>> up to 30 seconds at a time, completely frozen up and then frequently
>> pops up script stalled warnings. (obviously a bug because I have two 1.2
>> ghz CPUs under the hood.) After my experience with seamonkey and kde4,
>> you could not pay me to give a flying #### about a few hundred
>> microseconds!!! =P

> Right. And the problem is... capabilites?

My point is that I'm experiencing profound cognitive dissonance between
you complaining about microseconds and my actual living experience with
the system.

>> I think I found that documentation. It basically says "Since we don't
>> like Jochen's amazingly beautiful design, we've decided to #### it up."
>> It's only real complaint against L4 stock was that it was *slow*, and it
>> wanted to do away with L4's most brilliant feature, the clan and chief
>> system. =((((

> You might have interpreted it that way, but it was both slow *and*
> ugly. It was hideous! And it didn't really work, either. 

Aha! Now there is a valid argument!

> My understanding was that the only way to get unforgeable references was
> to introduce them into one process (an ambient authority) and require
> all IPC to pass through it before any application would act on it.

My understanding was that all IPC was stamped with a return address
therefore pipes were inherently separate. At the top level you do not
want to hide API's because that adds complexity and destroys
functionality. (so it's silly to want to forge a reference to an API
which is already public.) If you really did need to control which
process had access to which resource (I can't imagine why!), you add
some code to the runtime library of each process which checks the return
address on every IPC and rejects any invalid calls. The other great
approach is to let the chieftan do his job. Therefore it remains trivial
to create an arbitrary new top-level clan with full access to the system
so I won't have to spend the rest of my life on this mailing list
begging you for the keys to the security domains I need access to.

As for speed, when you really need it, you use a shared memory
scratchpad (scarey, I know,) but if done right, would only be limited by
the cache system on the CPU (which is a very non-trivial issue on SMP
machines).

> The sad part is that the only thing a microkernel *should* do imho is
> provide a fast, protected means of IPC, and l4 *did not do this* at
> the time.

What do you mean by protected here?
As long as return addresses are unforgeable, the system will work and be
perfectly secure. *nb, I have not spent great time meditating on this issue.

> I'm not saying that you shouldn't have a computer without reasonable
> security. I simply wouldn't have a reason to put forth effort
> developing it for you. In fact, I think the biggest qualifier for
> asshatism is assuming everyone has the same desires and needs as you,
> and that therefore the sun shines out of L4's ass.

Good comeback! Best I've read in recent years, congrats.

Really, no kernel is 1/10th as good as L4. I want to see it in action
before people start making half-assed changes to it. =(

> I like L4, I really do, and I think it would be a good base for a rather 
> fault tolerant
> and performant operating system. But it's not something I would work
> on myself, because I would *like* to be able to confine applications.

To me confinement has two aspects.

A. Is the process confined to its address space?  (Yes for L4).
B. Are there any "back door"/unintentional IPC mechanisms? (On L4, no),

Therefore, applications are confined on L4.

I don't want anything more.

Really, I want there to be nothing more.

>> Give me an L4 without capabilities and keep the one with. Then see which
>> of us can do more cool things with it. =P

> http://l4ka.org/projects/pistachio/

Yes, that's a good kernel. Last time I actually tried to use it, I
couldn't find any documentation for Sigma0 and this whole business of
loading modules through grub was deeply mysterious (and undocumented) so
I really couldn't make any progress with it. The demos kicked ass though!

One L4 I downloaded kept its source code in secret, deeply buried
directories so when you went to build it the source code suddenly
materialized in the main directory and it would work. This is obscene
and unacceptable because I need to know where the code CAME FROM in
order to modify and customize it. I strongly suspect that was the intent
of the design, to prevent mere mortals from understanding and modifying it.

[Orthagonal persistence]
> like http://www.erights.org/data/serial/jhu-paper/upgrade.html brings
> out, it's good for crash protection, but in the interests of reliable
> software it can't be the be all and end all.

Wonderful article.

>> Talk is cheap.
>> Do you actually have such a system or do you just like to fill up
>> academic journals masturbating over it?

> Right now I am using GNU/Linux, but that is because I am Yak Shaving.
> My main area of research (in my free time) is currently compiler
> technology (dynamic effect analysis and optimisation), and I needed
> more ram than I could have under pure GNU. I intend to get into
> Coyotos development in the next few years.

I don't get the part about more ram.... Linux on a modern 64 bit
platform should allow you to use tens of gigabytes of ram/VM...
Hopefully you only need that space for the research part of your effort. =P

Compiler technology is definitely the most important part of any free
software system and the most difficult (hence we only have a single
ultra-crufty compiler suite).

Good luck on your project.

> But I'm not filling up academic journals. The people who do research
> into capability systems have written a lot of quality software. While
> I have not read your paper (though it sounds interesting) or know of
> the numerous quality software products you have surely produced, 

Actually, I'm currently the most active developer on a package called
ktechlab. I also write in-house applications for a company I contract
for in Java.

>I'm not interested in your blanket slurs or what technology and models you
> do not like. I can't imagine them meaning anything to anyone without
> you doing something about it. Bitching to a mailing list that not
> everyone has the same priorities and interests as you* is not /doing
> anything/, except (when it contains personal affronts) making you
> sound like a four year old.

If I coulda I woulda. =(

>> My point is, WHO THE FUCK ARE YOU TO JUDGE WHICH HABITS ARE BAD??

> It's perfectly fine to judge ones own habits bad. It's also fine to
> judge someone else's software deficient when a replacement exists, or
> you are developing it yourself. I'm not judging your opinions, though.
> I'm telling you about conclusions that were reached by people far
> smarter than me, their entire reasoning recorded in this list for
> anyone to read.

It's always a bad idea to yield to a "higher authority" on anything. =P

> I should probably also ask who you are to judge the lead engineers,
> seeing as you are not interested in contributing either code or an
> intelligent discussion about why everyone should submit to your
> software engineering whim.

The lead engineers aren't ones to talk about producing code. Where is
the link to Hurd 0.9 alpha anyway? =P

>> Want to know how to design an operating system that nobody will ever
>> want to use?

> You've already enlightened me:
> 0. Write a paper about it rather than implement it.

I tried, I tried. =(

> No-one. You are free to start an L4 based operating system free of
> secure extensions. You are free to encourage like minded individuals
> to join you. I think if you did so, you would have some degree of
> success, if you were less of a jerk, and contributed more than hot
> air.

That's what everyone says about all free software. =/

The truth is that it takes an intractable number of man-years to make
any non-trivial change. That's the nature of the system. =(

This is not surprising because the relevant parts of all the tools are
not documented at all because it is assumed that they'll always be used
on and for unix and since they already work on and for unix, there is no
reason for anyone to ever need to change them. So when you say you want
to create something that's NOT UNIX, all the tools suddenly stop working
and leave you no manual.

>>>> (Linux has no useable IPC mechanisms.)
>>> I've no idea how you can come to that conclusion, sorry.
>> [pharsical idea of how IPC should operate without a use case]

> Well, to start with, it makes no sense to be *receiving* a message you
> are not expecting (or what will you do with it?), so we can assume the
> process is aware of that. In that case, the process can set up a unix
> domain socket or pipe (depending on the need for multiplexing the
> connection).

Pipes are one-way and therefore useless. (IIRC).

"Domain sockets" are undocumented anywhere and therefore cannot be used. =(

> As for discovery, PIDfiles and dbus are perfectly
> acceptable. To do this with named pipes and pidfiles is five lines of
> python, with sockets, seven.

> Since you are talking about discovery and messaging, which are two
> unrelated concepts, there is no single interface that will allow you
> to do both.

I'm willing to do "discovery" manually for the first week if I can just
open that first line of communication!! =\

> As for Unix IPC, I never quite understood for the need for books on
> the subject. Beej is the popular reference, if you can stand his style
> of writing.

Ideally, I'd like a leather-bound volume written on hundred-year paper
that says "This is how the damn thing works; use it!"

I never heard of beej before, I'll have to study it. -- buys the book;
hopes for your sake that it's worth it. (because linux sucks, a document
opened from a website can't be dragged over to my other monitor, a nice
24" flatpannel, and my CRT is 20% dead at this point...)

If I'm obscenely successful, I'll emulate clans and chieftans on Linux
and you can witness how awesome my system is.

Ideally, I'd have a useable L4 development environment. (none were
published, last I checked, (about 4 years ago)). Such a development
environment would document all API calls of not only the kernel but all
of the runtime servers too. and come with guarentees that if you use
such and such a library and with such and such a linker script, then the
system will be able to load your code. This is somewhat trivial for
application code because you'll be writing your own interpreters
eventually but for grub modules, I absolutely need to know, in writing,
how that is supposed to work.

-- 
New president: Here we go again...
Chemistry.com: A total rip-off.
Powers are not rights.