My understanding of the science (some of this is recent) goes like this on this point. If you look at "paleoclimate", what you get is that the last time it was as warm as it is projected to get, the sea level was meters higher. http://www.cmar.csiro.au/sealevel/sl_proj_longer.html That is, the temperature may be predicted by models, but the melting is predicted by "history". What history lacks is a record of how fast things melt during rapid change, because past change was not as rapid as what is currently observed and predicted.
At the fast-melt end, there's this: http://www.giss.nasa.gov/research/briefs/hansen_15/ I followed the links and attempted to understand them, but did not to my satisfaction. One paper notes that we seem to be observing accelerating melt rates (but it is too soon to tell for sure). The other paper ( http://www.columbia.edu/~jeh1/mailings/2011/20110118_MilankovicPaper.pdf ) is harder to understand. One issue is the difference in methods of estimating old temperatures; ocean sediment cores give one result, ice cores give another. If you believe ice cores, we have a couple of degrees C before we hit the icecaps-melt temperature; if you believe the ocean cores, we have a few tenths of degree C (i.e., we're essentially there now). Hansen also discusses much faster icecap disintegration, but I have not followed the reference chain all the way back to the papers that reached those conclusions (it appears to be based on more paleoclimate studies, and some inferences from the rate of temperature change then versus now).
And I've been trying to make sense of the Hansen predictions, because at the high end, they suggest rates as fast as 5 centimeters per year, occurring sometime later in this century, which I think counts as alarming.
In everything that I read, I have not seen anyone who accepts the IPCC conclusions who does not also say that eventually, several meters of ocean rise worth of ice cap will melt. Obviously there's the possibility of sample bias. What I do see is a wide range of predicted time spans for that to occur, some of them on the order of a thousand years, some as short as 100.
And add, to this, as someone who spent the first half of his life living on the (humid, warm) Gulf coast, that humans living in many parts of the US would have no trouble with a warmer local climate. They'd bitch at first, but they'd adapt.
The stuff to watch out for is melting ice caps (which might raise sea levels and displace people, even people in the US), droughts (suppose last summer in Texas becomes something you see every three years), and perhaps dangerously high temperatures+humidity in various parts of the world (including central US) that would make it impossible for humans to stay cool. Low-probability-but-extremely-scary are things like the ocean doing some atmosphere-poisoning anoxic badness ( http://en.wikipedia.org/wiki/Permian–Triassic_extinction_event#Causes_of_the_extinction_event ).
There's pretty good consensus that it will be enough to melt the a lot of ice and raise the sea level. We've got paleoclimate data showing that when there's this much CO2, it gets warm, and the sea level goes up.
The question still in play, now, is how fast will the oceans rise? We do not have paleoclimate data on what happens when CO2 is cranked up this quickly; it took hundreds of years in the past, but it also took hundreds of years to crank up the CO2, so we can't draw solid conclusions.
1) Clonezilla didn't appear to be what I wanted. That's the thing where I burn a special CD, boot from that, and am given a bunch of lethal-to-data choices, and doesn't grok LVM? Also, dog-damn-slow? (Hmmm, appears to do LVM now.) Yes, I downloaded it, burned the CD, tried it, and for some reason decided that it was not working (it may have not worked, that may be why I decided that). No doubt, pilot error, but if Linux is only a friendly option for pilots more skilled than me, then it's doomed on the desktop (hint: I'm a pretty good pilot, though as a skilled pilot, not happy to have my valuable time wasted).
2) I can add a disk by plugging it in to the back. The box has SATA ports, right there. Lots of people add disks and memory to Macs, I have been doing it for years, and it is far easier than the soft side (partition, copy, make boot) of adding a disk to Linux. Physically adding a drive is just not that hard (unscrew, add plugs where they fit, rescrew, done).
3) If you're interested in selling on the desktop, all those *choices* are bad. Every choice, is a branch point in documentation and testing. Choices destroy network effects (ask my friends for help, what if they do it two different ways?)
4) Users can be expected to understand "disk", "backup", and (maybe) RAID. All that other stuff, all the steps used to accomplish the users' high level desires, that is either sausage manufacturer or digestion, and those details are scary and confusing, not helpful.
If your reply is intended seriously, it is the poster child for "why linux can't sell on the desktop". Nerds doing stuff that makes nerds happy, will only sell on the nerd desktop. Here's something that you should accept as an axiom if you expect Linux to sell on the desktop -- Clonezilla is a miserable failure. If all you can do is make excuses for why I'm wrong and it isn't an unusably borked, you're doing it wrong.
It does NOT just work. I wanted to perform the equivalent of cloning my system partition to a newer, larger drive, then I wanted to turn that into my startup disk. On a Mac, that's a quick run of SuperDuper!, followed by setting the startup disk in System Preferences. There MAY be a similarly troublefree way to do this in Linux, but I could not find it. I did, eventually, succeed. It wasn't fun. (Answer: LVM, and then I think I used grub from the command line, because the magic-friendly UI buttons didn't seem to work.)
Other gripe, adding a new disk (one of those big ones that lies about its block size), the tools were an abomination. Command-line tools were borked by the block size (ask for N gig, get N/8 gig, awesome), GUI tools would by default misalign the partitions, then tell me what a bad stupid person I was to not align the partitions, why don't you repeat the operation and see if you get a different result? And I know, after extensive Googling, that it doesn't matter that much for ext4 anyway. It's UI clusterfuck of misinformation, poorly chosen defaults, and irrelevant insults to the luser.
There's all sorts of fun stuff you can do in Linux, that does not matter to most people. My experience with MacPorts on the Mac suggests that it is possible to have a generally-useful computer that is also 90% nerd-friendly, so I think that the Linux problems are more developer-side cultural rather than technical; stuff that matters to nerds (or to companies sponsoring nerds to work on Linux) does not matter to "most people". The "wrong stuff" is what gets optimized, the stuff that matters to people who buy Macs, does not.
So here's my advice: 1) The defaults should be set right for "normal" people, in the interface that "normal" people use. Treat that interface like it is the most important one, not an afterthought. Consider operations at a high level, not a low level -- add a disk, remove a disk, backup a disk, (maybe) convert to RAID. NOT, "align a partition", "copy blocks", "install a bootloader" (and I have bootloader choices, and one of them is apparently VERY WRONG, WTF did you hand me that kryptonite for?)
2) The need to RTFM before doing anything at all is a bug. Figure out what people want to do with your tool, and give them instructions to do that, with progressive disclosure as they get more confident, adventurous, interested.
3) If you're going to have desktop design battles, don't inflict them on "normal" people. I cannot even keep track of GNOME-this versus KDE-that, let alone what the alleged merits are. (Did KDE lose?)
4) Learn to write instructions. "Documentation" is the wrong word, I think it gives people the idea that if you simply mention every detail, it is "documented". Don't use vague terms like "appropriate". Give examples. Ask yourself, whenever writing down unambiguous instructions (a) why is it so hard to write unambiguous instructions -- do we have gratuitous variation between different flavors of Linux? how can that be eliminated and (b) why isn't this a bash/python/whatever script, activated by a button press? If you can't explain it carefully enough for a computer to follow the instructions, are you sure you really understand how to explain it? If the result has ten knobs to be set before the button press, are the knobs really necessary? Are the ones that are necessary, explained? Is there an "undo" button?
Oh hell, if you're going to cheap out on audio performance, you might as well just use coat hangers twisted into wires. Bah! A true audiophile would never compromise on price.
If they're so smart, how come they're running out of gas? You beg for gas, at the gas station, with your little gas can. Or you get a ride there, and the guy who gives you a ride, also helps you fill the gas can.
The inconvenience of "excuse me, can you help me fill my gas can? I ran out 2 miles up the road" is tiny compared to the inconvenience of walking those two miles. If this is the biggest flaw in this plan, then this is a great plan.
Since the 80s at least. Was a college radio DJ back then, Blue Oyster Cult had a Godzilla single that after the first few seconds held the VU meters still at a single reading. Very useful for calibrating your levels and power output without your listeners knowing you were playing a test signal.
I hope your optical cables are made of sapphire, and not glass. Everyone knows that glass flows slowly over time, which ultimately leads to a pear-shaped fiber cross-section and bit disequalization.
Sure you haven't, but I've made plenty, and somehow, I have never gotten around to making this one. It requires really poor planning and sustained inattention to run out of gasoline, and even if you do, surely you can beg a favor from someone at the gas station to get your can filled. This is just not important enough an objection to care.
And Massachusetts has mandatory auto insurance, and their traffic fatality rate is even lower. http://www.census.gov/statab/ranks/rank39.html I'm not sure that datapoint works for you -- it could be more demographic, size of state, design of roads (there's a scary thought, given the state of road "design" around here). I don't think insurance here is especially cheap, though.
His statement is not quite proved false. "He doesn't think..." If that is an accurate description of his mistaken belief, then the statement is true. Not necessarily useful, but true. His *belief* is proved false.
Just for reference, I have a PhD, I work on compilers and runtime systems. People like me program in assembly, we program in HLLs, whatever works. We will (for actual example) pore over 88 pages of assembly-language output from a compiler in order to find the register allocation bug. Other people I've worked with on compilers (some with PhDs, some not) do things like diagnosing a C optimizer bug based only on the C++ input to cfront (later run through a C compiler) and the busted output, or, after pondering the full set of symptoms, (correctly) diagnose a "compiler bug" as a lack of thermal compound between CPU and heat sink (over the phone!)
You get good at this stuff when you do it full-time, and a compiler/debugger person who had come across this language in the past would probably ID it confidently. It's probably NOT something that passed through a C compiler, because those still have calling conventions, structure layout conventions, and other funny idioms that would still be obvious to someone familiar with C compilers on that platform (which presumably the guys at Kaspersky are).
Your statement is not universally true; I am a counterexample. Dieting is not easy (for me). Riding my bike to work and on random errands is. Riding my bike caused me to lose about 15-20lbs pretty quickly and keep it off for years, plus I get to enjoy meals and/or beer.
and in some, the mere presence of an opened container of alcohol in a moving vehicle is against the law. Florida is that way, or was when I was younger.
In this country, with the exception of high speed roads ("limited access highways"), bicycles are allowed on all roads. Drivers are supposed to pay attention and drive in a way that makes this a safe choice for the cyclists. Reality diverges from theory, of course, though it is one of those things were most people are great, another chunk is clueless but well-meaning, and then there's a small number of inconsiderate bozos who ruins it for everyone. I determined this experimentally with a rear-facing camera on one of my (bicycle) commutes; very many people would see me and take sensible steps before I was even aware of them (at quite some distance, true defensive driving).
They ARE more dangerous, and politically, we love it; mortality rates are higher for commuters who only drive, who do not walk or bike, but the deaths come from nice civilized heart attacks, strokes, and other diseases of the sedentary. Try to get in the way of that, and "help, help, I'm being repressed!" What we need, is for cars to SEEM more dangerous. Reality doesn't matter -- if it did, everyone would get a LOT more exercise than they do.
Perhaps there is a level of intoxication that is unsafe and detectable post-crash, yet not apparent in "ordinary driving". Could be that there's lots more drunk drivers than you think.
Being drunk also has the property that (as noted above) you cannot stop being drunk. People may not be smart enough to put the phone down entering a risky situation, but they may be smart enough to put the phone down (and lie about its use) AFTER the crash.
On the other hand, given the number of people I see on the phone, you'd expect an uptick in the overall accident rate if it were significantly dangerous in real driving.
Slashdot Mirror
My understanding of the science (some of this is recent) goes like this on this point. If you look at "paleoclimate", what you get is that the last time it was as warm as it is projected to get, the sea level was meters higher. http://www.cmar.csiro.au/sealevel/sl_proj_longer.html That is, the temperature may be predicted by models, but the melting is predicted by "history". What history lacks is a record of how fast things melt during rapid change, because past change was not as rapid as what is currently observed and predicted.
At the fast-melt end, there's this: http://www.giss.nasa.gov/research/briefs/hansen_15/ I followed the links and attempted to understand them, but did not to my satisfaction. One paper notes that we seem to be observing accelerating melt rates (but it is too soon to tell for sure). The other paper ( http://www.columbia.edu/~jeh1/mailings/2011/20110118_MilankovicPaper.pdf ) is harder to understand. One issue is the difference in methods of estimating old temperatures; ocean sediment cores give one result, ice cores give another. If you believe ice cores, we have a couple of degrees C before we hit the icecaps-melt temperature; if you believe the ocean cores, we have a few tenths of degree C (i.e., we're essentially there now). Hansen also discusses much faster icecap disintegration, but I have not followed the reference chain all the way back to the papers that reached those conclusions (it appears to be based on more paleoclimate studies, and some inferences from the rate of temperature change then versus now).
And I've been trying to make sense of the Hansen predictions, because at the high end, they suggest rates as fast as 5 centimeters per year, occurring sometime later in this century, which I think counts as alarming.
Well, there's this: http://www.post-carbon-living.com/TTHW/Documents/Climate_Change_Consensus.pdf
I don't think that will do it for you.
In everything that I read, I have not seen anyone who accepts the IPCC conclusions who does not also say that eventually, several meters of ocean rise worth of ice cap will melt. Obviously there's the possibility of sample bias. What I do see is a wide range of predicted time spans for that to occur, some of them on the order of a thousand years, some as short as 100.
IPCC
And add, to this, as someone who spent the first half of his life living on the (humid, warm) Gulf coast, that humans living in many parts of the US would have no trouble with a warmer local climate. They'd bitch at first, but they'd adapt.
The stuff to watch out for is melting ice caps (which might raise sea levels and displace people, even people in the US), droughts (suppose last summer in Texas becomes something you see every three years), and perhaps dangerously high temperatures+humidity in various parts of the world (including central US) that would make it impossible for humans to stay cool. Low-probability-but-extremely-scary are things like the ocean doing some atmosphere-poisoning anoxic badness ( http://en.wikipedia.org/wiki/Permian–Triassic_extinction_event#Causes_of_the_extinction_event ).
There's pretty good consensus that it will be enough to melt the a lot of ice and raise the sea level. We've got paleoclimate data showing that when there's this much CO2, it gets warm, and the sea level goes up.
The question still in play, now, is how fast will the oceans rise? We do not have paleoclimate data on what happens when CO2 is cranked up this quickly; it took hundreds of years in the past, but it also took hundreds of years to crank up the CO2, so we can't draw solid conclusions.
Not true. http://epa.gov/climatechange/emissions/usinventoryreport.html
I can't tell if you're serious or joking.
1) Clonezilla didn't appear to be what I wanted.
That's the thing where I burn a special CD, boot from that, and am given a bunch of lethal-to-data choices, and doesn't grok LVM? Also, dog-damn-slow? (Hmmm, appears to do LVM now.) Yes, I downloaded it, burned the CD, tried it, and for some reason decided that it was not working (it may have not worked, that may be why I decided that). No doubt, pilot error, but if Linux is only a friendly option for pilots more skilled than me, then it's doomed on the desktop (hint: I'm a pretty good pilot, though as a skilled pilot, not happy to have my valuable time wasted).
2) I can add a disk by plugging it in to the back. The box has SATA ports, right there. Lots of people add disks and memory to Macs, I have been doing it for years, and it is far easier than the soft side (partition, copy, make boot) of adding a disk to Linux. Physically adding a drive is just not that hard (unscrew, add plugs where they fit, rescrew, done).
3) If you're interested in selling on the desktop, all those *choices* are bad. Every choice, is a branch point in documentation and testing. Choices destroy network effects (ask my friends for help, what if they do it two different ways?)
4) Users can be expected to understand "disk", "backup", and (maybe) RAID. All that other stuff, all the steps used to accomplish the users' high level desires, that is either sausage manufacturer or digestion, and those details are scary and confusing, not helpful.
If your reply is intended seriously, it is the poster child for "why linux can't sell on the desktop". Nerds doing stuff that makes nerds happy, will only sell on the nerd desktop. Here's something that you should accept as an axiom if you expect Linux to sell on the desktop -- Clonezilla is a miserable failure. If all you can do is make excuses for why I'm wrong and it isn't an unusably borked, you're doing it wrong.
It does NOT just work. I wanted to perform the equivalent of cloning my system partition to a newer, larger drive, then I wanted to turn that into my startup disk. On a Mac, that's a quick run of SuperDuper!, followed by setting the startup disk in System Preferences. There MAY be a similarly troublefree way to do this in Linux, but I could not find it. I did, eventually, succeed. It wasn't fun. (Answer: LVM, and then I think I used grub from the command line, because the magic-friendly UI buttons didn't seem to work.)
Other gripe, adding a new disk (one of those big ones that lies about its block size), the tools were an abomination. Command-line tools were borked by the block size (ask for N gig, get N/8 gig, awesome), GUI tools would by default misalign the partitions, then tell me what a bad stupid person I was to not align the partitions, why don't you repeat the operation and see if you get a different result? And I know, after extensive Googling, that it doesn't matter that much for ext4 anyway. It's UI clusterfuck of misinformation, poorly chosen defaults, and irrelevant insults to the luser.
There's all sorts of fun stuff you can do in Linux, that does not matter to most people. My experience with MacPorts on the Mac suggests that it is possible to have a generally-useful computer that is also 90% nerd-friendly, so I think that the Linux problems are more developer-side cultural rather than technical; stuff that matters to nerds (or to companies sponsoring nerds to work on Linux) does not matter to "most people". The "wrong stuff" is what gets optimized, the stuff that matters to people who buy Macs, does not.
So here's my advice:
1) The defaults should be set right for "normal" people, in the interface that "normal" people use.
Treat that interface like it is the most important one, not an afterthought.
Consider operations at a high level, not a low level -- add a disk, remove a disk, backup a disk, (maybe) convert to RAID. NOT, "align a partition", "copy blocks", "install a bootloader" (and I have bootloader choices, and one of them is apparently VERY WRONG, WTF did you hand me that kryptonite for?)
2) The need to RTFM before doing anything at all is a bug. Figure out what people want to do with your tool, and give them instructions to do that, with progressive disclosure as they get more confident, adventurous, interested.
3) If you're going to have desktop design battles, don't inflict them on "normal" people. I cannot even keep track of GNOME-this versus KDE-that, let alone what the alleged merits are. (Did KDE lose?)
4) Learn to write instructions. "Documentation" is the wrong word, I think it gives people the idea that if you simply mention every detail, it is "documented". Don't use vague terms like "appropriate". Give examples. Ask yourself, whenever writing down unambiguous instructions (a) why is it so hard to write unambiguous instructions -- do we have gratuitous variation between different flavors of Linux? how can that be eliminated and (b) why isn't this a bash/python/whatever script, activated by a button press? If you can't explain it carefully enough for a computer to follow the instructions, are you sure you really understand how to explain it? If the result has ten knobs to be set before the button press, are the knobs really necessary? Are the ones that are necessary, explained? Is there an "undo" button?
Oh hell, if you're going to cheap out on audio performance, you might as well just use coat hangers twisted into wires. Bah! A true audiophile would never compromise on price.
If they're so smart, how come they're running out of gas? You beg for gas, at the gas station, with your little gas can. Or you get a ride there, and the guy who gives you a ride, also helps you fill the gas can.
The inconvenience of "excuse me, can you help me fill my gas can? I ran out 2 miles up the road" is tiny compared to the inconvenience of walking those two miles. If this is the biggest flaw in this plan, then this is a great plan.
I thought you wanted a superconducting feed, cooled with Helium 3, not 4, because the lower atomic weight provides better heat transfer.
Since the 80s at least. Was a college radio DJ back then, Blue Oyster Cult had a Godzilla single that after the first few seconds held the VU meters still at a single reading. Very useful for calibrating your levels and power output without your listeners knowing you were playing a test signal.
I hope your optical cables are made of sapphire, and not glass. Everyone knows that glass flows slowly over time, which ultimately leads to a pear-shaped fiber cross-section and bit disequalization.
Sure you haven't, but I've made plenty, and somehow, I have never gotten around to making this one. It requires really poor planning and sustained inattention to run out of gasoline, and even if you do, surely you can beg a favor from someone at the gas station to get your can filled. This is just not important enough an objection to care.
And Massachusetts has mandatory auto insurance, and their traffic fatality rate is even lower.
http://www.census.gov/statab/ranks/rank39.html
I'm not sure that datapoint works for you -- it could be more demographic, size of state, design of roads (there's a scary thought, given the state of road "design" around here). I don't think insurance here is especially cheap, though.
His statement is not quite proved false. "He doesn't think ..." If that is an accurate description of his mistaken belief, then the statement is true. Not necessarily useful, but true. His *belief* is proved false.
I've been driving for 35 years, and I have never, ever run out of gas. How is this not an instance of life is harder when you're dumb?
Just for reference, I have a PhD, I work on compilers and runtime systems. People like me program in assembly, we program in HLLs, whatever works. We will (for actual example) pore over 88 pages of assembly-language output from a compiler in order to find the register allocation bug. Other people I've worked with on compilers (some with PhDs, some not) do things like diagnosing a C optimizer bug based only on the C++ input to cfront (later run through a C compiler) and the busted output, or, after pondering the full set of symptoms, (correctly) diagnose a "compiler bug" as a lack of thermal compound between CPU and heat sink (over the phone!)
You get good at this stuff when you do it full-time, and a compiler/debugger person who had come across this language in the past would probably ID it confidently. It's probably NOT something that passed through a C compiler, because those still have calling conventions, structure layout conventions, and other funny idioms that would still be obvious to someone familiar with C compilers on that platform (which presumably the guys at Kaspersky are).
Your statement is not universally true; I am a counterexample. Dieting is not easy (for me). Riding my bike to work and on random errands is. Riding my bike caused me to lose about 15-20lbs pretty quickly and keep it off for years, plus I get to enjoy meals and/or beer.
It'll make you stranger, more likely.
Knitting. Yes, I have seen it (sitting up high on a bicycle, while I pass cars and vice-versa).
and in some, the mere presence of an opened container of alcohol in a moving vehicle is against the law. Florida is that way, or was when I was younger.
In this country, with the exception of high speed roads ("limited access highways"), bicycles are allowed on all roads. Drivers are supposed to pay attention and drive in a way that makes this a safe choice for the cyclists. Reality diverges from theory, of course, though it is one of those things were most people are great, another chunk is clueless but well-meaning, and then there's a small number of inconsiderate bozos who ruins it for everyone. I determined this experimentally with a rear-facing camera on one of my (bicycle) commutes; very many people would see me and take sensible steps before I was even aware of them (at quite some distance, true defensive driving).
They ARE more dangerous, and politically, we love it; mortality rates are higher for commuters who only drive, who do not walk or bike, but the deaths come from nice civilized heart attacks, strokes, and other diseases of the sedentary. Try to get in the way of that, and "help, help, I'm being repressed!" What we need, is for cars to SEEM more dangerous. Reality doesn't matter -- if it did, everyone would get a LOT more exercise than they do.
Perhaps there is a level of intoxication that is unsafe and detectable post-crash, yet not apparent in "ordinary driving". Could be that there's lots more drunk drivers than you think.
Being drunk also has the property that (as noted above) you cannot stop being drunk. People may not be smart enough to put the phone down entering a risky situation, but they may be smart enough to put the phone down (and lie about its use) AFTER the crash.
On the other hand, given the number of people I see on the phone, you'd expect an uptick in the overall accident rate if it were significantly dangerous in real driving.