The Unix Haters Handbook

[Linux-User]

nman schrieb:

Aber so ein zwei-stufiger Löschprozess wäre schon eine tolle Sache, d.h. alle Dateien sind so lange abrufbar bis das Dateisystem den Speicher benötigt. Wobei das ja in ein paar Jahren unter Linux Einzug erhält mit Btrfs oder Logfs (ich glaube Tux3 wird das auch unterstützten). Da hat man dann versioning.

Wenn Du Verzeichnisse versioniert haben möchtest, dann pack sie doch in ein Versionskontrollsystem. Oder mach versionierte Backups.

Klar kann man das, aber es geht nicht automatisch. Ich habe normal mehr als genug freien Diskspace den das Dateisystem für ein paar Diffs und gelöschte Dateien zeitweise benutzen könnte.

Ein versioniertes Dateisystem hatte zB VMS schon und ich trauere dem nicht hinterher. Hatte natürlich seine Vorteile, aber auch massig Nachteile.

Was sind die Nachteile?

rm ist nunmal eine sehr endgültige Sache; es gab da auch ein Projekt, mit einer Art rm-Papierkorb, der über die libc reingepatcht wurde, aber im Grunde sollte sowas IMO das GUI regeln.

Diese Patches kenne ich, aber so wie ich gehört habe gibt es trotzdem noch Fälle wo Dateien gelöscht werden ohne, dass diese gepatchten Routinen das erledigen. Und das schlimmste ist wenn man sich in falscher Sicherheit wiegt, auch wenn selbst nach jahrelangem Windows-Einsatz noch heute den Papierkorb kaum benutze (lösche meist direkt, oder leere den Papierkorb danach). Allerdings passiert es einem in einer GUI nicht so leicht, dass man falsche Dateien löscht.
Daher wäre so eine kleine Hilfe bei rm schon nicht schlecht, so lange man nicht eine "kann es ja sowieso wiederherstellen"-Mentalität entwickelt.

(Ich glaube, übrigens dass Du ein Feature von Btrfs falsch verstanden hast, ich verfolge das recht interessiert, kann mich aber nicht an das erinnern, was Du zu meinen scheinst. Bei Tux3 _glaube_ ich das auch, kenne mich aber nicht besonders aus und von Logfs weiß ich praktisch nichts.)

Ok, die Snapshots sind nicht das Selbe wie Versioning, aber ein bischen helfen kann es trotzdem (wobei ich denke, dass es nicht mit den Checkpoints bei LogFS mithalten kann, da sind die Kosten quasi 0 für das Erstellen eines Checkpoints).
Auf LWN.net findest du einen kleinen Artikel über LogFS: http://lwn.net/Articles/234441/

[quote]

Hier ging es um die Fehlerausgabe, nicht die Abfolge der Kommandos selbst.

Ach so. Naja, ein Verzeichnis ist eben eine Datei.

Ist mir schon klar, aber halt ein technisches Detail das hier leakt. Ein normaler User muss das nicht wissen (bzw. sollte es nicht wissen müssen).

So findet man manchmal etwas in man, häufig ist die Dokumentation aber stark abgespeckt mit der Info, dass man die offizielle Doku in "info" findet und dort dann nur die selbe man-page Seite zu Gesicht bekommt, weil die Distribution die info-Seiten nicht mitausliefert.

Das ist eine GNU-Krankheit. Die BSDs haben richtig gute Manpages, die GNU-Leute wollen nur ihre Info-Seiten pflegen. Info halte ich allerdings auch für unschön, da gefällt mir man wesentlich besser. (Insbesondere ist der Standard-Info-Browser furchtbar, wenn ich nicht Emacs-User wäre, wäre Info für mich völlig unbenutzbar.)

