FreeNAS/TrueNAS soll auf Debian portiert werden II

Lance

Well-Known Member
Quellen:

https://www.heise.de/newsticker/mel...Debian-GNU-Linux-portiert-werden-4679361.html

https://www.pro-linux.de/news/1/27858/truenas-soll-nach-debian-11-portiert-werden.html


Ich frage mich ob das am Ende in eine ähnliche Richtung geht wie Project Trident, auch wenn iX mit diesem nicht direkt zu tun hat, aber es war einer meiner ersten Gedanken. Ich weiss nur dass mir die Nachricht irgendwie nicht gefallen hat. Geht es euch da vielleicht ähnlich? Könnt ihr den Schritt von iX nachvollziehen?

LG Lance
 
ähnliche Richtung geht wie Project Trident
Das denke ich jetzt noch und dachte ich, als ich die Meldung vor ein paar Tagen las.

Sprunghaft war das/die Projekt(e) immer schon, nicht nur beim Namen. Hatte da immer gerne mal reingeschnuppert, wenn Zeit übrig war und ausprobiert, aber mir persönlich gefiel XigmaNAS irgendwie besser.
Ich denke, sie haben ihre Gründe. Erst Recht, wenn es nur um die ZFS-Geschichte geht.
 
Öhm, aus dem Blog-Eintrag:

The only thing changing is the name. FreeNAS will take on the name of “TrueNAS CORE”
[...]
The change in name does not change the underlying FreeBSD OS, the FreeBSD-based license, or our commitment to free and Open Source software.

Klingt für mich einfach so, als will man einfach nur die eigene Software an sich etwas portabler gestalten.
 
We're specifically making all the portable bits (middleware and UI) able to run on other OS's for future product(s). Right now we're working to port it to Debian 11 (Bullseye)
Das klingt für mich anders. Kris Moores Beitrag im Forum.
Vielleicht verkauft es sich besser wenn das Produkt Linux im Namen hat, weil Linux bekannter ist? Die beklagen ja im Blog, dass FreeNAS Pro nicht ernst genommen wird. Aber dann sollen die ihre Manpower auf FreeBSD fokussieren anstatt wieder neue Pfade (=Baustellen) einzuschlagen.
Diese ganze PCBSD/TrueOS/Lumina Geschichte einfach nur schlimme Erinnerungen...
 
Vielleicht verkauft es sich besser wenn das Produkt Linux im Namen hat, weil Linux bekannter ist?

Ich vermute andere Gründe aus eigener Erfahrung bei Kunden: viele Unternehmen setzen inzwischen ausschließlich auf Linux-Container als Plattform für den Betrieb ihrer (neuen) Anwendungen. Falls ein Hersteller das nicht leisten kann, hat er automatisch verloren.
 
Vielleicht verkauft es sich besser wenn das Produkt Linux im Namen hat, weil Linux bekannter ist? ...

Meines Erachtens zielt das in die Richtung, allerdings unter dem Aspekt, dass Linux (im gegensatz zu BSD) halt einfach mittlerweile "mainstreamiger" ist...

Die Entwicklung findet wohl jetzt direkt erst auf Linux statt, dann fliessen die Neuerungen über Ilumos zu FreeBSD, anstatt umgekehrt bzw gleichranging - bis 2017 waren Linux und FreeBSD quasi auf der gleichen Entwicklungsebene (siehe den Vortrag von Matt Ahrens, ist auf der OpenZFS Seite abrufbar, OpenZFS Developer Summit 2019, "State of OpenZFS", Seiten 11 u. 12).

Das war mir bis gestern auch neu, hatte die Entwicklung von ZFS seit den OpenSolaris/-Indiana/Nexenta/joyos und wie sie alle hießen-Zeiten (also vor Jahren) nicht mehr weiter im Detail verfolgt;

Hatte nur über die Jahre mit Wohlwollen gesehen, dass das ZFS auf FreeBSD recht weit gediegen war und es sich dort sehr wie in alten SUN Solaris 10 Zeiten angefühlt hat - unter dem Aspekt Handling und Stabilität; da war meines Erachtens Linux noch etwas weiter weg, zumindest hatte es mir ZFS auf Linux ein paar mal unrettbar zerlegt, auf FreeBSD Basis nie - aber meine Einzelschicksale sind natürlich kein Kriterium für irgendwas auf der Welt.

