Immer wieder wenn ich Nachrichten über *BSD sehe, frage ich mich:
Warum unterschiedliche Projekte, so unterschiedlich stark von Open Source Aufschwung profitieren. Warum gibt es kaum Firmen, die ihren Geschäft auf *BSD aufbauen würden. Liegt es an der Licenze oder an den Leuten, die diese Projekte leiten?
Wenn die Licenze schuld sein soll, warum gibt es so was wie HURD mit der richtigen Licenze und theoretisch "besseren" Architektur und trotzem ist HURD höchstens zum Witzereisen gut geeignet?
Warum sind so viele User und Entwickler mit Linux Kernel unzufrieden und trotzdem marschieren alle brav hinterher?
Von sepplschorsch am So, 21. Oktober 2007 um 12:45 #
>Liegt es an der Licenze oder an den Leuten, die diese Projekte leiten? K.A.! Wahrscheinlich an beidem und noch viel mehr! >Wenn die Licenze schuld sein soll, warum gibt es so was wie HURD mit der >richtigen Licenze und theoretisch "besseren" Architektur und trotzem ist >HURD höchstens zum Witzereisen gut geeignet? Naja, _man_ sagt ja, Mikrokernel ganz toll, aber auch sehr kompliziert... >Warum sind so viele User und Entwickler mit Linux Kernel unzufrieden und >trotzdem marschieren alle brav hinterher? Das es _so_viele_ sind, ist nicht bewiesen.
Also ich finde ja dass Yahoo nicht so wenige sind. Und in Japan ist FreeBsd fast gleich stark verbreitet als Serversystem wie Linux. Zum anderen der Grund wird sein: kennst du eine Firma wie Redhat oder Novell oder IBM unsw. die FreeBsd Anbieten bzw Support leisten? Wäre ja vielleicht eine Marklücke.
Yahoo ist nur noch bei FreeBSD weil ihre ganze Infrastruktur für FreeBSD über Jahre gewachsen ist und sie gar nicht anders können als weiterhin FreeBSD einzusetzen. Die würden gerne mittlerweile auf Linux umsteigen aber für Yahoo wäre das so schwierig wie ein Umstieg von Windows auf Linux und deswegen ist es auch bei Yahoo so, dass die nicht von heute auf Morgen umsteigen werden sondern immer wieder nur Teilbereiche umstellen.
Da würde mich doch, sozusagen aus erster Hand, interessieren, warum yahoo auf Linux umsteigen möchte (oder sollte)? Weshalb ist man mit bsd unzufrieden oder welchen Vorteil verspräche ein Umstieg?
Bei der BSD Lizenz muß man nur die Copyrightinformationen im Quelltext beibehalten. Ansonsten kann man machen was man will. Daher können Firmen Eigenentwicklungen unter Verschluß halten. Oft ist es aber so das durchaus etwas an die *BSD Entwickler zurückgegeben wird da die Firmen den Aufwand einer ständigen Pflege scheuen.
Bei der GPL muss der Quelltext offen bleiben. Daher ist es auch viel offensichtlicher wenn eine Firma Linux einsetzt, da sie ja den Quelltext veröffentlichen muß.
NetBSD wird z.B. sehr oft in Storagesystemen eingesetzt ohne das man was davon mitbekommt. FreeBSD wird von vielen Providern im Hintergrund als Server eingesetzt ohne viel Trara darum zu machen und OpenBSD in Firewalls.
Was ist mit Apache? Kein GPL Web-Server kann sich durchsetzen und die Beispielen kann man ohne Ende fortführen. Ich denke, dass es zu Beginn auf jeden Fall und später in meisten Fällen es ausschließlich auf die Leute ankommt. Die Licenze ist sehr wichtig aber nicht entscheidend.
Und man darf nicht vergessen, dass Apache das erste (!) erfolgreiche Projekt überhaupt war. Von denen hat IBM erst gelernt, dass Open Source einen Sinn hat und sich dann erst auf Linux eingelassen.
Und es war die Apache Foundation, die ein Java geschaffen hat, dass so gut war, dass es Sun zum Handeln gezwungen hat. Wenn ich es recht verstehe, verwendet der gcj zumindest ihren Parser als Frontend, da er schon lange Java 1.5 (generics, etc) kann. Das GPL Java Projekt ist an der Stelle nicht weit gekommen.
Denn, die ursprüngliche Frage betreffend. Am Ende des Tages entscheiden über den Erfolg eines Projektes:
a) Die Qualität des existierenden Codes b) Die Offenheit der Community c) Wer zuerst kommt
zu c) Die BSD-Unixe waren zwar zuerst da, hatten damals aber bei ihrem SCO-Problem (AT&T) einen kompletten Stillstand über Jahre wegzustecken. Zeit für Linux. Ohne dieses Problem wäre Linus heute vermutlich mit einem BSD Unix auf seinem Rechner unterwegs. Er hatte damals ja nur Minix, was ihm nicht gut/offen genug war.
zu b) Die BSD-Community gibt ihren Code frei. Im Projekt darf aber nicht jeder einfach alles tun. Im Code eines anderen einfach was zu ändern, gilt als unfein, solange dieser es selbst machen will. Viele solche Situationen sind damit geendet, dass Änderungen nicht akzeptiert, aber auch nie richtig gemacht wurden. Linux 0.95 war da offen für alle.
zu a) Die Qualität des Codes sprach für BSD auf eine Weise. Aber Linux konnte ohne Floating-Point Coprozessor und ohne SCSI-Disk mit billiger IDE-Hardware laufen. Das war die entscheidende Qualität für die grosse Masse an Hardware-Besitzern.
Aber NetBSD wird immer mein erstes Unix bleiben, auf dem Amiga damals. Damals war Linux noch ein Gerücht. :)
Von theBohemian am So, 21. Oktober 2007 um 19:11 #
> Und es war die Apache Foundation, die ein Java geschaffen hat, dass so gut war, dass es Sun zum Handeln gezwungen hat. Echt? Warum hatn dann OpenJDK die gleiche Lizenz wie GNU Classpath und nicht die von Apache Harmony?
> Wenn ich es recht verstehe, verwendet der gcj zumindest ihren Parser als Frontend, da er schon lange Java 1.5 (generics, etc) kann. GCJ benutzt ECJ. Der kommt vom Eclipse Project.
Sorry, Du hast Recht. Das war die Eclipse Foundation, nicht Apache, mit dem gcj Frontend! Die EPL von denen ich zwar auch liberaler als die GPL, aber da hab ich was verwechselt.
Für Java hat Sun mit Absicht (so understelle ich!) die GPL gewählt, weil diese aus Sun-Sicht das kleinere Übel darstellt und verhindert, dass Harmony sich auch nur eine Zeile Code leihen könnte, ohne eine für Apache inakzeptable Lizenz zu nehmen.
Die GPL gibt einer Firma eine ziemlich starke Kontrolle, wenn die alleiniger Copyright-Holder ist. Siehe auch Qt. Darum ist sie die natürliche Wahl für Projekte, die eine Firma alleine stemmen will. Bei Sun sind das OpenOffice, OpenSolaris und OpenJDK. Unter der Apache Lizenz hat keiner irgendeine Kontrolle. Das wollen alle ausser Sun.
>Die BSD-Unixe waren zwar zuerst da, hatten damals aber bei ihrem SCO-Problem (AT&T) einen kompletten Stillstand über Jahre wegzustecken
Das ist mehr oder weniger kompletter Blödsinn.
https://www.bsdwiki.de/Geschichte - lesen bildet.
>Im Projekt darf aber nicht jeder einfach alles tun.
Ebenfalls Blödsinn. Linus kloppt seit Beginn jedem auf die Finger der Amok läuft, bei BSD macht dies die Mehrheit der Entwickler und das *gewählte* Core-Team gibt die Richtung vor. Also nichts Diktatur, nur ne Menge FUD seitens Linux.
>Ohne dieses Problem wäre Linus heute vermutlich mit einem BSD Unix auf seinem Rechner unterwegs.
Er hätte es damals auch haben können, wenn er nicht dem FUD geglaubt und sich besser informiert hätte. Gut es gab noch kein Internet mit der breiten Info-Basis, aber wie man hier sieht halfs auch nicht wirklich :-)
Also bitte, weniger Unfug das nächste mal und mehr Wissen. Das war wohl jetzt ein Lektion in geschichtlichem Amoklauf?
Dass es immerhin bis 1994 gedauert hat, bis die Sache ausgestanden war, ist Dir aber schon aufgefallen? Dadurch sind 2 Jahre verloren gegangen. Ohne diese Ereignisse wäre es BSD deutlich besser ergangen. Ich dachte, das wäre unumstritten.
Und oft beobachtetes Fakt ist, dass bei BSD gerne mal Teile des Codes komplett einem einzigen Maintainer anvertraut waren. Den musste man fragen, so gehörte sich das. Die Geschichte des Theo Deraadth (http://en.wikipedia.org/wiki/Theo_de_Raadt) ist da beredtes Zeugnis. Sein OpenBSD wurde gegründet, weil NetBSD nicht offen war. Und übrigends wurde Theo weder gewählt, noch abgewählt, sondern vom Core-Team ausgeschlossen. Es ist oft passiert in der BSD Historie, dass Änderungen nicht aus technischen, sondern aus personellen Gründen abgelehnt wurden. Der Maintainer wird in der Regel diejenigen mit Patches solange warten lassen, bis er selbst soweit ist. Es wurden hier schon prominente BSD-Entwickler mit solchen Aussagen zitiert?!
Bei Linux ist seit jeher Niemandes Code heilig, alles ist rein zufällig, da es kein stabiles System gibt. Von jedem werden Patches akzeptiert, wenn sie sinnvoll erscheinen. Wer nicht mithalten kann, fällt raus. Auch hier werden Entscheidungen aus personellen Gründen gefällt, siehe Con neulich, wenn man Entwicklern nicht recht traut, und das Thema nicht wichtig ist. Aber in der Regel geht es nie darum, dass jemand seinen Code beschützen darf. So wird z.B. gegen den Willen des x86 Maintainers gerade x86 mit x64 gemerged. Da hat jemand keine Macht über "seinen" Code mehr, nur ob er den dann noch weiter supported.
Und BSD _konnte_ Linus nicht haben, da er keinen SCSI-Controller hatte, ganz einfach. Ohne diesen hätte Linus nicht mal versuchen können, den Treiber für IDE entwickeln können, da ohne diesen BSD nicht installierbar war. Viele seiner Mitstreiter (er selbst?) hatten keine FPU und ohne das ging BSD damals erst recht nicht. Es war überhaupt nicht denkbar, BSD auf minderwertiger Hardware (sprich DOS-Boxen) zu verwenden.
Und Linus war sicher gut genug informiert, denn das Internet gab es auch schon vor dem WWW.
Ich weiss aus Erfahrung, dass "Unfug" und "FUD" auch nur Ersatzworte für "will ich nicht glauben", "es kann nicht wahr sein, was nicht wahr sein darf" sind. Mir würde es auch helfen, wenn Du in Argument-Form formulierst.
Hier geht es eher darum das Apache wohl einer der ersten Webserver überhaupt war und alles bot was man brauchte. Ab einem gewissen Verbreitungsgrad wird es dann ein Selbstläufer.
Alternative freie Webserver wie z.B. Lighttpd, Cherokee oder thttpd sind eher Spezialisten als Alleskönner. Ich verwende z.B. den Lighttpd gerne wenn auf dem Server nur eine begrenze Anzahl an Seiten läuft und nichts spezielles benötigt wird oder nur eine begrenzete Menge Resourcen (z.B. auf VServern) zur Verfügung steht.
Im Massenhosting sind diese Webserver fast nicht einsetzbar. Nicht etwas weil sie schlechter als der Apache wären aber die Leute erwarten das z.B. die .htaccess Dateien mit den mod_rewrite Anweisungen bei ihrem Blog, CMS oder Webshop läuft.
Zudem ist auch oft Unkenntnis ein Faktor. Die meisten kennen diese Alternativen garnicht.
In gewissen Situationen ist ein anderer Webserver besser. z.B. bricht der Apache bei vielen gleichzeitigen Anfragen von der Leistung her ziemlich stark ein. Da baut sich leicht ein Stau an Anfragen auf.
Der Lighttpd hingegen ist da viel belastbarer und liefert auch bei vielen gleichzeitgen Anfragen die Daten entsprechend flott aus.
Auch der Speicherverbrauch von Lighttpd ist wesentlich geringer als der vom Apache. Dadurch kann der gleiche Server mehr Prozesse verkraften.
Dafür hat der Lighttpd bei weitem nicht die Fähigkeiten vom Apache.
Allerdings gibt es dafür einige Spezialgebiete die der Lighttpd hat. z.B. das Modul mod_flv_streaming das wohl von YouTube mit entwickelt wurde und von diesen auch massiv im Backend von YouTube eingesetzt wird.
Auch Wikipedia setzt in einigen Bereichen auf den Lighttpd.
danke für den Hinweis, schon interessant. Im allgemeinen liegen die Vorteile wohl bei grossen Dateien, vielleicht finde ich ja mal ne Verwendung dafür. :-)
Von Donnerlatte am So, 21. Oktober 2007 um 14:24 #
Genauso siehts aus! BSD steckt in eine Menge drin. Da ich mich gerade mit NAS-Systemen beschäftige, bin ich auf einige Produkte gestossen, wo mit Sicherheit BSD drinsteckt, man aber nicht darüber erfährt. Bin aber zum Entschluss gekommen auf Mini ITX Basis + FreeNas auf einer CF-Card ein eigenes System aufzusetzen.
Letzendlich bleibt die Frage ist nicht die BSD-Lizenz noch freier als die GPL, weil Sie wirklich jedem die Freiheit gibt damit zu tun was man will. Oder ist die GPL freier, weil Sie eine Firma zwingt die Quellen zugänglich zu machen? Das ist Ansichtsache. Man sollte erwähnen, das Firmen die sich bedienen, grundlegend ein Interesse haben gewisse Features upstream ins Projekt zu bekommen, weil Sie sonst sehr aufwendig neben der Innovation, die im Projekt selbst geschieht, selbst Ihre Sachen "nebenher" pflegen müsssen.
Von Dr. Halbbit am So, 21. Oktober 2007 um 19:23 #
Letzendlich bleibt die Frage ist nicht die BSD-Lizenz noch freier als die GPL, weil Sie wirklich jedem die Freiheit gibt damit zu tun was man will. Oder ist die GPL freier, weil Sie eine Firma zwingt die Quellen zugänglich zu machen?
Wo ist denn da noch eine Frage offen?
Das ist Ansichtsache.
Keinesfalls!
In einem Lager, Reservat oder Knast ist man freier als "Draußen"? Man wäre ja zumindest unter Gleichen... das gibt einem schon etwas Beruhigung und die Zäune, Wälle oder Mauern schützen Dich ja vor den Bösen jenseits des NonGPL-Schutzwalls... man mauert sich glatt noch freiwillig ein, wenn das propagierte Feindbild gräusig genug erscheint...
NATÜRLICH ist die GPL unfreier als die BSD-Lizenz, denn GPL bedeutet eingesperrte Freiheit, wie im Reservat, weil GPLler glauben, daß man ihnen was wegnimmt, wenn sie sich nicht selbst einmauern. Außer für das gute Gefühl im Bauch beim Aufgeben der zuvor vorhandenen Freiheit spielt es keine Rolle, daß der GPLer sich dafür selbst freiwillig eingemauert hat: Mauer ist Mauer und das Freiheitsgefühl innerhalb dieser Mauer ist purer Selbstbetrug!
Die GPL paßt prima zur Paranoia der derzeitigen Politik und ich bin schon gespannt, wieviel härter GPLv4 wird...
Daß man bei dieser "Freiheit in Schutzhaft" überhaupt von Freiheit reden darf, ist mir ein ständiger Quell von Verwunderung!
Von Klabautermann am So, 21. Oktober 2007 um 22:55 #
Jeder Programmierer kann seinen Quelltext unter die Lizenz stellen, die ihm passt. Wenn dir die Lizenz nicht passt, benutze das Programm nicht.
Btw: dir ist es auch nicht erlaubt einfach einen Menschen zu töten. Ist jetzt eine Gesellschaft, die das Töten von Menschen erlaubt, "besser" nur weil deine persönliche Freiheit größer ist?
Absolute Freiheit ist etwas für Egomanen und hilft der Gemeinschaft überhaupt nicht. Wo das gesunde Mittelmaß ist, ist immer die Frage.
im Moment sind diese noch nicht so in Mode, hängt auch leider mit der "geistigen" Flexibitität der Programmierer zusammen, das geht nicht so schnell. Aus akademischer Sicht sind Microkernel den aktuellen monolytischen Kerneln vorzuziehen. Auch Linux ist mit seinen nachladbaren Modulen ein monolytischer Kernel.
An der Informatik-Fakultät in Dresden gibt es Projekte, welche die selbe Sytemsicherheit mit weit weniger Code bei Microkerneln erzielen als SELinux mit dem Linuxkernel. Insgesamt ist es wesentlich weniger Code, dadurch wird es auch übersichtlicher. Man muss allerdings zwischen akademischer und industrieller Welt unterscheiden. Die Industrie interessiert sich leider nicht dafür.
Und die Dresdener sind so dumm nicht...
schönen Sonntag noch
PS > Warum sind so viele User und Entwickler mit Linux Kernel unzufrieden und trotzdem marschieren alle brav hinterher?
Die Frage, ob Mikrokernel besser sind, und Linux damit obsolet, wird schon mindestens seit 1992 diskutiert: http://www.educ.umu.se/~bjorn/mhonarc-files/obsolete/ ist das klassische Beispiel dafür. Interessanterweise hat in all den Jahren niemand in der Industrie den vermeintlichen Vorteil für sich entdeckt und es blieb bei dem ewigen Mantra "ist überlegen" in akademischen Kreisen. Gäbe mir langsam mal zu denken.
> Man muss allerdings zwischen akademischer und industrieller Welt unterscheiden. Das ist es eben. Akademiker brauchen sich erstmal an der Realität nicht orientieren, Praktiker schon. Und beides ist auch gut so.
Was sagst Du zu FUSE (Filesystem in Userspace) ? Nicht wenige bezeichnen FUSE als Mikrokernel durch die Hintertür. Linus kann doch nicht zugeben, dass er so viele Jahre falsch lag, aber warten wir ab, wohin die Entwicklung uns hinführt. Außerdem ist Mikrokernel gar nicht so selten. Es gibt Gerüchte, dass Windows und MacOS und einige weitere mit Mikrokernen ausgestattet sind.
Das hat noch lange nichts mit Mikrokernel zu tun. Das Entscheidende bei Mikrokerneln ist die Prozesskommunikation per Message-Passing und die Behandlung von Interrupts durch Userspace-Server die durch Nachrichten vom Kernel über Interrupts informiert werden.
Windows ist kein Mikrokernelsystem und weil bei MacOS X fast alles was irgendwie wichtig ist im BSD-Kern läuft, der wiederum auf dem Mach-Mikrokernel läuft, würde ich es auch nicht Mikrokernelsystem nennen.
Windows NT hatte einen Microkernelmäßigen Ansatz, da aber Treiber auch in den Kernelspace geladen werden ist es kein reiner Microkernel.
> Mac OS, hat ein BSD als Unterbau.
Das Konzept hinter einem Microkernel ist, daß man alle Treiber in den Userspace auslagert. Große Probleme gibt es bei der Kommunikation zwischen dem Kernel und den Treibern, da dort noch eine Zusatzschicht als "Übersezter" arbeitet.
Sich mal auf den OS-Seiten der Dresdner Informatiker herum zu treiben lohnt sich.
Ein Fiasko-Kernel ist nur noch ca. 3 Prozent langsamer als ein 2.6er Linuxkernel, auf gleicher PC-Hardware selbstverständlich vorausgesetzt. Und um das System vergleichbar wie ein SELinux abzusichert braucht man viel weniger Code, da fast nichts im Kernelspace läuft.
> Linus kann doch nicht zugeben, dass er so viele Jahre falsch lag [...]
1992: "True, linux is monolithic, and I agree that microkernels are nicer. [...] If the GNU kernel had been ready last spring, I'd not have bothered to even start my project: the fact is that it wasn't and still isn't." (Linus Torvalds)
2007: siehe '1992'
Aber: Linus hat ursprünglich auch nicht geplant, den Kernel jemals auf andere (non-i386) Architekturen zu portieren; wenn der Bedarf besteht und die Vorteile die Nachteile überwiegen, wird immer mehr Funktionalität in den user space verlagert werden, egal, ob Linus das will oder nicht.
Von Anonymous Coward am Mo, 22. Oktober 2007 um 13:16 #
"Interessanterweise hat in all den Jahren niemand in der Industrie den vermeintlichen Vorteil für sich entdeckt" Doch, es gibt z. B. QNX Neutrino, und auch Microsoft forscht an einem Microkernel-System namens Singularity.
Von Anonymous Coward am Mo, 22. Oktober 2007 um 13:06 #
Wenn die Licenze schuld sein soll, warum gibt es so was wie HURD mit der richtigen Licenze und theoretisch "besseren" Architektur und trotzem ist HURD höchstens zum Witzereisen gut geeignet? Weil die HURD-Architektur ganz einfach schlecht ist. Der verwendete Mach-Microkernel hat große Performance-Probleme bei der Interprozesskommunikation, welche bei einem Microkernel-System extrem wichtig ist. Es gab und gibt wohl einige Bemühungen, Hurd auf andere Microkernel zu porten (L4, Coyotos und zuletzt ein eigener Microkernel von Marcus Brinkmann: http://mrhurd.no-ip.org/hird/Main_Page), aber keiner scheint so richtig zu wissen, in welche Richtung das ganze geht, und parallel wird auch noch der Mach-Hurd weiterentwickelt. Das ist heilloses Chaos.
... wieso sollte ich nicht Linux verwenden? Ich habe vor Jahren FreeBSD und OpenBSD ausprobiert, aber für mich keine Vorteile entdeckt (außer das alles sehr "aufgeräumt" gewirkt hat - aber kein Wunder wenn alles aus einer Hand kommt). Eher im Gegenteil: viele Anwendungen müssen erst compiliert werden (viel Spaß beim Updaten! - ich weiß das die Abhängigkeiten aufgelöst werden, aber compilieren muß man das trotzdem) - das ist eigentlich nur Bastlern oder ganz großen gewerblichen Nutzern zumutbar. In der Regel will man aber einfach nur binäre Updates einspielen, wie es bei den allermeisten Linux-Distributionen üblich ist. Wenn es aber beispielsweise ein mit breiter Unterstützung gewartetes Debian/NetBSD gäbe sehe die Sache vielleicht anders aus.
Was aber für Linux spricht: bei Linux gibts eine größere Community, insofern breitere Unterstützung bei Problemen, Neuentwicklungen, Treibern, usw. In Linux ist bspw. auch schon sehr viel Geld von Unternehmen geflossen die bestimmte Kernelbereiche optimiert haben.
Wenn Du aber meinst wieso zu Beginn dieser Projekte sich Linux gegenüber anderen Unixen behaupten konnte: das ist wohl eher keine technische Frage sondern lag IMHO an den Leuten die beteiligt waren. Linus Torvalds konnte anscheinend in relativ kurzer Zeit Entwickler begeistern sich ihm anzuschließen ...
1.) Der Linux- Kernel hat einen grundlegenden Bug, der nicht ohne weiteres korrigiert werden kan: und zwar die Philosophie des monolithischen Kernels und fehlenden stabilen API. Fast alle paar Stunden kommt eine neue Kernelversion raus, die meistens inkompatibel zu Vorgängern ist. Gut dass es noch nicht so viele Linux Nutzer in der Welt gibt, sonst würde uns bei Kernel- Kompilieren eine viel größere Öko- Katastrophe drohen.
2.) Treiber- und Softwareentwickler sowie normale User müssen viel überflüssiger arbeit leisten. Anstatt nur die verbugte Datei auszutauschen, wird ein neuer Kernel installiert, wobei nicht selten kernelnahe Software wie udev u.s.w., alle möglichen Treiber sowohl freie als auch nicht freie und sogar die, die im Kernel drin sind, Virtualisierungslösungen wie Vmware, Virtualbox, u.s.w., ihren Dienst einstellen.
Natürlich versuchen Distributoren viele diese Mankos auszugleichen, aber wenn Linus nicht so stur wäre, hätten viele Leute sehr viel weniger Kopfschmerzen und die ganze stupide Arbeit wäre überflüssig.
zu 1) Es ist Dir natürlich klar, dass zur Zeit nur alle 3 Monate ein neuer Kernel erscheint. Und dass den weniger als 1% der Linux-User compilieren werden. Dass den dann so keiner ausführt, sondern eher das abgeleitete Produkt von RHEL oder Ubuntu, das viel seltener ein Update erfährt, reduziert das "Problem" weiter. Von denen haben die User die Garantie und die Unterstützung, die Ihnen die Entwickler nicht geben können und wollen und auch nicht müssen.
zu 2) Normale User installieren nur fertige Systeme und tauschen dort nur den Kernel gegen minimal veränderte Versionen aus, in denen nur Bugfixes enthalten sind. Das gilt inzwischen auch für mich, vor Jahren habe ich immer noch selbst gebaut, um für schwache Hardware (immer zuwenig RAM) zu optimieren, aber jetzt lohnt sich das nicht mehr. Beachte hierzu die "stable" Kernelserie, die dazu dient, unter den Distributoren das Wichtigste gemeinsam zu verfolgen.
Das gute an der Sache ist die Geschwindigkeit mit der sich Linux verbessert. Und viele der angeblichen Opfer schätzen Linux sehr. So ist IBM nicht alleine darin, ihr Unix zugunsten von Linux aufzugeben und spart sich Unmengen. Nur diejenigen, die das falsche tun wollen oder müssen, nämlich mit ihrem Code ausserhalb von Linux zu leben, habe Probleme damit.
Und udev darfst Du nicht nennen, weil ein Kernelupdate ohne libc-Update und ohne udev-Update nicht korrekt ist. Aber das macht Ubuntu für mich schon... :-)
Die neuen Kernel mit der mit der Änderung an der 3. Stelle erscheinen in der Tat ca. alle 3 Monate. Die Bugfix- Kernel mit der 4. Stelle erscheinen aber öfter. Hier ist keine Planung möglich. Es kann Wochen, Tage oder nur Stunden dauern bis zur nächsten Version.
Und wenn ich jetzt den Distributionskernel durch den aktuellen Vanilla-Kernel ersetze, weil ich z.B. bestimmte Treiber benötige, dann kann ich mit Sicherheit sagen, dass mindestens Nvidia Treiber und Vmware Server ohne neuen Kernelmodule versagen. Weitere Problem sind nicht ausgeschlossen.
Wenn ich nur nur den passenden Treiber austauschen könnte, hätte nicht nur ich viel weniger Probleme.
Von Anonymous Coward am So, 21. Oktober 2007 um 21:54 #
.. die an der 4. Stelle sind aber nur kritische Bugfixes und keine API-Aenderungen. Da koenntest du deine externen Module einfach wieder in's lib/modules kopieren .. oder wie schon den Kernel neu uebersetzen. Vor Bugs ist man eben nicht gefeit, meist sind die Changelogs dieser Revisionen aber auch nicht so lang und man kann dann immernoch entscheiden ob man's braucht.
>>Die Bugfix- Kernel mit der 4. Stelle erscheinen aber öfter. Hier ist keine Planung möglich. Es kann Wochen, Tage oder nur Stunden dauern bis zur nächsten Version.
Richtig kompiliert, kannst du hier ganz einfach deine Module vom vohrerigen Kernel nutzen, sprich 2.6.21.1 - 2.6.21.x . Des weiteren, ist es doch eigentlich immer so, dass hier so exotische Sachen gefixt werden, die nur ganz wenig Leute betreffen. Guck dir mal Änderungen darin an, betreffen dich die jedesmal?
>>>Und wenn ich jetzt den Distributionskernel durch den aktuellen Vanilla-Kernel ersetze, weil ich z.B. bestimmte Treiber benötige, dann kann ich mit Sicherheit sagen, dass mindestens Nvidia Treiber und Vmware Server ohne neuen Kernelmodule versagen. Weitere Problem sind nicht ausgeschlossen.
Also ich nutze seit Jahren immer den aktuellsten Vanilla Kernel, die paarmal in denen der aktuellste Nvidia Treiber nicht kompilierte kann ich an der Hand abzählen.
Vanilla Kernel sind ja eh eigentlich was für Bastler, genauso wie ein Detonator etc.
Von Anonymous Coward am So, 21. Oktober 2007 um 22:18 #
> Und udev darfst Du nicht nennen, weil ein Kernelupdate ohne libc-Update und ohne udev-Update nicht korrekt ist. Aber das macht Ubuntu für mich schon.
Aehm, die Systemcalls aendern sich doch nicht soo haeufig.. bis jetzt habe ich immer ganz gut mit reinen Kernelupdates gelebt.
Von Dr. Halbbit am So, 21. Oktober 2007 um 19:32 #
Wenn es aber beispielsweise ein mit breiter Unterstützung gewartetes Debian/NetBSD gäbe sehe die Sache vielleicht anders aus.
Debian/NetBSD wäre ein Debian-Port und kein NetBSD. Es wäre nett, wenn Debian sich so vom Linuxkernel emanzipieren könnte und dafür ad hoc 50 Plattformen gewinnt, aber es würde NetBSD wenig beeinflussen, wenn dies geschähe.
Alle großen BSDs planen, langfristig frei von GPL-Code zu werden und das ist auch gut so!
Von Dr. Halbbit am So, 21. Oktober 2007 um 21:11 #
...man kann Lizenzen natürlich auch ignorieren...
Aber tut man das nicht, schränkt Einen die BSDLizenz deutlich weniger ein. Ich sehe darin wahrlich mehr als eine praxisirrelevante quasireligiöse Frage.
Für den sogenannten "Enduser" tut es auch die MS EULA oder GPL oder BSD. Oder oftmals die Raubkopie.
Die anderen als religiös zu diffamieren (was ja auch nur in Deutschland funktioniert, in den USA sind Atheisten nicht gesellschaftsfähig) ist einfach und effektiv, besagt aber nichts. Man sollte sich lieber über die Ziele unterhalten, und die sind sicher nicht, in den Himmel zu kommen.
Ich behaupte, es gibt Entwickler, die nur untereinander Code tauschen wollen und dies als Sprungbrett sehen, um in richtigen Firmen auch mal richtige Projekte umzusetzen, wo dann auch Vollzeit bezahlt wird. Die BSD-Entwickler haben aus meiner Sicht kein Problem damit, Neuland zu erforschen, auch wenn Firmen wie Apple den Code für sich behalten wollen. Diesen sind die Enduser egal, vielleicht auch zu Recht, denn den Endusern sind ja auch die Entwickler egal!
Und ich behaupte, es gibt Entwickler, die möglichst viele Programme haben wollen, die sie frei einsetzen können oder eben auch selbst weiterentwickeln. Sie wollen aber nicht, dass Firmen daraus "richtige" Projekte machen wollen. Für sie, ist das öffentliche Projekt das wichtigste und das einzig richtige.
Mit Religion hat das wenig zu tun. Die einen meinen halt, sie brauchen ein komplettes System, das sie beherrschen und einsetzen können, wie sie wollen, auch im Kontext einer Firma, die keine Open Source macht. Und die anderen brauchen auch so ein komplettes System, nur unter einer anderen Lizenz. Was die beiden wollen ist halt grundlegend verschieden.
Moralisch gesehen sind die Entwickler, die den öffentlichen Code über alles stellen, in der Lage, die ethisch überlegene Position zu behaupten. Es fehlte aber bisher der Nachweis, dass die anderen Entwickler minder viel für die Freiheit tun. Ich bin geneigt, BSD-Entwickler wie Theo oder Dillon ganz oben auf der Skala zu sehen.
Aber jetzt, wo Leute mit rein öffentlichem Code für grosse Firmen an Projekten vollzeit bezahlt arbeiten können, stellt sich die Frage, ob es die "richtigen" Projekte noch braucht. Selbst Firmen wie Oracle arbeiten fieberhaft daran, den Linux-Kernel mit ihren Techniken zu verbessern. Nicht zu vergessen, HP, IBM, Redhat, Novell, etc.
Ich würde davon sprechen, dass dem "öffentlichen" Code eine Konvergenz der Ziele gelungen ist, jedenfalls für Entwickler. Meine Prognose ist, dass zunehmend Firmen sich von der Idee verabschieden werden, Systeme zu kontrollieren. Sun und Microsoft sind die beiden, die es noch lange aushalten werden, es anders zu versuchen, Sun sogar mit Aussicht auf langfristigen Erfolg.
Das hat nichts mit "Lizenzen ignorieren" zutun! Aktuell enthalten (anscheinend) BSD-Distributionen GPL-Code und es stört keinen, also könnte es so bleiben und keine Lizenz wird verletzt. Das Entfernen beruht somit nicht auf inkompatiblen Lizenzen.
Von Anonymous Coward am So, 21. Oktober 2007 um 22:06 #
Linux hat einerseits eine breite Treiber/Featureunterstuetzung und manche Distributionen haben ein breites Software-Packete Spektrum andererseits aber, wie du schon bemerkt hast, ist nicht alles so einheitlich. Vorallem im Netzwerkbereich sehe ich das, z.B. Traffic-shaping mit iptables/tc ist vorallem scriptgesteuert oder dynamisch eine Qual. Mit pf geht das deutlich uebersichtlicher und komfortabler. Die WLAN-Konfiguration unter (Open)BSD scheint mir auch einfacher (viel habe ich da nicht gemacht, kein WPA, aber ath5k lief super. ;)). Ansonsten gibt es schon einige Packete installieren und updaten.
Das Release muss nicht neukompiliert werden, sondern kann bei FreeBSD binär aktualisiert werden. Dank höherer Qualität sind selbst Neukompilierungen des Systems nur selten bis gar nicht notwendig (mit ccache und durchschnittlichem Dualcore in knapp 25min durchziehbar) . Die Ports werden auf Servern in der Regel binär eingespielt, diejenigen die dauernd das neueste möchten kompilieren eben. Heutzutage kein Akt und mit ccache etc. kein Aufwand.
>Was aber für Linux spricht: bei Linux gibts eine größere Community, insofern breitere Unterstützung bei Problemen
Bei einem System das Qualität und Sicherheit derart schleifen lässt auch kein Wunder. Die Story vom Frickelsystem wurde doch erst durch Linux aufgebracht, UNIX hatte nie diesen Ruf.
Warum unterschiedliche Projekte, so unterschiedlich stark von Open Source Aufschwung profitieren. Warum gibt es kaum Firmen, die ihren Geschäft auf *BSD aufbauen würden. Liegt es an der Licenze oder an den Leuten, die diese Projekte leiten?
Wenn die Licenze schuld sein soll, warum gibt es so was wie HURD mit der richtigen Licenze und theoretisch "besseren" Architektur und trotzem ist HURD höchstens zum Witzereisen gut geeignet?
Warum sind so viele User und Entwickler mit Linux Kernel unzufrieden und trotzdem marschieren alle brav hinterher?
K.A.! Wahrscheinlich an beidem und noch viel mehr!
>Wenn die Licenze schuld sein soll, warum gibt es so was wie HURD mit der
>richtigen Licenze und theoretisch "besseren" Architektur und trotzem ist
>HURD höchstens zum Witzereisen gut geeignet?
Naja, _man_ sagt ja, Mikrokernel ganz toll, aber auch sehr kompliziert...
>Warum sind so viele User und Entwickler mit Linux Kernel unzufrieden und
>trotzdem marschieren alle brav hinterher?
Das es _so_viele_ sind, ist nicht bewiesen.
cu
cu
Jupp und mit diesem angeblich schlechten Code und der fehlenden Doku, hat Windows trotzdem mehr Verbreitung als Linuy ...
was sagt das über Linux aus?
Bastel dir deine Welt, wie sie dir gefällt, aber glaube nicht du wärst der Mittelpunkt des geballten Wissens, wie
an deiner Argumentation gesehen!
Versteh ich nicht, hurd ist doch nächstes Jahr fertig...
Bei der BSD Lizenz muß man nur die Copyrightinformationen im Quelltext beibehalten. Ansonsten kann man machen was man will. Daher können Firmen Eigenentwicklungen unter Verschluß halten. Oft ist es aber so das durchaus etwas an die *BSD Entwickler zurückgegeben wird da die Firmen den Aufwand einer ständigen Pflege scheuen.
Bei der GPL muss der Quelltext offen bleiben. Daher ist es auch viel offensichtlicher wenn eine Firma Linux einsetzt, da sie ja den Quelltext veröffentlichen muß.
NetBSD wird z.B. sehr oft in Storagesystemen eingesetzt ohne das man was davon mitbekommt. FreeBSD wird von vielen Providern im Hintergrund als Server eingesetzt ohne viel Trara darum zu machen und OpenBSD in Firewalls.
Und es war die Apache Foundation, die ein Java geschaffen hat, dass so gut war, dass es Sun zum Handeln gezwungen hat. Wenn ich es recht verstehe, verwendet der gcj zumindest ihren Parser als Frontend, da er schon lange Java 1.5 (generics, etc) kann. Das GPL Java Projekt ist an der Stelle nicht weit gekommen.
Denn, die ursprüngliche Frage betreffend. Am Ende des Tages entscheiden über den Erfolg eines Projektes:
a) Die Qualität des existierenden Codes
b) Die Offenheit der Community
c) Wer zuerst kommt
zu c) Die BSD-Unixe waren zwar zuerst da, hatten damals aber bei ihrem SCO-Problem (AT&T) einen kompletten Stillstand über Jahre wegzustecken. Zeit für Linux. Ohne dieses Problem wäre Linus heute vermutlich mit einem BSD Unix auf seinem Rechner unterwegs. Er hatte damals ja nur Minix, was ihm nicht gut/offen genug war.
zu b) Die BSD-Community gibt ihren Code frei. Im Projekt darf aber nicht jeder einfach alles tun. Im Code eines anderen einfach was zu ändern, gilt als unfein, solange dieser es selbst machen will. Viele solche Situationen sind damit geendet, dass Änderungen nicht akzeptiert, aber auch nie richtig gemacht wurden. Linux 0.95 war da offen für alle.
zu a) Die Qualität des Codes sprach für BSD auf eine Weise. Aber Linux konnte ohne Floating-Point Coprozessor und ohne SCSI-Disk mit billiger IDE-Hardware laufen. Das war die entscheidende Qualität für die grosse Masse an Hardware-Besitzern.
Aber NetBSD wird immer mein erstes Unix bleiben, auf dem Amiga damals. Damals war Linux noch ein Gerücht. :)
Gruss,
Kay
Echt? Warum hatn dann OpenJDK die gleiche Lizenz wie GNU Classpath und nicht die von Apache Harmony?
> Wenn ich es recht verstehe, verwendet der gcj zumindest ihren Parser als Frontend, da er schon lange Java 1.5 (generics, etc) kann.
GCJ benutzt ECJ. Der kommt vom Eclipse Project.
Für Java hat Sun mit Absicht (so understelle ich!) die GPL gewählt, weil diese aus Sun-Sicht das kleinere Übel darstellt und verhindert, dass Harmony sich auch nur eine Zeile Code leihen könnte, ohne eine für Apache inakzeptable Lizenz zu nehmen.
Die GPL gibt einer Firma eine ziemlich starke Kontrolle, wenn die alleiniger Copyright-Holder ist. Siehe auch Qt. Darum ist sie die natürliche Wahl für Projekte, die eine Firma alleine stemmen will. Bei Sun sind das OpenOffice, OpenSolaris und OpenJDK. Unter der Apache Lizenz hat keiner irgendeine Kontrolle. Das wollen alle ausser Sun.
Gruss,
Kay
Das ist mehr oder weniger kompletter Blödsinn.
https://www.bsdwiki.de/Geschichte - lesen bildet.
>Im Projekt darf aber nicht jeder einfach alles tun.
Ebenfalls Blödsinn. Linus kloppt seit Beginn jedem auf die Finger der Amok läuft, bei BSD macht dies die Mehrheit der Entwickler und das *gewählte* Core-Team gibt die Richtung vor. Also nichts Diktatur, nur ne Menge FUD seitens Linux.
>Ohne dieses Problem wäre Linus heute vermutlich mit einem BSD Unix auf seinem Rechner unterwegs.
Er hätte es damals auch haben können, wenn er nicht dem FUD geglaubt und sich besser informiert hätte. Gut es gab noch kein Internet mit der breiten Info-Basis, aber wie man hier sieht halfs auch nicht wirklich :-)
Also bitte, weniger Unfug das nächste mal und mehr Wissen. Das war wohl jetzt ein Lektion in geschichtlichem Amoklauf?
Und oft beobachtetes Fakt ist, dass bei BSD gerne mal Teile des Codes komplett einem einzigen Maintainer anvertraut waren. Den musste man fragen, so gehörte sich das. Die Geschichte des Theo Deraadth (http://en.wikipedia.org/wiki/Theo_de_Raadt) ist da beredtes Zeugnis. Sein OpenBSD wurde gegründet, weil NetBSD nicht offen war. Und übrigends wurde Theo weder gewählt, noch abgewählt, sondern vom Core-Team ausgeschlossen. Es ist oft passiert in der BSD Historie, dass Änderungen nicht aus technischen, sondern aus personellen Gründen abgelehnt wurden. Der Maintainer wird in der Regel diejenigen mit Patches solange warten lassen, bis er selbst soweit ist. Es wurden hier schon prominente BSD-Entwickler mit solchen Aussagen zitiert?!
Bei Linux ist seit jeher Niemandes Code heilig, alles ist rein zufällig, da es kein stabiles System gibt. Von jedem werden Patches akzeptiert, wenn sie sinnvoll erscheinen. Wer nicht mithalten kann, fällt raus. Auch hier werden Entscheidungen aus personellen Gründen gefällt, siehe Con neulich, wenn man Entwicklern nicht recht traut, und das Thema nicht wichtig ist. Aber in der Regel geht es nie darum, dass jemand seinen Code beschützen darf. So wird z.B. gegen den Willen des x86 Maintainers gerade x86 mit x64 gemerged. Da hat jemand keine Macht über "seinen" Code mehr, nur ob er den dann noch weiter supported.
Und BSD _konnte_ Linus nicht haben, da er keinen SCSI-Controller hatte, ganz einfach. Ohne diesen hätte Linus nicht mal versuchen können, den Treiber für IDE entwickeln können, da ohne diesen BSD nicht installierbar war. Viele seiner Mitstreiter (er selbst?) hatten keine FPU und ohne das ging BSD damals erst recht nicht. Es war überhaupt nicht denkbar, BSD auf minderwertiger Hardware (sprich DOS-Boxen) zu verwenden.
Und Linus war sicher gut genug informiert, denn das Internet gab es auch schon vor dem WWW.
Ich weiss aus Erfahrung, dass "Unfug" und "FUD" auch nur Ersatzworte für "will ich nicht glauben", "es kann nicht wahr sein, was nicht wahr sein darf" sind. Mir würde es auch helfen, wenn Du in Argument-Form formulierst.
Gruss,
Kay
Zum nachlesen der kompletten BSD-Geschichte empfehle ich:
Kostenlos und überlegen
von Peter Wayner
und wenn Du das gelesen und verstanden hast, können wir uns hier gerne wieder unterhalten.
Ab einem gewissen Verbreitungsgrad wird es dann ein Selbstläufer.
Alternative freie Webserver wie z.B. Lighttpd, Cherokee oder thttpd sind eher Spezialisten als Alleskönner. Ich verwende z.B. den Lighttpd gerne wenn auf dem Server nur eine begrenze Anzahl an Seiten läuft und nichts spezielles benötigt wird oder nur eine begrenzete Menge Resourcen (z.B. auf VServern) zur Verfügung steht.
Im Massenhosting sind diese Webserver fast nicht einsetzbar.
Nicht etwas weil sie schlechter als der Apache wären aber die Leute erwarten das z.B. die .htaccess Dateien mit den mod_rewrite Anweisungen bei ihrem Blog, CMS oder Webshop läuft.
Zudem ist auch oft Unkenntnis ein Faktor. Die meisten kennen diese Alternativen garnicht.
Aber warum auch was anderes als Apache nehmen? Was vor 7 Jahren auf alter Hardware schon gut genug war, ist heute sicher nicht zu fett, oder?
Gruss,
Kay
z.B. bricht der Apache bei vielen gleichzeitigen Anfragen von der Leistung her ziemlich stark ein. Da baut sich leicht ein Stau an Anfragen auf.
Der Lighttpd hingegen ist da viel belastbarer und liefert auch bei vielen gleichzeitgen Anfragen die Daten entsprechend flott aus.
Auch der Speicherverbrauch von Lighttpd ist wesentlich geringer als der vom Apache. Dadurch kann der gleiche Server mehr Prozesse verkraften.
Dafür hat der Lighttpd bei weitem nicht die Fähigkeiten vom Apache.
Allerdings gibt es dafür einige Spezialgebiete die der Lighttpd hat. z.B. das Modul mod_flv_streaming das wohl von YouTube mit entwickelt wurde und von diesen auch massiv im Backend von YouTube eingesetzt wird.
Auch Wikipedia setzt in einigen Bereichen auf den Lighttpd.
danke für den Hinweis, schon interessant. Im allgemeinen liegen die Vorteile wohl bei grossen Dateien, vielleicht finde ich ja mal ne Verwendung dafür. :-)
Gruss,
Kay
Letzendlich bleibt die Frage ist nicht die BSD-Lizenz noch freier als die GPL, weil Sie wirklich jedem die Freiheit gibt damit zu tun was man will. Oder ist die GPL freier, weil Sie eine Firma zwingt die Quellen zugänglich zu machen? Das ist Ansichtsache. Man sollte erwähnen, das Firmen die sich bedienen, grundlegend ein Interesse haben gewisse Features upstream ins Projekt zu bekommen, weil Sie sonst sehr aufwendig neben der Innovation, die im Projekt selbst geschieht, selbst Ihre Sachen "nebenher" pflegen müsssen.
Wo ist denn da noch eine Frage offen?
Das ist Ansichtsache.
Keinesfalls!
In einem Lager, Reservat oder Knast ist man freier als "Draußen"? Man wäre ja zumindest unter Gleichen... das gibt einem schon etwas Beruhigung und die Zäune, Wälle oder Mauern schützen Dich ja vor den Bösen jenseits des NonGPL-Schutzwalls... man mauert sich glatt noch freiwillig ein, wenn das propagierte Feindbild gräusig genug erscheint...
NATÜRLICH ist die GPL unfreier als die BSD-Lizenz, denn GPL bedeutet eingesperrte Freiheit, wie im Reservat, weil GPLler glauben, daß man ihnen was wegnimmt, wenn sie sich nicht selbst einmauern. Außer für das gute Gefühl im Bauch beim Aufgeben der zuvor vorhandenen Freiheit spielt es keine Rolle, daß der GPLer sich dafür selbst freiwillig eingemauert hat: Mauer ist Mauer und das Freiheitsgefühl innerhalb dieser Mauer ist purer Selbstbetrug!
Die GPL paßt prima zur Paranoia der derzeitigen Politik und ich bin schon gespannt, wieviel härter GPLv4 wird...
Daß man bei dieser "Freiheit in Schutzhaft" überhaupt von Freiheit reden darf, ist mir ein ständiger Quell von Verwunderung!
Btw: dir ist es auch nicht erlaubt einfach einen Menschen zu töten. Ist jetzt eine Gesellschaft, die das Töten von Menschen erlaubt, "besser" nur weil deine persönliche Freiheit größer ist?
Absolute Freiheit ist etwas für Egomanen und hilft der Gemeinschaft überhaupt nicht. Wo das gesunde Mittelmaß ist, ist immer die Frage.
zum Thema Microkernel:
im Moment sind diese noch nicht so in Mode, hängt auch leider mit der "geistigen" Flexibitität der Programmierer zusammen, das geht nicht so schnell. Aus akademischer Sicht sind Microkernel den aktuellen monolytischen Kerneln vorzuziehen. Auch Linux ist mit seinen nachladbaren Modulen ein monolytischer Kernel.
An der Informatik-Fakultät in Dresden gibt es Projekte, welche die selbe Sytemsicherheit mit weit weniger Code bei Microkerneln erzielen als SELinux mit dem Linuxkernel. Insgesamt ist es wesentlich weniger Code, dadurch wird es auch übersichtlicher. Man muss allerdings zwischen akademischer und industrieller Welt unterscheiden.
Die Industrie interessiert sich leider nicht dafür.
Und die Dresdener sind so dumm nicht...
schönen Sonntag noch
PS > Warum sind so viele User und Entwickler mit Linux Kernel unzufrieden und trotzdem marschieren alle brav hinterher?
Macht der Gewohnheit, Langsamkeit der Masse
http://www.educ.umu.se/~bjorn/mhonarc-files/obsolete/ ist das klassische Beispiel dafür. Interessanterweise hat in all den Jahren niemand in der Industrie den vermeintlichen Vorteil für sich entdeckt und es blieb bei dem ewigen Mantra "ist überlegen" in akademischen Kreisen. Gäbe mir langsam mal zu denken.
> Man muss allerdings zwischen akademischer und industrieller Welt unterscheiden.
Das ist es eben. Akademiker brauchen sich erstmal an der Realität nicht orientieren, Praktiker schon. Und beides ist auch gut so.
Windows ist kein Mikrokernelsystem und weil bei MacOS X fast alles was irgendwie wichtig ist im BSD-Kern läuft, der wiederum auf dem Mach-Mikrokernel läuft, würde ich es auch nicht Mikrokernelsystem nennen.
Windows NT hatte einen Microkernelmäßigen Ansatz, da aber Treiber auch in den Kernelspace geladen werden ist es kein reiner Microkernel.
> Mac OS, hat ein BSD als Unterbau.
Das Konzept hinter einem Microkernel ist, daß man alle Treiber in den Userspace auslagert. Große Probleme gibt es bei der Kommunikation zwischen dem Kernel und den Treibern, da dort noch eine Zusatzschicht als "Übersezter" arbeitet.
Sich mal auf den OS-Seiten der Dresdner Informatiker herum zu treiben lohnt sich.
Ein Fiasko-Kernel ist nur noch ca. 3 Prozent langsamer als ein 2.6er Linuxkernel, auf gleicher PC-Hardware selbstverständlich vorausgesetzt. Und um das System vergleichbar wie ein SELinux abzusichert braucht man viel weniger Code, da fast nichts im Kernelspace läuft.
schönen Sonntag
1992: "True, linux is monolithic, and I agree that microkernels are nicer. [...] If the GNU kernel had been ready last spring, I'd not have bothered to even start my project: the fact is that it wasn't and still isn't." (Linus Torvalds)
2007: siehe '1992'
Aber: Linus hat ursprünglich auch nicht geplant, den Kernel jemals auf andere (non-i386) Architekturen zu portieren; wenn der Bedarf besteht und die Vorteile die Nachteile überwiegen, wird immer mehr Funktionalität in den user space verlagert werden, egal, ob Linus das will oder nicht.
Doch, es gibt z. B. QNX Neutrino, und auch Microsoft forscht an einem Microkernel-System namens Singularity.
Weil die HURD-Architektur ganz einfach schlecht ist. Der verwendete Mach-Microkernel hat große Performance-Probleme bei der Interprozesskommunikation, welche bei einem Microkernel-System extrem wichtig ist. Es gab und gibt wohl einige Bemühungen, Hurd auf andere Microkernel zu porten (L4, Coyotos und zuletzt ein eigener Microkernel von Marcus Brinkmann: http://mrhurd.no-ip.org/hird/Main_Page), aber keiner scheint so richtig zu wissen, in welche Richtung das ganze geht, und parallel wird auch noch der Mach-Hurd weiterentwickelt. Das ist heilloses Chaos.
Was aber für Linux spricht: bei Linux gibts eine größere Community, insofern breitere Unterstützung bei Problemen, Neuentwicklungen, Treibern, usw. In Linux ist bspw. auch schon sehr viel Geld von Unternehmen geflossen die bestimmte Kernelbereiche optimiert haben.
Wenn Du aber meinst wieso zu Beginn dieser Projekte sich Linux gegenüber anderen Unixen behaupten konnte: das ist wohl eher keine technische Frage sondern lag IMHO an den Leuten die beteiligt waren. Linus Torvalds konnte anscheinend in relativ kurzer Zeit Entwickler begeistern sich ihm anzuschließen ...
So könnte man aber auch den Gebrauch von Windows schönreden...
1.) Der Linux- Kernel hat einen grundlegenden Bug, der nicht ohne weiteres korrigiert werden kan: und zwar die Philosophie des monolithischen Kernels und fehlenden stabilen API. Fast alle paar Stunden kommt eine neue Kernelversion raus, die meistens inkompatibel zu Vorgängern ist. Gut dass es noch nicht so viele Linux Nutzer in der Welt gibt, sonst würde uns bei Kernel- Kompilieren eine viel größere Öko- Katastrophe drohen.
2.) Treiber- und Softwareentwickler sowie normale User müssen viel überflüssiger arbeit leisten. Anstatt nur die verbugte Datei auszutauschen, wird ein neuer Kernel installiert, wobei nicht selten kernelnahe Software wie udev u.s.w., alle möglichen Treiber sowohl freie als auch nicht freie und sogar die, die im Kernel drin sind, Virtualisierungslösungen wie Vmware, Virtualbox, u.s.w., ihren Dienst einstellen.
Natürlich versuchen Distributoren viele diese Mankos auszugleichen, aber wenn Linus nicht so stur wäre, hätten viele Leute sehr viel weniger Kopfschmerzen und die ganze stupide Arbeit wäre überflüssig.
zu 1) Es ist Dir natürlich klar, dass zur Zeit nur alle 3 Monate ein neuer Kernel erscheint. Und dass den weniger als 1% der Linux-User compilieren werden. Dass den dann so keiner ausführt, sondern eher das abgeleitete Produkt von RHEL oder Ubuntu, das viel seltener ein Update erfährt, reduziert das "Problem" weiter. Von denen haben die User die Garantie und die Unterstützung, die Ihnen die Entwickler nicht geben können und wollen und auch nicht müssen.
zu 2) Normale User installieren nur fertige Systeme und tauschen dort nur den Kernel gegen minimal veränderte Versionen aus, in denen nur Bugfixes enthalten sind. Das gilt inzwischen auch für mich, vor Jahren habe ich immer noch selbst gebaut, um für schwache Hardware (immer zuwenig RAM) zu optimieren, aber jetzt lohnt sich das nicht mehr. Beachte hierzu die "stable" Kernelserie, die dazu dient, unter den Distributoren das Wichtigste gemeinsam zu verfolgen.
Das gute an der Sache ist die Geschwindigkeit mit der sich Linux verbessert. Und viele der angeblichen Opfer schätzen Linux sehr. So ist IBM nicht alleine darin, ihr Unix zugunsten von Linux aufzugeben und spart sich Unmengen. Nur diejenigen, die das falsche tun wollen oder müssen, nämlich mit ihrem Code ausserhalb von Linux zu leben, habe Probleme damit.
Und udev darfst Du nicht nennen, weil ein Kernelupdate ohne libc-Update und ohne udev-Update nicht korrekt ist. Aber das macht Ubuntu für mich schon... :-)
Gruss,
Kay
Und wenn ich jetzt den Distributionskernel durch den aktuellen Vanilla-Kernel ersetze, weil ich z.B. bestimmte Treiber benötige, dann kann ich mit Sicherheit sagen, dass mindestens Nvidia Treiber und Vmware Server ohne neuen Kernelmodule versagen. Weitere Problem sind nicht ausgeschlossen.
Wenn ich nur nur den passenden Treiber austauschen könnte, hätte nicht nur ich viel weniger Probleme.
Andreas Coward
Richtig kompiliert, kannst du hier ganz einfach deine Module vom vohrerigen Kernel nutzen, sprich 2.6.21.1 - 2.6.21.x . Des weiteren, ist es doch eigentlich immer so, dass hier so exotische Sachen gefixt werden, die nur ganz wenig Leute betreffen. Guck dir mal Änderungen darin an, betreffen dich die jedesmal?
>>>Und wenn ich jetzt den Distributionskernel durch den aktuellen Vanilla-Kernel ersetze, weil ich z.B. bestimmte Treiber benötige, dann kann ich mit Sicherheit sagen, dass mindestens Nvidia Treiber und Vmware Server ohne neuen Kernelmodule versagen. Weitere Problem sind nicht ausgeschlossen.
Also ich nutze seit Jahren immer den aktuellsten Vanilla Kernel, die paarmal in denen der aktuellste Nvidia Treiber nicht kompilierte kann ich an der Hand abzählen.
Vanilla Kernel sind ja eh eigentlich was für Bastler, genauso wie ein Detonator etc.
Aehm, die Systemcalls aendern sich doch nicht soo haeufig.. bis jetzt habe ich immer ganz gut mit reinen Kernelupdates gelebt.
Debian/NetBSD wäre ein Debian-Port und kein NetBSD. Es wäre nett, wenn Debian sich so vom Linuxkernel emanzipieren könnte und dafür ad hoc 50 Plattformen gewinnt, aber es würde NetBSD wenig beeinflussen, wenn dies geschähe.
Alle großen BSDs planen, langfristig frei von GPL-Code zu werden und das ist auch gut so!
Aber tut man das nicht, schränkt Einen die BSDLizenz deutlich weniger ein. Ich sehe darin wahrlich mehr als eine praxisirrelevante quasireligiöse Frage.
Die anderen als religiös zu diffamieren (was ja auch nur in Deutschland funktioniert, in den USA sind Atheisten nicht gesellschaftsfähig) ist einfach und effektiv, besagt aber nichts. Man sollte sich lieber über die Ziele unterhalten, und die sind sicher nicht, in den Himmel zu kommen.
Ich behaupte, es gibt Entwickler, die nur untereinander Code tauschen wollen und dies als Sprungbrett sehen, um in richtigen Firmen auch mal richtige Projekte umzusetzen, wo dann auch Vollzeit bezahlt wird. Die BSD-Entwickler haben aus meiner Sicht kein Problem damit, Neuland zu erforschen, auch wenn Firmen wie Apple den Code für sich behalten wollen. Diesen sind die Enduser egal, vielleicht auch zu Recht, denn den Endusern sind ja auch die Entwickler egal!
Und ich behaupte, es gibt Entwickler, die möglichst viele Programme haben wollen, die sie frei einsetzen können oder eben auch selbst weiterentwickeln. Sie wollen aber nicht, dass Firmen daraus "richtige" Projekte machen wollen. Für sie, ist das öffentliche Projekt das wichtigste und das einzig richtige.
Mit Religion hat das wenig zu tun. Die einen meinen halt, sie brauchen ein komplettes System, das sie beherrschen und einsetzen können, wie sie wollen, auch im Kontext einer Firma, die keine Open Source macht. Und die anderen brauchen auch so ein komplettes System, nur unter einer anderen Lizenz. Was die beiden wollen ist halt grundlegend verschieden.
Moralisch gesehen sind die Entwickler, die den öffentlichen Code über alles stellen, in der Lage, die ethisch überlegene Position zu behaupten. Es fehlte aber bisher der Nachweis, dass die anderen Entwickler minder viel für die Freiheit tun. Ich bin geneigt, BSD-Entwickler wie Theo oder Dillon ganz oben auf der Skala zu sehen.
Aber jetzt, wo Leute mit rein öffentlichem Code für grosse Firmen an Projekten vollzeit bezahlt arbeiten können, stellt sich die Frage, ob es die "richtigen" Projekte noch braucht. Selbst Firmen wie Oracle arbeiten fieberhaft daran, den Linux-Kernel mit ihren Techniken zu verbessern. Nicht zu vergessen, HP, IBM, Redhat, Novell, etc.
Ich würde davon sprechen, dass dem "öffentlichen" Code eine Konvergenz der Ziele gelungen ist, jedenfalls für Entwickler. Meine Prognose ist, dass zunehmend Firmen sich von der Idee verabschieden werden, Systeme zu kontrollieren. Sun und Microsoft sind die beiden, die es noch lange aushalten werden, es anders zu versuchen, Sun sogar mit Aussicht auf langfristigen Erfolg.
Gruss,
Kay
Ansonsten gibt es schon einige Packete installieren und updaten.
Andreas Coward
Das Release muss nicht neukompiliert werden, sondern kann bei FreeBSD binär aktualisiert werden. Dank höherer Qualität sind selbst Neukompilierungen des Systems nur selten bis gar nicht notwendig (mit ccache und durchschnittlichem Dualcore in knapp 25min durchziehbar) . Die Ports werden auf Servern in der Regel binär eingespielt, diejenigen die dauernd das neueste möchten kompilieren eben. Heutzutage kein Akt und mit ccache etc. kein Aufwand.
>Was aber für Linux spricht: bei Linux gibts eine größere Community, insofern breitere Unterstützung bei Problemen
Bei einem System das Qualität und Sicherheit derart schleifen lässt auch kein Wunder. Die Story vom Frickelsystem wurde doch erst durch Linux aufgebracht, UNIX hatte nie diesen Ruf.
lg. Trächtige Tröllin