Re: My broken dream.

[William Leslie]

2009/9/18 Alan Grimes <address@hidden>:
> William Leslie wrote:
>> "The main reason for further development of L4, like the name of
>> L4.sec suggest, was the lack of
>> security. There was no fast way to implement information flow control
>> and no way to manage the kernel memory a task consumes."
>>
>> - L4.sec Implementation, Kernel Memory Management, Bernhard Kauer
>
> You know what?
>
> I've been saving up to replace my six year old computer. But instead,
> I'll gladly pay those $300 to you if you'll just give me a usable L4
> developer's kit WITHOUT A TRACE OF FLOW CONTROL OR CAPABILITIES.
>
> 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?

>> Implementing workable information flow control is a requirement for
>> any secure 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. 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.

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.

> Douglas Adams claimed that the least imaginative creature in the
> universe is a Vogon. I can do him one better. There is something even
> duller, an *Anti-imaginative* creature. That is the type of creature I
> find writing things like process.c in Minix3 and L4.sec. This type of
> creature can't imagine anything less imperfect than unix so, when
> confronted with a GOOD OPERATING SYSTEM, he instantly directs *ALL* (not
> some, but _ALL_) of his energies towards rendering it useless like the
> unix he's familiar with so nobody gets the chance to actually express
> themselves with their computers.

I agree.

> If you think that I shouldn't be allowed to own a computer WITHOUT
> "information flow control" then I hate you. I simply hate you. I mean
> there would be a new golden age of computing if the full power of L4
> could be realized!!! BUT NOOOOOO asshats such as Mr. "Implementing
> workable information flow control is a requirement for any secure
> system." have to get in the way. =(((((((((((((((

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. 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.

>> [Talk about DOS]
>
> It's relevant because the problem with HURD has always been that it's
> allowed the perfect to get in the way of the good enough, or even the
> Damn Good.

It's been pragmatic, yes. Overly pragmatic? Maybe. That's mostly the
engineer's imperative, I think.

> [generic performance complaints about modern monolithic kernels]

> It either doesn't exist on my system or is of such negligable importance
> that I really don't care.

I am genuinely pleased for you.

> 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/

>> I thought they were strange and over-engineered when I first read
>> about them. For months they seemed completely pointless. But after
>> reviewing the literature carefully... well, I'll use Shap's words
>> (here about orthogonal persistance, but just as relevant):

Oops, I lie, that was Marcus.

> GODDAMN IT!!! THAT'S ANOTHER CONCEPT I CAN'T STAND!!! I make so many
> mistakes that I would go insane if I couldn't discard them by closing
> the window and restarting the application. That's not to say that I
> haven't written and deployed applications that simulate an orthogonal
> persistent interface but then I'm the one who gets to say what stays and
> what goes. Again, I'll pay good money for an operating system without
> 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.

> 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.

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, 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.

* and by extension that we should all develop software according to
your specification

> 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.

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.

> 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.
1. Create it based on the whimsical desires of some random jerk.

> I mean when I
> was reading that L4.sec document I was so furious that I wanted to rip
> out my big 45 pound CRT and throw it out the window.

Nobody is stopping you.

> Who the hell is
> sitting on their high throne and telling me that I can't have a nice
> simple L4 based operating system until it has been sufficiently
> bastardized and otherwise fucked over to be useless for anything? =(((

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.

>
>>> (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). 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.

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.

William Leslie