Hi:
Kevin wrote:
gravaera wrote:
It's an unnecessary hassle, and anyone who can't read English is already most likely not going to have an easy time. Most useful articles are written in English, with examples in C, a language which uses English keywords. All the more highly recommended tutorials which are making all of the newbies think inside of a small, illogical box and making them ask illogical questions are written in English, so for you to even begin to read them to get all the bad ideas in them, you have to know English.
I think you're completely missing the point. Most Germans do understand and speak English. Even though it may not be perfect, what I write can be recognized as English, right? I'm also capable of reading English specs. Still, it's not the language that I use for everyday purposes and
you're not going to change that. English is a language that I can and do use happily whereever it helps for communication, but it remains a foreign language. If there's some information in both German and English, I'll start with reading the German one and only quickly scan the English one for additional information.
It's not my intention to try to change what language you use everyday, and honestly, I'm not trying to change anything in fact. My previous post was just me expressing concern over something I think is a problem: take it at its face value.
Kevin wrote:
Quote:
it's based on a reluctance to make inaccurate, unofficial documentation more easily available, in possibly less precise forms. Google is more than good enough:
Well, in a lot of your reply you're arguing for shutting down the osdev.org wiki. That's really not related to interlanguage links or to the language the wiki articles are written in, but to your dislike of using anything other than official specs (and it's not as if specs were always clear: sometimes you'll find the correct interpretation of an ambiguous statement in the wiki).
The closest I came to suggesting closing the Wiki was when I said that "Wikis are already not a good thing": but given the overall idea behind my post, looking at this line, it should be interpreted not as gunning for a closing down of the Wiki, but simply a building statement to support my argument; I was trying to make it clear that Wikis are likely to contain possibly unreliable, second-hand interpretations of information, and are more likely to be less reliable than official documentation, and I used that statement to concrete it. It wasn't really a snipe at the OSDev.org wiki.
Kevin wrote:
Though there's one thing I'd like to know: When you started off with a Hello World kernel, did you read all related specs, or did you just take a tutorial? I find it hard to believe that you would actually have achieved your goal if you had started with the former.
I've never written a kernel which printed "Hello world" to my screen, or that did anything similar: it makes no sense to me. In my current kernel, I wrote a full PMM + VMM without having a "printf()" for debugging. You may want to know what's so great about that. My PMM layer is not "normal" so to speak. I have support for certain things that other people don't which would have made that a bit harder than "writing a bitmap allocator". I wrote in small increments and tested furiously, debugging several deadlocks and other problems using for (;;){} loops and bochs' single stepping, and nothing more.
You're pretty much asking, "how did
you begin, if not from tutorials?". That implied question is faulty at its base: you shouldn't be asking that, but "How did you begin, if not from a simple base?", and the answer would be: I did begin from a simple base: but that base was not tutorial-derived. It was more reading-oriented. I began overall, by looking at the "Bare Bones" article. On the first day, I realized that I only vaguely understood it. I took two weeks off from actually doing any further work, and read all kinds of articles, mostly using Wikipedia as a starting point, then spiraling outward to more documentation. After those two weeks, I moved on to attempt to implement a simple "skeleton" of what I thought I wanted my kernel to be. Within about two days it became obvious to me that my work was highly unportable, and very childish, and I didn't like the feel of it. I halted development, began reading again but this time, I kept a set of notebooks and used a push-point pencil and kept writing to myself in the first person, about designs that made sense to me, and kept reading without any implementation for about nine months. Along with this, I looked through LKML, and a clone of linux master and kept going until I understood my target topic, then moved on. an extremely important thing that newcomers are *not* getting is a set of comprehensive examples of "the common case", and then "the variations".
Portable, correct design is founded on knowing what is "platform dependent" and what is not. Most of these tutorials are steeped in the x86/IBM-PC-compatible platform, and even worse, too many of them don't state this, and even go so far as to imply that their concrete, PC-specific example code and the relevant explanation is actually cohesive, abstract theory. That is a fatal problem. So the newcomer gets flooded with a set of static ideas which are fixed to a highly ugly platform, and even thinks that these PC-specifics are all what the overall picture of kernel development looks like. In my opinion, it's a terrible trap.
I used this OSDev.org forum as a grounds for testing my learning: I tried answering other peoples' questions, both here and on #osdev even though I was not using the generally recommended learning base, and confirmed that I was learning well when I was becoming increasingly able to answer other peoples' questions, and shed light on issues that their tutorial bases could not. Anytime I encountered something that I didn't understand, I googled, and I read. What does this mean? It means that with hard work, and enough RTFM, you can do much better than if you were to follow tutorials. And the static, incorrect ideas that people who read tutorials get are less likely to come up when you prefer to read broadly. Am I saying that people should be able to get by without any starting point whatsoever, or trying to be elitist? No. Every complex system requires a simple base, and every long journey begins with one step.
On the contrary I'm saying that people should have a *better* starting base than the tutorials which are being promoted as good starting material currently. See, my beef is not with the idea of starting material, but with
which starting material is used, and the
way this starting material addresses the relevant points. Where can this "better" starting base be found? The answer is "no particular location". It's currently distributed across multiple locations, but if you look enough, you'll
always be able to find it. Whether you need to email people from mailing lists, or some other tedious activity, the correct material is there. You may ask, "so how can people get to it if it's that hard to find?": the best answer is: "If you, seeing that this information is too difficult to obtain, feel daunted by it, go ahead and write a series of articles which should provide a core for a newcomer, then provide those resources at a single location".
As a result, I am against the idea of providing *more* of this, IMHO faulty starting material, in more languages, and linking to it more furiously from places where newcomers are likely to frequently browse. It does no good IMHO, and is simply a recipe for more and more disaster.
Kevin wrote:
Quote:
you're more likely to come across official documentation from googling than to encounter it while lazily looking for "short", "easy to read" supplements on a wiki, and following cross-language links.
Actually, to be honest, I usually use the links at the end of a wiki article to find the specs. Googling them is often too hard and you'll find anything (including worse tutorials than on the wiki) but the official specs.
This was an "I do it, so it must be right" type of argument, and I don't fare well with those since they're hard to counter: the person has effectively presented a subjective experience as argumentative material. I believe in the validity of the personal experience, so I usually don't argue those. So I'll skip it
Kevin wrote:
Quote:
Even worse are Wikis which have information which has been interpreted, then translated from a subjective understanding into a condensed reference. I think anyone who has studied languages should understand that translations usually don't get mapped 1:1, or keep their original intent precisely as first encoded. Far less for a person who's paraphrasing and translating that paraphrasal.
Why do you presume that English articles are always based directly on the spec whereas non-English ones must be translations of the English articles? In my experience, both is wrong. In fact, I don't know of any Lowlevel article that was translated rather than written from scratch.
Notice my wording: "Even worse are Wikis which do X", and not "Even worse is that Wikis do X": the former implies the set of Wikis that do X, and the latter implies that all Wikis as a collective set do X.
Kevin wrote:
In other places you basically say that non-English articles have inherently lower quality than English ones. Do you have a really good justification for such bold claims?
I'm sorry, but I simple implied that translations of subjective understanding of a specification are likely to introduce inaccuracies. I'm not too sure, but I'm willing to stick my neck out to say that I don't think you can logically argue with that: it's a fact, or at least I believe so.
EDIT: Combuster posted while I was writing this up, so this is all written without having read his response.
--All the best
gravaera