OpenBSD Philosophie (binarys vs. Sourcecode)

xenobyte

root
Eins vorweg:

Ich moechte hier keinen Flamewar oder Vergleich wie "FreeBSD und OpenBSD" festlegen, ich wuerde nur gern Aussagen von einigen anderen OpenBSD-Usern hoeren zum Thema Source-Code vs. Binary.

In http://www.openbsd.org/faq/de/faq5.html steht:

* Du wirst KEINE bessere Systemleistung durch das Compilieren deines eigenen Systems erhalten.

* Compiler-Optionen verändern führt eher dazu, dass du dein System zerschießst, statt es zu verbessern.

Zum Thema Ports vs. Packages steht in http://www.openbsd.org/faq/faq8.html#PortsvsPkgs:

In general, you are HIGHLY advised to use packages over building an application from ports

Daraus wird ersichtlich, dass das OpenBSD-Team dazu raet, ihre Binarys zu verwenden. Allerdings verwirrt es mich, dass *alle* OpenBSD-User, die ich kenne ihre Anwendungen aus den Ports bauen, und einige sogar das komplette System "from scratch" bauen. Durch meine Erfahrungen mit Linux kann ich sagen, dass man sehr wohl viel optimieren kann, wenn man aus dem Sourcecode kompiliert.
Warum wird also vom 'do it yourself'-Prinzip abgeraten?
 
Ich nehme an, das hat mit folgendem Problem zu tun:
Wenn du ein OS nimmst und dann Zusatz-Software installierst, die sich
konstant ändert (Ports), kannst du mit deinem System nie einen definierten wiederholbaren
Zustand erreichen.

Dies erschwert die Fehlersuche natürlich.

Darum raten sie ja auch dazu nur den Generic-Kernel zu benutzen und ihn nicht zu
modifizieren, weil dann die Fehlersuche einfacher wird (weniger Fehlermöglichkeiten).
 
Zum Thema System aus den Sourcen bauen. Ja, ist klar, schneller wird es dadurch nicht. Aber es gibt Gründe das trotzdem zu tun. Zum Beispiel wenn man an der aktuellen Entwicklung teilhaben will.

Bei 3rd Party Programmen, sprich Ports sieht das anders aus. Da kann man das entsprechende Programm durchaus optimieren. Ein schönes Beispiel ist der mplayer. Ausserdem kann man dadurch wesentlich aktuellere Software benutzen. Aber das spielt ja bei OpenBSD eh nicht die Rolle.

Ich denke mal diese Tips hängen auch ein wenig mit der OpenBSD-Philosophie zusammen. Ein Compiler an sich hat ja auf einem High-Secure-System schon mal nichts verlohren. ;)

r0b0
 
xenobyte schrieb:
Durch meine Erfahrungen mit Linux kann ich sagen, dass man sehr wohl viel optimieren kann, wenn man aus dem Sourcecode kompiliert.
Aha, dann kannst du uns ja mal die fundierten Benchmarkergebnisse praesentieren, die du unter Linux durchgefuehrt hast.

Wie? Du hast keine Benchmarks durchgefuehrt? Es hat sich einfach nur schneller "angefuehlt"? Alles klar :D
 
Nein, Benchmarks hab ich in der Tat nicht durchgefuehrt, aber zweimal ein LFS auf der selben Hardware aufgesetzt.

Ich versteh allerdings nicht, was du von mir willst, wenn ich aus Software Support fuer Features rausnehme, die ich nicht benoetige, ist wohl jedem klar, dass das ganze ein bisschen mehr 'lightweight' wird. Oder brauchst du QT- und KDE-Support in Anwendungen, wenn du mit GTK+arbeitest und mit der glib entwickelst? Brauchst du Sound-, WLAN-, Bluetooth-, Crypto- USB-Support, wenn deine Hardware dieses nicht unterstuetzt ?

Eben...
 
Zuletzt bearbeitet:
MrFixit schrieb:
Wie? Du hast keine Benchmarks durchgefuehrt? Es hat sich einfach nur schneller "angefuehlt"? Alles klar :D
Benchmarks sind laut einem der BSDForen.de-Mods ohne jede Aussagekraft.
 
xenobyte schrieb:
Ich versteh allerdings nicht, was du von mir willst, wenn ich aus Software Support fuer Features rausnehme, die ich nicht benoetige, ist wohl jedem klar, dass das ganze ein bisschen mehr 'lightweight' wird.

Zwischen "Software support" rausnehmen und "ich kompilier alles mit -funroll-loops" liegen aber Welten. Mag ja sein, dass die Anwendung 0.5s schneller laedt, wenn der rtld nicht auch noch libqt.so in den Adressraum packen muss, aber diese "Optimierung" beisst einen spaetestens dann, wenn einem auffaellt, man haette doch QT support gebraucht.

Zumal es eben die Aufgabe des Maintainers ist, sinnvolle Standardpakete zu schnueren. Dass man nie alle zufriedenstellen kann ist klar. Ich jedenfalls will meinen mplayer so fett wie nur moeglich, schliesslich habe ich keine Lust ihn erstmal neu zu uebersetzen, nur weil er per default keine Unterstuetzung fuer das Format XYZ hat.

