Hacker News Reader

We run a Mac and Linux setup here - me being the admin, this is tolerable. Mac's still-essentially-Unix underlying OS makes this reasonably consistent - I can SSH between either platform fairly easily, for example. We offer new starters the option, and are about 50/50, though I've had a few surprises - one user had only previously used Windows, and from experience these sort of users switch to Mac more easily than Ubuntu, but he gave his MBP back after a day and switched to Ubuntu instead, which he's stuck with. I could not be more proud :D

It's very nice to give end users the option - when I joined, I asked for Linux and was given a brand-new Dell XPS with Ubuntu pre-installed, root access, and told, customise it to suit you. I keep that spirit with my users.

Throwing Windows into such a setup is a nightmare though - two users actually installed their company laptops with their own personal Windows 10 licenses without my knowledge or approval - I still hold a grudge because I had to actually read the MS EULA to make sure they weren't about to cause trouble! It means I can't manage them (I have no real tools to do so on Ubuntu), so they're on their own for that. Fortunately management has my back, declaring the company to be a *nix shop.

Our actual product is all containerised so it should run anywhere.

> I have no real tools to do so on Ubuntu

Ansible works pretty well for managing Windows machines but it requires a little bit more up-front setup on the Windows side and as always YMMV depending on what you're trying to do.

I would have been pretty upset with that. Unless you're writing machine-native code, development environments should work on anything, especially if they run on VMs deployed by Vagrant.

I’ve had problems even getting anaconda (scientific python distro) to work in a VM on windows (because the file system of the host OS lacks certain UNIXy features).

In theory there is no difference between theory and practice. If no one is testing the build on platform X, no one should be surprised if it doesn't "just work" on platform X.

Well the thing with Vagrant is that it (in theory) runs your application code inside the VM, but you typically run all your development tooling in the host OS.

I suspect that it was on the local tooling side that things fell apart for this Windows developer, if he was grabbing a project mostly built on Mac or Linux.

A lot of popular dev tooling built around web technologies (node, Ruby, PHP, etc) isn't as mature on Windows as it is on MacOS or Linux.

My source on this is me. I have a Mac and a Windows box at home, and I've had projects fail to set up and build on the Windows machine for these reasons.

You would think that right? Except then you actually want to run a simple python script on Windows and observe things like: os.rename not being able to replace opened files, the default encoding not being UTF-8 (wtf), not being able to just `pip install scipy` because of some weird BLAS/MKL dependency...

I guess from a business point of view it makes sense, but I really get frustrated when I find an open source project that's completely unbuildable on Windows.

Maybe the developer in question would have been better using a manually created VM or WSL?

A windows developer just needs to create a build

Now, take this with a grain of salt, as I'm no open source maintainer, and I only rarely use Windows, and even then for development. Up until very recently, to get real developer tools that are supported by Microsoft one had to buy visual studio. VS2017 has a community edition that's usable for open source projects.

Not to mention, the windows environment is completely different to linux and OSX. Until x64, they had a different calling convention. On OSX and linux, also until recently, I could use the same compiler for both platforms and still be supported by the platform vendor.

All of these non-trivial differences make it a lot more resource-intensive to support a codebase on windows that already runs on Linux and OSX. Asides from my work VMs, I don't even have a windows device that I could use for development. So to me, it's no surprise that most open source projects don't build on Windows.

Community Edition is really nice nowadays, usable for day-to-day professional usage as well. If ReSharper works - it works for me.

Student and hobby editions of Visual Studio exist for decades, before they introduced Community, there was the Express editions.

Also, mingw and cygwin also exist since late 90's.

OS X tools are kind of included on Apple's hardware price.

Apple hardware costs in many countries is similar to average PC + VS License costs.

Whilst I agree with you on all but mingw and cygwin, these tools are wildly different. Integrating microsoft's C/C++ toolchain into an existing makefile would be hell. And again, most people who have a mac don't have to buy the compiler. Most people don't buy extra software after the fact just to compile open source libraries. I can't imagine a reason to buy visual studio for personal use, and I can't imagine a reason as to why I'd dick around with visual studio in my free time.

As for mingq and cygwin, most regular people don't have it installed and configured. And cygwin and mingw are not _platforms_ which receive first party support, as unfortunate as that might be.

I once had to use cygwin to port an old C library from UNIX (I don't recall the flavor of UNIX) to windows. It involved editing makefiles to use the MSVC toolchain, amongst many other things.

It was pure pain. Especially when the boss kept asking me what was taking so long (it's just a recompile right?).

People that have a Mac already payed for the compiler.

500 € PC + Visual Studio vs 1000 € Mac.

I don't believe that the majority of people who buy 500€ PCs would spend money on Visual Studio. In the Mac case, nobody pays for the compiler because Clang is open source - this is a massive oversimplification, but whilst the fact that Clang and Make are distributed in the standard OSX base install is a value add in my book, I don't believe that it's something that people pay for. Also, the people who buy Apple hardware are a completely different set of customers to those who buy 500€ PCs. However, this is all a bit moot as you and many others have pointed out that the community edition is out there and it is usable.

Windows is a bad product made by a company that has historically been a bad and unethical actor that has attempted to limit user freedom and destroy freedom of choice by illegally destroying competitors. Recently we are to believe that they have found jesus and ethics via quiet contemplation and peaceful regime change.

All projects are ultimately created to scratch somebodies itch. If it doesn't work on windows out of the box that isn't their use case. What you are wondering is in effect is why people don't pay money to purchase a windows license which will ultimately fund a bad and evil company in order to enable the projects software to run on an inferior OS that the dev doesn't run or care about. If its not end user software for desktop users it doesn't even have the positive effect of enabling a substantially bigger group of potential users to benefit from the software. For anything server related they are either already running linux or can as easily run a linux vm as a windows one.

Further the users who would benefit will by and large buy a license if the software is non free but probably wont contribute anything but complaints phrased similarly to the support requests they would make for paid products that had failed to perform adequately.

What was the problem just install an xwindows server (the new bash environment should support it) or just turn on the telnet clinet.

The new bash env is a bit of a let down for development currently, at least for me. I love this move by MS though and am willing to give it another go in the future once it’s more complete.