Fructose has a glycemic index of 22, sucrose of 64, and glucose of 100. Many fruits are close to fructose. The reason is that there is an active transport for glucose, while fructose gets absorbed by diffusion. The presence of fiber (in fruit), minerals, fat, and protein also affects the glycemic index.
Science aside, I'm still inclined to believe that big monied interests have a lot to do with the holdup.
If it only were a simple as corruption. Rather, it's the way things work around here: herbs don't make much money relative to patented chemicals. That means that people don't have much money for scientific trials involving herbs. Furthermore, it's the drug and chemical companies that (directly or indirectly) train applied chemists and biologists, and they ultimately set the standards; it's not that they want to be biased, it's just that they can't imagine any other way of doing business.
The solution? Increased government funding for drug and herbal research--we can't rely on the market to fix this. The profit motive in medicine doesn't coincide with good patient care: a patented maintenance drug for a common chronic illness is much more interesting financially than a non-patentable cure. The drug companies want the maintenance drug, the patients want the cure.
According to my client, both mouse support (i.e. clicking the little bar and bringing up the language) and keyboard support (using key commands to change languages) are VASTLY more efficient in Windows 2000 than in MacOS 9.
Wow. Just the kind of complex technology Microsoft would spend years researching: a button and a keyboard shortcut to change languages.
Now, be serious. On MacOSX, enabling language switching via a menu appears once you select a second language. If you must, you can assign a keyboard shortcut. I'd be very surprised if you couldn't do something similar under MacOS9. Several Linux desktops, of course, have the same feature.
But if Apple couldn't come up with anything more productive for MacOS 9, which was intended from the start to be a consumer-level, desktop, OS, I am highly doubtful that Linux developers can come up with anything better.
You don't know the systems you are working with well and you admit to knowing nothing about the technologies you are judging. Yep, I guess you are perfectly qualified to be a high-priced consultant to some really clueless business.
Consuming refined sugar, corn syrup, etc. is clearly bad: it causes wild swings in blood sugar, tooth decay, and other problems. Sugars we would consume traditionally were mostly those that came from fruits and the digestion of starches. Those are generally released fairly slowly.
The best thing to do is not to consume any artificial sweeterners at all, and to cut back on sugar. Sugar in processed foods has numbed our taste buds; once you cut back, you'll find that a lot less tastes just as sweet. And for a sweet treat, try fruits.
There is a much simpler way of satisfying a craving for sugar: just cut back on it. After a short while, your taste buds will adjust and a little sugar will taste very sweet.
I think sending people to Mars serves no purpose whatsoever. Whether it's $20 billion or $20 trillion, for the cost of sending 6 people to Mars, we could send probably a hundred unmanned one-way missions, or even several unmanned return missions. Those would yield much more scientific data.
If, on the other hand, the goal is public relations and media coverage, then let the entertainment and media businesses pay for it.
Well, I agree that $20 billion is a low-ball. On the other hand, the shuttle and ISS are gold plated boondoggles for contractors, of little scientific or practical value. You can't do any cost estimates based on them.
(Of course, I still haven't figured out why we would even want a manned mission to Mars.)
You seem to be implying that colonization of Mars would be "useful", while scientific exploration isn't.
I don't get that. I would view colonization of Mars as supremely useless. It's a harsh, fragile environment. You'd be better off colonizing Antarctica. We haven't even figured out how to live sustainably on Earth. If you don't live sustainably on Mars, you die immediately.
The comparison with the colonization of America is completely off. While American settlers may have been thinking that they had it hard in a harsh country, America was a enormously rich in natural resources--anybody with wilderness experience could have lived very well, as the American Indians generally did before the arrival of the settlers.
Colonizing Mars will solve none of our problems. We have to figure out how to live sustainably. If we do, we'll live in paradise on Earth, and we don't have to go anywhere. If we don't, we'll die out no matter where we go. We can't run away from ourselves.
I generally have no problems with this, and it doesn't strike me as unlawful. If these people want to damage their brand name by putting out junk content under their artists' names, that's fine by me. This kind of nonsense will also be easy to circumvent technologically. What would the alternative be? More regulation of content on P2P networks? That's something we don't want.
What would be a problem is if they started doing this for content they don't own. For example, if there was an artist that put his work on P2P networks, started competing with them, and then they tried to sabotage his popularity by putting out junk under his name. That, however, is probably already prohibited by current trademark laws.
I used to use gprof on Suns, which by your definition is "working".
In a working profiler, time spent waiting for I/O doesn't show up because it doesn't take CPU cycles to wait.
Oh? Could have fooled me. I have had plenty of CPU intensive I/O. But in any case, when I do look at system calls, of course, I want to know time waiting. It is of no interest to me whether the process is slow because the CPU is spinning or because it's waiting for a disk block.
Thread synchronization is expensive. I had a multithreaded server app that spent 15% of it's time just in the posix mutex functions.
I don't get it: do you or don't you want to see time spent waiting? Waiting for a mutex may well be just--waiting.
The iPod is a FireWire disk. Windows needs software for it because it's formatted in HFS+ (I believe). But Linux has native HFS+ support (and UFS, for that matter). You should just be able to plug it in and use something like "rsync" to synchronize your music. Other than that, iPod uses MP3 tags.
You say that there is a problem with profiling multithreaded code with gprof. But the issue you point to seems to apply to both single and multithreaded code: Linux gprof doesn't seem to count time spent in system code.
Now, compute intensive code tends not to spend a lot of time in system calls, so it isn't clear that it matters whether a profiler counts time spent in system calls. I kind of prefer if it doesn't because it doesn't clutter up the profile with I/O delays (which are usually unavoidable).
If you want to find out where your code is spending time in system calls, you can use "strace -c".
There are also gcov-like tools that can be used for profiling via code insertion (as opposed to statistical profiling like gprof), although I'm not sure whether PC hardware has the necessary timer support.
Overall, the answer is: yes, profiling still matters for programs that push the limits of the machine. But fewer programs do. I think most people would be a lot better off not programming in C or C++ at all and not worrying about performance. Too much worry about "efficiency" often results in code that is not only buggy but also quite inefficient: tricks that are fine for optimizing a few inner loops wreak havoc with performance when applied throughout a program. Too much tuning of low-level stuff also causes people to miss opportunities for better data structure and program logic. This is actually an endemic problem in the industry that affects almost all big C/C++ software systems. Desktop software, major servers, and even major parts of the kernel should simply not be written in C/C++ anymore.
The thing with profiling and optimization is to know when to stop, and few people know that. So, maybe the best thing to say is: "no, profiling doesn't matter anymore". That will keep most people out of trouble, and the few that still need to profile will figure it out themselves.
You don't get it, do you? This was a test by Xinet, testing their own product FullPress on several servers
It doesn't matter what Xinet's original intentions were, what matters is how this gets portrayed in the press. I'm simply pointing out that announcements like "Xserve Outperforms Sun, SGI, Windows" are misleading.
Apple and the Mac press have a history of greatly overstating the performance of their systems. This is just more of the same.
If there is to be a 12 month statute of limitations, I think that the window should begin *when the plaintiff becomes aware of the material*, not when it was actually published.
Then the plaintiff would be able to sue whenever they want because they'll just claim that "they weren't aware of it".
Unless I'm missing something, if I want to defame someone in the US now, all I have to do is upload the material to a web site, and wait 12 months before I give anyone a link to it.
The burden of proof of publication is probably on you. "I put it up on my web site on 1/1/02." is probably not good enough. "It showed up on Google on 1/1/02, and here is the evidence." probably is. If you want to prove an earlier publication date, it's up to you to figure out something better.
There are billions of CPUs in the world--many of them embedded. You can make your own CPUs out of programmable logic. Many embedded CPUs and even programmable logic CPUs are perfectly fine for desktop use. The notion that Microsoft will somehow succeed into getting cryptography and their operating system into every single powerful chip is ridiculous. Microsoft would be destroying much of their developer base, many of whom use at least some libraries or tools that were not developed with Microsoft tools (even die-hard VC++ users use such components). Competitors would be overjoyed if Microsoft were so foolish.
Now, what will happen is that some CPUs will offer cryptographic code checking, and that some.NET and Java runtimes will do the same for bytecodes. When they run in "normal" mode, they will check that the checksums are OK. I doubt it will help much with viruses or DRM, but, hey, Microsoft is floundering when it comes to security, so they need to do something.
I think Palladium isn't worth the extensive discussion and fear that it has caused. It's just another hare-brained Microsoft scheme, along with their nth iteration of "the file system is a database" and "intelligent assistants that ask whether your computer is turned on"; nothing much will come of it. And if Microsoft really goes through with it, all the better for the rest of us--there is no faster way than that to give marketshare to PCs based on embedded chips from Motorola--like the Macintosh for example.
I think LindowsOS is not good for Linux. Windows emulation under Linux is limited, and getting Windows emulation onto people's desks does nothing to encourage developers to develop Linux applications. Click-and-run seems particularly bad: a Linux installation could dazzle people with all the great software that is available, for free. Instead, customers are treated to downloading huge amounts of software.
I don't know whether Microsoft should win the trademark infringement case against LindowsOS, but someone should take them to court over Linux tradmark infringement. This distribution claims to be Linux, but it delivers little of what Linux is so great for: tons of software, complete installations of everything from a single source, and robust and simple application installation.
WalMart should ship a good Linux installation--RedHat, SuSE, Mandrake, whatever, with a full complement of word processing, games, and Internet access. They probably also need to offer something like Kapital. If they still want Windows compatibility, that should be a minor feature, kind of like VirtualPC for Macintosh, but it should be kept clearly separate from Linux.
Since [my computer] usually wide open, I don't see too much harm, but these cheap boxes that never get opened and cleaned have to be a hazard right?
Computers are not designed or approved to be run open. It's a stupid thing to do if you are afraid of fire--they get less air circulation, they run hotter, and if they catch fire, the fire can more easily spread. Running your computer open also violates FCC rules because it will cause lots of interference, affecting radio operators, police and fire communications, baby monitors, and medical equipment.
Computers are designed with metal cases for good reasons: they allow the fans to work, they conduct heat, they keep RF inside, and they offer some protection against fire. Don't run your computer open--it's just stupid.
For the last time (or rather, for the people without a brain) they did not test Photoshop on the Xserve.
Come on, you are quibbling. What matters is that they failed to use standard benchmarks, not what particular oddball choices they made for comparisons.
As for the compiler, it may be bad, but it's the compiler almost all Windows software is compiled with. And where did you get the information that gcc 2.95 is "pretty much the best compiler there is" for PPC?
What's your point? Even under the most charitable assumptions, the G4 is in the ballpark of a PIII with similar clock frequencies.
I hope Apple has something up their sleeve in terms of performance. I and others are willing to put up with a bit of performance lag relative to Intel and AMD, but at some point, it is going to start hurting them. Where are those G5's?
And testing a server with the SPEC CPU benchmark is a good idea why exactly? Esp. when SPEC has several server benchmarks?
Because Apple makes big claims for their CPU peformance, because that's what many people are using servers for. But if you like, fine, run SPEC's server benchmark. Running PhotoShop, however, is bogus, and it definitely isn't anything one would use OSX server for.
As for the Heise tests: they also show that a 800MHz G4 is faster than a 1GHz P3. Which brings us to the issue of compilers...
So what? That shows that you can make the Intel chip perform bad with a bad compiler. For PPC, they pretty much used the best compiler there is.
I have never gotten much out of lectures. Maybe you'll find that just reading a lot will do and get you to your goal faster. Also, thinking about and tackling interesting problems is probably the best way of learning a subject.
Of course, some places (like MIT) put their lectures on the web now. You can view Strang's linear algebra lectures on the web--you can't do much better than that (I leave out the link--no need to burden his site, but if you really care, it's easy to find).
about 10% [of stars within 100 light years] have been found to possess planetary systems. So, with about 300 billion stars in our galaxy, there could be about 30 billion planetary systems in the Milky Way alone;
That calculation doesn't work. Our local environment is likely to be reasonably good for planet formation. Closer to the core and closer to the fringes of our galaxy, planets probably become less frequent.
The accepted standard for CPU benchmarks are the SPEC benchmarks. They aren't perfect either (no benchmark ever is), but they are well understood, reproducible, and published.
Apple is notably absent from SPEC's list--they never submitted results.
Apple should move to the G5 quickly. Or, perhaps, Apple should even switch to some 64bit Intel or AMD processor--Motorola is likely going to keep remaining behind the curve a bit.
if I undestand correctly, the great deal of Western law is based on 'common law', the practice of allowing previous court decisions to affect future decisions.
Common law is a peculiarly Anglo-American affliction. In most other Western nations, judges do not get to make new law.
Slashdot Mirror
Fructose has a glycemic index of 22, sucrose of 64, and glucose of 100. Many fruits are close to fructose. The reason is that there is an active transport for glucose, while fructose gets absorbed by diffusion. The presence of fiber (in fruit), minerals, fat, and protein also affects the glycemic index.
If it only were a simple as corruption. Rather, it's the way things work around here: herbs don't make much money relative to patented chemicals. That means that people don't have much money for scientific trials involving herbs. Furthermore, it's the drug and chemical companies that (directly or indirectly) train applied chemists and biologists, and they ultimately set the standards; it's not that they want to be biased, it's just that they can't imagine any other way of doing business.
The solution? Increased government funding for drug and herbal research--we can't rely on the market to fix this. The profit motive in medicine doesn't coincide with good patient care: a patented maintenance drug for a common chronic illness is much more interesting financially than a non-patentable cure. The drug companies want the maintenance drug, the patients want the cure.
Wow. Just the kind of complex technology Microsoft would spend years researching: a button and a keyboard shortcut to change languages.
Now, be serious. On MacOSX, enabling language switching via a menu appears once you select a second language. If you must, you can assign a keyboard shortcut. I'd be very surprised if you couldn't do something similar under MacOS9. Several Linux desktops, of course, have the same feature.
But if Apple couldn't come up with anything more productive for MacOS 9, which was intended from the start to be a consumer-level, desktop, OS, I am highly doubtful that Linux developers can come up with anything better.
You don't know the systems you are working with well and you admit to knowing nothing about the technologies you are judging. Yep, I guess you are perfectly qualified to be a high-priced consultant to some really clueless business.
The best thing to do is not to consume any artificial sweeterners at all, and to cut back on sugar. Sugar in processed foods has numbed our taste buds; once you cut back, you'll find that a lot less tastes just as sweet. And for a sweet treat, try fruits.
There is a much simpler way of satisfying a craving for sugar: just cut back on it. After a short while, your taste buds will adjust and a little sugar will taste very sweet.
If, on the other hand, the goal is public relations and media coverage, then let the entertainment and media businesses pay for it.
(Of course, I still haven't figured out why we would even want a manned mission to Mars.)
I don't get that. I would view colonization of Mars as supremely useless. It's a harsh, fragile environment. You'd be better off colonizing Antarctica. We haven't even figured out how to live sustainably on Earth. If you don't live sustainably on Mars, you die immediately.
The comparison with the colonization of America is completely off. While American settlers may have been thinking that they had it hard in a harsh country, America was a enormously rich in natural resources--anybody with wilderness experience could have lived very well, as the American Indians generally did before the arrival of the settlers.
Colonizing Mars will solve none of our problems. We have to figure out how to live sustainably. If we do, we'll live in paradise on Earth, and we don't have to go anywhere. If we don't, we'll die out no matter where we go. We can't run away from ourselves.
What would be a problem is if they started doing this for content they don't own. For example, if there was an artist that put his work on P2P networks, started competing with them, and then they tried to sabotage his popularity by putting out junk under his name. That, however, is probably already prohibited by current trademark laws.
Come on: read and think. gprof wasn't working multithreaded because it was getting its signal only in the main thread. And read the documentation.
I used to use gprof on Suns, which by your definition is "working".
In a working profiler, time spent waiting for I/O doesn't show up because it doesn't take CPU cycles to wait.
Oh? Could have fooled me. I have had plenty of CPU intensive I/O. But in any case, when I do look at system calls, of course, I want to know time waiting. It is of no interest to me whether the process is slow because the CPU is spinning or because it's waiting for a disk block.
Thread synchronization is expensive. I had a multithreaded server app that spent 15% of it's time just in the posix mutex functions.
I don't get it: do you or don't you want to see time spent waiting? Waiting for a mutex may well be just--waiting.
The iPod is a FireWire disk. Windows needs software for it because it's formatted in HFS+ (I believe). But Linux has native HFS+ support (and UFS, for that matter). You should just be able to plug it in and use something like "rsync" to synchronize your music. Other than that, iPod uses MP3 tags.
Now, compute intensive code tends not to spend a lot of time in system calls, so it isn't clear that it matters whether a profiler counts time spent in system calls. I kind of prefer if it doesn't because it doesn't clutter up the profile with I/O delays (which are usually unavoidable).
If you want to find out where your code is spending time in system calls, you can use "strace -c".
There are also gcov-like tools that can be used for profiling via code insertion (as opposed to statistical profiling like gprof), although I'm not sure whether PC hardware has the necessary timer support.
Overall, the answer is: yes, profiling still matters for programs that push the limits of the machine. But fewer programs do. I think most people would be a lot better off not programming in C or C++ at all and not worrying about performance. Too much worry about "efficiency" often results in code that is not only buggy but also quite inefficient: tricks that are fine for optimizing a few inner loops wreak havoc with performance when applied throughout a program. Too much tuning of low-level stuff also causes people to miss opportunities for better data structure and program logic. This is actually an endemic problem in the industry that affects almost all big C/C++ software systems. Desktop software, major servers, and even major parts of the kernel should simply not be written in C/C++ anymore.
The thing with profiling and optimization is to know when to stop, and few people know that. So, maybe the best thing to say is: "no, profiling doesn't matter anymore". That will keep most people out of trouble, and the few that still need to profile will figure it out themselves.
It doesn't matter what Xinet's original intentions were, what matters is how this gets portrayed in the press. I'm simply pointing out that announcements like "Xserve Outperforms Sun, SGI, Windows" are misleading.
Apple and the Mac press have a history of greatly overstating the performance of their systems. This is just more of the same.
Then the plaintiff would be able to sue whenever they want because they'll just claim that "they weren't aware of it".
Unless I'm missing something, if I want to defame someone in the US now, all I have to do is upload the material to a web site, and wait 12 months before I give anyone a link to it.
The burden of proof of publication is probably on you. "I put it up on my web site on 1/1/02." is probably not good enough. "It showed up on Google on 1/1/02, and here is the evidence." probably is. If you want to prove an earlier publication date, it's up to you to figure out something better.
Now, what will happen is that some CPUs will offer cryptographic code checking, and that some .NET and Java runtimes will do the same for bytecodes. When they run in "normal" mode, they will check that the checksums are OK. I doubt it will help much with viruses or DRM, but, hey, Microsoft is floundering when it comes to security, so they need to do something.
I think Palladium isn't worth the extensive discussion and fear that it has caused. It's just another hare-brained Microsoft scheme, along with their nth iteration of "the file system is a database" and "intelligent assistants that ask whether your computer is turned on"; nothing much will come of it. And if Microsoft really goes through with it, all the better for the rest of us--there is no faster way than that to give marketshare to PCs based on embedded chips from Motorola--like the Macintosh for example.
I don't know whether Microsoft should win the trademark infringement case against LindowsOS, but someone should take them to court over Linux tradmark infringement. This distribution claims to be Linux, but it delivers little of what Linux is so great for: tons of software, complete installations of everything from a single source, and robust and simple application installation.
WalMart should ship a good Linux installation--RedHat, SuSE, Mandrake, whatever, with a full complement of word processing, games, and Internet access. They probably also need to offer something like Kapital. If they still want Windows compatibility, that should be a minor feature, kind of like VirtualPC for Macintosh, but it should be kept clearly separate from Linux.
Computers are not designed or approved to be run open. It's a stupid thing to do if you are afraid of fire--they get less air circulation, they run hotter, and if they catch fire, the fire can more easily spread. Running your computer open also violates FCC rules because it will cause lots of interference, affecting radio operators, police and fire communications, baby monitors, and medical equipment.
Computers are designed with metal cases for good reasons: they allow the fans to work, they conduct heat, they keep RF inside, and they offer some protection against fire. Don't run your computer open--it's just stupid.
Come on, you are quibbling. What matters is that they failed to use standard benchmarks, not what particular oddball choices they made for comparisons.
As for the compiler, it may be bad, but it's the compiler almost all Windows software is compiled with. And where did you get the information that gcc 2.95 is "pretty much the best compiler there is" for PPC?
What's your point? Even under the most charitable assumptions, the G4 is in the ballpark of a PIII with similar clock frequencies.
I hope Apple has something up their sleeve in terms of performance. I and others are willing to put up with a bit of performance lag relative to Intel and AMD, but at some point, it is going to start hurting them. Where are those G5's?
Because Apple makes big claims for their CPU peformance, because that's what many people are using servers for. But if you like, fine, run SPEC's server benchmark. Running PhotoShop, however, is bogus, and it definitely isn't anything one would use OSX server for.
As for the Heise tests: they also show that a 800MHz G4 is faster than a 1GHz P3. Which brings us to the issue of compilers...
So what? That shows that you can make the Intel chip perform bad with a bad compiler. For PPC, they pretty much used the best compiler there is.
Of course, some places (like MIT) put their lectures on the web now. You can view Strang's linear algebra lectures on the web--you can't do much better than that (I leave out the link--no need to burden his site, but if you really care, it's easy to find).
That calculation doesn't work. Our local environment is likely to be reasonably good for planet formation. Closer to the core and closer to the fringes of our galaxy, planets probably become less frequent.
Apple is notably absent from SPEC's list--they never submitted results.
However, third parties have run the SPEC benchmarks. A 1GHz G4 seems to perform about as well as a 1GHz Pentium III: decent but not overwhelming. See also this Register article.
Apple should move to the G5 quickly. Or, perhaps, Apple should even switch to some 64bit Intel or AMD processor--Motorola is likely going to keep remaining behind the curve a bit.
if I undestand correctly, the great deal of Western law is based on 'common law', the practice of allowing previous court decisions to affect future decisions. Common law is a peculiarly Anglo-American affliction. In most other Western nations, judges do not get to make new law.
Yes, that's the issue: the mold is more complex than for other methods.
(The other part that's going to be laboriously and complex is to convince the cook in the house to let you use the microwave for metallurgy :-)