FreeBSD 5.3 is "stable" but not production-ready

M

minuseins

has spoken
Jem Matzan hat auf Newsforge zwei interessante aber sicherlich streibare Artikel veröffentlich.

Der erste handelt von der 5.x Reihe von FreeBSD. Hier nimmt er die aktuellen Probleme ins Visier. Insbesondere was den Stand der 64Bit-Umsetzung anbelangt.

Vorallem bemängelt er, dass die gewohnte Zuverlässigkeit der FreeBSD-Releases fehlt. [1]

Der zweite Artikel befasst sich mit der Definition von Stabilität. Da hier auch viel Philosophie mitspielt, ist der Artikel sehr streitbar. Auch aus diesem Grund gehe ich nicht tiefer auf das Geschriebene ein. [2]

[1] FreeBSD 5.3 is "stable" but not production-ready
[2] The myth of stability
 
Anmerkungen

Zu [1] FreeBSD 5.3 is "stable" but not production-ready

Das Problem bei der Frage, ob ein Betriebsystem "production-ready" ist, ist folgendes:
Erstens hängt die Antwort von der Erwartungshaltung des Benutzers ab. Im Unternehmensbereich wird ein System von Leuten gewartet, die sich den ganzen Tag mit nichts anderem als eben diesem System beschäftigen. Im Consumer-Bereich haben die Nutzer weder Zeit noch Lust sich intensiv mit Details zu beschäftigen. Die wollen das System nicht verstehen, sondern nur benutzen. Daraus folgt, dass es eigentlich kein System geben kann, dass "es allen recht macht".
Zweitens hängt das auch davon ab, welche Anwendungsprogramme für das System vorhanden sind. Man kann die Frage also gar nicht beantworten, wenn man nur das Betriebssystem betrachtet.


Zu [2] The myth of stability

Was die Frage der Stabilität angeght, vermisse ich da immer eine bestimmte Betrachtungsweise: In der Physik heißt ein System stabil, wenn es nach einer kleinen Störung wieder in den Ausgangszustand zurückkehrt (vereinfacht gesagt). Auf Software übertragen hieße das nichts anders, als ein gewisses Maß an Fehlertoleranz zu fordern. Beispiele:
Stellt sich das System automatisch von z.B. der Installations-CD wieder her, wenn ich (als root !) ein paar Systembibliotheken lösche?
Wie verhält sich das System, wenn ich (bewußt) ein fehlerhaftes Programm starte?
In dieser Betrachtungsweise wäre ein stabiles System eines, dass erwartet, dass seine Benutzer Fehler machen können.
 
thorsten1 schrieb:
Was die Frage der Stabilität angeght, vermisse ich da immer eine bestimmte Betrachtungsweise: In der Physik heißt ein System stabil, wenn es nach einer kleinen Störung wieder in den Ausgangszustand zurückkehrt (vereinfacht gesagt). Auf Software übertragen hieße das nichts anders, als ein gewisses Maß an Fehlertoleranz zu fordern. Beispiele:
Stellt sich das System automatisch von z.B. der Installations-CD wieder her, wenn ich (als root !) ein paar Systembibliotheken lösche?
Wie verhält sich das System, wenn ich (bewußt) ein fehlerhaftes Programm starte?
In dieser Betrachtungsweise wäre ein stabiles System eines, dass erwartet, dass seine Benutzer Fehler machen können.
Zum Vergrößern anklicken....
Nun ja, Unix ist durchaus fehlertolerant. Zumindest wenn es mit dummen Usern zu tun hat. Wenn allerdings root kommt und ein paar Systembiblitheken löscht, dann denkt sich Unix: "Hey, wenn das root ist und er löscht das, dann denkt er sich was dabei. Also löschen wir das." Danach eine Neuinstallation von CD zu starten um die Systembibliotheken wiederherzustellen, wäre vielleicht garnicht im Sinne von root. Und wenn root dieses Verhalten wollte, dann kann er das ja gern selbst ins System hacken.
Bei Windows ist das System root (deshalb heisst der Superuser nur Admin :-) ) und bevormundet alle, bei Unix ist root root, und was root macht ist richtig. Wenn bei Unix einer jemanden bevormundet, dann immer nur root das System (und damit den User).
 