Was findest du an Info so schlecht? Ich hatte vor einiger Zeit keine Meinung dazu, dann habe ich angefangen "The Linux System Administration Handbook" zu lesen und dort wurde es total niedergemacht. Danach dachte ich "boah wie schlecht das Ding sein muss" (ok, damals hatte ich mit info auch nie was anfangen können, wenn mich eine Manpage mal wieder auf diese verwies). Und dann habe ich angefangen Emacs zu benutzen und die Info Seiten zu schätzen gelernt. Finde diese Baum-artige Struktur mit den Links und allem echt toll. Wie kann es sein, dass du mit Emacs Info nutzen kann und ohne nicht? Das Kommandozeilen-Toll hat doch die gleichen Shortcuts

Versteht mich nicht falsch; Unix hat einige ernsthafte, große Schwierigkeiten. Aber statt echte fundamentale Probleme aufzuzählen, ergeht sich das Buch größtenteils darin, über oberflächlichen Kleinscheiß zu motzen und herumzutrollen.

Viel spannender und gehaltvoller finde ich da das entsprechende Kapitel von ESRs "The Art of Unix Programming": http://www.faqs.org/docs/artu/futurechapter.html

Werde ich als nächstes lesen. Bisher habe ich mir noch nie Gedanken darüber gemacht was an Unix schlecht ist, daher habe ich hier noch keine große Meinung dazu.

[Linux-User]

Oh ganz vergessen. Aus dem Buch:

No File Types
To UFS and all Unix-derived file systems, files are nothing more than long
sequences of bytes. (A bag’o’bytes, as the mythology goes, even though
they are technically not bags, but streams). Programs are free to interpret
those bytes however they wish. To make this easier, Unix doesn’t store
type information with each file. Instead, Unix forces the user to encode this
information in the file’s name! Files ending with a “.c” are C source files,
files ending with a “.o” are object files, and so forth. This makes it easy to
burn your fingers when renaming files.
To resolve this problem, some Unix files have “magic numbers” that are
contained in the file’s first few bytes. Only some files—shell scripts, “.o”
files and executable programs—have magic numbers. What happens when
a file’s “type” (as indicated by its extension) and its magic number don’t
agree? That depends on the particular program you happen to be running.
The loader will just complain and exit. The exec() family of kernel func-
tions, on the other hand, might try starting up a copy of /bin/sh and giving
your file to that shell as input.

Also ich finde deren Vorschlag (Dateityp als Attribut der Datei) hat keine Vorteile gegenüber dem Unix-Weg zur Erkennung einer Datei. Ein Dateiattribut kann genau so falsch sein wie eine Dateiendung und ein gutes Programm sollte eine Datei anhand ihres Inhaltes bewerten und nicht nach einer Endung oder einem Attribut. Bei dem Punkt mit dem Umbenennen muss ich denen aber Recht geben. Allerdings kann Thunar (Dateimanager) beim Umbenennen automatisch alles bis auf die Dateiendung markieren, so kann man die Dateien leicht umbenennen ohne, dass man die Endung wiederholen muss (könnte sich der Windows Explorer mal abschauen). Ich sehe hier das Problem weniger im Design als in den Tools.
Unter den GUIs ist es bereits realität und in der Shell könnte man ein Tool schreiben das so arbeitet (und für diese eine eigene bash-completion). Wobei ich mir jetzt erst einmal rename anschauen muss

[Christian Steifen]

Linux-User schrieb:

Ein normaler User muss das nicht wissen (bzw. sollte es nicht wissen müssen).

Wenn der Benutzer ach so normal ist, dann soll er eben auch seine Finger von den Shells lassen...

[Ben04]

Also ich weiß ehrlich gesagt nicht, was an einem nicht löschendem rm so toll sein soll. Ich habe Win wesentlich länger verwendet als Linux und habe nicht gelernt den Papierkorb zu lieben. Um ehrlich zu sein nervt der mehr als er mir nützt. In all den Jahren habe ich ziemlich genau 0 Dateien da wieder ausgegraben. Da finde ich rm eigentlich toll so wie es ist. Wenn ich ein Backup will, dann nenne ich die Datei um und lösche sie halt nicht.

