Posted Nov 24, 2011 1:17 UTC (Thu) by csigler (subscriber, #1224)
In reply to: SPICE by jonabbey
Parent article: The first GNOME Boxes release
Apologies if I sound like a broken record, as I've commented on other articles about remote desktop access. I've used FreeNX from http://freenx.berlios.de/ and have been quite satisfied. Performance is acceptable or better over lower bandwidth, higher latency links.
There've been no updates to FreeNX for over three years as its developer, Fabian Franz, and another major force in the effort, Kurt Pfeifle, have "moved on," as someone on the mailing list noted. There's a dormant github project Fabian put up after FreeNX's last significant development input:
so when Berlios goes away, the project history may not be lost after all.
For similar efforts, there's NeatX, a libre partial implementation of NX from Google, but it's been abandoned since 2009. For others, see this mailing list message:
Been a long time since I did any "research" on available software in this area because, when I need it, I've been using FreeNX. In a related development, NoMachine announced in December, 2010, that their next version, 4, would use a closed source protocol and implementation.
is claimed to work very well to provide remote sound via PulseAudio. HTH.
Clemmitt
SPICE
Posted Nov 24, 2011 12:47 UTC (Thu) by mgedmin (subscriber, #34497)
[Link]
Doesn't PulseAudio make audio network transparent when you use X?
I recall once ssh'ing into a remote machine connected to the speakers to play some music with mplayer and being surprised when the sound came out of my laptop's speakers instead, thanks to SSH X forwarding and the PULSE_SERVER property on the root window. That was years ago.
SPICE
Posted Nov 25, 2011 7:05 UTC (Fri) by drag (subscriber, #31333)
[Link]
> Doesn't PulseAudio make audio network transparent when you use X?
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.
SPICE
Posted Nov 25, 2011 17:50 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
[Link]
SPICE can certainly work (in theory) without QEMU and other stuff. It should be fairly easy to start Wayland on an offscreen video buffer and use it for SPICE remoting.
That way you'll even get hardware graphics acceleration on your host. The only thing you'll need is a working EGL library.
What's more, you can in theory later just attach Wayland surface to a real device using the hotplug mechanism. Just imagine - you work remotely on your computer using a tablet while your wife is watching YouTube on it. Then you come to your computer and with a flick of hand transfer your workspace from offscreen buffer to the real console.
All of the infrastructure for this is ready.
SPICE
Posted Nov 26, 2011 23:45 UTC (Sat) by drag (subscriber, #31333)
[Link]
That's very cool.
One of the things people don't notice about Windows is that (I don't understand the exact circumstances) applications can disconnect from a running GUI session and then reconnect without needed to be restarted.
The biggest example that I can think of this happening is one of the reasons how Microsoft was to enable much greater (perceived) stability for graphics drivers for Vista and Windows 7. Many Windows users can testify that occasionally when launching a 3D game or some app or something the entire screen will go black and then restart up again. What has happened (from what it seems like anyways) is that the kernel caught a exception or some other problem with the graphics drivers and had reset everything. The GUI is rebuilt and then all the applications still running are loaded back up and reconnected to the GUI session like nothing happened.
With Wayland, and it's compositing-based windowing system, seems like this sort of thing should be possible.
SPICE
Posted Nov 27, 2011 4:58 UTC (Sun) by raven667 (subscriber, #5198)
[Link]
What has happened (from what it seems like anyways) is that the kernel caught a exception or some other problem with the graphics drivers and had reset everything. The GUI is rebuilt and then all the applications still running are loaded back up and reconnected to the GUI session like nothing happened.
With Wayland, and it's compositing-based windowing system, seems like this sort of thing should be possible.
that sounds way cool. I hope wayland ends up working that way because that sounds like it will be way more reliable in practice
SPICE
Posted Nov 29, 2011 22:19 UTC (Tue) by elanthis (guest, #6227)
[Link]
It also means you can upgrade your graphics driver (which is usually the only time I see that happen) without so much as a restart. Unlike Linux, which requires installing an entire new kernel to get a simple DRM driver update (and this is unlikely to ever change).
SPICE
Posted Dec 1, 2011 23:10 UTC (Thu) by intgr (subscriber, #39733)
[Link]
> when launching a 3D game or some app or something the entire screen will
> go black and then restart up again. What has happened (from what it seems
> like anyways) is that the kernel caught a exception or some other problem
> with the graphics drivers and had reset everything
Linux can recover from these, too (at least the Intel driver does).
SPICE
Posted Nov 26, 2011 0:05 UTC (Sat) by jonabbey (subscriber, #2736)
[Link]
Ah, that's what I need to do, then. We're allowing one-way ssh to the system that provides a web browser to the outside world, and if I can tunnel PulseAudio over that rather than having to let the browser host call back into the inside over a non-encrypted link, that would be great.
SPICE
Posted Nov 26, 2011 0:08 UTC (Sat) by jonabbey (subscriber, #2736)
[Link]
Agreed, it would be wonderful to have SPICE develop into a full featured high performance (GPU accelerated as appropriate) remote desktop system in the free world.
SPICE
Posted Nov 25, 2011 17:49 UTC (Fri) by nix (subscriber, #2304)
[Link]
There is one thing spice is missing which it will eventually need if modern desktop Linux distros are to run under virtualization, and that's 3D virtualization. This is really really hard, but people are working on it. (Chances of getting it working with QEMU's other display targets: pretty much nil.)
SPICE
Posted Nov 25, 2011 17:51 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
[Link]
Uhm. You're missing something. VMWare has working 3D virtualization for a few years.
Aaaaand it's open source! And even mainlined.
SPICE
Posted Nov 25, 2011 18:39 UTC (Fri) by dlang (✭ supporter ✭, #313)
[Link]
vmware open source??
I know they had some flavors that were free of charge for individuals, but I didn't know they had anything that was opensource. do you have a pointer to this?
SPICE
Posted Nov 25, 2011 18:43 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
[Link]
VMWare is definitely NOT open source, but its 3D acceleration architecture is.
Look at vmwgfx driver in Linux and corresponding 'SVGA' driver in Gallium3D in userland.
SPICE
Posted Nov 26, 2011 16:58 UTC (Sat) by nix (subscriber, #2304)
[Link]
Er, yeah, it may have, but VMWare != spice. :)
SPICE
Posted Dec 2, 2011 9:50 UTC (Fri) by robbe (guest, #16131)
[Link]
This 3D virtualization only works locally, not over the network. I don't know whether there is much code reuse possibility for SPICE or similar protocols.
If it were that easy, VMware itself would already offer it for their View product.