Die Code-Basis ist quasi die selbe in beiden Welten, Linux ist mehr Mainstream, da ist es vllt nur konsequent, das ganze Produkt auf Linux zu hieven - oder halt wirtschaftlicher auf lange Sicht? Wer weiß... wäre interessant gewesen, was in den Meetings dazu bei iX-Systems besprochen wurde und was schlußendlich der Grund zu dieser Entscheidung war.

Ich bin nur gespannt, wie iX - und auch Canonical z.B, die arbeiten ja auch grade an ner Integration von ZFS - es schaffen wollen, ZFS und den Linux Kernel in einem (quasi) kommerziellen Produkt zu vereinen - da ja die beiden Lizenzen (CDDL und GPL) unvereinbar bzw inkompatibel zueinander sind. Entweder müssten alle ZFS oder alle Linux Contributors ner jeweiligen Lizenzänderung zustimmen um das ein für alle Mal auf Lizenzebene gradezubiegen - was für beide schwierig bis unmöglich sein dürfte.
 
Entweder müssten alle ZFS oder alle Linux Contributors ner jeweiligen Lizenzänderung zustimmen um das ein für alle Mal auf Lizenzebene gradezubiegen - was für beide schwierig bis unmöglich sein dürfte.
das ist doch eher ein ideologisches Problem und es gibt dafür technische Lösungen, die natürlich durchaus umstritten sind, wie ZFS nicht im Kernel sondern außerhalb oder im Kernel derart virtualisiert, dass es quasi nicht mehr unter Linux läuft sondern innerhalb einer Box und so weiter.
Rein praktisch gesehen reden wir ja schon lange nicht mehr von ZFS, sondern von OpenZFS und das ist quasi gleich ZFS-on-Linux geworden. Ich könnte mir vorstellen, dass dieses Argument am stärksten wiegen wird und die CDDL-Beschränkungen einfach fallen werden. Immerhin hat Linux auch noch BTRFS und das hat sich auch ganz ordentlich entwickelt. Im Zweifel könnte ich mir vorstellen, dass man einfach ganz auf den CDDL-Code verzichtet und, wie das im Linux-Lager ja häufig passiert, einfach mal schnell was ganz Neues vom Zaun bricht.
Den Mut, die Unbekümmertheit, die Man-Power, den Eigensinn: all das findet sich ja im Linux-Lager.

Jedenfalls bin ich da auch schon recht gespannt, was da weiter passieren wird.
 
DEM Braten traue ich nicht! Canonical nimmt lieber ZFS und Red Hat fokussiert sich auf sein XFS.
Mit Oracle fang ich gar nicht erst an.

RedHat hat nen SW Hersteller für Deduplizierung gekauft und hat jetzt ne Software die für teures Geld das macht, was btrfs von sich aus kann - nämlich brauchbare out of band deduplication. Kurz darauf viel der btrfs Support ;)
Canonical will sich von Debian/RHEL/SLES abgrenzen und geht daher das rechtliche Risiko mit ZFS ein - Canonical hat den Sitz zudem nicht in den USA was da vielleicht auch besser ist.

Große btrfs-Nutzer: Facebook, Google, SAP, SLES (als größter Contributor derzeit).
Man darf bei dem Teil halt nicht blöd alle Features aktivieren die einem angeboten werden, sondern muss gucken was als Stable gekennzeichnet ist. Das diese Vorgehensweiße (alles in den Tools verfügbar machen und nicht wirklich kennzeichnen was experimental ist) kann man zurecht kritisieren.
 
Rein praktisch gesehen reden wir ja schon lange nicht mehr von ZFS, sondern von OpenZFS und das ist quasi gleich ZFS-on-Linux geworden.

Entwicklung primär auf Linux heißt aber auch "gcc als Compiler" (geh ich mal davon aus) - bei FreeBSD müsste dann sichergestellt werden, dass das mit llvm compiliert bzw 2 Code-Zweige (denn als Entwickler programmiert man ja eh nicht nach dem Sprach-Standard, sondern so wie es der Compiler gern haben möchte, gell :D) gepflegt werden.

Außerdem können sich bedingt durch die Entwicklung auf Linux Methodiken bzw Herangehensweisen eingeschlichen haben, welche es erstmal so nur auf Linux gibt - die müssten dann für FreeBSD erstmal zurechtgebogen oder gar simuliert werden?

Dann noch die Lizenzfrage CDDL gegen GPLv2...

Es bleibt erstmal spannend.

