Thanks Nick, I'd quite forgotten this discussion, but useful to have
your comments all the same.
There's not a lot I can add - mostly because I entirely agree with
pretty much everything you've said !
Unfortunately the issue remains for me (or to be more accurate, my
clients - because I long ago ditched M$) that most of them expect to use
M$Office etc and *no* alternative will be considered.
Other than the rigidity of their outlook I don't have any issue with
this and would otherwise be happy enough in my support of their end
goal, if it wasn't for the balls around the (M$) OS requirements on a
virtual/remote platform.
So, FWIW, I continue to monitor this, and from time to time re-ignite
the research to see what others have done in such situations (and/or to
see if M$ have become more user-friendly [haha]), but a suitable answer
continues to be elusive.
Should anything arise I'll let you know, it does seem to me something
that many would benefit from. I remain ever hopeful there will be a way
forward sooner or later...
Cheers, Luke.
On 18/01/21 8:37 am, Nick Couchman wrote:
On Fri, Sep 4, 2020 at 10:18 PM ivanmarcus <[email protected]
<mailto:[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