nickers schrieb:
Wenn allerdings root kommt und ein paar Systembiblitheken löscht, dann denkt sich Unix: "Hey, wenn das root ist und er löscht das, dann denkt er sich was dabei. Also löschen wir das." Danach eine Neuinstallation von CD zu starten um die Systembibliotheken wiederherzustellen, wäre vielleicht garnicht im Sinne von root.
Zum Vergrößern anklicken....
Ich meinte ja auch den Fall, dass jemand Sachen löscht, die essenziell für das Funktionieren des Systems sind.

nickers schrieb:
Bei Windows ist das System root (deshalb heisst der Superuser nur Admin :-) ) und bevormundet alle, bei Unix ist root root, und was root macht ist richtig. Wenn bei Unix einer jemanden bevormundet, dann immer nur root das System (und damit den User).
Zum Vergrößern anklicken....
Ist natürlich schwierig, sobald man in den Consumer-Bereich kommt. Als Unix "erfunden" wurde, gabs Leute, die Computer "nur" benutzt haben, und welche die eigens dafür da waren, Computer zu warten. Beim PC ist das natürlich anders, denn da wartet jeder sein System selber. Und nicht jeder kennt sich perfekt aus. Daher muss ein Consumer-OS fehlertoleranter sein als eins für z.B. Server.
Mit dem selben Argument, könnte man ja sagen, ABS hat im Auto nichts zu suchen, da es den Fahrer beim Bremsen bevormundet.
 
Ich meinte ja auch den Fall, dass jemand Sachen löscht, die essenziell für das Funktionieren des Systems sind.
Zum Vergrößern anklicken....
Ich habe schon verstanden was Du meinst, aber was ist denn essentiell fürs System? Der Bootloader, der Kernel, init, rc? Vielleicht hat root sich etwas dabei gedacht, als er 'rm -rf /' eingegeben hat, vielleicht aber auch nicht. Aber wie will das System das entscheiden?

Natürlich muss ein OS für den heimischen Schreibtisch anders aussehen, als das für 'nen Grossrechner. Und hier stellt sich die Frage welchen "Kundenkreis" FreeBSD bedienen will, den Heimanwender ohne Ahnung von Computern oder den Profi mit Ahnung von der Materie. Der Spagat ist schwer.
SuSE versucht sowohl die einen, als auch die anderen glücklich zu machen. Was dabei herauskommt ist quietschbunt und irgendwie gruselig in der Bedienung (ich kenne allerdings die Servervarianten von SuSE nicht besonders gut). Für den Heimanwender scheint es aber zu funktionieren. Microsoft versuchts genauso, und es ist genauso grauenvoll. Dem Profi darf ich schon mal ein bisschen Geistesleistung abverlangen und muss ihn nicht ständig bervormunden. Beim unerfahrenen Heimanwender ist es vielleicht andersrum. Allerdings habe ich die Erfahrung gemacht, dass Anwender, denen man eine Funktion erklärt, wesentlich besser klarkommen, als die, denen man immer nur sagt: "Drück erst Knopf 1 und dann Knopf 5 und dann passiert was".

Mit dem selben Argument, könnte man ja sagen, ABS hat im Auto nichts zu suchen, da es den Fahrer beim Bremsen bevormundet.
Zum Vergrößern anklicken....
Es gibt su, sudo, Dateirechte, Mehrbenutzersystem, Backups. Niemand sagt, dass root keine Sicherheit will.
 
nickers schrieb:
Ich habe schon verstanden was Du meinst, aber was ist denn essentiell fürs System? Der Bootloader, der Kernel, init, rc? Vielleicht hat root sich etwas dabei gedacht, als er 'rm -rf /' eingegeben hat, vielleicht aber auch nicht. Aber wie will das System das entscheiden?
Zum Vergrößern anklicken....

