OpenBSD - why and how?

[Rakor]

Die Diskussion ist doch nun wirklich unsinnig und bringt keinen weiter.

Je mehr Dienste laufen um so offener wird ne Kiste, das ist nun mal so. Ob man nun auf seine Kiste viele Sachen packt oder nicht liegt an den Anwendungsfällen und an Anwender.

 

[duda]

ja, was denn dann - interessiert mich auch brennend

 

[duda]

also ich schätze die Beiträge von CrimsonKing durchaus - herrgott, was wären die Abende sonst langweilig

 

[f41thr]

dass OpenBSD nicht nur als Geheimtipp für bärtige Admins mit Hosenträger gilt
.....
Michael

Dann kann ich Dich beruhigen. Es gibt sie die Anzugträger im IT Management mit Schlips und Kragen die OpenBSD verwenden und propagieren.
Womit ich wahrscheinlich zu einer ausserordentlich seltenen Spezies gehöre ;->
Und dann baue ich meine Releases auch noch selber.

 

[pit234a]

Rakor hat den einen Punkt, den ich in meinem Beitrag anführte, deutlich erklärt. Zusätzlich noch ein Beispiel: wenn LibreOffice einen Bug enthält oder eine Sicherheitslücke, dann findet sich die in einer bestimmten Version von LibreOffice und greift auf allen Systemen (mehr oder weniger), wo diese SW installiert und betrieben wird. OpenBSD ist da nicht sicherer, als ein GNU/Linux oder FreeBSD. Ein typischer Server hat wesentlich weniger SW installiert, kommt vielleicht sogar mit dem "reinen" Basissystem aus und bietet daher auch eine viel kleinere Angriffsfläche. Ähnlich läuft das Argument gegen alle laufenden und benutzten DIenste: desto weniger, desto geringer die Wahrscheinlichkeit für ein Loch.

Das war aber für mich nur ein Punkt, der zeigen sollte, dass die oft gehörte Werbung vom sicheren und sauberen OpenBSD für einen Desktop-Anwender leicht zu einer Floskel verkommen mag.
Der andere Punkt meiner Überlegung richtet sich aber direkt auf die Behauptung, dass der Code von OpenBSD überlegen sei. Oft wird behauptet, dass hier wirklich "sauber" programmiert wird und dass kein unsinniger Ballast im System verbleibt und ähnliche Begriffe mehr. Einst kritisierte Theo de Raadt den Code von Linux wegen zahlreicher vorhandener Kommentare, die eine gewisse Naivität oder mangelnde Seriosität der Programmierer suggerieren sollte.
Da frage ich mich eben insgesamt, ob das nicht unsinniges Gespräch ist. Und ich frage mich das tatsächlich un will damit nicht provozieren, ich kenne mich damit nicht aus.
Der Code ist ja der von Menschen lesbare Teil eines Programms.
Inwieweit wirken sich da nun ästhetische Empfindungen tatsächlich aus?
Ist es ein Zeichen für eine gut laufende Binary, dass ihr Quellcode in irgendeiner Form uns Menschen oder bestimmten Menschen gefällt?
Gibt es tatsächlich besseren Code, der auch erkennbar ist?
Oder lassen wir uns da nicht durch Konventionen aus anderen Bereichen täuschen?
Ist es für ein Desktop-System "besser", wenn es aufgeräumt ist? Und woran merke ich das als Endanwender?

