Thanks, but the Google charger does indeed have powerful magnets. The problem is that they don't always pull the phone into the correct alignment for charging.
They are strong enough to grab and hold it to the charger firmly while it is still out of alignment. If you don't witness the charging indication starting within a few seconds, you must move the phone to see if it is properly aligned.
The difference between charging alignment and incorrect alignment is less than 1 cm.
Meh. The magnets don't always align it properly, so you can't just drop it on and expect it to work. You have to either wait to confirm charging started or slowly move the phone around until it starts (rotating it to be perfectly aligned, or up/down + side to side)
If I wanted to spend a lot of time dealing with charging I would just plug it in.
I still use it, but it's not really a time saver when I have to wait a second or two to witness the charging started confirmation (sound or animation). Simply placing the phone on the charger is a 90+% reliable solution, but that's not good enough when these smartphones don't get two days' runtime on a charge.
Its also slow and potentially doesnt charge the phone when its in use.
Not only is it slow, and potentially does not charge the phone while it is in use, it also potentially does not charge the phone when it's on the charger.
More than once, incidentally including last night, I have placed the phone on the charger before bed and awoke to a phone that did not charge because I had placed it slightly off alignment.
I bought this Google charger for my Nexus 5 to make charging more convenient (no fumbling with micro USB with my glasses off, etc).
I am in favor of socialized medicine because I recognize US medicine has been irrevocably socialized for decades, the majority wants it that way, and therefore the free market approach isn't on the table. I prefer socialized medicine because I want to reduce the taxes I am paying for healthcare.
Anyway, I wanted to point out that the public option or single payer was never a viable alternative when the Democrats ramrodded Obamacare through Congress. There were too many conservative Democrats who wouldn't vote in favor of that (remember that every last Democratic senator's vote was required). That's why Obamacare turned into a pork barrel wishlist to buy moderate/conservative Democrat votes.
It's also why, for example, Ben Nelson (D-NE), the last holdout whose vote was bought with the "Cornhusker kickback", was forced to retire after decades in Congress and was replaced by a Republican. He wasn't the only one.
Politics is the art of the possible, and Obamacare was a bridge too far for many of these Democratic senators.
Coincidentally, I just read a Paul Krugman piece this morning while waiting for the doctor. He completely misportrayed what happened and what it means.
No surprise there. Krugman's modus operandi is to mislead his readers. I believe it's through malice on his part, but it could very well be through delusional incompetence.
If you can't figure out how to manage addresses using practically enough bits to allow every particle in the universe to be able to individually directly address every other particle in the universe, You're Doing It Wrong.
Direct connection routing is n^2. 512 is close to allowing n^2, but the 10^80 is an estimate as well.
You don't think a future logical addressing scheme would be able to at least do as well, efficiency wise, as a directly connected, n^2 network?
N^2 is the trivial case, mind you, and is practically not even a network (if everything can directly communicate with everything else, then is it really a routing network?)
Again, that does not imply that communication is between locations. Communication is between/among physical objects/entities.
512 bit addressing allows over 200 bits of logical addressing to go with the 266 bits of unique addressing. If general location makes the most sense for logical blocks for routing, then use that. It still does not imply that the address itself should be some "absolute" (*cough*) location.
You are still always communicating to objects, never locations. You described a scenario where you want to talk to physical objects (people) who happen to be in a location.
Have you ever walked into an empty room with the intention to communicate with a location? Because that's what addressing based on location rather than objects implies. Normal communication would involve going into a room that wasn't empty and talking to a person or people. You aren't communicating to space itself, but rather with physical objects.
Imagine if your phone number constantly changed based on which room of the house you were in, and it continued to change as you walked around while talking with someone.
There is no use case I can conceive of where addressing a location makes more sense than addressing a particular object/person. Communication is fundamentally about objects passing information. Location is metadata or is something that is incidental to the objects communicating. Locations don't communicate, objects/people do. Therefore, objects/people should be the basis for the addressing scheme.
And when I said relativity makes the proposed plank-length location addressing idea a bitch, I really meant that it is essentially impossible.
Rounding up to 512 bit addressing allows the ~266 bit identifier to be unique (ala the typical MAC aspect of IPv6) while allowing substantial overhead for logical addressing hierarchy based on some allocation system that makes sense.
It is a sure bet that once it gets codified into a standard that we can only communicate with our universe and integrated into a host of products, we will discover that we can in fact communicate with multiple universes. Luckily, there is the likely possibility that there are a host of other universes won't make this mistake.
NAT. You know that would be the de facto solution, and I grin at the thought of future address space purists wringing their hands over the solution as much as their 21st century ancestors did...
Yeah, that'll work great, until we discover multiple universes...
The question then becomes "if there is another universe we cannot communicate with, do we really need to be able to address their physical particles with our communication networks?"
This will only solve it for people who think that addresses should be assigned to objects.
I don't know about you, but every time I am communicating with something or someone, I am communicating with something physical rather than a location.
Do you have a use case for why we should be communicating based on locations rather than physical objects? Relativity would make your idea a real bitch. Furthermore, I don't care where my server is located (and I don't want to have to care, either), but with your idea our communication would involve constantly changing IPs for every Planck time (because, no doubt, both my device and my server are constantly in motion relative to your IP addressing scheme's frame of reference).
Actually, why not solve it for all time? Given the estimate of 10^80 particles in the universe, then moving to 266 bit addressing (i.e. 80/log(2)) would allow each particle to be addressed individually. Bumping to 512 bit addressing would accommodate the typical logical addressing inefficiencies.
While I agree with you this is corruption, if the choice is between a union that moves government money into the pockets of at least some citizens vs. a lobby group that moves government money into the pockets of the 0.01% then I'd rather have the former.
Keep watching and check where the new candidate moves the money to.
That's a false dichotomy. The unions and their compensation are directly responsible for my taxes being increased (sales and property taxes). Furthermore, this is not the government's money, it's the taxpayers' money that is being appropriated to feather these union people's nests.
Bringing the unions to heel involves the new mayor forcing them to accept substantive changes to their abusive compensation. This is underway, and the inevitable lawsuits are winding their way through the courts. Hopefully once these unions are defeated we will be able to roll back the special tax assessments.
So: beating the unions results in the possibility of more money for me and all the other non-millionaire/non-billionaire taxpayers like me in my city.
It's a crime what they pay police officers. They practically guarantee corruption.
I agree, but for the opposite reason you purport. In my locale, we have cops retiring on full pension in their 40's. Furthermore, until a few years ago, the cops were all "spiking" their pensions so they were pulling down $100+k/year pensions (pension pay was based on the last 18 months of income better retirement, and they all loaded up on scads of overtime during their leadup to retirement). Actuarially, they are going to live another 30+ years while drawing these $100+k/year pensions. Of course, they will immediately launch into a second career after retiring in their 40's, so their income is actually the full pension plus their new career.
That's certainly a "living wage" *cough*.
The fire and police unions are driving my city into a race to the bottom. We are half a billion dollars in the hole for the pension fund thanks to these people.
The problem is that the police/fire unions have served as "kingmakers" for the mayoral elections for the past few decades. It's no wonder their contracts have gotten "recommended" enhancements by the mayors. We finally broke the back of the union kingmakers in last year's election... a candidate they opposed won, on a platform that included bringing the unions to heel. Hopefully we can claw back the criminal amounts we are paying these people.
Well, of course you can look at it that way, but absent the constitution or another social contract you have only the state of nature - where life is nasty, brutish and short.
Certainly you could say we have many rights protected under the constitution, but really it's just semantics; the rights exist but to fully enjoy the benefits that flow therefrom might require discretion over which rights we exercise and when and how we do so.
Your perspective is precisely why some of the Founders were against a Bill of Rights. They believed that by explicitly guaranteeing certain rights, people would start to believe that the Constitution existed to circumscribe the rights of the states and the people—when in fact, it is exactly the opposite. The Constitution was written as a whitelist of powers of the federal government. Everything else, all rights and powers, were implicitly retained by the states and/or people.
The compromise for the Bill of Rights for the Founders who opposed it was the inclusion of the 9th and 10th amendments, which serve as a reminder that the Constitution does *not* define your rights, but rather exists to restrain the government.
This distinction matters. We are not supposed to live at the whim and pleasure of our governmental "masters". Thinking about this backwards (I.e. that the government grants us our rights rather than we granting powers to the government) preconditions the construct for abuse by the government.
Again, meh. I'm really not concerned that "everything" might need to be recompiled. Distros do it for binaries in the first place (you aren't using Gentoo are you?), cloud build farm time is cheap, etc. Besides, for most of these minor updates that are supposed to "just work" (*cough*), they should only need to be re-linked, not fully recompiled.
Your proposal of manually tweaking LD_LIBRARY_PATH is not an example of what I would call "easy".
For example, if I want to run a svn or git client binary, these have massive dependencies. I shouldn't need root in order to get these running on a new machine, and I shouldn't have to deal with choosing between lib-apr breaking svn vs postgresql or hunting down 10+ libraries that are on a different major version of CentOS in order to get the minimum version level for svn that has the feature I require. I don't want to have to care which version of libc the platform has... I just want to be able to drop a self-contained binary in the directory and have it work.
This is no larger an issue than dependency tracking already is. The idea is that your distro provides the binaries, so they should also have the checksums for the individual binaries that correlate to the compilation/static linking. That is to say, if you have hash X then they know that's linked against OpenFail 0.2.3, etc. I imagine it would be a simple extension to package managers to fetch this kind of metadata.
Updates would come out via binary deltas, just like the way the Google Chrome updater works.
Give me statically compiled binaries any day (naturally YMMV on embedded platforms).
Oh yes, because having to upgrade half of the system because a bug in some library was finally fixed is sooo much better...
Meh. I'm sick of updating a shared library and having it break some client binaries while being a mandatory minimum patchlevel for others. Why do I have to choose between one set of binaries or the other? Static binaries avoid the whole damn problem.
Your cited concern does indeed represent one drawback. However it really isn't a big deal anymore: binary deltas reduce the I/O bandwidth for patching.
Do you have a counterproposal that gives fully portable, self-contained binaries that aren't subject to dependency hell? That's my goal, and statically linked binaries is just the only method I can think of to satisfy the goal.
Still, I would much rather have a binary that I can move to another installation and have it "Just Work(tm)". Dependency hell sucks, and I am sick of yak shaving simply to get a basic client binary to run. Besides, the promise of shared libs "fix once, fixed everywhere" doesn't really pan out aside from trivial cases. More frequently it's "shared library is patched, dammit... that broke several consumers. now what?"
Just give us statically compiled binaries and do a Google Chrome-style binary diff upgrade system for the clients so that network bandwidth consumption doesn't go off the charts for the distro host.
We would finally be able to have portable, standalone binaries that are free of extraneous dependencies and would run on another machine without fuss. I don't care if my 300 KB binary compiled against shared libs balloons into a 30 MB self-contained, static binary. Hell, it probably wouldn't be as bad as that, anyway.
Linux was not as polished at all, but did a few things reasonably. In particular, it had shared libraries, greatly reducing the memory requirements at a time when memory was expensive
Talk about a Faustian deal. The shared libs approach is like the legacy of a chemical waste dump... it's there, it seemed like a good idea at the time, and there is not a whole lot anyone is doing to deal with the problems it causes simply by existing. Memory and disk space are no longer expensive, but catch-22 shared library hell is forever.
Give me statically compiled binaries any day (naturally YMMV on embedded platforms).
Look: in practically every other case, I would agree with you. However, why would you want to read a post by Linus with some tweets that he copied and pasted?
Then again, after watching the video, I regret wasting that portion of my life on such a lame set of vignettes. I was expecting him to be reading some kernel dev's ragequit tweet or something. Instead, what he got was the equivalent of a handjob by his "detractors".
The whole thing was paramasturbatory for Linus. I suggest you continue with your no video policy.
With my old CRT TV, the near-60-hz image (30hz interlaced) appeared flicker free. On my old Viewsonic CRT monitor, anything less than 85hz would flicker very noticeably to me. I usually preferred to run at 120hz interlaced.
You speak truth. I could pass a double-blinded test about CRT refresh rates below 80 Hz. It was overtly obvious, even without waiting for the dreaded "low refresh rate flicker" headache to kick in.
With LCDs flicker isn't really an issue, but smearing/tearing certainly is.
This is useless and irrelevant calculation.
What counts is what is the total cost and return on investment.
I concur. However, I believe it is requisite (though not sufficient) for a viable alternative to meet energy return on investment.
If it can't even do that, then it certainly can't be economical.
Cf. fusion energy: it certainly doesn't meet that threshold.
Thanks, but the Google charger does indeed have powerful magnets. The problem is that they don't always pull the phone into the correct alignment for charging.
They are strong enough to grab and hold it to the charger firmly while it is still out of alignment. If you don't witness the charging indication starting within a few seconds, you must move the phone to see if it is properly aligned.
The difference between charging alignment and incorrect alignment is less than 1 cm.
Meh. The magnets don't always align it properly, so you can't just drop it on and expect it to work. You have to either wait to confirm charging started or slowly move the phone around until it starts (rotating it to be perfectly aligned, or up/down + side to side)
If I wanted to spend a lot of time dealing with charging I would just plug it in.
I still use it, but it's not really a time saver when I have to wait a second or two to witness the charging started confirmation (sound or animation). Simply placing the phone on the charger is a 90+% reliable solution, but that's not good enough when these smartphones don't get two days' runtime on a charge.
they didn't get the half million. Kickstarter shut it down before the transfers.
Discerning con artists prefer indiegogo for precisely that reason. Then again there are plenty of examples of scams on kickstarter as well.
Its also slow and potentially doesnt charge the phone when its in use.
Not only is it slow, and potentially does not charge the phone while it is in use, it also potentially does not charge the phone when it's on the charger.
More than once, incidentally including last night, I have placed the phone on the charger before bed and awoke to a phone that did not charge because I had placed it slightly off alignment.
I bought this Google charger for my Nexus 5 to make charging more convenient (no fumbling with micro USB with my glasses off, etc).
That makes my experience ironic.
I am in favor of socialized medicine because I recognize US medicine has been irrevocably socialized for decades, the majority wants it that way, and therefore the free market approach isn't on the table. I prefer socialized medicine because I want to reduce the taxes I am paying for healthcare.
Anyway, I wanted to point out that the public option or single payer was never a viable alternative when the Democrats ramrodded Obamacare through Congress. There were too many conservative Democrats who wouldn't vote in favor of that (remember that every last Democratic senator's vote was required). That's why Obamacare turned into a pork barrel wishlist to buy moderate/conservative Democrat votes.
It's also why, for example, Ben Nelson (D-NE), the last holdout whose vote was bought with the "Cornhusker kickback", was forced to retire after decades in Congress and was replaced by a Republican. He wasn't the only one.
Politics is the art of the possible, and Obamacare was a bridge too far for many of these Democratic senators.
Coincidentally, I just read a Paul Krugman piece this morning while waiting for the doctor. He completely misportrayed what happened and what it means.
No surprise there. Krugman's modus operandi is to mislead his readers. I believe it's through malice on his part, but it could very well be through delusional incompetence.
If you can't figure out how to manage addresses using practically enough bits to allow every particle in the universe to be able to individually directly address every other particle in the universe, You're Doing It Wrong.
Direct connection routing is n^2. 512 is close to allowing n^2, but the 10^80 is an estimate as well.
You don't think a future logical addressing scheme would be able to at least do as well, efficiency wise, as a directly connected, n^2 network?
N^2 is the trivial case, mind you, and is practically not even a network (if everything can directly communicate with everything else, then is it really a routing network?)
Again, that does not imply that communication is between locations. Communication is between/among physical objects/entities.
512 bit addressing allows over 200 bits of logical addressing to go with the 266 bits of unique addressing. If general location makes the most sense for logical blocks for routing, then use that. It still does not imply that the address itself should be some "absolute" (*cough*) location.
You are still always communicating to objects, never locations. You described a scenario where you want to talk to physical objects (people) who happen to be in a location.
Have you ever walked into an empty room with the intention to communicate with a location? Because that's what addressing based on location rather than objects implies. Normal communication would involve going into a room that wasn't empty and talking to a person or people. You aren't communicating to space itself, but rather with physical objects.
Imagine if your phone number constantly changed based on which room of the house you were in, and it continued to change as you walked around while talking with someone.
There is no use case I can conceive of where addressing a location makes more sense than addressing a particular object/person. Communication is fundamentally about objects passing information. Location is metadata or is something that is incidental to the objects communicating. Locations don't communicate, objects/people do. Therefore, objects/people should be the basis for the addressing scheme.
And when I said relativity makes the proposed plank-length location addressing idea a bitch, I really meant that it is essentially impossible.
Rounding up to 512 bit addressing allows the ~266 bit identifier to be unique (ala the typical MAC aspect of IPv6) while allowing substantial overhead for logical addressing hierarchy based on some allocation system that makes sense.
It is a sure bet that once it gets codified into a standard that we can only communicate with our universe and integrated into a host of products, we will discover that we can in fact communicate with multiple universes. Luckily, there is the likely possibility that there are a host of other universes won't make this mistake.
NAT. You know that would be the de facto solution, and I grin at the thought of future address space purists wringing their hands over the solution as much as their 21st century ancestors did...
Yeah, that'll work great, until we discover multiple universes...
The question then becomes "if there is another universe we cannot communicate with, do we really need to be able to address their physical particles with our communication networks?"
This will only solve it for people who think that addresses should be assigned to objects.
I don't know about you, but every time I am communicating with something or someone, I am communicating with something physical rather than a location.
Do you have a use case for why we should be communicating based on locations rather than physical objects? Relativity would make your idea a real bitch. Furthermore, I don't care where my server is located (and I don't want to have to care, either), but with your idea our communication would involve constantly changing IPs for every Planck time (because, no doubt, both my device and my server are constantly in motion relative to your IP addressing scheme's frame of reference).
Amazingly IPv6 will be sufficient for a long time:
2^128 IPv6 addresses * (1 atom / address) / (7*10^27 atoms/human) = 48 billion humans.
Actually, why not solve it for all time? Given the estimate of 10^80 particles in the universe, then moving to 266 bit addressing (i.e. 80/log(2)) would allow each particle to be addressed individually. Bumping to 512 bit addressing would accommodate the typical logical addressing inefficiencies.
While I agree with you this is corruption, if the choice is between a union that moves government money into the pockets of at least some citizens vs. a lobby group that moves government money into the pockets of the 0.01% then I'd rather have the former.
Keep watching and check where the new candidate moves the money to.
That's a false dichotomy. The unions and their compensation are directly responsible for my taxes being increased (sales and property taxes). Furthermore, this is not the government's money, it's the taxpayers' money that is being appropriated to feather these union people's nests.
Bringing the unions to heel involves the new mayor forcing them to accept substantive changes to their abusive compensation. This is underway, and the inevitable lawsuits are winding their way through the courts. Hopefully once these unions are defeated we will be able to roll back the special tax assessments.
So: beating the unions results in the possibility of more money for me and all the other non-millionaire/non-billionaire taxpayers like me in my city.
It's a crime what they pay police officers. They practically guarantee corruption.
I agree, but for the opposite reason you purport. In my locale, we have cops retiring on full pension in their 40's. Furthermore, until a few years ago, the cops were all "spiking" their pensions so they were pulling down $100+k/year pensions (pension pay was based on the last 18 months of income better retirement, and they all loaded up on scads of overtime during their leadup to retirement). Actuarially, they are going to live another 30+ years while drawing these $100+k/year pensions. Of course, they will immediately launch into a second career after retiring in their 40's, so their income is actually the full pension plus their new career.
That's certainly a "living wage" *cough*.
The fire and police unions are driving my city into a race to the bottom. We are half a billion dollars in the hole for the pension fund thanks to these people.
The problem is that the police/fire unions have served as "kingmakers" for the mayoral elections for the past few decades. It's no wonder their contracts have gotten "recommended" enhancements by the mayors. We finally broke the back of the union kingmakers in last year's election... a candidate they opposed won, on a platform that included bringing the unions to heel. Hopefully we can claw back the criminal amounts we are paying these people.
There is no such thing as centrifugal force... when you talk like that you basically show why dumbasses shouldn't be involved in car design.
Stock XKCD counterpoint: Centrifugal Force
Well, of course you can look at it that way, but absent the constitution or another social contract you have only the state of nature - where life is nasty, brutish and short.
Certainly you could say we have many rights protected under the constitution, but really it's just semantics; the rights exist but to fully enjoy the benefits that flow therefrom might require discretion over which rights we exercise and when and how we do so.
Your perspective is precisely why some of the Founders were against a Bill of Rights. They believed that by explicitly guaranteeing certain rights, people would start to believe that the Constitution existed to circumscribe the rights of the states and the people—when in fact, it is exactly the opposite. The Constitution was written as a whitelist of powers of the federal government. Everything else, all rights and powers, were implicitly retained by the states and/or people.
The compromise for the Bill of Rights for the Founders who opposed it was the inclusion of the 9th and 10th amendments, which serve as a reminder that the Constitution does *not* define your rights, but rather exists to restrain the government.
This distinction matters. We are not supposed to live at the whim and pleasure of our governmental "masters". Thinking about this backwards (I.e. that the government grants us our rights rather than we granting powers to the government) preconditions the construct for abuse by the government.
Again, meh. I'm really not concerned that "everything" might need to be recompiled. Distros do it for binaries in the first place (you aren't using Gentoo are you?), cloud build farm time is cheap, etc. Besides, for most of these minor updates that are supposed to "just work" (*cough*), they should only need to be re-linked, not fully recompiled.
Your proposal of manually tweaking LD_LIBRARY_PATH is not an example of what I would call "easy".
For example, if I want to run a svn or git client binary, these have massive dependencies. I shouldn't need root in order to get these running on a new machine, and I shouldn't have to deal with choosing between lib-apr breaking svn vs postgresql or hunting down 10+ libraries that are on a different major version of CentOS in order to get the minimum version level for svn that has the feature I require. I don't want to have to care which version of libc the platform has... I just want to be able to drop a self-contained binary in the directory and have it work.
This is no larger an issue than dependency tracking already is. The idea is that your distro provides the binaries, so they should also have the checksums for the individual binaries that correlate to the compilation/static linking. That is to say, if you have hash X then they know that's linked against OpenFail 0.2.3, etc. I imagine it would be a simple extension to package managers to fetch this kind of metadata.
Updates would come out via binary deltas, just like the way the Google Chrome updater works.
Give me statically compiled binaries any day (naturally YMMV on embedded platforms).
Oh yes, because having to upgrade half of the system because a bug in some library was finally fixed is sooo much better...
Meh. I'm sick of updating a shared library and having it break some client binaries while being a mandatory minimum patchlevel for others. Why do I have to choose between one set of binaries or the other? Static binaries avoid the whole damn problem.
Your cited concern does indeed represent one drawback. However it really isn't a big deal anymore: binary deltas reduce the I/O bandwidth for patching.
Do you have a counterproposal that gives fully portable, self-contained binaries that aren't subject to dependency hell? That's my goal, and statically linked binaries is just the only method I can think of to satisfy the goal.
Still, I would much rather have a binary that I can move to another installation and have it "Just Work(tm)". Dependency hell sucks, and I am sick of yak shaving simply to get a basic client binary to run. Besides, the promise of shared libs "fix once, fixed everywhere" doesn't really pan out aside from trivial cases. More frequently it's "shared library is patched, dammit... that broke several consumers. now what?"
Just give us statically compiled binaries and do a Google Chrome-style binary diff upgrade system for the clients so that network bandwidth consumption doesn't go off the charts for the distro host.
We would finally be able to have portable, standalone binaries that are free of extraneous dependencies and would run on another machine without fuss. I don't care if my 300 KB binary compiled against shared libs balloons into a 30 MB self-contained, static binary. Hell, it probably wouldn't be as bad as that, anyway.
Linux was not as polished at all, but did a few things reasonably. In particular, it had shared libraries, greatly reducing the memory requirements at a time when memory was expensive
Talk about a Faustian deal. The shared libs approach is like the legacy of a chemical waste dump... it's there, it seemed like a good idea at the time, and there is not a whole lot anyone is doing to deal with the problems it causes simply by existing. Memory and disk space are no longer expensive, but catch-22 shared library hell is forever.
Give me statically compiled binaries any day (naturally YMMV on embedded platforms).
Text, thanks.
Look: in practically every other case, I would agree with you. However, why would you want to read a post by Linus with some tweets that he copied and pasted?
Then again, after watching the video, I regret wasting that portion of my life on such a lame set of vignettes. I was expecting him to be reading some kernel dev's ragequit tweet or something. Instead, what he got was the equivalent of a handjob by his "detractors".
The whole thing was paramasturbatory for Linus. I suggest you continue with your no video policy.
With my old CRT TV, the near-60-hz image (30hz interlaced) appeared flicker free. On my old Viewsonic CRT monitor, anything less than 85hz would flicker very noticeably to me. I usually preferred to run at 120hz interlaced.
You speak truth. I could pass a double-blinded test about CRT refresh rates below 80 Hz. It was overtly obvious, even without waiting for the dreaded "low refresh rate flicker" headache to kick in.
With LCDs flicker isn't really an issue, but smearing/tearing certainly is.