That makes a lot of sense, as Windows boxes are not really good for web development, but I really hope they still test everything on Windows, extensively. Even though their software is web-based, there's still difference in behavior on different platforms.
Agreed. I also combine that with a Linux server VM. This way you can mess around with server configuration without nuking your development environment. Plus you're developing on a server that is very similar to the production server.
Honestly, it depends what you're developing in. If you're developing in .NET, Windows isn't a bad platform. Anything else, and Windows starts to feel like a second-class citizen. For instance, a lot of tools written in Ruby tend to assume a Unix-like environment, even though the language itself is cross-platform.
The other problem with Windows is that it doesn't make a very good server, and it's often useful to develop on the same OS you'll be eventually deploying to.
Windows is surely a better server than OS X. Also, the tool set for web development on Windows is very mature and stable.
Google is making a business decision here: it is too expensive for them to support Windows at the level of security they desire, which is likely a higher standard than most software development shops, and perhaps many banks.
I've been unable to find anything equivalent to Puppet or Chef on Windows. Might I enquire what tools you use for managing Windows servers?
That said, I doubt I'd ever actually use an OSX server. There's little difference in functionality between an OSX server and a Linux server, and Linux servers have no licensing costs to worry about. Currently we're developing on OSX and Linux desktops, and deploying to Linux servers.
"Also, the tool set for web development on Windows is very mature and stable."
For .NET, maybe. Not for something like Ruby, I'm afraid. Also, we haven't found any good way of deploying to Windows. I'd be curious how you manage deploying applications to a Windows server.
This is ignoring PHP (one of the biggest web dev languages) and Python which do just as well on both.
Also I have never seen the need to develop on the same platform as your server (if your using a local server, well, then that makes sense - but it's not the best workflow and, in addition, that is not a limitation of the development but of the server requirements :))
If you're the sole developer, it makes a lot of sense to run a local server for development purposes. It's cheaper, more convenient and really helpful if you're stuck somewhere with a poor Internet connection.
I develop Django on Windows, and I deploy on Windows as well. You can use PowerShell to script all of your deployment and server management operations, and you can remotely invoke all of those scripts as well.
I tried RoR on Windows, and it is a second class citizen IMO, so I switched to Python/Django, and I've been happy since. Python/Django are pretty blissfully OS agnostic.
"You can use PowerShell to script all of your deployment and server management operations, and you can remotely invoke all of those scripts as well."
I've looked into powershell, but remote powershell isn't much better than shell scripts executed over SSH (and in some ways worse). Tools like Capistrano, Puppet, Chef, etc. don't seem to exist for Windows as yet.
OS X is pretty Unixy and has the ability to run virtually all the Unixy server stuff that runs on other Unixy platforms which are generally considered top tier server platforms. It's entirely possible that Windows is a better server, but you can't expect people to accept a statement like that on its face. Please provide some evidence.
Windows is surely a better server than OS X? OS X comes with an Apache server already set up and ready to go at the flick of a switch. I find it quite satisfactory for testing sites before I go to online testing. I can also fire up a Windows VM and navigate to my local ip, for quick cross browser testing.
Me too. I greatly prefer the tools that are available to me in Windows, but apparently I'm a freak for wanting a decent GUI IDE; most of my colleagues just use vim.
Yeah, other than Rails, I pretty much agree. I actually prefer Vim on windows to Vim on *nix, (I guess I'm mostly speaking of gVim),Visual Studio is terrific if you don't mind working in .NET, Eclipse and Netbeans are equally mature on Windows, and if you spend a lot of time in the command line, Powershell is really a better Bash in a lot of ways (still needs persistent command history though).
Banning the platform most of your users are using doesn't sound like a great idea to me. There's enormous value in eating one's own dogfood (and stuff running in Chrome is an entirely different kind of dogfood than stuff running in IE, on Windows).
Increasingly their users are going to be using Macs and Android, and I really do expect Linux distros to start to see an upswing as data becomes accessible on more and more devices.
To a certain degree this is sensible. It will probably make them safer in the short-term.
Ultimately though this is just a TSA level maneuver. It's reactionary, short-sighted, and imperfect to a degree that is likely to make it nearly useless.
Security is a meta-property, for organizations as well as for software. You can't create security in software as a line-item feature. Nor can you create security in a company by using, or not using, a particular tool. Security ultimately is an overarching endeavor. If google is serious about security they need to approach it that way. The particularly dangerous failure mode for google's recent actions is that they think they've made a serious security enhancement (at best it's incremental), they become complacent, and then they get owned harder than before.
Hopefully this is just a teeny, tiny aspect of a larger security initiative, but from the outside it's difficult to tell if that's the case.
25 comments
[ 2.2 ms ] story [ 38.6 ms ] threadUnfair! I use Linux and Windows for web dev and they are both equally as good as the other.
EDIT; oh come on, at least justify it... :)
The other problem with Windows is that it doesn't make a very good server, and it's often useful to develop on the same OS you'll be eventually deploying to.
Google is making a business decision here: it is too expensive for them to support Windows at the level of security they desire, which is likely a higher standard than most software development shops, and perhaps many banks.
I've been unable to find anything equivalent to Puppet or Chef on Windows. Might I enquire what tools you use for managing Windows servers?
That said, I doubt I'd ever actually use an OSX server. There's little difference in functionality between an OSX server and a Linux server, and Linux servers have no licensing costs to worry about. Currently we're developing on OSX and Linux desktops, and deploying to Linux servers.
"Also, the tool set for web development on Windows is very mature and stable."
For .NET, maybe. Not for something like Ruby, I'm afraid. Also, we haven't found any good way of deploying to Windows. I'd be curious how you manage deploying applications to a Windows server.
This is ignoring PHP (one of the biggest web dev languages) and Python which do just as well on both.
Also I have never seen the need to develop on the same platform as your server (if your using a local server, well, then that makes sense - but it's not the best workflow and, in addition, that is not a limitation of the development but of the server requirements :))
I won't disagree Ruby is better on Linux though.
I tried RoR on Windows, and it is a second class citizen IMO, so I switched to Python/Django, and I've been happy since. Python/Django are pretty blissfully OS agnostic.
I've looked into powershell, but remote powershell isn't much better than shell scripts executed over SSH (and in some ways worse). Tools like Capistrano, Puppet, Chef, etc. don't seem to exist for Windows as yet.
OS X is pretty Unixy and has the ability to run virtually all the Unixy server stuff that runs on other Unixy platforms which are generally considered top tier server platforms. It's entirely possible that Windows is a better server, but you can't expect people to accept a statement like that on its face. Please provide some evidence.
So, "ban" - not so much. More like "strongly discouraged unless there's a reason".
Ultimately though this is just a TSA level maneuver. It's reactionary, short-sighted, and imperfect to a degree that is likely to make it nearly useless.
Security is a meta-property, for organizations as well as for software. You can't create security in software as a line-item feature. Nor can you create security in a company by using, or not using, a particular tool. Security ultimately is an overarching endeavor. If google is serious about security they need to approach it that way. The particularly dangerous failure mode for google's recent actions is that they think they've made a serious security enhancement (at best it's incremental), they become complacent, and then they get owned harder than before.
Hopefully this is just a teeny, tiny aspect of a larger security initiative, but from the outside it's difficult to tell if that's the case.