Und: den schlipstragenden Industrie-Keks-zum-fahlen-Industrie-Kaffee-Nehmern in den Meetingrunden der Unternehmen interessierts doch sowieso nicht, was im Unterbau auf irgendenm Server irgendwo im Keller oder irgendwo auf der Welt läuft. Hauptsache, die Zahlen stimmen und die IT kostet ned zuviel Geld. Linux? BSD? Wurscht! Kennt eh keiner Details bzw will damit belastet werden.
 
Persönlich finde ich den Schritt sehr schade, und es bedeutet für mich das diese Software wieder rausfliegt von meinem System.
Auch wenn es dann wieder heißt mehr Code zu schreiben (mit Ansible und co) um ein BSD basiertes NAS zu haben.
Ich hätte mir lieber gewünscht iX Systems hätte das Produkt erweitert um Features wie: Distributed Storage (mittels Ceph oder Gluster) und ARM based.
Vom Wirtschaftlichen Aspekt kann ich es verstehen, aber nicht ganz Nachvollziehen.
Wenn Ihnen die Kunden fehlen oder abspringen, dann sicher nicht wegen dem Kernel.
Denn die aktuellen NAS Systeme bietet fast alle die gleichen Features.
Und ob nun ein weiteres Linux basiertes NAS vom Publikum akzeptiert wird, nur weil es von FreeBSD kommt ?
Es gibt als schon zu viele Linux basierte NAS Systeme und alle sind annähernd gleich.
 
Fände es persönlich auch sehr schade, wenn die FreeBSD Linie aufgegeben werden würde, aber ich denke nicht, dass iX auf lange Sicht 2 verschiedene OS Linien damit fahren wird, bzw würde es mich sehr wundern.

Die Funktionalität der FreeNAS kann man sich auch jederzeit auf nem handgeschnitzten (bzw mit Ansible automatisiert aufgesetztem) FreeBSD System auf Kommandozeilenbasis bereitstellen, das nette WebGUI braucht man ja nicht unbedingt dazu, wobei ich zugeben muss, dass gerade das von FreeNAS mittlerweile schon sehr gut geworden ist bzw auch die vorherige Version schon sehr gut war.

Fileserver und Virtualisierung kann Linux auch ganz gut... ob die Welt nun aber wirklich das x-te Linux-NAS braucht, das sei mal dahingestellt, ja. Aber die meisten (außer uns FreeBSD.de Foristen) interessiert der Unterbau vermutlich eh nicht.

Vielmehr mach ich mir eher Sorgen, dass es dann den Weg geht wie damals nexenta und wie die alle hießen - die "core" Version gibts frei zum Download, dafür kann die dann wieder nur mit gebremstem Schaum arbeiten, für die volle Leistung musste den Geldbeutel aufmachen und nen "Plan" kaufen... %-/
War ja ein ähnlich gelagerter Fall - Solaris/Linux, die Funktionalität konnte man gut mit ner OpenSolaris bzw OpenIndiana-Maschine abbilden, nur ohne WebGUI aber auch ohne Beschränkung auf 3TB im ZFS Pool von nexenta core (oder warens mehr, kann mich nicht mehr genau erinnern).
 
Ehrlich gesagt finde ich eine Migration sehr schade... Nur weil Linux in aller Munde ist. Meine Erfahrungen hier (z.B. im Umgang mit Servern) zeigt mir, dass es kaum Vorteile gibt, es sei denn man muss unbedingt z.B. Schocker (äh Docker ;-)) o.ä. verwenden... Ubuntu macht manchmal ziemliche "Faxen", was installeirte Software angeht. Ich habe extra ein Verzeichnis für zusätzliche (biol.) Software angelegt und blast (ein biol. Tool) dort "installiert". Nun, Ubuntu meinte in einer (dummen) Paketabhängigkeit, es nochmals (in älterer Version) auch in /usr/bin installieren zu müssen. Das gibt dann immer so nette PATH Probleme... Ehrlich gesagt: ich mag *BSD und würde nur Linux verwenden, wenn BSD tot ist ;-) VG Norbert
 
Ehrlich gesagt: ich mag *BSD und würde nur Linux verwenden, wenn BSD tot is
Ich mache keine Religion draus. Ich ziehe FreeBSD Linux vor aber bei mir steht keine Idiologie oder technisches Interesse im Vordergrund.
Und ich will auch gegen Ubuntu nichts sagen, da es seit Jahren nahezu "rock-solid" läuft. In den letzten Jahren ist der Dateimamager 1 bis 2 mal abgestürtzt, sonst war nie was. Das Ding läuft. Auch null Ärger mit Updates. Ich verstehe die Kritik an Ubuntu (ob hier oder wo anders) oft nicht. In meinen Augen sind einfach viele Fanboys in den Foren unterwegs die "Ihr" System heiligen und andere immer zu schnell/leicht schlechtreden. Das bezieht sich jetzt nicht auf meinen Vorposter, aber zB im heise Forum scheinen wohl fast nur solche unterwegs.

