5 ms·

Obvious developer is being Obvious. If you are developing for Linux deployment, it doesn't make sense to develop on Windows. This is a no brainer. Likewise if

Obvious developer is being Obvious. If you are developing for Linux deployment, it doesn't make sense to develop on Windows. This is a no brainer. Likewise if I was to develop for IIS/SQL Server I wouldn't do so using my Linux environment.

dagw 14y ago
I develop for Linux deployment on Windows. Why? Because I also develop other things and use other tools that are Windows based, and its easier to have just one setup rather than changing machines or dual booting all the time. Windows with a Linux server in a VM is a perfectly fine solution, and unless your Linux dev machine runs exactly the same distro and config as your production server, you're going to need a separate VM or dev server to test on anyway.
- walshemj 14y ago
  Your Dev system should be the same as your live server (same distribution and ideally the same hardware) other wise your just a hobby programmer. Back in the day at BT we even brought all our systems (Dev, Test and Live at the same time so we had identical systems from the same production run from sun.
  - dagw 14y ago
    Well I guess that makes me a hobby programmer. Half the time I don't know what server the code will be deployed on when I start coding. 9 times out of 10 the hardware is completely out of my control (often it's whatever cloud server provider X decides to spin up that week, which can often be something completely different from what they decided to spin up last week). Obviously making sure your test environment is as close to possible as your production environment is important, but I don't get too bothered about making sure the machine my text editor runs on is identical to the machine I will end up deploying to. But then again, I'm just a hobby programmer.
    - jimwhitson 14y ago
      By the GP's definition there are a lot of us hobby programmers. I used to write code to run on all kinds of weird servers, SPARCs, IBM POWER kit, ARM dev boards and so on - I hate to think how a non-hobby programmer would have approached that job...
    - walshemj 14y ago
      What you use as a dev client is not the point its the dev and test hardware the application running on that needs to be as close (ideally identical) to live as possible. And the random approach to hardware that clouds use well maybe thats why they have such poor up time when compered to the carrier grade gear a telco uses.
  - jrabone 14y ago
    Rubbish. Spotting the hobby programmer is easy - they're the ones hardcoding "/" or "\\" instead of File.SEPERATOR. At Amazon most of the teams I worked with developed our entire Java service stack on Windows, and shipped on Linux - because the Windows tooling was just better. To this day Eclipse on Linux needs endless tweaking to fit the same content to the same screen resolution, and the double monitor support back then was hilariously poor.
- rogerbinns 14y ago
  An example of wasted productivity on Windows is that we have several utility scripts. One of them needs to run a jar which is trivial on Linux and Mac (java is in the path). That script had to be runnable by outsiders so I had to make it run on Windows too and had to do all sorts of grovelling through the registry (it is possible to have Java installed but not registered for jar files, and we need to supply parameters to the java command). Some status information is saved in an ini file. On Linux and Mac I make it hidden by having a dot prefix in the filename. To make it hidden on Windows I had to use a Win32 call (SetFileAttributes) and wrap the access in a call to unhide it and then rehide it afterwards. When the tool finds problems it can open the browser on a local copy of the documentation shipped with the tool. However opening web pages with anchors has the anchor ignored on Windows making things that much more hostile. Those were just the waste of time on one utility, not to mention all the testing to find them. Multiply by everything else and it just isn't worth it. Some of our stuff does intensive file I/O. This is a lot slower in a VM. It all adds up to a death by a 1,000 cuts.
  - asveikau 14y ago
    If you wrote an application that does nothing but call SetFileAttributes I suspect you've not heard of the attrib command. Most of this is just "it's different, wah." Maybe it's not so bad to people who are used to it the other way. Maybe to some the dotfiles are the weird thing.
    - rogerbinns 14y ago
      > If you wrote an application that does nothing but call SetFileAttributes I suspect you've not heard of the attrib command I didn't explain clearly enough. The python script uses an ini style file to remember one value between runs. On Mac/Linux I can hide that file purely by putting a dot in front of the name. On Windows I hide it by changing attributes to hidden, but have to unhide for the portion of the script that access the file. The attrib command isn't relevant in this case. (And yes I've heard of it.) Just to make things clearer, these are the non-mobile operating systems I've used beyond the superficial as well as doing software development on the vast majority: Prodos, MSDOS (3 through 6), Windows 2, Windows 3 (including real mode), Windows for Workgroups, Windows NT, Terminal Server, 2000, XP, Vista and 7, Pyramid Unix, SunOS, SVR4 (several derivatives and flavours), Linux, and MacOS. I've used several more but deeply enough to make the list (hello GEM, OS/2, AS/400, BeOS, a zillion Unix flavours ...).
