BSD mit den wenigsten Bugs im Basissystem?

hartmut

Debian user
Kann man feststellen, welches BSD die wenigsten Bugs im Basissystem (ohne Ports) hat?

Zu FreeBSD habe ich vom lieben Bummibaer die sinngemäße Aussage "Bei FreeBSD knallt es eigentlich nur, wenn Hardware, Firmware oder closed-source-Treiber kaputt sind."

NetBSD hat ja den hohen Anspruch "emphasis on correct design and clean code" und "it doesn't work unless it's right".

OpenBSDs hoher Sicherheitsanspruch läßt sich ja wohl auch nur mit sehr sauberem Code erreichen.

Kein Flame, eher eine statistische Frage. Vielen Dank :)
 
Die meisten Bugs gäbe es sicher nicht wenn man sie kennen würde. Daher halte ich das für eher schwierig zu bewerten.
Und nur weil eine Software wenig Bugreports oder Bugfixes hat heisst es nicht, dass sie gut ist. Evtl ist sie einfach kaum genutzt und wenig gepflegt.
 
Das statistisch zu analysieren, dürfte schwer werden. Es beginnt schon damit, dass man nur Bugs erfassen kann, die auch gefunden wurden. Systeme mit kleinerem Nutzerkreis sind damit schon im Vorteil, da weniger Nutzer wahrscheinlich auch weniger Augen und damit weniger gefundene Bugs bedeuten. Dazu kommt, dass Bugs meist durch Änderungen im Code zustande kommen. Aber ist ein System, was mehr Dinge ändert und damit mehr Bugs einbaut zwangsläufig schlechter als ein System, was Änderungen vermeidet?

Wie dem auch sei. Ich nutze seit viel zu vielen Jahren FreeBSD auf verdammt vielen Systemen. Meine erste Installation war 2.1.6. In all den Jahren hatte ich vielleicht eine Hand voll wirklich böser Bugs im System. Meine Favoriten sind:
  • Als Journaled Softupdates eingeführt wurden, hatte man den Fall "Snapshots" nicht beachtet. Daher führte das Anlegen eines Snapshots auf einem UFS mit Journaled Softupdates mit hoher Wahrscheinlichkeit zur Panic. Als ich das bemerkt und analysiert hatte, waren Journaled Softupdates bereits ein gutes halbes Jahr im System. So gesehen bin ich Schuld, dass bei Journaled Softupdates Snapshots nicht unterstützt werden.
  • Wenn man das UFS Dateisystem als Kernelmodul baute, konnte man Snapshots nicht löschen. Sie verschwanden, waren augenscheinlich weg. Sogar der Speicherplatz wurde freigegeben. Doch im Dateisystem blieben sie teilweise referenziert, was man bemerkte, sobald man die maximale Anzahl Snapshots erreicht hatte. Der Bug war mindestens 10 Jahre im System.
  • Meine Attansic L1 NIC hatte einen Hardware-Bug. Wenn der DMA-Bereich über die 4GB-Grenze ging, schrieb die NIC Datenmüll quer über alle physischen Speicheradressen. Das zerschremmelte ZFSs Metadaten im RAM, er schrieb Müll in den Pool und nach dem nächsten Reboot führte der Import zur Panic. Ich musste mein Backup holen.
Ich möchte damit sagen, dass praktisch alle ernsten Probleme immer in Bereichen des Systems lagen, die kaum jemand nutzt(e) und damit eine schlechte Abdeckung in Sachen Bugsuche haben. Nichtzuletzt daher ist FreeBSD inzwischen auch dazu übergegangen, eine möglich hohe Testabdeckung anzustreben und hat einen Review-Prozess eingeführt. Auch statische Codeanalysen werden gemacht. Der Rest der Bugs war einfach obskur und krank, kaum im Vorfeld zu finden.

