EDIT: By UNIX pro, I personally mean people who are familiar with the typical nix stack, e.g. GNU/Linux, BSD, Darwin. This would encompass sysadmins, programmers, etc.
We do all our development on Linux with one or two developers using Mac. I expressly forbid doing any development on Windows even though everything could run on Windows. This is purely because it takes longer, has more hassles, the tools aren't better (eg valgrind), awful package/dependency management, and it doesn't match deployment environments.
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.
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.
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.
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.
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.
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.
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.
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 ...).
Exe4J / Install4J; works everywhere.
Some status information is saved in an ini file...
Don't. Use the registry on Windows, dotfiles on Linux (and plists on Mac? Or is that gone with OsX) ?
...open the browser on a local copy of the documentation...
Don't, use CHM on Windows (although I think this changed AGAIN recently).
Some of our stuff does intensive file I/O. This is a lot slower in a VM
VMWare Workstation?
Software development is death by 1000 cuts. That's the nature of the game. If you get into x-platform dev without thinking too hard about it you'll suffer, but none of the platforms is "right" - just better or worse for something.
> Exe4J / Install4J; works everywhere
So to run a jar that produces command line output and is consumed by the script and is one line to run on Linux/Mac (java -blah -blah -jar foo.jar blah blah) requires me to purchase a 3rd party wrapper/installer app. That there is a hoop to jump. Finding the java binary via the registry worked just fine, didn't require installation or wrapping or anything else.
> Don't. Use the registry on Windows, dotfiles on Linux (and plists on Mac? Or is that gone with OsX) ?
I used the Python configfile module which does ini style files. At the moment I save exactly one value. It is trivial and works really well. Doing more than that is more hoop jumping.
> Don't, use CHM on Windows (although I think this changed AGAIN recently).
So I need to convert perfectly good documentation that works in any browser on any platform into another format just because Windows strips the anchor when opening a URL? More hoops.
Incidentally I do actually generate CHM files for one of my open source projects. I had to give up because the help compiler refuses to install now (I believe the setup program is doing 32 bit arithmetic on free disk space and wrapping around to negative numbers).
> VMWare Workstation
I've yet to use any virtualization solution where guest disk access is at the same performance level as on the host. (I prefer virtualbox.)
> If you get into x-platform dev without thinking too hard about it
I never said I wasn't a x-platform dev. All my open source projects for well over a decade work on all 3 platforms. But that is because I'm diligent and don't want there to be any impediments to others being able to use the software. Windows is usually what causes the highest amount of work for least results, although there are exceptions (eg printing support has always been easiest to add support for on Windows).
But when we do our internal stuff there is no value to being cross platform to Windows. It wouldn't be a big deal if it didn't require so much additional effort. Consider something as trivial as deleting a file. If you just had it open (can't delete open files on Windows, more hoops) then closing it and deleting will often fail. You have to add delay/retry loops because tagalongs like virus scanners and backup agents opened the file after you closed it.
So as a result the only thing we have that runs on all platforms is one script because it is run by outsiders, and that required extra effort for Windows. It could require even more if I did everything "properly" although the people running the script wouldn't know any different which is why I didn't expend even more effort.
Install4J is free-as-in-beer BTW, but you do tend to get what you pay for on Windows, especially with virtualisation software.
Deleting open files is another different-not-better situation - I've seen Linux server apps resurrect entire paths due to open inodes that looked like they were deleted but weren't. That was fun to debug on a production system doing $millions a month.
Have you tried Qt or similar? Perhaps a script isn't the right answer if it needs to Just Work everywhere.
No installation is done - you just run the script. It has an accompanying data file which is actually a zip file and one member is the jar. It is extracted to a temporary directory and run and then deleted afterwards. (Performance is not a problem since this isn't run that often.)
The open deletion isn't relevant to this but is something I've dealt with elsewhere. Note that you can still have problems doing deletions even after you have closed the file due to tagalongs.
In this particular scenario a command line tool that has an exit code and can be automated via make, ides etc is the right solution.
I've done cross platform GUIs before as well as cross platform servers. For one company the latter was done using Qt but there was no gui so it was QThread, QString etc.
For cross platform GUIs there are roughly two approaches. One is where there is some sort of wrapper that uses the native platform widgets and tries to provide the same API on each platform. This often suffers from the lowest common denominator effect across the platforms. The other end is a toolkit that draws everything itself effectively mimicking the platform and provided the same underlying code on all the platforms.
I really don't like the latter approach. There will always be discontinuities between the real platform and the mimc. The mimic will always lag the platform and its developers will have to spend a lot of effort just to stand still.
For the first approach I like to use wxPython/wxWidgets. One neat thing they do is provide their own widgets (composed out of as many platform widgets as possible) when the platform doesn't have the relevant one so you do get a good set to develop on.
That said I do user interfaces in HTML these days where possible so there aren't as many cross platform issues (and I never support IE6 although it often works well enough).
The job of a manager is not to bend the environment to his needs but to aid the people that do the work.
Our situation is the other way around where deployment is to Linux (AWS/AppEngine) and there are several internal tools that work seamlessly on Linux and Mac. Having to add conditionals all over the place for Windows (not to mention the additional testing) is not free. The new developers can adapt to Linux or they aren't very good developers. (Note we make it abundantly clear that we use Linux and Mac for development in our job ads.)
When you hear about companies needing Windows Pros, do you think they really mean Windows kernel developers? Why would a Linux Pro mean kernel developer, while UNIX pro would be more generic?
They want someone who knows the Linux ecosystem. There are Linuxisms that have nothing to do with UNIX. That's what they're talking about.
Because Linux is technically the name of just the kernel, not the entire system encompassing userspace as well. There's definitely room for misinterpretation there.
Nice thing about context, it tells you how something is being used.
Stallman isn't putting up want ads.
I mean, I just guessed based on how "Linux" is typically used, i.e. GNU's userland. I don't exactly have time to call up "93% of hiring managers" and ask them personally.
I occasionally have recruiters contact me believing this means I'm a perl/awk/bash wizard.