The main practical difference, past the API, is their approach to branching: A git branch is a mercurial bookmark. There are no concept like mercurial's branch in git.
As a git user, I've done a bit of reading about Hg branches. The difference seems to be pretty much "the name of the branch is stored permanently with the commit." Is that it, or is there more?
(The "is that it" is meant to be a question, not a dismissive value judgement.)
To minimize it, I keep telling people to avoid git pull like the plague, and instead use git fetch, followed by git rebase as the baseline case.
You probably know this, but you can git pull --rebase and still do it in one step. You could also add a config alias (e.g. git get or something) for that; heck, I'd bet $20 you can make --rebase the default for just git pull.
Or, you know, git rev-parse HEAD. Though I'll admit that doesn't address your "I have to run something" objection, at least it's a far cleaner command with less shell and quoting dependencies and issues.
stash pop would normally get rid of the stash after applying it, but even there the original stash is preserved if there were any merge conflicts.
I didn't know/forgot about that (in addition to confusing stash pop, which is what I virtually always use, and stash apply). Though I will point out that there can be conflicts other than textual ones.
For example, he randomly picked the word checkout to mean revert
That choice actually makes sense from the Git model. A Subversion person would ask why there is one command for three+ different things (svn revert, svn switch, svn up -r### are all done using git checkout). But if you turn your head around and look at it from a different perspective, all three of those are doing the same thing: copying something from the repository store to the working copy. From the Git perspective, Subversion is giving three different names to the same thing, each of which only works some of the time.
I don't want to argue Git is right, just that if it has a fault here, Git's is that its terms are at a lower level than users usually think and not that it's inconsistent on this point.
Ditto using the word reset to mean unstage.
Oh boy. The whole index is a mess of inconsistent terminology. You stage something to the index using git add, unless you're using git add --interactive in which case that process is called updating. And of course you see what the changes are in your index by using git diff --cached. Wut?
(Yes, I know, git diff --staged is now an alias for the last. Good, now all they have to do is deal with the three other synonyms for the same thing.)
"git pull" refuses to update the source like a normal system would. Instead you have to do the "git stash; git stash apply stash@{0}" dance
Here I also defend git, because I think this is a significant selling point. One major advantage that Git has is that once something is actually added to the store, it's nearly impossible to accidentally lose information. git stash adds the state to the store.
Compare to something like Subversion. Suppose you have a nice change. It's working properly. Now you svn up. Now you get a bunch of hard-to-resolve conflicts. You say "I don't want to deal with this now; I just want to go back to the state I was in before updating." Too bad, you can't (at least any way I know how). You're screwed, because Subversion has caused you to lose information.
Compare to git. You have to run stash before pulling (merging/rebasing technically of course), so now the state of the working copy right before the pull is in the store. You then stash apply. You get the conflicts, say "I give up for now". Now all you have to do is figure out what the SHA1 of the copy that was in the stash is. Might have to do some reflog digging, but it is not only possible but actually pretty easy if you know about the reflog.
The only reason I can come up with Gits popularity over Mercurial is that Linus wrote it.
You may be partly right. But I think a lot of it is that for a while, Git was a lot more "powerful" -- it supported some very useful modes of operation that Hg either didn't have or wasn't very good at. So while Git was confusing, once you learned the model and commands it did a really good job of rewarding you for it.
This gap has closed substantially, particularly on the Hg side -- a lot of the "missing features" have been implemented either in core Hg or in extensions. At the same time, Git has been doing a reasonably good job at improving usability, though some issues remain.
Then again, I'm a Git user who hasn't worked much with Hg, so take what I said with a strong dose of salt.
I haven't used Mercurial enough to compare it meaningfully to Git, but even in a traditional corporate environment I'd take either over Subversion in a heartbeat. (In my little use of Hg I haven't liked it as much as Git, particularly TortoiseHg vs TortoiseGit, but I'm sure most of that has to do with familiarity.)
The "D" part is still occasionally useful for things like working on an airplane or something, and it's nice to commit half-baked changes without polluting a global branch namespace and worrying about policies and stuff. I recently embarked on a couple-day change to one part of our code, and made just a local Git repo so I could play around with my changes without having to go to the ground-truth repository (SVN). (I've thought about working with git-svn and haven't tried it, but I think our repository structure wouldn't work very well with that.) Once I got things done over the course of a dozen or so Git commits, I could clean them up and for submission to the actual repo.
In addition, both Git and Hg offer just a bunch of really nice features that have nothing to do with their distributed-ness; in particular, I love Git's index and add --patch/--interactive, to the point of which I actually wrote a script that tries to duplicate the add --patch with Subversion. But in part because Git was built around that idea, my script doesn't and more or less can't work as well as Git.
Git is just awful.
I have two or so big usability complaints about git, but in general I actually like it quite a bit. (And I don't say that about much software...) My general impression is that it has a sharper learning curve than Hg at the front but that it rewards that by being able to do some really nice things.
Yeah it got me for a good bit too. I was about to go post it to a chat in a making-fun-of-SVN-way at which point my brain was like "waaaaiiiit a minnnute..."
SSH has no certificates, and yet has a higher market share in the shell connection market than SSL has in the http connection market
This is not a particularly fair comparison.
I would say that almost all traffic that goes via SSH/telnet/whatever is reasonably private. In most cases; even if the traffic isn't so private, you're getting a shell connection to another computer! There's only one time I can think of where I've SSH/telnetted to that wasn't private like that, and that's to towel.blinkenlights.nl.
By contrast, a large portion of traffic that goes via HTTP is just generic traffic. If you or I go to slashdot.org, we'll get almost the same thing. That information pretty fundamentally will be present with encryption too. There is some privacy issue in terms of exactly what URL you're going to (e.g. what/. stories you're interested in, potentially what AC comments you make), but for the most part its much less than your typical shell session from a privacy perspective.
The other thing that encryption does from a network infrastructure level is kill caching. That doesn't matter so much for SSH/telnet connections (at least until you start tunneling other stuff across them) because they're probably unique anyway; it does matter for something like Netflix.
... the CA system doesn't help in this scenario, as the MITM is likely to negate the redirect to SSL in the first place, and to just keep the user in plain http.
I can't speak for most people obviously, but I usually glance at the address bar and make sure it indicates HTTPS when I'm connecting to a high-value site.
[TOFU] prevents the kinds of attacks that actually matter, while ignoring the kinds of attacks that look great on paper but aren't really a big deal in practice.
If HTTPS used TOFU, it would mean that if I wanted to connect to some high-value site on a device that hadn't visited it before, I couldn't do it on a network that I didn't at least kind of trust. Traveling? Sucks to be you if you need to contact your bank on a relatively new laptop.
TOFU and CAs do have some interesting security tradeoffs, but I definitely disagree that "TOFU is far superior to CAs". For typical HTTPS browsing situations, I think CAs provide the better set of tradeoffs.
For all we know by now it's possible and not implausible to assume that MITM attacks are conducted routinely by various intelligence agencies across the world.
Better than MITM attacks being conducted routinely by anyone who can set up a wi-fi access point.
Use physically delivered security tokens (such as encrypted random data on a USB stick)
I'll be sure to order one for my (non-AWS, just to be clear) Amazon account right away. </sarcasm>
Not incidentally, I'll also point out that the linked article was written before wi-fi was common. At that point, it was perhaps much more reasonable. But nowadays, when people think nothing of connecting to public wi-fi networks, MITM protection is critical.
The frequency of a true MITM - one defined above where someone has the ability to control an intermediate node at low level and take central position - is so low as to be difficult to measure.
This is about as dumb of an argument against SSL as I can imagine. True MITMs are reasonably rare in large part because of SSL.
SSL and CAs are far from perfect, but the situation is a hell of a lot better than if they weren't around...
The interior photos I've found of the Tesla shows that the accelerator pedal is a different shape and is further back than the brake pedal, so if your feet are off all pedals and you randomly mash down, you'll catch the brake pedal before you catch the gas pedal.
No one has claimed to the contrary. In fact, the blog author has measured how much you catch the brake pedal by.
The claim is twofold: (1) the distinction is much less in the Tesla than in most cars, and (2) it's too easy to catch both pedals. So you catch the brake pedal, continue pressing down, and then catch the accelerator, and then continue pressing down. So now even though you're braking, your engine is also supplying a lot of power, so you don't slow as quickly.
And I know cause I drive one daily and I have managed to double pedal a total of two-three times when being lazy and it's never been a situation where it'd lead to the car not stopping
I'm not sure you're helping your case. In fact, IMO you're supporting his. He has only double-pedaled a small number of times too, and his previous times were when he didn't have issues stopping either. And in years and years of driving my normal sedan, I think I have never double pedaled.
Well, here's the thing... to at least a moderate extent, Intel isn't really competing against AMD or nVidia, because unless something has changed relatively recently, they don't have anything that comes even close to the offerings of the latter in terms of performance. So if AMD or nVidia learns something about how Intel chips works and improves their own a bit as a result, they're not going to take away much business from Intel. On the other hand, if AMD open-sourced the guts of their driver and nVidia learned enough to raise the performance of their own cards by a few percentage points or something, that'd be a somewhat big deal.
The complement to this argument is that because Intel can't win customers based on performance, they have incentive to seek other distinguishing factors. One of those factors would be openness and Linux support.
In addition to what other people have said, GPU drives contain shader compilers and probably other kinds of optimization routines which actually give a "competitive advantage".
OpenDNS hijackes NXDOMAIN failures, which is one of the big reasons to drop many ISP's DNS in the first place. I don't want to get into evaluation of motivation and such, but the effect is the same.
Nice misdirection, firstly the typical windows shell sucks, secondly it ignores the Windows XP style start menu which is also vastly superior to the typical Windows shell (did I mention that windows shells typically suck?).
I could have been clearer, but I was including typical Unix shells in that as well.
Actually if you define a command-line shell as a text-based program that you use to launch and interact with other programs, the Vista/7/8 search mechanism for launching programs works better than every command-line shell that I've ever used if you just want to launch the program with no command-line arguments (which is the usual thing when starting a GUI program).
Take Word, remove the space bar and replace it with a button in the GUI. Can you imagine the pain caused by this?
If you're launching programs with anything approaching the frequency of typing a space, you're doing something really weird.
But fine, take a different example: a web browser. Browsers are primarily a mouse-driven program -- scrolling is arguably nicer with a mouse, and clicking links and such is definitely nicer with a mouse. But if you want to go to a new URL, what do you do? Type it out, even though that's only a momentary use of the keyboard.
Why should there be a sharp line between GUI and text interface? In other words, the question shouldn't be "should this typing thing be in a GUI" and should instead be "is this (or when is this not) a good way of launching programs?"
For instance, I'm actually one of the relatively few people who actually really liked Vista, and a lot of that was on account of the search feature of the start menu. I'd have taken it over XP on the basis of that feature alone, that's how much it improved my usability. (Possibly XP + Launchy would have satisfied me, but I discovered it a bit too late to use it much with XP and view it as pretty much obsoleted by Vista+.) For several reasons, I think it's even significantly easier and faster overall to use the start menu search than it is to use tab completion in a typical shell to launch a GUI program.
(And incidentally, this is one reason that I'm almost completely indifferent about Win8, which I suspect you don't see. I pretty much ignore the fact that metro exists except when launching programs, and I launch programs pretty much identically to how I launched them in Vista & 7.)
No one says "hey I actually have to type when creating a document in Word; what gives?!" even though Word is pretty much undeniably a GUI.
I think that in a lot of cases, the same can be said for the start menu. If you're on a desktop/laptop, most of the time pressing win then typing a few characters is just fundamentally going to be the fastest way to start a program. The Win8 problem comes from the fact that in other situations, or if the user doesn't know you can do that, or if they just don't want to type, the start screen is pretty hard to use well.
Windows NT has had a journaling FS since its introduction in 1993.
But (on any OS) a journaling FS usually just means that the file system metadata itself is consistent; most journaling FSs don't journal data changes as well, so you could have a half-committed change to the contents of a file from a program. Even if it did, that still doesn't guarantee that a program will issue file operations in a way that has any chance of being considered atomic.
You could make an argument that journaling fixes some of the least important file system consistency issues.
Uh... no. I'm not saying no one uses those terms the way you define it, but "dynamic range" is pretty much the only term I've seen used for what you call exposure range.
For example, if I Google "dynamic range photo" (and in the interest of fully disclosing my methods, that's the first search term I tried), the first five results are:
"Overall, the dynamic range of a digital camera can therefore be described as the ratio of maximum light intensity measurable (at pixel saturation), to minimum light intensity measurable (above read-out noise)." http://www.cambridgeincolour.c...
"In photography, dynamic range is the difference between the lightest light and darkest dark which can be seen in a photo." http://www.kenrockwell.com/tec...
"The dynamic range of a sensor is defined by the largest possible signal divided by the smallest possible signal it can generate." This one is closer to your definition of dynamic range. http://www.dpreview.com/glossa...
The wikipedia hit I get goes right to the HDR articles, which says "In photography, dynamic range is measured in EV differences (known as stops) between the brightest and darkest parts of the image that show detail." If you follow the link to the dynamic range article, you get "Photographers use "dynamic range" for the luminance range of a scene being photographed, or the limits of luminance range that a given digital camera or film can capture, or the opacity range of developed film images, or the reflectance range of images on photographic papers." (emphasis mine) http://en.wikipedia.org/wiki/H... http://en.wikipedia.org/wiki/D...
So if I'm generous and count dpreview for you (and then count the fifth link as neutral), that's 1 out of 4 links that agree with you and 3 out of 4 that use "dynamic range" to mean what you call "exposure range".
Can you install Windows 8 on an 8-year old PC and expect it to run acceptably?
I run Win8 on a 6 1/2-year old PC. Believe it or not, that's actually my main computer at home. Works fine. Only upgrades were more RAM (2->6GB), an SSD, and a new GPU (only because the old one died). The only one of those that had anything to do with the OS upgrade was the SSD -- I used the "well I have to reinstall anyway" as an excuse to move from 7 to 8. Barring any HW failures, it is almost certain that will remain my primary computer until it is more than 7 years old.
Would I see benefit from an upgrade? Yeah, occasionally. Would I see enough benefit that it's worth the money? No, not since I've gotten a dedicated gaming machine.
Besides, your question isn't even the right question. It's not a matter of "would it run fine if you installed the latest and greatest thing" -- it's a matter of "is it running fine with what it has already".
Slashdot Mirror
As a git user, I've done a bit of reading about Hg branches. The difference seems to be pretty much "the name of the branch is stored permanently with the commit." Is that it, or is there more?
(The "is that it" is meant to be a question, not a dismissive value judgement.)
You probably know this, but you can git pull --rebase and still do it in one step. You could also add a config alias (e.g. git get or something) for that; heck, I'd bet $20 you can make --rebase the default for just git pull.
Or, you know, git rev-parse HEAD. Though I'll admit that doesn't address your "I have to run something" objection, at least it's a far cleaner command with less shell and quoting dependencies and issues.
I didn't know/forgot about that (in addition to confusing stash pop, which is what I virtually always use, and stash apply). Though I will point out that there can be conflicts other than textual ones.
That choice actually makes sense from the Git model. A Subversion person would ask why there is one command for three+ different things (svn revert, svn switch, svn up -r### are all done using git checkout). But if you turn your head around and look at it from a different perspective, all three of those are doing the same thing: copying something from the repository store to the working copy. From the Git perspective, Subversion is giving three different names to the same thing, each of which only works some of the time.
I don't want to argue Git is right, just that if it has a fault here, Git's is that its terms are at a lower level than users usually think and not that it's inconsistent on this point.
Oh boy. The whole index is a mess of inconsistent terminology. You stage something to the index using git add, unless you're using git add --interactive in which case that process is called updating. And of course you see what the changes are in your index by using git diff --cached. Wut?
(Yes, I know, git diff --staged is now an alias for the last. Good, now all they have to do is deal with the three other synonyms for the same thing.)
Here I also defend git, because I think this is a significant selling point. One major advantage that Git has is that once something is actually added to the store, it's nearly impossible to accidentally lose information. git stash adds the state to the store.
Compare to something like Subversion. Suppose you have a nice change. It's working properly. Now you svn up. Now you get a bunch of hard-to-resolve conflicts. You say "I don't want to deal with this now; I just want to go back to the state I was in before updating." Too bad, you can't (at least any way I know how). You're screwed, because Subversion has caused you to lose information.
Compare to git. You have to run stash before pulling (merging/rebasing technically of course), so now the state of the working copy right before the pull is in the store. You then stash apply. You get the conflicts, say "I give up for now". Now all you have to do is figure out what the SHA1 of the copy that was in the stash is. Might have to do some reflog digging, but it is not only possible but actually pretty easy if you know about the reflog.
You may be partly right. But I think a lot of it is that for a while, Git was a lot more "powerful" -- it supported some very useful modes of operation that Hg either didn't have or wasn't very good at. So while Git was confusing, once you learned the model and commands it did a really good job of rewarding you for it.
This gap has closed substantially, particularly on the Hg side -- a lot of the "missing features" have been implemented either in core Hg or in extensions. At the same time, Git has been doing a reasonably good job at improving usability, though some issues remain.
Then again, I'm a Git user who hasn't worked much with Hg, so take what I said with a strong dose of salt.
I haven't used Mercurial enough to compare it meaningfully to Git, but even in a traditional corporate environment I'd take either over Subversion in a heartbeat. (In my little use of Hg I haven't liked it as much as Git, particularly TortoiseHg vs TortoiseGit, but I'm sure most of that has to do with familiarity.)
The "D" part is still occasionally useful for things like working on an airplane or something, and it's nice to commit half-baked changes without polluting a global branch namespace and worrying about policies and stuff. I recently embarked on a couple-day change to one part of our code, and made just a local Git repo so I could play around with my changes without having to go to the ground-truth repository (SVN). (I've thought about working with git-svn and haven't tried it, but I think our repository structure wouldn't work very well with that.) Once I got things done over the course of a dozen or so Git commits, I could clean them up and for submission to the actual repo.
In addition, both Git and Hg offer just a bunch of really nice features that have nothing to do with their distributed-ness; in particular, I love Git's index and add --patch/--interactive, to the point of which I actually wrote a script that tries to duplicate the add --patch with Subversion. But in part because Git was built around that idea, my script doesn't and more or less can't work as well as Git.
I have two or so big usability complaints about git, but in general I actually like it quite a bit. (And I don't say that about much software...) My general impression is that it has a sharper learning curve than Hg at the front but that it rewards that by being able to do some really nice things.
Yeah it got me for a good bit too. I was about to go post it to a chat in a making-fun-of-SVN-way at which point my brain was like "waaaaiiiit a minnnute..."
This is not a particularly fair comparison.
I would say that almost all traffic that goes via SSH/telnet/whatever is reasonably private. In most cases; even if the traffic isn't so private, you're getting a shell connection to another computer! There's only one time I can think of where I've SSH/telnetted to that wasn't private like that, and that's to towel.blinkenlights.nl.
By contrast, a large portion of traffic that goes via HTTP is just generic traffic. If you or I go to slashdot.org, we'll get almost the same thing. That information pretty fundamentally will be present with encryption too. There is some privacy issue in terms of exactly what URL you're going to (e.g. what /. stories you're interested in, potentially what AC comments you make), but for the most part its much less than your typical shell session from a privacy perspective.
The other thing that encryption does from a network infrastructure level is kill caching. That doesn't matter so much for SSH/telnet connections (at least until you start tunneling other stuff across them) because they're probably unique anyway; it does matter for something like Netflix.
I can't speak for most people obviously, but I usually glance at the address bar and make sure it indicates HTTPS when I'm connecting to a high-value site.
If HTTPS used TOFU, it would mean that if I wanted to connect to some high-value site on a device that hadn't visited it before, I couldn't do it on a network that I didn't at least kind of trust. Traveling? Sucks to be you if you need to contact your bank on a relatively new laptop.
TOFU and CAs do have some interesting security tradeoffs, but I definitely disagree that "TOFU is far superior to CAs". For typical HTTPS browsing situations, I think CAs provide the better set of tradeoffs.
I didn't say they provide a silver bullet. In fact I pretty much explicitly said they aren't a silver bullet: "CAs are far from perfect."
What I said they're a hell of a lot better than nothing.
Better than MITM attacks being conducted routinely by anyone who can set up a wi-fi access point.
I'll be sure to order one for my (non-AWS, just to be clear) Amazon account right away. </sarcasm>
Not incidentally, I'll also point out that the linked article was written before wi-fi was common. At that point, it was perhaps much more reasonable. But nowadays, when people think nothing of connecting to public wi-fi networks, MITM protection is critical.
This is about as dumb of an argument against SSL as I can imagine. True MITMs are reasonably rare in large part because of SSL.
SSL and CAs are far from perfect, but the situation is a hell of a lot better than if they weren't around...
I don't have a Tesla, nor do I know anyone who I know has a Tesla. I can't try it. However, the blog post directly contradicts you.
Care to point to a definitive source?
No one has claimed to the contrary. In fact, the blog author has measured how much you catch the brake pedal by.
The claim is twofold: (1) the distinction is much less in the Tesla than in most cars, and (2) it's too easy to catch both pedals. So you catch the brake pedal, continue pressing down, and then catch the accelerator, and then continue pressing down. So now even though you're braking, your engine is also supplying a lot of power, so you don't slow as quickly.
I'm not sure you're helping your case. In fact, IMO you're supporting his. He has only double-pedaled a small number of times too, and his previous times were when he didn't have issues stopping either. And in years and years of driving my normal sedan, I think I have never double pedaled.
It really does sound like a design problem.
Well, here's the thing... to at least a moderate extent, Intel isn't really competing against AMD or nVidia, because unless something has changed relatively recently, they don't have anything that comes even close to the offerings of the latter in terms of performance. So if AMD or nVidia learns something about how Intel chips works and improves their own a bit as a result, they're not going to take away much business from Intel. On the other hand, if AMD open-sourced the guts of their driver and nVidia learned enough to raise the performance of their own cards by a few percentage points or something, that'd be a somewhat big deal.
The complement to this argument is that because Intel can't win customers based on performance, they have incentive to seek other distinguishing factors. One of those factors would be openness and Linux support.
In addition to what other people have said, GPU drives contain shader compilers and probably other kinds of optimization routines which actually give a "competitive advantage".
OpenDNS hijackes NXDOMAIN failures, which is one of the big reasons to drop many ISP's DNS in the first place. I don't want to get into evaluation of motivation and such, but the effect is the same.
I could have been clearer, but I was including typical Unix shells in that as well.
Actually if you define a command-line shell as a text-based program that you use to launch and interact with other programs, the Vista/7/8 search mechanism for launching programs works better than every command-line shell that I've ever used if you just want to launch the program with no command-line arguments (which is the usual thing when starting a GUI program).
If you're launching programs with anything approaching the frequency of typing a space, you're doing something really weird.
But fine, take a different example: a web browser. Browsers are primarily a mouse-driven program -- scrolling is arguably nicer with a mouse, and clicking links and such is definitely nicer with a mouse. But if you want to go to a new URL, what do you do? Type it out, even though that's only a momentary use of the keyboard.
Why should there be a sharp line between GUI and text interface? In other words, the question shouldn't be "should this typing thing be in a GUI" and should instead be "is this (or when is this not) a good way of launching programs?"
For instance, I'm actually one of the relatively few people who actually really liked Vista, and a lot of that was on account of the search feature of the start menu. I'd have taken it over XP on the basis of that feature alone, that's how much it improved my usability. (Possibly XP + Launchy would have satisfied me, but I discovered it a bit too late to use it much with XP and view it as pretty much obsoleted by Vista+.) For several reasons, I think it's even significantly easier and faster overall to use the start menu search than it is to use tab completion in a typical shell to launch a GUI program.
(And incidentally, this is one reason that I'm almost completely indifferent about Win8, which I suspect you don't see. I pretty much ignore the fact that metro exists except when launching programs, and I launch programs pretty much identically to how I launched them in Vista & 7.)
No one says "hey I actually have to type when creating a document in Word; what gives?!" even though Word is pretty much undeniably a GUI.
I think that in a lot of cases, the same can be said for the start menu. If you're on a desktop/laptop, most of the time pressing win then typing a few characters is just fundamentally going to be the fastest way to start a program. The Win8 problem comes from the fact that in other situations, or if the user doesn't know you can do that, or if they just don't want to type, the start screen is pretty hard to use well.
Windows NT has had a journaling FS since its introduction in 1993.
But (on any OS) a journaling FS usually just means that the file system metadata itself is consistent; most journaling FSs don't journal data changes as well, so you could have a half-committed change to the contents of a file from a program. Even if it did, that still doesn't guarantee that a program will issue file operations in a way that has any chance of being considered atomic.
You could make an argument that journaling fixes some of the least important file system consistency issues.
Uh... no. I'm not saying no one uses those terms the way you define it, but "dynamic range" is pretty much the only term I've seen used for what you call exposure range.
For example, if I Google "dynamic range photo" (and in the interest of fully disclosing my methods, that's the first search term I tried), the first five results are:
"Overall, the dynamic range of a digital camera can therefore be described as the ratio of maximum light intensity measurable (at pixel saturation), to minimum light intensity measurable (above read-out noise)."
http://www.cambridgeincolour.c...
"In photography, dynamic range is the difference between the lightest light and darkest dark which can be seen in a photo."
http://www.kenrockwell.com/tec...
"The dynamic range of a sensor is defined by the largest possible signal divided by the smallest possible signal it can generate." This one is closer to your definition of dynamic range.
http://www.dpreview.com/glossa...
The wikipedia hit I get goes right to the HDR articles, which says "In photography, dynamic range is measured in EV differences (known as stops) between the brightest and darkest parts of the image that show detail." If you follow the link to the dynamic range article, you get "Photographers use "dynamic range" for the luminance range of a scene being photographed, or the limits of luminance range that a given digital camera or film can capture, or the opacity range of developed film images, or the reflectance range of images on photographic papers." (emphasis mine)
http://en.wikipedia.org/wiki/H...
http://en.wikipedia.org/wiki/D...
The fifth link, http://www.stuckincustoms.com/..., doesn't have any definition of dynamic range, and is basically an ad site.
So if I'm generous and count dpreview for you (and then count the fifth link as neutral), that's 1 out of 4 links that agree with you and 3 out of 4 that use "dynamic range" to mean what you call "exposure range".
I run Win8 on a 6 1/2-year old PC. Believe it or not, that's actually my main computer at home. Works fine. Only upgrades were more RAM (2->6GB), an SSD, and a new GPU (only because the old one died). The only one of those that had anything to do with the OS upgrade was the SSD -- I used the "well I have to reinstall anyway" as an excuse to move from 7 to 8. Barring any HW failures, it is almost certain that will remain my primary computer until it is more than 7 years old.
Would I see benefit from an upgrade? Yeah, occasionally. Would I see enough benefit that it's worth the money? No, not since I've gotten a dedicated gaming machine.
Besides, your question isn't even the right question. It's not a matter of "would it run fine if you installed the latest and greatest thing" -- it's a matter of "is it running fine with what it has already".