Ich nutze auf meinem Laptop seit Januar das oft als instabil gescholtene Arch Linux. Da hatte ich bisher auch nur einen einzigen, bösen Bug. Ein einfaches C-Programm mit endloser Rekursion führte beim Crash dazu, dass systemds Coredump-Handler abschmierte. Der Kernel versuchte daraufhin korrekt den Coredump des Coredump-Handlers in den Coredump-Handler zu schreiben... Dumm gelaufen. Und auch wieder ein Fall im Bereich selten genutzter Code, bis hin zu obskur.
 
Kann man feststellen, welches BSD die wenigsten Bugs im Basissystem (ohne Ports) hat?
Ich glaube, ein Vergleich scheitert schon daran, dass es keine einheitliche Definition von "Bug" gibt. In OpenBSD kann man z.B. einen Problem Report gegen eine Man Page einreichen. Das wird dort genauso als "Bug" behandelt, wie ein Fehler im Programm-Code.
 
Solche Listen sind ja schön aber, FreeBSD 9.x (aktuell 10.1) und OpenBSD 5.3 (aktuell 5.7) zu „untersuchen" sagt ja schon viel über den Autor der Seite aus.

Ich finde auch, was ist ein Bug ... etwas das nicht funktioniert ? ... etwas das mit einem workaround funktioniert ? ... sicherheitsrelevante Punkte ?
 
Das ist ja wie mit OS X... wurde damals (von Fans und Apple selbst) als sicheres Betriebssystem verkauft/beworben. Nachdem sich das durch steigende Nutzerschaft mal mehr Leute angesehen haben, hat man gemerkt, dass es eines der unsichersten Systeme ist xD
 
Was ist ein Bug, was wird gefunden, wie viele werden produziert? Geht es um Releases, geht es um aktuelle Stable oder nimmt man Entwicklungsversionen dazu? Was ist mit Bugs, die sagen wir ein Bug sind, weil sie einen Standard brechen, aber bleiben, weil sie trotzdem Kompatibilität oder Sicherheit schaffen?

Je nach Anspruch und Denkweise kann man vieles als Bug ansehen, was andere nicht als Bug sehen und umgekehrt, gerade im undefinierten Bereich. Ist es ein Bug, wenn etwas keinen Fehler ausgibt, obwohl die Eingabe falsch ist? Ist es ein Bug, wenn man trotzdem wissen könnte was das Richtige bzw. gemeint ist, aber man abbricht? Auch gibt es immer wieder was, was als experimentell oder "may break" dokumentiert ist. Wenn das passiert, ist es ein Bug oder erwartetes Verhalten? Oder umgekehrt: Ist es ein Bug, wenn Dinge unerwartet funktionieren? Was ist mit fehlerhafter Dokumentation oder fehlerhafter Konfiguration?

Was ist mit schlechtem Design? Das kann man als Bug betrachten, wenn es ernsthafte Limitierungen gibt.

Bei Basissystem stellt sich auch die Frage wie du das definierst. Heißt das alle Sets? Meinst du wirklich alle Software im System oder nur tatsächlich verwendete?

Auch statistisch und überblicksmäßig müssten viele dieser Dinge im Detail definiert werden und ob man dann jemals wirklich zufrieden ist ist dann die Frage, weil ich mir vorstellen kann, dass es Aufgrund der Unterschiede in den BSDs sehr, sehr leicht zu unfairen Situationen kommen kann.

Eben mal ganz abgesehen von der Frage, ob es um tatsächliche Bugs oder entdeckte Bugs geht. Bei letzterem kann man davon ausgehen, dass das sehr Stark mit der Userzahl korrespondiert. Eine Vermutung wäre sogar, dass ein System mit mehr entdeckten Bugs potentiell weniger vorhandene Bugs hat, weil die Entdeckung zur Behebung geführt hat. Das muss aber nicht so sein, denn natürlich muss der Bug auch entstehen und darauf kann der Entwicklungsstil und die Erfahrung der aktiven Entwickler, so wie die Größe der Codebasis Einfluss haben.

