Complete incremental backup of computer to network drive, usb drive, whatever.
Because we all know Windows computers can't do that.
nfs, and sshfs. They really are awesome. Windows/mac users don't even know what they are missing.
SSHFS I'll give you, because that would be awesome. But NFS? Besides a question of whether NFS even holds a candle to something like CIFS (I can't speak to NFSv4, but I'd use CIFS before any previous version of NFS any day of the week), Windows has an NFS server and client.
Complain if you will, but I prefer.files and.folders to the obfuscated and cryptic Windows registry...
Yes, but to me, that's like saying "I prefer getting slapped in the face to kicked in the nuts."
The cluttering of ~ with.crap is one of the things that bugs me most about Linux from a practical level, because it puts me in a conundrum. Do set things like my file open dialogs to show all my.shit and deal with close to 200 directories and files cluttering stuff up, or do I turn it off and make it a PITA to actually go into those directories when I want to (which is not terribly uncommon)?
The right way to do this would be to start putting configuration stuff in a subdirectory. (Those were invented for a reason...) Some programs do this right and use.config, but not many.
(To expand on the registry comparison, the Unix method way is a bit annoying more often. The registry is infrequently annoying, but when it is it can be crippling.)
Though it is a pretty big rip off of OSX and for those that remember, OS/2.
I can't speak to OS/2, but I'd say the Win7 taskbar isn't that much a bigger rip off the OS X dock than the dock was off of the old-style taskbar.
For instance, my long-term impression (admittedly from the relatively little I've used OS X; I could be missing something; OTOH I didn't exactly read a Windows manual or anything like that) of the OS X dock is that it's fine for opening programs, but it sucks for window management. There's almost nothing you can do in that arena with the dock that couldn't be done easier with alt-tab and alt-` or whatever the 'next application' and 'next window' buttons are.
For OS X, this is fine, because it has another nice window management feature: expose. Windows doesn't have this, so if the Win7 taskbar was as crap for switching windows as the dock is, it'd be unusable. But fortunately this isn't the case.
I'm with you 100% on the murder comment; I don't think anyone (let's ignore minors for a sec; that would open a whole ball-of-wax) who commits 1st degree murder (which this sounds like) should get less than lift-without-parole.
However, the goal of the law in more general terms is actually a pretty good idea. Reducing recidivism rates requires that people who get out of jail actually have a shot at getting a decent job and continuing on with their life. Having a criminal background can make this very difficult.
People always complain about Windows programs not being available on Linux. I have the complete opposite opinion. Of all the tools and programs I take for granted on a *nix system, few are available for Windows (modulo a 500MB Cygwin installation), and what does exist, typically sucks.
Wow, different OSes work well for different people in different situations. Who'd have thunk it?
...it does have perhaps the nicest screen of any portable device on the market right now. Most smart phones have low-resolution screens.
Really?! I'm looking at specs now; by what I see, the Zune HD 32 has a 480x272 pixel screen.
There are quite a few smart phones out there with better than that. The Droid has 480 x 854; the HTC hero has 320x480; the Nokia N900 has 800x480. Even the iPhone, which doesn't have stellar resolution, is 480x320.
es now are based on quick expansions example 12nexus 14cc 12 hatch
12 hatch you definitely see; that's one of the most common openings for zerg, I think in all three matchups. 12 nexus you'll see occasionally, but forge fast expand is more common, especially vs zerg. (The thing that will change there is whether the protoss plants the nexus or a photon cannon first; that decision is based on scouting information.) However, 14cc is a pretty risky strategy, and at least at the level of pro play is considered a bit cheesy. For instance, if you are terran vs a zerg, if you 14cc and the zerg 9 pools (not uncommon even if 12 pool or 12 hatch is more common), you're almost certainly sunk. 1rax or 1fact into expand (e.g. the fake double) is much more common for terran.
The overall gist of what you say is right though; SC has gotten way more macro heavy over the past few years.
I've never seen early expansion work properly in any of the pro matches I've watched, which to be honest is just short of a dozen so I'm not the know it all.
When did you watch? Forge fast-expand is the usual play for Protoss vs Zerg, and you almost never *don't* see a FE by Zerg vs either Terran or Protoss.
Every matchup except for Zerg vs. Zerg starts with EXTREMELY fast expanding these days. Usually before they even have a single non-peon unit out
That's not really true, at least the latter part. Protoss will often forge fast-expand, especially against Zerg, but other openings like one gate tech aren't uncommon. For terran, you almost never see expand-before-marine, and often there's no expand until the factory is building.
So you *see* FEs like that in each matchup, I wouldn't call them *the* standard build except for Zerg in ZvT and both sides in ZvP.
Depends where you look. Last month's KESPA ratings (the latest, at least on TLPD) put Jaedong at #1 and flash down at #6. In fact, the last time he wasn't #1 in that ranking was March.
Ah, okay. Bad antecedents. I took "that advantage" in your post to refer to "C++ has templates" from the OP. (This still stands; there are a number of things you can do with templates that you can't do with generics.)
privileges are elevated for a single helper binary that (assuming it was written well) is a narrowly defined piece of code...
And there's the rub. As the other person replying to you said, the situation isn't much different on Windows. You can still have well-written programs that behave the way you want.
The problem with the Windows security model is much more with crappy programs due to the crappy security model in the past than it is with any real objective problems in today's model....you would have to first compromise the non-root application sufficient to execute arbitrary code, then find a second exploitable vulnerability in the much smaller root helper code
I don't necessarily buy this either, maybe because I don't know enough about the OS X security model.
Let me ask this: are the helper programs application-specific, or are they things like 'install' that are system-wide?
I can imagine Microsoft engineers asking the same question and concluding that people think sudo is a good thing, so automatic user friendly sudo everywhere is by extension a good thing.
I suspect it was more an effort to make programs that assume admin rights (of which we all know there are tons) less obnoxious. I mean, that'd really suck to work with a program for 10 minutes, go to do something, and have the operation denied because you didn't start it with sudo. That's the sort of thing that would cause all but the very very most security-focused people (i.e. not me) to turn off UAC.
(After all, Windows NT has had the ability to start programs as other users (like su) for a long time now; that particular ability isn't new. It's only the on-demand escalation that is.)
Knowing when to use something less powerful instead of sudo is an important, pervasive, and ongoing conscious part of the "Linux sudo model." That's how it's different.
I still don't particularly buy the differences you state though, or at least buy that it's a particularly useful tradeoff.
First of all, there's definitely a security-vs-usability tradeoff here. If xsane fails with a permission denied error, the user has to go and investigate how to set up things right, then do it. Even if the permission denied dialog itself gave instructions, users don't really read them. (Though in that extreme, I start to lose empathy.) Compare that to the UAC world, where you get a popup that you have to clear to continue. Lose a little security, but gain quite a bit of convenience. (Especially if it's something you do infrequently. If you do it often, then setting things up right with the Unix model will mean it works smoothly, while you'll still get a UAC prompt each time with the Windows model.)
Now note that even the security increase in the Unix model isn't absolute. How do you set it up to get the necessary permissions? You add yourself to the 'scanner' group or whatever to get permissions to the necessary device nodes. Okay, in the case of the scanner, this is not a big deal, but what this means is that if you trust a particular program more than you trust other programs you run from having access to a resource, then you should run that program as root. This fact shouldn't be a surprise; it's basically why we need sudo in the first place.
But my contention is that the set of programs that fit the "asks for UAC rights on Windows but would be better satisfied by more granular permission changes" (like xsane) is very small, and that almost everything that asks for UAC elevation falls into the "run this program as sudo" category. Certainly my anecdotal "feeling" supports this contention, but I also did a slightly more careful experiment when I first switched to Vista. The result of it was that almost every elevation request I got for a month (I kept a log) was for some action where the equivalent on Linux would have required sudo rights anyway. The main exceptions were (1) changing environment variables (in Vista the terrible dialog where you change user-local and system-wide variables is the same, and MS didn't go out of their way to make it possible to change user-local ones) and (2) this one crappy hardware monitoring software I was using for some reason.
Basically everything else was like system config changes that would have required root on Linux or program installations, which also require root on Linux. (Well, okay, you can usually do configure/make/make install without root. But only then if you're really masochistic, because that drops you back to the hell of resolving dependencies that made Linux a PITA to use before package managers. Virtually none of the package managers out there work without root.)
So theoretically speaking... I can buy your argument. Practically speaking, I think it makes basically no difference whatsoever.
The first parts of your post are fine... but I have problems starting about here:
Also, I'm under the impression (based on the patent) that Windows is temporarily elevating the privileges of the application itself, which means that you now have a much larger chunk of code that must be checked for security holes, lest malicious individuals co-opt the application for nefarious purposes.
How is this different from the Linux sudo model or Apple's AuthorizationExecuteWithPrivileges? With that model, you start a process under sudo and it gets admin rights for the duration of the process.
By the "proportion of the code running with elevation" metric, Windows should actually be better in this regard, since the time between when the process starts to when it first elevates will be run without admin rights.
Such a design also makes it very hard to adequately use code signing to ensure the authenticity of the code running with elevated privileges...
As opposed to Sudo, which doesn't check the signature of the executable being run at all (at least AFAIK)?
I meant to say one more thing. Ever been at the command prompt, issued a command as a normal user that needs root, gotten a failure, and gone "doh, forgot to run it as root", hit the up arrow, and put a sudo before it?
With sudo-style elevation, you need to do that. This is what Gnome or whatever is doing behind the scenes when you open a configuration dialog that needs root (except that it never forgets!).
The UAC, this-patent-way of doing it would be for your initial attempt to cause Linux to say "this program is trying to do something that needs root, is that what you wanted?" and give you a password prompt then.
Can you please explain why this is different than the patent?
To the end user, it will appear (nearly) the same.
However, the architecture is rather different, at least compared the sudo case. In the sudo case, if a program runs with insufficient rights, it will simply fail. Because of this, a program that wants a dialog to pop up if the user does something (e.g. click "install") must take proactive actions to achieve this: it must explicitly call sudo.
By contrast, what UAC does (and that's what this patent is talking about) is watches requests from a program; if it requests something it doesn't have rights to, then the OS will display the elevation prompt.
To witness the effects of this, try installing software on Vista or Win 7. Some installers ask for elevations up front, but not all; others will let you go through the initial steps (e.g. choosing which parts to install, setting a target directory) without elevation, and then present the UAC prompt when it starts to install.
In other words, by my understanding:
- sudo cannot elevate an existing process
- UAC does elevate existing processes
I strongly suspect the same thing is true of OS X, though I can't speak with complete confidence in that matter.
I don't want to argue that the patent is valid or anything like that, but there is a pretty big difference.
Sugar isn't as bad as HFCS is. Just replacing HFCS with the same amount of calories in real sugar will already help.
Will it?
Coincidentally, I just yesterday saw a very interesting video about the body's processing of sugar. (Warning: this is very long, and has about 40 minutes of biochem in the middle that supposedly explains how fructose consumption contributes to hypertension, obesity, diabetes, etc. that I have no remotely realistic way of evaluating.) The thesis of the guy's talk in a nutshell is that "fructose is a poison".
Basically he said, "you know all those things people are saying about HFCS being bad for you? It's all true. HFCS is terrible for you." But, he also said that "real" sugar, sucrose, is basically no different nutritionally.
HFCS is (as he said an Wikipedia supports) basically a mix of glucose (which is fine/good for you) and fructose, at about a 50% mixture. (Wikipedia says two common variants are 55% fructose and 42% fructose.) But what's sucrose? Sucrose is (as he said and, again, Wikipedia supports) basically a glucose and a fructose molecule bonded together. (There's a missing H on one of the OH pairs on each, and that bond is spent on bonding the molecules together.) But what happens to sucrose in the stomach? An enzyme called glycoside hydrolase metabolizes the sucrose and just splits the damn thing up into sucrose and fructose!
The bottom line? Within a few percent, the nutritional content of sugar and HFCS is basically the same!
(Incidentally the corn industry has been putting out some studies that support this. The corn industry of course would like you to believe that HFCS isn't that bad because it's the same as sugar; this guy's point was that these studies are actually 100% correct, but because sugar is just as terrible as HFCS is.)
The problem, he contends, is that the total volume of sugar (sucrose + HFCS), and fructose in particular, has gone up substantially over the past couple decades. Because HFCS is so cheap, companies are putting it in everything, even things that they'd never ever have put sugar in before HFCS was invented. Furthermore, HFCS is a bit sweeter than sugar is, so you should be able to use a little less of it in things that are "supposed to be" sweet -- but companies don't. Finally, he says that nature's natural "antidote" to fructose is fiber, but people don't get enough fiber.
I can't really evaluate his claims in general -- I did some searching but couldn't really find any critiques from people who, say, used evidence to support their position. However, at least the HFCS/sucrose equivalence at least looks good from what I've seen.
Hydrogren peroxide is a common home remedy for ear-aches and wax buildup.
See, I didn't even know that and I still thought it was a reasonable question. I just assumed that someone got a cut or something inside their ear somehow and wanted to disinfect it.
Why is the peroxide question that stupid? The only thing I can think of is that the person probably meant 'hydrogen peroxide', and then I think it's a pretty reasonable question.
Slashdot Mirror
Complete incremental backup of computer to network drive, usb drive, whatever.
Because we all know Windows computers can't do that.
nfs, and sshfs. They really are awesome. Windows/mac users don't even know what they are missing.
SSHFS I'll give you, because that would be awesome. But NFS? Besides a question of whether NFS even holds a candle to something like CIFS (I can't speak to NFSv4, but I'd use CIFS before any previous version of NFS any day of the week), Windows has an NFS server and client.
[I'm not the OP, but I do agree with him.]
Complain if you will, but I prefer .files and .folders to the obfuscated and cryptic Windows registry...
Yes, but to me, that's like saying "I prefer getting slapped in the face to kicked in the nuts."
The cluttering of ~ with .crap is one of the things that bugs me most about Linux from a practical level, because it puts me in a conundrum. Do set things like my file open dialogs to show all my .shit and deal with close to 200 directories and files cluttering stuff up, or do I turn it off and make it a PITA to actually go into those directories when I want to (which is not terribly uncommon)?
The right way to do this would be to start putting configuration stuff in a subdirectory. (Those were invented for a reason...) Some programs do this right and use .config, but not many.
(To expand on the registry comparison, the Unix method way is a bit annoying more often. The registry is infrequently annoying, but when it is it can be crippling.)
Though it is a pretty big rip off of OSX and for those that remember, OS/2.
I can't speak to OS/2, but I'd say the Win7 taskbar isn't that much a bigger rip off the OS X dock than the dock was off of the old-style taskbar.
For instance, my long-term impression (admittedly from the relatively little I've used OS X; I could be missing something; OTOH I didn't exactly read a Windows manual or anything like that) of the OS X dock is that it's fine for opening programs, but it sucks for window management. There's almost nothing you can do in that arena with the dock that couldn't be done easier with alt-tab and alt-` or whatever the 'next application' and 'next window' buttons are.
For OS X, this is fine, because it has another nice window management feature: expose. Windows doesn't have this, so if the Win7 taskbar was as crap for switching windows as the dock is, it'd be unusable. But fortunately this isn't the case.
I'm with you 100% on the murder comment; I don't think anyone (let's ignore minors for a sec; that would open a whole ball-of-wax) who commits 1st degree murder (which this sounds like) should get less than lift-without-parole.
However, the goal of the law in more general terms is actually a pretty good idea. Reducing recidivism rates requires that people who get out of jail actually have a shot at getting a decent job and continuing on with their life. Having a criminal background can make this very difficult.
*woosh*
People always complain about Windows programs not being available on Linux. I have the complete opposite opinion. Of all the tools and programs I take for granted on a *nix system, few are available for Windows (modulo a 500MB Cygwin installation), and what does exist, typically sucks.
Wow, different OSes work well for different people in different situations. Who'd have thunk it?
(Sorry for the snark there.)
I know I spend way too much time at \.
...it does have perhaps the nicest screen of any portable device on the market right now. Most smart phones have low-resolution screens.
Really?! I'm looking at specs now; by what I see, the Zune HD 32 has a 480x272 pixel screen.
There are quite a few smart phones out there with better than that. The Droid has 480 x 854; the HTC hero has 320x480; the Nokia N900 has 800x480. Even the iPhone, which doesn't have stellar resolution, is 480x320.
es now are based on quick expansions example 12nexus 14cc 12 hatch
12 hatch you definitely see; that's one of the most common openings for zerg, I think in all three matchups. 12 nexus you'll see occasionally, but forge fast expand is more common, especially vs zerg. (The thing that will change there is whether the protoss plants the nexus or a photon cannon first; that decision is based on scouting information.) However, 14cc is a pretty risky strategy, and at least at the level of pro play is considered a bit cheesy. For instance, if you are terran vs a zerg, if you 14cc and the zerg 9 pools (not uncommon even if 12 pool or 12 hatch is more common), you're almost certainly sunk. 1rax or 1fact into expand (e.g. the fake double) is much more common for terran.
The overall gist of what you say is right though; SC has gotten way more macro heavy over the past few years.
I've never seen early expansion work properly in any of the pro matches I've watched, which to be honest is just short of a dozen so I'm not the know it all.
When did you watch? Forge fast-expand is the usual play for Protoss vs Zerg, and you almost never *don't* see a FE by Zerg vs either Terran or Protoss.
Every matchup except for Zerg vs. Zerg starts with EXTREMELY fast expanding these days. Usually before they even have a single non-peon unit out
That's not really true, at least the latter part. Protoss will often forge fast-expand, especially against Zerg, but other openings like one gate tech aren't uncommon. For terran, you almost never see expand-before-marine, and often there's no expand until the factory is building.
So you *see* FEs like that in each matchup, I wouldn't call them *the* standard build except for Zerg in ZvT and both sides in ZvP.
Depends where you look. Last month's KESPA ratings (the latest, at least on TLPD) put Jaedong at #1 and flash down at #6. In fact, the last time he wasn't #1 in that ranking was March.
Ah, okay. Bad antecedents. I took "that advantage" in your post to refer to "C++ has templates" from the OP. (This still stands; there are a number of things you can do with templates that you can't do with generics.)
Wait, I don't understand. Why would you come to /. if you don't want to read a bad analogy?
Your criticism of errors stand, but let me see if I understand your argument in this post. I'll paraphrase:
1) C++ has templates
2) Java has generics
3) Generics are not templates
4) Thus... this proves that C++ doesn't have the advantage of templates
Did I get that right?
privileges are elevated for a single helper binary that (assuming it was written well) is a narrowly defined piece of code...
And there's the rub. As the other person replying to you said, the situation isn't much different on Windows. You can still have well-written programs that behave the way you want.
The problem with the Windows security model is much more with crappy programs due to the crappy security model in the past than it is with any real objective problems in today's model. ...you would have to first compromise the non-root application sufficient to execute arbitrary code, then find a second exploitable vulnerability in the much smaller root helper code
I don't necessarily buy this either, maybe because I don't know enough about the OS X security model.
Let me ask this: are the helper programs application-specific, or are they things like 'install' that are system-wide?
I can imagine Microsoft engineers asking the same question and concluding that people think sudo is a good thing, so automatic user friendly sudo everywhere is by extension a good thing.
I suspect it was more an effort to make programs that assume admin rights (of which we all know there are tons) less obnoxious. I mean, that'd really suck to work with a program for 10 minutes, go to do something, and have the operation denied because you didn't start it with sudo. That's the sort of thing that would cause all but the very very most security-focused people (i.e. not me) to turn off UAC.
(After all, Windows NT has had the ability to start programs as other users (like su) for a long time now; that particular ability isn't new. It's only the on-demand escalation that is.)
Knowing when to use something less powerful instead of sudo is an important, pervasive, and ongoing conscious part of the "Linux sudo model." That's how it's different.
I still don't particularly buy the differences you state though, or at least buy that it's a particularly useful tradeoff.
First of all, there's definitely a security-vs-usability tradeoff here. If xsane fails with a permission denied error, the user has to go and investigate how to set up things right, then do it. Even if the permission denied dialog itself gave instructions, users don't really read them. (Though in that extreme, I start to lose empathy.) Compare that to the UAC world, where you get a popup that you have to clear to continue. Lose a little security, but gain quite a bit of convenience. (Especially if it's something you do infrequently. If you do it often, then setting things up right with the Unix model will mean it works smoothly, while you'll still get a UAC prompt each time with the Windows model.)
Now note that even the security increase in the Unix model isn't absolute. How do you set it up to get the necessary permissions? You add yourself to the 'scanner' group or whatever to get permissions to the necessary device nodes. Okay, in the case of the scanner, this is not a big deal, but what this means is that if you trust a particular program more than you trust other programs you run from having access to a resource, then you should run that program as root. This fact shouldn't be a surprise; it's basically why we need sudo in the first place.
But my contention is that the set of programs that fit the "asks for UAC rights on Windows but would be better satisfied by more granular permission changes" (like xsane) is very small, and that almost everything that asks for UAC elevation falls into the "run this program as sudo" category. Certainly my anecdotal "feeling" supports this contention, but I also did a slightly more careful experiment when I first switched to Vista. The result of it was that almost every elevation request I got for a month (I kept a log) was for some action where the equivalent on Linux would have required sudo rights anyway. The main exceptions were (1) changing environment variables (in Vista the terrible dialog where you change user-local and system-wide variables is the same, and MS didn't go out of their way to make it possible to change user-local ones) and (2) this one crappy hardware monitoring software I was using for some reason.
Basically everything else was like system config changes that would have required root on Linux or program installations, which also require root on Linux. (Well, okay, you can usually do configure/make/make install without root. But only then if you're really masochistic, because that drops you back to the hell of resolving dependencies that made Linux a PITA to use before package managers. Virtually none of the package managers out there work without root.)
So theoretically speaking... I can buy your argument. Practically speaking, I think it makes basically no difference whatsoever.
The first parts of your post are fine... but I have problems starting about here:
Also, I'm under the impression (based on the patent) that Windows is temporarily elevating the privileges of the application itself, which means that you now have a much larger chunk of code that must be checked for security holes, lest malicious individuals co-opt the application for nefarious purposes.
How is this different from the Linux sudo model or Apple's AuthorizationExecuteWithPrivileges? With that model, you start a process under sudo and it gets admin rights for the duration of the process.
By the "proportion of the code running with elevation" metric, Windows should actually be better in this regard, since the time between when the process starts to when it first elevates will be run without admin rights.
Such a design also makes it very hard to adequately use code signing to ensure the authenticity of the code running with elevated privileges...
As opposed to Sudo, which doesn't check the signature of the executable being run at all (at least AFAIK)?
I meant to say one more thing. Ever been at the command prompt, issued a command as a normal user that needs root, gotten a failure, and gone "doh, forgot to run it as root", hit the up arrow, and put a sudo before it?
With sudo-style elevation, you need to do that. This is what Gnome or whatever is doing behind the scenes when you open a configuration dialog that needs root (except that it never forgets!).
The UAC, this-patent-way of doing it would be for your initial attempt to cause Linux to say "this program is trying to do something that needs root, is that what you wanted?" and give you a password prompt then.
Can you please explain why this is different than the patent?
To the end user, it will appear (nearly) the same.
However, the architecture is rather different, at least compared the sudo case. In the sudo case, if a program runs with insufficient rights, it will simply fail. Because of this, a program that wants a dialog to pop up if the user does something (e.g. click "install") must take proactive actions to achieve this: it must explicitly call sudo.
By contrast, what UAC does (and that's what this patent is talking about) is watches requests from a program; if it requests something it doesn't have rights to, then the OS will display the elevation prompt.
To witness the effects of this, try installing software on Vista or Win 7. Some installers ask for elevations up front, but not all; others will let you go through the initial steps (e.g. choosing which parts to install, setting a target directory) without elevation, and then present the UAC prompt when it starts to install.
In other words, by my understanding:
- sudo cannot elevate an existing process
- UAC does elevate existing processes
I strongly suspect the same thing is true of OS X, though I can't speak with complete confidence in that matter.
I don't want to argue that the patent is valid or anything like that, but there is a pretty big difference.
Sugar isn't as bad as HFCS is. Just replacing HFCS with the same amount of calories in real sugar will already help.
Will it?
Coincidentally, I just yesterday saw a very interesting video about the body's processing of sugar. (Warning: this is very long, and has about 40 minutes of biochem in the middle that supposedly explains how fructose consumption contributes to hypertension, obesity, diabetes, etc. that I have no remotely realistic way of evaluating.) The thesis of the guy's talk in a nutshell is that "fructose is a poison".
Basically he said, "you know all those things people are saying about HFCS being bad for you? It's all true. HFCS is terrible for you." But, he also said that "real" sugar, sucrose, is basically no different nutritionally.
HFCS is (as he said an Wikipedia supports) basically a mix of glucose (which is fine/good for you) and fructose, at about a 50% mixture. (Wikipedia says two common variants are 55% fructose and 42% fructose.) But what's sucrose? Sucrose is (as he said and, again, Wikipedia supports) basically a glucose and a fructose molecule bonded together. (There's a missing H on one of the OH pairs on each, and that bond is spent on bonding the molecules together.) But what happens to sucrose in the stomach? An enzyme called glycoside hydrolase metabolizes the sucrose and just splits the damn thing up into sucrose and fructose!
The bottom line? Within a few percent, the nutritional content of sugar and HFCS is basically the same!
(Incidentally the corn industry has been putting out some studies that support this. The corn industry of course would like you to believe that HFCS isn't that bad because it's the same as sugar; this guy's point was that these studies are actually 100% correct, but because sugar is just as terrible as HFCS is.)
The problem, he contends, is that the total volume of sugar (sucrose + HFCS), and fructose in particular, has gone up substantially over the past couple decades. Because HFCS is so cheap, companies are putting it in everything, even things that they'd never ever have put sugar in before HFCS was invented. Furthermore, HFCS is a bit sweeter than sugar is, so you should be able to use a little less of it in things that are "supposed to be" sweet -- but companies don't. Finally, he says that nature's natural "antidote" to fructose is fiber, but people don't get enough fiber.
I can't really evaluate his claims in general -- I did some searching but couldn't really find any critiques from people who, say, used evidence to support their position. However, at least the HFCS/sucrose equivalence at least looks good from what I've seen.
Damn, and I had mod points when I loaded the page but just posted. Oh well.
What's wrong with yours? It randomly type #s?
Hydrogren peroxide is a common home remedy for ear-aches and wax buildup.
See, I didn't even know that and I still thought it was a reasonable question. I just assumed that someone got a cut or something inside their ear somehow and wanted to disinfect it.
Why is the peroxide question that stupid? The only thing I can think of is that the person probably meant 'hydrogen peroxide', and then I think it's a pretty reasonable question.