Suche guten Trueimage-Nachfolger für USB-Boot

foofoobar schrieb:
Die These bzgl. ARM würde ich so generell wie du die aufgestellt hast nicht unterschreiben wollen.
Auf ARM-uefi Kisten könnte ich mir vorstellen das das funktioniert.
Bist gerne eingeladen das für Dich auszuprobieren.
Was man sich im Konjunktiv vorstellen sind prinzipiell Nullaussagen.
foofoobar schrieb:
Fipptehler - Distros ist gemeint.
foofoobar schrieb:
Was genau soll eine Gui haben?
Jede App oder Programm im Jahre 2026.
Ich weis, dass gerade Linuxianer das noch nicht angekommen sind - aber es ist Teil des Geheimnisses, warum Windows hier erfolgreicher ist. 🤷‍♂️
 
mchawk777 schrieb:
Bist gerne eingeladen das für Dich auszuprobieren.
Was man sich im Konjunktiv vorstellen sind prinzipiell Nullaussagen.
Wer über Computerkram nicht im Konjunktiv redet hat sich bisher zu wenig mit Computern beschäftigt.
Und ARM kann ja auch ein Plaste-Router oder eine Waschmaschine sein.

Aber man ja einfach nachschauen:
Code:
Format: 1.0
Source: rear
Version: 2.9
Binary: rear
Maintainer: Gratien Dhaese <gratien.dhaese@gmail.com>
Architecture: all
Build-Depends: debhelper
Files:-
 2a75df0c3bbdff1d9366ee1b2a86c9aa 1015547 rear-2.9.tar.gz
https://raw.githubusercontent.com/rear/rear/refs/heads/master/packaging/debian/rear.dsc

mchawk777 schrieb:
Fipptehler - Distros ist gemeint.
Das Zeug sind nur Files in einem einzigen Directory:
Code:
This quick start guide will show you how to run Relax-and-Recover from the gitcheckout and create a bootable USB backup.

Please note that this is intended for testing, experimentation and development as bypasses some of the security measures that are in place for production use. For production use, please install ReaR into your system, either via a package or via sudo make install from source.

Start by cloning the Relax-and-Recover sources from GitHub:

git clone https://github.com/rear/rear.git<br>

Move into the rear/ directory:
cd rear/<br>
Prepare your USB media. Change /dev/sdb to the correct device in your situation.Relax-and-Recover will ‘own’ the device in this example.

This will destroy all data on that device.
sudo usr/sbin/rear format /dev/sdb<br>

    [ ..... ]
https://relax-and-recover.org/documentation/getting-started

