Best setup for Linux development from Windows?

Question

What's the best setup for developing Linux apps from a Windows workstation? Right now I'm connected via SSH to our Linux development server and am using Eclipse, forwarded over SSH via PuTTY, to the public domain version of Xming running on my Windows workstation. It works, but it's not great; Eclipse's response times are far from snappy (noticeably worse than Eclipse running natively on my much slower Windows workstation), I can't resize some dialog boxes, and I haven't figured out a good way to reconfigure my fonts.

Is there a better setup available?

Edit: This is for C/C++ development.

Answer 1

Cygwin might be helpful.

Answer 2

An easy to setup option would be to run Eclipse natively in windows but deploy the code via a Samba share on the Linux machine (which you can mount as another drive) (or SSH/SCP if SMB is not an option) and then run it there via SSH console.

Another easy to setup option is to simply develop on Linux via freenx or a similar tool instead of a full blown X session, check this answer: http://serverfault.com/questions/11367/remote-desktopping-from-windows-to-linux/11372#11372

The other options (Virtualization, Linux running inside windows, Cygwin) are indeed valid but have their drawbacks, like being more machine demanding, harder to setup, or not equivalent enough to the actual linux environment, but may very well be worth your while if you have the machine and the scenario justifies their use.

Doing everything on the Linux side will always have some drawbacks if your machine is Windows.

I personally have a Linux box where everybody else has Windows and do Windows dev inside a VM, but it has costed me a lot of RAM and some network setup pains.

Answer 3

You might try other X servers on Windows such as xwin32 and hummingbird. Note that these are commercial implementations.

Another solution is to install a VM server on your Windows box and install Linux on the VM. Options include VMware (non-free) and Microsoft Virtual PC (free download). VMware is much nicer than VirtualPC (64-bit support, more incentive to support Linux client OSes, etc.). There may also

Answer 4

For development I usually use a Linux virtual machine on my Windows box. It will probably send Linux users running to the bathroom to wash their hands, but I do all of my development in Visual Studio, and I have a custom Visual Studio plugin that invokes G++ through the virtual machine and pipes the output into the VS output window. With a quick change of a Combo box I can build and test for Windows or Linux.

Answer 5

Use sharpdevelop / Visual Studio / Mono Develop and make Mono applications.

Easy to set up and program for. Test through vmware / vpc images.

Answer 6

You could take a look at setting up a svn server on the linux box and then using something like TeamCity todo a build on commit. You could write your code locally and do a commit when you want it to be compiled.

Answer 7

Options for Linux on Windows:

Tools Only

Given you're using Eclipse I'm going to assume you want a full IDE, but if you can get by with just the GNU/Linux tools, there are a few choices.

• cygwin gives you a bash shell with lots of tools, including an X11 server. This has been around awhile and is mature.
• msys is a smaller, lightweight alternative to cygwin.
• GNU utilities for Win32 is another lightweight alternative. These are native versions of the tools, as opposed to cygwin which requires a cygwin DLL to fake out its tools into thinking they are running on Linux.

Linux in a Windows Process

There are several packages that will run Linux as a Windows process, without simulating an entire PC as virtualization does. They use Cooperative Linux, a.k.a. coLinux, which is limited to 32-bit systems. These don't have the overhead of virtualizing, and they start up faster since you're not booting a virtual PC. This is a little more on the experimental side and may not be as stable as some of the virtualization options.

• Portable Ubuntu
• andLinux

Virtualization

Virtualization software lets you boot up another OS in a virtual PC, one that shares hardware with the host OS. This is pretty tried-and-true. There are nice options here for taking snapshots of your Virtual PC in a particular state, suspend/resume a virtual PC, etc. It's nice to be able to experiment with a virtual PC, add a few packages, then revert to a previous snapshot and "start clean".

• VMWare
• VirtualBox
• VirtualPC

In my case...

Sounds like your environment has different performance characteristics, but here's my situation: I started out with Eclipse on my Windows laptop (doing Rails development), found this sluggish, and switched to using putty to ssh into a fast Linux box. I do my editing via an emacs running on the Linux server, displayed on Windows using Xming. Or I use native emacs on Windows, editing the files shared via NFS. The latter is slower in my environment due to sluggish saves.

When working from home, I ditch X because it is too slow with remote clients, and just run emacs -nw within a putty window. I then use GNU screen so that I have multiple "windows", and so that I can easily resume where I left off if my network connection flakes out.

Answer 8

The best approach that I've found is to:

1. keep your code portable
2. develop natively on your desktop
3. verify any OS dependencies (minimize these as much as possible)
4. deploy to your target regularly, test & debug there

I know that this isn't a direct answer, but using an IDE for development through X is painful with most of the free tools. The only way that I've been productive doing work this way was when I was running a UNIX-like on my desktop so X was native. If you are going to use this approach, try a commercial X solution on the desktop.

Other than that, consider ditching the IDE and doing your development and debugging via SSH, a terminal editor (e.g., vi, pico, ee, emacs), make/ant, and gdb.

The best approach for you is going to be driven by your programming language and the type of application you're developing. If you are doing GUI applications, then using X might be the only approach that is acceptable. If you are doing back-office/daemon development, then the SSH and terminal approach will probably work though you probably want to get really comfortable with either vi or emacs.

EDIT: just noticed that you are doing C/C++ development. Consider using a cross platform framework if you aren't already. Using something like Qt, APR, ACE, or Poco should make it possible to natively develop under Windows with a deploy/debug step to your Linux environment.

Answer 9

I've done what you want to do for exactly the same reason: full control over the output (you're having font issues with your current solution) and much slower Windows machine than the remote Linux development box.

Most answers are bogus: having a "Linux development environment" is not just "having an IDE". It's about having the whole Un*x power at your fingertips.

Is it a local or remote Linux server? bandwith issues? Because on a LAN, even an old 100 MBit/s LAN, FreeNX flies. How's the load on that Linux server?

Setup the free FreeNX on the Linux system, install the free FreeNX client on the Windows machine and bingo, you've got your Linux development environment at your fingertips.

FreeNX is much more efficient than VNC, it's night day (VNC is actually pretty bad perfs wise, even compare to Windows's Remote Desktop... But FreeNX flies).

Regarding speed, a long time ago, I set up my main Linux workstation (it was a Pentium 4 / 2GB of memory back in the days) on which I was developing full-time using IntelliJ IDEA (another IDE), to serve a full X session (complete with a window manager etc.) that another developer was displaying remotely to... run another IntelliJ instance (and access all the Un*x niceties). It was on a LAN 100 Mbit/s and it was as if the app was local for the other developer.

Anyway, on today's hardware I cannot imagine how this could not work: I now have here a Core 2 Duo / 4GB of ram as my main desktop and a Gigabit LAN.

Such a setup was working perfectly 4 years ago, it would work perfectly today.

Now if you tell me you have bandwith issues or that the Linux machine you've got your account on is under heavy load or that it's not on the LAN, then things may be different...

How the younger developers who want a powerful Un*x system do it at the company I'm consulting for nowadays (that only has Windows desktops)? Most of them bring their shiny MacBook Pro and use that to develop ;)