Ne, so ganz hast Du mich nicht verstanden: Das System soll und muss gar nichts entscheiden! Ich meinte nicht: "Wie verhält sich das System, wenn ich gerade dabei bin einen Fehler zu machen?", sondern "Welche Möglichkeiten gibt mir das System, einen Fehler schnell zu beheben?". Beispiel:
Als ich noch neu bei BSD war, hab ich mir mal mein KDE zerschossen. Nach der Installation eines KDE-Programms (was gar nicht für meine KDE-Version war), begrüsste mich nach dem nächsten startkde eine schmucklose Dialogbox mit dem Text "Check your installation".
Welche Möglichkeiten bietet das System jetzt an, KDE wieder herzustellen?
pkg_add geht nicht, weil das Paket kde ja schon da ist.
pkg_delete ist auch schlecht, weil dann alle Pakete, die von kde abhängen, auch gelöscht werden müssten.
pkg_update tut wahrscheinlich gar nichts, da ich ihm ja die vorhandene Version angebe.
Natürlich kann man bei pkg_* die Option -f angeben, aber dann gibts möglicherweise Inkonsistenzen. Also gerade das, was ein Paketsystem ja verhindern soll.
Fazit: Auf die Idee, das Programmdateien auch mal beschädigt werden können und dann repariert werden müssen, sind die Entwickler offenbar nicht gekommen. Oder sie haben die Tools besonders gut versteckt!

Natürlich muss ein OS für den heimischen Schreibtisch anders aussehen, als das für 'nen Grossrechner. Und hier stellt sich die Frage welchen "Kundenkreis" FreeBSD bedienen will, den Heimanwender ohne Ahnung von Computern oder den Profi mit Ahnung von der Materie. Der Spagat ist schwer.
Zum Vergrößern anklicken....
Stimmt. Ich würde sogar soweit gehen, dass der Spagat unmöglich ist. Trotzdem wird aber genau das von der open source community und allen Distributoren ständig versucht. Sie wollen ein neues Desktop-OS etablieren und machen gleich zum Anfang den entscheidenden Fehler: "Man nehme einen Unix-Kernel... ".

Dem Profi darf ich schon mal ein bisschen Geistesleistung abverlangen und muss ihn nicht ständig bervormunden. Beim unerfahrenen Heimanwender ist es vielleicht andersrum.
Zum Vergrößern anklicken....
Es geht doch nicht darum, dass der Heimanwender für BSD zu blöd wäre oder sich gerne von Windows bevormunden ließe. Geh nur mal auf die nvidia-Seite zum Treiber-download und vergleiche die Anleitungen für Windows (Treiber runterladen) und FreeBSD (readme lesen, Treiber runterladen, Dok lesen, Abhängigkeiten auflösen, install-readme lesen). Da denkt sich der Heimanwender natürlich seinen Teil. Die Tatsache, dass es offenbar auch einfacher geht, hat doch nichts mit Bevormundung zu tun, sondern eben mit Produktivität.
Bitte mal ein konkretes Beispiel, wo dich Windows bevormundet!


@ die Admins hier: könnt ihr das mal nach Geplauer verschieben, so die News ist das nach zwei Wochen nicht mehr. ;-)
 
Du installierst ein KDE Programm welches den ganzen KDE in die Knie zwingt? Was hat third party software mit dem System zu tun? Aber gut, warum dann nicht einfach das fehlerhafte Programm runterwerfen. Gut ist. pkg_deinstall $programmname
 
thorsten1 schrieb:
Stimmt. Ich würde sogar soweit gehen, dass der Spagat unmöglich ist. Trotzdem wird aber genau das von der open source community und allen Distributoren ständig versucht. Sie wollen ein neues Desktop-OS etablieren und machen gleich zum Anfang den entscheidenden Fehler: "Man nehme einen Unix-Kernel... ".
Zum Vergrößern anklicken....


Hier möchte ich mal kurz einhaken, meiner Meinung nach hat Apple den Ansatz/Spagat richtig gemacht. Das System ist sehr benutzerfreundlich und wenn man möchte kann man, muss aber nicht, in die Unix-Tiefen absteigen. Ich denke das dieser Ansatz ziemlich gut ist.
 
