"Now that OpenSolaris is dead..."

nakal

Anfänger
Habt ihr das mitbekommen wie Pawel Jakub Dawidek OpenSolaris in einem -CURRENT-Thread kommentiert hat?

Now that OpenSolaris is dead we don't have to be so strict with keeping the diff against vendor small at all cost. I'd prefer not to modify vendor code whenever possible so it is easier for us to cooperate with IllumOS (we already took ome code from them).


Vollständige E-Mail ist hier.

Naja gut, man könnte sagen "das hätte man kommen sehen können", aber ich bin irgendwie trotzdem erstaunt, dass sich auch FreeBSD von Oracle abwendet. Vor allem pjd sagt es so einfach geradeaus ohne irgendeine Vorwarnung.

Weiß jemand auf welcher Version von ZFS IllumOS gerade aufsetzt? Sind sie weiter als ZPool v28?
 
Die hinken immer etwas hinterher. Das wird mal sowas wie CentOS. Einer machts vor was dann nachgebaut wird. Es sei denn Oracle lässt diese Träumerei platzen.
 
Es fehlt halt der Quellcode der Neuentwicklungen für Solaris 11. Und die kommen ja erst mit garantiert merklicher Verzögerung ...

Und Illumos ist bezüglich ZFS auf dem Stand der letzten verfügbaren OpenSolaris-Sourcen (also ZFS 28) ...
 
Und ich dachte noch hätte Openindiana die Nase vorn:
www.zfsbuild.com/2010/10/11/openindiana-benchmarks/

In Zukunft wird sich wohl zeigen, ob oi nur nachbaut bzw den verzögert veröffentlichen Solaris Quellcode einbaut oder ob die Entwicklungen auseinander gehen. Noch heißt es ja, das oi/ilumos kompatibel zu Solaris sein sollen. Das muss aber nicht so bleiben...
 
Zuletzt bearbeitet:
Es hat sich aber schon öfters gezeigt, dass kommerzielle Projekte viel schneller und innovativer entwickeln als die Leute, die sich an OpenSource-Varianten beteiligen. Das ist natürlich keine generelle Aussage.

Schlecht ist schon mal, dass das Projekt in 2 Splitter zerfallen ist. Ich glaube nicht, dass die Community groß genug ist für nur einen solchen OpenSource-Fork und dann halbieren sie sich auch noch.

Ausm Wunschdenken allein wird OpenSolaris auch nicht sterben. Denn an Oracle werden Unsummen an Lizenzgeldern nun gepumpt. Die Preise für ex-Sun-Software-Lizenzen wurden drastisch erhöht und werden aber trotzdem noch bezahlt. Und das wird noch eine Weile dauern wegen "never change a running system".
 
Neues von ZFS wird ja erst beim nächsten Release von Solaris freigegeben.. davor kann niemand neueres haben.
 
Soweit ich informiert bin, ist die Sache mit OpenSolaris gelaufen. Oracle veröffentlicht da aktuell keinen Quellcode mehr in irgendwelchen öffentlichen Repos und wenn er eines Tages vielleicht doch noch kommen sollte (ich habe da noch meine Zweifel) wird es sicher ein simples Source-Archiv sein. Sowas komplexes wie ZFS allein mit vimdiff oder etwas ähnlichem zu mergen, ist bestenfalls widerlich. Man bräuchte da schon eine Revisions-Historie... Man will nun wohl enger mit IllumOS zusammenarbeiten, wie pjd@ ja auch schreibt. Die haben im Prinzip das gleiche Problem.

Ich sehe es kommen... ZFS geht es nun so, wie vor knappen 20 Jahren UFS / FFS. Die einst gemeinsame Basis zerfällt, es wird in Zukunft mehrere wahrscheinlich zueinander inkomaptible Derivate geben. D.h. man kann ein FreeBSD- und Illumos-ZFS nicht problemlos auf Solaris nutzen und umgekehrt. Bei Linux könnte es noch krasser werden, fuse-zfs wäre zu dem "echten" Blob-ZFS inkompatibel. Besonders schön wird es dann, wenn sich die einzelnen Zweige auch noch in Sachen Features zu unterscheiden beginnen.

