SSD mit Windows NT klonen

Clonezilla.

Wenn du allerdings mit den Treibern einen exotischen Weg zur IDE-Disk 
meinst, der in Clonezilla nicht drin ist, dann wirds schwieriger.

Adapter schrieb:
> Wenn der Rechner von USB booten kann, besteht der sicherste und
> einfachste Weg darin, Linux zu booten und dd zu benutzen. Achtung: NICHT
> Quell- und Ziellaufwerk vertauschen! ;-)

Clonezilla macht im Grunde auch nichts anderes (ok, es kennt FAT und 
NTFS und kopiert daher nur genutzte Blöcke). Aber mit einfacherer 
Benutzerführung, besonders was Quelle und Ziel angeht.

Geht übrigens beides auch ohne USB. In der Guten Alten Zeit (tm) hatte 
man noch CD-Laufwerke. ;-)

Adapter schrieb:
> und dd zu benutzen

wenn man es denn gerne so hat dass man nicht weiss,
wann die Kiste fertig ist...
gut, 1 GB ist nicht die Welt aber prinzipiell... Tonne

das darf man schon gerne mit einem Programm machen,
dass einem auch den Fortschritt anzeigen kann.

Handeule schrieb:
> da kommt eine Fehlermeldung

Die Fehlermeldung selbst wäre auch nicht ganz uninteressant.

Handeule schrieb:
> ...clonezilla braucht min. 196MB RAM, 128 sind vorhanden.

- USB/IDE-Adapter besorgen.
- IDE-SSD aus NT-Rechner ausbauen und dort dran hängen.
- Beides zusammen an einen aktuelleren Rechner hängen.
- Mit Clonezilla ein Imagefile auf einen USB-Stick ziehen.

Dann hast du ein exaktes Disk-Image auf dem Stick das du in umgekehrter 
Richtung auch wieder auf eine IDE-SSD kopieren kannst.

HDClone kann man wahlweise auf eine Boot CD brennen und dann völlig ohne 
Benutzung des Host Betriebssystems Platten klonen.
Dauert eine Weile, aber läuft zuverlässig.

Handeule schrieb:
> Auf dem PC läuft Windows XP, wie erstelle ich da jetzt die bootfähige CD
> für clonezilla?

Die kannst Du auf irgendeinem anderen PC erstellen. Du musst nur das 
ISO-Image herunterladen; neuere Windows-Versionen können das ohne 
zusätzliche Software auf eine CD brennen (nennt sich dann 
"Datenträgerabbild brennen").

Rufus Τ. F. schrieb:
> neuere Windows-Versionen können das ohne
> zusätzliche Software auf eine CD brennen

Falls dein XP nichts an Bord hat, um ISO zu brennen, gibts z.B. 
kostenlos 'DeepBurner' der sowas kann - allerdings musst du einen 
Brenner im System haben - logisch.

Handeule schrieb:
> Die Treibersoftware ist nicht mehr zu bekommen und muss
> unbedingt erhalten bleiben.

Aber ein Backup ist vorhanden?

Schreiber schrieb:
> Eine zweite Festplatte anschießen und alles mit dem Explorer
> rüberkopieren?!

Das ist kein "Klonen" und liefert vor allem keine bootfähige 
Betriebssysteminstallation.

Pete K. schrieb:
> Aber ein Backup ist vorhanden?

Dann hätte er ja kein Problem.

Sicherlich ließen sich sogar die Originaldisketten noch auftreiben. Die 
liegen wahrscheinlich in dem Schrank, in dem das ganze andere Zeug, das 
zu der Maschine gehört, aufbewahrt wird. Aber hast du schon mal versucht 
von einer 20 Jahre alten Diskette zu installieren?

Handeule schrieb:
> Wie sieht das denn aus, wenn ich auf die neue SSD Windows NT installiere
> und dann hergehe und mit dem Explorer das Betriebsprogramm mit allen
> Dateien herüberkopiere. Bekommt man so etwas zum laufen, bzw. was muss
> da wie geändert werden damit es lauffähig wird?

Könnte funktionieren. Du mußt aber alles, wirklich alles kopieren. Also 
auch System- und Hiddenfiles und vor allem die Registry.