Durandal schrieb:
Hier möchte ich mal kurz einhaken, meiner Meinung nach hat Apple den Ansatz/Spagat richtig gemacht. Das System ist sehr benutzerfreundlich und wenn man möchte kann man, muss aber nicht, in die Unix-Tiefen absteigen. Ich denke das dieser Ansatz ziemlich gut ist.
Zum Vergrößern anklicken....

Mmmh, der Angelo Laub hat auf dem 21c3 einen interessanten Vortrag zum Thema "Mac OS X Security" gehalten; dort kann man sehen, was problematisch sein koennte :)

http://21c3.annulator.de/21c3_Folien.pdf
 
thorsten1 schrieb:
Beispiel:
Als ich noch neu bei BSD war, hab ich mir mal mein KDE zerschossen. Nach der Installation eines KDE-Programms (was gar nicht für meine KDE-Version war), begrüsste mich nach dem nächsten startkde eine schmucklose Dialogbox mit dem Text "Check your installation".
Welche Möglichkeiten bietet das System jetzt an, KDE wieder herzustellen?
pkg_add geht nicht, weil das Paket kde ja schon da ist.
pkg_delete ist auch schlecht, weil dann alle Pakete, die von kde abhängen, auch gelöscht werden müssten.
pkg_update tut wahrscheinlich gar nichts, da ich ihm ja die vorhandene Version angebe.
Natürlich kann man bei pkg_* die Option -f angeben, aber dann gibts möglicherweise Inkonsistenzen. Also gerade das, was ein Paketsystem ja verhindern soll.
Fazit: Auf die Idee, das Programmdateien auch mal beschädigt werden können und dann repariert werden müssen, sind die Entwickler offenbar nicht gekommen. Oder sie haben die Tools besonders gut versteckt!
Zum Vergrößern anklicken....
Dieser Fall ist nicht allzu einfach zu beheben, aber es würde sich anbieten, von vorneweg die portupgrade-Tool-Suite zu verwenden, um solche Probleme zu vermeiden.
Zudem ist es für Port-Maintainer schlichtweg nicht möglich, alle möglichen Kombinationen aus installierten Packages und Versionen konsistent zu halten, vor allem, weil eben wie festgestellt verschiedene Versionen nicht kompatibel zueinander sein können (API-Änderungen, etc.).
Eine Möglichkeit, die allerdings etwas Vorausdenken erfordert, wäre, immer Pakete der installierten Software zu horten und im Falle des Falles die fehlerhafte Software zu deinstallieren und das Paket des installierten, beschädigten Pakets zurückzuspielen.
Man kann den Entwicklern aber nichts vorwerfen, wenn aktuellere Versionen entsprechender Pakete zur Verfügung stehen, aber trotzdem ältere (und zudem inkompatible) benutzt werden oder Drittprogramme unvorhergesehenes Verhalten zeigen (in deinem Fall vermute ich nämlich eher, dass irgendwelche Konfigurationsdateien unbrauchbar gemacht wurden als dass Programmdateien überschrieben wurden)

snake
 
Durandal schrieb:
Hier möchte ich mal kurz einhaken, meiner Meinung nach hat Apple den Ansatz/Spagat richtig gemacht. Das System ist sehr benutzerfreundlich und wenn man möchte kann man, muss aber nicht, in die Unix-Tiefen absteigen. Ich denke das dieser Ansatz ziemlich gut ist.
Zum Vergrößern anklicken....

Der Ansatz ist richtig, aber das hat weniger was mit Unix zu tun.

Meine Theorie: Mac OS X ist erfolgreich, weil es nicht open source ist !!!

