Nachdem ich lange auf XZ gesetzt habe, hat Zstd dem für mich den Rang abgelaufen. Es kann - je nach Kompressionslevel - superschnell (und trotzdem noch ansehnlich stark) komprimieren oder eben sehr stark, aber deutlich schneller als XZ. Zstandard nutze ich inzwischen für fast alles.
Abgesehen speziell von ZPAQ bietet zstd das laut Wikipedia auch:
Starting from version 1.3.2 (October 2017), zstd optionally implements very long range search and deduplication similar to rzip or lrzip.
lzip samt lziprecover finde ich nicht schlecht. Das wurde explizit für Langzeitarchivierung entworfen. Leider ist es nur single-threaded. Man kann aber auf plzip ausweichen, ist auch nicht ohne Nachteile (0,4-2% größere Archivdatei als lzip + entpackt mit lzip gepackt Archive nicht multi-threaded).
Wieso die XZ Utils gegen lzip gewannen (Verbreitung), kann ich bis heute nicht recht nachvollziehen.
Von blablabla233 am Fr, 8. November 2019 um 15:53 #
Danke fuer die Info wegen zstd...ja speziell weil xz extrem schlecht designed ist (das format..nicht der algo) https://www.nongnu.org/lzip/xz_inadequate.html
Ich nutze ne Mischung aus gz (Kompatiblität), xz (max. Kompression) oder halt zstd. Komprimiert fast so gut wie xz aber ist sehr viel schneller. Nutze ich z. B. um einen ~ 500 GiB großen postgresql-snapshot zu packen und schnell wieder entpacken zu können.
Wenn ich zwei geringfügig abweichende Diskimages von bspw. einem Linuxsystem habe und beide Diskimages in eine Datei komprimiere, welches Kompressionsformat erkennt dann, dass innerhalb beider Diskimages viele Dateien doppelt vorkommen?
Wären meine beiden Diskimages bspw. 500 MB groß und die Abweichung innerhalb deren Dateisysteme beträge nur 5 MB, dann könnte man sich theoretisch 495 MB sparen, da man nicht 2 * 500 MB komprimieren müsste, sondern 1 * 495 MB + 2 * 5 MB.
Welches Kompressionsformat kann das denn? Oder anders gefragt, die meisten Kompressionsformate arbeiten auf Blockebene und kennen somit keine Dateisysteme. Welche Kompressionsformate beherrschen denn auch Dateisysteme um solche Duplikate in den Dateisystemen auch finden zu können?
Ansonsten ist mir ein reines Kompressionsformat, was das bietet, nicht bekannt. Schließlich erstreckt sich eine Gesamtlösung über mehrere Systemschichten. Gemäß der traditionellen Entwicklerphilosophie im unixoiden Ökosystem würde ich auch nicht erwarten, dass es ein brauchbares Kompressionsformat dieser Art gäbe. Es wäre zu komplex. Aber ich kann mich genau so gut auch irren.
Nichtsdestotrotz, kommen mir ein paar Ideen, wie man das mit bestehenden Werkzeugen umsetzen könnte, ohne Gewähr versteht sich
2. Eine Möglichkeit sehe ich in der Verwendung von Backupwerkzeugen, die differentielle Backups erstellen, die Daten dabei deduplizieren und das Resultat in bekannten Formaten komprimieren. Auf Dateieben gäbe es da duplcity (GUI: Déjà Dup), duplicati(?) und auf Chunkebene (als Abgrenzung zur Blockebene des darunterliegenden Dateisystems) rdiff-backup, Borg, restic, Bup...
Natürlich sind das keine reinen Kompressionsformate, sondern mehr oder minder vollständige Backupsoftwarelösungen.
3. Ansonsten könnte man natürlich noch seine eigene Lösung schreiben, die man auf bestehende Werkzeuge aufsetzt, so z.B.: cp, diff, rsync, rsnapshot, tar, gzip (oder sonstiger Kompressor), gnupg, ssh, cron, systemd-timer, udev.
Allerdings ist das gar nicht so trivial, wenn man es richtig und performant machen möchte. Für simplere Ansprüche funktioniert das aber prima.
4. Ein weiterer Ansatz wäre die Verwendung eines CoW-Dateisystems mit guter Snapshotfunktion und transparenter Kompression, z.B. ZFS oder Btrfs.
Das hat den Vorteil, dass man das gesamte Dateisystem (root) auch im laufenden Betrieb konsistent sichern kann (inkrementelle Snapshots + zfs-send / btrfs-send = differentielles Dateisystemabbild) Alle Dateiattribute und erweiterten Attribute, Links usw. müssen nicht durch gesonderten Code in irgendwelchen Kompressionsformaten unterstützt werden, sondern sind nativ.
Die Snapshots sind beliebig inkrementell und sichern nur die Dateisystemdifferenzen auf Blockebene. Die Kompression ist transparent, sodass man das nicht separat machen muss. Auch kann man die Archive (Dateisystemabbilder) direkt mounten, Sie müssen also nicht dekomprimiert werden. Natürlich kann man die Abbilder nachträglich auch noch hashen, signieren, verschlüsseln und beliebig kopieren.
5. Einige Dateisysteme unterstützen dump. UFS und XFS unterstützen das. Für ext-Dateisysteme würde ich mir das in Anbetracht des Zustands und der Linus Rants von vor bald fast 20 Jahren aber genauer überlegen, siehe hier.
Natürlich müsste man dann noch nachträglich komprimieren.
DAR kannte ich noch nicht, das werde ich mir mal anschauen,
2-3 Ja, das wollte ich eigentlich nicht. Die Lösungen sind zu komplex für Dritte und oft auch nicht plattformunabhängig.
4. auch hier ist die fehlende Plattformunabhängigkeit ein Problem. Die Snapshotfunktion hilft hier aber auch nicht wirklich, weil es zwei Systemabbilder wären. Bzw. würde man die Snapshotfunktion ziemlich umbiegen, wenn man das vergangenen Snapshots für System A und das aktuelle für System B verwendet. Möglich ist das natürlich, aber auch viel zu komplex für die Zielgruppe. Und der fehlende OS Support kommt noch dazu.
zur Komplexität: Wie stellen Sie sich weniger komplexe Lösungen vor? Wie sagt man im englischsprachigen Raum so gern... "You can't have your cake and eat it too."
zur Plattform(un)abhängigkeit: a) Zunächst sei gesagt, dass ich aus Ihrem Eingangskommentar die Anforderung der Plattformunabhängigkeit nicht herauslesen konnte. Ich lese da sogar eher das Gegenteil heraus. Zudem sind wir hier auf "Pro-Linux"...
b) Was verstehen Sie unter "plattformunabhängig" genauer? Reicht Ihnen eine Unterstützung gepflegter Versionen von Linux, BSD, macOS oder Windows aus? Falls ja, kann ich Ihren Einwand der Plattformabhängigkeit in Punkt 2 nicht teilen: Borg und restic laufen auf diesen Plattformen. rdiff-backup auch, aber die Unterstützung für Windows ist laut Internetpräsenz nur wenig getestet worden. Duplicati läuft auf diesen Plattformen, allerdings ist keine explizite Unterstützung für BSD genannt. Da es aber auf C#, sprich Mono, basiert, wird es zumindest auch unter FreeBSD lauffähig sein.
zu 4) Neben der ZFS-Referenz Solaris stehen inzwischen Ports verschiedener Qualität von ZFS auf die Plattformen illumos, FreeBSD, OSX, Linux, Windows und NetBSD zur Verfügung (die Ports für Windows und NetBSD sind noch experimentell). Soviel zur Plattform(un)abhängigkeit.
Einen anderen Teil Ihres Einwands kann ich nicht nachvollziehen. Das Problem der Deduplikation wird auf der Blockebene des Dateisystems und entsprechender Snapshots gelöst. Die Snapshots können Sie beliebig verpacken, z.B. mit tar, cpio, pax oder zip (ggf. ohne Kompression, d.h. Kompressionsstufe 0). Das Archivformat kann generisch sein, es muss weder Deduplikation noch Dateiattribute etc. kennen. Es wäre sinnvoll, aber nicht notwendig, wenn es ein nachträgliches Anhängen von Dateien unterstützen würde. Danach hätten Sie eine einzelne Datei, die die Dateisystemzustände in deduplizierter Form enthält. Eine geeignete Kompression können Sie hinterher durchführen oder, vermutlich besser, bereits vorher auf Dateisystemebene (schnellere Sicherung & Widerherstellung).
Das Gesamtproblem wird also mittels zwei bzw. drei strikt getrennter Schichten gelöst (im Fall von btrfs oder ZFS verbindet die Dateisystemebene die Schicht der Blockdeduplikation mit der Schicht der Schanppschüsse, siehe Lösungen à la LVM; ggf. kommt noch die Schicht der transparenten Verschlüsselung hinzu). Das ist doch prima, oder nicht?
Übliche Paketformate wie zip und Co sind recht einfach zu handhaben. In dieser Richtung stelle ich mir das vor. Das es das nicht gibt, ist bedauerlich, aber ist halt wohl so. Deswegen wähle ich aber keine komplexe Lösung, die dann nur zu noch mehr Problemen führen. Dann ist es besser, die Leute laden sich die recht ähnlichen ISOs beide runter. Das Verursacht zwar mehr Traffic und sorgt für längere Downloads, aber dann ist das halt so, bis es mal ein entsprechendes Packprogramm gibt, dass auch das abdeckt.
a) Als Linuxer ist man für Offenheit und denkt auch an andere Plattformen. Wären wir unter Windows auf einer Pro-Windows Seite ja, dann würde man daraus herauslesen, dass man sich um andere Systeme nicht kümmert.
b) windows, mac und linux wären Pflicht. Möglicherweise auch FreeBSD. Haiku hat eine zu geringe Vebreitung um das derzeit ernsthaft in Betracht zu ziehen.
4) Die Installation von zfs Support unter Windows ist für Ottonormalbürger viel zu kompliziert. Mit zwei Mausklicks muss er zum Ziel kommen. Entpacken, starten, fertig.
Zur Deduplikation Es ist nicht ein System das gleichzeitig läuft, sondern zwei. Daher 2 Images, die sind nur leicht verscheiden. Mit Snapshots wird das ein gemurkse, da es bedeutet: 1. Basissystem installieren 2. Anpassung für System A vornehmen 3. Snapshot erstellen. 4. Anpassungen rückgängig machen und für System B anpassen. 5. System sichern.
Der Nutzer müsste jetzt: 1. Datei downloaden 2. Datei duplizierem 3. System B starten und einmal via Snapshot zu System A zurück, das ist nun System A. 4. zweite Datei starten und als System B nutzen.
zur Komplexität: Ihre Beschreibungen sind nicht besonders genau. Meine Argumentation läuft darauf hinaus, dass ich glaube, dass es keine Lösung gibt, die viel weniger komplex sein würde - vorausgesetzt, die IT-Landschaft ändert sich hier nicht bahnbrechend. Bedauerlich finde ich das nicht. Die Lösungsmöglichkeiten sind da, man müsste Sie lediglich automatisieren...
Dann ist es besser, die Leute laden sich die recht ähnlichen ISOs beide runter.
Und an diesem Punkt verstehe ich Ihren eigentlichen Anwendungsfall nicht mehr. So schrieben Sie eingangs doch noch:
[Titel: ]Welches Kompressionsformat beherrscht den Deduplikation auf DiskImage Ebene
Wenn ich zwei geringfügig abweichende Diskimages von bspw. einem Linuxsystem habe und beide Diskimages in eine Datei komprimiere, welches Kompressionsformat erkennt dann, dass innerhalb beider Diskimages viele Dateien doppelt vorkommen?
zur Plattform(un)abhängigkeit: a) Naja, Menschen sind verschieden. Ich finde diesen Sachverhalt nicht so offensichtlich, wie Sie. Auch der Vergleich ist irgendwie unangebracht. Sie setzen hier eine gewisse Elitismus innerhalb der Linux-Community voraus, die in gewisser Form sicherlich existiert, die ich aber nicht gutheißen kann.
Sagen wir einfach, dass hier ein Problem auf Kommunikationsebene vorliegt. Der Absender hat missverständlich geschrieben und der Empfänger hat "fehlinterpretiert", auch wenn ich dieses Wort nicht gerne benutze, weil nur die subjektiv wahrscheinlichste Interpretation des Empfängers nicht mit der Aussageintention des Absenders übereinspricht. Beim Ballsport ist auch der Passgeber für den Erfolg des Passes hauptverantwortlich...
b) Na dann kämen ja ein paar der genannten Optionen unter Punkt 2 in Frage. Nix da "plattformabhängig".
zu 4) Ja, da gebe ich Ihnen recht. Allerdings wusste ich zum Zeitpunkt des Verfassens meines Vorschlags auch nicht, dass überhaupt eine Unterstützung anderer Plattformen als Linux gewünscht war - zu Recht, wie ich finde.
zur Deduplikation:
Es ist nicht ein System das gleichzeitig läuft, sondern zwei.
Ich verweise nochmals auf Ihren Eingangskommentar (Satz 1). Dort steht (Hervorhebungen gehören mir):
Wenn ich zwei geringfügig abweichende Diskimages von bspw. einem Linuxsystem habe [...]
Ändern Sie hier nicht stillschweigend die Prämisse bzw. den Anwendungsfall? Wie passt das zusammen?
Mit Snapshots wird das ein gemurkse, da es bedeutet: [...]
Das ist kaum verwunderlich, denn Sie betrachten hier Voraussetzungen, die von den ursprünglichen modifiziert wurden. Für diesen Fall wären andere Lösungen sinnvoller. Da wäre bspw. ein System- & Abbildgenerierung, Deploymentwerkzeuge und ggf. ein separates verteiltes Konfigurationsverwaltungssystem. Dabei möchte ich es aber belassen, denn das wäre ein ganz anderes Thema.
Der Nutzer müsste jetzt: 1. Datei downloaden 2. Datei duplizierem 3. System B starten und einmal via Snapshot zu System A zurück, das ist nun System A. 4. zweite Datei starten und als System B nutzen.
Wieso downloaden? Woher? Wohin? Wieso duplizieren? Warum das alles? Warum so kompliziert? Wofür? Ich glaube wir reden aneinander vorbei. Sind Sie noch in dem ursprünglichen Anwendungsfall "von bspw. einem Linuxsystem"?
So ginge das: 1. ggf. Archiv entpacken. 2. Die Dateisystemabbilder werden korrekt eingehangen. 3. Der zu verwende Snapshot/Zustand wird gewählt. 4. Starten. 5. Profit. Wie soll es noch einfacher gehen? Schwebt Ihnen eine einknöpfige Bedienung à la iPhone vor?
Viel zu umständlich und für Joe zu kompliziert.
Hilfsbereit hatte ich Ihnen gutgemeinte Vorschläge zur Beantwortung Ihrer ursprünglichen Frage abgegeben. Ich bezweifle stark, dass es wesentlich einfachere Lösungen gäbe. Was fehlt, ist lediglich die Automatisierung/Integration.
Außerdem schrieben Sie eingangs "Wenn ich [...]", d.h. es ging nie um "Joe". Oder sind Sie "Joe" und reden von sich in der dritten Person. Das wäre irgendwie ein wenig schräg.
Haha ja, das Siezen ist so eine meiner Gepflogenheiten. Erst wurde es mir eingetrichtert, dann habe ich es mir angewöhnt und nun werde es einfach nicht mehr los. Nun hat es sich hier scheinbar schon zu einer Art Markenzeichen für mich entwickelt.
Ich wollte nur alle Möglichkeiten der Aussage in Betracht ziehen, denn öfters wird mir vorgeworfen, ich würde die Kommentare "fehlinterpretieren". Wenn jemand von sich gerne in der dritten Person spricht, von mir aus. Ich gewöhn' mich dran.
Kompatibilität ist am Wichtigsten, weil ich zwischen vielen Systemen hin und her wechsle und auch muss. Sodass am Ende die Kompatibilität am Wichtigsten ist.
Um die Daten meines Ideapads vor der Umstellung von MBR auf GPT und Kubuntu 15.10 auf Leap 15.1 inkl. Secure Boot zu sichern, habe ich von beiden Partitionen jeweils eine gz-komprimierte cpio-Datei erstellt. Hat zügig und abbruchfrei funktioniert.
Nachdem ich lange auf XZ gesetzt habe, hat Zstd dem für mich den Rang abgelaufen. Es kann - je nach Kompressionslevel - superschnell (und trotzdem noch ansehnlich stark) komprimieren oder eben sehr stark, aber deutlich schneller als XZ. Zstandard nutze ich inzwischen für fast alles.
lrzip oder zpaq fuer Langzeitarchivierung
Abgesehen speziell von ZPAQ bietet zstd das laut Wikipedia auch:
lzip samt lziprecover finde ich nicht schlecht. Das wurde explizit für Langzeitarchivierung entworfen. Leider ist es nur single-threaded. Man kann aber auf plzip ausweichen, ist auch nicht ohne Nachteile (0,4-2% größere Archivdatei als lzip + entpackt mit lzip gepackt Archive nicht multi-threaded).
Wieso die XZ Utils gegen lzip gewannen (Verbreitung), kann ich bis heute nicht recht nachvollziehen.
Danke fuer die Info wegen zstd...ja speziell weil xz extrem schlecht designed ist (das format..nicht der algo)
https://www.nongnu.org/lzip/xz_inadequate.html
dito. zstd rult alles weg
Ich nutze ne Mischung aus gz (Kompatiblität), xz (max. Kompression) oder halt zstd.
Komprimiert fast so gut wie xz aber ist sehr viel schneller. Nutze ich z. B. um einen ~ 500 GiB großen postgresql-snapshot zu packen und schnell wieder entpacken zu können.
Wenn ich zwei geringfügig abweichende Diskimages von bspw. einem Linuxsystem habe und beide Diskimages in eine Datei komprimiere, welches Kompressionsformat erkennt dann, dass innerhalb beider Diskimages viele Dateien doppelt vorkommen?
Wären meine beiden Diskimages bspw. 500 MB groß und die Abweichung innerhalb deren Dateisysteme beträge nur 5 MB, dann könnte man sich theoretisch 495 MB sparen, da man nicht 2 * 500 MB komprimieren müsste, sondern 1 * 495 MB + 2 * 5 MB.
Welches Kompressionsformat kann das denn?
Oder anders gefragt, die meisten Kompressionsformate arbeiten auf Blockebene und kennen somit keine Dateisysteme.
Welche Kompressionsformate beherrschen denn auch Dateisysteme um solche Duplikate in den Dateisystemen auch finden zu können?
Lrzip kann das...und ahnscheinend neu auch zstd....
Danke für die Info.
1. Hm, es gibt dar.
Ansonsten ist mir ein reines Kompressionsformat, was das bietet, nicht bekannt. Schließlich erstreckt sich eine Gesamtlösung über mehrere Systemschichten. Gemäß der traditionellen Entwicklerphilosophie im unixoiden Ökosystem würde ich auch nicht erwarten, dass es ein brauchbares Kompressionsformat dieser Art gäbe. Es wäre zu komplex. Aber ich kann mich genau so gut auch irren.
Nichtsdestotrotz, kommen mir ein paar Ideen, wie man das mit bestehenden Werkzeugen umsetzen könnte, ohne Gewähr versteht sich
2. Eine Möglichkeit sehe ich in der Verwendung von Backupwerkzeugen, die differentielle Backups erstellen, die Daten dabei deduplizieren und das Resultat in bekannten Formaten komprimieren. Auf Dateieben gäbe es da duplcity (GUI: Déjà Dup), duplicati(?) und auf Chunkebene (als Abgrenzung zur Blockebene des darunterliegenden Dateisystems) rdiff-backup, Borg, restic, Bup...
Natürlich sind das keine reinen Kompressionsformate, sondern mehr oder minder vollständige Backupsoftwarelösungen.
3. Ansonsten könnte man natürlich noch seine eigene Lösung schreiben, die man auf bestehende Werkzeuge aufsetzt, so z.B.: cp, diff, rsync, rsnapshot, tar, gzip (oder sonstiger Kompressor), gnupg, ssh, cron, systemd-timer, udev.
Allerdings ist das gar nicht so trivial, wenn man es richtig und performant machen möchte. Für simplere Ansprüche funktioniert das aber prima.
4. Ein weiterer Ansatz wäre die Verwendung eines CoW-Dateisystems mit guter Snapshotfunktion und transparenter Kompression, z.B. ZFS oder Btrfs.
Das hat den Vorteil, dass man das gesamte Dateisystem (root) auch im laufenden Betrieb konsistent sichern kann (inkrementelle Snapshots + zfs-send / btrfs-send = differentielles Dateisystemabbild)
Alle Dateiattribute und erweiterten Attribute, Links usw. müssen nicht durch gesonderten Code in irgendwelchen Kompressionsformaten unterstützt werden, sondern sind nativ.
Die Snapshots sind beliebig inkrementell und sichern nur die Dateisystemdifferenzen auf Blockebene. Die Kompression ist transparent, sodass man das nicht separat machen muss. Auch kann man die Archive (Dateisystemabbilder) direkt mounten, Sie müssen also nicht dekomprimiert werden. Natürlich kann man die Abbilder nachträglich auch noch hashen, signieren, verschlüsseln und beliebig kopieren.
kleine Ergänzung:
5. Einige Dateisysteme unterstützen dump. UFS und XFS unterstützen das. Für ext-Dateisysteme würde ich mir das in Anbetracht des Zustands und der Linus Rants von vor bald fast 20 Jahren aber genauer überlegen, siehe hier.
Natürlich müsste man dann noch nachträglich komprimieren.
DAR kannte ich noch nicht, das werde ich mir mal anschauen,
2-3 Ja, das wollte ich eigentlich nicht. Die Lösungen sind zu komplex für Dritte und oft auch nicht plattformunabhängig.
4. auch hier ist die fehlende Plattformunabhängigkeit ein Problem.
Die Snapshotfunktion hilft hier aber auch nicht wirklich, weil es zwei Systemabbilder wären. Bzw. würde man die Snapshotfunktion ziemlich umbiegen, wenn man das vergangenen Snapshots für System A und das aktuelle für System B verwendet.
Möglich ist das natürlich, aber auch viel zu komplex für die Zielgruppe. Und der fehlende OS Support kommt noch dazu.
zur Komplexität:
Wie stellen Sie sich weniger komplexe Lösungen vor? Wie sagt man im englischsprachigen Raum so gern... "You can't have your cake and eat it too."
zur Plattform(un)abhängigkeit:
a) Zunächst sei gesagt, dass ich aus Ihrem Eingangskommentar die Anforderung der Plattformunabhängigkeit nicht herauslesen konnte. Ich lese da sogar eher das Gegenteil heraus. Zudem sind wir hier auf "Pro-Linux"...
b) Was verstehen Sie unter "plattformunabhängig" genauer? Reicht Ihnen eine Unterstützung gepflegter Versionen von Linux, BSD, macOS oder Windows aus?
Falls ja, kann ich Ihren Einwand der Plattformabhängigkeit in Punkt 2 nicht teilen: Borg und restic laufen auf diesen Plattformen. rdiff-backup auch, aber die Unterstützung für Windows ist laut Internetpräsenz nur wenig getestet worden. Duplicati läuft auf diesen Plattformen, allerdings ist keine explizite Unterstützung für BSD genannt. Da es aber auf C#, sprich Mono, basiert, wird es zumindest auch unter FreeBSD lauffähig sein.
zu 4)
Neben der ZFS-Referenz Solaris stehen inzwischen Ports verschiedener Qualität von ZFS auf die Plattformen illumos, FreeBSD, OSX, Linux, Windows und NetBSD zur Verfügung (die Ports für Windows und NetBSD sind noch experimentell). Soviel zur Plattform(un)abhängigkeit.
Einen anderen Teil Ihres Einwands kann ich nicht nachvollziehen. Das Problem der Deduplikation wird auf der Blockebene des Dateisystems und entsprechender Snapshots gelöst. Die Snapshots können Sie beliebig verpacken, z.B. mit tar, cpio, pax oder zip (ggf. ohne Kompression, d.h. Kompressionsstufe 0). Das Archivformat kann generisch sein, es muss weder Deduplikation noch Dateiattribute etc. kennen. Es wäre sinnvoll, aber nicht notwendig, wenn es ein nachträgliches Anhängen von Dateien unterstützen würde.
Danach hätten Sie eine einzelne Datei, die die Dateisystemzustände in deduplizierter Form enthält.
Eine geeignete Kompression können Sie hinterher durchführen oder, vermutlich besser, bereits vorher auf Dateisystemebene (schnellere Sicherung & Widerherstellung).
Das Gesamtproblem wird also mittels zwei bzw. drei strikt getrennter Schichten gelöst (im Fall von btrfs oder ZFS verbindet die Dateisystemebene die Schicht der Blockdeduplikation mit der Schicht der Schanppschüsse, siehe Lösungen à la LVM; ggf. kommt noch die Schicht der transparenten Verschlüsselung hinzu). Das ist doch prima, oder nicht?
Übliche Paketformate wie zip und Co sind recht einfach zu handhaben.
In dieser Richtung stelle ich mir das vor. Das es das nicht gibt, ist bedauerlich, aber ist halt wohl so. Deswegen wähle ich aber keine komplexe Lösung, die dann nur zu noch mehr Problemen führen. Dann ist es besser, die Leute laden sich die recht ähnlichen ISOs beide runter. Das Verursacht zwar mehr Traffic und sorgt für längere Downloads, aber dann ist das halt so, bis es mal ein entsprechendes Packprogramm gibt, dass auch das abdeckt.
a) Als Linuxer ist man für Offenheit und denkt auch an andere Plattformen.
Wären wir unter Windows auf einer Pro-Windows Seite ja, dann würde man daraus herauslesen, dass man sich um andere Systeme nicht kümmert.
b) windows, mac und linux wären Pflicht. Möglicherweise auch FreeBSD.
Haiku hat eine zu geringe Vebreitung um das derzeit ernsthaft in Betracht zu ziehen.
4) Die Installation von zfs Support unter Windows ist für Ottonormalbürger viel zu kompliziert.
Mit zwei Mausklicks muss er zum Ziel kommen. Entpacken, starten, fertig.
Zur Deduplikation
Es ist nicht ein System das gleichzeitig läuft, sondern zwei.
Daher 2 Images, die sind nur leicht verscheiden.
Mit Snapshots wird das ein gemurkse, da es bedeutet:
1. Basissystem installieren
2. Anpassung für System A vornehmen
3. Snapshot erstellen.
4. Anpassungen rückgängig machen und für System B anpassen.
5. System sichern.
Der Nutzer müsste jetzt:
1. Datei downloaden
2. Datei duplizierem
3. System B starten und einmal via Snapshot zu System A zurück, das ist nun System A.
4. zweite Datei starten und als System B nutzen.
Viel zu umständlich und für Joe zu kompliziert.
zur Komplexität:
Und an diesem Punkt verstehe ich Ihren eigentlichen Anwendungsfall nicht mehr. So schrieben Sie eingangs doch noch:Ihre Beschreibungen sind nicht besonders genau. Meine Argumentation läuft darauf hinaus, dass ich glaube, dass es keine Lösung gibt, die viel weniger komplex sein würde - vorausgesetzt, die IT-Landschaft ändert sich hier nicht bahnbrechend.
Bedauerlich finde ich das nicht. Die Lösungsmöglichkeiten sind da, man müsste Sie lediglich automatisieren...
zur Plattform(un)abhängigkeit:
a) Naja, Menschen sind verschieden. Ich finde diesen Sachverhalt nicht so offensichtlich, wie Sie. Auch der Vergleich ist irgendwie unangebracht. Sie setzen hier eine gewisse Elitismus innerhalb der Linux-Community voraus, die in gewisser Form sicherlich existiert, die ich aber nicht gutheißen kann.
Sagen wir einfach, dass hier ein Problem auf Kommunikationsebene vorliegt. Der Absender hat missverständlich geschrieben und der Empfänger hat "fehlinterpretiert", auch wenn ich dieses Wort nicht gerne benutze, weil nur die subjektiv wahrscheinlichste Interpretation des Empfängers nicht mit der Aussageintention des Absenders übereinspricht. Beim Ballsport ist auch der Passgeber für den Erfolg des Passes hauptverantwortlich...
b) Na dann kämen ja ein paar der genannten Optionen unter Punkt 2 in Frage. Nix da "plattformabhängig".
zu 4) Ja, da gebe ich Ihnen recht. Allerdings wusste ich zum Zeitpunkt des Verfassens meines Vorschlags auch nicht, dass überhaupt eine Unterstützung anderer Plattformen als Linux gewünscht war - zu Recht, wie ich finde.
zur Deduplikation:
Ich verweise nochmals auf Ihren Eingangskommentar (Satz 1). Dort steht (Hervorhebungen gehören mir):Ändern Sie hier nicht stillschweigend die Prämisse bzw. den Anwendungsfall? Wie passt das zusammen?Das ist kaum verwunderlich, denn Sie betrachten hier Voraussetzungen, die von den ursprünglichen modifiziert wurden. Für diesen Fall wären andere Lösungen sinnvoller. Da wäre bspw. ein System- & Abbildgenerierung, Deploymentwerkzeuge und ggf. ein separates verteiltes Konfigurationsverwaltungssystem.Dabei möchte ich es aber belassen, denn das wäre ein ganz anderes Thema.Wieso downloaden? Woher? Wohin? Wieso duplizieren? Warum das alles? Warum so kompliziert? Wofür? Ich glaube wir reden aneinander vorbei. Sind Sie noch in dem ursprünglichen Anwendungsfall "von bspw. einem Linuxsystem"?
So ginge das: 1. ggf. Archiv entpacken. 2. Die Dateisystemabbilder werden korrekt eingehangen. 3. Der zu verwende Snapshot/Zustand wird gewählt. 4. Starten. 5. Profit.
Hilfsbereit hatte ich Ihnen gutgemeinte Vorschläge zur Beantwortung Ihrer ursprünglichen Frage abgegeben. Ich bezweifle stark, dass es wesentlich einfachere Lösungen gäbe. Was fehlt, ist lediglich die Automatisierung/Integration.Wie soll es noch einfacher gehen? Schwebt Ihnen eine einknöpfige Bedienung à la iPhone vor?
Außerdem schrieben Sie eingangs "Wenn ich [...]", d.h. es ging nie um "Joe". Oder sind Sie "Joe" und reden von sich in der dritten Person. Das wäre irgendwie ein wenig schräg.
> von sich in der dritten Person. Das wäre irgendwie ein wenig schräg.
Noch schräger als Leute hier zu siezen
Haha ja, das Siezen ist so eine meiner Gepflogenheiten. Erst wurde es mir eingetrichtert, dann habe ich es mir angewöhnt und nun werde es einfach nicht mehr los. Nun hat es sich hier scheinbar schon zu einer Art Markenzeichen für mich entwickelt.
Ich wollte nur alle Möglichkeiten der Aussage in Betracht ziehen, denn öfters wird mir vorgeworfen, ich würde die Kommentare "fehlinterpretieren". Wenn jemand von sich gerne in der dritten Person spricht, von mir aus. Ich gewöhn' mich dran.
Jeder wie er kann und mag, schätze ich
Kompatibilität ist am Wichtigsten, weil ich zwischen vielen Systemen hin und her wechsle und auch muss. Sodass am Ende die Kompatibilität am Wichtigsten ist.
Ja, deshalb bleibe ich auch bei tar.gz. Es läuft halt.
Um die Daten meines Ideapads vor der Umstellung von MBR auf GPT und Kubuntu 15.10 auf Leap 15.1 inkl. Secure Boot zu sichern, habe ich von beiden Partitionen jeweils eine gz-komprimierte cpio-Datei erstellt. Hat zügig und abbruchfrei funktioniert.
geht das?
welche frontends unterstützen das bereits?
schönen dank