Spannend sind auch so Übergänge. FreeBSD hatte ja mal gcc und clang gleichzeitig (wie DragonFly derzeit), was sicher allein schon deshalb bedeutet, dass es weitaus mehr Bugs im System gibt.

NetBSD hat mit seinen vielen unterstützten Architekturen sicher viele Bugs die nur auf einzelnen Architekturen auftritt, auch bei OpenBSD ist das sicher nicht zu unterschätzen. Auf letzterem ist der einzige Bug den ich als erstes entdeckt habe auf hppa gewesen.
 
Das ist ja wie mit OS X... wurde damals (von Fans und Apple selbst) als sicheres Betriebssystem verkauft/beworben. Nachdem sich das durch steigende Nutzerschaft mal mehr Leute angesehen haben, hat man gemerkt, dass es eines der unsichersten Systeme ist xD

Was macht denn OS X so unsicher? Ich nutze OS X Yosemite wirklich gerne und bin etwas überrascht über diese Aussage..
 
Was macht denn OS X so unsicher? Ich nutze OS X Yosemite wirklich gerne und bin etwas überrascht über diese Aussage..

Die schiere Anzahl und Schwere an Sicherheitslücken die in den letzten Jahren so aufgekommen sind. Sicher werden die in moderater Zeit gefixt, aber alleine dass sie da sind zeugt halt von einem "im Grunde" nicht allzu sicheren System / wenig Code Reviews.

http://www.cvedetails.com/product/156/Apple-Mac-Os-X.html?vendor_id=49

siehe den Graph unten. Und damit ist nicht mal Code Execution alleine gemeint. Safari/WebKit ist Einfallstor #1 da, seit Anbeginn. Aber auch so Sachen wie "mal einfach so Lokaler Admin werden", "Login-Screen umgehen" und die Sandbox zu verlassen war bisher auch immer relativ einfach (siehe Pwn2Own Wettbewerbe als Beispiel). Das Aushebeln von signierten Binaries war letztens erst wieder großes Gesprächsthema. Vom SSL-Debakel letztens (nicht Heartbleed) ganz zu schweigen ;)

Alleine 2014 hatte OS X doppelt so viele Code Execution Lücken wie Windows 8.1 in seiner Lebenszeit bisher (Windows 8 steht nicht schlechter da):

http://www.cvedetails.com/product/26434/Microsoft-Windows-8.1.html?vendor_id=26

Sicherlich alles auch etwas "Zahlenspielereien", aber man sieht hier doch schon etwas den Unterschied zwischen der allgemeinen Chor "OS X ist sicher" und der dagegenstehenden Anzahl an kritischen Lücken.

Man erkennt auch, dass MS was für die eigene Systemsicherheit tut (Range Checks per Compiler, etc.), während Apple überall Emojis einbaut.
 
Was macht denn OS X so unsicher? Ich nutze OS X Yosemite wirklich gerne und bin etwas überrascht über diese Aussage..

Off Topic :
Spontan fällt mir da ein ... der Firewire DMA Hack, der Thunderbolt Hack (proof of concept - aber, damit lässt sich das EFI vollständig umkrempeln). Dein Standardbenutzer ist nicht root, kann aber das Selbe (root ist standardmäßig deaktiviert, hat aber kein Passwort). Die uralte Bash Version ... usw.
 
FireWire ist von der Architektur her unsicher und kann nur mittels IOMMU "umgangen" werden. Egal welches System, ohne IOMMU ist man mit FireWire am Arsch.
 
Was ist ein Bug, was wird gefunden, wie viele werden produziert? Geht es um Releases, geht es um aktuelle Stable oder nimmt man Entwicklungsversionen dazu? Was ist mit Bugs, die sagen wir ein Bug sind, weil sie einen Standard brechen, aber bleiben, weil sie trotzdem Kompatibilität oder Sicherheit schaffen?