Mir ist die Benutzung von Begriffen aus anderen Gebieten verdächtig. Eine "runde Sache", ein "kompaktes Programm", ein "aufgeräumter Code" und so weiter, das sind doch eher Marketing-Begriffe, als dass tatsächlich etwas daraus abgelesen oder abgeleitet werden kann. Selbst, wenn die benutzten Attribute in irgendeiner Form tatsächlich zutreffen, also in den Augen dessen, der diese setzt vollkommen gerechtfertigt sind, bedeutet das ja noch lange nicht, dass in der Praxis irgendeine Bewandtnis daraus hergeleitet werden kann.
Die teilweise lustigen und unseriös wirkenden Kommentare in Linux hatten sicher keine negative Wirkung auf das fertig kompilierte Ergebnis.
Wenn ich ein GNU/Linux benutze und darauf "meine" Arbeitsumgebung setze und die üblichen Programme benutze, dann merke ich kaum einen Unterschied zu FreeBSD. Im Grunde bemerke ich sogar gar keinen Unterschied, nur, dass meine wenigen Installationen mit GNU/Linux schneller laufen, als meine FreeBSD Installation und diese wiederum konnte gegenüber OpenBSD bei mir punkten. Dabei ist die HW aber auch unterschiedlich und nicht wirklich identisch, ich will hier kein Ranking liefern, nur darauf hinweisen, was ich überhaupt als Endanwender merken kann.
Der angeblich "saubere Code" gehört jedenfalls nicht dazu (mal davon abgesehen, dass wir mit BASH-Fehler angefangen auch in manchen Open* -Tools von Fehlern überrascht wurden, die auch in OpenBSD benutzt worden waren).

 

[Kamikaze]

Rakor hat den einen Punkt, den ich in meinem Beitrag anführte, deutlich erklärt. Zusätzlich noch ein Beispiel: wenn LibreOffice einen Bug enthält oder eine Sicherheitslücke, dann findet sich die in einer bestimmten Version von LibreOffice und greift auf allen Systemen (mehr oder weniger), wo diese SW installiert und betrieben wird. OpenBSD ist da nicht sicherer, als ein GNU/Linux oder FreeBSD.

Das ist so nicht korrekt.

OpenBSD hat viele Features die, zumindest bei einigen Klassen von Bugs, einen Exploit verhindern. Zum Beispiel toleriert ein aktuelles OpenBSD kein Use-after-free. Das ist ein sehr nützliches Feature für das ich auf einem Server auch gerne 25% Durchsatz opfern würde.

 

[mipl]

Gibt es tatsächlich besseren Code, der auch erkennbar ist?

Ja, weil ein gut lesbarer und den Regeln entsprechender Code, der sauber dokumentiert ist, auch von anderen Leuten gelesen und ggf. verbessert werden kann, während das bei Spaghetticode nicht der Fall ist. Und da Sourcecode so etwa 2-20 Fehler pro 1k Zeilen enthält, hat wenig Code statistisch gesehen weniger Fehler als viel Code. Und weniger Fehler bedeuten weniger Angriffspunkte. Und dann sind wir da, wo ich sein will: Ein kleines OpenBSD-Basissystem (könnte man Server nennen), zu dem ich ein paar notwendige Tools und Fluxbox installiere (das könnte man Desktop nennen), und auf das kein LibreOffcie/Firefox/Thunderbird kommt, weil ich davon 131% der Funktionen nicht brauche, aber mein System lahm und löchrig machen würde. Win-Win.
Muss aber jeder nach seinem eigenen Geschmack entscheiden, wer Whatsapp braucht, bekommt das eben mit OpenBSD nicht unter einen Hut. Und wer Bio-Gemüse will, sollte sich nicht beim Bio-Bauern beschweren, dass der keine Apfelingelinge anpflanzt... :P

 

[pit234a]

Ja, weil ein gut lesbarer und den Regeln entsprechender Code, der sauber dokumentiert ist, auch von anderen Leuten gelesen und ggf. verbessert werden kann, während das bei Spaghetticode nicht der Fall ist.

