On Fri, Sep 4, 2020 at 10:18 PM ivanmarcus <[email protected]> wrote:
> Nick, > > I see Mark's valuable contribution, mine is probably *much* less so > because I struggle to avoid the ogre in the room that you want to ignore > (understandably!). > > To that end I can really only acknowledge the good idea, and let you know > it's been read by others. Technically I've gone a short way down this track > in using Guacamole to access different VM's, and from there considering how > one might improve things to make a more comprehensive package. > > Unfortunately I keep banging up against the M$ thing, which is bloody > frustrating because it works so well. If it wasn't for that I expect this > would be very popular. > > As things stand at the moment I wonder whether you have any particular use > case, or have had anyone ask about such deployment (other than the odd > enquiry I've seen on the mailing list)? My reason for asking is really just > to prompt a little discussion/thought as to how many would use such a > thing? It seems to me one could spend a lot of time on it; it'd be good to > know there were those that would use the result. > Finally going back and replying to this thread... Well, you threaten to open a can of worms, there :-). I have several use-cases and reasons to want to do this, stemming from long-standing beefs I have with the current VDI software providers out there, and some of which might require some therapy to get past. In both my current career and my previous one I had use-cases for Floating VDI pools - places where I can set up a smaller number of virtual desktop systems and have a large pool of users share them as required. The obvious question that pops into everyone's mind is, "Why not just use a Windows Server with RDSH (aka Terminal Services)?" The answer to that is probably more complicated than needs to be explained in this e-mail thread, aside from saying that there are situations where a Windows Workstation O/S and/or experience is required over a RDSH/TS connection. With the two current providers of VDI software that handle floating pools, I have many, many beefs: - Cost: They are hideously expensive, which drives up the cost of VDI for everyone. There are many situations where VDI would be helpful to people, but the cost of implementing it is prohibitive. AWS has come out with some offerings over the past couple of years that may actually give the other guys a run for their money, but, in my view, more competition is better and will drive down the price. One of the reasons I love Open Source Software is that it gives everyone access to the technology without putting you in a place where you have to be able to afford it. In my past career I worked for a small enough company that I couldn't afford to go out and purchase everything that I wanted to implement, and OSS gave me many opportunities to do things I wouldn't have had access to. (See what I mean about needing some therapy?!) - Vendor Lock-In: Related to money, the other challenge of the current ones is that they do not give you choices in many of the components. If you purchase the VDI package, you are also required to purchase the Hypervisor produced by the same company to run the software, and you can't run the Hypervisor of your choosing. This further prevents you from optimizing cost because you choose a VDI package based on the features of that package, but then are forced to absorb whatever costs they choose for you associated with their hypervisor. Having a free product that works on whatever hypervisor(s) someone chooses to implement using the SDKs/APIs provided by those vendors, and one that can also easily span into Cloud platforms, lets you choose what you pay for the compute services. - Client Support: The other VDI vendors out there have recently started supporting browser-only connectivity (HTML5 clients), but this is pretty recent and wasn't always around, and still can be a little glitchy at times. The lack of browser support for their platforms meant that you had to have their client software, which meant that you were at the mercy of their support for various client platforms, and Linux wasn't generally on the list. Again, things have changed and improved recently in that regard, but it hasn't always been the case. - Orchestration Platforms: The current on-premise VDI platforms have orchestration tools that generally run on Windows and require IIS and SQL server. This goes back to allowing people to choose the platform... - Open Source: Because there aren't a lot of Open Source VDI projects/products, because I believe in Open Source software and communities, and because many of the existing VDI platforms have (ab)used open source software without contributing back to the projects and communities that they are using to making insane amounts of money off of. > I should add, at the risk of doing exactly what you didn't want (but > please bear with me), that as much as want to rally and rail about M$ > policies I have spent a lot of time trying to research how one might > legitimately achieve the end result that people might want (all the while > using something along the lines of what you propose). In this I've had > various clients that really just want to run a simple subset of progs - > let's say M$ Office as an example - remotely. > > None of these people would have an issue paying M$ the standard OEM OS fee > they pay for a PC, but as that isn't allowed by policy (and the legit way > is incredibly complex/expensive) I've looked at using Wine, Crossover, > ReactOS etc. Really, I've gone through a *lot* of calories but > unfortunately haven't yet found a suitable way forward, so I'd be very keen > to know if you or anyone else has figured out a solution? > > In my experience the only complete and legitimate solution is to rip off the band-aide, and ditch M$ Office. This isn't without its implications and sacrifices - I do think that Micro$oft Office is one of the better, more complete, and more user-friendly office suites out there. Others are getting better, but still not quite there, and, importantly, not what users expect. However, Micro$oft continues to leverage their power, money, and market share to herd their customers in the direction they want them (=>Azure), and breaking free from that has its costs. (As a side note, I've just found out that, back in 2019, Microsoft made changes to their Office365 license agreement that stipulates that, if you want to run the Office365 applications on any shared tenant platform (=cloud on non-dedicated hosts other than Azure), you have to get written approval from Microsoft. My source for this was not Microsoft or a Microsoft reseller.) > I realise this goes further than you wished to ringfence the discussion, > so please ignore it as you wish, but on the off-chance I've overlooked > something that could make a VDI system such as this more pertinent or > widely applicable I thought I'd put it out there... > Appreciate the feedback and insight! -Nick
