Cygwin vs Linux Virtual Machine for Development? - linux

< skippable part >
I work in IT (mostly desktop support and network administration) in a Windows environment, and I occasionally program.
A couple weeks ago, I decided I couldn't be as effective as I want to be without a Bash environment for my command prompt needs. This is especially true when I am using Ruby and git. I used Msysgit for a while, but I just didn't like how it wasn't extensible like Linux. So, I installed Cygwin and played around with that for a couple weeks.
As great as Cygwin is, it seems like it is meant to be a suped up command prompt, and its compatibility with Linux is just a pleasant side effect. This especially became evident when I tried to upgrade Ruby to 1.9.3 (it worked, but it wasn't straightforward), install rvm (never worked), and install RMagick (may or may not work, but looks like a headache).
So, now I'm considering running Linux in a virtual machine. But I'm worried that might be another can of worms and I'll have wasted hours before I find that out. I like that Cygwin runs in Windows and I get to use my IDE, user folder, and more with it. But I don't like that support for it is not as thorough as for a major distro.
< /skippable part >
Does anyone here have insight on using Cygwin vs running a Linux virtual machine?
Any advice on setting up a Linux development environment in a virtual machine within Windows?

I have faced common issues before, and the best solution according to my experience is just 2 workstations :).
Apart from that having Linux running in a virtual environment is way better.
First of all, you will have full Linux capabilities (except 3d acceleration, but you probably don't need that).
You will have the capability of creating snapshots and revert back to them when things go wrong!
You can start multiple environment using templates, which is very convenient.
The only downfall I can think of is performance issues of the host machine.
If it's a normal workstation/PC, an IDE + one virtual machine + a 100+tabs browser just makes it slow.

1: cygwin is good for quick hacks, and for being able to acces host-os resources(you can run IE for example in a bash script). For something tightly integrated and some "real" word, go to a vm. It will emulate everything and separate development from the real machine, and this may be a good thing in some cases... as a plus it simulates a real server:)
2: in virtualbox at least, you have shared folders, and you can share a local folder, and see it in the vm as a local folder(local or as a windows share..it actually depends). Then you can use that "entry point" to symlink stuff into the vm, and do the things you need with the real files being located in the real(host) machine

SSH into a linux box. This is what everyone does. Why isn't this the answer?

There is something I have heard of called Cooperative Linux. It runs Linux alongside with Windows kernel so you can use them at the same time. I've never used it, but here:
http://www.colinux.org/

What I think now is getting the pros of 2 options is using
Docker
, it is giving you cygwin simplicity and VM functionality with better performance.

Linux in a virtual machine will give you the experience you want more than cygwin or any mock shell as I like to call them.
Running VM's though require a lot of ram depending on whether you want a desktop version of linux or just a command line version.
Myself in work I have a pc with 8gb of ram and I run ubuntu 64bit as main OS, two ubuntu servers (these are for dev environments two different projects) and a windows 7 VM and a win XP VM.
I can run the two ubuntu servers and one other VM at the same time, key here is more ram if you want to be able to do VM's.

If you're going to be working with Ruby then get an Ubuntu virtual machine up and running :) I've not tried Ruby, etc on Windows but I have heard that it is a pain to setup and configure. I use a Mac for all my Rails development so I cannot comment on the Windows side for that.
As for virtual machine creation, I prefer VMware Workstation, however there are free alternatives such as Virtualbox and VMware Server.

I'm using a Linux VM within a Windows seven environment as this VM is as representative as possible of the final production environment. The whole setup is binded to the Eclipse IDE under ms-Windows seven. So this is really great for local full testing, before committing or tagging the tested version to the production servers.
As you mentioned as well, this takes some time to get properly setup and fully configured. So if your need is only for little tricks or tasks, you may keep using cygwin. For example, I faced significant issues to configure perl and compile mysql within cygwin. So it's ok for basic usages, but not to fully take advantage of a full linux environment.
Your choice strongly depends on the final server setup purpose. A VM will do it whatever your need is. The setup cost for it is higher, so this time investment must be used often to get returned.

Related

Are there any benefits to keep your files (scripts) on WSL filesystem