Das bezieht sich aber auf den Code, den Menschen lesen können. Das macht Menschen die Arbeit leichter. Macht ein derart sauberer Code auch automatisch das kompilierte Programm besser, stabiler, performanter, sicherer?
Den Spruch vom "Spaghetticode" höre ich auch schon seit über 20 Jahren und ich habe schon oft erlebt, dass dieses Wort dazu benutzt wurde, Code schlecht darzustellen. Dabei ist an Spaghettis nichts verkehrt.
Lass mich ein Beispiel aus meinem Lernberuf bringen: wir bastelten einen Computer in der Ausbildung. Dazu benutzten wir verschiedene Techniken und eine war die "Fädel-Technik". Dabei wird nicht erst ein Platinen-Layout erstellt und Leiterbahnen geplant und dann ausgeführt, sondern es wird ein dünner, isolierter Draht benutzt, der von einer kleinen Rolle ab-gespult und direkt an den Lötpunkten angelötet werden kann. Es zeigte sich, dass die sehr ordentlichen "Layouts" mit paralleler Drahtführung nicht oder nur schlecht funktionierten, während die wüsten und unordentlichen Ausführungen durchwegs besser abschnitten. Vom Ansehen hätten die ordentlichen Platinen immer besser gepunktet (und haben auch bessere Noten bekommen), aber in der Praxis brachten sie es nicht. Die Kapazitäten der parallelen Drähte sorgten für zu großes Übersprechen. Außerdem waren Fehler schlechter zu finden. Also, aus unserem gewachsenen Sinn für Ästhetik schnitten die ordentlichen Platinen besser ab, aber daraus ließ sich keine bessere Funktion ableiten.
Und das ging soweit, dass wir alle Bauteile ordnen sollten. Also alle Widerstände beisammen und in einer Reihe, alle Kondensatoren beisammen, alle ICs in einer Reihe und gleichmäßig verteilt. Das bedeutet, der Sinn für diese Ästhetik wurde schließlich über funktionale Zusammenhänge erhoben und sogar über sparsamen und sinnvollen Umgang mit Ressourcen gestellt. Ein "ordentliches Layout" genügte also solchen Anforderungen, die in keinem Zusammenhang zur Funktionalität standen.

Viele Begriffe bei der Bewertung von Code im Allgemeinen und von OpenBSD im Speziellen scheinen mir nun unserer Alltagssprache entnommen zu sein, wo bestimmte Zustände als positiv bewertet werden, ohne dass ich erkennen kann, wo dies bei einem Betriebssystem tatsächlich zu einer besseren Funktion führen würde. "Aufgeräumt", "ordentlich", "sauber" zum Beispiel, das bekommen wir doch schon als Kinder eingetrichtert und lernen diese Begriffe als positiv besetzt zu begreifen.

Und ich sehe da im Übrigen auch einen schönen Kontrast zu den kulthaft verehrten Hackern früherer Zeiten und ihren gar nicht zu diesen Begriffen passenden Erscheinungsbildern.

Das ist so nicht korrekt.

stimmt. Davon hatte ich auch gelesen, ohne es wirklich zu verstehen und zu verinnerlichen.
Die von mir benutzte Version hatte diese Neuerungen damals noch nicht (soweit ich mich erinnere).

weil ich davon 131% der Funktionen nicht brauche

Da bin ich voll bei dir und aus ähnlichen Gründen wähle ich mir deshalb gerne die Komponenten für mein System aus dem FreeBSD Angebot und nehme keine vorgefertigte Lösung, die mich nur mit vielen Dingen belästigt, die ich nicht wünsche.

 

[CrimsonKing]

Den Spruch vom "Spaghetticode" höre ich auch schon seit über 20 Jahren und ich habe schon oft erlebt, dass dieses Wort dazu benutzt wurde, Code schlecht darzustellen. Dabei ist an Spaghettis nichts verkehrt.

Assembler ist auch meist Spaghetticode. Ja, wir haben's kapiert, "Goto" ist in "modernen Sprachen" schlechter Stil. Funktioniert aber in reifen Sprachen erste Sahne.

 

[Athaba]

Was viele Leute nicht realisieren: wie gut OpenBSD inzwischen auch als Desktop taugt.

Das ist generell was was mich etwas nervt. Meine Einschätzung dazu ist, dass Leute aus irgendeinem Grund glauben, dass ein graphischer Installer ein einfaches System verspricht. Kurzum also, dass wenn man genau die selben Fragen beantwortet, aber statt einfach immer Enter zu drücken einen Mausklick zu machen das viel benutzerfreundlicher ist. Ich glaube weiters, dass das deshalb so ist, weil es sich vor Ewigkeiten mal eingebürgert hat diese "Reviews" von Linuxdistributionen (oder vielleicht kommt das ja anders wo her) zu machen und dann *NUR* den Installer zu besprechen.