Entweder ich brauche die Datei vielleicht noch dann umbenennen oder ich brauch sie nicht mehr und lösche sie. Löschen und dann die Daumen drücken, dass das FS die Dateien doch nicht überschrieben hat ist Blödsinn.

[Mr. N]

Ben04 schrieb:

Wenn ich ein Backup will, dann nenne ich die Datei um und lösche sie halt nicht.

Oder du machst richtige Backups...

[nman]

Linux-User schrieb:

Wenn Du Verzeichnisse versioniert haben möchtest, dann pack sie doch in ein Versionskontrollsystem. Oder mach versionierte Backups.

Klar kann man das, aber es geht nicht automatisch.[/quote]
Doch, natürlich. TimeMachine macht das sehr hübsch, mein geliebtes man: rdiff-backup oä. bei Bedarf auch und für Git und Konsorten gibts auch fertige automatische Versionierungslösungen. Alle genannten Optionen sind wesentlich besser als die VMS-Versionierung es je war, auch wenn die VMS-Variante sehr elegant wirkt.

Was sind die Nachteile?

- Performancetechnisch war das katastrophal. Häufig hat man die Versionierung komplett abgeschalten und sie dann gezielt für einzelne Verzeichnisse wieder aktiviert, was auch nicht "automatischer" ist als die oben aufgezählten Lösungen.

- Du musstest die Anzahl von alten Versionen, angeben. Du wusstest also nie genau, wie lange die alte Version einer Datei wieder herstellbar ist. (Mit Git ist alles wieder herstellbar, mit TimeMachine alles, solange der Speicherplatz Deines Backupmediums reicht und mit rdiff-backup entweder auch die letzten n Versionen, oder - viel besser - alle Versionen der letzten m Wochen.)

- Teilweise war Files-11 ziemlich inkonsistent; Renames zB. waren immer wieder komisch und manches war einfach nur unintuitiv.

Diese Patches kenne ich, aber so wie ich gehört habe gibt es trotzdem noch Fälle wo Dateien gelöscht werden ohne, dass diese gepatchten Routinen das erledigen.

Nein, eigentlich funktionierte das ziemlich fein. Wie gesagt, da wurde damals wirklich die glibc zurechtgepatcht.

Allerdings passiert es einem in einer GUI nicht so leicht, dass man falsche Dateien löscht.

In einer vernünftig konfigurierten Shell auch nicht. Ich verwende zsh und lasse mir dort meine Wildcards beim Löschen immer per TAB inline expandieren. Wenn ich das vergesse und trotzdem ein Wildcard in Verbindung mit rm verwende, dann fragt mich zsh, ob ich mir sicher bin, dass ich das machen möchte.

Wenn man Midnight Commander oä. verwendet (empfehlenswert), stellt sich das Problem auch nicht.

Ok, die Snapshots sind nicht das Selbe wie Versioning, aber ein bischen helfen kann es trotzdem

Genauso sehr wie Git und die sonstigen oben genannten Alternativen.
(Nein, ich weiß schon, dass das praktisch wird, mag das bei ZFS ja auch sehr gerne. Habe dennoch zwei Einwände: 1. ist das auch nicht "automatisch" und 2. werden diese Dateisysteme gerade für ein Unix-Derivat entwickelt, offenbar ist das also nichts, was mit Unix konzeptionell unvereinbar wäre.)

Auf LWN.net findest du einen kleinen Artikel über LogFS: http://lwn.net/Articles/234441/

Hab ich irgendwann schon gelesen. Aber irgendwie kam mir das relativ tot vor und ich dachte, dass das primär für SSDs gedacht sei.

Ist mir schon klar, aber halt ein technisches Detail das hier leakt. Ein normaler User muss das nicht wissen (bzw. sollte es nicht wissen müssen).

Aber "normale User" verwendeten früher doch schon Midnight Commander & Co. bzw. verwenden jetzt eben GUIs.

Was findest du an Info so schlecht?

