It used to be the case that scientists had a good theory about what weather there would be in different seasons, and this theory was usually right. They couldn't predict daily weather all that well, but they could predict that you could reasonably grow oranges in Florida without worrying about it being colder than Maine for a week and snowing a month later, and they could tell you that there would be snow in Vancouver and not in Dallas.
Now conditions are outside the boundaries that climate models are based on, and scientists really have no clue any more. And it's not just the scientific climate models that don't apply; common sense and experience are no longer relevant, because we don't have history that tells us what happens in this environment, measured, anecdotal, or otherwise. In all of our past experience, the arctic wind has blown eastwards around the pole. Then one year it blows across the pole into Europe. Two years later, it blows across the pole into North America. Is this going to be a regular occurrence? Nobody knows.
The extent to which climate change has a falsifiable hypothesis, it is rejecting the null hypothesis. That is, you can ask: is the environment now following the patterns we have previously observed? We find that we are observing patterns that we had not observed previously, including some that we would have noticed had they occurred in a substantial time period. On the other side, we've previously been able to demonstrate enough of an understanding of climate to know how to build houses and what crops to plant where. But the evidence that you should build houses in Florida to keep heat out and houses in Maine to keep heat in is getting less certain. The issue is not that scientists know that something bad is going to happen, it's that nobody has any clue if something bad is going to happen, even after taking into account that some bad things never happened before, because the situation is just different in some measurable ways.
Personally, my guess is that the planet has major negative feedback, or it wouldn't have stayed in a reasonably narrow range of climates long enough for life to get this far. More greenhouse gasses in the atmosphere will trigger more cooling by some other mechanism, which might be okay or might be all of the continents turning into highly-reflective deserts instead of light-absorbent arable land. We really can't make an accurate prediction.
There's got to be a significant correlation between having the seasonal flu vaccine recommended for you, and being exposed to swine flu. Surely we should expect that people who choose to get seasonal flu shots do so in part because they're more likely than average to come down with the flu if they don't get a vaccine. Being at high risk for exposure to the flu is a clear mediating factor in leading to both getting every available flu shot and coming down with any strain that goes around that there isn't a vaccine for.
To put it another way, we vaccinate some people go keep them from spreading the flu. If there's a link between getting the vaccine and getting the flu if you don't get the vaccine, then we're vaccinating the right people, and we should go on vaccinating them. (But it's worth making sure people know that they can't act like they're immune to the flu this year.)
Of course, the study could have found an actual danger to the vaccine, but we can't tell until the peer review is complete; peer review is where people will come to some sort of consensus on what the risk is that this value should be compared to.
That's why there's a legal system to which the two parties present their evidence before a judgement is rendered. If this guy can actually present the evidence he says (here) he has, he should win in court. If he's lying here, he should still go to court, and lose big. (Or, more likely, they should go to court-backed mediation, where they can show their evidence to a mediator who can make a decision if it's obvious and make it stick if they both accept it.)
He makes a good point about the weird Ubuntu version scheme: a new user is likely to think that you could update from version 8.04 to 8.10 as a ordinary incremental change. But an expert would know that 8.04 and 8.10 are actually dates ('08.April and '08.October), and everybody actually calls them Hardy and Intrepid whenever they're saying anything that might be useful information. For that matter, the recent code names actually tend to give accurate suggestions about the sort of release it will be, with the LTS one suggesting robustness and the others suggesting ambition of various sorts. (Are you sure you want to move from something Hardy to something Intrepid? On the one hand, you get new stuff; on the other hand, it won't live as long)
$ host www.whitehouse.gov www.whitehouse.gov is an alias for www.whitehouse.gov.edgekey.net. www.whitehouse.gov.edgekey.net is an alias for e2561.b.akamaiedge.net.
Reducing their bandwidth and server load is just not a big deal. (See Akamai and note that the whole site takes the path that the "image" request takes in that diagram.)
You don't need to update at all until you're done with your branch. If there were any benefit to updating regularly, you could get exactly the same effect at the end by rebasing a dozen times against progressively newer commits in the upstream history. The exception, of course, is if someone has done something you want to use, but you can just update to the point you require. SVN doesn't have a command for "updating all the way is too hard, update only a little bit at a time", which gets people in the habit of updating all the time.
If this is your whole workflow, you shouldn't have any of your own changes on the master branch (except, of course, when you send out your work branch and then get it back in the next pull), so you shouldn't need to fix anything there; in fact, the "pull" should just say "fast-forward" and give you exactly what is in the main repository. In fact, you can skip having a master branch at all, and just rebase against "origin/master" (which is the state of the main repository the last time you looked).
You should use "git commit" all the time. Until you push, you can revise commits after you make them. As soon as you've done any work you wouldn't want to redo, commit it. Then use "git commit --amend" when you do more. Eventually, do another amend to write a real message, inspect the change with "git show", then fetch, rebase, make sure you still like it, and then push.
I generally work with two branches, one which contains just whatever I've written as I write it, with tons of commits with the message "more stuff" or "fixes", and the other formed by getting a diff between origin and the junk branch and applying only those parts that are actually all one logical change and all good, and committing it with a good message. I repeat this until my good branch contains everything worthwhile, and then I dump the branch that's only got unneeded debugging statements, whitespace changes, and so forth.
For that matter, why should Red Hat fund development on the sorts of thing that Alan Cox works on, if hardware vendors are willing to fund it? Intel can even get developers internal documentation and (most importantly) face time with hardware designers who can explain things that they didn't think to document (or that they documented in a huge specification that's too big to find the little detail in).
There's no reason for Red Hat to have a collection of kernel developers working on stuff that Red Hat doesn't need more than anybody else does.
I think you're missing the fact that the Wiimote is sufficiently different from other systems' controllers that most games released for both of them will be terrible on one or the other. Trying to sell to the massive Wii install base isn't going to be easy if you're trying to compete with games that are less awkward and more fun on the Wii.
On the other hand, there's no reason there couldn't be a good Wii GTA, except that it would be much more disturbing than other console versions. In ordinary GTA games, your character does all sorts of bad things while you sit around pushing buttons on a controller. In a proper Wii version, you'd be miming doing the bad things yourself, which will seem a whole lot worse.
I'd actually say that the US needs a CTO, who would be responsible for identifying the most promising technologies to subsidize the development of. Someone who can look at the range of technologies that are under development, and decide whether it makes sense to go for more efficient production of renewable hydrocarbon fuels for cars and fuel-efficient hybrids, or whether we'd do better to produce more electricity in the midwest, transport it as compressed hydrogen gas, turn it back into electricity in the high-population areas, and drive plug-in electrics. And are we going to use enough more oil to make it worthwhile to put research into cleaner and safer processing, or should we focus on not using it in the first place? OSHA, the EPA, and the DoE each have their own priorities, and there isn't anyone in the position to find a balance between them and get useful things done.
On the other hand, the government needs someone to fix the government's information technology problems, which is an entirely different job, and seems to be what Obama's looking for. I'm not sure why this post isn't called "Secretary of Information Technology", actually, which would be more in line with other executive branch government posts and distinguish clearly between the two possible job descriptions.
You don't like "Funky Weasel is Jiggy wit it"? Or "Rotary Wombat"? Or "Killer Bat of Doom"? Sure, they don't change every release, and they don't get used anywhere at all, but they're more frequently changed and more... creative... than Windows version names.
The problem with simple manual counting is actually that a significant number of ballots will be spoiled as cast. That is, there will be lots of ballots marked in such a way that the counters will disagree over what the voter intended. And, furthermore, there will be cases were the ballot design, intentionally or otherwise, will lead more voters who want to cast one particular vote to spoil their ballots than some other particular vote, meaning that discarding the spoiled ballots will favor one option over another.
This comes down to the fact that, after the ballot is separated from the voter, it is too late to get the voter to fix anything, but before the ballot is separated from the voter, anonymity requires that nobody else see it. Machines can solve this by examining the ballot and making sure that it is clear before the voter leaves.
The other problem is that blind people have the right to vote, and can't use pen and paper effectively without human assistance. And they have the right to have an anonymous ballot, even the only blind voter at that polling place.
Actually, it's more than that. Having multiple people working at the same time on different computers requires branching (to put a version on each computer with its own state) and merging (to generate a consensus version). What "svn update" does is a merge (it even uses the "merge" program from rcs-utils). What git is very good at is being able to have tons of these branches for a single developer, with almost no cost in either space or time. It's also good at protecting the work you do on one of these branches, and good at letting you make pristine commits out of the changes you've done on a branch, so that the history comes out clean and informative.
As an example, I have a personal project where the current history is almost entirely linear, with the exceptions being ~6 cases (in several years) where changes were made for use in different applications at the same time; once I had 3 parallel threads, but otherwise I've only ever had at most two, and by far the most common width is 1. On the other hand, I do this development in a repository with about 20 branches, each with some work I've started and then decided I wasn't happy with its current state but I didn't want to discard it. As I go back to working on those topics, I rebase on the latest version, and then I improve the code until I think the final state is good, and then I generate a clear series of changes to get there, which is what I push to the main repository.
Having your repositories in some random directory on a file share that other people can read from is actually the ideal situation for git. The options for servers are really (in decreasing order of niceness): some filesystem that some people can write to and more people can read from; such a filesystem on a machine people can ssh to; anonymous read access with a special server program (and one of the other options for writing); some web space that people can read from on a system writers can ssh to; WebDAV.
For example, Linux kernel development is largely around the web-served and mirrored subdirectories of people's home directories on master.kernel.org, with the git daemon running to provide efficient anonymous read access for non-core-developers.
I wouldn't be surprised if, for most operations, git is faster on Windows than SVN is. The secret is to avoid ever using git on Linux, because then you'll find pretty much any other combination (except, perhaps, Mercurial on Linux, which has similar performance characteristics) unusably slow. Also, git's performance problems on Windows are gradually improving as operations that are okay on Linux and terrible on Windows are replaced with operations that are slightly better on Linux and okay on Windows. There is, however, a fundamental performance problem with Windows, which is that the hot-cache case of verifying that none of the files in a large directory tree have been modified takes a noticeable amount of time on Windows, so any operation that requires noticing changes to the checked-out state is going to be slow. Which is to say, on Windows, you'll never be able to make 100 commits in under a second, at least if you go through the working tree.
Game engines are one of the cases where you'd want to know calculus, but that's for the physics, not for the programming. And really, you want to forget your calculus and just look up the right ways to do things, because if you just use calculus, you'll right something theoretically good but unstable due to rounding, which will tend to go crazy if stars align right.
I agree that it's worth finding out things that aren't actually useful (I recently worked out cos(i) within 10% in my head, in the process refreshing the necessary math I'd forgotten, just because I was curious). But there's no need to learn particular non-useful things if they don't happen to interest you at the time.
The current worldwide crisis isn't really a subprime mortgage crisis. There are a number of things going on: (1) "netted out credit default swaps" all over the place. These are a normally-low-risk and popular investment which pays you for some arbitrary company's bankruptcy insurance premiums going up; oh, and if the company (Lehman Brothers) does go bankrupt, and the original insurer (AIG) also goes bankrupt, so do you (everybody else). Oops. But that's so unlikely as to not get into the models. (2) Banks have to believe that other banks aren't going to go out of business in the next day before they'll be able to function. They don't have any way to estimate this risk; under normal circumstances, it's unlikely enough to ignore, but these days they're worried. (3) Nobody is interested in any single credit investment, because it's too small and particular and too risky individually; they deal in CDOs, which have unrelated investments smoothed out, and are set up to pay out a predictable amount each day for the next 30 years, and they're still working normally (paying out only a little less, if that). But it used to be that, if you needed more money today, you could sell your share to somebody else, but buyers are freaked out and not buying. Lots of entities have shares of CDOs that they expected to be able to sell as needed. Imagine if you had a savings account that paid 4% interest into your checking account, and one day it paid 3.95% interest, and the next day you couldn't take money out of it, but it kept paying interest into your checking account. Oh, and you'd put next month's rent in savings until you needed it.
The worldwide credit crisis is due to the fact that the worldwide system only works if everybody expects all the big players to still be around in 3 months. The subprime mortgage crisis is a small and localized failure, but it made a big player collapse, and there's not enough transparency to allow anybody to trust any of the other big players with this precedent, and big players need to work together or they starve.
I think calculus is, among branches of mathematics, one of the less useful for computer programming. Computers are discrete systems, and either need to use approximations for using calculus or need to use something else. Graph theory, field theory, algebra of all sorts, and (obviously) computation theory are all more applicable to general computer programming problems. Calculus and computer programming mainly only go together when you're trying to make a computer solve problems that can be best modeled with calculus; and it's always the case that it's helpful to have domain knowledge when implementing something.
Of course, calculus is very useful for a lot of other fields, including ones as related as electrical engineering. (Unless, of course, you include as "calculus" things that are unrelated to calculus except in name and the Latin root; the lambda calculus is good to understand if you're a programmer, so that you can precisely communicate programming language behavior, but that's only related to calculus in that it's a set of symbols and manipulation rules which models an abstract mathematical concept.)
With a solid state drive the cost factor between RAM and "disk" is less extreme. Think of it this way: the same amount of RAM is definitely better than swap, if you could afford to triple your memory. The cost of SSD is such that, if you can afford that much SSD, you can nearly afford it as RAM, and the RAM will behave better. Think of the EEE as having 256M of RAM, with another 768M of RAM as fast, no-wear swap (other system features are more in line with a 256M machine than a 1G machine).
For your desktop PC, it's relatively hard to use up 4G of RAM unless you've either got a 64-bit userspace or are doing a lot at a time, because programs only have ~3G of virtual address space (each) available. This means that you're going to have a relatively hard time generating memory pressure (of course, the kernel will fill up the 4G with stuff from disk that you're pretty likely to want fast access to, so it's not wasted, but the kernel is unlikely to do into swap instead of dropping cache at that point).
Have you ever tried to prove the properties of arithmetic? It's not hard, but it's tedious if you're starting from minimal definitions and have to prove that those definitions lead to the familiar properties. That is to say, bothering to prove those statements is not much less work in English than that, and people generally just don't have to do it, because it's already well established. But, of course, it's in the standard library for the prover, so you don't have to do it for the prover, either.
It's just like their instant delivery service, available for items that you've put on your wish list in advance. The way it works is that, when you put an item on your wish list, they ship it to you. Then, if you buy it, they give you the tracking number, you go to the shipper's site, and find that the item is on your porch, at which point you bring it inside and open it. If you don't buy it, eventually the shipper notices that it's been sitting on your porch for a while unclaimed and brings it back to Amazon.
Pen and paper is really quick, but it's a lousy text editor. I make notes for myself on chopstick wrappers on my desk, and I keep trying to copy text from them to other windows by pointing the mouse pointer at them and selecting the text, and it never works.
Just go to about:config and set "browser.urlbar.matchOnlyTyped" to true, and start your porn browsing from a URL that doesn't look too interesting. It'll incidentally only suggest plausible URLs that you might actually want to select when you set it like that.
Call up your bank and get their certificate fingerprint. Compare it against the fingerprint of the certificate you get from the site. If they match, either the site is safe, or your bank is hopeless. Just because somebody's managed to convince a CA to issue a cert to them for www.mybank.com.su and their site looks just like your bank's site doesn't mean it's actually your bank. For all you know, you've made a typo and you're giving your info to some Russian cybercriminal. Or, for that matter, somebody could have subverted your DNS to redirect you from the right domain to a similar looking domain for which they got a CA-signed certificate. CA's only check (if they check anything) that the person is who they say they are; they can't check that the person is who you'll think they are, because they don't know how you could be misled. That's why the only way to be really safe is to verify the certificate by means of the relationship you have with the owner.
In order to make the chips easier to design, they decided to standardize the size and shape of their functional components to one of two squares. Sure, the UART wastes some space, but it avoids the need to come up with a funny-shaped peripheral to go next to it. It's like why the AT91SAM7X has the same size MMIO space for the ethernet and for the reset controller.
Actually, the real reason is that, if the UART were smaller, it wouldn't cover up enough of the secret design in the next layer down, which you can see (but only tantalizing bits, nothing useful) around those blocks.
Slashdot Mirror
It used to be the case that scientists had a good theory about what weather there would be in different seasons, and this theory was usually right. They couldn't predict daily weather all that well, but they could predict that you could reasonably grow oranges in Florida without worrying about it being colder than Maine for a week and snowing a month later, and they could tell you that there would be snow in Vancouver and not in Dallas.
Now conditions are outside the boundaries that climate models are based on, and scientists really have no clue any more. And it's not just the scientific climate models that don't apply; common sense and experience are no longer relevant, because we don't have history that tells us what happens in this environment, measured, anecdotal, or otherwise. In all of our past experience, the arctic wind has blown eastwards around the pole. Then one year it blows across the pole into Europe. Two years later, it blows across the pole into North America. Is this going to be a regular occurrence? Nobody knows.
The extent to which climate change has a falsifiable hypothesis, it is rejecting the null hypothesis. That is, you can ask: is the environment now following the patterns we have previously observed? We find that we are observing patterns that we had not observed previously, including some that we would have noticed had they occurred in a substantial time period. On the other side, we've previously been able to demonstrate enough of an understanding of climate to know how to build houses and what crops to plant where. But the evidence that you should build houses in Florida to keep heat out and houses in Maine to keep heat in is getting less certain. The issue is not that scientists know that something bad is going to happen, it's that nobody has any clue if something bad is going to happen, even after taking into account that some bad things never happened before, because the situation is just different in some measurable ways.
Personally, my guess is that the planet has major negative feedback, or it wouldn't have stayed in a reasonably narrow range of climates long enough for life to get this far. More greenhouse gasses in the atmosphere will trigger more cooling by some other mechanism, which might be okay or might be all of the continents turning into highly-reflective deserts instead of light-absorbent arable land. We really can't make an accurate prediction.
There's got to be a significant correlation between having the seasonal flu vaccine recommended for you, and being exposed to swine flu. Surely we should expect that people who choose to get seasonal flu shots do so in part because they're more likely than average to come down with the flu if they don't get a vaccine. Being at high risk for exposure to the flu is a clear mediating factor in leading to both getting every available flu shot and coming down with any strain that goes around that there isn't a vaccine for.
To put it another way, we vaccinate some people go keep them from spreading the flu. If there's a link between getting the vaccine and getting the flu if you don't get the vaccine, then we're vaccinating the right people, and we should go on vaccinating them. (But it's worth making sure people know that they can't act like they're immune to the flu this year.)
Of course, the study could have found an actual danger to the vaccine, but we can't tell until the peer review is complete; peer review is where people will come to some sort of consensus on what the risk is that this value should be compared to.
That's why there's a legal system to which the two parties present their evidence before a judgement is rendered. If this guy can actually present the evidence he says (here) he has, he should win in court. If he's lying here, he should still go to court, and lose big. (Or, more likely, they should go to court-backed mediation, where they can show their evidence to a mediator who can make a decision if it's obvious and make it stick if they both accept it.)
He makes a good point about the weird Ubuntu version scheme: a new user is likely to think that you could update from version 8.04 to 8.10 as a ordinary incremental change. But an expert would know that 8.04 and 8.10 are actually dates ('08.April and '08.October), and everybody actually calls them Hardy and Intrepid whenever they're saying anything that might be useful information. For that matter, the recent code names actually tend to give accurate suggestions about the sort of release it will be, with the LTS one suggesting robustness and the others suggesting ambition of various sorts. (Are you sure you want to move from something Hardy to something Intrepid? On the one hand, you get new stuff; on the other hand, it won't live as long)
$ host www.whitehouse.gov
www.whitehouse.gov is an alias for www.whitehouse.gov.edgekey.net.
www.whitehouse.gov.edgekey.net is an alias for e2561.b.akamaiedge.net.
Reducing their bandwidth and server load is just not a big deal. (See Akamai and note that the whole site takes the path that the "image" request takes in that diagram.)
You can probably simplify the git workflow a lot.
You don't need to update at all until you're done with your branch. If there were any benefit to updating regularly, you could get exactly the same effect at the end by rebasing a dozen times against progressively newer commits in the upstream history. The exception, of course, is if someone has done something you want to use, but you can just update to the point you require. SVN doesn't have a command for "updating all the way is too hard, update only a little bit at a time", which gets people in the habit of updating all the time.
If this is your whole workflow, you shouldn't have any of your own changes on the master branch (except, of course, when you send out your work branch and then get it back in the next pull), so you shouldn't need to fix anything there; in fact, the "pull" should just say "fast-forward" and give you exactly what is in the main repository. In fact, you can skip having a master branch at all, and just rebase against "origin/master" (which is the state of the main repository the last time you looked).
You should use "git commit" all the time. Until you push, you can revise commits after you make them. As soon as you've done any work you wouldn't want to redo, commit it. Then use "git commit --amend" when you do more. Eventually, do another amend to write a real message, inspect the change with "git show", then fetch, rebase, make sure you still like it, and then push.
I generally work with two branches, one which contains just whatever I've written as I write it, with tons of commits with the message "more stuff" or "fixes", and the other formed by getting a diff between origin and the junk branch and applying only those parts that are actually all one logical change and all good, and committing it with a good message. I repeat this until my good branch contains everything worthwhile, and then I dump the branch that's only got unneeded debugging statements, whitespace changes, and so forth.
How can you not mention a line that starts "chomp(my $HEAD..."?
For that matter, why should Red Hat fund development on the sorts of thing that Alan Cox works on, if hardware vendors are willing to fund it? Intel can even get developers internal documentation and (most importantly) face time with hardware designers who can explain things that they didn't think to document (or that they documented in a huge specification that's too big to find the little detail in).
There's no reason for Red Hat to have a collection of kernel developers working on stuff that Red Hat doesn't need more than anybody else does.
I think you're missing the fact that the Wiimote is sufficiently different from other systems' controllers that most games released for both of them will be terrible on one or the other. Trying to sell to the massive Wii install base isn't going to be easy if you're trying to compete with games that are less awkward and more fun on the Wii.
On the other hand, there's no reason there couldn't be a good Wii GTA, except that it would be much more disturbing than other console versions. In ordinary GTA games, your character does all sorts of bad things while you sit around pushing buttons on a controller. In a proper Wii version, you'd be miming doing the bad things yourself, which will seem a whole lot worse.
I'd actually say that the US needs a CTO, who would be responsible for identifying the most promising technologies to subsidize the development of. Someone who can look at the range of technologies that are under development, and decide whether it makes sense to go for more efficient production of renewable hydrocarbon fuels for cars and fuel-efficient hybrids, or whether we'd do better to produce more electricity in the midwest, transport it as compressed hydrogen gas, turn it back into electricity in the high-population areas, and drive plug-in electrics. And are we going to use enough more oil to make it worthwhile to put research into cleaner and safer processing, or should we focus on not using it in the first place? OSHA, the EPA, and the DoE each have their own priorities, and there isn't anyone in the position to find a balance between them and get useful things done.
On the other hand, the government needs someone to fix the government's information technology problems, which is an entirely different job, and seems to be what Obama's looking for. I'm not sure why this post isn't called "Secretary of Information Technology", actually, which would be more in line with other executive branch government posts and distinguish clearly between the two possible job descriptions.
You don't like "Funky Weasel is Jiggy wit it"? Or "Rotary Wombat"? Or "Killer Bat of Doom"? Sure, they don't change every release, and they don't get used anywhere at all, but they're more frequently changed and more... creative... than Windows version names.
The problem with simple manual counting is actually that a significant number of ballots will be spoiled as cast. That is, there will be lots of ballots marked in such a way that the counters will disagree over what the voter intended. And, furthermore, there will be cases were the ballot design, intentionally or otherwise, will lead more voters who want to cast one particular vote to spoil their ballots than some other particular vote, meaning that discarding the spoiled ballots will favor one option over another.
This comes down to the fact that, after the ballot is separated from the voter, it is too late to get the voter to fix anything, but before the ballot is separated from the voter, anonymity requires that nobody else see it. Machines can solve this by examining the ballot and making sure that it is clear before the voter leaves.
The other problem is that blind people have the right to vote, and can't use pen and paper effectively without human assistance. And they have the right to have an anonymous ballot, even the only blind voter at that polling place.
Actually, it's more than that. Having multiple people working at the same time on different computers requires branching (to put a version on each computer with its own state) and merging (to generate a consensus version). What "svn update" does is a merge (it even uses the "merge" program from rcs-utils). What git is very good at is being able to have tons of these branches for a single developer, with almost no cost in either space or time. It's also good at protecting the work you do on one of these branches, and good at letting you make pristine commits out of the changes you've done on a branch, so that the history comes out clean and informative.
As an example, I have a personal project where the current history is almost entirely linear, with the exceptions being ~6 cases (in several years) where changes were made for use in different applications at the same time; once I had 3 parallel threads, but otherwise I've only ever had at most two, and by far the most common width is 1. On the other hand, I do this development in a repository with about 20 branches, each with some work I've started and then decided I wasn't happy with its current state but I didn't want to discard it. As I go back to working on those topics, I rebase on the latest version, and then I improve the code until I think the final state is good, and then I generate a clear series of changes to get there, which is what I push to the main repository.
Having your repositories in some random directory on a file share that other people can read from is actually the ideal situation for git. The options for servers are really (in decreasing order of niceness): some filesystem that some people can write to and more people can read from; such a filesystem on a machine people can ssh to; anonymous read access with a special server program (and one of the other options for writing); some web space that people can read from on a system writers can ssh to; WebDAV.
For example, Linux kernel development is largely around the web-served and mirrored subdirectories of people's home directories on master.kernel.org, with the git daemon running to provide efficient anonymous read access for non-core-developers.
I wouldn't be surprised if, for most operations, git is faster on Windows than SVN is. The secret is to avoid ever using git on Linux, because then you'll find pretty much any other combination (except, perhaps, Mercurial on Linux, which has similar performance characteristics) unusably slow. Also, git's performance problems on Windows are gradually improving as operations that are okay on Linux and terrible on Windows are replaced with operations that are slightly better on Linux and okay on Windows. There is, however, a fundamental performance problem with Windows, which is that the hot-cache case of verifying that none of the files in a large directory tree have been modified takes a noticeable amount of time on Windows, so any operation that requires noticing changes to the checked-out state is going to be slow. Which is to say, on Windows, you'll never be able to make 100 commits in under a second, at least if you go through the working tree.
Game engines are one of the cases where you'd want to know calculus, but that's for the physics, not for the programming. And really, you want to forget your calculus and just look up the right ways to do things, because if you just use calculus, you'll right something theoretically good but unstable due to rounding, which will tend to go crazy if stars align right.
I agree that it's worth finding out things that aren't actually useful (I recently worked out cos(i) within 10% in my head, in the process refreshing the necessary math I'd forgotten, just because I was curious). But there's no need to learn particular non-useful things if they don't happen to interest you at the time.
The current worldwide crisis isn't really a subprime mortgage crisis. There are a number of things going on: (1) "netted out credit default swaps" all over the place. These are a normally-low-risk and popular investment which pays you for some arbitrary company's bankruptcy insurance premiums going up; oh, and if the company (Lehman Brothers) does go bankrupt, and the original insurer (AIG) also goes bankrupt, so do you (everybody else). Oops. But that's so unlikely as to not get into the models. (2) Banks have to believe that other banks aren't going to go out of business in the next day before they'll be able to function. They don't have any way to estimate this risk; under normal circumstances, it's unlikely enough to ignore, but these days they're worried. (3) Nobody is interested in any single credit investment, because it's too small and particular and too risky individually; they deal in CDOs, which have unrelated investments smoothed out, and are set up to pay out a predictable amount each day for the next 30 years, and they're still working normally (paying out only a little less, if that). But it used to be that, if you needed more money today, you could sell your share to somebody else, but buyers are freaked out and not buying. Lots of entities have shares of CDOs that they expected to be able to sell as needed. Imagine if you had a savings account that paid 4% interest into your checking account, and one day it paid 3.95% interest, and the next day you couldn't take money out of it, but it kept paying interest into your checking account. Oh, and you'd put next month's rent in savings until you needed it.
The worldwide credit crisis is due to the fact that the worldwide system only works if everybody expects all the big players to still be around in 3 months. The subprime mortgage crisis is a small and localized failure, but it made a big player collapse, and there's not enough transparency to allow anybody to trust any of the other big players with this precedent, and big players need to work together or they starve.
I think calculus is, among branches of mathematics, one of the less useful for computer programming. Computers are discrete systems, and either need to use approximations for using calculus or need to use something else. Graph theory, field theory, algebra of all sorts, and (obviously) computation theory are all more applicable to general computer programming problems. Calculus and computer programming mainly only go together when you're trying to make a computer solve problems that can be best modeled with calculus; and it's always the case that it's helpful to have domain knowledge when implementing something.
Of course, calculus is very useful for a lot of other fields, including ones as related as electrical engineering. (Unless, of course, you include as "calculus" things that are unrelated to calculus except in name and the Latin root; the lambda calculus is good to understand if you're a programmer, so that you can precisely communicate programming language behavior, but that's only related to calculus in that it's a set of symbols and manipulation rules which models an abstract mathematical concept.)
With a solid state drive the cost factor between RAM and "disk" is less extreme. Think of it this way: the same amount of RAM is definitely better than swap, if you could afford to triple your memory. The cost of SSD is such that, if you can afford that much SSD, you can nearly afford it as RAM, and the RAM will behave better. Think of the EEE as having 256M of RAM, with another 768M of RAM as fast, no-wear swap (other system features are more in line with a 256M machine than a 1G machine).
For your desktop PC, it's relatively hard to use up 4G of RAM unless you've either got a 64-bit userspace or are doing a lot at a time, because programs only have ~3G of virtual address space (each) available. This means that you're going to have a relatively hard time generating memory pressure (of course, the kernel will fill up the 4G with stuff from disk that you're pretty likely to want fast access to, so it's not wasted, but the kernel is unlikely to do into swap instead of dropping cache at that point).
Have you ever tried to prove the properties of arithmetic? It's not hard, but it's tedious if you're starting from minimal definitions and have to prove that those definitions lead to the familiar properties. That is to say, bothering to prove those statements is not much less work in English than that, and people generally just don't have to do it, because it's already well established. But, of course, it's in the standard library for the prover, so you don't have to do it for the prover, either.
It's just like their instant delivery service, available for items that you've put on your wish list in advance. The way it works is that, when you put an item on your wish list, they ship it to you. Then, if you buy it, they give you the tracking number, you go to the shipper's site, and find that the item is on your porch, at which point you bring it inside and open it. If you don't buy it, eventually the shipper notices that it's been sitting on your porch for a while unclaimed and brings it back to Amazon.
Pen and paper is really quick, but it's a lousy text editor. I make notes for myself on chopstick wrappers on my desk, and I keep trying to copy text from them to other windows by pointing the mouse pointer at them and selecting the text, and it never works.
Just go to about:config and set "browser.urlbar.matchOnlyTyped" to true, and start your porn browsing from a URL that doesn't look too interesting. It'll incidentally only suggest plausible URLs that you might actually want to select when you set it like that.
Call up your bank and get their certificate fingerprint. Compare it against the fingerprint of the certificate you get from the site. If they match, either the site is safe, or your bank is hopeless. Just because somebody's managed to convince a CA to issue a cert to them for www.mybank.com.su and their site looks just like your bank's site doesn't mean it's actually your bank. For all you know, you've made a typo and you're giving your info to some Russian cybercriminal. Or, for that matter, somebody could have subverted your DNS to redirect you from the right domain to a similar looking domain for which they got a CA-signed certificate. CA's only check (if they check anything) that the person is who they say they are; they can't check that the person is who you'll think they are, because they don't know how you could be misled. That's why the only way to be really safe is to verify the certificate by means of the relationship you have with the owner.
In order to make the chips easier to design, they decided to standardize the size and shape of their functional components to one of two squares. Sure, the UART wastes some space, but it avoids the need to come up with a funny-shaped peripheral to go next to it. It's like why the AT91SAM7X has the same size MMIO space for the ethernet and for the reset controller.
Actually, the real reason is that, if the UART were smaller, it wouldn't cover up enough of the secret design in the next layer down, which you can see (but only tantalizing bits, nothing useful) around those blocks.