Das ist so ähnlich, wie Boot-Splash-Screen. Das ist genau sowas. Ja, das ist was für Leute, die Apple-Fanboys sind (nix gegen Apple, ich rede hier mal über dieses Fanboyhafte und die eignen sich dafür). Da muss alles in weiß und mit einem Apfel sein, sonst ist es nicht gut und mühsam zu bedienen.

Und ein wichtiger Punkt: Es muss magisch wirken. Das wiederum bedeutet, dass man nicht wissen darf, was hinter den Kulissen passiert, sonst wirkt es nicht magisch. Oder es muss zumindest schön umschrieben werden. Das ist dann so wie bei der Zahnpaste-Werbung.

Und jetzt der Vergleich mit dem Desktop. Schaut euch mal an, wie kostenpflichtige(!) Virenscanner aussehen. Genau das wird von Desktopsystemen erwartet. Man sieht nicht was passiert und es gab ja sogar mal eine Virenscanner-App, die sich mal jemand angeschaut hat, die nachweislich nur eine zeitgesteuerte Progress-Bar hatte. Alles dahinter war Magie.

Darunter leidet unsere Industrie. Das ist auch der Grund warum Buzzwords so gut kommen. Die beschreiben Dinge extrem wage und nicht-technisch. Das zu tun kommt wiederum aus dem Marketing. Ein Beispiel dafür ist, dass Unternehmen wie Skype von Anfang an eine Liste von Worten und Phrasen hatte, die nicht verwendet werden dürfen (auch nicht im Vergleich mit anderen Produkten). Da fielen so Sachen, wie VoIP, Peer-To-Peer, Telephony, etc. rein[1]. Das ist auch eine Art Dinge "magisch" wirken zu lassen.

Das alles ist der Gegenpol zu dem was mit in den BSDs schätzt und generell in der IT-Welt (abseits von Web-Development - und Spielen, weil man da ja häufig als Ziel hat Probleme zu kreieren, nicht diese zu lösen - das bleibt da dem "User" überlassen).

Noch kurz was zur Bequemlichkeit vs. Sicherheit: Das Gute und das wo ich große Hoffnung habe ist, dass die Fundamente per-default sicher werden. Compileroptionen, OpenBSD's pledge/tame, TLS, public keys per default, Multifactor-Authentication, interessante Experimente, wie Rust, Nacl/Sodium, etc. schaffen gemeinsam ein generelles Bewusstsein und vor allem auch eine gewisse Infrastruktur, die es gerade neuen Projekten ermöglicht von Anfang an sicher zu sein. Vieles was nicht sicher ist (damit mein ich "bekanntermaßen und automatisiert" angreifbar) ist entweder aus einer Zeit, wo Security quasi nicht existierte oder wurde nur mal zum Testen ohne jegliche Sicherheit implementiert/konfiguriert und hat es in die Produktion geschafft. Kurzum: Es war keine Zeit dafür.

Dadurch, dass man heutzutage komplett automatisiert extrem schnell das ganze(!) Internet nach Lücken durchforsten kann gibt es neuerdings ein gewisses Bewusstsein. Niemand meint mehr "Ah, ich habe da eh keinen schönen A-Record. Damit ist das System sicher". Ja, sowas gibt's auch heute noch, aber die fangen sich mit der Haltung relativ schnell was ein. Ist zwar traurig, dass es das braucht, aber damit bekommt Security einfach einen deutlich höheren Stellenwert und in weiterer Folge hoffentlich auch simple Systeme.

Aber alles nur Theorie und Wunschdenken.

[1] http://download.skype.com/share/blogskin/press/skype_brandbook.pdf

 

[pit234a]

Assembler ist auch meist Spaghetticode. Ja, wir haben's kapiert, "Goto" ist in "modernen Sprachen" schlechter Stil. Funktioniert aber in reifen Sprachen erste Sahne.

