KIO is very much still alive, and in frequent use for me at least. Treating remote folders over SSH straight in my favorite file manager is pretty indeed.

> I was amazed at the ability to open a file on the server as if it was on my hard drive.

I wish it worked as well as you describe. It only works if the application you are using is KIO-enabled.

On Windows, you can use a "\\servername\sharename\path\to\file.txt" style path (a UNC path) virtually anywhere and it just works. It also has the smarts to pass along your credentials, etc, so it's virtually transparent. The only exception I've seen to this is that the command prompt doesn't understand a UNC path as a working directory, but commands like copy, etc, do work with it.

Not sure this is a fair comparison. It works with basically any KDE app, for any protocol that has a KIO slave. There certainly must be a lot of confusion for users that don't understand why it doesn't work in random non-KDE apps they've installed, or the command line, but I suspect very few of them are typing in SSH URLs anyway. At the same time, Windows doesn't accept an SFTP URL in a file open dialog.

Anyway, I use emacs on both platforms and it handles all of this for me, so my dog retired from this game many years ago.

The UNC paths in Windows are very much a Windows-ism. They work perfectly when you're in an all Windows environment, but there's no consideration to speaking non-Windows protocols.

The key problem I have with KIO is that it's doing something that should be done at a lower level so that every application can benefit.

As I see it, there are three classes of apps on Linux when it comes to file handling:

* Apps that can open remote files using one set of protocols (KIO-enabled apps).

* Apps that can open remote files using a different set of protocols (things that reinvent this wheel, like emacs in your example).

* Apps that can only work on local files.

So we get a situation where I can open a file on an SMB server using Kate, but I can't open the same file in Sublime Text. It makes for a terrible user experience.

The Mac makes it easy to mount filesystems, but it's kludgey compared to using UNC paths in Windows. This is the one feature that I really miss from Windows.

Sure, totally agree that it'd be great if this was a low level feature of the OS that seamlessly integrated with any possible GUI for authentication from readline and up. But we could sit here all day and enumerate ways in which open source operating systems and desktop environments are less integrated than others.

All I was saying originally was that KDE was the first Linux environment I used which came close to the level of broad support and integration you get from something like Windows, and in some cases it went beyond.

Integration is definitely an area where open source could do better, the freedesktop project is a step in the right direction, but we need more.

KioFuse will let you mount KIO slaves as real filesystems:

https://techbase.kde.org/Projects/KioFuse

Never tried it myself, so I don't know how well it works.

It looks like it was last updated 8 years ago, so it could be abandoned.

That also only works for the windows file sharing protocol. It's not even close to what KIO provided with it's protocol agnostic support. The windows UNC paths also only work on windows with windows apps. It's not a fair comparison.

The real win would be the Plan 9 filesystem protocols which had the same feature but at the file system protocol level.