Tutorial, E-Book und andere Publikationsformen
-
Ok, aber dann möchte ich, dass du da noch etwas einfügst, alle anderen hast du auch drin (!!!):
http://henkessoft.de/OS_Dev/OS_Dev1.htm
Dann gibt es da noch viele andere, z.B. Christian F. Coors, der mich auf einen Fehler (RAM Disk Speicherbelegung) aufmerksam machte und mich auch sonst bei der Fehlersuche und umfangreichen Tests kräftig unterstützt.
(fehlt in http://rmweb.rm.funpic.de/PrettyOS_Dokumentation/einfuehrung.html)
-
Cuervo schrieb:
Ok, aber dann möchte ich, dass du da noch etwas einfügst, alle anderen hast du auch drin (!!!):
http://henkessoft.de/OS_Dev/OS_Dev1.htm
Dann gibt es da noch viele andere, z.B. Christian F. Coors, der mich auf einen Fehler (RAM Disk Speicherbelegung) aufmerksam machte und mich auch sonst bei der Fehlersuche und umfangreichen Tests kräftig unterstützt.
(fehlt in http://rmweb.rm.funpic.de/PrettyOS_Dokumentation/einfuehrung.html)
Da hätte ich von Dr. Henkes gerne mal eine Liste derjenigen, die mitgewírkt haben...
-
Inzwischen sind das einige mehr. Ich kuemmere mich naechste Woche um ein Update.
-
Erhard Henkes schrieb:
Inzwischen sind das einige mehr. Ich kuemmere mich naechste Woche um ein Update.
Wie ist der aktuelle Stand? Hast Du auch die Angabe der Dateien, in die der jeweilige Quelltext rein gehört, mit eingesetzt?
-
Die Datei findet man doch im Download. Ansonsten machen im Moment Badestrand, Cuervo und abc.w mit. _fricky hat uns einen USB-Treiber versprochen und bisher nichts gezeigt, ist seitdem verschwunden. Ansonsten gibt es einige wichtige Ratgeber, z.B. XanClic und Tobiking. That's it.
-
Erhard Henkes schrieb:
Die Datei findet man doch im Download.
Auf der ersten Seite Deines Tutorials sollte den Leser schon sagen, was wo hin gehört... Im 2. Abschnitt kann man ja auf die Beispieldateien verweisen... Und, was mir besonders auffiel: Die angehängten Beispiele unterschieden sich teilweise erheblich von dem, was man im Tutorial las... Wenn man Beispiele beilegt, sollten diese Deckungsgleich zum Tutorial sein und nicht schon teile des folgenden Abschnittes beinhalten...
Erhard Henkes schrieb:
Ansonsten machen im Moment Badestrand, Cuervo und abc.w mit. _fricky hat uns einen USB-Treiber versprochen und bisher nichts gezeigt, ist seitdem verschwunden. Ansonsten gibt es einige wichtige Ratgeber, z.B. XanClic und Tobiking. That's it.
Das setze ich dann mal ins E-Book ein.
-
Wenn man Beispiele beilegt, sollten diese Deckungsgleich zum Tutorial sein und nicht schon teile des folgenden Abschnittes beinhalten...
Ja, da gab es ab und zu kleine Feinheiten.
-
Aufgrund der letzten Ereignisse im Forum stelle ich hier mal folgende Frage:
Soll PrettyOS weiter Dokumentiert werden, oder soll man ein (neues) OS parallel zu PrettyOS erstellen und es Dokumentation
-
Ich denke, wir sollten PrettyOS bis zu einem gewissen Stand - nennen wir ihn mal 1.0 - stabilisieren. Folgende Möglichkeiten stelle ich mir dabei vor:
- Dokumentation nach innen in den Quellcode legen (evtl. automatisch extrahierbar)
- Ein Tutorial (z.B. Teil 4 im Internet) oder ein E-Book (von mehreren Autoren, kostenlos oder gegen paypal, je nach Aufwand) erstellen, das zu diesem Status 1.0 von Null an führt: was ist ein OS? warum OSDEV? welche Tools? PrettyOS erstellen. Mit PrettyOS experimentieren (mir als Chemiker sehr wichtig ).
- Eine Weiterentwicklung von PrettyOS, die zunächst wie unter 1 im Code dokumentiert wird.
Wir brauchen hier also eine funktionierende "Schleife".
Vielleicht hat jemand eine bessere Idee.
-
PrettyOS erstmal zu einem gewissen Stand bringen und dann das Tutorial dazu schreiben klingt auf jeden Fall besser als in dem Tutorial mehrmals an der gleichen Stelle herumzudoktern weil einem später etwas auffällt das geändert werden muss. Bevor man zu einem Teil ein Tutorial schreibt sollte man diesen auch verstanden haben.
Inwiefern die Dokumentation im Quellcode Sinn macht muss man gucken. Eine Beschreibung (im Doxygen Stil) darüber was eine Funktion macht und kleinere Kommentare an verzwickten Stellen passen sicherlich in den Quellcode. Die genaue Funktionsweise und eine Erklärung zu der Funktion sollte dann aber doch schon extern sein.
-
Hier kann ich Tobiking nur zustimmen.
-
Hallo,
Gamepower schrieb:
Soll PrettyOS weiter Dokumentiert werden, oder soll man ein (neues) OS parallel zu PrettyOS erstellen und es Dokumentation
Ich würde eher sagen das Ihr den Weg zu einem ordentlichen OS dokumentieren solltet. Das währe eine echte Bereicherung des deutschen Internets.
Tobiking2 schrieb:
PrettyOS erstmal zu einem gewissen Stand bringen und dann das Tutorial dazu schreiben
Dann fehlen aber wieder die ganzen Designentscheidungen (entschuldigt bitte das ich auf diesem Wort so rumreite aber einfach eine gewisse Menge an Problemlösungen hintereinander zu klatschen ohne die Problemursachen zu beschreiben find ich einfach doof, davon gibt es schon zu viel im Internet, http://www.brokenthorn.com/Resources/OSDevIndex.html scheint auch in diese Kategorie zu fallen). Gerade der Weg der zu einem bestimmten Ziel führt ist doch wichtig. Sonst ist der Leser nur in der Lage genau Euer OS ein weiteres mal zu schreiben (entwickeln währe schon das falsche Wort) und nicht was neues/eigenes zu erschaffen.
Tobiking2 schrieb:
Bevor man zu einem Teil ein Tutorial schreibt sollte man diesen auch verstanden haben.
Das ist wohl war, aber man kann/sollte während des Verstehens ein paar Notizen machen damit man dann auch wirklich beschreiben kann warum die Probleme so gelöst wurden wie sie gelöst wurden.
Tobiking2 schrieb:
Inwiefern die Dokumentation im Quellcode Sinn macht muss man gucken. Eine Beschreibung (im Doxygen Stil) darüber was eine Funktion macht und kleinere Kommentare an verzwickten Stellen passen sicherlich in den Quellcode. Die genaue Funktionsweise und eine Erklärung zu der Funktion sollte dann aber doch schon extern sein.
ACK. Das "Wie" gehört in den Quell-Code, das "Warum" in ein ordentliches Text-Dokument. Querverweise währen eine zusätzliche Bereicherung, wenn im Quell-Code an einer verzwickten Stelle steht "siehe Kapitel X" dann könnte der Leser dort in Langform nachlesen welche Designentscheidung eben zu genau dieser Lösung geführt hat und verstehen was dahinter steckt.
Grüße
Erik
-
"währe" ist falsch (Standardfehler bei Dir), kommt nicht von "wahr", sondern ist der Konjunktiv von "war".
-
Hallo,
Erhard Henkes schrieb:
"währe" ist falsch ...
Wenn das alles ist was Dir zu meinem Beitrag einfällt dann bin ich hier eindeutig fehl am Platz!
(Womit ich nicht sagen will das korrekte Orthographie ganz zu vernachlässigen ist.)Grüße
Erik
-
Du stellst das Thema Designentscheidungen in den Vordergrund, ist auch ok, wird zukünftig stärker berücksichtigt. Dein Impetus ist also akzeptiert.
-
Das mit den Designentscheidungen stimmt schon. Allerdings kann das je nach Thema recht umfassend werden oder einfach unpassend an der jeweiligen Stelle. Bei einem längeren Werk wie einem Buch könnte man das natürlich planen, gewisse Punkte dann erstmal zurückstellen und die Erklärung nachliefern wenn diese relevant wird.
Diese Schritt für Schritt Tutorials die man online findet sind da eher knapp gehalten. Das zieht wahrscheinlich mehr Leser an, die dann denken sie können das ganze in wenigen Stunden nachmachen, dürfte den Lesern, die an dem Thema wirklich interessiert sind, aber nicht ausreichen.
Erhard hatte als Zielgruppe damals vor allem an Jugendliche gedacht. Da ist diese Tutorial Form wahrscheinlich geeigneter. Ich weiß nicht wie er da zurzeit zu steht.
Vielleicht kann man das ganze auch etwas mischen. Die ersten Schritte (Bootvorgang, Kernel laden etc.) haben noch nicht so viele Designentscheidungen und sind eher von den Gegebenheiten geprägt. Der Einstieg könnte also durchaus in Schritt für Schritt Form ohne große Diskussionen über Sinn und Unsinn erfolgen. Sobald der Leser dann etwas im Thema drin ist können die großen Entscheidungen dargelegt und gerechtfertigt werden.
Ein wichtiger Punkt der mir gerade auch noch dazu einfällt ist das benötigte Vorwissen. Geht man davon das der Lesen ein gewissen Vorwissen zu Betriebssystemen hat? Sollte er z.B. das Buch von Tanenbaum gelesen haben? Dann könnte man gewissen Themen auch darauf verweisen. Das führt natürlich zu der Frage inwiefern man auf andere Quellen (ich denke da vor allem an das lowlevel Wiki das zu vielen Themen auch Artikel hat) verweist. Solange die Doku online erreichbar ist sollte das verlinken kein Problem sein. Als Buch geht das ganze dann natürlich nicht mehr.
-
Hallo,
Tobiking2 schrieb:
Das mit den Designentscheidungen stimmt schon. Allerdings kann das je nach Thema recht umfassend werden oder einfach unpassend an der jeweiligen Stelle.
Man muss das ja nicht immer ausarten lassen aber ich finde dem Leser sollte ganz klar sein das an einer bestimmten Stelle eine Designentscheidung getroffen wurde so das er sieht das dort eine mögliche Abzweigung ist die er selber anders gehen könnte und wenn er es tut dann sollte er wenigstens Stichpunkte für die Suchmaschine seiner Wahl haben.
Tobiking2 schrieb:
Diese Schritt für Schritt Tutorials die man online findet sind da eher knapp gehalten.
Für meinen persönlichen Geschmack etwas zu knapp, das liegt aber sicher daran das ich die meisten dieser Entscheidungen sehr gut kenne und auch zum Teil schon selber getroffen habe. Ob man z.B. das Thema "kooperatives Multitasking vs. preemptives Multitasking" angehen muss ist für ein heutiges OS sicher fraglich aber es gehört IMHO zum Themen-Komplex OS-Dev und sollte mit ein paar Sätzen (in nem kleinen Infokasten o.ä.) erwähnt werden. Aber das hängt davon ab wie viel bzw. welche Bedeutung der Autor seinem Tellerrand beimisst.
Tobiking2 schrieb:
Das zieht wahrscheinlich mehr Leser an, die dann denken sie können das ganze in wenigen Stunden nachmachen, dürfte den Lesern, die an dem Thema wirklich interessiert sind, aber nicht ausreichen.
So ist es. Welche Klientel möchte man mit einem aufwändigen Tutorial über OS-Dev erreichen? Mir persönlich wäre die zweite Gruppe lieber, sicher weil ich selber zu dieser Gruppe gehöre, ist aber letztendlich auch wieder Sache des Autors.
Tobiking2 schrieb:
Erhard hatte als Zielgruppe damals vor allem an Jugendliche gedacht. Da ist diese Tutorial Form wahrscheinlich geeigneter.
Dafür liefert er aber zu wenig Basics, so wie die meisten anderen OS-Dev-Tutorials auch die ich in den letzten 3 Jahren so gelesen hab.
Tobiking2 schrieb:
Ein wichtiger Punkt der mir gerade auch noch dazu einfällt ist das benötigte Vorwissen. Geht man davon das der Lesen ein gewissen Vorwissen zu Betriebssystemen hat?
Selbst wenn man davon aus geht das der Leser schon etwas Vorwissen mitbringt so sollte ein gutes Tutorial auch die Leser mit weniger Vorwissen auf das erforderliche Niveau anheben. Es sollte zumindest genug Wissen vermittelt werden das Anfängerfragen wie http://www.c-plusplus.net/forum/viewtopic-var-t-is-245602.html und http://www.c-plusplus.net/forum/viewtopic-var-t-is-259827.html nicht mehr aufkommen.
Tobiking2 schrieb:
Sollte er z.B. das Buch von Tanenbaum gelesen haben?
Von einem Anfänger kann man das sicher nicht erwarten. Ich würde dieses Buch sogar eher als "Weiterführende Lektüre" betrachten in der viele Aspekte eines OS noch mal genauer/detaillierter beleuchtet werden. Ist interessant wenn man sein OS qualitativ eine Ebene höher haben will.
Ich selber hab es übrigens nur Auszugsweise gelesen (man bekommt es als ganzes nur gegen Geld oder kennt jemand einen guten Download-Link zur englischen Original-Ausgabe) bin aber der Meinung das jemand mit meinen Zielen dieses Buch fast auswendig kennen sollte.Erhard Henkes schrieb:
Du stellst das Thema Designentscheidungen in den Vordergrund
Ich bin der Meinung das so ein Tutorial dem Leser nicht nur die Entstehung eines bestimmten OS näher bringen soll sondern es muss auch zeigen wie dieser Weg funktioniert. Ich finde aber zusätzlich auch das dem Leser das nötige Wissen vermittelt werden muss.
Erhard Henkes schrieb:
Dein Impetus ist also akzeptiert.
Es geht mir nicht darum das Du meine Meinung akzeptierst, es geht mir nur darum das Du über meine Argumente nachdenkst oder darüber diskutierst und dann möglicherweise Deine eigene Entscheidung triffst.
Grüße
Erik
-
Von einem Anfänger kann man das sicher nicht erwarten. Ich würde dieses Buch sogar eher als "Weiterführende Lektüre" betrachten ...
Da stimme ich Dir voll zu. Ich habe zu früheren Zeiten öfter solche Bücher in die Hand genommen, dort aber keinen Ansatz gefunden, um ein eigenes OS zum Laufen zu bekommen. Für einen kompletten Anfänger in diesem Gebiet ist der Start eine gewaltige Herausforderung, den nicht jeder steht mit dem Assembler/Kompiler/Linker auf Du und Du, sondern verwendet hübsche Oberflächen mit Buttons und Menüs, die ihn von z.B. einem makefile oder Linkerscript möglichst weit fern halten. Beim OSDEV ist einfach alles schwierig, weil low level. Nach Umschalten auf PM ist zusätzlich das BIOS weg.
Daher ist der praktische Einstieg das Wichtigste. Anschließend benötigt man Kompiler/Linker-Wissen und Nachschlagwerke/Spezifikationen.
Die Ebene des Buchs von Tanenbaum kommt da ganz zuletzt.
Mir hat z.B. ein dreiteiliger Artikel in der Linux-Gazette beim Ersteinstieg geholfen. Den Umstieg zu PM habe ich damals allerdings nicht wirklich verdaut (der dritte Teil dieser Serie war leider fehlerhaft und sehr schlecht aufgebaut), so dass ich aufhörte.
Erst einige Artikel von osdev.org und das Tutorial von James Molloy, das in den ersten Kapiteln auf einem älteren fußt und nicht wirklich gut ist (weiß er selbst, daher will er es überarbeiten), brachte mich wirklich in die Gänge. Mein Tutorial könnte man als eine gewisse Fortsetzung des JM Tuts ansehen.
Die aktuelle Phase hier im Subforum von cplusplus.de sehe ich als Experiment. Danach möchte ich entscheiden, ob gemeinsam mit einigen interessierten Entwicklern, Autoren und Designern ein neuer didaktischer Ansatz bezüglich einer Publikation möglich ist.
Es würde mich freuen, wenn Du dazu gehörst. Daher würde mich interessieren, ob Du mit deiner klaren Vorstellung zu dem Thema und deiner Erfahrung bereits eigene Publikationen zu diesem Thema geschaffen hast. Diese würde ich gerne lesen.
-
Bezüglich der Designentscheidungen fängt es schon ganz vorne beim x86 und beim Bootloader an. Das Hostsystem für die Entwicklung ist später sicher zweitrangig, am Anfang für den Einstieg aber sehr entscheidend. Heute geht vieles stark in Richtung Microkernel, vielleicht ein Grund mehr PrettyOS zum YottaKernel zu entwickeln (dies ist eher Instinkt als Determinismus, selbst bei Linux und Microsoft läuft das so).
-
Hallo,
Erhard Henkes schrieb:
Ich habe zu früheren Zeiten öfter solche Bücher in die Hand genommen, dort aber keinen Ansatz gefunden, um ein eigenes OS zum Laufen zu bekommen.
Das ist auch nicht das Ziel solcher Bücher, die dienen eher dem Profi sein bestehendes OS qualitativ zu verbessern oder es beim nächsten Versuch besser zu machen. Diese Bücher verfolgen einen eher akademischen Ansatz.
Erhard Henkes schrieb:
Für einen kompletten Anfänger in diesem Gebiet ist der Start eine gewaltige Herausforderung
Oh ja, das muss schön Schritt für Schritt gemacht werden.
Erhard Henkes schrieb:
den nicht jeder steht mit dem Assembler/Kompiler/Linker auf Du und Du
Das sollte aber schon sein wenn man sich an das Thema OS-Dev heranwagt. Das sollte IMHO eigentlich für alle Softwareentwicklungen so sein (außer vielleicht Assembler).
Erhard Henkes schrieb:
Beim OSDEV ist einfach alles schwierig, weil low level.
Gerade das ist für mich die Herausforderung.
Erhard Henkes schrieb:
Die Ebene des Buchs von Tanenbaum kommt da ganz zuletzt.
Naja, man sollte es spätestens lesen nachdem man auch mit seinem zweiten OS nicht wirklich zufrieden ist.
Erhard Henkes schrieb:
Die aktuelle Phase hier im Subforum von cplusplus.de sehe ich als Experiment. Danach möchte ich entscheiden, ob gemeinsam mit einigen interessierten Entwicklern, Autoren und Designern ein neuer didaktischer Ansatz bezüglich einer Publikation möglich ist.
Das müsstest Du mal bitte etwas genauer erläutern.
Erhard Henkes schrieb:
Es würde mich freuen, wenn Du dazu gehörst.
Da bist Du nicht der einzigste. Für mich steht aber erst mal mein eigenes Projekt an erster Stelle und davor kommt noch meine Familie. Es währe von Vorteil wenn sich mein Projekt und Dein Vorhaben nicht gegenseitig ausschließen würden aber ich kann da keine Gemeinsamkeiten erkennen.
Erhard Henkes schrieb:
Daher würde mich interessieren, ob Du mit deiner klaren Vorstellung zu dem Thema und deiner Erfahrung bereits eigene Publikationen zu diesem Thema geschaffen hast. Diese würde ich gerne lesen.
Außer Spezifikationen hab ich noch nichts geschrieben.
Erhard Henkes schrieb:
Bezüglich der Designentscheidungen fängt es schon ganz vorne beim x86 und beim Bootloader an.
Als Einstieg wäre IMHO ein hübsches ARM-Board die deutlich bessere Wahl, wenn es nicht extra Geld kosten würde. Auch wenn die ARM-Architektur fast so alt wie x86 ist so gibt es dort deutlich weniger Stolperfallen und Irrwege.
Erhard Henkes schrieb:
Heute geht vieles stark in Richtung Microkernel,
Hat ja auch ne Menge Vorteile, deshalb will auch ich in diese Richtung (Segmentierung kann da sogar einiges zusätzlich erleichtern).
Erhard Henkes schrieb:
vielleicht ein Grund mehr PrettyOS zum YottaKernel zu entwickeln
Was meinst Du mit "YottaKernel"?
Grüße
Erik