Vielleicht lässt sich im Festplattencontroller deines Rechners aber auch 
ein Raid konfigurieren. Raid 1(Reliability) spiegelt die Festplatten.

Schreiber schrieb:
> Das geht meist schon, zumindest meine Win 3.11 Disketten sind noch
> lesbar.

Deine 3.11 Disketten braucht aber keiner.

dd kopiert Sektorweise, egal welches Filesystem verwendet wird. Lass es 
von jemandem machen, der Ahnung hat.
Dann ist das in 1h erledigt.

Handeule schrieb:
> mir bei clonezilla und obigem Vorgehen nicht?

Clonezilla basiert auf Linux und interessiert sich beim Kopiervorgang 
fürs NTFS nur genau so weit, als es beim Kopieren die ungenutzten Blöcke 
auslässt. Es wird kein Quellfilesystem gemounted, es werden keine Files 
davon kopiert und irgendwelche Filesystem-Checks sind optional. Im 
Grunde ein "dd" unter Auslassung ungenutzter Blöcke.

Man kann andererseits auch explizit fordern, dass wirklich reines "dd" 
verwendet wird, also besagte Optimierung bekannter Filesysteme nicht 
stattfindet.

guest schrieb:
> Prinzipiell geht das.

Wenn es denn gehen sollte, dann wird man dennoch eine NT CD benötigen, 
um im davon gebooteten Rettungssystem den Bootloader auf der Zieldisk zu 
installieren.

Handeule schrieb:
> Wie sieht das denn aus, wenn ich auf die neue SSD Windows NT installiere
> und dann hergehe und mit dem Explorer das Betriebsprogramm mit allen
> Dateien herüberkopiere. Bekommt man so etwas zum laufen,

Du kannst nicht über das laufende Windows drüber kopieren. Du kannst 
aber auf einer Partition mehrere Windows Instanzen installieren und im 
Bootmanager auswählen (via boot.ini). Wenn du das neue NT unter einem 
anderen Pfad installierst, dann kopierst du das ursprüngliche Windows 
nicht über das laufende Windows drüber und hast gewisse Chancen. Würde 
ich aber eher als Verzweiflungslösung zur Rettung von Files ansehen, mit 
Aussicht auf viel Gebastel hinterher.

A. K. schrieb:
> Wenn es denn gehen sollte, dann wird man dennoch eine NT CD benötigen,

Und wo ist da das Problem?
https://archive.org/details/Microsoft_Windows_NT_Workstation_4.0_Microsoft_1996

Michael B. schrieb:
> Und wo ist da das Problem?

Technisch keins. Der ganze Ansatz geht freilich von hinten durch die 
Brust in Auge. Image ist einfacher und sicherer.

Hi

Wenn DU (viel) Zeit hast, braucht 'dd' nur zwei übergebene Werte - die 
Quelle 'if=' und das Ziel 'of='.
Bei Linux heißen die Platten anders, z.B. /dev/sda (erste Festplatte)
Wenn Da noch Nummern dran hängen, bist Du bei den Partitionen - für 
einen kompletten Clon willst Du aber an das Laufwerk.

Linux ist nicht Windows!
Wenn Du Linux sagst, daß Du Die Platte gelöscht haben willst, dann macht 
Linux Das (sofern Du die Rechts dazu hast - in einem Live-System wirst 
Du diese Rechte aber haben).
Da kommen keine 12 Abfragen, ob Du Dir sicher bist - Linux vertraut Dir, 
Du bist der Boss!!
Das geht so weit, daß Linux erst die Arbeit einstellt, wenn die eigene 
Systemplatte 'leer' ist, solltest Du Dich entscheiden, das Linux sich 
selbst löschen zu lassen.
Unter Windows (nahezu ??) unmöglich, die System- oder Boot-Partition zu 
löschen. (bis 95,98,XP, jetzt noch virtuell Win7)

if INPUT F (F= ?? müsste nachschauen)
of OUTPUT F (dito)
Sowohl bei if wie bei of kann man eine Platte, eine Partition oder ein 
File angeben.
Der Fortschritt (wie lange dauert Das denn noch?? ... oder ... Sind wir 
schon daaa??) lässt sich per USR1 in einem weiteren Terminal abfragen.
Das Terminal, in Dem dd läuft, ist so lange beschäftigt, bis dd fertig 
ist!
Auch das Ausführen im Hintergrund (Anhängen eines &) hilft Dir nur 
bedingt - das Terminal muß offen bleiben, da sonst das dd-Komando 
'gekillt' wird.

