I'd be willing to posit that if you can afford to pay at the highest level then you can get the highest level of care. According to the New York Times though the USA doesn't provide the highest-qualtiy health care in all areas:

http://www.nytimes.com/2007/08...

Not sure what you're smoking. Canada has quite a healthy private health care industry:
http://www.cbc.ca/news2/backgr...

Most of the time a sore throat isn't something you need to see a doctor about:
http://www.mayoclinic.org/dise...

In Canada we have a free healthcare phone number that you can call and talk to a Registered Nurse. They'll ask questions and clarify whether or not you should even both going in to see a doctor.

Sure I can. I can call up my family doc and book an appointment (generally within 1 week), or if I don't want to wait that long I can go to the local clinic and wait for the on-call doc to see me, or if it's really serious I can go to Emergency at the hospital.

Now if you want to see a specialist then you might be waiting a while. But if the GP thinks your case is serious then they'll bump you further up the queue, and if it's really serious they can generally get you in right away.

The biggest failing is in highly specialized stuff like pediatric psychiatry, or health care for really remote areas, but I suspect that would be an issue under most forms of health care.

Technically 5.1 is out and there's supposed to be an update coming for my Moto G, but it hasn't arrived yet. Arguably this is Moto's fault more than Google's.

That said, from what I hear Android 5.0 wasn't all that stable, so it seems likely that a lot of manufacturers just skipped it in favour of waiting for 5.1.

It's *beautiful* for simulating a cluster on a single machine.

Could they have still gone after people in court?

I mean, copyright infringement did happen. Or does the fact that they seeded the files mean that they can't go after anyone else for distributing the files?

My high school calculus teacher observed that the marks for that class over decades of teaching tended towards bimodal. To some extent, either you "got it" or you didn't.

This post (https://gasstationwithoutpumps.wordpress.com/tag/bimodal-distribution/) based on USA stats for 2010 suggests that "many of the exams that require math had this sort of bimodal distribution."

Even at 10K/round that wouldn't be crazy compared to the cost of training the sniper and getting them in and out of the area.

Now try it ten feet away from a 120" projector screen. (Or 2 feet away from a 24" monitor, which is the same relative size.)

Linux internal APIs get changed from time to time. Drivers that are part of the kernel tree get updated by whoever is changing the API. Drivers that are outside the kernel tree have to be updated to work with the API changes.

I've had my distro ship a new kernel and then had to wait weeks for the Nvidia driver to be updated. (Admittedly they're getting better at it, but it has happened.)

The rule against using rebase really only applies if you are publishing your git repo (and specifically the branch in question) to other people.

The reason for the rule is that if you rebase your changes on top of the latest upstream, anyone pulling in your branch is then forced to rebase as well since you've essentially rewritten history. (Doing a rebase changes the hashes on all your local commits.) If you instead merge upstream work onto your local branch then your history is preserved and everyone downstream from you can also just do a merge.

However, for any development branch that you are not exporting to other people, "git rebase" is a very useful tool to keep your own development at the tip of your local development branch. When other people push changes you can pull them in and rebase your work on top of theirs.

I *never* do development on an upstream branch. So instead of the above I would always checkout the local "master" branch, do a "git pull", then checkout my development branch and rebase my work on top of the latest local "master" branch.

The nice thing about this is that the local "master" branch is always identical to some version of the upstream "master" branch, I never need to worry about it getting polluted with my development work.

I prefer the model where the "master" branch is the continuous trunk of development. When you want to release, you branch off for that release.

Functionally equivalent, but has the nice property that most stuff goes into "master" and only bugfixes/backports or special-case stuff goes onto the release branch.

In git a "branch" is literally a mapping between a name and the commit ID of the commit at the head of the branch. If you've merged your commit into the main development trunk (submitting the bugfix) there is essentially zero overhead to keeping the branch around in your repository.

Some CI systems have a mechanism where you create what you think will be the fix, then push it up to a common area for testing, review, etc. Then you respin your fix based on feedback, send it back in. Rinse, wash, repeat until everyone is satisfied, then merge for real. In that sort of environment it can be handy to have one local branch per bug that you're working on.

So one branch per bug you're working on, one branch per feature you're working on, one branch per released version, etc. I just checked and one local git repo I'm working on is sitting at around 40 local branches currently.