Den Beitrag habe ich gestern schon gelesen und nicht verstanden. Bezieht sich das irgendwie auf das, was ich zuvor gesagt hatte und wovon du einen Auszug zitierst oder sollte ich das einfach ignorieren?

 

[CrimsonKing]

Ich hab' dir zugestimmt.

 

[holgerw]

Das ist generell was was mich etwas nervt. Meine Einschätzung dazu ist, dass Leute aus irgendeinem Grund glauben, dass ein graphischer Installer ein einfaches System verspricht. Kurzum also, dass wenn man genau die selben Fragen beantwortet, aber statt einfach immer Enter zu drücken einen Mausklick zu machen das viel benutzerfreundlicher ist. Ich glaube weiters, dass das deshalb so ist, weil es sich vor Ewigkeiten mal eingebürgert hat diese "Reviews" von Linuxdistributionen (oder vielleicht kommt das ja anders wo her) zu machen und dann *NUR* den Installer zu besprechen.

Hallo,

das kenne ich noch zu Zeiten meiner Nutzung von Debian GNU/Linux. Da wurde oft von Nutzern openSUSES über den hausbackenen unmodernen Installer von Debian abgelästert (wobei ich das Paketmanagement über YaST2 seit der Verwendung von libzypp eigentlich sehr ordentlich finde).

Dabei musste man auch bei YaST wissen, welche Werte man einträgt, wie man bei Sonderwünschen manuell partitioniert u.s.w. Mich stört generell die Häme aus unterschiedlichen Lagern gegenüber der sogenannten jeweiligen Konkurrenz. Da geben sich Leute Mühe, freie Software zur Verfügung zu stellen, verfolgen dabei natürlich unterschiedliche Ansätze der Distributierung u.s.f. und anstatt diese verschiedenen Ansätze zu tolerieren - was ja nicht heißt, dass man sachliche Kritik nicht üben darf - finden verbale Schlammschlachten statt.

Viele Grüße,
Holger

 

[SierraX]

Ist jetzt sehr subjektiv. Ich fand und finde die meisten graphischen Installer und Paket Manager einfach nur übel... SuSE hatte ich damals verlassen als YaST2 ... YaST(1) vollständig ersetzen sollte. Centos 7 hat mit ihrem Installer das einrichten von LVM2 in meinen Augen zur wahren Tortur gemacht... davon abgesehen das manchmal das (ich glaub) overscan nicht anständig funktioniert und man diverse Buttons nicht erreichen kann, ist es ein ständiges vor und zurück bis die config endlich ausschaut wie man sich das vorstellt.
Und ich glaube meine Versuche mit FreeBSD auf einer SunUltra hab ich damals (muss so 10 Jahre her sein) ebenfalls wegen dem für mich unverständlichen Installer zu Gunsten Net- und OpenBSD abgebrochen

 

[TCM]

Das bezieht sich aber auf den Code, den Menschen lesen können. Das macht Menschen die Arbeit leichter. Macht ein derart sauberer Code auch automatisch das kompilierte Programm besser, stabiler, performanter, sicherer?

Da sich Programme nicht selbst schreiben, erscheint das doch zwingend, oder nicht?

 

[pit234a]

Da sich Programme nicht selbst schreiben, erscheint das doch zwingend, oder nicht?

Es erscheint mir eben nicht zwingend, deshalb frage ich danach.
Ist das wirklich so, dass die äußere Form eines Codes, seine gute Lesbarkeit und Struktur, etwa eines Programms in C, tatsächlich auch eine bessere Qualität, wie Stabillität und Performance bedeutet?
Oder sind das einfach Ansprüche, die wir aus Erziehung und anderen Einflüssen her ableiten und sehen wollen, ohne dass es einen Beleg dafür gibt, dass unsere Forderungen auch technisch sinnvoll sind.

 

[mipl]

Ist das wirklich so, dass die äußere Form eines Codes, seine gute Lesbarkeit und Struktur, etwa eines Programms in C, tatsächlich auch eine bessere Qualität, wie Stabillität und Performance bedeutet?