When reading the WSL documentation, it is stated that:
"Unlike our practice with trying to exclusively install programs and software on Ubuntu, our files and folders need to live exclusively on the Windows FS [...] Windows and Windows Apps can only read and write Windows files, and VSCode will be making our changes."
I understand the reasoning behind this and indeed, if one uses VSCode for example, it all makes sense. But my question is:
Is there any real reason why you couldn't keep your files (i.e. scripts) on the WSL filesystem itself? More specifically, if you don't ever intend to use the Windows filesystem (i.e you won't ever need a GUI or else), is there any sense in placing the files in the Windows FS?
Obviously you need to make sure you backup your data (GitHub or else) but aside from that, is there any downside? I guess what I'm saying is: can I use WSL like a VM? Can I keep BOTH software AND scripts all in WSL, separate from the Windows filesystem?
PS: The reason for avoiding a VM in this context is because I have a low spec laptop which has struggled a lot in the past with VMs (slow, not enough RAM), and so far, WSL seems be running much more smoothly.
Thanks
The simple answer is yes, you can use WSL as if it were a VM. WSL is for the most part fully-fledged Linux, and you can use Linux as your primary operating system, ignoring the fact you need to start it from within Windows. I haven't tried WSL 2, but it's said to be implemented as a fast VM, which is exactly what you ask for. (Further, the lack of GUIs can be mitigated using built in support for sending X data over SSH to the Windows half of your computer, and display it with an X Server. If I remember correctly, these two articles got me most of my way there.)
However, if you want to get pedantic, you can't store any files separate from your Windows filesystem on WSL 1. If you run e.g. Ubuntu, your Linux filesystem is instead always contained within %USERPROFILE%\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState, so it'll technically not be separate. I can't test WSL 2, but according to this article, WSL 2 also stores its data in that folder, just as a single VDHX image. Presumably every WSL distro stores its data on the Windows filesystem.
Warning: Do not access the files themselves in your Linux filesystem within AppData using Windows tools, or you run a high risk of corrupting those files.
Yes, you can, and only place files in the Windows filesystem if you want to share them with Windows programs. Moreover, in Windows 1903 you don't need to place files in Windows filesystem to share them with Windows Programs, they can access them.
In WSL2 they encourage you to keep everything in WSL filesystem to take advantage of the filesystem's performance improve.
So, yes you can and you should.

What is the best practice to code when the project is on a Guest OS (Virtualbox)?

I have a project and the files are on Guest OS (Red Hat Enterprise Linux) with Virtualbox, my host OS is Mac OS. I used to coding right in RHEL with editor Atom. But my boss told me that it's inefficient to code in a Guest OS, well, it makes sense because Mac OS or Windows is more responsive than linux, so I changed my way:
Copy the whole project located on RHEL to a share folder between Mac OS and RHEL using rsync
Code with Atom in Mac OS
Copy back the project in share folder to the original project in RHEL by rsync
I'm using Atom (not vim in RHEL) because it can edit the whole project in one window which is convenient for my situation. But there is a problem: after copying back the project in Step 3, git status shows everything has been changed even though I just edited only a few files. That is a little annoying.
Is there any better way to code in such environment? any advice is appreciated.
BretzL's suggestion to use shared folders is a good one, but I think it's important to address the underlying issue: your boss' assumption about coding being inefficient or slow just because you're working on a VM is simply not true.
It sounds like your new workflow, which was instituted as a result of his/her advice, is causing you to have a harder time developing that you did on the VM. The shared folders will help with that, but if you have the VM configured to have access to enough cores and memory, then its performance for most tasks will be fine, and there may not be any problem with developing on the VM directly. I do a significant amount of development on a VM, and haven't had any issues. You may experience slower builds on the VM if you're building whole kernels or other large projects, but if that's not the case, it should be fine.
If you didn't have any performance or productivity problems before forcing yourself to work outside of the VM, then... it wasn't a problem.
(I also have an issue with the assumption that Linux is always less responsive than Windows or Mac OS, but that's a debate for a different day.)
VirtualBox supports shared folders, so you dont need to rsync back and forth. Just mount the shared folder into where your application server on RHEL guest expects the code.
I also recommend you take a look at https://www.vagrantup.com/ for managing developer VMs.

Develop on Windows and running on linux machines

I need to develop applications for Linux but I don't want to either program on Linux (I already have all my "precious" tools setted up) or test it on Windows using some kind of POSIX for Windows and hoping that if runs well on that runs well on real Linux.
What's the better choice? Preferentially I want to use Eclipse IDE for compile/run/debug and run my programs on a Linux distribution that is running on a local VM or remote.
Right now I'm using a similar approach, but for Java Web Service testing on a remote server. Perhaps that's the way to go?
Edit:
In order to beter explain what I want, here is the steps that I want to follow:
Program in C, for POSIX compliant systems, using Eclipse on Windows
Make small tests on Windows, perhaps using Cygwin (this is not mandatory it's just to be quicker)
From my Windows Eclipse, I want to run/debug my application on a real Linux environment (could be a VM or a remote machine) and, preferentially, redirect the application stdout to my computer. The Linux machine only exists in order to garantee that everything runs ok, no need of even open it.
One thing that I didn't mentioned: all of the applications are command line, no need for GUI, just input from a shell and read the output.
First, install Linux in a virtual PC like VirtualBox or VirtualPC or something from vmware.
Then configure Eclipse for remote development. That allows you to run tools (like the debugger, the compiler suite, etc) on Linux from your Windows desktop inside of Eclipse. You edit the files just like you're used to, you debug as if the app was running local on Windows, etc. Eclipse will do the plumbing.
Remote server is the way to go. But most people have a powerful enough machine to run a 32-bit Linux distro in Virtualbox which is better than a real remote server because you have full control of setup and config.
But install cygwin including GCC and use that to run initial compile (and maybe unit tests) locally. Also, do use Valgrind on your Linux VM to help you produce cleaner code.

How to verify cross platform installation steps

I have to check installation steps of my application on different production machines. I want to check how can I install my application on HP UX. I have only linux/windows machines but dont have real physical HP unix machine. Is there any way i can check installation steps of HP unix. I am thinking of any virtual environment or any flavour that run on linux or windows which gives accessiblity and functionality of HP unix.
I am looking something to cross check platfrom installation steps.
The short answer is no. HP-UX is as different from Linux as Linux is from Windows (almost). There would be many differences in libraries, patches, installed utilities, build tools, etc.
A few examples:
HP-UX does not come pre-installed with the bash shell
HP-UX uses a proprietary software packager and installer called swinstall (analogous to RPM but completely different)
Partition layout is different
Many common utilities behave differently. "echo" is one of many examples. This will affect things if your build process uses shell utilities
Even if you can test the install, don't you need to test the product's operation on HP-UX?
Not saying it's impossible. If your application uses basic, nonspecific utilities for install, it might work. There is no way to know without a running installation. Unfortunately you need Itanium hardware and the O/S.
My recommendation would be to get your application working on Solaris and any other Unixes first. The more platforms you test on, the more portable your code will become on all of them. Then, put out some feelers and find someone with a system you can borrow time on.
Worst case, find an Itanium server like an rx2620 on eBay, should not cost too much. Even better if the seller forgets to wipe the O/S :). You'll need a terminal and possibly null modem. 11.31 (11iv3) is the latest version of the O/S.

Advantages of Using Linux as primary developer desktop [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I want to get some input on some of the advantages of why developers should and need to use Linux as their primary development desktop on a daily basic as opposed to using Windows. This is particulary helpful when your Dev, QA, and Production environments are Linux.
The current analogy that I keep coming back to is. If I build my demo car as a Ford Escort, but my project car is a Ford Mustang, it doesn't make sense at all.
I'm currently at an IT department that allows dual boot with Windows and Linux, but some run Linux while the vast majority use Windows.
Here's several advantages that I've came up with since using Linux as a primary desktop.
Same Exact operating system as Dev, QA, and Production
Same Scripts (.sh) instead of maintaining (.bat and *.sh). Somewhat mitigated by using cygwin, but still a bit different.
Team learns simple commands such as: cd, ls, cat, top
Team learns Advanced commands like: pkill, pgrep, chmod, su, sudo, ssh, scp
Full access to installs typically for Linux, such as RPM, DEB installs just like the target environments.
The list could go on and on, but I want to get some feedback of anything that I may have missed, or even any disadvantages (of course there are some). To me it makes sense to migrate an entire team over to using Linux, and using Virtual Box, running Windows XP VM's to test functional items that 95% of most of the world uses.
This is similar but a little different thread going on here as well.
link text
I have to say getting forced into SSH access to a linux development box for PHP/MySQL development has been one of my greatest and fastest growth experiences as a developer (who formerly worked only in windows XP as a dev environment) as well as bridging some of the knowledge gap between development and sysadmin tasks which is great for developers to understand more about, especially if you ever end up in a one-man army kind of situation.
I was all about windows/eclipse and point and click, and now I am all about VIM and keyboard shortcuts. The color coding/auto tab complete stuff is pretty good these days.
Where I work we use Rackspace Cloud servers for production and development. I imaged the production server (2G ram/CentOS 5.2 stack) for a dev server (so the environment IS EXACTLY THE SAME not close but EXACT) and run it on the smallest instance (256M ram) which is only about $12 month for my dev box. My buddy had a mac he did local dev on for the same codebase and he experienced subtle bugs in the code due to the mac environment, that I do not experience on my cloud dev box (or production).
So what I am getting at is with this type of shift (to the cloud for linux dev with no GUI) portability and quick recovery from hardware failure, and productivity (keyboard shortcuts rule over point/click/drag select) are some other major advantages. Obvs you can learn keyboard shortcuts in Windows too, but when forced to work in only a terminal window, you learn a lot more of them out of necessity. I run Windows 7 on a laptop (essentially as a dumb terminal to my cloud devbox), but I SSH into my devbox with putty and work on code with VIM and manage it with git. If my laptop ever fails or gets stolen, all I really need is ANY computer that has an SSH client (and internet connection) and I can be productive on a temporary loaned computer within 30 minutes until my preferred hardware is fixed/replaced. (all my passwords on the laptop are in a keepass encrypted db which is backed up on dropbox.com as well as external HD, occasional gmail to self). And of course configure putty with nice fonts/font size and full-screen window size.
In contrast getting a windows box from clean install to dev environment tweaked exactly how you want might take a couple full-time days plus a couple hours here and there for a month, and still not replicate the production environment to your needs.
Ok, end biased rant - I guess my point is I didn't know what I was missing as a windows guy, and simple non GUI linux tools for web development have proven to be superior to me for how we work. But also note my laptop is Windows 7, so when work is done or a need to do some IE testing, I'm on a "normal" OS. However, I doubt a lot of people would be willing to make such a change if there is no perceptible gain or immediate need.
I just switched to using Ubuntu from Windows XP, here's what I found:
Pro's of Linux
Linux is less likely to be affected by viruses. I lost some time to viruses when I used XP.
As you said, same environment as Dev/QA/Prod which is nice. It's no longer a change of mindset when I connect to one of those machines
Linux is more stable. I usually rebooted XP every week or two.
You get to use the unix tools (find, pkill, grep, etc.). Cygwin is a workaround but seems quite a bit slower than running unix natively.
Performance seems quite a bit better on Linux. This is probably the biggest win for me, I have a memory-intensive Dev environment.
Cons of Linux
Open Office is a bit of a shock to the system compared to Word/Excel (which I have been using for many years).
I miss Notepad++
I need to run VirtualBox to host my local Sql Server Dev database
I need to run VirtualBox when running internet explorer
More of a pain to copy/paste text between Sql Server Management studio and IE if needed because they run in VirtualBox
Remote Desktop is more of a pain. Microsoft's remote desktop allowed me to not have to log out from work before working at home and vice versa
I have one app that only runs with the Wine emulator and won't work at all for me when remote desktop-ing on linux
I agree with the poster who said it's good to give developers a choice - they will appreciate that instead of having one or the other OS rammed down their throats. An added benefit is that you'll then be able to differentiate the good devs from the bad :) Just kidding.
On my first employment, we had been working on HP UX systems. So I really learned love the power of the console and it's elegance:
Use find to work on loads of files
less for really big log or data files without delay
for loops with substring handling to rename thousands of files in seconds.
and many other nice shell hacks to save you time and nerves...
But not many people seemed to agree in my later employments...
However. I only once had the posibility to use a Fedora Linux box for development several years ago. It was a 64 bit system in the first years of their existance. Maybe this was the problem. I was looking forward to use a proper shell again, but was disapointed as Eclipse did not run stable and had a lot of bugs. This was a pitty and a no go. Since then I never again had the chance to use linux as development OS.
As I start to work in a new employment in some days I really think about to give it an other try. Would do you think, is it still unstable? I nearly can't imagine.
You won't have to use Visual Studio.
Since that doesn't seem to be an issue for you, you might provide more details---what languages are you developing in? If it's Java, then you'll be spending most of your time in Eclipse, Netbeans, etc., so it really won't make much difference. What is your budget for the changeover, or what savings do you hope to get?
From your reasons it seems that you're pretty commited to UNIX already.
Why not give the developers a choice?
git runs faster.
...
Okay, not that much of an advantage...
Linux boxes are easier to containerize with solutions like Docker so that you can more easily share your environment with other devs or QA.
Also, if you need multiple boxes talking to each other for your dev setup, then Linux is a more practical solution. I was working on a Windows machine with a .Net solution which had to talk to services on a different box. I chose to install a couple of VM's using the steps described here (http://mytakeon.it/the-complete-steps-to-having-a-virtual-box-up-and-running-on-your-computer/). The Linux VMs were so light weight, easy to manage and faster in booting up.

Resources