Für FreeBSD wird es zumindest nach der Veröffentlichung von 7.4 und 8.2 - man wollte dort -CURRENT zu den -STABLEs erst einmal kompatibel halten - erst einmal ZFSv28 geben, was ja auch schon länger in Form von Patches durch das Netz fliegt. Wie es dann weitergeht, weiß ich nicht. Wird man also abwarten müssen.
 
Ja, wenn btrfs dann endlich mal stable ist. Außerdem bin ich mir nicht sicher, ob es dann auch Bestandteil der BSDs wird, eben auch wegen der GPL ... (fragend in die Runde schauend)
 
Ja, wenn btrfs dann endlich mal stable ist. Außerdem bin ich mir nicht sicher, ob es dann auch Bestandteil der BSDs wird, eben auch wegen der GPL ... (fragend in die Runde schauend)

Selbst ohne GPL, müßte man es erst einmal portieren. Und dies setzt auch ein entsprechendes Knowhow voraus. Bei Linux gibts ja schnell das Prädikat "stable", auch wenn dem nicht unbedingt so ist.
 
Obwohl man natürlich auch sagen muss, dass es nicht Oracle's Schuld ist, wenn es gleich zwei Freie Forks gibt, die sich nicht einigen, plus FreeBSD, dass sich nicht mit denen einigt (aus der Nachricht hört es sich nicht so an, als wollten sie sich auf was gemeinsames verpflichten). Genauso wie niemand außer den BSDs Schuld ist, dass diese unterschiedliche UFSe und Partitionsschemata verwenden.

Überhaupt ist zwischen den BSDs Synergie glaube ich ein Fremdwort ;) Nur DfBSD gibt sich Mühe -- was sie ja auch irgendwie machen müssen um Beduetung zu erlangen.

Bezüglich Linux_ZFS muss ich aber nochmal was fragen, was mich schon lange beschäftigt:
Linux integriert Solaris-ZFS-Kernelteil nicht, da dieses CDDLed ist. FreeBSD hat aber doch auch nicht den CDDL-Code genommen, sondern die Kernel-Teile unter der BSDL neuimplementiert und nur den Userland-Code genommen, oder?
Wenn ja,
1) Warum konnte die Linuxer das nicht auch machen für Kernelteile?
2) Warum nehmen sie nicht einfach FreeBSDs Code, der ist doch GPL-kompatibel?
 
ZFS kommt wegen der CDDL nicht in den GPL Kernel

Wenn du unter Linux nativ ZFS nutzen willst kannst du gerne einer meiner Seiten besuchen. http://opensource.hojnik.de/ Dort ist schon ein fertig vorkonfiguriertes VMware Image zum Ausprobieren. Binary's gibt es als Alternative auch
 
Überhaupt ist zwischen den BSDs Synergie glaube ich ein Fremdwort ;) Nur DfBSD gibt sich Mühe

OT: ich musste hier kurz mal lachen :)

Rate mal wer wegen fehlender Synergie aus dem FreeBSD-Projekt rausgeflogen ist (ganz im Gegenteil zum Rest des Teams das synergisch und einstimmig entschieden hat) und jetzt als beleidigte Leberwurst einen FreeBSD-4.x-Fork eröffnet hat und ab und zu immer noch seinen Senf auf den FreeBSD-Mailinglisten dazu gibt.
 
ZFS kommt wegen der CDDL nicht in den GPL Kernel

Wenn du unter Linux nativ ZFS nutzen willst kannst du gerne einer meiner Seiten besuchen. http://opensource.hojnik.de/ Dort ist schon ein fertig vorkonfiguriertes VMware Image zum Ausprobieren. Binary's gibt es als Alternative auch

Du hast meinen Post nicht genau gelesen, mir ist klar, dass die CDDL nicht GPL-kompatibel ist. Deswegen kann in die Linux-Kernel nicht mit einem gegen sie gelinkten ZFS-Modul verteilt werden.
Dies trifft doch aber nur auf das Kernel-Modul zu (nicht auf Programme im Userland, die lediglich mit dem Kernel kommunizieren) und auch nur, sofern wirklich der Code von OSol benutzt wird.
Wenn FreeBSD den kompletten Kernel-Teil neugeschrieben hat (was ich dachte), dann müsste Linux doch diesen Code portieren können (denn er ist ja BSDlizensiert und damit GPL-kompatibel).

OT: ich musste hier kurz mal lachen :)