Je nach Anspruch und Denkweise kann man vieles als Bug ansehen, was andere nicht als Bug sehen und umgekehrt, gerade im undefinierten Bereich. Ist es ein Bug, wenn etwas keinen Fehler ausgibt, obwohl die Eingabe falsch ist? Ist es ein Bug, wenn man trotzdem wissen könnte was das Richtige bzw. gemeint ist, aber man abbricht? Auch gibt es immer wieder was, was als experimentell oder "may break" dokumentiert ist. Wenn das passiert, ist es ein Bug oder erwartetes Verhalten? Oder umgekehrt: Ist es ein Bug, wenn Dinge unerwartet funktionieren? Was ist mit fehlerhafter Dokumentation oder fehlerhafter Konfiguration?

Was ist mit schlechtem Design? Das kann man als Bug betrachten, wenn es ernsthafte Limitierungen gibt.

Bei Basissystem stellt sich auch die Frage wie du das definierst. Heißt das alle Sets? Meinst du wirklich alle Software im System oder nur tatsächlich verwendete?

Auch statistisch und überblicksmäßig müssten viele dieser Dinge im Detail definiert werden und ob man dann jemals wirklich zufrieden ist ist dann die Frage, weil ich mir vorstellen kann, dass es Aufgrund der Unterschiede in den BSDs sehr, sehr leicht zu unfairen Situationen kommen kann.

Eben mal ganz abgesehen von der Frage, ob es um tatsächliche Bugs oder entdeckte Bugs geht. Bei letzterem kann man davon ausgehen, dass das sehr Stark mit der Userzahl korrespondiert. Eine Vermutung wäre sogar, dass ein System mit mehr entdeckten Bugs potentiell weniger vorhandene Bugs hat, weil die Entdeckung zur Behebung geführt hat. Das muss aber nicht so sein, denn natürlich muss der Bug auch entstehen und darauf kann der Entwicklungsstil und die Erfahrung der aktiven Entwickler, so wie die Größe der Codebasis Einfluss haben.

Spannend sind auch so Übergänge. FreeBSD hatte ja mal gcc und clang gleichzeitig (wie DragonFly derzeit), was sicher allein schon deshalb bedeutet, dass es weitaus mehr Bugs im System gibt.

NetBSD hat mit seinen vielen unterstützten Architekturen sicher viele Bugs die nur auf einzelnen Architekturen auftritt, auch bei OpenBSD ist das sicher nicht zu unterschätzen. Auf letzterem ist der einzige Bug den ich als erstes entdeckt habe auf hppa gewesen.
Ich meine in diesem Fall primär Codefehler im Basissystem (alle Sets) von Stable-Releases, die zu Abstürzen und/oder Sicherheitslücken führen. Natürlich ist der Vergleich nur beschränkt möglich, da ja z. B. OpenBSD Xorg im Basissystem hat ... Fehlerhafte Doku wollte ich erstmal ausklammern.

Anders gefragt: Welches BSD hat die bestorganisierte bzw. effektivste Code-Review?
 
Anders gefragt: Welches BSD hat die bestorganisierte bzw. effektivste Code-Review?
Dann hast sollte die Frage aber eher sein, welches BSD hat die meisten Bug-Reports, oder? Nur dass da neben dem Bug-Tracker auch Mailing Lists, etc. eingerechnet werden müsste. Effektiver Code-Review heißt ja vor allem auch immer mal wieder drüber zu gehen und nicht nur Patches zu begutachten. Regelmäßige Code-Audits, viele Leute die den Code verstehen und Bugs reporten sind ein sehr wichtiger Teil von effektivem Code-Review.

