Autor Thema: Reihenfolge  (Gelesen 2675 mal)

pgahlen

  • Gast
Gespeichert
« am: 22. June 2010, 16:58 »
Hallo,
Vielleicht könnte man hier mal eine strukturierte Vorgehensweise schreiben, z.B. welche Artikel man zu erst durchlesen sollte, und was man dazu proggen sollte.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 22. June 2010, 17:30 »
Mit dem Übersichtsartikel von OS-Dev für Einsteiger anfangen und am Ende des Artikels zum jeweils nächsten Teil weiterspringen. ;)

Und unterwegs natürlich je nach Bedarf die verlinkten Artikel lesen. (Die wirst du auch brauchen, um das Tutorial richtig nachvollziehen zu können)
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

pgahlen

  • Gast
Gespeichert
« Antwort #2 am: 22. June 2010, 18:01 »
ok vielleicht habe ich es falsch formuliert die Frage könnte eher lauten:
Was soll ich nach dem Tutorial als nächstes machen?

aber danke schon mal an die Antwort

Cjreek

  • Beiträge: 104
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 22. June 2010, 19:08 »
Du musst gar nichts.

Such dir einfach was aus  :wink:
"Programmers talk about software development on weekends, vacations, and over meals not because they lack imagination,
but because their imagination reveals worlds that others cannot see."

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #4 am: 22. June 2010, 19:40 »
Paging bzw. virtuelle Speicherverwaltung wäre wohl der nächste sinnvolle Schritt.
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 22. June 2010, 21:47 »
Sinnvoll wäre auch eine Überlegung mit Milestones, also was wie in welcher Reihenfolge fertiggestellt werden soll. Dazu gehören Speicherverwaltung, Taskverwaltung, diverse Treiber mit den entsprechenden Designentscheidungen. Diese später zu ändern ist meist umständlich.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #6 am: 22. June 2010, 22:09 »
Aber in der Regel kann man ohne Erfahrung auch nicht sagen, was ein gutes Design ist.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #7 am: 22. June 2010, 22:40 »
Aber in der Regel kann man ohne Erfahrung auch nicht sagen, was ein gutes Design ist.
Ich könnte ne Menge Leute beim Namen nennen die das auch mit jahrelanger Erfahrung nicht können. ;)

Aber ansonsten hast Du natürlich recht.
Bleibt also nur so lange zu probieren bis man mit dem Ergebnis zufrieden ist oder man ließt sich vorher jahrelang in die Thematik ein bis man sich für einen (Pseudo-)Experten hält. Beides dauert ziemlich lange, aber wenn man nicht einfach mal anfängt wird man erst recht zu nichts kommen.


Grüße
Erik
Reality is that which, when you stop believing in it, doesn't go away.

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #8 am: 23. June 2010, 00:35 »
Auch ein schlechtes Design muss erstmal erdacht werden. Man sollte wenigstens grob wissen, was man gerade implementiert und wie man es einigermaßen testen kann. Dazu braucht man eine Vorstellung, was man gerade tut.

Und alles runterimplementieren und erst testen, wenn es komplett fertig ist, können die wenigsten. Fehlerfrei, so behaupte ich, kann es keiner. Erst recht keinen Kernel.

Ich meinte damit kein geschriebenes Pflichtenheft; ein paar Notizen oder bisschen nachdenken reicht gelegentlich auch.

 

Einloggen