Rate mal wer wegen fehlender Synergie aus dem FreeBSD-Projekt rausgeflogen ist (ganz im Gegenteil zum Rest des Teams das synergisch und einstimmig entschieden hat) und jetzt als beleidigte Leberwurst einen FreeBSD-4.x-Fork eröffnet hat und ab und zu immer noch seinen Senf auf den FreeBSD-Mailinglisten dazu gibt.

Lol, nagut. Ein Fork ist natürlich per Definition Synergie^-1
Und auch aus Trotz nicht ZFS zu nehmen, weil FreeBSD das schon hat, ist auch nicht so synergetisch ;)
Aber daneben geben sie sich Mühe viel Code von anderen zu portieren, LVM, dm-crypt, udev sind ja schon beachtlich, auch wenns Synergie in ne andere Richtung ist.
 
Nur braucht FreeBSD HAMMER? Sicher wäre HAMMER schön zu haben, aber wie schon öfter gesagt ist es keinesfalls trivial zu portieren. HAMMER benötigt Änderungen am VFS, die Matt sich leisten konnte, da er keine Kompatiblität zu irgendwas einhalten musste... Vor allem ist da das 64-Bit ino_t, an dem mindestens ein FreeBSD-Entwickler nun schon beinahe ein geschlagenes Jahr lang die Zähne ausbeißt. Ich denke, dass der Zug dort erst einmal abgefahren ist. Man hat nun ZFS und wird es zur Not auch ohne Oracle weiterentwickeln, es ist ja auch weitgehend Feature-Vollständig. Dort umschwenken wird man wahrscheinlich nur noch, wenn sich entweder jemand freiwilliges für die Drecksarbeit meldet oder aber der Leidensdruck bei ZFS wider erwarten drastisch ansteigen sollte. Und ob es dann gleich HAMMER werden würde... Viele sind noch immer schlecht auf Matt zu sprechen. :)

Das was FreeBSD dateisystemtechnisch nun noch fehlt, ist im Prinzip ein "Dateisystem der Mitte". Auf der einen Seite haben wir UFS. Es ist gut und schön, seit Hauptproblem löst sich mit Journaled Softupdates, aber es ist auch alt und verlangt Überbauten in Form von z.B. Dir-Hashes. Seine Speicherplatzausnutzung ist auch nicht gerade optimal. Auf der anderen Seite gibt es ZFS. Fett, ressourcenfressend und sehr, sehr umfassend. Eigentlich eine Antwort auf alle Fragen, leider auch die, die nie gestellt wurden. Es wäre daher gut, wenn es etwas zwischen den Beiden geben würde. Halt ein modernes Dateisystem, was nur ein Dateisystem ist und nicht noch gleich Volumenmanager und sonst was... Zum Beispiel wäre dort XFS sehr interessant, wovon es ja bereits einen Port mit Alpha-Qualität gibt.
 
Ich persönlich finde den Groll gegenüber Matt Dillon unerträglich. Viele wissen gar nicht, was der Mann alles für die freie Softwarewelt geleistet hat. Angefangen bei seiner Mitarbeit an der ersten TCP-Implementierung unter Linux 1992. Später war er dann DER Guru von NFS und ganz besonders von der VM für FreeBSD und hat entscheidend dazu beigetragen, dass die 4.X-Serie von FreeBSD das stabilste Stück Software war, das jemals auf X86-Rechnern lief. Das DragonFlyBSD so belächelt wird, kann ich auch nicht verstehen. Matt Dillon ist einer der ganz wenigen Leute, die ohne Zweifel Experten auf ganz vielen Gebieten sind. Dateisysteme, VM, Netzwerk, Compiler um nur mal ein paar zu nennen...

Ansonsten gebe ich Yamagi völlig recht. ZFS ist nicht "the last word in filesystems", wie es Jeff Bonwick gerne gesagt hat. Grade BTRFS zeigt, dass sich gewisse Elemente mit B-Trees eleganter implementieren lassen. Damit will ich nicht sagen, dass BTRFS vergleichbar oder gar besser als ZFS wäre. BTRFS muss seine Qualitäten erst noch beweisen.

@Yamagi
Irgendwo hatte ich mal gelesen, dass Jeff Roberson ein "UFS3" plant, aber irgendwie finde ich die relevante Stelle jetzt nicht mehr. Jedenfalls hat er selber auch gesagt, dass ZFS nicht die Antwort auf alle Fragen ist.
 
Dillon war schon mit seinem Shareware-Compiler auf dem Amiga der Held und hatte sich dort einen Namen gemacht, falls sich noch einige daran erinnern können. Insofern betrachte ich Hammer, DFBSD & Co natürlich mit erhöhter Aufmerksamkeit ... der Mann hat Ideen und vermag sie auch umzusetzen.

Im Moment sieht man in FBSD viele Baustellen und zukünftige no-go-Areas, wie z.B. X und diverse Treiber. Ich hoffe die Filesysteme entwickeln sich nicht auch in diese Richtung, denn wie Yamagi schon bemerkte, es fehlt ein zeitgemäßes Filesystem, welches zwischen UFS und ZFS rangiert.
 
Allerdings sind die Probleme bekannt und man sucht Antworten und nicht nach Ausreden. Klar gibt es Baustellen, es wird ja auch gearbeitet. FreeBSD wird sich davon "erholen" und steht allgemein auch nicht so schlecht da. Es wäre ja nicht das erste Mal, dass ein BSD totgesagt wird und sich die Entwicklergemeinschaft Durchhaltevermögen unter Beweis stellt und sich den Weg nach vorne bahnt. Das ist ja auch ein Grund für die vielen treuen Anhänger, die BSD hinter sich weiß.

Wie sich die Sache mit ZFS auch entwickeln mag, FreeBSD wird sich davon erholen. Klar wird das viel Arbeit, aber man muss ja nur einen kurzen Blick in die Vergangenheit werfen um zu sehen, dass man schon größere Probleme hatte. Genau so, wie jedes andere Projekt sie auch hat.

Ich nenne jetzt mal keine Beispiele, weil ich denke, dass die meisten hier ohnehin bessere haben. Um UFS und ZFS, wie sie derzeit sind beneiden FreeBSD viele und bis man da mal aufschließt wird man sich sicherlich schon etwas überlegt haben.

EDIT: Der Beitrag etwas übertrieben formuliert. Wollte eigentlich nur sagen, dass man aus einer Mücke keinen Elefanten machen soll und dann tue ich es selbst :D
 
Wenn FreeBSD den kompletten Kernel-Teil neugeschrieben hat (was ich dachte), dann müsste Linux doch diesen Code portieren können (denn er ist ja BSDlizensiert und damit GPL-kompatibel).

Nee, der Code in FreeBSD basiert auf dem von Sun, und ist daher CDDL lizensiert. FreeBSD hat da keine Probleme mit.

Vor allem ist da das 64-Bit ino_t, an dem mindestens ein FreeBSD-Entwickler nun schon beinahe ein geschlagenes Jahr lang die Zähne ausbeißt.

Und ZFS braucht keine 64-bit inodes?
 
> FreeBSD wird sich davon "erholen" und steht allgemein auch nicht so schlecht da.

Ich glaube diese Art von Pathos kann man sich für osnews und Co aufsparen. Das war kein Abgesang auf FreeBSD, sondern eine schlichte Feststellung. Abgesehen davon kann man Durchhaltevermögen in den 90ern bzw. Ausdauer im unmittelbaren Postmillenium kaum mit heutigen Zeiten vergleichen. Die Entwicklung ist abermals rasanter, mehr oder weniger "eindimensionale" Anwendungen sind Geschichte, vieles ist eine Art moving target.

Nehmen wir Filesysteme, in heterogenen Umgebungen wird oftmals ein gemeinsamer Nenner bevorzugt anstelle der Abgeschiedenheit eines Systems. Es existieren noch zahllose andere Beispiele.

Der Elefant trampelt schon recht lustig umher, viele wollen es nur nicht hören. Ein positives Beispiel gänzlich anderer Natur ist meiner Meinung nach OpenBSD. Dort hat sich in den letzten Jahren in vielen Bereichen einiges getan, wovon sich auch FreeBSD eine Scheibe abschneiden könnte. "Politik" hat da einiges verhindert, wie z.B. die Übernahme des Sensor-Frameworks. Einer legte ein Veto ein, bis heute tat sich nichts mehr, während OpenBSD ein wirkliches Plus in diesem Bereich zu bieten hat. Ein System muß nicht unbedingt sterben, es kann sich auch auf Irrwege begeben und wird irgendwo bedeutungslos.
 
Zurück
Oben