Nur wenn du Doku ausklammerst, dann ist halt wirklich die Frage was du unter Code-Review verstehst, also einfach weil falsche Dokumentation mitunter extrem kritisch sein kann. Wenn man annimmt, dass man das hat, was da in der Doku garantiert wird und dann ist es nicht so und irgendwann, wenn was schlimmes passiert ist heißt es sowas, wie "intentional Desgin", dann ist das oft deutlich schlimmer als, dass unter obskuren Umständen das Programm abstürzen und das vielleicht sogar dokumentiert ist oder es sogar eine Meldung abgibt, was ja auch immer wieder vorkommt. Das wird dann vielleicht als Bug mit niedriger Priorität gesehen, weil davor gewarnt wird, man vielleicht ein paar Schrauben drehen muss, damit man in die Situation wo das Problem auftritt kommen kann, aber ein Bug bleibt es trotzdem. Oder eben so Dinge, wo es Workarounds gibt, die man schon aus Gewohnheit macht, weil ein Zustand nicht erkannt wird. Dann kommt noch die Frage dazu, ob es ein Feature ist, dass das erkannt werden soll oder eben ein Bug, dass das nicht erkannt wird.

Leider ist die Definition von so solchen Dingen sehr, sehr schwer und es kommt zu subjektiven Meinungen und Situationen, die durch das Umfeld detoniert werden: Darf bzw. soll ein Programm mit einen Error (nicht unbedingt immer gleich ein segfault) beenden oder soll es trotzdem versuchen weiterzumachen? So eine Entscheidung hängt häufig vom Umfeld ab, wenn es dir um Durchsatz und Performance geht machst du manchmal weiter, handelst es noch einigermaßen, aber brichst nicht ab. Im Security-Bereich kann das ein schlimmer Fehler sein. Wenn das nicht dokumentiert ist, dann ist die fehlende Dokumentation für viele der wirklich Bug, denn sonst gehst du einfach von was bestimmten aus und je nach Einsatzbereich kann alles mögliche kritisch sein. Es gibt Anwendung, da ist Performance kritisch, manchmal hängt das sogar mit Security zusammen. Gerade wenn man an DoS-Attacken denkt ist es so, dass ein Performanceproblem in einem Fall, der im Normalbetrieb kaum vorkommt plötzlich ein Fall für deine Security wird.

Das mit der Doku geht auch anders rum: Spezifikationen. Was ist wenn der Fehler in einem Standard ist oder ein Standard aus sicherheitstechnischen Überlegungen absichtlich gebrochen wird? Ist das ein Bug, weil dein Protokoll-Stack den Standard verletzt und er somit keine valide Implementierung darstellt? Oder sagst du der Standard hat einen Bug? Aber was ist, wenn das nur gefährlich ist, weil man theoretisch vieles falsch machen könnte, man es aber auch "einfach" richtig, fehlerfrei implementieren könnte? Was ist, wenn die Doku darüber, dass du den Standard nicht ganz einhältst fehlt? Unter welchen Umständen zählt das?

Oder eben die Möglichkeit von falscher Konfiguration. Du kannst sicher viel Blödsinn machen, wenn du dich mit sysctls spielst. Ist das ein Bug, wenn es Nebeneffekte, die vielleicht nicht beachtet oder dokumentiert sind? Ist es ein Bug, wenn dein System-Update in speziellen Fällen fehlschlägt, die du aber explizit nicht nutzen sollst? Was ist wenn nicht klar ist, ob etwas zu einem Problem führen kann? Klar, auf den ersten Blick würde man sich denken, hey, selber schuld, wenn er Unfug damit treibt, aber dann muss man auch immer daran denken, dass ein Angreifer diesen Unfug durchaus treibt und vielleicht gerade ein komplexes Zusammenspiel vieler verschiedener Teile des Systems nutzt und es nur durch all diese Teile zum Auftreten eines Bugs kommen kann. Dann ist plötzlich ein Tool, das man einfach lokal verwendet um irgendwelche Daten gecached zu haben, damit Programm X schneller startet plötzlich der Grund, dass jemand über einen Remote-Angriff bestimmte Rechte erlangt.

