Friday, April 8, 2016

Windows Has a Long Way to Go for Developers

OS X attracted a lot of developers in the 2000's and many are still on it. Linux in its various flavors also has a significant combined community of developers and continues to be a strong force, especially considering that Linux is used more on the server. Of course, those developing in Microsoft technologies and some of those in Java, etc. use Windows as well.

But, I've been in a primarily OS X desktop environment and primarily Linux server environment for close to the last 10 years now. With that experience, here are some places where I believe Windows is still deficient, and will remain deficient as a development environment that works for the majority of development languages (not just Windows-based) for at least a few years, possibly much longer.

OS X embraces Linux/*nix as far as command-line tools go via Homebrew and has maintained a reasonably active community with that. Windows has Chocolatey but that's not a replacement for all of the tools, and at time of writing Scoop is also really lightweight compared to the long list of formulas in Homebrew.

Sure, OS X includes bash at command-line, and yes, Windows 10 will provide it and support for other commands provided in Ubuntu to work by using an adapter as part of Windows.

However, that doesn't go far enough.

In order to be an easy-to-use Desktop environment, a powerful development workstation, and similar enough in the underpinnings to be fairly compatible with the most stable and ubiquitous server operating systems which use the Linux kernel, Windows would need to be a Desktop manager atop Linux. That won't happen anytime soon, and is not in Microsoft's plans.

Why does it matter? I've personally seen the pain of a developers trying to migrate to Windows from an environment that was targetted at Linux, in languages that for the most part assume to be run on Linux servers, and with developers that use OS X or Linux... and it is painful. Incompatibilities galore when you swim against the stream. And, no developer should be put into this situation. If the money is there, the right tools should be used for the job. This may mean that your best environment should be composed of teams running Windows, OS X, Linux, and more. While there is something to be said for developers using the same tools so that they can work with each other more easily, you shouldn't ever continually force developers to use the wrong tools for the job or switch to them unless you want them to fail.

I really want Windows to provide some serious competition to OS X and Linux in the realm of all types of development, not just .Net and the like. If it could be better than OS X for all developers, I'd use it. But, even if I start buying Windows PCs at home here and there now that Windows 8 has mostly run its course, I can tell you that I don't see a future in the next few years where I would enjoy writing code in Windows, unless I'm writing code in .Net or other languages where Windows might be a better choice.

That said, Windows still has the majority share in Desktop operating systems, at time of writing. 46.66% Windows 7, 13.65% Windows 10, 11.67% Windows 8.1 vs. 9.03% OS X according to StatCounter for January 2016.

But, in comparison, public servers on the Internet are 35.9% Linux and 32.3% Windows. For the most part, I develop software that is either run on or is served by similar servers, therefore it continues to be in my best interest as a developer to develop in an OS that not only has a terminal with a bash/zsh shell, but works more closely to Linux where I can use tools in the terminal that work similar to those that work on the servers that the code I write will be run on.

I know this is not the case for everyone, and if you write Visual C++, .Net, etc., you're better off in Windows. But, as for me, I'm for OS X, Linux, or another *nix as long as I can be, or at least for as long as it makes sense and is practical to be.

Wednesday, March 30, 2016

Windows Embracing Linux -> Windows Absorbing Linux

In Microsoft's latest move, Microsoft has partnered with Canonical to incorporate native Ubuntu Linux binaries directly into Windows 10 so that the bash shell can run. It will be available in the win 10 anniversary update.

See Developers can run Bash Shell and user-mode Ubuntu Linux binaries on Windows 10 in Scott Hanselman's blog for details.

I'd write more, but I'm still in shock. Babun still looks to be an option also, though, for those that want bash/zsh in cygwin under Windows.

Unrecoverable Instructions and Other Oddities

Some unrecoverable instructions and other oddities:

Thursday, March 17, 2016

Git <= 2.7.3: Buffer Overflow Exploit Possible

According to Mattias Geniar, remote code execution via buffer overflow is possible in all git versions (client + server) < 2.7.1 (See: CVE-2016-2324, CVE-2016‑2315 or original post to the seclist by LaĆ«l Cellier). But in this post, it corrects that to say that the Git patch has not been incorporated as of 2.7.3- that change is only in master and it provides links to master and the patches.

In OS X, I just did this to get the latest- you might want to also:

brew update && brew upgrade git
However, as of 2016-03-17 that only updates to 2.7.3 which does not fix the problem, so you'll have to build master or download/patch yourself until homebrew is updated. Try it just in case, though, if you are reading this later.

Update!: As of 2016-03-18, Git 2.7.4 contains a fix. It can be downloaded from and elsewhere. The OS X Homebrew version/recipe was updated, so might want to do this:

brew update && brew upgrade git

Tuesday, March 1, 2016

Vulnerable to DROWN?

I'm told you can protect yourself against DROWN and POODLE by ensuring SSLv2 and v3, respectively, are disabled, but do your own research and do at your own risk.

To check whether you're vulnerable, you could take a look at:

But... it might be lying. Kind of.

If you use: to test, it only looks at the cert. SSLv2 and SSLv3 can be disabled at the server level, though.

So, also try: which might actually test it.

You could also try testing yourself with nmap, if allowed:

However, it's not as simple as that, so's assessment might be the safest.

I'm told that a server is vulnerable to DROWN if EITHER it allows SSLv2 connections OR its private key is used on any other server that allows SSLv2 connections, even for another protocol. If server A and server B share the same private key, and server A supports SSLv2 and server B does not, then an attacker can take advantage of server A to break TLS connections to server B.

So, to be safe, if says you are vulnerable, assume you might be.