Don't understand german? Read or subscribe to my english-only feed.

Unix im Jahr 2010: die Arbeit am Rechner in der Zukunft

Ich habe weder stunden- oder tagelang über dem Design gebrütet noch lege ich Anspruch auf Vollständigkeit. Aber das sind ein paar jener Sachen die ich in Zukunft einmal auf meinem Rechenknecht in der Praxis sehen möchte:

1.) Objektorientierte Pipes: ähnlich dem was die MSH kann bzw. können wird möchte ich einmal folgendes machen:

% cat wordfile.doc | out/xml   # konvertiere das Word-Dokument in eine XML-Datei
% cat *.wmv | out/mpg all_in_one.mpg # mach aus allen WMV-Videos eine einzelne MPEG-Datei

2.) Suspend/Resume: Ich möchte – unabhängig vom verwendeten Window-Manager – mein X schlafenlegen und wieder aufwecken können, alla screen mit detach und reattach. Ich möchte auch meine komplette Arbeitsumgebung in ein Image schreiben und auf einem anderen Rechner damit weiterarbeiten können. Snapshots dieser Arbeitsumgebungen können in Backups einbezogen werden.

3.) Zusammenspiel Konsole mit dem ‘Graphical User Environment’: Drag and Drop zwischen Konsole und Window-Manager bzw. Applikationen (AFAIK geht sowas bei Mac OS). Selektive Auswahl von Objekten in der Konsole (‘Alles Markieren nur die XML-Dateien nicht’) und diverse Operationen via Pipe an gewünschtes Programm darauf ausführen (‘Backup erstellen; Dateien anschauen; Dateien per Mail senden’). ‘cat++ meine_katze.jpg’ öffnet den Image-Viewer, ‘cat++ foobar.xml’ zeigt mir die Datei im XML-Renderer.

4.) Konsole: History nicht nur von Kommandos sondern auch von Konsolen-Output. Sowas ähnliches geht mit dem keep-hack von Bart Schaefer für die zsh, ich möchte das aber ohne manuelles Zutun, komfortabel und shellübergreifend.

5.) Globales “alles ist eine Datei”: ich möchte das Plan9-ähnlich haben. Nicht nur mein lokales Dateisystem soll aus Dateien bestehen, ich möchte netzwerkweit agieren können – am liebsten auch wieder in Kombination mit objektorientierten Pipes:

% cd http://grml.org/zsh/ # in das Verzeichnis wechseln
% grep zsh < http://grml.org/files/release-0.3/dpkg_list # nach einem String in einer Datei auf einem Webserver greppen
% cat http://grml.org/zsh/zsh-lovers.1 | out/pdf zsh-lovers.pdf # eine Datei auf einem Webserver on-the-fly in ein anderes Format konvertieren

Was kann man aus obigen Wünschen herauslesen? Die Unix-Philosophie "one tool - one job" will gut koordiniert sein. Die Shell spielt eine wichtige Rolle, ist aber kein Muss. Es werden zentrale Schnittstellen geschaffen, ähnlich dem was DCOP von KDE schon heute bietet. Wenn man überlegt wie optimiert, feinkonfiguriert und tiefergelegt der durchschnittliche Geek-Desktop schon heute ist bin ich optimistisch, dass zumindest Teile der obigen Wunschliste mal in der freien Wildbahn zu finden sein werden. :-)

