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