Im Endeffkt ist es leider so, dass was man als kritischen Bug und Sicherheitslücke hat immer mal wieder genau sowas. Das ist nichts was man mit auf Patches schauen und Probleme in den Patches selbst findet, sondern mit Code-Review der vor allem auch nachdem Commit gelandet ist wenn möglich vor etwaigen Angreifern findet um einen Fix dafür zu releasen und unter die Leute zu bekommen. Klar, man könnte sagen, dann war es schon zu spät. Andererseits ist das echtes Code-Reviewing und reduziert die Anzahl der Bugs im System, während man woanders vielleicht viel mehr auf die einzelnen Patches/Commit schaut und deshalb vielleicht im großen Bild was übersieht, denn vieles wird ja auch erst sichtbarer, wenn man wirklich damit arbeitet und eben Stack X, Compiler Y und Konfiguration Z zusammen betrachtet, weil man es für die Anwendung gerade benötigt. Und da können Programmierer noch so gut sein, sie werden nicht das gesamte System in jeglicher Konfiguration durchdenken können und am Ende auch immer mal wieder Bugs einbauen und übersehen, denn die offensichtlichen findet man selbst, mit Tests, statischer Analyse oder jemand sobald es durch die Mailing List geht.

Und dann gibt es noch so Statistik-Sachen: Ist etwas ein Bug oder sind es zwei? Zählst du die Ursachen oder die Symptome?

Du kannst vielleicht hier Suchen nach den BSDs machen: https://web.nvd.nist.gov/view/vuln/search

Das sind vor allem Sicherheitslücken also bei weitem nicht alle Bugs.

Nur die Frage, ob der Code-Review effektiv ist ist leider schwer, weil durch Reviews Bugs entdeckt werden, selbst wenn du einen Commit mit neuem Code schaust kannst du alte Fehler finden, vor allem wen der Review gut ist.
 
Darf man fragen warum du, als alter FreeBSD-Freund, auf einmal zu Linux wechselst? Und noch dazu zu einem mit systemd?
Ich antworte mal, warum ich das auch machen würde! Arch ähnelt FreeBSD in einigen Dingen sehr, ist aber ansonsten sehr aktuell und es wird deutlich mehr Hardware unterstützt. Die Community bei Arch ist auch sehr groß, so dass man viel Support für Software findet.
 
Das beschreibt die Entscheidung für Arch Linux recht gut. Nochmal ausführlicher: Mein erstes Laptop war seinerzeit ein weißes Intel-Macbook der ersten Generation. Es enttäuschte mich sehr, denn die Hardware war einfach überteuerter Schrott und OS X nicht mein Fall. Daher schaffte ich ein Lenovo R500 an. Es startete mit FreeBSD 7.1 und wurde über die Jahre bis hin zu FreeBSD 10.0 aktualisiert. Die ganzen Jahre über lief FreeBSD darauf immer gut, aber es gab doch Punkte, die mich nervten.
  • Ich habe über die Jahre etliche Bugs in Sachen Suspend und Resume gefixt, besser wurde es aber nie. 11-CURRENT ist die erste FreeBSD-Version, wo dank diverser Umbauten Suspend sauber funktioniert und das System beim Resume ebenso sauber wieder hochkommt. Es klappt sogar auf meinem Desktop.
  • FreeBSDs WLAN-Stack ist durchwachsen. Die alte Intel-WLAN-Karte im R500 war immer saulahm und die aktuelle 822.11ac Karte des T440s wäre gar nicht unterstützt. Es gibt inzwischen allerdings einen Alpha-Treiber.
  • FreeBSD, Intel-GPU und X.org war schon mit der alten GM45 eine sehr wackelige und nervende Kombination. Nicht mal das 18 Jahre alte Quake II lief darauf nicht mal auch nur annähernd akzeptabel, von so Nebensächlichkeiten wie XVideo reden wir besser erst gar nichts.