Fragen zu Linux (im Näheren Ubuntu) lassen sich gut mit dem Ubuntu-Wiki 
'erschlagen'.
https://wiki.ubuntuusers.de/dd/

Dort sind im Forum spätestens auch dann passende 'Linuxer' unterwegs.


MfG

Patrick J. schrieb:
> Bei Linux heißen die Platten anders, z.B. /dev/sda (erste Festplatte)

Ich habe ein Serverlein laufen, bei dem dank verschiedener Controller 
für Boot- und Datendisks die Bootdisk je nach Laune des Systemstarts mal 
vor und mal nach der ersten Datendisk aufkreuzt, also mal als /dev/sda 
und mal als /dev/sdb.

Wenn man dann auch noch identische Disks für Quelle und Ziel verwendet, 
dann wirds fast Glücksache, ob man die Disk mit dd sichert oder plättet.

> Dort sind im Forum spätestens auch dann passende 'Linuxer' unterwegs.

Ich würde einem Linux-Laien nicht empfehlen, selbst dd zu verwenden. Es 
sei denn es ist egal, was man damit vernichten kann.

Aus ähnlichem Grund ist es auch sicherer, die Disk nicht direkt auf eine 
gleiche Zieldisk zu kopieren, sondern den Weg über ein Image-File auf 
anderen Medium zu gehen. Es reduziert die Verwechslungsgefahr ungemein.

Hi

A. K. schrieb:
> Aus ähnlichem Grund ist es auch sicherer, die Disk nicht direkt auf eine
> gleiche Zieldisk zu kopieren, sondern den Weg über ein Image-File auf
> anderen Medium zu gehen. Es reduziert die Verwechslungsgefahr ungemein.

Dem stimme ich im Ganzen zu!

Auch ist das Unterscheiden, welche physikalische Platte nun welchem 
Buchstabensalat entspricht, unter Windows schöner umgesetzt - rein 
subjektiv!
Hilft aber Nichts, wenn man Linux benutzt ;)

MfG

A. K. schrieb:
> Ich habe ein Serverlein laufen, bei dem dank verschiedener Controller
> für Boot- und Datendisks die Bootdisk je nach Laune des Systemstarts mal
> vor und mal nach der ersten Datendisk aufkreuzt, also mal als /dev/sda
> und mal als /dev/sdb.
>
> Wenn man dann auch noch identische Disks für Quelle und Ziel verwendet,
> dann wirds fast Glücksache, ob man die Disk mit dd sichert oder plättet.

ja...gnarf
das sorgt hier mit diversen Rechnern, die jeweils auch schonmal
mit unterschiedlichen Systemen gebootet werden
auch schon mal für Verwirrung.

Beim Anschluss neuer Laufwerke hilft ein

lsblk

Erstmal bevor man weitere Laufwerke anschliesst
und dann nochmal nachdem das nächste hinzu kommt.

das listet eine Art Verzeichnisbaum mit Laufwerken und Partitionen auf

an hiesigem Rechner grad so:

sda      8:0    0 232,9G  0 disk
├─sda1   8:1    0   1,9G  0 part [SWAP]
├─sda2   8:2    0    28G  0 part /
└─sda3   8:3    0   203G  0 part /home
sdb      8:16   0 149,1G  0 disk
├─sdb1   8:17   0   100M  0 part /media/desinfector/System-reserviert
├─sdb2   8:18   0  48,7G  0 part /media/desinfector/PROG
└─sdb3   8:19   0 100,2G  0 part

Das schliesst sogar für mich Unklarheiten aus,
wie das neue Laufwerk nun gerade "heisst".


sdb wird gleich geplättet - und wieder ein Windows weniger ;)

Handeule schrieb:
> Meine Anfangsfrage, wie
> ich mit einem Programm, dass unter NT läuft, eine SSD klonen kann, ist
> aber leider noch klar.

Wie meinen?

Handeule schrieb:
> Ja, zumindest habe ich nun eine Vorstellung, welche Dimension das
> annehmen kann, mal eben 1GB klonen zu wollen.

