SPICE

It can.

One thing I've done that I've liked is to enable the TCP support in PulseAudio daemon and configure it to listen on localhost. Then on the remote machine set the ~/.pulse/client.conf to default-server=localhost.

Then I set ~/.ssh/config to do a reverse port for PulseAudio to use and that way I get sound streaming to my local system tunneled over SSH. That way everything is all encrypted and happy.

I don't know if that is abusing the protocol or whatever, but it seems to work fine. Have not tried it over high latency links.

One thing I've been contemplating doing is to either take advantage of PulseAudio's RTP protocol support or setup a gstreamer chain to forward my audio to a Icecast server. That way I could use regular desktop applications to setup a internet radio stream. Even tie it into Jack for doing live mixing or whatever. Seems like it would be a useful way to turn a linux-based Digital Audio Workstation into a sound board for a internet radio station.

As far as SPICE goes it is not optimized for low-bandwidth utilization. So far it's intended purpose is strictly for doing virtualized-based workstations. It is designed to provide performance on par with a local desktop over a LAN configuration. It does happy things like audio compression and it can detect video on the display and use mjpeg video to stream it over a network.

So comparing it currently to things like FreeNX is comparing apples and oranges. There is overlap, but the use case is different.

For example:

Spice requires virtualized hardware. FreeNX does not.
FreeNX requires a remote X Server. Spice does not.

So you can use SPICE with MSDOS if you want. For optimal use you have to use a paravirtualized QXL video card, but it's not required. You still get a lot of performance benefits when using regular VESA or other cards Qemu suports. You can use SPICE to do installs remotely over a network for a wide variety of operating systems. FreeNX you cannot do. Load special drivers for Windows installations, switch Grub to using single user mode, using Linux console, All sorts of stuff like that. It's not so much 'remote desktop' as 'remote VGA connection'.

But FreeNX is still going to be far superior if you are trying to do remote administration over a slow 'WAN' network.

Hopefully SPICE will get a bandwidth optimized version. This is needed to compete with ICA protocol from Citrix.

Also hopefully the paravirtualization gets to the point were you can have OpenGL acceleration. This is needed to get KVM to the same level as Vmware, Virtualbox, and a couple other virtualization solutions.

I don't think that most Linux users/admins really quite comprehend the level that remote desktops are now used in the industry. We have people that use run dozens of desktops in a call center that are running remotely 3/4 of the world away. VoIP and everything is integrated. Probably about 90% of the desktop applications I use at work on Windows is done from virtualized machines. This requires zero training and is completely and utterly transparent to users. I suspected it because of the little icon in the systray and a indicator that would pop up when launching new apps on my Windows workstation, but a less curious person would have no idea that 'local' applications are ran remotely.

The only problems I ran into was with a particularly badly written piece of Java software, because the VMs are defaulted limited to 256MB of RAM per application. Other then that it's really very transparent. I was quite surprised on how vastly more mature remote desktop stuff on Windows has gotten compared to Linux.

It would be fantastic if we could do something like that with open source software. Maybe 'X12' could do it. Maybe some future version of SPICE can be made to do it. I don't know.

I imagine that if SPICE is to be used as a remote desktop or remote administrative interface for non-virtualized Linux systems there would need to be a framework for Linux to host virtual hardware for otherwise non-virtualized system. SPICE is designed to operate at 'below' the hardware level with paravirt hardware.

That could open all sorts of possibilities for virtualized hardware on otherwise non-virtualized systems. Virtual USB devices, virtual network devices, virtual drives. Maybe useful for LXC. Maybe not so interesting. I don't know.