Da Linux sich sehr gemacht hat (Ich bin nach wie vor der Meinung, dass Linux-Kernel bis 2.6.16 Spielzeug waren. Seitdem ist das Ding aber wesentlich besser geworden und inzwischen wohl der mit Abstand beste unixoide Kernel) und man über den Tellerrand schauen sollte, habe ich es mal mit Arch Linux gesucht. systemd war dabei kein Kriterium. Ich finde zwar, dass es eine sehr dumme Idee ist, aber Red Hat und Poettering haben es halt zum Sieg geführt und es wird nicht wieder verschwinden. Zumindest nicht, bis man alles wieder umbaut.
 
Wo sind da die Gemeinsamkeiten? Arch Linux benutzt Systemd und braucht keinen Installer - generell richtet es sich an den verspielten, fortgeschritteten User. Arch Linux ist eine Linux Bleeding Edge Distro dessen Standardantwort auf Probleme eine falsche Programmversion ist.
Oder war damit gemeint pkg -> pkg, aurora -> ports, dann stimmt das auch nicht. Linux Software auf eine Linux-Distro lauffähig zu konfigurieren ist nun wahrlich keine Raketenwissenschaft.
 
Danke Yamagi, für deinen Bericht. Ich bin ja auch immer hin und her gerissen. Mit FreeBSD liebäugle ich schon seit Jahren, allerdings mangelte es halt immer an der richtigen Unterstützung für Desktop-Rechner, und so blieb ich Ubuntu, und später Debian, treu. An FreeBSD gefällt mir, dass das Basis-System "professioneller" entwickelt wird, es wird nicht durch Hobby-Programmierer kaputt gefrickelt. Der kleinere Entwicklerkreis führt aber wohl auch zu geringerer Hardware-Unterstützung und anderen Mängeln. So wird das UDF Dateisystem nur lesend unterstützt, was die sinnvolle Verwendung von DVD-RAM unmöglich macht.

Mit Debians Entscheidung für systemd wuchs dann der Druck auf mich zu einem Umstieg. Poetterings Software nervte mich ständig mit Bugs (und auch das andere Zeug von Gnome und freedesktop.org), und die Aussicht dass er bald das gesamte System kontrolliert, war alles andere als rosig. Meinen Laptop habe ich vor einigen Monaten daher auf FreeBSD umgestellt, um weitere Erfahrungen zu sammeln. Wie du auch schon schreibst, klappt das mit Suspend/Resume und WLAN nach AC Standard erst mit FreeBSD 11, sodass ich mit den Updates erheblichen Aufwand habe. Desweiteren musste ich lernen dass sich die gute Qualität auf das Basis-System beschränkt. Bei den Ports sieht die Sache schon ganz anders aus, siehe Probleme mit Thunderbird/Enigmail im Nachbar-Thread. Und aktueller Fall von "geht gar nicht": zum syncen meiner Rechner und NAS verwende ich Unison. Um Kompatibilität aufrecht zu erhalten, wird Unison nicht nur in aktueller Version, sondern auch in älteren angeboten. Der kleinste gemeinsame Nenner aller meiner Rechner ist unison 2.40. Unison ist mit ocaml programmiert. Kürzlich gab es sowohl von unison240 als auch von ocaml ein Update. Ocaml wurde von 4.01 auf 4.02 aktualisiert. Und jetzt der Hammer: Programme die mit ocaml 4.01 compiliert wurden sind nicht mehr kompatibel mit Programmen die mit ocaml 4.02 compiliert wurden! Mein FreeBSD unison240 konnte nicht mehr mit dem unison240 unter Debian und Raspbian reden. Der absolute GAU. Sowas darf einfach nicht passieren. Linuxe mit "bleeding edge software" (ich glaube Arch und Gentoo) waren auch von dem Problem betroffen, zumindest findet man da Treffer mit Google. Da habe ich doch lieber eine Instanz wie Debian dazwischen, die nur ausgereifte und erprobte Software in ihre Distribution aufnimmt. Auch wenn die Software dann älter ist. Aber irgendeine Instanz zur Qualitätskontrolle ist bei Opensource zwingend nötig.