Das liegt natürlich auch ein Bisschen an dir. Je länger du grübelst und 
Bedenken trägst, desto verwirrender wird es.

für ältere Sachen bis max 2TB Plattengrösse
habe ich die besten Ergebnisse mit Acronis 11 erzielt.
Das älteste System war hier ein ca 20 Jahre altes OS/2
das sich klaglos clonen liess.

"High Performance Computing"
-oder wie hiess der Clonezilla-Laden noch?
ist für mich auch alleine schon
wegen der notigen Bedienschritte was anderes.
Aber das ist ja Geschmackssache, etliche mögen das ja,
wenn es unnötig kompliziert ist.

Du nimmst einen IDE-USB-Adapter.
Es gibt auch welche die SATA und die beiden IDE-Anschlüsse
(für DesktopPlatten und kleine Laptopplatten) haben.
Und idealerweise hat man 2 solcher Adapter.

Man bootet also einen Rechner mit genannter
Acronis-Version und clont das alte Laufwerk aufs neue.

Einiges läuft auf der neuen (grösseren???) Platte nur dann,
wenn man die Partitionsgrössen auf dem neuen Laufwerk so belässt,
wie sie auf dem Vorgänger waren, also 1:1 kopieren und nicht etwa
die grössen proportional anpassen oder so.

Für Acronis kann man Laufwerke an USB auch anschliessen,
wenn Acronis fertig geladen ist,
Die werden dann so nach ca 10sek automatisch erkannt und eingebunden.

michael_ schrieb:
> Beste Ergebnisse?
> Mehr als eine ordentliche HD-Kopie gibt es nicht.
> Keine Steigerung möglich.

im Sinne von keiner Fehlermeldung und am Ende lauffähige Clones oder 
Images.

btw kann Acronis ein Image von egal welchen Verzeichnissen heraus
holen und nicht nur aus dem Stammverzeichnis einer Backup-Platte.

sagen wir mal so:
in Momenten einer Datenverlust-Panik sollte ein Programm,
dass diese Daten wieder herstellen soll, möglichst übersichtlich sein.

und den User schon nicht nur für das Wort "Backup-Quelle"
 mit einem 3/4 Monitorbild voll mit Text dicht seiern.

● J-A V. schrieb:
> und den User schon nicht nur für das Wort "Backup-Quelle"
>  mit einem 3/4 Monitorbild voll mit Text dicht seiern.

Also doch "dd"? ;-)

Linux.
aber eben übersichtlich.
und nicht so'n Kommandozeilengequatsche.

● J-A V. schrieb:
> Linux.
> aber eben übersichtlich.
> und nicht so'n Kommandozeilengequatsche.

Für mich ist dieses "Kommandozeilengequatsche" ausgesprochen 
übersichtlich und obendrein extrem leistungsfähig, flexibel und 
effizient.

Tilo L. schrieb:
> 2. Live-Linux starten

Das auf dem Altrechner gestartete aktuelle Live-Linux startet eventuell 
wegen Speicherplatzmangel nicht.

Am sinnvollsten ist der Ausbau der Platte, Anschluss über Adapter an 
einem modernen Rechner und Erstellung eines 1:1-Duplikats, ob nun unter 
Windows oder Linux ist dabei letztlich egal.

Ungeachtet der beeindruckenden Fähigkeiten von TrueImage und ähnlicher 
Software sollte man die Erstellung von Komplett-Images aus einem 
laufendem System heraus vermeiden.

c-hater schrieb:
> Sheeva P. schrieb:
>
>> Für mich ist dieses "Kommandozeilengequatsche" ausgesprochen
>> übersichtlich
>
> Das ist es naturgemäß nicht.

Doch, ist es. Die Kommandos haben einfache und einprägsame Namen und 
klar definierte Parameter. Alle Buchstaben haben eine feste Höhe und 
Breite, es gibt keine Popupmenüs, scrollbars oder Fenster die wichtige 
Inhalte verdecken könnten, und man hat überall die gleiche in idealer 
Grösse eingestellte schrift.

>> effizient.
>
> Das dann wieder nicht. Denn bei der "Effizenz" muss man immer die Zeit
> einkalkulieren, die der Benutzer braucht. Und hier ist das
> Kommandozeilengeraffel einfach mal schwer im Nachteil.