snarfy 14y ago
I dunno, it works for me. I can build my web service app in VisualStudio on Windows and run+debug it, then once it's working, copy the folder over to linux. Linux is setup with mono fastcgi + nginx + servicestack.net. I don't even have to do anything on linux after the copy is done - just refresh the web page.

dagw 14y ago

I develop for Linux deployment on Windows. Why? Because I also develop other things and use other tools that are Windows based, and its easier to have just one setup rather than changing machines or dual booting all the time. Windows with a Linux server in a VM is a perfectly fine solution, and unless your Linux dev machine runs exactly the same distro and config as your production server, you're going to need a separate VM or dev server to test on anyway.

walshemj 14y ago
Your Dev system should be the same as your live server (same distribution and ideally the same hardware) other wise your just a hobby programmer. Back in the day at BT we even brought all our systems (Dev, Test and Live at the same time so we had identical systems from the same production run from sun.
- dagw 14y ago
  Well I guess that makes me a hobby programmer. Half the time I don't know what server the code will be deployed on when I start coding. 9 times out of 10 the hardware is completely out of my control (often it's whatever cloud server provider X decides to spin up that week, which can often be something completely different from what they decided to spin up last week). Obviously making sure your test environment is as close to possible as your production environment is important, but I don't get too bothered about making sure the machine my text editor runs on is identical to the machine I will end up deploying to. But then again, I'm just a hobby programmer.
  - jimwhitson 14y ago
    By the GP's definition there are a lot of us hobby programmers. I used to write code to run on all kinds of weird servers, SPARCs, IBM POWER kit, ARM dev boards and so on - I hate to think how a non-hobby programmer would have approached that job...
  - walshemj 14y ago
    What you use as a dev client is not the point its the dev and test hardware the application running on that needs to be as close (ideally identical) to live as possible. And the random approach to hardware that clouds use well maybe thats why they have such poor up time when compered to the carrier grade gear a telco uses.
- jrabone 14y ago
  Rubbish. Spotting the hobby programmer is easy - they're the ones hardcoding "/" or "\\" instead of File.SEPERATOR. At Amazon most of the teams I worked with developed our entire Java service stack on Windows, and shipped on Linux - because the Windows tooling was just better. To this day Eclipse on Linux needs endless tweaking to fit the same content to the same screen resolution, and the double monitor support back then was hilariously poor.
rogerbinns 14y ago
An example of wasted productivity on Windows is that we have several utility scripts. One of them needs to run a jar which is trivial on Linux and Mac (java is in the path). That script had to be runnable by outsiders so I had to make it run on Windows too and had to do all sorts of grovelling through the registry (it is possible to have Java installed but not registered for jar files, and we need to supply parameters to the java command). Some status information is saved in an ini file. On Linux and Mac I make it hidden by having a dot prefix in the filename. To make it hidden on Windows I had to use a Win32 call (SetFileAttributes) and wrap the access in a call to unhide it and then rehide it afterwards. When the tool finds problems it can open the browser on a local copy of the documentation shipped with the tool. However opening web pages with anchors has the anchor ignored on Windows making things that much more hostile. Those were just the waste of time on one utility, not to mention all the testing to find them. Multiply by everything else and it just isn't worth it. Some of our stuff does intensive file I/O. This is a lot slower in a VM. It all adds up to a death by a 1,000 cuts.
- asveikau 14y ago
  If you wrote an application that does nothing but call SetFileAttributes I suspect you've not heard of the attrib command. Most of this is just "it's different, wah." Maybe it's not so bad to people who are used to it the other way. Maybe to some the dotfiles are the weird thing.
  - rogerbinns 14y ago
    > If you wrote an application that does nothing but call SetFileAttributes I suspect you've not heard of the attrib command I didn't explain clearly enough. The python script uses an ini style file to remember one value between runs. On Mac/Linux I can hide that file purely by putting a dot in front of the name. On Windows I hide it by changing attributes to hidden, but have to unhide for the portion of the script that access the file. The attrib command isn't relevant in this case. (And yes I've heard of it.) Just to make things clearer, these are the non-mobile operating systems I've used beyond the superficial as well as doing software development on the vast majority: Prodos, MSDOS (3 through 6), Windows 2, Windows 3 (including real mode), Windows for Workgroups, Windows NT, Terminal Server, 2000, XP, Vista and 7, Pyramid Unix, SunOS, SVR4 (several derivatives and flavours), Linux, and MacOS. I've used several more but deeply enough to make the list (hello GEM, OS/2, AS/400, BeOS, a zillion Unix flavours ...).

snarfy 14y ago

I dunno, it works for me. I can build my web service app in VisualStudio on Windows and run+debug it, then once it's working, copy the folder over to linux. Linux is setup with mono fastcgi + nginx + servicestack.net. I don't even have to do anything on linux after the copy is done - just refresh the web page.