Im Prinzip läuft mein Thinkpad nun ganz gut mit FreeBSD 11, auch die Lüftersteuerung habe ich hinbekommen. Aber mein Eindruck ist nachwievor zwiespältig. Bleib ich dabei? Schwenke ich zurück zu Debian Wheezy? FreeBSD hat ein paar Einschränkungen, mit denen man aber irgendwie leben kann. Wie schon erwähnt ist da das readonly-UDF Dateisystem. Dann geht mein Chipkartenleser für Online-Banking nicht, und der Scanner meines Brother DCP-7045N kann auch nicht genutzt werden. Virtualbox unterstützt kein USB 2.0 und VMware Player geht gar nicht.

Bei Linux ist allerdings auch nicht alles Gold was glänzt. Die freien Treiber für Nividia und AMD Grafik haben zu viele Mängel, und die proprietären Treiber werden auch nicht richtig unterstützt (Probleme mit verschiedenen Fenstermanagern). Bei Linux geht eigentlich nur Intel-Grafik zufriedenstellend. Mit dem Kernel 3.16 funktioniert USB 3.0 an meinem Lenovo Ideacentre nicht, mit dem Kernel 3.2 hingegen einwandfrei. Sowas ist ärgerlich, wenn Dinge schlechter werden statt besser. Und systemd will ich auf alle Fälle vermeiden, zu viele schlechte Erfahrung mit Poettering-Ware.

So bin ich nun hin und her gerissen. Echt schwierige Entscheidung. Man kann wohl nicht alles haben. Einen Tod muss man sterben.
 
Ich sehe auch keinen Grund dafür warum man sich fanatisch auf ein System für alle seine Computer beschränken sollte... Die Systeme arbeiten doch auch so wunderbar zusammen. Sei es SMB, SSH, NFS, etc.
 
Ich sehe auch keinen Grund dafür warum man sich fanatisch auf ein System für alle seine Computer beschränken sollte... Die Systeme arbeiten doch auch so wunderbar zusammen. Sei es SMB, SSH, NFS, etc.

Da möchte ich dir grundsätzlich zustimmen. Ich versuche dennoch, zumindest bei so Basisnahen Systemen wie BSDs oder auch Arch etc, bei möglichst einem zu bleiben, einfach weil es mir als Privatunixer schon schwer genug fällt mich bei einem System immer zu erinnern wo etwas eingestellt wird oder wie der Befehl noch genau hiess.
 
FireWire ist von der Architektur her unsicher und kann nur mittels IOMMU "umgangen" werden. Egal welches System, ohne IOMMU ist man mit FireWire am Arsch.
Falsch. FireWire unterstützt DMA, aber das impliziert noch kein Sicherheitsproblem. Das Registermodell der üblichen PCI FireWire Controller enthält ein Paar 32 Bit Register, die pro ID einstellen ob DMA Requests einen Interrupt auslösen, der dem Kernel es ermöglicht Zugriffskontrolle aufs RAM zu implementieren oder direkt die physikalische Adresse ohne Prüfung an den DMA Controller geht. FireWire ist ein Bus und als solcher spoofbar es gibt also nur zwei sinnvolle Werte: für alle IDs erlauben oder für keine ID erlauben. DMA ohne Interrupts zu erlauben ist natürlich ein offenes Scheunentor. Es gibt aber valide Gründe dafür es zu aktivieren z.B. lässt sich so Firewire zum Debugging vollständig abgestürzter Kernel verwenden. Der Fehler, der FireWire den Ruf eingebracht hat unsicher zu sein, war es DMA ohne Kontrolle by default zu erlauben um die Host CPU zu entlasten.
 
Ich sehe auch keinen Grund dafür warum man sich fanatisch auf ein System für alle seine Computer beschränken sollte... Die Systeme arbeiten doch auch so wunderbar zusammen.

Das kann ich nur unterstreichen.

"Zusammenarbeit" braucht's bei mir hingegen praktisch nicht, da mir keine solche Anforderungen bestehen.
 
Zurück
Oben