Hier ist eher das Gegenteil der Fall. Das Tippen ist ein sehr schneller 
prozess, besonders zusammen mit der Autovervollständigung, und man muss 
nicht warten bis ein Fenster oder Menu aufgeht, Fenster verschieben und 
herumscrollen. Im vergleich dazu ist das Maus verschieben, Klicken und 
auf Menus warten bei GUIs sehr langsam.

Und wenn man in der shell mal etwas häufiger braucht schreibt man die 
Befehle einfach in ein script, oder erstellt einen alias, oder 
automatisiert es anderweitig. Und falls man mal viele Dateien ändern 
muss nimmt man einfach eine schleife oder das find Kommando, je nach 
Anwendungsfall. Mit GUI programmen kommt man dort meist nicht weit.

> Das ändert sich nicht einmal nennenswert, wenn man das Programm und
> seine Konzepte schon recht gut kennt. Klar, für die üblichen Anwendungen
> eines häufig verwendeten Programms weiss man natürlich aus dem Kopf, was
> man eintippen muss.

Ein gutes Programm erfüllt genau einen Zweck, und meistens ist es 
ausreichend die wichtigsten ~10 zu kennen. Ausserdem sind die meisten 
Programme sehr intuitiv. Eigentlich schreibt man einfach nur hin, was 
man will.

> Aber wehe, es ist ein eher ungewöhnliche Anwendung. Kein Mensch kann
> sich alle Optionen und Parameter tausender Kommandozeilenprogramme
> merken.

Muss man auch nicht, es gibt ja man pages. Ausserdem bezweifle ich, dass 
jemals jemand in seinem leben derart viele unterschiedliche Programme 
aufrufen musste. Und das selbe Problem trifft auch GUI Programme, dort 
muss man das UI auch erst lernen. Versuche mal deine Arbeitsprogramme 
durch alternativen zu ersetzen, oder etwas spezielles damit zu machen, 
und verschwende deine Zeit damit frustriert den richtigen Menüeintrag 
nicht zu finden.

> Auch DU nicht.

Kannst du das beweisen?

> Und dann wird's sehr schnell sehr ineffizient...
>
> Beispiel: Du erstellst irgendwann ein Image eine kompletten Platte, also
> irgendwie sowas:
>
> dd if=/dev/sda of=~/sda.img bs=1M
>
> Einfach und effizent (aber auch nur, wenn man regelmäßig dd benutzt und
> deshalb bei solchem Standardkram nix nachlesen muss).
>
> Aber jetzt kommt die Aufgabe: Erstelle aus dem Image wieder eine
> physische Platte, bei der aber z.B. sda2 und sda7 ihre Inhalte(und damit
> ihre Größe) tauschen (der Grund für dieses Ziele sei jetzt mal
> unwichtig). Wetten, dass auch du eine ganze Weile brauchst, bis du die
> nötigen dd-Zeilen zusammengestoppelt hast?
>
> Und ja: das geht tatsächlich allein mit dd. Also wirklich nachweislich
> ein extrem leistungsfähiges und flexibles Programm.

Dazu müsste man die Partitionstabelle anpassen, das geht mit dd alleine 
nicht. Mit fdisk oder gdisk würde das gehen. Und dann ist es doch viel 
sicherer losetup -fP --show zu verwenden, statt sich mit den skip, 
offset, bs, und count optionen von dd herumzuschlagen. Man könnte dann 
meistens sogar ganz auf dd verzichten, und mount & cp -a verwendet, ist 
es sogar noch sicherer und einfacher.

> Aber nein, es ist nicht wirklich effizient, wenn man die aufgewandte
> Gesamtzeit betrachtet...

Ich mache sowas gelegentlich nebenher. Hier mal noch ein anderes 
scenario:
Ich hatte einmal ein image mit GPT Partition von einem Smartphone, bei 
dem die Sektorgrösse 4092 bytes gross war, aber mein PC war auf normale 
512 bytes eingestellt. Es gab darin mehrere Partitionen mit falschem 
Partitionstyp in ext4. Versuche mal ein GUI Programm zu finden, das 
damit umgehen kann, und Dateien daraus entpacken und wieder hinein 
packen kann. Und aus unerfindlichen gründen soll es dann noch 
automatisiert werden. Da so ein GUI programm vermutlich nicht existiert 
ist dieses Szenario unendlich ineffizient.