mchawk777 schrieb:
Jede App oder Programm im Jahre 2026.
Ich weis, dass gerade Linuxianer das noch nicht angekommen sind - aber es ist Teil des Geheimnisses, warum Windows hier erfolgreicher ist. 🤷‍♂️
Wenn man viele Kisten hat und möglicherweise diese Horde von Maschine von zentralen Job Schedulern gesteuert werden juckt Niemand eine fehlende GUI.
Und bedenke dabei das ein Bare-metal Recovery zwingend von der Konsole läuft und dort will wirklich niemand eine GUI die über irgentwelche grundsätzlich rottigen BMCs oder KVMs rüber muss mit z.b. immer wieder kaputten Tastatur-Layouts. Und dann liegen die auch typischerweise hinter jump-hosts. (Turnschuh ist total 90'er)
Und wirklich Niemand will sich bei einem Bare-Metal-Recovery mit irgendwelchen dusseligen Grafik-Problemen rumärgen.
 
Zuletzt bearbeitet:
foofoobar schrieb:
Und wirklich Niemand will sich bei einem Bare-Metal-Recovery mit irgendwelchen dusseligen Grafik-Problemen rumärgen.

Vielleicht sind die dusseligen Grafik-Probleme ja das eigentliche Problem von Linux.

Ich hatte als Noob mit total veraltetem Wissen gerade das Vergnügen. Warum ist der angebliche Quasistandard GTK nur in der uralten Version 3 vorinstalliert ? Warum kann man GTK4 nicht einfach installieren, so dass es funktioniert, ohne einen mit "theme parser warning" zuzuschmeißen ? Warum reißt mir dieses blöde GTK das C-Hauptprogramm aus der Hand, und nervt mich mit einer ominösen "App-Struktur" ?

Das bisschen, was ich an GUI haben wollte, hätte ich in C64-Assembler schneller fertig gehabt.

Immerhin habe ich jetzt die "Nuklear Immediate Mode GUI" gefunden, die bis jetzt das tut, was sie soll.

Zumindest, solange ich keine Bildimporte brauche. Denn da gab es auch wieder irgendwelche seltsamen Inkompatibilitäten zwischen Nuklear-Version und OpenGL-Version, die es eigentlich nicht geben dürfte.
 
JMP $FCE2 schrieb:
Vielleicht sind die dusseligen Grafik-Probleme ja das eigentliche Problem von Linux.

Ich hatte als Noob mit total veraltetem Wissen gerade das Vergnügen. Warum ist der angebliche Quasistandard GTK nur in der uralten Version 3 vorinstalliert ? Warum kann man GTK4 nicht einfach installieren, so dass es funktioniert, ohne einen mit "theme parser warning" zuzuschmeißen ? Warum reißt mir dieses blöde GTK das C-Hauptprogramm aus der Hand, und nervt mich mit einer ominösen "App-Struktur" ?

Das bisschen, was ich an GUI haben wollte, hätte ich in C64-Assembler schneller fertig gehabt.
Das klingt eher nach einem Fall für so was wie TCL/TK.

Ansonsten zielt mein Rant eher auf typische Server-Infrastruktur ab, wo der Kram über zig (BMC/virtuelle Consolen/RDP/etc) Layer drüber muss und die zu allem Überfluss noch an diversen Ecken und Kanten mit Snakeoil gespickt ist. (Solche Umgebungen sind ja zusätzlich eher nicht statisch, und Tests für einer neuen BMC -Version o.ä. sind zwingend mit Downtimes verbunden)
Sowohl Windows als auch Unix kriegen das ja nicht zu sehen (anderer Layer), daher verkackt Windows dort genau so wie Unix.

Der Klassiker: Über eine Remote-Console sich nicht auf dem OS einloggen zu können weil mal wieder das Tastatur-Layout zerschossen ist und man bestimmte Zeichen nicht auf der Tastatur eingeben kann. Und von C&P in oder aus der Remote-Console fange ich gar nicht erst an oder von zuppelnden Mauszeigern.

Will man nicht haben, weil es typischerweise wenn ein Bare-Metal-Recovery ansteht schnell gehen soll.
Und wenn man sich das von mir verlinkte Video anschaut sehe ich dort nichts wo eine GUI einen signifikanten Vorteil bzgl. Usability erbringen würde. Aber ich lasse mir gerne von dir aufzeigen wo eine GUI ganz konkret die von mir aufgezeigten Risiken und Nachteile aufwiegt. Insbesondere wo nach dem Boot von dem Recovery-Image direkt angezeigt wird was zu tippen ist, eine Y/N Abfrage wäre da auch denkbar allerdings ist es nicht schlecht wenn man vorher etwas tippen muss, die Kiste wird ja komplett über gebügelt.
Und wer nicht in der Lage ist ein paar Buchstaben fehlerfrei auf einer Tastatur ein zu tippen ist schlicht nicht die Zielgruppe für derartige Tools.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: JMP $FCE2
Ich kann im Windows Bereich "Drive Snapshot" empfehlen, kostet zwar auch (einmalig), ist aber sehr leichtgewichtig. Bekommt keinen Ordnen für die GUI, macht aber genau das was man will.
Mit Secure Boot wird es da nie Probleme geben, weil man die exe einfach von der Windows DVD/USB Stick zur Wiederherstellung nutzen kann.
 
foofoobar schrieb:
Aber ich lasse mir gerne von dir aufzeigen wo eine GUI ganz konkret die von mir aufgezeigten Risiken und Nachteile aufwiegt.

Eine vernünftige GUI soll vor allem eine Bedienungsanleitung überflüssig machen, und natürlich bei kritischen Funktionen (wie Partition überschreiben) hervorgehobene Warnungen einblenden, und zusätzliche Bestätigungen anfordern.

Ein "Normaluser" braucht besonders die Recovery-Plattform eher selten, deshalb sollte sie selbsterklärend und intuitiv bedienbar sein.

foofoobar schrieb:
Der Klassiker: Über eine Remote-Console sich nicht auf dem OS einloggen zu können weil mal wieder das Tastatur-Layout zerschossen ist und man bestimmte Zeichen nicht auf der Tastatur eingeben kann.

Selbst da wäre man mit einem "Minimal-GUI" nach C64-/MS-DOS-Style besser bedient, wo man einfach einen invertierten Balken mit den Cursortasten bewegt, und mit Enter bestätigt, oder alternativ Tastenkürzel drückt.

Ein bisschen ASCII-Text und vielleicht 100 Byte Assemblercode, Ressourcenbedarf quasi Null - und schon ist das ganze um Welten zugänglicher für Normaluser, als jede Kommandozeilengeschichte. Und trotzdem extrem schnell zu bedienen:

https://rr.pokefinder.org/wiki/File:Action_Replay_Freezer.gif

Ich fand schon DOS-Kram wie pkzip damals extrem lästig, weil vergleichbare C64-Tools (auch meine selbst geschriebenen) immer eine "GUI" wie die in dem Bild hatten.

foofoobar schrieb:
Das klingt eher nach einem Fall für so was wie TCL/TK.

Danke, werde ich mir mal ansehen. Obwohl ich wahrscheinlich bei Nuklear bleibe - der von ChatGPT im Vergleich als Nachteil aufgeführte Punkt 2 ist für mich der Vorteil, nach dem ich gesucht hatte:

tcltk-nuklear.gif
 
  • Gefällt mir
Reaktionen: mchawk777
JMP $FCE2 schrieb:
Ein "Normaluser" braucht besonders die Recovery-Plattform eher selten, deshalb sollte sie selbsterklärend und intuitiv bedienbar sein.
Nicht nur bei der Recovery.
Solange sich die Erkenntnis bei eingefleischten Linuxianern nicht durchsetzt, dass der Punkt, in dem Windows dem Linux-System deutlich schlägt, eine deutlich intuitivere und einheitlichere GUI ist.

Von dem Fehlen einer generellen Standard-Betriebssystem-GUI für alle Distros abgesehen. Das ist ja mehr oder minder der Grund, warum immer wieder die Kommandozeile bei Anleitungen heran gezogen wird: Sie ist der kleinste, gemeinsame Nenner - und gleichzeitig eine große Design- und Interface-Schwäche.
 
JMP $FCE2 schrieb:
Selbst da wäre man mit einem "Minimal-GUI" nach C64-/MS-DOS-Style besser bedient, wo man einfach einen invertierten Balken mit den Cursortasten bewegt, und mit Enter bestätigt, oder alternativ Tastenkürzel drückt.

Ein bisschen ASCII-Text und vielleicht 100 Byte Assemblercode, Ressourcenbedarf quasi Null - und schon ist das ganze um Welten zugänglicher für Normaluser, als jede Kommandozeilengeschichte. Und trotzdem extrem schnell zu bedienen:

https://rr.pokefinder.org/wiki/File:Action_Replay_Freezer.gif

Ich fand schon DOS-Kram wie pkzip damals extrem lästig, weil vergleichbare C64-Tools (auch meine selbst geschriebenen) immer eine "GUI" wie die in dem Bild hatten.
Dafür gibt es dialog: https://wiki.ubuntuusers.de/Dialog/

Der Autor freut sich bestimmt über deine Commits.
mchawk777 schrieb:
Von dem Fehlen einer generellen Standard-Betriebssystem-GUI für alle Distros abgesehen. Das ist ja mehr oder minder der Grund, warum immer wieder die Kommandozeile bei Anleitungen heran gezogen wird: Sie ist der kleinste, gemeinsame Nenner - und gleichzeitig eine große Design- und Interface-Schwäche.
Wie würdest du eine GUI konzipieren mit der man z.b. PAM vollständig konfigurieren kann?

Normalerweise ist man bei solchen Sachen immer froh wenn man dafür funktionierende Snippets die man per C&P einfach reinbraten kann.
Und bei den typischen Windows-Config-GUIs fehlt mir immer eine Suchfunktion, die Fragestellung ob irgendwas mit $FOO konfiguriert ist bzw. was wurde mit $FOO konfiguriert ist ja nun keine Fragestellung die selten ist.
Spätestens wenn das über eine gewisse Anzahl von Maschinen hinaus geht wird Klick-Klack nervig, kontraproduktiv und fehleranfällig.
 
Zuletzt bearbeitet:
foofoobar schrieb:
Wie würdest du eine GUI konzipieren mit der man z.b. PAM vollständig konfigurieren kann?
Man muss als Kritiker keine Lösung haben. Häufiges Missverständnis. So auch hier.
 
  • Gefällt mir
Reaktionen: nutrix
foofoobar schrieb:
Dann kann also Windows noch die letzte verbleibende Nische Desktop verlieren?
Theoretisch? Ja, klar.
Praktisch? Nö - dafür müsste sich Linux deutlich ändern - und das machen die aktuellen Nutzer nicht mit. 😉
 
Zurück
Oben