Ich finde einseitige, hübsch strukturierte Manpages mit Beispielen viel besser als Info, weil sie sich viel besser eignen um schnell mal was nachzulesen. Bei Info muss ich mich durch eine völlig überflüssige Hierarchie durchhangeln, die nur für "von vorne bis hinten alles vollständig durchlesen" passend ist.

Normalerweise tue ich das aber nicht, sondern möchte einfach nur eine schnelle Referenz, bzw. wenn ich etwas langes zu einem richtig komplizierten Stück Software lesen möchte, bevorzuge ich ohnehin PDF oä., weil sich das viel hübscher auf toten Baum bannen lässt und ich es auch auf Windows-Rechnern, Mobiltelefonen etc. gut lesen kann.

Wie kann es sein, dass du mit Emacs Info nutzen kann und ohne nicht? Das Kommandozeilen-Toll hat doch die gleichen Shortcuts

Trotzdem ist info(1) ein mieserabler Info-Browser und Emacs ein halbwegs akzeptabler Info-Browser. Du sagst doch selbst, dass Du Info erst verwendest, seit Du Emacs benutzt.

Bisher habe ich mir noch nie Gedanken darüber gemacht was an Unix schlecht ist, daher habe ich hier noch keine große Meinung dazu.

Das haben die Autoren des Unix Haters' Handbook IMO auch nicht, aber im Unterschied zu Dir geht es Ihnen offenbar nur um Herumgetrolle. Und das öfters zu wiederholen, macht es nicht richtiger und aktueller.

[Linux-User]

Ben04 schrieb:

Also ich weiß ehrlich gesagt nicht, was an einem nicht löschendem rm so toll sein soll. Ich habe Win wesentlich länger verwendet als Linux und habe nicht gelernt den Papierkorb zu lieben. Um ehrlich zu sein nervt der mehr als er mir nützt. In all den Jahren habe ich ziemlich genau 0 Dateien da wieder ausgegraben. Da finde ich rm eigentlich toll so wie es ist. Wenn ich ein Backup will, dann nenne ich die Datei um und lösche sie halt nicht.

Entweder ich brauche die Datei vielleicht noch dann umbenennen oder ich brauch sie nicht mehr und lösche sie. Löschen und dann die Daumen drücken, dass das FS die Dateien doch nicht überschrieben hat ist Blödsinn.

Es geht hier nicht um das alltägliche Löschen, sondern um versehentliches löschen, z.B. ein rm *.c statt einem vermeintlichen rm *.d

[Linux-User]

nman schrieb:

Linux-User schrieb:

Wenn Du Verzeichnisse versioniert haben möchtest, dann pack sie doch in ein Versionskontrollsystem. Oder mach versionierte Backups.

Klar kann man das, aber es geht nicht automatisch.

Doch, natürlich. TimeMachine macht das sehr hübsch, mein geliebtes man: rdiff-backup oä. bei Bedarf auch und für Git und Konsorten gibts auch fertige automatische Versionierungslösungen. Alle genannten Optionen sind wesentlich besser als die VMS-Versionierung es je war, auch wenn die VMS-Variante sehr elegant wirkt.
[/quote]
Das kannte ich noch nicht, werde ich gleich ausprobieren

Allerdings passiert es einem in einer GUI nicht so leicht, dass man falsche Dateien löscht.

In einer vernünftig konfigurierten Shell auch nicht. Ich verwende zsh und lasse mir dort meine Wildcards beim Löschen immer per TAB inline expandieren. Wenn ich das vergesse und trotzdem ein Wildcard in Verbindung mit rm verwende, dann fragt mich zsh, ob ich mir sicher bin, dass ich das machen möchte.

zsh wollte ich früher schon einmal verwenden, aber da gab es ein paar Dinge die ich bei bash habe und zsh nicht (dummerweise ist das schon recht lange her und ich kann mich nicht mehr daran erinnern, ich glaub da war was mit den Emacs shortcuts oder so). Kann zsh inzwischen Unicode?