Aber selbst dann wirken sich die ganzen --with-foo=yes und --without-bar=yes nur marginal auf die Performanz, aber signifikant auf die Features aus.
 
was lars sagt.

@xenobyte
dann bin ich der erste openbsd user den du kennenlernst, der nichts aus dem quellcode uebersetzt :).
dieses millisekundengeoptimiere steht fuer mich einfach nicht im richtigen kosten-nutzen verhaeltnis. ob dein officeprogramm jetzt 150mb "gross ist" oder nur 15, duerfte deinem ultra-hyper-mega-krass-hardcore-kill_em_all-fett-super-dingle-dongle-schnick-schnack rechner ziemlich egal sein... (der spuerbare unterschied ist nach meiner erfahrung marginal).
 
kith:

Genau darum geht es ja, ich habe keinen "ultra-hyper-mega-krass-hardcore-kill_em_all-fett-super-dingle-dongle-schnick-schnack rechner" und da ist es mir schon wichtig, zu haben was ich will/brauch.

Geschwindigkeit ist ja nicht das einzige, weswegen man aus den Ports kompiliert, sondern Sachen wie:

- Securitypatches _sofort_ einspielen.
- lokale Patches einbauen um ein abstruses Feature hinzuzufuegen.
- Wenn ich Software mit einem anderen Compiler uebersetzt haben will/muss.

... gehen mit Packages eben nicht.

Die Diskusion geht in die falsche Richtung. Es ging weniger um den Geschwindigkeitsvorteil, sondern viel mehr um den Grundgedanken, der hinter diesen Zeilen aus der heiligen OpenBSD-Schrift steht...

Zu diesem Thema hab ich noch ein nettes Zitat von einem OpenBSD-Maintainer

Christian Schneider schrieb:
Packages bei OpenBSD saugen; pkg_add(1) loest keine Abhaengigkeiten auf. VIel Spass beim installieren von MPLayer :>
 
ich dachte die frage war:
Warum wird also vom 'do it yourself'-Prinzip abgeraten?

daraufhin sagte lars:
Dies erschwert die Fehlersuche natürlich.

ich sagte dann:

der rest meines postings sollte nur erklaeren warum ich nicht, oder nur selten quellcode uebersetze. das "dein" und "deinem" war auch nicht wirklich speziell auf dich bezogen, sondern eher allgemein gemeint ;).

- Securitypatches _sofort_ einspielen.
- lokale Patches einbauen um ein abstruses Feature hinzuzufuegen.
- Wenn ich Software mit einem anderen Compiler uebersetzt haben will/muss.
-wieviele sooo sicherheitsrelevante kisten hast du am laufen? und wieviele ports sind auf diesen kisten installiert? und stehen diese kisten in der gefahr penetriert zu werden, wenn du security fixes nicht sofort einspielst?
-wenn meine app sowieso alles kann, muss ich es nicht neu uebersetzen. falls es sich um ein voellig neues feature handelt welches ich BRAUCHE, hab ich vermutlich eine andere app benutzt, da app 1 dieses feature ja nicht kann oder konnte...
-hatte ich noch nie das verlangen danach... ;)

so, ich muss weg.
 
xenobyte schrieb:
Daraus wird ersichtlich, dass das OpenBSD-Team dazu raet, ihre Binarys zu verwenden. Allerdings verwirrt es mich, dass *alle* OpenBSD-User, die ich kenne ihre Anwendungen aus den Ports bauen, und einige sogar das komplette System "from scratch" bauen. Durch meine Erfahrungen mit Linux kann ich sagen, dass man sehr wohl viel optimieren kann, wenn man aus dem Sourcecode kompiliert.
Warum wird also vom 'do it yourself'-Prinzip abgeraten?

Es gibt diverse Gruende, warum zu Binaries (CD, FTP/stable oder auch Snapshots) geraten wird:

  • Die Installation geht schneller.
  • Die Gefahr, dass man anschliessend ein halb zerschossenes System hat, ist geringer.
  • Current vs. Snapshots: Letztere korrelieren nicht notwendigerweise mit dem aktuellen CVS-Repository, sind aber gleichzeitig "Release-Candiate-Candidates". D.h. wenn mit Current etwas nicht richtig laeuft, dann kann das daran liegen, dass man beim cvs update Pech gehabt hat (oder einen Flagday uebersehen hat). Wenn bei Snapshots etwas schief geht, hat man vermutlich einen Bug gefunden.
  • Das OpenBSD-Team hat besseres zu tun, als sich mit Deppen (wie mir) herumzuschlagen, die sich nach einem Update des gcc das System zerschiessen.

Meine persoenlichen Gruende, warum ich trotzdem von Sourcen baue:

  • Ich schraube teilweise selbst an den Sourcen herum (ksh, diverse Ports).
  • Traffic Limit zu Hause. Fuer jeden Snapshot das ganze Binarygeraffel zu saugen, kommt fuer mich einfach nicht in Frage. Ein cvs update ist wesentlich bandbreitenschoenender.
 
Zurück
Oben