Application Virtualization in Linux Environment
-
@scottalanmiller said in Application Virtualization in Linux Environment:
@Pete-S said in Application Virtualization in Linux Environment:
I had some problems with it when I tested it with NX as it only supported the older open source protocols.
Can you not install the commercial NX client onto it?
I can't remember but I think NoMachine didn't have the RPi3 version at the time. Maybe I should give this entire thing a new spin with the new RPi4 I have. In the past the problem with graphics on the RPi has been the GPU support and hardware offloading.
-
In Windows, I've set up RemoteApp with some applications. It's not App Virtualization at all. It's basically an app installed on a Windows server, accessed via RDP, made to look like a local app from a user's perspective.
I only did this because in cases it being a shitty app, not running well on Windows computers because of incompatibility problems, usually with other things installed with conflicting versions of requirements with other apps.
-
In Fedora for example, their way around this kind of thing is their modular installs. Or containers for example with most things.
-
@EddieJennings I think the biggest challenges there are two fold...
-
Defining what you mean. Because XenApp does one thing, and application virtualization is something different. And the use case you are mentioning (Guacamole) is a third. Instead of taking a product or term and looking for something similar, start with the functionality that you wish to emulate.
-
What's the end goal. What problem do you want to solve.
-
-
@Obsolesce said in Application Virtualization in Linux Environment:
In Windows, I've set up RemoteApp with some applications. It's not App Virtualization at all. It's basically an app installed on a Windows server, accessed via RDP, made to look like a local app from a user's perspective.
Yeah, there was a thing about ten years ago to brand anything with RDP involved as "virtualization", even though there is nothing virtual about it.
-
@scottalanmiller said in Application Virtualization in Linux Environment:
@Obsolesce said in Application Virtualization in Linux Environment:
In Windows, I've set up RemoteApp with some applications. It's not App Virtualization at all. It's basically an app installed on a Windows server, accessed via RDP, made to look like a local app from a user's perspective.
Yeah, there was a thing about ten years ago to brand anything with RDP involved as "virtualization", even though there is nothing virtual about it.
Hey, the RDP desktop is virtual. It's not a physical desktop environment on a screen somewhere
-
@Pete-S said in Application Virtualization in Linux Environment:
@scottalanmiller said in Application Virtualization in Linux Environment:
@Obsolesce said in Application Virtualization in Linux Environment:
In Windows, I've set up RemoteApp with some applications. It's not App Virtualization at all. It's basically an app installed on a Windows server, accessed via RDP, made to look like a local app from a user's perspective.
Yeah, there was a thing about ten years ago to brand anything with RDP involved as "virtualization", even though there is nothing virtual about it.
Hey, the RDP desktop is virtual. It's not a physical desktop environment on a screen somewhere
It was a big push when companies couldn't figure out what "virtual" meant, and they kept seeing system accessed remotely. And the companies that couldn't figure out virtual often were not that versed in remote access either, so they started assuming that things like Remote Desktop was the virtualization rather than the hardware abstraction layer and so started saying that they were virtualized just because someone, somewhere used RDP for something, lol. Such a train wreck.
-
@scottalanmiller said in Application Virtualization in Linux Environment:
@EddieJennings I think the biggest challenges there are two fold...
- Defining what you mean. Because XenApp does one thing, and application virtualization is something different. And the use case you are mentioning (Guacamole) is a third.
Through this thread I'm trying to figure that out. Let's start with application virtualization. I found this from NIST, and from that definition, XenApp, as you folks said, does not function in that fashion. So, my use of "application virtualization" is incorrect.
Instead of taking a product or term and looking for something similar, start with the functionality that you wish to emulate.
The functionality I'm wanting to emulate / see if it can exist (if for nothing else, a thought experiment) is a sample of what we have at work without using Windows: User logs into a machine (in our case at work, a WYSE Terminal), and sees a desktop with icons, which launch an instance of an application like LibreOffice Writer where LibreOffice is installed on another VM in the network. Any documents that would be created and saved by that user would be stored on a file share.
- What's the end goal.
The end goal is see if this
$thingwe do at work is solely dependant on having infrastructure running Windows, or (assuming applications are available that can run on Linux) could the$thingbe done on infrastructure running a Linux distro.What problem do you want to solve.
I'm not trying to solve a problem.
-
@EddieJennings said in Application Virtualization in Linux Environment:
The functionality I'm wanting to emulate / see if it can exist (if for nothing else, a thought experiment) is a sample of what we have at work without using Windows: User logs into a machine (in our case at work, a WYSE Terminal), and sees a desktop with icons, which launch an instance of an application like LibreOffice Writer where LibreOffice is installed on another VM in the network.
Ah ha, okay. This is "remote desktop", and just that. Leave the term "application" out because in the context of remote access that would refer to a single application being accessed remotely rather than a desktop.
With an entire desktop being accessed remotely, it's just called a remote desktop. There are two styles... multiple users per machine aka terminal server, or a single user per machine called VDI. But on the end user side, it's just a remote desktop.
You can experience this in any Windows environment by using Remote Desktop to connect to another Windows box. This is the best known example of this.
-
@EddieJennings said in Application Virtualization in Linux Environment:
The end goal is see if this $thing we do at work is solely dependant on having infrastructure running Windows, or (assuming applications are available that can run on Linux) could the $thing be done on infrastructure running a Linux distro.
I see. So you have options...
Citrix XenApp is just an enhanced version of Microsoft's RDS. RDS is just extra features on regular RDP deployed on Windows. You can use straight RDP, RDS, XenApp, XenDesktop, VNC, NX, and other tools on Windows to access other machines remotely.
Then on to Linux...
-
In the UNIX world, which includes Linux, X Windows is the basis for the desktop environment. X Windows does all desktops in this way, even when local. It creates a loopback over 127.0.0.1 and has both the "server" and the "client" on the same box, there isn't any concept of skipping this functionality, it's just automated and hidden when all on one desktop.
So having a remote desktop like XenApp does on Windows is native to UNIX and has been available since the first networking UNIX boxes with desktops were available. But X is not very efficient, it is tuned for the "unlimited" bandwidth and zero latency of the loopback environment.
Linux standardly comes with VNC and RDP built it. You can get XenApp just like on Windows, or NX. Or you can just use the X system that is always there, it even works over SSH.
-
If it helps to visualize...
XenApp is an ICA server. ICA is the same protocol as RDP, but with some enhancements. Microsoft actually licenses RDP from Citrix. RDS is to XenApp as RDP is to ICA. So XenApp is basically a beefed up RDS server, same functionality, just more features and better performance. That's why to use XenApp, you have to license RDS if you are on Windows.
-
If you want to use a "remote desktop" but only view one application, it's called seamless window mode.
Check out which "remote desktop"-software support this:
https://en.wikipedia.org/wiki/Comparison_of_remote_desktop_software#Features -
And for those wondering why you might want to only get a single application, it's sometimes nice so that you can have a single window dedicated to an app that runs remotely. It integrates with your existing desktop because often you don't want an entire desktop from "somewhere else."
One example when this is useful is when I need a web browser from another location for testing. Or you might want just a spreadsheet from a server with loads of resources.
-
Thread has been enlightening; though, I feel I ought have been able to figure it out on my own. The goal was attaining some wisdom, so I suppose it matters not the path
There's one other thing I didn't mentioned in the thread, but did mention to Scott through another channel. Another scenario at work are for folks like me, who don't have a WYSE terminal. If I wanted, I could browse to a URL, which is our Storefront server, where I'm presented with various icons of applications that are hosted on various servers. And upon thinking about what's going on, this, too, is simply remote desktop.
-
@EddieJennings said in Application Virtualization in Linux Environment:
Another scenario at work are for folks like me, who don't have a WYSE terminal.
I think the thin client is throwing you off. That thin client is just a normal computer with very little installed on it. A thin client works the same as any computer, it's just a computer that runs an RDP or ICA client. Thin clients have no special sauce, they are just really, really wimpy computers. Any Windows, Linux, MacOS, Android, or iOS device will do the same stuff.
Often thin clients are set to launch their RDP client on boot up. But you can do the same thing with Windows for example. Just set RDP to launch on boot and your regular Windows 10 acts identically to a thin client.
-
@EddieJennings said in Application Virtualization in Linux Environment:
And upon thinking about what's going on, this, too, is simply remote desktop.
Yup, it's all the same
-
@scottalanmiller said in Application Virtualization in Linux Environment:
@EddieJennings said in Application Virtualization in Linux Environment:
Another scenario at work are for folks like me, who don't have a WYSE terminal.
I think the thin client is throwing you off. That thin client is just a normal computer with very little installed on it. A thin client works the same as any computer, it's just a computer that runs an RDP or ICA client. Thin clients have no special sauce, they are just really, really wimpy computers. Any Windows, Linux, MacOS, Android, or iOS device will do the same stuff.
Often thin clients are set to launch their RDP client on boot up. But you can do the same thing with Windows for example. Just set RDP to launch on boot and your regular Windows 10 acts identically to a thin client.
That I do know. Upon boot our thin clients really are just running the ICA client.
-
@EddieJennings said in Application Virtualization in Linux Environment:
I’ve had a little time to think this through. It seems like offering virtual desktops through Linux could be as simple as having something like Guacamole set up. Users could use whatever computer they want as long as they have a browser, they login to Guacamole, have their desktop presented and be on their way. I’m probably oversimplifying Guacamole, but at a high level that seems like what’s going on.
It seems like it be best to do the reverse. Make your workstations run linux desktop, and then only access Windows terminal services when needed. That would be a more efficient use of resources IMO.
That is considering you have mostly web apps. I am assuming this is probably the case as you want to present a linux desktop to the user.
-
@IRJ said in Application Virtualization in Linux Environment:
It seems like it be best to do the reverse. Make your workstations run linux desktop, and then only access Windows terminal services when needed. That would be a more efficient use of resources IMO.
Excellent point. I do this with Remmina on Linux.