Wenn man Midnight Commander oä. verwendet (empfehlenswert), stellt sich das Problem auch nicht.

Ok, die Snapshots sind nicht das Selbe wie Versioning, aber ein bischen helfen kann es trotzdem

Genauso sehr wie Git und die sonstigen oben genannten Alternativen.
(Nein, ich weiß schon, dass das praktisch wird, mag das bei ZFS ja auch sehr gerne. Habe dennoch zwei Einwände: 1. ist das auch nicht "automatisch" und 2. werden diese Dateisysteme gerade für ein Unix-Derivat entwickelt, offenbar ist das also nichts, was mit Unix konzeptionell unvereinbar wäre.)

In dem Fall ist das tatsächlich einigermaßen weniger relevant, aber für Backups sind die Snapshots schon praktisch, da kann man zu einem Zeitpunkt mit wenig Last (oder kurz in single user mode fahren) ein Snapshot erstellen und das Backup dann in Ruhe im laufenden Betrieb erstellen, ohne Angst für inkonsistenzen in Dateien haben zu müssen

Auf LWN.net findest du einen kleinen Artikel über LogFS: http://lwn.net/Articles/234441/

Hab ich irgendwann schon gelesen. Aber irgendwie kam mir das relativ tot vor und ich dachte, dass das primär für SSDs gedacht sei.

Ist es auch, aber finde es trotzdem interessant, weshalb ich es hier erwähnt habe.

Was findest du an Info so schlecht?

Ich finde einseitige, hübsch strukturierte Manpages mit Beispielen viel besser als Info, weil sie sich viel besser eignen um schnell mal was nachzulesen. Bei Info muss ich mich durch eine völlig überflüssige Hierarchie durchhangeln, die nur für "von vorne bis hinten alles vollständig durchlesen" passend ist.

Normalerweise tue ich das aber nicht, sondern möchte einfach nur eine schnelle Referenz, bzw. wenn ich etwas langes zu einem richtig komplizierten Stück Software lesen möchte, bevorzuge ich ohnehin PDF oä., weil sich das viel hübscher auf toten Baum bannen lässt und ich es auch auf Windows-Rechnern, Mobiltelefonen etc. gut lesen kann.

Wie kann es sein, dass du mit Emacs Info nutzen kann und ohne nicht? Das Kommandozeilen-Toll hat doch die gleichen Shortcuts

Trotzdem ist info(1) ein mieserabler Info-Browser und Emacs ein halbwegs akzeptabler Info-Browser. Du sagst doch selbst, dass Du Info erst verwendest, seit Du Emacs benutzt.

Das stimmt schon Der Hauptgrund warum man unter Emacs Info nutzen kann ist wohl C-h b um zu sehen wie man darin navigiert
Du kannst aber auch Info-Seiten am Stück lesen, einfach info node|less Oder mit -o einen gesamten Knoten in eine Datei umleiten. Also ich find es echt nicht schlecht, gerade libtool oder automake, da hab ich die Dokumentation direkt in Emacs sauber navigier- und durchsuchbar.
Für eine schnelle Übersicht, d.h. wenn man das Tool schon kennt hast du natürlich recht, da ist man schon besser. Gerade die system calls, da sind mir die man-pages schon lieber und mit woman in Emacs kann man die meisten ja auch in einem verlinkten Format anschauen.

So jetzt werde ich erst einmal The Art of Unix Programming lesen

[nman]

Linux-User schrieb:

Das kannte ich noch nicht, werde ich gleich ausprobieren

Lies insbesondere auch irgendwas zu Versionskontrolle mit Git; Pro Git zB. dürfte recht gut sein.

zsh wollte ich früher schon einmal verwenden, aber da gab es ein paar Dinge die ich bei bash habe und zsh nicht

Echt? Kann ich mir fast nicht vorstellen.

Kann zsh inzwischen Unicode?

Ja, seit 4.3.irgendwas.

