Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Comment: I would qualify that... (Score 1) 457

by Chirs (#49630843) Attached to: The Medical Bill Mystery

Our medical care is second to none in quality and capability.

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...

Comment: I usually wouldn't bother for a sore throat (Score 1) 457

by Chirs (#49630739) Attached to: The Medical Bill Mystery

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.

Comment: another Canadian begs to differ (Score 1) 457

by Chirs (#49630691) Attached to: The Medical Bill Mystery

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.

Comment: Is this Google's fault? (Score 1) 395

by Chirs (#49625035) Attached to: Google Can't Ignore the Android Update Problem Any Longer

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.

Comment: calculus (Score 1) 409

by Chirs (#49622951) Attached to: The Programming Talent Myth

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."

Comment: Sure there is... (Score 1) 309

by Chirs (#49492945) Attached to: NVIDIA's New GPUs Are Very Open-Source Unfriendly

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.)

Comment: "don't use rebase" only applies in some cases (Score 1) 203

by Chirs (#49420225) Attached to: 10 Years of Git: An Interview With Linus Torvalds

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.

Comment: I prefer separate pull/rebase steps (Score 1) 203

by Chirs (#49420213) Attached to: 10 Years of Git: An Interview With Linus Torvalds

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.

Comment: I prefer continuous trunk... (Score 1) 203

by Chirs (#49420191) Attached to: 10 Years of Git: An Interview With Linus Torvalds

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.

Comment: a "branch" is just a name pointing to a commit (Score 1) 203

by Chirs (#49420177) Attached to: 10 Years of Git: An Interview With Linus Torvalds

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.

Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth

Working...