On Mon, 2012-09-17 at 11:42 +0200, Richard Braun wrote: > 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
Not Hurd related, read the follow-up mails. > http://lists.debian.org/debian-hurd/2011/04/msg00040.html What's wrong with that posting? I am more patient by now, haven't you noticed? > http://lists.debian.org/debian-devel/2012/04/msg00600.html Not Hurd related. > http://lists.debian.org/debian-devel/2012/07/msg00759.html Not Hurd related. I cannot se anywhere where I call you dumb or an idiot, can you? > > 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. Yes he is nice, unfortunately I cannot say the same of you sometimes. > > > You've spent more than a year working on this system, and you > > > still don't get the big picture of it, Maybe because the _reference_ manuals don't give the big picture, and reading every detail of a function call, and all its variants makes you fall asleep. Such information is very valuable but not as a learning tool. Did you ever attend a class where the only course literature was a reference manual, and no teachers/assistants to ask questions? I doubt 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 As I replied to Samuel, I'm not too fond of browsing web pages to find information scattered in many places, not as an introduction to Hurd. Where is the complete (tutorial) pdf to download and print out? However, these links are good to read, but there are too many of them e.g. before finding the IO-path stuff. > 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. Now you have done it again, calling me names. Grow up! I am a teacher and don't _ever_ call them stupid even if i think so in some cases. It's all about respect to other people. And I'm not lazy, forget that. > > > 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. Samuel answered that one already. > > > 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. Another good reference again, thank you. Now we are talking. > > > 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". So far I've mainly been porting packages, not doing any work related to gnumach/hurd, admitted, no inner working knowledge was needed. Now is the time to learn about glibc-gnumach-hurd, therefore the questions come now. > > > And you're blaming lack of documentation for that ?! Yes, if the rpc.mdwn was written and pointed early to the web page things would be much more understandable. And this: user_code <-> libc(client) <-> gnumach(mailman) <-> hurd(server) gives me _much_ more than lengthy descriptions on details on the gnumach/hurd functions. And there does not seem to exist any description of the gnumach/Hurd parts of eglibc, right? I haven't found any. > > 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. See above, and my replies to Samuel: Getting a top-down view of a system is almost always better for learning purposes, even if you only work with a subset of that system. At least this is my experience as a teacher, something I've been for many years now. And very much appreciated by the students. > > > 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. See above, unfortunately too boring as teaching material, but good as a look-up reference. Like a dictionary, do you read them from start to end, I doubt it! > > > 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/. See my reply to Samuel. I volunteer to write something down if there is interest. > 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. I'm rather fluent by now, most patches sent for review are granted by either Samuel or Guillem. You don't seem to be a very frequent reviewer, however. I know that you are one of the few people doing _real_ development on gnumach and Hurd, that is really appreciated. Please don't make this discussion into a pie-throwing war. There are too few Hurd users and developers for that.