6 Responses to “Unix im Jahr 2010: die Arbeit am Rechner in der Zukunft”

  1. Freest Chad Says:

    Was soll daran großartig toll sein?

    % cat wordfile.doc | out/xml

    Wo der wahnsinnig tolle überragende Vorteil zu:

    % cat michis_wordfile.doc | out -xml

    liegen?

  2. mika Says:

    > Was soll daran großartig toll sein?
    > % cat wordfile.doc | out/xml
    > Wo der wahnsinnig tolle überragende Vorteil zu:
    > % cat michis_wordfile.doc | out -XML
    > liegen?

    Auf die Syntax habe ich keinen Wert gelegt (cat++ würde wohl cat-ng heissen ;-)). Die cmdline war nur an jene der MSH angelehnt. ‘out -XML’ wäre ja auch schlecht gewählt (Optionen ‘-X -M -L’), ‘out –format=XML’ wäre wohl realistischer. ;-) Und out/xml ähnlich MIME wäre halt auch schnell zu tippseln. :-)

    Mir gehts also rein um die Ideen und nicht die Namens- und Syntaxgebung.

  3. tklauser Says:

    Zu 1):

    Zumindest auf Audio/Video bezogen kann das GStreamer bzw. die Tools dazu (GStreamer ist ja genau genommen nur eine Library) schon recht anständig, auch wenn die Kommandozeilen dazu etwas länger und IMO weniger intuitiv sind. Ausserdem scheint es auch noch etwas an Dokumentation zu mangeln.

  4. mika Says:

    @tklauser:

    Jepp! GStreamer ist ziemlich genial (amarok nutzt es z.B. ja auch schon länger). mplayer/transcode & CO sind ja für Video-/Audioumwandlung auch schon ziemlich gut. Aber gerade rund um Sound- und Videocodecs braucht es noch relativ viel menschliches Wissen um Formatumwandlungen ordentlich durchführen zu können. Und die passenden Optionen hat man nur selten grad im Kopf – deswegen auch mein Beispiel mit wmv und mpg. ;-)

    Insofern wünsche ich mir eine Schnittstelle (in meinem Beispiel das ‘|out/…’, die man einfach ansprechen kann und die sich dann um die passenden Optionen für die Tools kümmert.

  5. murphee Says:

    ad 1.)
    Ich bin nicht sicher warum die Dinger “objektorientierte” Pipes heissen… was macht die Beispiele “objekt”-orientiert?

    ad 2.)
    Suspend/Resume: wie waers da mit so Zeug wie UserModeLinux oder Kollegen? (auf Windows is CoLinux ganz praktisch);
    Die Dinger haben auch Suspend/Resume Funktionalitaet. Interessant ist auch die moegliche Trennung zwischen den verschiedenen Systemen, zB Networking Applikationen laufen in einer UML Instanz, Programmierzeugs laeuft in einer anderen,… Dh. selbst wenn ein Programm aus der Netzwerk Instanz gekapert wird, zerstoert es nur seine eigene Instanz, und der Rest laeuft normal weiter. Ich schaetze, wenn man jeder Instanz eine eigene Partition gibt, dann sollte auch die Performance besser sein, da der Umweg uebers Host FS nicht gemacht werden muss; da ist dann allerdings die Portabilitaet (im Sinne von: Image einpacken und auf einen anderen Rechner schmeissen) nicht so einfach.

  6. mika Says:

    @murphee:

    ad 1) “Pipelines are Cmdlets passing structured objects” — http://download.microsoft.com/download/3/8/1/38198a72-294d-46c3-93ba-faee5cf85d00/ARC334.ppt – dort sieht man noch am Ehesten was damit gemeint ist. Ich hab in meinem MSH-Blogeintrag (http://www.michael-prokop.at/blog/index.php?p=217) einmal zusammengefasst was ich an Dokumentation entdecken konnte, diese ist leider auch heute noch sehr unvollständig und verstreut.

    ad2) Ja, ist mit (eventuell einer Kombination aus) swsusp2, vserver, XEN oder UML und VMWare [teilweise] schon möglich. Jener Punkt, den du Portabilitaet nennst (Image einpacken und woanders weitermachen) ist AFAIK nur mit VMWare möglich. swsusp2 ist leider noch nicht im Mainstream-Kernel, VMWare ist sehr teuer, UML wird mittlerweile AFAICS durch XEN abgelöst. Ich hab mit XEN aber noch keine Erfahrung – ich werd mich da am Grazer LinuxTag von Herrn Linzbichler aufklären lassen. ;-)

    Ach ja: danke für den Hinweis auf CoLinux, das kannte ich noch nicht!