I got flamed a month ago [1] for noting how difficult it is to get up and running on GitHub in the Windows world, where things like generating SSH keys aren't exactly part of the daily routine. Glad to hear that they were listening.
As a Windows user I initially found the setup a little daunting, but the GitHub install guide was a great help and guided me through everything fairly painlessly. If I'm honest about it though, without that help guide, I would have been pretty lost.
The ssh setup is a barrier to entry for a great deal of Windows users, simply because they don't have to deal with such things on a daily basis. Whether they all should know these things is debatable.
I personally couldn't give shit how 'it' works, as long as I don't have to waste my precious time having to learn something I don't need to. I don't want to have to learn machine code for the same reason. We abstract to become more productive. We build on the shoulders of giants. We don't re-invent the wheel. I could go on...
The bottom line is that the previous installation for Windows was manageable, but still it was a drag. Luckily there were enough good resources on the web to help you through it. However, it was time consuming and that barrier has now been removed.
In my opinion that's great. It follows Dieter Rams' principles of good design, namely:
Good design is as little design as possible.
Less, but better – because it concentrates on the essential aspects,
and the products are not burdened with non-essentials.
Let's remember that Git is a distributed source control mechanism. It needs to move versioned code around. That is its pure purpose. When the security setup takes more effort than the source control you're doing it wrong.
That being said, the common language of the Git world will remain the command line. The vast majority of examples you will find on the web when you are learning how to use Git will be executed via the command line. That fact in itself means that you should still learn the basic commands and get familiar with git bash.
EDIT: I hope this gives a fairly balanced opinion from a typical Windows Git user. I appreciate that this topic is a heated one.
I think it would really help you to have a play with command line Git, just to get a feel for what's going on. SSH keys aren't hard to learn and are useful enough to be worth the time spent.
It's not about being unfamiliar with the CLI, it's that Windows isn't like OSX/Linux in that you can just store your keys in a .ssh folder and be done with it (at least not if you don't use cygwin/msys)
The method I chose in Windows was to use pageant (part of Putty) to load the keys. Not sure if I missed this option but you can't autoload keys so when you restart pageant you have to readd the keys (which is not terrible bad, just annoying).
Haven't tried Github For Windows yet but if it fixes the hassle of using ssh keys then I'll probably use it as my main git client for Windows.
It's not simply a matter of checking an option unfortunately, but you can still get Pageant to load keys at startup by creating a shortcut to it in Programs -> Startup:
You can autoload keys with pageant. You have to change the shortcut in your Programs\Startup folder that loads pageant itself. From memory I think it's as simple as adding the paths (in quotes) space separated after the executable. It's certainly in the help documentation at any rate.
> Windows isn't like OSX/Linux in that you can just store your keys in a .ssh folder and be done with it (at least not if you don't use cygwin/msys)
Then, by all means, use Cygwin or anything that helps you, even if it doesn't come with Windows, if it isn't provided by Microsoft, doesn't look familiar and if it doesn't play well with Visual Studio. If you code for Windows you are coding against an insanely complicated set of APIs.
It's not a question of familiarity, it's that git doesn't play nice on Windows. It requires a POSIX emulation environment, like cygwin, which is a second class experience.
Compare this with Mercurial, which runs great from the command line on multiple platforms. I actually prefer the command line for SCM work, but git makes it hard.
Putting all of your SSH keys in a .SSH folder (inside your user directory) and setting up OpenSSH to look through those when you try to connect to something is exactly what installing Git on Windows does.
This seems pretty friendly to me. Is there something I'm missing?
Just ignore the internet warriors below. :). Smile, nod and continue being productive. The GUI saves you time and reduces the learning curve for new developers. If you feel like using the command prompt, you still can.
For my team, which consists of designers and developers, this will make the learning curve of my designers a lot easier.
Saying that because you don't know how to use SSH keys on a windows machine means you can't write secure code is just silly. It is a slippery slope to say that. If the majority of senior guys actually believed it then we wouldn't have a use for higher level languages (ruby, php, etc), frameworks like .net, etc.
I really don't want to get involved in this flamewar but I have one question: You can use github with https and you never have to setup ssh and manage keys. So what's the problem? SSH is not the only choice.
"Scary crypto stuff"? So you don't understand how PKI works and you're trying to use distributed source control? (I say this not to be a jerk, but because there aren't exactly a wealth of good alternatives given it is a distributed source control mechanism. PKI comes with the territory and an SSH key generation is part of that)
GitHub doesn't take any more setup than a standard Git setup takes (well, outside of signing up, a very short process anyhow). Install the Git client via the Windows installer, (point and click, a minute, tops). Generate an SSH key. Upload the id_rsa.pub. Done. I mean, it would be one thing if they left users in the dark about this, but I'm fairly sure that the "Thanks for signing up page" links directly to the OS-specific meticulous step-by-step instructions of generating the key.
I'm not sure you understand what it means to be flamed. Every one of the comments is specific about your misconceptions and why signing up for a GitHub account is as trivially easy as signing up for a Twitter account. (Using GitHub as an oAuth account does not require actually uploading a public key)
None of us want to understand every single domain of knowledge from set theory or quantum physics up to cosmology or social psychology.
I personally have been forced to learn more low-level Unixy things than I ever wanted to. I want to write simple and elegant front and back end code quickly so I can spend my spare time honing UX and other human-facing aspects of my work.
I resent being flamed because I don't fully understand the subtleties of zsh or nginx or or whatever other shiny toy someone else happens to find essential knowledge. Your world might not necessarily be mine.
Actually. I agree with you (apart from the fact that I haven't had a chance to learn much about social psychology). I was just trying to think of examples of disciplines at opposite ends of an imagined continuum.
You might be right about any number of such subtleties, but you are not right about this. There is no way that spending half an hour to learn how public-key authentication works is a bad investment for any person working on an application that communicates with something over a network.
You can't follow 3 step-by-step instructions, insult me by implying I'm flaming and then drudge up completely unrelated tools in a discussion about ssh-keygen?
What do you people want? Seriously? Yes, I'd love to have a big red easy button. It could autoconfigure MySQL, and write init scripts, configure deploy environments because apache conf files are too complicated to learn. Hell, it could even write my backend code and then commit it for me too!
I'm done with this ludicrous conversation. I've never seen such an ignorant-excusing entitled discussion in a "technical" community before. Downvote me because you can't follow steps or can't be bothered to learn how to use one of your most important development tools, I've lost interest.
From looking at the desktops of an ordinary office, it may be difficult to realize that, when you are talking about internet connected servers, it's a very *nix world.
One of the reasons why I recommend using Linux on the desktop if you develop software for anything non-Windows: it's handy to have more exposure to the environment your code will run on. If you run Eclipse to develop Java code that'll run under Tomcat on Linux, you have a lot to gain by moving to Linux yourself.
If, for some reason, I end up writing Windows-specific code once again, I'll probably develop it on a Windows box. Visual Studio is a great IDE if you want to write programs for Windows.
Nobody in this thread implied that you are flaming, nor intended to insult you; the person you are responding to is not the person you originally responded to, and he is commenting about people in other threads flaming him. I resent having to explain this to you.
What the hell are you so angry about, seriously? People have less expertise than you, and that makes you upset?
He's probably angry because he's had a person with 15 years experience unstage 10 commits already pushed to origin (reset HEAD~10) then readd them to the index and complain to everyone that git tells him every file in his repo is conflicting after a merge. After a serious bout of ROFL he has to help the coworker use merge correctly weekly. After a while of this the person decides to manually fix the conflicts each time he has to push to origin there adding a comment in the git log that says :merged master back into branch.
So to all of you that actually know the difference between merge and rebase and what the difference between origin and local branches are :hattip:
>I resent being flamed because I don't fully understand the subtleties of zsh or nginx or or whatever other shiny toy someone else happens to find essential knowledge. Your world might not necessarily be mine.
That was in the post I replied to. It's insulting because it's accusing me of things that I didn't do. I merely am just a bit floored by the notion that following these instructions, http://help.github.com/win-set-up-git/, is asking too much of someone who is going to be using Git regularly.
I guess I expect too much and seem to be wasting my energy. I apologize.
For many people there Github = git, so saying github isn't much harder to set up than Git isn't saying much.
Using git on Windows has historically not been super fun. The CLI installer mostly works, but it's pretty clunky. Cygwin works fine too, but it's also not especially elegant. At the very least, known of these solutions conform to the expectations of people of the platform. The GUI clients on Windows last I looked (a year ago) were pretty terrible, especially compared to TortoiseSVN, which isn't bad. OS X, on the other hand, had several very nice GUI clients even before the official Github client came out.
Maybe it's gotten better, but last I tried it, TortoiseGit simply did not work well. It was buggy and awkward. It crashed. And I agree with what I think you're saying in that it obscures a lot of what makes Git different. (That said, I still think it would be very useful if it worked well.)
I don't know what difference the "Github = git" distinction makes, from an oAuth perspective it still seems implicitly obvious to me that completing the signup and adding SSH keys are distinct tasks.
As for "CLI installer" (I presume you mean the installer for the CLI git client), and Cygwin, I'm not sure what to say. I've used the Git installer dozens of times without problem, there aren't exactly tons of places for it to go wrong. Are there specific or particular issues you have with it?
I do indeed forget that some programmers manage to make it far resisting learning to use the command line. Even with step-by-step instructions. I guess at some people I'm willing to fault the developer rather than tools that are powerful that come with good documentation.
I think you're right and I guess that's what I'm beginning to realize. I just kind of assumed that in that case... Git is the wrong tool for their job. If you don't need the "power of Git" (I swear, I'm not in love with Git), then use Dropbox or SVN or something simpler. Seems easier than fighting with keys, and then fighting with git's distributed nature and then fighting with all of the complexities of merging and conflicts.
Haha, maybe another of way of putting things from my perspective, I found keys to be the least of my concerns once I got into projects that really used Git and I have a hard time seeing people be successful with Git if the keygen steps throws them off.
I hope that explains things from a different perspective :)
I'm sure you'd love to still be programming in assembly, but some of us prefer to spend our time actually, you know, not mucking around with stuff that is an utter waste of our time.
It takes less than 4 minutes to do. And way to ignore every, other, thing I mention in there, like how something else is probably better suited for your needs if you think it is an "utter waste of time".
The level of discourse and use the downvote just amazes me anymore. Seriously, how can you be that much of a douche after I made very basic, undisputed points?
What I don't get is why some people are so against making things simpler to get started with.
So what if it takes 4 minutes? Why not save all the people who might use your tool 4 minutes of clicking 'OK' through a half dozen boxes you assure them they should just ignore? Particularly if github (as seems clear) want to get more people to pay them money.
Well, in the original quote that was cited from "scary crypto stuff" was surrounded with:
Last I checked they[GitHub] made you perform a bunch of scary crypto stuff on your local machine before they'd let you in.
If performing `ssh-keygen` and entering in an (optional) password from a command line constitutes "scary crypto", then maybe Git and GitHub isn't for everyone. Not that anyone needs to know how PKI works, but they might be better off knowing that `ssh-keygen` generates an ssh key pair, a pretty essential component of the `git` workflow.
Maybe that's why SVN is so strong in older development shops. Outside of the effort required to convert an SVN repo to a Git repo, all those developers already have all the tools necessary on their machines (Windows is high on that list) and in many cases inside a VPN like my division we just use WebDAV anyways, completely bypassing the need for SSH Keys in favor of ActiveDirectory.
My apologies, I abuse "PKI" to mean "PK infrastructure" (which I know is what the acronym stands for, I'm making a bit of tongue-in-cheek commentary), I think it's silly that PKI implicitly means CAs but according to Wikipedia at least, you're correct.
No, he isn't, and the relevant Wikipedia article is very poorly written. PKI is a highly generic term. Webs of trust are just as much a PKI as a certificate-based system.
Everything you've said in this thread has been bang-on, and the replies you're getting are deeply depressing.
Can we at least agree that if we attempted a list of all the Xs a programmer needs to know before doing Y and made it law that nobody could write any software at all?
You got flamed for that comment because you called generating SSH keys "scary crypto stuff." If that scares you, you probably also enjoy the simplicity of storing passwords in plaintext...
What is your problem with someone being scared of crypto stuff?
I find this shows the necessary respect when dealing with security related tasks, since they are HARD.
I'm not talking about developing crypto related software, but just setting up a "safe" environment where you can store your SSH Keys in a way that doesn't defeat the purpose of using them in the first place is non-trivial, even for people with degrees.
IT Security is a complex field of its own and if a user is afraid of making the wrong choice it only shows that he understands the basics of it.
It's one thing to be scared of the deep inner-workings of OpenSSH (which truly can be scary). It's another thing to be "scared" of ssh-keygen, especially considering it's something that most competent developers will use when managing servers, deploying to Heroku, managing source, etc.
"ssh-keygen -t rsa", set a passcode on it, upload the id_rsa.pub and you're done.
Demonstrating a lack of understanding of that was worrisome for myself and other users that commented on his post a few weeks ago.
The important thing you missed then and are still missing now is that none of that stuff you mention happens in the Windows world.
We set up VPNs to our servers and access them via network paths or directly using Remote Desktop. One can go one's entire career without ever typing ssh-keygen into a terminal window. It's certainly not a step involved in setting up a client to talk to version control.
You don't have to believe me on this. You can read the article we're talking about here and see this same sentiment expressed by the GitHub team themselves.
Thanks to that team, folks in our side of the dev world now have an easy path into Git and GitHub, and can go about our merry way building things without ever having to parse what it was that you did in your second paragraph.
"Thanks to that team, folks in our side of the dev world now have an easy path into Git and GitHub, and can go about our merry way building things without ever having to parse what it was that you did in your second paragraph."
... except when github messes up, forces you to do a SSH key audit and then you're back to needing to know "scary crypto stuff".
Problem is, not everyone who wants to program is willing to go through these steps. Even being a security engineer myself, I balked at some of the steps. I know why they're required, and I understand the steps behind them, but man all I want to do is put this little script somewhere where I don't have to worry about it getting lost.
I don't want to have to do it all command-line, I don't want to have to copy and paste from their blog, I don't want to have to do it by hand. I'm not a competent developer (and I reject your assertion that you need to be a competent developer to use version control), I'm not setting up a server, I'm not deploying to Heroku. I want this script backed up and I want it version controlled. No reason why it should be hard.
No reason why it should be hard, because the whole goal of technology is to make life easier. I'm scared by the thought of a lot of stuff inside my computer and OS, but luckily there wasn't someone with your mindset and now anyone can easily get a computer from bare metal to running Angry Birds in Chrome. I'm not a developer although I write scripts sometimes, and the barrier to entry should not be set higher than absolutely necessary. If that means GUI, then so be it.
Nobody said anything about it being scary to type "ssh-keygen -t rsa" but rather about the responsibility that comes with it.
I'd bet my right hand the more than 25% of "competent developers" that are "managing servers" will have made security mistakes while storing their ssh keys on a level with storing the password in plaintext on a .txt file on the desktop.
Thats whats scary about "crypto stuff", not that it isn't easy to use the tools, its hard to be really sure how to put them to good use when you are no expert on IT security.
Outside of checking id_rsa into your Git repo or emailing it, (which would be equivalent to doing so with passwords.txt), SSH (and thus Git) protect you from leaving id_rsa with open permissions. Though it may not be obvious that id_rsa is something to protect. (though again, I don't go emailing random files I don't understand either).
That having been said, I'm certainly not a security expert. Are there other common things to look out for to ensure my private key(s) are safe?
Do I understand right that id_rsa is an equivalent of password.txt in that you have big broblems if someone gets it? In this case I really worry about its being stored in the open in some /users/AppData and not on some TrueCrypt drive that is not mounted by default.
This is why you protect it with a passphrase, which SSH asks you to do by default. Choose a good passphrase, it's encrypted on disk, and decrypted only as needed.
Seriously guys, you're not even trying. Here are the instructions everyone is freaking out about, they contain an explanation of this very issue.
> managing servers, deploying to Heroku, managing source
I'd hate to say it but if you're introducing someone in Windows land to source control then NONE of the items on that list are part of their skill set.
I'm surprised that the responses to this amount to, "I don't understand it, don't want to follow instructions and want a two-click GUI". Git isn't magic. To leverage it well, you need to be willing to get down and dirty with the CLI sooner or later. If you're unwilling to learn Git, don't use it.
If you're a dev, source control is one of your tools. Learn it or find a tool that holds your hand more. I don't know how it gets more hand-holdy than step by step instructions that take 4 minutes to carry out.
Is anyone going to actually reply, or should I continue taking downvotes as "I disagree or I deserve more hand-holding"?
You're being down-voted into oblivion. You get even more insulting as you're falling down in your edit.
Mm disclaimer: I'm a windows dev by day. I introduced git into that shop I'm working at, the rogue 'I set it up, would you technical guys like to work with it' way. This happened 1.5 years earlier, today it's the blessed and only source control in play (ignoring one sad division having to deal with tfs.. Oh the agony).
So, I a) was the driving force pushing git and b) work in an environment where unix/linux knowledge is rare and ssh is a weird thing.
You are, again and again in this thread, missing the point and just plain insulting. Take it from this guy that types this message from his linux box and has a linux to windows box ratio of 5:1..: The git toolset sucks. It's crap for people that are used to windows only. You can mock people for them being uncomfortable with putty-gen (more likely, btw) or ssh-keygen, but the fact is that it's arcane and unintuitive to do that, if you have no clue what ssh is in the first place.
It doesn't help that git really doesn't _need_ ssh. It's just one (well, _the_ one) protocol you can use. I've coworkers that generated their key and didn't keep it afterwards. They thought it's kind of like a registration or that the client will keep this 'stuff' around somewhere. Most 'git doesn't work' errors are related to crappy windows clients being not helpful if the ssh key isn't available (ssh-agent/pageant not running or key not loaded).
SSH, in the company I work at, is 'that git stuff'. You consider that funny? Well.. Go ahead. My totally socially awkward inner geek might agree with you, but to the real world you're laughing about a weird kind of a maths joke right now. Most people don't get it, you're mocking things no one cares about and in the end you just look out of place.
Maybe GitHub for Windows will alleviate some of the problems with bad key handling, but I wonder if a few strategically logged bug reports with GitExtensions and TortoiseGit would go a fair way to fixing a lot of the friction people experience.
"You want to use Git, you should know how to use Git"
If that's insulting, then I'm going to have to learn to live with being a cruel, mean person.
Also, it's GitHub's fault that they use an existing secure method of transferring source code instead of writing a new protocol that's easier for you to use. Because 4 step-by-step instructions are too hard to follow. OK.
I'm not even asking that you understand it, but simply be able to follow very, very simple instructions.
(It's perfectly reasonable to not like Git's toolset. There are dozens of other source control utilities out there. The only ones I know of that are more 'usable' are SVN and TFS, and the tradeoffs there are pretty stark in my humble opinion)
The insulting and derogatory remarks is stuff like:
"Also, it's GitHub's fault that they use an existing secure method of transferring source code instead of writing a new protocol that's easier for you to use. Because 4 step-by-step instructions are too hard to follow. OK."
"I'm not even asking that you understand it, but simply be able to follow very, very simple instructions."
"If you're a dev, source control is one of your tools. Learn it or find a tool that holds your hand more. I don't know how it gets more hand-holdy than step by step instructions that take 4 minutes to carry out."
It's not insulting to point out that the instructions are very simple, easy to follow, and easy to understand. Everyone here is smart enough to understand these things, and it's utterly bewildering that they angrily refuse to spend 5 minutes learning about something new in order to use something new.
Ah, but to the people who may have trouble with the instructions (for whatever reason) or using the product beyond the instructions it is quite insulting. It is a direct insult to their intelligence and/or their ability for no good reason. That attitude does nothing to help our community, especially the people who are new to all this.
Let's imagine a company creates some form of hardware widget that requires some form of setup before it can be used. Initially the setup involves four steps that the company feels is "simple". Now, let's say a number of their customers have trouble with those simple instructions for different reasons. What's the proper response from that company?
A: Maybe we should think over the instructions to identify some problem spots as to why people are having trouble? Maybe we should ask some of these people what part are they having trouble with? Maybe we should consider a more in-depth explanation to people who have never used a similar device before?
B: If people aren't smart enough to figure out our simple instructions then they're too stupid to use our product. We could just ignore them but instead we'll insult them because they just don't get it. After all, if they're in our industry then they should already know how to do this.
I'm not saying that everyone should use response A, since most likely the problem has been answered somewhere. But too many people go with response B with absolutely no benefit to anyone in any way.
People telling you to follow the instructions are not questioning your intelligence. They're telling you to you know, follow the instructions. Because they work.
If you don't want to do that, you now have the option not to.
Please, bring me someone who actually had trouble with those instructions, and not because they freaked out at the first sign of a command line. They must have actually read them, including the expandable bits, made a serious effort to follow them, and failed.
I had a couple of breakages, because step 2 tells you to remove SSH keys if they are already present (without saying "Wait! Why do you have SSH keys? Maybe you should ask why they are there"), which broke various tools that expected the old keys to be there.
So in all the rules, the one place that isn't just "press OK, press OK, press OK", tells you to do something probably dangerous, depending on your setup.
It tells you to back them up, that makes it an inconvenience in the worst case, not dangerous.
More fundamentally, you had SSH keys and no understanding of what they were for? Sorry, but this is exactly what I'm talking about. You are choosing to use systems you have no understanding of, and taking no time at all to learn about them. You are dangerous.
I guess the problem some people don't want to realize is that you actually create that situation with this "Why can't you just follow this simple list" attitude.
I agree that everyone should be able to follow that list. And now you have someone with ssh keys and no idea what they are.
I think it's dangerous to mock people that are scared of these things (defined as opaque instructions that install various products and ask you to copy paste commands in a terminal) and afterwards mocking people that potentially DID follow that list, succeeded and now use a system they have no understanding of.
I love git. Git on Windows feels out of place for every Windows only guy I showed it to. Why is that something to argue about - and why does it lead to borderline insulting comments? It's interface is.. different and UIs are bolted on only and it packs a lot of mental dependencies (learn about ssh, different newlines) that aren't really related to your ability to write (Windows) code.
That Github link is perfectly correct and still full of WTF material for people that never left Visual Studio. I work with those, and I have a couple dozen anecdotal evidences available..
First of all, I should have clarifed that "I had a couple of issues" means I had to fix some broken computers where that had happened.
Secondly, you just said you wanted "A single person actually who had trouble with these rules". I presented you with such a person (indirectly).
While it isn't dangerous, it was annoying, because it took some time to figure out why various tools where no longer working correctly.
To be honest, you seem to be getting surprisingly angry that there at people who might want to use this shiny thing called github, on which many projects they use might reside, without fulling understanding every detail of git, ssh, etc.
I know some mathematicans who can write amazing algorithms, who I would want involved in projects I work on. However, they use windows and don't really care about the finer workings of unix. Personally, I think it's good if such people has the easiest access possible to making a quick push request, on their own machine in their comfort zone.
I'm angry at willful ignorance and attempts to justify it.
I truly, TRULY have no problem with making key generation push-button. I really don't. I have a very BIG problem with people who don't understand it pushing that button.
But you're right, I give up. All I can do is ensure that these people who demand of themselves nothing but the most disgusting of human characteristics -- willful ignorance -- do not come anywhere near my systems or projects.
First of all, thanks for answering my question so clearly. However, I feel the need to make a reply, despite the fact I think we have reached an impasse (not saying that is your fault, just a difference of opinion). I just feel you are really expressing yourself in an insulting way (you consider it a most disgusting of human characteristics that someone might just not care to learn about how ssh keys are generated)?
It's isn't "wilful ignorance" to not try and learn everything, ever, about everything. Particularly things which you don't want to learn, and probably aren't going to help you. We all specialise to one degree or another. I work with mathematicians who have spent years learning and refining their craft, who certainly know more maths than I could ever learn. I accept that there are things they know, and things I know. I want them to continue doing amazing maths, so I don't want to pile on them a bunch of things they don't want to learn. Despite the fact I did a maths degree, I know there are things they commonly discuss I don't really understand, which would be their equivalent of ssh keys. Things everyone knows. I've learnt some of them for work. I've learnt some of them for fun. But I don't have the time to learn all of them, and that's fine.
Now, these people do still learn. They learn about all kinds of fields, and all kinds of areas. They learnt CVS, but they didn't enjoy it.
Also, I find it very productive, and fun, to work with people whose skill sets are almost entirely disjoint from mine. It does make working together a bit tricky, but some of my most productive times have risen from such situations.
In most cases you are probably correct, I'm not really commenting on those particular instructions. I'm just making an observation about the responses based on comments people give about problems they are having.
I've read through the instructions and they do seem straight-forward enough. In fact, they are actually quite nice. But that still does not mean that some people will not have problems along the way. Not that I have any evidence to back this up but I can think of a few possibilities of why people may have problems:
1: The installer keeps failing for some unexplainable reason. Maybe they don't have the user rights, maybe the IT department is blocking it, whatever other possible install problems. You can't assume that everyone will understand why the installer is having issues on their particular computer as compared to another. We're already seeing reports like this for the new installer just released, I guess those people can't follow the simplest instructions of double-clicking an exe installer correctly. Right?
2: When they get to the line ending conversions part; what if they don't understand the options and abandon the process? Remember, some of these people are new to Git and without some hand-holding they may feel lost. In the screenshot I see there's no recommended option. So it's up to the user to pick the one they need without knowing what they need. Unless there's someone to point it out. And considering some people's attitudes about noobs doing the "wrong" thing then options like that are rather important to consider properly. Do you want to bet whether someone has complained about someone else picking the Windows-style checkout?
3: Even though the instructions are nicely laid out, not everyone is accustomed to the command line. I bet there's a huge number of Windows users who have never used the command line. Even with simple instructions there's the possibility for mistakes. There's even an extra section just for SSH that clearly shows that some people have issues with that part, even Github is trying to address it right there. But they can't possibly cover every conceivable issue.
Notice that most of my examples have nothing to do with the instructions themselves, but unforeseen problems that we have to deal with simply because so many people have different computers with different configurations with different networks with different IT departments with their different mandates. The attitude that it's simple for me therefore it must be simple for you is a bad one. The new installer worked for me on the first try, I don't dismiss the ones that did have a problem for some reason.
But to further prove my point about my two responses from before, Github decided to go with response A. How do we know? The release of the even simpler all-in-one application that started this whole conversation. Even with the "simple" instructions that have been pointed out, Github decided to listen about problems with the process and have responded with an even easier method to accomplish the same task. Even go above and beyond.
That is the mark of a good software developer/company/project. These are people trying to be inclusive, not exclusive.
Sadly, too many people in this thread decided to go with response B. Thankfully, Github disagrees with that attitude.
> The installer keeps failing for some unexplainable reason.
Not a problem following the instructions -- such a failure is clearly outside their scope.
You also conveniently ignore the reality that if they don't have permissions to install it... They're not supposed to be installing it in the first place. Report them to their corporate IT department, you'll be doing everyone a favor.
> When they get to the line ending conversions part; what if they don't understand the options and abandon the process?
Purely hypothetical. But if they give up that easily, yes, I consider it PEBKAC. People must take responsibility for their own ignorance and laziness.
> Even though the instructions are nicely laid out, not everyone is accustomed to the command line.
It. Is. Text. Read it. We read every day, we type every day. This is not difficult. Fear of the command line is irrational, which is exactly why I excluded it.
Oh I agree, I'm just providing examples. As I stated, the instructions are quite nice and easy to follow. I'm just pointing out possible problems people may have during the install process when so many people seem to be saying surely no problems exist because it is so simple.
I tried to make it quite clear that it was all hypothetical and outside the scope of the instructions, maybe I failed. But they are indeed possible problems that people can have during the install process. Whether the people are correctly identifying their problems is a different discussion. You are making my point for me, it is simple for you therefore it should be simple for everyone else. I'm just saying that it is quite possibly not so simple for other people, for various reasons. Nothing more.
Here you ask for five minutes of learning, later in this thread you seem to (correct me) expect people to get a good grasp on ssh and key management to avoid being 'dangerous'.
Is both correct? Or would you agree that 5min to learn how ssh works, even for a broad overview, is not exactly helping / changing anything.
Two different issues got mixed together here, and I wasn't good at distinguishing them in my comments.
It should take five minutes for them to learn the basics of public key crypto so that their eyes don't glaze over when you say "public key", "private key", "fingerprint", or "RSA". I consider this basic knowledge absolutely essential for anyone using these concepts, even indirectly. Without it, you're dangerous.
Once those concepts are in place, it shouldn't even take five minutes for them to understand what SSH is doing, because SSH is a very simple and obvious application of the concepts. It should be self-evident from the brief discussions in github's instructions what is going on.
And once you've taken the five minutes to understand the concepts, not being dangerous is likewise simple and obvious:
* Put a good passphrase on your key.
* Don't share your key with others.
* Don't type in the passphrase for your key on any computer you don't trust at least as much as your own.
Notice how these aren't fundamentally different from protecting a password.
We are talking about inherently intelligent people with a good capacity for learning. It is mind-boggling to me that anyone would argue that these people should not have to spend five minutes to understand at even the most basic, limited level, how critical tools they want to use work.
When seeing other people who have problems and difficulties - one group only feels righteous indignation; while another group sees a business opportunity.
Here's the fundamental problem. If you can't understand very basic security tools and concepts, you cannot securely operate a computer, much less hope to ever write secure code.
SSH is one of the easiest security tools to use safely that has ever existed. I would say it is second in usability only to HTTPS in browsers, while having a much better actual security record, and is infinitely more powerful, while keeping basic operation so simple I once taught my mother to use it.
I am 100% confident that anyone competently engaged in development or systems administration can understand the basic concepts and operations of SSH in five minutes. Any fear of it is irrational. It is not hard, it was specifically designed not to be hard.
I'm equally confident you've not taken the five minutes to understand these relevant concepts, because your statement about setting up a "safe" environment makes no sense in the context of OpenSSH. The defaults are inherently safe, as they should be. You must take specific actions to make the system unsafe.
> Here's the fundamental problem. If you can't understand very basic security tools and concepts, you cannot securely operate a computer, much less hope to ever write secure code.
He didn't say he was incapable of understanding it.
> SSH is one of the easiest security tools to use safely that has ever existed. I would say it is second in usability only to HTTPS in browsers
Perhaps that's true, but I suggest testing it would show a massive discrepancy between ease of HTTPS use and SSH use.
In short: I think this is a UX issue, not a PEBCAK one.
There is no UX issue, it's entirely an irrational fear of having to read. Putting it in a GUI accomplishes nothing but clutter the screen with irrelevant crap.
nknight@unassigned-hostname:~$ ssh-keygen -t rsa -C "foo@example.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/nknight/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/nknight/.ssh/id_rsa.
Your public key has been saved in /home/nknight/.ssh/id_rsa.pub.
The key fingerprint is:
d3:c0:19:ae:5b:ff:46:fd:a0:b5:9c:a2:93:a4:ca:c2 foo@example.com
The key's randomart image is:
+--[ RSA 2048]----+
| . |
| o o |
| = |
| . o |
| . S . . |
| o o. . + |
| . . o.o + = |
| E. . o.+ + .|
| .o. .+.. |
+-----------------+
nknight@unassigned-hostname:~$
Read. READ. Comprehend. Don't throw your hands up and say "But it's sooooo confusing!". It's not. It's very simple, and it is not possible to simplify further, no matter how you try to dress it up in eyecandy, you still must read and comprehend the exact same concepts. If you do not, you cannot be secure. Ever. The basic concepts of public key crypto are mandatory knowledge for everybody.
Get over your irrational fear and you will have no more trouble than you would reading a technical book.
That is an excellent example of "scary crypto stuff".
Most people aren't going to change where the file is saved, or care. They don't know, or care what a fingerprint is. I still have no idea what the 'randomart' images are about.
I don't see any benefit to all of that over having a button marked "make keys" which just gets me set up so I can use github.
Of course, you could force people to care about what files are placed where, and their permissions. Then you should probably remove the default values of course.
So long as you're unwilling to learn, very simple things will forever elude you.
> I don't see any benefit to all of that over having a button marked "make keys" which just gets me set up so I can use github.
It's not that the form has any strong benefit in itself, it's that if you understand what is going on, which is required for security, the text form is in no way mysterious, complicated, or intimidating. The GUI isn't fixing anything, it's just masking a serious problem with the user.
I also like being told where semi-automated processes are placing critical files on my filesystem. I'm surprised that annoys you.
> I also like being told where semi-automated processes are placing critical files on my filesystem. I'm surprised that annoys you.
No, it really doesn't annoy me. I'm very happy for you to use git from the command line. I use git from the command line and don't intend to use this new GUI. It would be no good to me anyway, as I use linux.
However, I get the feeling that you are annoyed that other people might want to have a full automated process, and not care where the critical files are being placed.
As time goes by I feel one of the most important things is to reduce the amount of work it takes for people to get started with something, particular because I have wasted so much time on it. Did I waste the time I spent getting started with git? vim? python? Not at all.
Did I waste the time I spent getting started with emacs? ruby on rails? mercurial? FreeBSD? Arch Linux? screen? To be honest yes. Each of these things, in their own way, had an annoying and non-user friendly setup and start, and I've since stopped using them and don't believe the skills were transferable. While I enjoy learning things, sometimes I just want to get started. Also, sometimes I want to get many collegues, who are less computer literate but still experts in their own fields, started.
GitHub for Windows generates and associates the key automatically without any user intervention. This is arguably better UX, and indicates that how to use ssh-keygen isn't necessarily mandatory knowledge.
All sorts of things can be done without any user intervention, but if the user doesn't understand how it works, they can't use it safely, and they are a danger to themselves and those around them.
One can perform the act of driving a car without any understanding of what the engine does, but if you lack any understanding of what it does, you're going to park it in a closed garage, leave it running, and kill yourself or someone else because you were too afraid of scary mechanical stuff to learn.
If you can't be bothered to learn about public key crypto, someone's going to social engineer your key out of you without you having any clue what happened.
It could use a "Key generated in `c:\users\james\.ssh\`. Don't share keys indiscriminately." dialog, but that's about it to achieve social engineering education parity with ssh-keygen. Users aren't inherently less secure just because they didn't copy and paste a command and see a randomart image.
I found some of the responses to be as troubling as some found the original post. The responders made assumptions and didn't bother asking why he called it "scary crypto stuff". He might have had a point since new people to all this might have reacted that way. But who cares about that right?
Very well done. ClickOnce installer; solid UI (rare on Windows, I've found), and even installs git hooks into PowerShell so there's no need to dump the user into bash (unless they want it).
One downside, not entirely obvious how one's supposed to clone a repo with this?
To be fair, the GitHub for Windows UI looks a lot like the Zune UI, which has been around for a while now. I've not been able to try it yet on my Windows machines, but the screens I've seen look like they borrowed heavily from what Zune had.
GitHub for Mac borrows from a lot of good Mac UIs, and it looks like GitHub for Windows does the same from good Windows UIs. Frankly I find this refreshing. I'm tired of applications that build their own interaction layer and then implement that across every platform regardless of that platform's idioms. Or, even worse: Air apps.
I'd be interested in learning how they implemented the UI - it looks like it's native to Windows 8 but runs just as well on Windows 7. Would be interested to hear what toolkit they used.
So far, the UX has been impressive for a tool that has historically not run very well on Windows.
Edit: They've mentioned the toolkits used at the bottom of the page. Apparently this is written in C#.
The UI was implemented using WPF4 and Blend. We also use a framework called Caliburn Micro as well as a framework I wrote called ReactiveUI which orchestrates connecting the UI to data via binding.
It looks great and I am installing it now on Windows 8. I'm curious why you chose to use Caliburn Micro over, say, MVVMLight? Do you plan to share some of the technical decisions made for this product on GitHub's Blog?
We used Caliburn Micro for its Screens / Conductors implementation and its convention-based wireup of views. We use ReactiveUI for all the ViewModel code though.
Thanks for the info. It looks like you chose to embed Chromium for rendering markdown? What was the reason for not using an embedded IE instance (which is already part of every Windows installation).
IE doesn't participate in the WPF rendering system, so it would have all kinds of glitches like it sitting above all other controls (referred to in the docs as "Airspace Issues"), as well as unthemed controls (specifically the scroll bar - stuck out like a sore thumb). The markup that READMEs use is really simple, IE would've been fine for it.
If you run the app, click on the "tools and options" cog then "licences". This page lists a lot of libraries.
> Apparently this is written in C#.
You sound surprised. To me it looks like a quite slick WPF app, which aims for a metro-ish look. But I've seen nothing in the UI that is particularly challenging for WPF. WPF is very, very flexible.
> I assumed that doing any sort of integration with Git would require C-level bridging.
Short of re-writing git in c#, it does require bridging. That's what unsafe code is for - calling out to dlls written in c.
> Didn't realise there was any sort of decent C# bindings for Git.
I kind of just assumed that there was. There usually is. The licences page lists "libgit2", so it's probably this one: https://github.com/libgit2/libgit2sharp#readme (edit yep, LibGit2Sharp is mentioned later on in the licences)
The file LibGit2Sharp/Core/NativeMethods.cs seems to do a lot of the bindings.
> the WPF ones that I've seen were quite clunky
I said that WPF was flexible, I didn't say simple or easy :P Also, to get good design, you usually need the help of a designer. Most coders will produce "clunky" UIs. I would. Somehow, the Windows desktop space has been very slow to deal with this.
Are you serious? I ask this out of genuine ignorance, knowing only a little of what has gone on in the Windows world the last ~4 years. This is what Windows 8 apps are supposed to look like?
Not sure why you're getting downvoted -- this was my reaction as well. Particularly the lack of any sort of top or bottom border makes the app feel very cramped. Also, some of the mouse interactions I've become accustomed to in Win7 don't seem to work (such as dragging a maximized window from one screen to another) but I'm not sure what to blame for that.
I guess GitHub's apps are kind of the hipster git clients on all platforms. I don't really like the Mac version (I'm faster in GitX), but this looks actually pretty decent and also what I was expecting for a Metro app. I'll give it a try later to see how productive I can be with it.
This is not a "Metro app" in the Windows 8 sense of the word. This is a "desktop app" that looks like a WinRT/Metro/"modern app". Just as a heads up since there is already terminology/tech confusion.
I don't actively use any git GUI client, but my reaction is to the style in general rather than anything git-specific.
I don't claim to be a design guru, but it looks like somebody was going for minimalism, but used a nuke instead of a scalpel. My eyes don't know what to focus on, there's limited indication of what things are, and in places it's hard to tell at a glance where one component ends and the next begins.
It's not so much ugly as it is intensely vague and somewhat undiscoverable.
Edit: Just to be clear, I don't want this to be seen as a criticism of this app or its developers specifically, I'm operating under the impression I'm getting from other commenters that this is very Windows 8-ish in general, so take this as bewilderment at the Windows 8 style.
Nope. But I think it's a part of ClickOnce, the technology they use to bundle up an app into a setup.exe that fetches the latest source from a web server.
Nope. At work we have a similar setup.exe file. The setup.exe is a bootstrapper that installs prerequisites first, then runs the ClickOnce installer which is separate.
No such convention. Windows does some funky detection of when the exe might need to elevate privs but it detects anything with the word setup in the filename.
I really like the Mac app. Yes, it can be a little buggy and get in to some weird states, but when it works, I think it is one of the best ways to use source control.
I've been doing a lot of Windows development lately and I've missed a good git tool. I'm very happy about this.
For those of you looking for a nice Git client for Windows, I suggest checking out TortoiseGit[1]. I can't recommend it enough. It is such a powerful peace of software and I am surprised it is not brought up in discussions more often.
One single powerful window instead of explorer right-click menus, feels more productive for me. Great support for PuTTY (needs some tricks with KiTTY) but also works with openssh.
I use TortoiseGit (and was a long time user of TortoiseSVN before that), but I find it to be a poor substitute for the command line. I feel like they tried to make the names of git commands more user friendly, but having already grown accustomed to misnomers like "git checkout" it often takes me a little while to find the right action in TortoiseGit.
Checkout in SVN does not mean the same as it does in git. SVN Checkout is more like Git Clone. Checkout in git means change to a different branch. You "checkout a branch" in git.
I think it is better for TortoiseGit to match the semantics of git rather than match the semantics of TortoiseSVN. It causes some confusion coming from SVN for sure, but once you start using git, you should learn its dialect. It would be worse if TortoiseGit did not match git's vocabulary.
That was my point. For example, TortoiseGit presents "revert" instead of "checkout" (e.g. on a file, not a branch). "revert" in git actually means something else entirely.
Oh really? I used TortoiseSVN for a long time, and switched to the command line when I switched to git. I can see why TortoiseGit kept the "revert" naming, but I disagree about the choice.
I came here with that question in mind. What's the difference to the already battle-tested TortoiseGit? GitHub for Win obviously works with other hosting services, that's fine, but is it better?
I find it interesting that both native apps (for Windows and Mac) try hard to emulate the look and feel of their respective operating system.
One thing that is great about github.com and other websites is that it feels the same across multiple environments. Furthermore web browsers try to emulate their own style not that of the host operating system. If I use chrome or firefox in mac or windows they feel basically the same.
I wonder if more applications will go in the direction of trying to match the feel of the host operating system over the feel of there application as a whole.
I've been developing web apps for Windows 8 lately using the native -ms- proprietary CSS styles and UI hooks available in IE 10 on touch devices. (CSS grids and scroll snap points!) Let me just say, web apps that follow the Windows 8 UX guidelines are easier to develop and, overall, just feel better to use. That is, they feel like they belong inside Windows 8.
From that perspective, I think they're doing the right thing.
Precisely. Making the effort is half the game.
It's a similar scenario with mobile apps: far too many Android apps are ported across from iOS without consideration for the different platform (usually by using a tab bar). And it really shows.
> Being a good OS citizen is nothing but a good thing.
Actually there are pros and cons to adapting an application to the platform instead of adapting the platform to the application. You're also conflating the OS with the window manager.
One of the biggest reasons that I prefer Mac to Windows is that most Mac developers spend a lot more time working on a native look and feel. The common OS shortcuts and UI metaphors go a long way towards making an app easier to use.
but since this is using your framework, xpaulbettsx, is the source for this going to be available? I always love seeing open source functional applications that use a certain framework or toolkit I'm considering. Makes the divide between reading code/documentation and the end product just seem that whole much closer.
Good point. If I need the efficiency of a keyboard I will use the git bash cli. I suppose this is why they've bundled powershell git extensions.
It's a first iteration / release. I'm sure with more feedback they'll release more often. I'm unlikely to use this much - because I favour the cli - but I really hope this makes git more accesible to some Windows shops.
Seems nice except for how it keeps pushing you to login to github, that would probaby get annoying after a while if working with non-github repos. Also the diffs weren't working with the java files I tried it with, it just minuses and plusses the whole file, hopefully just a bug they can fix. This is my first look at a Windows 8 UI and if this is representative of the fufure I am worried, but it does looks pretty. Overall though this is a good effort.
This is awesome. Personally I'm a linux user so git is one of those rare tools that caters to me, but I've been in a few backwards development shops where git was looked down upon because of inferior tool support on windows when compared to subversion.
I'm in favor of anything that helps bring windows users into the git-using fold ;-)
I'm interested to see how the community responds to their choice of ClickOnce as the deployment method.
I use ClickOnce for several of my applications, and I'd say the users who dislike it the most have the highest technical aptitude (which, I'd guess, is a large part of GitHub's user base).
As a technical type, I don't mind ClickOnce. Chrome is another good example of a successful ClickOnce application that a lot of technically savvy types use.
I think maybe ClickOnce's drawbacks are less of a sticking point when the application you're installing is one that needs Internet connectivity to be fully functional anyway.
shrug - Honestly, I thought the same thing - and then I only realized GitHub was a ClickOnce app after poking around at the shortcut it created on the Desktop. The installation was pretty seamless.
- Why can't I find the installation directory? (ClickOnce doesn't use the standard C:/Program Files/ location, it stores program files in C:/Users/<your username>/AppData/Local/Apps/2.0 for security reasons.)
- Why does the installer need a network connection? (ClickOnce downloads the required setup files from the internet.)
The lack of a standard Program Files/.exe deployment also makes it difficult to map filetype associations, which is also a frequent complaint.
I'll likely be going with non-ClickOnce deployments for the future. ClickOnce is great for deploying production software at work, but for a consumer audience, it isn't quite perfect.
Considering that Paul has been working on it and yet choose to go with ClickOnce, I am guessing it's not ready for prime time but it might be worth looking into anyway.
NSync isn't finished yet - ClickOnce is 95% of what we want but has some pretty damning flaws (tells people randomly that an app is "Unknown Publisher", certs expire after one year and now people have to uninstall/reinstall, proxy server problems, etc).
NSync is my ongoing (not finished yet!) project to recreate ClickOnce
BTW is there a way to submit tickets other than email for GitHub for Windows? Maybe a GitHub repo? Would make it rather easy to submit and track issues while also limiting the number of duplicates.
NSync has a somewhat novel mechanism of delivering updates (via repurposed NuGet packages) that would be difficult to shoehorn into NAppUpdate or other frameworks
Yes I've been keeping a close eye on this project. Based off the readme, it sounds exactly like what I'm looking for. You make a good point though, as it was authored by the same user but ClickOnce was chosen instead.
I fucking hate ClickOnce. The crappy downloader fails all the time. Not all places have a good QoS connection like North America. HTTP download can be restarted and resumed at anytime.
Yes and it's actually really easy to do, it's built right into Visual Studio. The downsides are that you can't really do anything with it after you've set them (like at application runtime), the associations don't always work for some reason, and if the associations get changed by other applications you can't reset them unless the user re-runs the installer.
Another one I can add is that certain security packages (coughSEPcough) can do weird things to the SXS repos that ClickOnce relies on. This will lead to applications failing to install with pretty much useless error messages.
Granted, this 60/40 blame security software/clickonce, but it was a complaint nonetheless.
Is there a standalone installer? I am behind a proxy and the installer doesn't seem to get along with Tunnelier.
14:32:19.309 (unrecognized proxy protocol) connection from 127.0.0.1:3743 failed: Unsupported client protocol; the client may be expecting a regular HTTP proxy.
New to GIT - been using it only about four months. Using Windows 7 as my dev machine. I found learning the command line to not be too bad and haven't even really used the GUI toosl bundled with Msysgit. But I think I'm going to LOVE using this.
Awesome tool, but I think it shows once more the terrible state of SSH in the Windows world. It's scandalous how MS refuses to make it a first-class citizen on the platform -- it should come pre-installed and pre-configured, or at least with a config wizard, and have simple APIs for third-party apps.
Considering how MS are not really pushing a competitor, I don't understand why they refuse to add such a simple thing. RDP is a completely different tool, and anyway it's not really something you'd expose on the internet, so I don't understand why they can't just integrate OpenSSH -- it's not even GPL!
I'm strangely reminded of when people said that Android support would kill Instagram, because of their inferior cameras. (Don't shoot me. I'm an Android user of Instagram.)
It's great - one downside though: it has added a Github folder in "My Documents" that I can't seem to delete. I hate when unwanted folders pop in like that.
It was pretty easy to go into the Options and change the default folder, for instance, I have a /git/ folder at the root of my drive with my repos in it.
Nice to see this happen. Though Git Bash running on mingw32 actually is very handy, TortoiseGit also does a great job. But it is also good to have options.
Really cool. Looking forward when it will also will allow me to track Issues there.
One problem that is rendering it unusable for me atm though is that it tells me that files contain changes that have not been touched and if I try to discard those changes it actually has no effect. Wanted to report it but found no way to do so on the GitHub for Windows page.
I also have this problem. I let it commit and push the commit just to see what would happen and the commit seems to have deleted and then re-added my files. Even after cloning a repository it wants me to make a commit like this. Afterwards it seems to work as expected though.
I had this problem on Mac as well which is why I used it for all of 15 minutes before giving up. My colleague tried it against my recommendations and before the end of the day he experienced the same thing.
A part of me wants to cry, yet I was an early user of WinCVS back in the day, due to workplace requirements. I know I will reluctantly be an early adopter of this, as well, since GitHub is the cat's meow :)
This is good to see some better abstraction for non-experts. While I much prefer the command line interface, guis are a phenomenal way to introduce someone to the "better way". Now we just need good guis!
Is the app opensource? Looks really nice and I thing it would be great learning app for the c# libraries you used, e.g. to see how you use the reactive extensions..
I would like the ability to add multiple folders to the path where it looks for local git repositories. For various reasons, I have repositories clustered in a few different spots on my drive. I tried to use the Windows Libraries, but as expected, it wanted a directory.
Funny how most git users out there (at least according to the git user's survery 2011 [1]) use Linux, yet github seems to go out of its way not to build a tool for its majority of users. I would also go as far as to extrapolate and state that most github users are Linux users (which is true for every programmer I know on github).
Would it have been that hard to just use Qt and build a cross platform tool? Or is that not hipster-friendly enough?
I guess it's cool to profit, not that cool to give back. I wouldn't use their tool anyway but I think they're assholes on this one.
Instead of building for the existing community, they are trying to expand the toolset to "seduce" other communities. Both are perfectly worthy goals. Just different.
The tool for Linux users already exists: it's git itself. Demand for a desktop GUI in the Linux world is almost zero for basically everything, but especially so for a tool like git with no external dependency.
As a developer, I feel obligated to disagree with anything Windows. I'd honestly rather force people to use Linux or OSX than windows. I'd go so far as to say I would totally exclude Windows users entirely and that I support attempts to make it more difficult for a Windows user to use something.
Thanks for the reminder. I was responding to your comment about "intelligence of the user". My point is that, while it is a metric you can compete on, it's not a particularly meaningful one.
I got flamed a month ago [1] for noting how difficult it is to get up and running on GitHub in the Windows world, where things like generating SSH keys aren't exactly part of the daily routine. Glad to hear that they were listening.
[1] http://news.ycombinator.com/item?id=3871699