Mit anderen Worten: Du traust wirrem, unleserlichem und schwer nachvollziehbarem Code grundsätzlich zu, ein gutes Binary zu werden?

 

[double-p]

"Sauber" hat hier nicht nur was mit Formatierung zu tun.

 

[rubricanis]

Oder sind das einfach Ansprüche, die wir aus Erziehung und anderen Einflüssen her ableiten und sehen wollen, ohne dass es einen Beleg dafür gibt, dass unsere Forderungen auch technisch sinnvoll sind.

Die Punkte sind hier 'maintanance' (sprich bugs entfernen) und 'change'. Heute wird die software meist in Teams entwickelt und gewartet oder auch von dritten gewartet und weiterentwickelt. Das alles ist bei unleserlichem Code schwerlich möglich. Da steckt viel Erfahrung dahinter....

 

[peterle]

"Sauber" hat hier nicht nur was mit Formatierung zu tun.

Ich glaube "Lesbarkeit" hat hier nicht nur was mit Formatierung zu tun, trifft es vielleicht besser.

 

[pit234a]

OK.

Mal anders, um nicht zu weit in Grundsatzdiskussionen zu kommen, wo ich einfach gar nicht mehr mithalten kann:
Könnt ihr mir ein Beispiel zeigen, hier reinkopieren oder verlinken, wo ich "guten" OpenBSD Code sehe und dagegen dann ein Beispiel mit "schlechtem" Linux oder FreeBSD oder sonstwas Code, wobei das "gut" oder "schlecht" sich im Ergebnis zeigt, also dem fertig kompilierten Paket?

 

[SolarCatcher]

Gut strukturierter und formatierter Code kann immer noch Mist und buggy sein, keine Frage. Aber es ist für den geübten Leser leichter, Fehler zu sehen und diese zu beseitigen. Allein schon die korrekte Einrückungen von Code-Segmenten hilft zu erkennen, was zusammen gehört. Deshalb geben immer mehr Opensource Projekte heute vor, welche Formalien beim Coden eingehalten werden sollen.

 

[Rakor]

Stell dir eine komplizierte Verkabelung vor. Da hat einer 200 Drähte verkabelt. Alle haben die selbe Farbe und alle sind in einem großen Knäuel verheddert...

Die Verkabelung kann vollkommen korrekt sein.... Oder auch nicht.

1. Keiner kann einfach sehen ob die Verkabelung korrekt ist. Man kann stellenweise testen, aber umfänglich ist es schwer zu bewerten.
2. Wenn ein Fehler in der Verkabelung ist.... Viel Spass... Dadurch, dass du die genaue Verkabelung nur schwer verstehen kannst weißt du gar nicht welche Seiteneffekte auftreten können wenn du hier ne Kleinigkeit änderst um den Fehler beheben zu wollen.
3. Nachträgliche Änderungen machen keinen Spaß, denn hier zieht Punkt 2.

Stelle dir nun daneben eine saubere Verkabelung vor. Unterschiedliche Farben die sinnvoll gewählt sind. Saubere und nachvollziehbare Kabelführung, dazu ne umfangreiche Dokumentation dazu.... Wem würdest du mehr vertrauen.....?

Wie gesagt, auch das chaotische kann vollkommen korrekt sein... Nur ist Software komplex, entwickelt sich weiter und wird von Menschen geschaffen.

 

[mipl]

Könnt ihr mir ein Beispiel zeigen, hier reinkopieren oder verlinken, wo ich "guten" OpenBSD Code sehe und dagegen dann ein Beispiel mit "schlechtem" Linux oder FreeBSD oder sonstwas Code, wobei das "gut" oder "schlecht" sich im Ergebnis zeigt, also dem fertig kompilierten Paket?

Klar!
Guter Code: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/
Schlechter Code: https://bugzilla.kernel.org/buglist.cgi?bug_status=__open__&content=code&no_redirect=0&product=&query_format=specific&order=priority%2Cbug_severity&limit=0
Schlechte Binaries: https://www.microsoft.com/de-de/download/windows.aspx

SCNR

 

[CrimsonKing]

Microsoft hat wenigstens keinen Poettering.