Meine $HOMEs sind organisiert nach:
Archiv/2012/Ablage
Archiv/2012/Work
Archiv/2012/tmp
(ff. für jedes Jahr die gleiche Struktur)
Für das aktuelle Jahr gibt es jeweils Symlinks um Ablage, Work und tmp direktb im $HOME zu haben.
Ablage nutze ich für alles "Fertige" bzw. Unveränderliche, es gibt von vorneweg Unterorder für Rechnungen, Bestellungen, Mails, usw.
Work nutze ich zum Arbeiten, wobei es meist in "Projekten" organisiert ist und hier zumindest einen eigenen Unterordner hat.
tmp ist für alles was ich wirklich temporär mache (diesen text z.B.), Downloads oder Dinge per Drag&Drop.
Über Skripte lasse ich nun den Computer etwas tun, nach einigen Regeln:
a) Alles was älter als 4 Wochen ist wird aus tmp gnadenlos gelöscht. Das spart Platz und zwingt mich, Dinge die ich doch aufheben will woanders hin zu sortieren.
b) Dateien/Ordner/Projekte, die seit 8 Wochen nicht mehr modifiziert wurden werden nach Ablage verschoben, da ich anhehmen kann daß ich da wohl nix mehr dran machen werde.
c) Ein Jahrswechsel-Skript warnt mich einige Zeit vorm Jahreswechsel doch bitte Ablage nach nutzlosem zu durchforsten, tmp nochmal anzuschauen. Gleichzeitig würde für 2013 die neue Struktur in Archiv angelegt. Dinge aus Work schließe ich nun entweder ab (verschiebe diese ggf. nach Ablage) oder nehme sie ins neue jahr mit. Am Jahreswechsel werden dann die Symlinks angepaßt, tmp vom Altjahr wird gelöscht und im Idealfall sollte der Work-Ordner leer sein.
Alles was ich erstelle spielt sich also in diesen 3 Ordnern ab. Die allermeisten Dinge sind eine Art Projekt/Aufgabe (die i.d.R. auch mehr als eine Datei umfassen). So lege ich meist dafür einen Ordner an, bzw. lasse über Template-Skripte diese generieren.
Das bringt mich zu einem meiner Lieblingsthemen im Bereich Desktop/Workflow: Ich liebe Templates/Vorlagen und hasse die stiefmütterliche Umsetzung innerhalb der Desktopumgebungen/Windowmanager... Meine Lieblingsarbeitsumgebung war schon imer die WorkplaceShell(WPS) von OS/2, da diese zwei für mich genial umgesetzte Konzepte mitbrachte:
a) Geniales Template-System, jede Datei/Ordner konnte in jedem Zustand per Mausklick zu einer Vorlage gemacht werden. Diese tauchte dann sofort im speziellen Template-Ordner auf. Durch "Abreißen" erstellte man nun eine "Kopie" davon, egal ob das eine Zip-Datei, ein Ordner mit Skripten und Copyright-Notiz oder einfach nur ein Office-Dokument mit Faxbriefkopf etc. war.
Etwas für mich vergleichbares kriege ich nur durch (tar/zip)Archive oder halt mit Skripts hin (ein neues Ruby-Skript lasse ich mir z.B. durch ein Ruby-Skript erstellen, inkl. Bang und Kommentarblock). Auch nutze ich ERB intensiv, also eingebettetes Ruby in z.B. privat-brief.tex.erb, was mir durch erb variable Inhalte in der Datei vorbelegt (das selbe Prinzipt wie mit PHP innerhalb Webseiten).
b) Das zweite geniale Konzept von OS/2-WPS war das Mittel der Arbeitsordner. Ein Ordner zum Arbeitsordner zu deklarieren bedeutete, daß beim Schließen des Ordners der Zustand aller Objekte darin (Textfile->Editor, URl->Browser) ebenfalls gespeichert wurde. Beim Wiederöffnen konnte man also an dem Punkt weitermachen beidem man beim Schließen aufhörte.
Vergleichbar ist das mit den Aktivitäten bei KDE, die in neueren Versionen auch gut funktionierte. Für mich wäre das der einzige Grund für KDE, allerdings würde ich mir das erfahrungsgemäß mit zuvielen Nachteilen erkaufen...
Bilder+Musik ("Multimedia") liegt bei mir auf dem Server, Daten davon werden per NFS eingebunden. Unter /media liegt da alles, ich muß da eigentlich nur selten mit einer Art "Dateimanager" ran...
Meine $HOMES kommen auch per NFS, das werde ich wohl wieder ändern da ich mit meinem NFS-Server doch erhebliche Locking-Probleme habe (muß den unfsd verwenden statt dem Kernel-NFS...)
Ansonsten wäre mein "Traum" einer Konzeptlösung, den Computer viel mehr für mich arbeiten zu lassen (alle meine Rechner "idlen" so >90% über einen längeren Zeitpunkt gesehen vor sich hin->Verschwendung...)
Ich hatte mal mit einem Dokumentenarchivierungssystem über den CUPS angefangen, der sich wie ein "Drucker" verhielt und die Daten in einer Datenbank ablegte. Zu dem reinen (Postcript)-Druckdokument wurde gleichzeitig noch ein PDF, wenn möglich die Originaldatei und ein geparster Textauszug(strings) mit abgelegt. Im "Druckdialog" konnten schon Ablageorte ähnlich herkömmlichen Leitz-Ordnern angegeben werden.
Ausgehend davon könnte ich mir eine Daten/Dateiablage auch recht gut in einer Datenbank vorstellen, eine Art SQL-Fs (Ansätze gibt/gab es schon). Sowas müßte natürlich objektorientiert statt "pur" relational sein (bzw. wenn relational, dann mit einer obejktorientierten Schnittstelle wie es RubyOnRails bietet).
Die Möglichkeiten von Beziehungen und Organisation/Reporting wäre halt bei einer Datenbank sicher besser zu nutzen als es eine Dateisystem basierende Ablage böte...
Was ich aus obigen Gedanken gerne hätte wäre: ein "Device (/dev/ablage)" oder auch ein Drag&Drop-Ziel, wo ich *ALLES* draufwerfen könnte. Egal ob Bild, Text(schnipsel), URL, usw... Das Ablagesystem erkennt nun (z.B. anhand sowas wie Quellprogramm oder Mime-Typ) die Art des "Blobs" und kümmert sich selbständig um die bestmögliche Ablage/Ablageort (anhand bestimmter "Regeln" die ich ja definieren könnte). Das System indexiert, klassifiziert und organisiert nun selbständig diese Daten und präsentiert mir auf Wunsch die benötigten Informationen in eine Art "Google-Suche" oder ggf. in einer Wikiartigen Aufbereitung... Das System (der "Dispatcher" im Hintergrund) ist lernfähig und kann seine Programmierung selbständig erweitern/organisieren: Wenn ich ihm z.B. dreimal sowas wie "098-456-345" vorwerfe erkennt er darin ein "Muster" und kann mich nach einer "Klasse" der Daten fragen. Wenn ich dann sage: Das sind Telefonnummern (die ersten Ziffern vor dem Bindestrich sind Vorwahlen, nimmm deine Vorwahldatenbank als Zusatzkriterium), dann könnte er diese "Blobs" in den Bereich Adressverwaltung aufnehmen, als Klasse/Unterobjekt halt Adresse->Telefonnummer... In Zeiten der "Langeweile/Idle" könnte sich so ein "selbstorganisierendes System" wunderbar um Optimierung der Daten-Ablage und -Präsentation kümmern.
Bei heutigen Indexsystemen fehlt mir halt die "KI-ähnliche" Art der Aufbereitung, Organisation und Beziehungen...
Ähnlich wäre ein sich selbst organisierendes Wiki, was Verlinkungen und Seitenaufbereitung und Erstellung selbst vornimmt - anhand eines Regelwerkes wie es ähnlich die KI-Sprache Prolog bot. Es werden also nur Beziehungen (Clousures nannte man das bei prolog AFAIK) definiert, vorgegeben - daraus ziehende Regeln, konkrete Umsetzung, erledigt das "System" selbständig.
Für sowas notwendige Rechenleistung und Speicher gibt es z.B. in jedem durchschnittlichen Büro+Serverraum zuhauf, fast jeder Officearbeitsplatz langweilt sich heute zu Tode...
dade schrieb
historisch bedingte Trennung zwischen Kommandozeile und grafischem UI
Ganz "grauenhaft" finde ich die ledigliche "GUI-sierung" von Kommandozeilentools. Was bei "Optionsboliden" wie mplayer noch Sinn macht (schiere Anzahl der verfügbaren Optionen/Parameter) konterkariert sich IMHO oft, wenn sich das GUI-Frontend für cdrecord quasi als "Brennprogramm der Ultraklasse" ausgibt...
Was ich toll finde ist die (historisch schon längst vorhandene) Modularisierung von Funktionalität. Die Quintessenz daraus ist IMHO: "Funktionalität" versteht die Eingabe von sdtin und gibt seine Arbeit über stdout aus. Durch Pipes("Röhren") läßt sich so eine Funktionskette erzeugen, die weit über die Möglichkeiten der Einzelprogramme hinausgeht. Richtig stark ist dieses Konzept nur auf der Kommandozeile bzw. in Skripten.
Vorstellen könnte ich mir nun durchaus etwas in der Art von "Objekten", die der Anwender kombinieren/verbinden kann. Das setzt natürlich ein Verständniss der Funktion dieser Einzelobjekte voraus. Aber durch so etwas wie Verbinden von stdin mit stout durch Hin- und Herschieben von "Kacheln" kann eine "Logik" evtl. greifbarer werden als durch "Tippen"...
Unter Squeak (eine Smalltalk-Implementation, genial im übrigen....) gibt es sowas in Form der eToys. Das ist grob eine Icon-Abbildung von Funktionalität/Sourcecode, die aber on-the-fly offenbart was sie leisten kann.
Beispiel: Ein Textobjekt "Käse". Wenn ich dort nun eine "Kachel" mit der Funktionalität von iconv hinziehe würde mir diese iconv-kachsel sagen: Der iso-8859-15-Text "Käse" kann ich so umwandeln das beim Wunsch UTF-8 folgendes rauskommt: "Käse". Wenn ich die "kachel" fallenlasse habe ich eine neue Funktionalität geschaffen. (bei Squeak hat man über die "Kacheln" jederzeit Zugriff auf den darunterliegenden Sourcecode, für unser Beispiel wäre es die iconv-manpage). Als Endergeniss der "Kachelprogrammierung" würde man aber auch mit den entsprehenden Kommandozeilen-Befehlen konfrontiert werden, wie z.B: echo "Käse" | iconv --aaa -bbbb
Ganze "teure IDEs für Dummies" bieten so ein Konzept schon, das dahintersteckende Wissen lassen sich diese Programmierer aber auch teuer bezahlen *und* es wird der "Code", der Befehl dahinter versteckt - Hallo Anwender, bleibe nur dumm, dumm ist modern! Deswegen darfst du das machen, was wir dir vorgeben...
Ich fände es also schon toll, wenn wir durch vermehrte Modularisierung - aber mit definierten, einfachen Schnittstellen wie stdin/stdout - Dinge wie Windowmanager, Desktops, Abläufe durch "An-/Abwählen" bzw. Kombination erreichen könnten - das entsprechende Wissen der Möglichkeiten vorausgesetzt.
Ein weiteres (meiner beliebten, hinkenden Beispiele <g>) wäre noch der Ansatz den Steve Jobs mit der NeXt-Oberfläche/"OS" hatte. Ein Rechtsplick auf ein beliebiges Objekt stellte dynamisch und sinnvoll eine Art Kontextmenü zusammen, was mit diesem Objekt (datei,textschnipsel) nun machbar ist (Senden als Email, Umwandeln in Postscriptcode,...) - und zwar je nachdem, welche zusätzliche Anwendung/Modul auf dem System verfügbar bzw. gestartet war...
So was "halbintelligentes" würde ich von meinem Computer/(Betriebs)System gerne öfters sehen....