In dem Fall ist das tatsächlich einigermaßen weniger relevant, aber für Backups sind die Snapshots schon praktisch, da kann man zu einem Zeitpunkt mit wenig Last (oder kurz in single user mode fahren) ein Snapshot erstellen und das Backup dann in Ruhe im laufenden Betrieb erstellen, ohne Angst für inkonsistenzen in Dateien haben zu müssen

Äh, Moment, halt: Angst vor Inkonsistenzen in Dateien habe ich sowieso nicht, weil alle auf rsync-basierenden Backup-Lösungen ziemlich Racecondition-frei sein sollten.
Was natürlich nix daran ändert, dass Snapshots toll sind und ich mich auf btrfs freue.

Du kannst aber auch Info-Seiten am Stück lesen, einfach info node|less

Ah, nett, das kannte ich noch gar nicht. Wobei sich "info gcc | less" jetzt auch nicht so prickelnd liest.

Also ich find es echt nicht schlecht, gerade libtool oder automake, da hab ich die Dokumentation direkt in Emacs sauber navigier- und durchsuchbar.

Wie gesagt, für Emacs-User geht das ja schon, ich hab ja auch meine SICP-Kopie im texi-Format, aber das ist doch eine ziemlich derbe Einstiegshürde nur zum Doku lesen.

So jetzt werde ich erst einmal The Art of Unix Programming lesen

Ja, tu das, das ist ein sehr feines Buch, das vieles an der Geschichte und Philosophie von Unix ein bisschen klarer werden lässt. Wobei sich in den letzten paar Jahren natürlich ein paar Sachen getan haben, die das Buch noch nicht berücksichtigt.

[nman]

Ach ja, falls Du zsh ausprobieren möchtest, hol Dir am besten das zsh-Setup von grml:

wget -O .zshrc http://git.grml.org/f/grml-etc-core/etc/zsh/zshrc

[u-ser_l]

Ben04 schrieb:

Also ich weiß ehrlich gesagt nicht, was an einem nicht löschendem rm so toll sein soll.

frage ich mich auch.

Mit

alias rm='/bin/rm -i'
alias cp='/bin/cp -i'

schützt sich der user vor der eigenen Schusseligkeit, wenn er sich zur
Angewohnheit macht, bei Nachfragen dieser Art die Zeile auch wirklich zu prüfen, ohne instinktiv "y" zu tippen.

Wichtige Dateiversionen kann man zB mit einem simplen Skript unter Anhängen des
Änderungsdatums an den Dateinamen in ein allgemeines backup-Vz kopieren.

Vorteil: nur die wichtigen Dateien werden aufbewahrt, Leerung überflüssig.

[Linux-User]

nman schrieb:

Linux-User schrieb:

Das kannte ich noch nicht, werde ich gleich ausprobieren

Lies insbesondere auch irgendwas zu Versionskontrolle mit Git; Pro Git zB. dürfte recht gut sein.

Das Buch bin ich bereits am lesen, bzw. habe es mal angefangen. Aber die Grundlagen von git kann ich bereits, d.h. zum lokalen Arbeiten reicht es schon vollkommen.

Also ich find es echt nicht schlecht, gerade libtool oder automake, da hab ich die Dokumentation direkt in Emacs sauber navigier- und durchsuchbar.

Wie gesagt, für Emacs-User geht das ja schon, ich hab ja auch meine SICP-Kopie im texi-Format, aber das ist doch eine ziemlich derbe Einstiegshürde nur zum Doku lesen.

Soweit mir das bekannt ist kann man texi doch ohne Probleme auch nach PS oder PDF übersetzen. Aber dir ging es ja auch um Info und nicht texi

So jetzt werde ich erst einmal The Art of Unix Programming lesen

Ja, tu das, das ist ein sehr feines Buch, das vieles an der Geschichte und Philosophie von Unix ein bisschen klarer werden lässt. Wobei sich in den letzten paar Jahren natürlich ein paar Sachen getan haben, die das Buch noch nicht berücksichtigt.

Habe es Gestern Abend angefangen und direkt die ersten zwei Kapitel am Stück verschlungen. Macht echt Spaß das Buch zu lesen

Nochmal zurück zum Thema: findet ihr es gut oder schlecht, dass Unix Dateien nur als eine Ansammlung von Bytes betrachtet? Beide Bücher haben das schon angesprochen, das Haters Book in einem sehr schlechten Ton, taoup bisher ohne Wertung.
Ich glaube, dass es essentiell für Unix ist, denn wenn Dateien nicht einfache Byte-Ströme wären, dann könnte man nicht die I/O-Streams, (echte) Dateien, Sockets, character- und block devices als Dateien modellieren und alles über eine Schnittstelle ansprechen. Und wenn es etwas gibt, das ich als Programmierer wirklich gut finde, dann die Tatsache, dass ich überall wo ich eine Datei benötige genau so gut eine fifo, socket, datei oder standardausgabe angeben kann (man denke z.B. an frprintf das funktioniert mit allem das als FILE handle darstellbar ist).

[DEvent]

Was natürlich nix daran ändert, dass Snapshots toll sind und ich mich auf btrfs freue.

Jepp, aber benutze ich schon seit ca. einem Jahr, seit ich damals LVM entdeckt habe.

lvmcreate -s -n root.snap -L 128M /dev/vgroup/root
mkdir /tmp/root.snap
mount /dev/vgroup/root.snap /tmp/root.snap
rsync -a --delete --backup --backup-dir=.`date +%F.%s` /tmp/root.snap/* /media/backup/root/

Das gleiche fuer die home-lvm, als cronjob, oder besser mit anachron, ist das meine "Timemachine".

[Mr. N]

DEvent schrieb:

Was natürlich nix daran ändert, dass Snapshots toll sind und ich mich auf btrfs freue.

Jepp, aber benutze ich schon seit ca. einem Jahr, seit ich damals LVM entdeckt habe.

lvmcreate -s -n root.snap -L 128M /dev/vgroup/root
mkdir /tmp/root.snap
mount /dev/vgroup/root.snap /tmp/root.snap
rsync -a --delete --backup --backup-dir=.`date +%F.%s` /tmp/root.snap/* /media/backup/root/

Das gleiche fuer die home-lvm, als cronjob, oder besser mit anachron, ist das meine "Timemachine".

Schau dir doch mal rdiff-backup an.

[u-ser_l]

Linux-User schrieb:

zurück zum Thema: findet ihr es gut oder schlecht, dass Unix Dateien nur als eine Ansammlung von Bytes betrachtet?

die *n*x-Prinzipien können so schlecht nicht sein, sonst hätten sie nicht rund 40 J überlebt.

Es mag hier und da Verbesserungsmöglichkeiten geben, aber so groß scheint mir das Verlangen nach verbesserten Nachfolgesystemen nicht zu sein, sonst besäßen Systeme wie plan9 wohl mehr Verbreitung.

Auch ein ähnlich bedeutsames prinzip: "nutze zur Speicherung möglichst Klartext-Formate".

[nman]

DEvent schrieb:

lvmcreate -s -n root.snap -L 128M /dev/vgroup/root
mkdir /tmp/root.snap
mount /dev/vgroup/root.snap /tmp/root.snap
rsync -a --delete --backup --backup-dir=.`date +%F.%s` /tmp/root.snap/* /media/backup/root/

Preisfrage: Welche dieser Zeilen ist böse und potentiell gefährlich und warum?

Linux-User: Sehe die Bytestream-Sache ähnlich wie Du.

u-ser_l: Naja, viele Features von Plan 9 wurden ja irgendwie in moderne Unices übernommen. Aber dass sich das nicht so sehr verbreiten würde, war klar. Unix ist einfach gut genug für den Praxiseinsatz, das Plus an Eleganz und Klarheit von Plan 9 bringt einfach den meisten Leuten nicht genug.