Ich glaub fuer fish braucht die Gegenstelle kein sftp-subsystem gestartet zu haben. Der Austausch geht dann ueber ssh. sftp wuerde dann auch das sftp-subsytem nutzen.
ja, aber ich finde es bei kde toll, dass ich z.B. mit dem konqueror auf jedes beliebige Netzwerklaufwerk zugreifen kann und dann Dateien mit jedem beliebigen Programm bearbeiten kann. Mit gnomevfs geht das (noch) nicht, nichtmal einfache txt Dateien kann ich mit gedit oder emacs editieren wenn sie im Nautilus über sftp angezeigt werden.
Was Netzwerktransparenz angeht hat GNOME imho noch einen langen Weg vor sich...
noch schöner wäre es, wenn die I/O Slaves zwischen KDE und Gnome austauschbar wären. Das wäre nicht nur gut für beide Desktops, sondern würde auch Linux wieder etwas geschlossener dar stehen lassen.
..ist z.B., daß man mit alt+f2 #bash wohl die schnellste Möglichkeit hat einfach mal die graphische Darstellung der man page zu bash anzugucken, ohne Konqueror vorher explizit starten zu müssen.
Du haettest vielleicht erwaehnen koennen, ob das "#" auch etwas mit I/O Slaves zu tun hat, denn so sieht es danach aus, als sei Dein Kommentar vollkommen am Thema vorbei, es ging nicht um allgemeine Erleichterungen - aber netter Tipp. Zudem klingt der Betreff Deines Posts nicht gerade nett - nur weil der Artikel kurz ist...
> Du haettest vielleicht erwaehnen koennen, ob das "#" auch etwas mit I/O Slaves zu tun > hat, denn so sieht es danach aus, als sei Dein Kommentar vollkommen am Thema vorbei
Nun, er hat recht und ist keineswegs am Thema vorbei.
Denn im Prinzip landest du auf man://bash wenn du das eingibst.
Von Christoph Bartoschek am Do, 7. Juli 2005 um 10:53 #
Das hat mal funktioniert. Dazu musste der NFS Server den Zugriff von Userspace Programmen aus erlauben. Dies wird über eine Konfigurationsoption in der exports geregelt, soweit ich weiss. Der Code war aber nie ganz stabil und wird nicht gepflegt. Wenn ich mich richtig erinnere wird der auch demnächst entfernt.
Von Hans-Joachim Daniels am Do, 7. Juli 2005 um 07:49 #
Die I/O-Slaves sind ja schön und gut, aber ein Fremdprogramm wie Eclipse und sie bringen einem nicht mehr viel. Aber auf diese Erkenntnis sind schon andere gestoßen, und haben http://kde.ground.cz/tiki-index.php?page=KIO+Fuse+Gateway in die Welt gesetzt. Nur fehlt mir momentan die Zeit, das auszuprobieren, hat da einer von euch mit Erfahrungen gesammelt?
Wenn das wirklich so gehen würde wie beschrieben, wäre das fein. Aber wenn ich mir ein Video unter KDE von einem Samba Server aus anschauen will, lädt er das Video erst runter und spielt es dann ab. Und weder Amorak noch JuK können von einem Samba Server mp3's abspielen. Das Konzept is toll (gut die KDE leute haben das ja auch nur abgekupfert), die Umsetzung mies.
Dein konkretes liegt daran, dass Kaffeine und Amarok eine Shell für nicht-KDE-Bibliotheken sind, die keine Ahnung von KIO haben.
Deswegen hat man als Auswegen erst die Datei über SMB runtergeladen und lässt die Lib (bspw. Xine) das ganze dann lokal abspielen um wenigstens ein bischen KIO in dem Fall zu haben. Also hat nix mit mieser Umsetzung von Seiten KDE's zu tun, sondern mit dem glatten Gegenteil, ansonsten ginge garnix.
Ach ja von wem soll den KDE das KIO Konzept abgekupfert haben? Mir ist kein wirklicher Vorgänger bekannt...
ALso mir persönlich (bin nicht der Vorposter) fällt spontan OS/2 ein. Dessen InstallableFileSystems (kurz IFS) könnten auf OS-Ebene solche Dienste zur Verfügung stellen. z.B. sehr früh FTP.ifs, welches beliebige FTP-Verzeichnisse als Laufwerke einbindet. TVFS.ifs, welches Unix-artige Links (ld) bewerkstelligte nfs.ifs für nfs... Tonigy.ifs für die Darstellung von CD-Audiotracks alas Wavs und später auch als MP3s (AFAIK)...
Und später hat Microsoft das bei Windows 95/98 mies nachkopiert mit ihrem Virtuellen Dateisystem in der die Systemsteuerung und Drucker und FTP/HTTP-Zugaenge gleich neben Laufwerken und Desktop liegen. Genauso wie es dann auch Programme gab die Archiv-Dateien direkt als Ordner ins System eingebunden haben u.ä.
Ich glaube zwar dass es ein ähnliches Konzept war, aber ich bezweifle dass es ebenso konsequent wie bei KDE geplant/umgesetzt ist. Bei anderen Systemen ist es meist nur eine aufgesetzte Zusatzfunktion, während es bei KDE erstmalig als Basis für alles konzipiert und implementiert wurde. Daher bezweifle ich grundsätzlich die Aussage es handelt sich um eine Kopie.
Allerdings hinkt natürlich der Vergleich zwischen OS/2 oder WINx zu KDE, da KDE hier ja "nur" ein Aufsatz zum OS ist.
> Dein konkretes liegt daran, dass Kaffeine und Amarok > eine Shell für nicht-KDE-Bibliotheken sind, die keine > Ahnung von KIO haben. [...] Mir is schon klar wo das Problem ist. Nur ändert das halt nix an dem Verhalten der KDE Anwendungen. Und wenn ich mir die entsprechenden Gnome Anwendungen (Totem, Rythmbox) anschaue, dann kriegen die das gebacken. Und bevor der nächste daherkommt, ich weiss dass auch Totem das File runterlädt, aber zumindest bringen die es soweit fertig, dass das Abspielen sofort beginnt. Hinzukommt noch das Juk zu KDE gehört und genauso mit KIO nicht umgehen kann.
> Ach ja von wem soll den KDE das KIO Konzept abgekupfert > haben? Mir ist kein wirklicher Vorgänger bekannt... Naja das ganze sieht so sehr nach dem Windows Filesystem Layer aus. Da kann ich auch Files direkt von SMB Shares starten und mit den Unix Tool auch von NFS. Windows kennt zwar nicht soviele Protokolle, dafür funktioniert das auch mit jeder Anwendung.
> Windows kennt zwar nicht soviele Protokolle, dafür funktioniert das auch mit jeder Anwendung. Sicher? Dann versuchs mal mit alten 16-Bit-Anwendungen. ;-)
Laufwerksbuchstabenzuweisungen zählen nicht. Denn das wäre nichts anderes als ein smbmount unter Linux und das funktioniert ebenfalls mit allen Programmen.
> Sicher? Dann versuchs mal mit alten 16-Bit-Anwendungen. WoW 16bit Anwendungen. sowas hab ich nicht mehr rumliegen um das auszuprobieren. Aber nachdem nicht mal alle KDE Anwendungen mit KIO funktionieren, denke ich muss ich das garnich ausprobieren. Wenn wir mal soweit sind, dass zumindest jede KDE Anwendung mit KIO komplett zurecht kommt, probier ich das mal aus.
> Laufwerksbuchstabenzuweisungen zählen nicht. Denn das wäre > nichts anderes als ein smbmount unter Linux und das funktioniert > ebenfalls mit allen Programmen. Laufwerksbuchstaben unter Windows sind was anderes: 1) Man braucht keine Adminrechte oder einen admin der fstab Einträge macht. 2) Sie existieren nur für die User Session, andere leute die auf dem Rechner arbeiten kriegen nichts mit davon und können auf die gemounteten Netzwerkfreigeben auch nicht zugreiffen. (Ich möchte daran erinnern das auch mit chmod go-rwx root immernoch in das Verzeichnis kann.
KIO-Slaves und GNOME-VFS versuchen beide das gleiche Problem zu lösen, nämlich dateien über diverse Protokolle zu öffnen. Das ist ja an und für sich eine sehr gute Idee, aber es können halt dann nur KDE oder Gnome Programme benutzen. Andere Programme, z.B. Java, Konsolen oder alte X Programme werden ausgeschlossen. Ich denke das Problem müsste auf Kernelebene, oder direkt dadrüber angegangen werden, denn so könnten alle Programme direkt damit arbeiten.
Es spricht nichts dagegen, das unter Linux zum Beispiel auf Kernelebene zu lösen, solange zusätzlich auch ein Verfahren besteht, mit dem User solche Dateisysteme in ihre privaten Mountpoints mounten können.
Darüber hinaus bräuchten die Desktops immer noch ihre eigenen Protokollimplementationen für System, die das nicht auf Kernel- oder Systemebene implementiert haben.
während dies zwar richtig ist, wird aber andereseits vergessen, dass weder Gnome noch KDE auf Linus "festgenagelt" sind. Wenn also KDE als "Desktopplattform" nun unter BSD, MacOSX, AIX oder Windows läuft, dann klappt das mit den KIO-Slaves immernoch. WENN man das auf OS-Ebene verlagert - ja dann sähe es eben auf jedem System anders aus...
Ein Ansatz wäre mittels Freedesktop.org eine Art Allgemeines-VFS zu schaffen, welches GNOME, KDE, XFCE und der gleichen gemeinsam nutzen würden.... was a) viel Disziplin verlangen würde (sprich keine Extrawürste aber b) das Problem von JAVA-Apps, alten X11er-Apps nun auch noch nicht löst...
Soweit ich weiß gibt es sowohl für KDE als auch für Gnome Bibliotheken, die den Zugriff von Java-Programmen erlauben. Für KDE gibt es z.B. hier Informationen dazu: http://developer.kde.org/language-bindings/
Natürlich funktioniert das dann immer noch nicht mit *allen* Anwendungen, aber zumindest könnte man bei vielen Open-Source-Programmen eine optionale Unterstützung einbauen.
"Natürlich kann man sich darüber streiten, ob es Sinn macht, mit Konqueror auf IMAP-Server zuzugreifen, ..."
Die Erklärung des Unsinns ist schnell gemacht. Die IO-Slaves werden ja nicht nur vom Konqueror benutzt sondern intern von allen Programmen die via Netz auf etwas zugreifen wollen. So arbeitet eben auch Kontact mit IO-Slaves, etc. Die IO-Slaves bieten hier eben auch dem Programmierer von Anwendungen eine transparente Schnittstelle zu Netzwerkdiensten, nicht nur den Dateiprogrammen.
Im Gegensatz zu den KDE I/O Slaves, wird in plan9[1] alles(!) über ein _generisches_ netzwerk-transparentes File-IO Protokoll abgehandelt, das sog. 9P[2] Protokoll, kürzlich auch in den Linux-Kernel in Form der v9fs[3] Unixifizierung eingeflossen. Dazu bedarf es nicht annähernd 100 unterschiedlicher Slave-Implementierungen, sondern lediglich eines 9P-Client-Server Stacks. In der plan9 Welt wird damit zB NAT betrieben in der Form, das man ein Ethernet Device auf einem Remote-Rechner einfach in das lokale VFS mountet, oder in dem man /dev/draw eines Remote Rechners lokal mountet, hat man sowas wie VNC oder NX...
Wäre vielleicht eine Anregung an KDE 6.0, darüber nachzudenken, ob man nicht Dinge ggf. erneuern will. Denn plan9 ist zwar auch schon 15 Jahre alt, aber Unix geht streng auf die 40 zu, und die I/O Slave-Grundlagen gehen auch weit in die frühen 70er zurück...
Dass Openoffice damit nicht umgehen kann stimmt nicht. Es gibt sehrwohl Openoffice-kde Versionen die den kde file open Dialog haben, und auch über die beschriebenen Protokolle auf Dateien zugreifen können. Für Firefox gilt sicher (bald) ähnliches.
Sonic
sftp wuerde dann auch das sftp-subsytem nutzen.
Gibts so ne schnittstelle auch fuer Web.de ?
Dort hast du dann (mind) 1GB Speicher, wo du nach Belieben Verzeichnisse anlegen kannst.
Was Zeit wird ist, dass mehr anwendungen auf gnomevfs migriert werden!
Mit gnomevfs geht das (noch) nicht, nichtmal einfache txt Dateien kann ich mit gedit oder emacs editieren wenn sie im Nautilus über sftp angezeigt werden.
Was Netzwerktransparenz angeht hat GNOME imho noch einen langen Weg vor sich...
noch schöner wäre es, wenn die I/O Slaves zwischen KDE und Gnome austauschbar wären. Das wäre nicht nur gut für beide Desktops, sondern würde auch Linux wieder etwas geschlossener dar stehen lassen.
- Jens
Du haettest vielleicht erwaehnen koennen, ob das "#" auch etwas mit I/O Slaves zu tun hat, denn so sieht es danach aus, als sei Dein Kommentar vollkommen am Thema vorbei, es ging nicht um allgemeine Erleichterungen - aber netter Tipp. Zudem klingt der Betreff Deines Posts nicht gerade nett - nur weil der Artikel kurz ist...
cu
Valentin Born
Nun, er hat recht und ist keineswegs am Thema vorbei.
Denn im Prinzip landest du auf man://bash wenn du das eingibst.
trotzdem guter tipp - wird jetzt wohl öfter zur anwendung kommen bei mir.
Aber auf diese Erkenntnis sind schon andere gestoßen, und haben http://kde.ground.cz/tiki-index.php?page=KIO+Fuse+Gateway in die Welt gesetzt. Nur fehlt mir momentan die Zeit, das auszuprobieren, hat da einer von euch mit Erfahrungen gesammelt?
Wollte es nur mal gesagt haben...
Exec=kaffeine %f
ein
Exec=kaffeine %u
Deswegen hat man als Auswegen erst die Datei über SMB runtergeladen und lässt die Lib (bspw. Xine) das ganze dann lokal abspielen um wenigstens ein bischen KIO in dem Fall zu haben. Also hat nix mit mieser Umsetzung von Seiten KDE's zu tun, sondern mit dem glatten Gegenteil, ansonsten ginge garnix.
Ach ja von wem soll den KDE das KIO Konzept abgekupfert haben? Mir ist kein wirklicher Vorgänger bekannt...
z.B. sehr früh FTP.ifs, welches beliebige FTP-Verzeichnisse als Laufwerke einbindet.
TVFS.ifs, welches Unix-artige Links (ld) bewerkstelligte
nfs.ifs für nfs...
Tonigy.ifs für die Darstellung von CD-Audiotracks alas Wavs und später auch als MP3s (AFAIK)...
Bei anderen Systemen ist es meist nur eine aufgesetzte Zusatzfunktion, während es bei KDE erstmalig als Basis für alles konzipiert und implementiert wurde.
Daher bezweifle ich grundsätzlich die Aussage es handelt sich um eine Kopie.
Allerdings hinkt natürlich der Vergleich zwischen OS/2 oder WINx zu KDE, da KDE hier ja "nur" ein Aufsatz zum OS ist.
> eine Shell für nicht-KDE-Bibliotheken sind, die keine
> Ahnung von KIO haben. [...]
Mir is schon klar wo das Problem ist. Nur ändert das halt nix an dem Verhalten der KDE Anwendungen.
Und wenn ich mir die entsprechenden Gnome Anwendungen (Totem, Rythmbox) anschaue, dann kriegen die das gebacken. Und bevor der nächste daherkommt, ich weiss dass auch Totem das File runterlädt, aber zumindest bringen die es soweit fertig, dass das Abspielen sofort beginnt.
Hinzukommt noch das Juk zu KDE gehört und genauso mit KIO nicht umgehen kann.
> Ach ja von wem soll den KDE das KIO Konzept abgekupfert
> haben? Mir ist kein wirklicher Vorgänger bekannt...
Naja das ganze sieht so sehr nach dem Windows Filesystem Layer aus. Da kann ich auch Files direkt von SMB Shares starten und mit den Unix Tool auch von NFS. Windows kennt zwar nicht soviele Protokolle, dafür funktioniert das auch mit jeder Anwendung.
Sicher? Dann versuchs mal mit alten 16-Bit-Anwendungen. ;-)
Laufwerksbuchstabenzuweisungen zählen nicht. Denn das wäre nichts anderes als ein smbmount unter Linux und das funktioniert ebenfalls mit allen Programmen.
WoW 16bit Anwendungen. sowas hab ich nicht mehr rumliegen um das auszuprobieren. Aber nachdem nicht mal alle KDE Anwendungen mit KIO funktionieren, denke ich muss ich das garnich ausprobieren. Wenn wir mal soweit sind, dass zumindest jede KDE Anwendung mit KIO komplett zurecht kommt, probier ich das mal aus.
> Laufwerksbuchstabenzuweisungen zählen nicht. Denn das wäre
> nichts anderes als ein smbmount unter Linux und das funktioniert
> ebenfalls mit allen Programmen.
Laufwerksbuchstaben unter Windows sind was anderes:
1) Man braucht keine Adminrechte oder einen admin der fstab Einträge macht.
2) Sie existieren nur für die User Session, andere leute die auf dem Rechner arbeiten kriegen nichts mit davon und können auf die gemounteten Netzwerkfreigeben auch nicht zugreiffen. (Ich möchte daran erinnern das auch mit chmod go-rwx root immernoch in das Verzeichnis kann.
Darüber hinaus bräuchten die Desktops immer noch ihre eigenen Protokollimplementationen für System, die das nicht auf Kernel- oder Systemebene implementiert haben.
Ein Ansatz wäre mittels Freedesktop.org eine Art Allgemeines-VFS zu schaffen, welches GNOME, KDE, XFCE und der gleichen gemeinsam nutzen würden.... was a) viel Disziplin verlangen würde (sprich keine Extrawürste
aber b) das Problem von JAVA-Apps, alten X11er-Apps nun auch noch nicht löst...
BTW: Danke für den Artikel! Feiner Überblick.
Natürlich funktioniert das dann immer noch nicht mit *allen* Anwendungen, aber zumindest könnte man bei vielen Open-Source-Programmen eine optionale Unterstützung einbauen.
Grüße,
Fabian
Die Erklärung des Unsinns ist schnell gemacht. Die IO-Slaves werden ja nicht nur vom Konqueror benutzt sondern intern von allen Programmen die via Netz auf etwas zugreifen wollen. So arbeitet eben auch Kontact mit IO-Slaves, etc.
Die IO-Slaves bieten hier eben auch dem Programmierer von Anwendungen eine transparente Schnittstelle zu Netzwerkdiensten, nicht nur den Dateiprogrammen.
Wäre vielleicht eine Anregung an KDE 6.0, darüber nachzudenken, ob man nicht Dinge ggf. erneuern will. Denn plan9 ist zwar auch schon 15 Jahre alt, aber Unix geht streng auf die 40 zu, und die I/O Slave-Grundlagen gehen auch weit in die frühen 70er zurück...
[1] http://www.cs.bell-labs.com/plan9dist/
[2] http://www.cs.bell-labs.com/sys/doc/names.html
[3] http://v9fs.sourceforge.net/
Für Firefox gilt sicher (bald) ähnliches.