@Freigeist
vor einiger Zeit hatten mich ähnliche Gedanken um getrieben und deshalb fragte ich danach, hier im Forum. Und zwar ging ich noch einen Schritt weiter und fragte auch, woran ch denn erkennen kann, dass ein Code etwas besonderes ist, beispielsweise besonders sicher oder gut. Was ich ich sehe ist doch nur die Auswirkung des Codes und da kann ch letztlich nur entscheiden, ob es geht und vielleicht auch noch, wie gut es geht. Ja, ich fragte sogar, ob ein für Menschen gut erscheinender Code denn tatsächlich die Grundlage für eine gute Binary sein muss. Der PC sieht die Qualität womöglich ja vollkommen anders,
Alle diese Fragen stellte ich auch als absoluter Laie.
Ich lernte dann aus den Antworten, dass SW nicht etwas ist, dass einzelne Genies in einer kleinen, dunklen und womöglich miefigen Art von Alchimistenküche produzieren und das dann nur zur einmaligen Anwendung gedacht ist. Vielmehr wird SW von vielen Leuten zusammen entwickelt und "schlimmer noch", womöglich über lange Zeiträume gepflegt. Das macht für mich absolut plausibel, dass die Auffassungsgabe von Menschen hierbei berücksichtigt werden muss und dass "ordentlicher" Code, einfacher Code und übersichtlicher Code natürlich deutliche Vorteile hat. Wirrer und verschachtelter Code, der auch noch unnötige Schleifen durchläuft, die niemand mehr kapieren kann und die nur eher zufällig noch zu einem gewünschten Ergebnis führen, ist nur sehr schwer von Fremden zu warten und zu pflegen oder auch weiter zu entwickeln.
Deshalb ist es mir auch verständlich, dass das bloße Aussehen eines Codes bereits etwas über die Qualität sagen kann. Die Form spielt eine große Rolle, das Einhalten von Standards und der Gebrauch festgelegter Routinen vereinfachen die Sache für alle beteiligten.
So, wie ich das verstanden habe, neigen nahezu alle Wissenden zu der Auffassung, dass dieser Part in OpenBSD vorbildlich gelöst ist.
Es gibt außerdem einige Features, die zusätzliche Sicherheit versprechen. Dazu zählt das Aufteilen des Speichers auf Prozesse und die Bildung von Zufallszahlen.
Was ich als Laie sehen konnte, macht mir keinen bedeutenden Unterschied zum FreeBSD Code. Also, als Unwissender von außen betrachtet ist FreeBSD durchaus häufiger ein klein wenig länger, aber dafür macht es auch mehr. (Also mehr Unterscheidungen im Code zB).
In OpenBSD hat man aber diese Design-Ziele festgeschrieben und verfolgt sie auch rigoros. Es hat sich seinen Ruf erarbeitet, das ist ihm nicht vor die Füße gefallen.
Mir persönlich hatten einige Dinge nicht so sehr behagt in OpenBSD. Rein von der praktischen Anwendung her, nicht so sehr vom Design, aber auch aus ideologischer Sicht. Dass es tatsächlich ein exotisches System ist, hatte dabei keine negative Rolle gespielt. Ich muss hier nun ausführen, dass es natürlich exotisch ist, weil es eine sehr kleine Entwicklertruppe hat die sehr wenige Anwender um sich scharen, dabei auch einen vollkommen eigenständigen Weg nicht scheuen und das trotz aller Probleme auch schon seit "Jahrzehnten" durchhalten. In meinen Augen haben alle BSDs den Namen exotisch verdient.
), aber deine Kapitelaufteilung gefällt mir schon ganz gut. Ein Vorschlag: OpenBSD hat außer dem vi (also nvi, das ist ja noch mal etwas andere Software) auch noch den mg, also quasi Emacs, im Kern. Für Neulinge ist der tatsächlich geringfügig einfacher zu bedienen als vi, unterstelle ich einfach mal, weil er keinen Einfügemodus braucht.
Das bedauer ich auch, aber wahrscheinlich war der Aufwand zu groß.