Apple ist ein Unternehmen, d.h. sie müssen mit ihren Produkten Gewinn machen, sonst sind sie Pleite. Der Marktanteil der PC-Unixe liegt bei etwa 5%. D.h. nach Abwägung allen Für und Widers kommen nur 5% aller PC-Besitzer zum Schluss, dass eine der Unix-Distributionen für sie das geeignete OS ist, also produktiv einsetzbar ist.
Wenn Apple ein Betriebsystem herausbringen würde, dessen Zielgruppe laut Markanalyse nur 5% aller Besitzer eines entsprechenden Computers umfasst, wäre die Entwicklung unrentabel. Darum haben die Mac OS X so konzipiert, dass es für fast alle benutzbar ist.

Anders bei open source: Ob eine Software von 1 Mio. , 1000, einen oder auch gar keinem genutzt wird, ist für den, der sie schreibt, schlichtweg egal. Denn er verdient so oder so nix daran.
 
@thorsten1
Aber die vielen Distributionen die als Unternehmen auftreten, wollen damit etwas verdienen. Ok, hier schlägt der verkaufte Support wohl mehr zu Buche als die CDs die sie verkloppen (oder sprechen die Zahlen etwas anderes?)

Ansonsten hat man bei Apple bei der creation von MacOSX auf NeXT zurückgegriffen. Seines Zeichen Mach 2.5 Kernel, somit stimmt die Aussage
"Sie wollen ein neues Desktop-OS etablieren und machen gleich zum Anfang den entscheidenden Fehler: "Man nehme einen Unix-Kernel... "."
Zum Vergrößern anklicken....
nicht wirklich.

Nimmt man nun den hier beschriebenen "Spagat", das ein normaler Homeuser ein OS nutzen kann/soll und auch ein versierter Nutzer mal in die Tiefen gehen kann, so ist MacOSX der Spagat am ehesten gelungen.
Es basiert immerhin auf opendarwin, welches wiederum frei ist und Teile davon unter der "Apple Public Source License" stehen, bzw. der GPL. Das Userland ist ein *BSD-userland, wobei den grössten Teil FreeBSD 5.x ausmacht. Auch der Kernel wird immer bsdisher, und es scheint zu funktionieren.
Ein Homeuser bekommt schnell eine schöne grafische Oberfläche (Aqua) geliefert auf der er alles einstellen kann was er braucht und vieles ist schon vorhanden.
Der "Profi" kann dann fink und die darwinports nutzen um Software zu installieren, er kann direkt via shell an den confs rumschrauben (ipfw, postfix, apache, cups) welche der Homeuser über die grafischen tools beharkt (und das auch reicht).
Man kann soweit gehen und den kernel neu bauen, wenn man es denn unbedingt möchte. Muss es aber nicht.
Der boot in die reine shell geht auch, X hochziehen mit blackbox auch.
Unterm Strich ist es ein System mit dem ein Anfänger schnell zurechtkommt und an dem sich ein UNIX Freund auch erlaben kann. Spagat gelungen.
 
Meine Theorie: Mac OS X ist erfolgreich, weil es nicht open source ist !!!
Zum Vergrößern anklicken....

Was hat die Güte eines Produktes damit zu tun ob die Quellen offen liegen?

Nebenbei bemerkt, man kann auch Software mit Sourcen verkaufen. Für den Käufer ist es dann quasi "Open Source".

r0b0
 
r0b0 schrieb:
Was hat die Güte eines Produktes damit zu tun ob die Quellen offen liegen?

Nebenbei bemerkt, man kann auch Software mit Sourcen verkaufen. Für den Käufer ist es dann quasi "Open Source".

r0b0
Zum Vergrößern anklicken....

Mit open source hatte ich hier gemeint: alles was unter GPL (oder vergleichbaren Lizenzen) steht, sprich kostenlos und ohne Einschränkungen verbreitet werden darf. Mit solcher Software lässt sich kein Geld verdienen, denn da jeder die Software unbeschränkt vervielfältigen und verteilen darf, sinkt der Preis des Produkts ins bodenlose, sprich auf 0 ¤ ! Firmen, die open source "verkaufen", leben folglich nicht von Software, sondern vom Support.
Und ob die Software mit oder ohne Quellcode verkauft wird, ist dem Durchschnittts-User herzlich egal, denn er könnte eh nix damit anfangen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben