The Unix Haters Handbook
-
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
-
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

-
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.
-
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
-
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.
-
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).
-
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".

-
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.

-
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".
-
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.