Aber wie schon im Erstpost erwähnt finde auch ich es schade und igendwie falsch von iX. Vielleicht bereuhen sie diese Entscheidung noch eines Tages.
 
sorry, mein Post sollte keine Diffamierung sein - ich finde es halt einfach nur schade, dass FreeBSD (und auch andere *BSD) so wenig in Erwägung gezogen werden, obwohl sie in Sachen Stabilität einem Linux nicht nachhängen... Auch bzgl Desktop nutze ich FreeBSD sehr gerne :)
 
sorry, mein Post sollte keine Diffamierung sein - ich finde es halt einfach nur schade, dass FreeBSD (und auch andere *BSD) so wenig in Erwägung gezogen werden, obwohl sie in Sachen Stabilität einem Linux nicht nachhängen... Auch bzgl Desktop nutze ich FreeBSD sehr gerne :)
So geht es mir auch. Aber was soll man machen? Windows ist das erfolgreichste OS (was Verbreitung angeht) und ich mochte es noch nie wirklich.

Zurück zum Hauptthema... (Meinungen aus dem Forum dort+meine)
....It means that iXsystems customers need an alternative if FreeBSD encounters difficulties to stay on the train. Therefore, porting FreeNAS to Linux is a wisdom choice.
Nein, es ist eine feige Flucht. Man lässt FreeBSD notfalls einfach fallen/im Stich.

Not to mention the ability to move away from Byhve, which is still a very immature platform.
Wie bitte??

Just to clarify, FreeNAS as it exists will continue on FreeBSD for 12.0 and beyond. ...
(Aussage von C. Moore) Wir werden sehen...
 
Zuletzt bearbeitet:

Es geht um Windows auf Bhyve, was auf einige Hosts nicht wirklich funktionierte. Es ist immer schön, wenn hunderte Nutzer sich beschweren und außerdem eine Firma mit durchaus Entwicklerressourcen im Spiel ist, aber keiner keiner es mal nötig hat das an sich gar nicht so komplizierte Problem mal sinnvoll zu debuggen. Ich habe mich dann über Weihnachten erbarmt und das Ergebnis ist vor einigen Tagen committet worden: https://svnweb.freebsd.org/base?view=revision&revision=358848 Meine Mail an Chris mit der Bitte um Remote Zugriff auf einige Testsysteme mit verschiedenen CPUs wurde übrigens ignoriert.
 
Ich war noch vorhin auf der dt. Dokumentation von FreeBSD und dort beschreiben sie lediglich die Vorgehensweise von FreeBSD und Linux als Gast unter bhyve. Bin die ganze Zeit schon am überlegen, es mit Windows mal zu versuchen, da mir VirtualBox mit USB 1.1 da keine befriedigende Lösung bietet.
 
Ich habe nicht den kompletten Thread verfolgt, glaube auch, dass das langsam ins OT abdriftet, möchte dir aber dennoch direkt den Tipp geben, dass USB-Geräte an einen bhyve-Gast durchreichen auch unschöne Seiten hat: Du musst schon vor dem Booten das Gerät reservieren, das du im Gast nutzen willst. Auf dem Host ist das Gerät dann nicht mehr nutzbar.
https://wiki.freebsd.org/bhyve/pci_passthru

Ich habe z.B.
Code:
pptdevs="1/0/0"
in /boot/loader.conf stehen, damit ich meinen Kartenleser mit der Signaturkarte im Windowsgast nutzen kann.
 
Ehrlich gesagt finde ich eine Migration sehr schade... Nur weil Linux in aller Munde ist. Meine Erfahrungen hier (z.B. im Umgang mit Servern) zeigt mir, dass es kaum Vorteile gibt, es sei denn man muss unbedingt z.B. Schocker (äh Docker ;-)) o.ä. verwenden...

Als Softwareentwickler lebe ich natürlich auch nur in meiner Filterblase der Unternehmenssoftware, aber Container sind inzwischen zu Recht in sehr vielen Fällen der Defacto-Standard bei Entwicklung und Betrieb serverseitiger Software.

Ubuntu macht manchmal ziemliche "Faxen", was installeirte Software angeht.

Nicht nur Ubuntu, alle Distributionen bzw. Betriebssysteme. Unter anderem deswegen verpackt man Software in Container, um genau eine Anwendung mit nur den genau benötigten Abhängigkeiten in genau ein transportables Artefakt zu verpacken.

Nein, es ist eine feige Flucht. Man lässt FreeBSD notfalls einfach fallen/im Stich.

Provokant gefragt: wer hat wen im Stich gelassen, wen der Unterbau nicht (mehr) den Anforderungen genügt?
 
Der einzige Grund für FreeBSD bei iX war doch urspünglich ZFS. Das hat sich erledigt da die Codebasis mit ZoL zusammengefügt wird.
Wieso also bei FreeBSD bleiben? Egal wie gut bhyve nun tatsächlich ist, mit KVM hat man sicher keinen schlechteren Hypervisor. Support für das Container Ökosystem hat FreeBSD keinen und Hardwaresupport sieht auch bei Linux besser aus.
Für ein kommerzielles Unternehmen ist doch klar wo die Reise hingeht oder?
 
Wieso also bei FreeBSD bleiben?
Vielleicht nach wie vor wegen ZFS. Ich frage mich, wie gut und zuverlässig es unter Linux auch in der Zukunft laufen wird, solange die Lizenz so bleibt. Und solange Oracle noch Solaris Lizenzen bzw Verträge verkauft, dürfte sich daran nichts ändern.
 
Vielleicht nach wie vor wegen ZFS. Ich frage mich, wie gut und zuverlässig es unter Linux auch in der Zukunft laufen wird, solange die Lizenz so bleibt. Und solange Oracle noch Solaris Lizenzen bzw Verträge verkauft, dürfte sich daran nichts ändern.
Wir setzten es unter CentOS 7 ein. Es läuft so lala. Die Woche erst musste ich einen Pool vergrößern in dem ich die Platten austausche. Eigentlich völlig simple mit zpool replace die Platten austauschen und mit zpool set autoexpand die automatische Vergrößerung einschalten. Tausendmal unter Solaris erfolgreich durchgeführt, ebenfalls unter Linux einige Einsätze erfolgreich durchgebracht. Nur diesmal wollte der Pool einfach nicht die neue Größe annehmen. Nach nem Reboot ging es dann doch plötzlich... Natürlich hatte ich keine Zeit groß zu analysieren, denn eigentlich ist der Vorgang ein Selbstläufer und die Zeit für den Change war entsprechend knapp angemeldet...
 
Der einzige Grund für FreeBSD bei iX war doch urspünglich ZFS. Das hat sich erledigt da die Codebasis mit ZoL zusammengefügt wird.
Wieso also bei FreeBSD bleiben?

Ich denke, das triffts genau. Wenn SUN noch existieren würde, dann hättens damals vllt sogar den OpenSolaris/Indiana als Unterbau genommen, wer weiß?

Hauptentwicklung von OpenZFS ist wie oben gesehen auf Linux, nicht auf BSD - da geht die Reise eindeutig hin.

Linux kann mit KVM/QEMU gut und stabil virtualisieren und mit LXC auch Container, (Docker geht auch, ich mag Docker aber ned), von daher ist FreeBSD mit bhyve nicht unbedingt notwendig.

Traurich (denn irgendwie war für mich ZFS auf Solaris oder auch FreeBSD "nativer"), aber isso...
 
Vielleicht nach wie vor wegen ZFS. Ich frage mich, wie gut und zuverlässig es unter Linux auch in der Zukunft laufen wird, solange die Lizenz so bleibt. Und solange Oracle noch Solaris Lizenzen bzw Verträge verkauft, dürfte sich daran nichts ändern.

Mit der Lizenz hat das nichts zu tun, es gibt genug gute Software die extern vom Kernel als Modul entwickelt wird. Prominentes Beispiel z.b. Wireguard was jetzt auch in den Kernel kommt.
Das mit der Lizenz ist ein rein rechtliches Problem - Canonical scheißt drauf und bisher hat noch keiner geklagt.

Einziger Vorteil den ich bei BSD sehe ist, dass ZFS direkt im Basissystem ist. ZFS "beisst" sich etwas mit dem vfs und dem nativen caching - sowohl unter FreeBSD als auch unter Linux. Da aber bei BSD alles in einer Hand entwickelt wird, kann man hier am Kernel etwas anpassen, unter ZoL wird das schwieriger. Ansonsten sollte es dank gleicher Codebasis und gleichem Testframework auf beiden Systemen ähnlich zuverlässig sein.
 
Zurück
Oben