Re: Questions on the interoperability between libc, gnumach and hurd servers

[Richard Braun]

On Sun, Sep 16, 2012 at 09:26:18PM +0200, Svante Signell wrote:
> What lack of respect? Lack of respect for what. Your sometimes not very
> nice language? At least I don't call you names, as you do. And Samuel
> does try nicely to answer my questions, but you only provoke.

I don't know. Let's ask a search engine. Oh look at this :
http://lists.debian.org/debian-devel/2012/09/msg00021.html
http://lists.debian.org/debian-hurd/2011/04/msg00040.html
http://lists.debian.org/debian-devel/2012/04/msg00600.html
http://lists.debian.org/debian-devel/2012/07/msg00759.html

And that's merely what's archived and quick to find. Oh and Samuel is
an exceptionnaly nice person, but he too is getting angry at you, or
I'm not understanding "Damn, grow up" correctly.

> > You've spent more than a year working on this system, and you
> > still don't get the big picture of it, 
> 
> With Samuels writing about RPC things get clearer. I have not found this
> written down somewhere before, have you?

Yes. First you look for "hurd" in a search engine, and you'll get to
http://www.gnu.org/software/hurd/hurd.html, then you use your eyes and
see the documentation links on the right. One of them is MIG, and the
global description states "Mig is an implementation of a subset of the
Matchmaker language. Matchmaker is a language for specifying and
automating the generation of multilingual inter-process communication
interfaces. MIG is an interim implementation of a subset of the
Matchmaker language that generates C and C++ remote procedure call
interfaces for inter-process communication between Mach tasks."

Below, there are a few links for more complete documentation, and even
one ("MIG in action: io path"), to
http://www.gnu.org/software/hurd/hurd/io_path.html

Did you know teachers get angry when the same student repeatedly shows
his inability to make any effort towards some progress ? And we're not
paid to teach you. So don't expect me to answer nicely to such a lazy
and stupid person like you.

> > asking question such as why
> > isn't setsockopt implemented in eglibc, 
> 
> I did not ask that, and it is not implemented there either, it is in the
> Hurd ...

>From http://lists.gnu.org/archive/html/bug-hurd/2012-09/msg00018.html :
"Why make things so complicated, via the RPC stuff? Implementing the
whole function setsockopt in eglibc would simplify a lot."

It's not strictly the same, but external readers will quickly get the
idea.

> > or what are the powerful
> > features of the Hurd,
> 
> Yes, where is the killer app?? Maybe when everything missing is
> implemented, there might be some, or not.

There are several killer apps, the main one for me being extensibility.
Another could be that extensibility is accessible to unprivileged users.
The whole structure being layered on top of capabilities make it
possible to transfer the rights one needs instead of starting from a
privileged state and reduce it afterwards. It's a huge security feature.
Finally (but this would require all drivers in userspace), the increased
protection between applications and system services, which makes it very
unlikely that anything (including hardware) gets corrupted and rendered
unsuable.

I'm not going to list all the advantages of the microkernel based multi
server model, there are many descriptions out there. And about the Hurd
specific bits, read http://www.gnu.org/software/hurd/hurd-paper.html.

> > or even is this really a client-server
> > implementation... 
> 
> I wanted to know more about the inner workings about the Hurd compared
> to e.g. Linux, an Samuel answered that partly. What did you do: ask more
> questions.

I asked only one question, which is basically how someone can work so much
time on something he doesn't understand *at all*. And this is actually a
rethorical question, because the true meaning of my message is really
"learn the thing or get out".

> > And you're blaming lack of documentation for that ?!
> 
> The documentation has large need for improvements, admit it! E.g. in the
> Hurd manual large parts are empty, i.e. no documentation at all.

Improvements, sure, but as I said, it's decent. If people needed
complete documentation to work on anything, well there wouldn't be much
of anything out there. The only true documentation is the source code.
If you don't understand that, noone can really help you.

> > Seriously ?
> > 
> > I mean, you're really, seriously asking those questions ?!
> 
> Of course I am. Reading the gnumach, mig and hurd manuals (and your
> master thesis) did not give me the big picture as the rpc.mdwn did. 

My "thesis" wasn't meant to, it's about the details of something you're
not expected to fully understand to work correctly, as we repeated so
many times. And if you didn't get the idea from the other manuals,
that's because you're not trying to understand what you're reading.

> > From there, it seems to me you have two options here. You either keep
> > working on stuff that doesn't require understanding operating systems
> > (that is, you work on high level package porting, or you move on to
> > another project that isn't an operating system), or you get to work
> > and read and learn about them.
> 
> I'll do both. I'm learning this OS stuff slowly, and in the learning
> phase I'm asking questions, especially when things are overly
> complicated. What's wrong with asking questions, I even offered to write
> down things in a (for me and many other people) clearer way, but that
> does not seem to be of interest.

Nothing is wrong about asking questions, but this isn't the place to
waste time on the basics. Things are complicated but not "overly". You
just need a bit of training like anybody does. Read a book about
operating systems, or use a search engine to find sites such as
http://wiki.osdev.org/. And please, please, LEARN C, because it's
almost not acceptable that someone writes patches for C programs,
replacing static with dynamic allocations, and doesn't understand what
malloc, realloc, and free really do, forcing people to go through
many review iterations just because of your lack of willingness to
correctly learn things instead of relying on others to do the job.

> > Seriously.
> 
> Yes, sincerely.

I can't believe that.

-- 
Richard Braun