> Das geht z.B. mit gparted viel schneller (obwohl die eigentliche
> Operation deutlich länger als nötig dauert). Sprich: Weniger
> leistungsfähig, aber insgesamt trotzdem deutlich effizienter, weil es
> halt dem Benutzer Arbeit abnimmt. Das genau ist aber eigentlich der Sinn
> von Computern, die sind kein Selbstzweck!

Du kannst mit gpartet weder Partitionen tauschen noch images 
wiederherstellen.

gibt es mittlerweile eine Version von CZ,
die mit allen Prozessoren (ob i386 oder AMD) klar kommt?

hat ggf einer einen Tipp, wie man das auf ein Boot-Medium bekommt?

c-hater schrieb:
> Sheeva P. schrieb:
>
>> Für mich ist dieses "Kommandozeilengequatsche" ausgesprochen
>> übersichtlich
>
> Das ist es naturgemäß nicht.

Aber ja doch. Für jeden Pippifax immer wieder ein anderes ein spezielles 
GUI-Werkzeug mit jeweils einem immer wieder neuen "originellen" 
Look&Feel installieren und lernen zu müssen, ist oft viel 
unübersichtlicher als die konstante und konsistente Optik und Haptik 
einer Kommandozeile. BTDT.

Und genau was, bitte, hast Du an "für mich" nicht verstanden? Du kennst 
weder mich, noch meine Aufgaben, und bestenfalls einen überschaubaren 
Teil der Software, die ich benutze. Wie kommst Du nur darauf, mir etwas 
darüber erzählen zu können, was ich täglich mache, wie ich es wahrnehme, 
und wie effizient das am Ende des Tages ist? Aber diese Mischung aus 
Herablassung und Anmaßung gehört wohl dazu, wenn man sich ausweislich 
seines Nickname über die herzlich gepflegte Abneigung gegenüber einem 
der verbreitetsten Programmierwerkzeuge definiert.

>> und obendrein extrem leistungsfähig, flexibel und
>
> Das allerdings schon
>
>> effizient.
>
> Das dann wieder nicht. Denn bei der "Effizenz" muss man immer die Zeit
> einkalkulieren, die der Benutzer braucht. Und hier ist das
> Kommandozeilengeraffel einfach mal schwer im Nachteil.

Eben nicht. Mit Kommandozeilen können etliche leistungsfähige Werkzeuge 
sehr flexibel mit einander kombiniert werden, und dadurch unendlich 
viele Aufgaben effizient gelöst werden. Mit GUI-Werkzeugen lassen sich 
dagegen nur jene Aufgaben lösen, die deren Hersteller vorgesehen haben, 
und alle anderen gar nicht oder nur mit aufwändigen Verrenkungen, auch 
dann, wenn sie nur leicht von den vorgesehenen abweichen. Daher bringen 
mittlerweile viele GUI-Tools heute eine Skriptsprache, 
Automatisierungsschnittstelle oder oft sogar eine eigene Kommandozeile 
mit. Sogar Microsoft hat das mittlerweile erkannt und liefert in 
aktuellen Versionen seiner Software sowohl eine leistungsfähige 
Kommandozeile ("PowersHell" heißt das wohl, glaube ich) als auch 
Schnittstellen dafür, YMMV. ;-)

In anderen Anwendungsfällen kommt hinzu, daß Benutzereingaben sogar auf 
der Kommandozeile viel schneller von der Hand gehen. "less datei.txt" 
kann man sogar ohne Tab-Completion schneller eingeben, als Du Dich im 
Startmenü zum Link für Word geklickt hast, von Ladezeiten dieses 
Programms und der darauf folgenden Klickorgie zum Öffnen der Datei ganz 
zu schweigen. Offenbar sind viele kleine, aber alltägliche Aufgaben auf 
der Kommandozeile schon gelöst, bevor ein GUI auch nur gestartet wäre.

Von den Limitierungen von GUIs bei der Verarbeitung größerer Datenmengen 
will ich gar nicht erst anfangen. Bei den meisten GUI-Werkzeugen stecken 
ca. 90% des Code in der GUI, welche so leider auch 90% der Fehler 
enthält und mitunter den größten Teil der Laufzeit und Ressourcen 
beansprucht.

