Distributing Windows Programs to Linux Desktops?
prell asks: "Our company has approximately 250 Linux desktops, and an array of Linux servers. Recently, we've been presented with the possibility of migrating all or most of these machines to Windows to support one industry-specific application, and we do not want this to happen. Coming to mind immediately were: Wine and CrossOver Office; some sort of multi-user VNC setup; Ndiyo; and VMWare. Keeping in mind that the desktop machines are low-spec (~350MHz CPUs on average), what are our options? How can we preserve our Linux install-base in the presence of a non-canonical Windows program?"
Windows Terminal server with the Linux desktops connecting via rdesktop is another way (assuming the app runs on TS).
(First Post)
I am, and always will be, an idiot. Karma: Coma (mostly effected by
VMware is always a useful app, however your comps may be too slow. CITRIX!! Citrix would be _the_ best solution in this situation. Works great on that speed hardware, doesn't require a great amount of bandwidth, and runs with all applications EXTREMELY well. Clients available for Linux. I'd say, the perfect solution.
Isn't there another solution besides that Windows Application that does the same thing?
Mind Booster Noori
Possibly the easiest would be to set up a collection of winframe servers in your server farm, and attach to them as needed via rdesktop from your Linux desktops.
Then again, I have not implemented this, so your experience may differ.
-Rusty
You never know...
Where I work we have some Linux desktops. At first we used VMware with good results, but on my own machine I use wine. I found that the only windows application I really need to use is Lotus Notes, and it runs very well on wine. However, some people here have excel macros that they can't run on OpenOffice, so they are still running VMware.
What is the ONE application that's about to drive this much churn in your shop? Perhaps rather talking about minor things like preferences and productivity, start talking about the cost of replacing 250 low-spec desktops with new machines, as well as any upgrades needed for your array of servers.
Since you probably can't tell what the ONE application is that's worth turning your whole IT infrastructure upside-down for, can you give a few of its properties? Is it a heavily interactive communications program? Is it a simulator? Before anyone can evaluate alternatives like VNC, WINE or VMWare, more information is needed.
The living have better things to do than to continue hating the dead.
Your company is apparently willing to incur the licensing costs of Windows, Windows applications, and this new app, but is unwilling to upgrade its desktops to hardware worth more than $10.
I think that your company is going to fold. You guys really need to figure out a lot more than how to obviate the need for an OS migration.
Crossover Office won't help you. It's just Wine pre-configured to support a lot of standard apps. People buy it to save themselves the (severe) headaches of hand-configuring Wine.
All the other choices you mention are ones you absolutely must not consider. Why? Because they defeat your primary purpose. Which is not just to get this one Windows app working. It's to maintain Linux as your primary desktop environment. If keeping Linux supreme in your workplace is your primary goal, then you must find a way to allow your users to run this app under Linux. If you force them to fire up a separate Windows environment just to run one program, you're telling them that Linux can't meet their needs. Eventually, they're going to say to each other, "Why are you using this stupid system that the geeks like, but doesn't run all the programs we use? Why don't we just run Windows?"
...if we knew what the software was. Is it a software publisher that is approachable? Would they be willing to consider doing a compile of the application using winelib?
That is make a win32 exe that runs on linux natively.
The more I look at migrating some office to OSS, there is always, ALWAYS that one application that the office can't part with for whatever reason. Or there are excel/word macros that don't work in OOo and they can't/won't re-write them to work in OOo.
If the office is commited to it, then I'd try getting it to compile with Winelib.
Another option is that if it runs under wine, but runs slowly on those dinky machines, get the company to consider setting up a powerful multi-cpu machine to use as a terminal server of sorts, load linux on it, install wine, then the application. Set it up to allow X11 forwarding via ssh. Make sure each user has a shared key with the server for ssh. Now set up a shortcut/script or whatever that does this:
ssh -X user@server 'wine app.exe'
The application will display locally, but the cpu cycles will be on the server.
Will that work for you?
Those with more experience with Wine and winelib, what kind of difficulties should a developer expect if a client makes this request and the devloper in question decides to attempt to comply. Say the app is written in Visual C++ for example...
Karma: Chameleon (mostly due to the fact that you come and go).
All you need is a Windows XP Professional machine with your software on it, and then you can run WinConnect Server XP. It is inexpensive, uses regular Windows RDP, includes a fairly decent admin tool, and you can try it out for free. ThinSoft also makes a Linux client, but you can use rdesktop. The bad news is that it only allows 21 clients concurrently.
No, I don't work for them, but I have used their software quite a bit. Their site leads you to believe that they only sell licenses in groups of three, but in fact, they are more than willing to sell you individual licenses. All in all, their system works rather well.
Show me on the doll where his noodly appendage touched you.
Rolling out windows isn't an option on 350MHz machinery. You'd have to buy some new boxes.
Assuming you just get some cheapo dells...
250 desktops * $400 = $100,000.
Oh, they wanted to run Office apps while they're at it? Assuming you can get some volume discounts that could be another $50,000.
Now you have a bunch of windows boxes but no active directory or shared file servers? You probably have some decent spec servers you could use for these, but you still have to pay for the software and CALs. I don't even know, but let's say another 10,000.
Hmmm, why are there so many smtp packets floating around my network? Oh shit I forgot anti-virus software for everyone. That's gotta be $50/user so there goes something like $12,500. Stuff still gets through because 5% of the time people click OK in IE, so you have to hire a guy that does nothing but disinfect machines all day for $25/hour + benefits. There goes $75,000 per year.
Okay, whew now great we can use this industry specific app...all it cost was a QUARTER MILLION DOLLARS.
For the amount of money that it's going to cost you to do this (easily $500k), you may be able to create your own version of the application. Of course, I realize that that may not always be possible, but it is worth considering.
There may be a web-based version of the application.
You may be able to outsource the application and have your users access it through rdesktop.
If you only have a few users using it at a time, then accessing a bank of Windows machines through VNC should be enough.
If it's a high-powered application that can't be ported, then you're in trouble. If you are really, really lucky, you can run it under an old version of NT on VMware on your current hardware and under Linux. If it requires a new version of Windows and/or significant resources, you need to upgrade all your hardware, no matter what you do. I'd still get a site license for VMware and run Windows under Linux--that way, at least you more easily avoid the costs of downgrading to an all Windows server infrastructure and retraining everybody, and you can more easily distribute and lock down the (virtual) Windows desktops.
Don't blame your decision of using Linux up to now for your predicament--consider yourself lucky that you have been able to save money so far. The cost of dealing with Windows now (hardware upgrades, licenses, installation, system management, etc.) is the cost you would otherwise have been paying roughly every two years as the cost of doing business.
An interesting comment made by a boss o'mine was along the lines of, "Why pay my programmers/techs to support a program that is practically a commodity?" The logic goes: If Operating Systems have vendors why write your own? If Word Processors have vendors why write your own? And so on. You focus your IT crew on the unique problems that your particular organisation faces.
I would push one level farther. Why pay for an OS/Word Processor/Browser if there is one that is free? Pay for the support contracts if you need support. Don't pay for software that there exist perfectly acceptable free substitutes for.
Keep in mind the stuff is free as in speech not just free as in beer. That means if you have an Open Source support guy on staff who contributes into the community, the whole community wins... you get better support... and you still employ the same number of IT staff. Yes, you lose one guy from your core IT goals... but you still lose one person to Anti-Virus stuff and pay-per-year software issues.
If you can do one of the following you might want to consider a Linux/Open Source strategy:
- Use an Open Source Community project to replace most of the functions of your pay-per-year software. You might use Open Office instead of MS Office for example. You could use a universal document format that would work across a variety of platforms.
- Create and maintain a replacement that is platform independent or SOA based. The replacement could be used as a platform for your business' future development. If you go SOA you can then support platforms such as PDAs, Cell Phones, and Kiosks. This only makes sense if you get a good ROI
- You could decide to use Wine/CrossOver/Lin4Win or whatever to provide emulation of Windows. In my personal experience only "stuff" that works with Windows 98 will work properly on Wine.
- I would put VNC or Citrix at the bottom of the list, but it could be a very cheap alternative. You just show the application where you need to. You could potentially get away without having to rewrite/retool anything. (except for the VNC server/client or Citrix server/client)
If none of these ideas offer a big enough payoff or offer a significant savings... I hate to say it but... you really might be better off as a windows shop.Most companies pull money from different "pools" and many companies think that purchasing windows computers is a one time capital expense. It's not. You end up having to purchase new software annually from Microsoft or third parties to keep your systems running and patched.
Make sure you make the decision fully educated about recurring costs and the life-cycles of all your systems. Pay-per-year systems will cost you more in licenses and still require staff to support them. Open Source will require either service and support contracts, additional "expert" staff (or staff training), or both.
You can control whether OSS shifts underneath your company. You cannot control whether a vendor pulls support or shifts technology. If you go OSS you free your company from "Data Hostage" situations where other companies control your business' data.
If you go with Pay-per-year software you can get cheaper staff and supplement them with service/support contracts reasonably cheaply. That will change as more and more IT folks become experts with OSS.
The choice is: commit to a vendor and keep them happy since they essentially hold your data and your company hostage. OR commit to a community and quality employees who will hold expertise that is hard to replace.
[signature]
I can give a concrete example on how we solved a few problems with Windows applications in a Linux-only environment.
I worked on a big migration project here in Bavaria, where the complete Blood Donation Service Of The Bavarian Red Cross switched from individual Windows desktops to a centralized application server/thin client system. I estimate this are about 1000 users affected. The migration was done about two years ago.
A short overview: The users are using Linux based thin clients which I've developed to connect to an array of application servers on which I've worked as well. Every site has its own application servers, in Munich we currently have three or four of them (Dual PIII 1.4GHz, 2GB RAM) and IIRC about 200 people do their daily work on them... no performance problems, but if we had we just would add another server. The thin clients connect to the servers through DNS round robin which is enough load balancing in this case. The application servers are just normal SuSE 8.0 servers with KDE 3.1 where I've configured KDE to restrict what users may do (e.g. they are not allowed to move the Kicker bar... we did things like this to prevent support calls like "My start bar is now on the right, help !" ;-).
Now, the Blood Donation Service people who are working in the areas where the donated blood is prepared and checked for diseases rely on a specific application which only runs on Windows. We evaluated running this application with Wine but it wasn't good enough for this application back then. To make a long story short, this is how we're doing it:
We have a few Linux servers on which we're running Windows terminal servers (I don't know which Windows) in VMWares. I explain the reason for this later. Clients who are working on the application servers connect to the Windows servers with rdesktop. The users' home directories are on NFS servers which means they get their home directory on every application server and on the Windows servers as well. This works very well. Only a few dozen people need to access Windows servers because of this and another industry-specific application.
We needed to identify which thin client is accessing the Windows application. Because rdesktop runs on the application server we needed to do a trick: I've enhanced our thin clients to include a finger server which tells finger clients the MAC address of the thin client. When the users log in to the application server the MAC address is finger'ed from the thin client and stored in an environment variable. And when the users then start their rdesktop the MAC address is passed as host name ;-) So Windows thinks the user is connecting from, say, a computer called 00AB12CD34EF and this can be evaluated on the Windows side :-)
Now for the reason why we run Windows in VMWares: the whole point of our architecture is that we have a master site where all bavarian application servers are configured (new applications get installed there, for example) and they synchronize through rsync to all sites. This means all application servers are in sync and changes are only done on exactly one server. We wanted to do the same with Windows. In short: it's not possible with Windows-only methods and applications because of some limitations of Windows. The best solution is to run Windows in a Linux VMWare and rsync the VMWare disk from the master server to all site servers :-)
This setup is running full-scale (i.e. in the complete Blood Donation Service of Bavaria) for about one and a half years, and it's running very well. No major problems. Even the 50+ secretaries didn't have any major problems (except for a bug in the Linux version of Acrobat Reader 5.0.x and PDF forms) ;-)