> Das ändert sich nicht einmal nennenswert, wenn man das Programm und
> seine Konzepte schon recht gut kennt. Klar, für die üblichen Anwendungen
> eines häufig verwendeten Programms weiss man natürlich aus dem Kopf, was
> man eintippen muss. Dann geht's dann schnell, zumal man ja die
> Eingabe-Vervollständigung oft nutzen kann.
>
> Aber wehe, es ist ein eher ungewöhnliche Anwendung. Kein Mensch kann
> sich alle Optionen und Parameter tausender Kommandozeilenprogramme
> merken. Auch DU nicht. Und dann wird's sehr schnell sehr ineffizient...

Indem ich die Aus- und Eingaben von Kommandozeilenprogrammen miteinander 
kombinieren kann, brauche ich gar keine "tausende Programme", sondern 
kann auf einen bewährten Fundus einiger Dutzend Programme zurückgreifen 
und sie flexibel miteinander kombinieren, um wesentlich kompliziertere 
Aufgaben zu lösen, als die Einzelprogramme das könnten. Deswegen muß ich 
mir nicht für jede Aufgabe ein eigenes Programm suchen (sowie ggf auch 
noch evaluieren) und seine Bedienung erlernen, was den scheinbaren 
Vorteil der schnelleren Erfaß- und Erlernbarkeit bei GUI-Werkzeugen oft 
wieder zunichte macht.

> Aber jetzt kommt die Aufgabe:

Es ist ebenso einfach wie billig, sich einen Anwendungsfall zusammen zu 
stoppeln, in dem ein ganz bestimmtes, für haargenau diesen 
Anwendungsfall entwickeltes GUI-Programm wie gparted einen Vorteil hat. 
Genauso einfach und billig wäre es natürlich meinerseits, mir einen 
ähnlich hanebüchenen Anwendungsfall etwa für find -exec, xargs oä. zu 
konstruieren, an dem noch Deine Enkel herum klicken würden. Deswegen 
werde mich nicht auf derartige Kindereien einlassen, sondern beschränke 
mich auf die Feststellung, daß die praktische Relevanz Deines Beispiels 
mehr als fragwürdig ist. Das scheint Dir aber auch selbst schon klar 
geworden zu sein, immerhin.

> Das geht z.B. mit gparted viel schneller (obwohl die eigentliche
> Operation deutlich länger als nötig dauert).

Probier' das mit Deinem gparted-Beispiel doch mal mit einem Stapel von 
zwei oder mehr Disks aus einer Cloud oder einem Cluster. Dafür brauche 
ich dann nämlich immer noch nur diese eine einzige Kommandozeile, die 
ich mir genau einmal "zusammengestoppelt" habe. Damit bin ich längst 
fertig, während Du Dir mit Deinem gparted-Beispiel immer noch die Finger 
wund klickst. ;-)

> Sprich: Weniger
> leistungsfähig, aber insgesamt trotzdem deutlich effizienter, weil es
> halt dem Benutzer Arbeit abnimmt. Das genau ist aber eigentlich der Sinn
> von Computern, die sind kein Selbstzweck!

Dabei kommt es auf das Ziel an: wenn es darum geht, einen ausgefallenen 
Rechner oder gar einen Cluster möglichst schnell wieder zum Laufen zu 
bringen, ist die dd-Version wesentlich effizienter. Und sobald dieselbe 
Aufgabe mehrmals erledigt werden muß, auch bei den Benutzereingaben.

Aber, wie schon in meinem vorigen Beitrag und auch hier wieder erwähnt: 
das alles gilt lediglich für mich und die vielen verschiedenen und 
vielfältigen Aufgaben, die mir im täglichen Betrieb begegnen. Wenn Du 
Dir einen Fundus an GUI-Werkzeugen zusammengesucht und erlernt hast, die 
perfekt auf Deine Anwendungsfälle passen, mag das für Dich zwar anders 
aussehen. Aber daß Du glaubst, allgemeingültige Aussagen über meine 
Arbeitsumgebung treffen zu können, ohne meine Aufgaben, meine 
Arbeitsweise, oder gar mich zu kennen, ist am Ende nur noch lächerlich.

apropos verteidigen...