At first glance I read "Plone Founders" as "Phone Pounders." Imagine my reaction.
In my case, after reading the headline I was thinking for a second that O'Reilly had tried to interview some hacker known as "the Plone", and that the interview had gone horribly wrong.
Late 60s economy: good -> Thank Nixon
Early 70s economy: bad -> Blame Johnson
Late 70s economy: bad -> Blame Carter
Early 80s economy: bad -> Blame Carter
Late 80s economy: good -> Thank Reagan
1990 Economy: bad -> Blame Carter
Early 90s economy: good -> Thank Reagan
Late 90s economy: good -> Thank Reagan
Early 00s economy: bad -> Blame Clinton
Companies will not own their hardware, but rent it. If they suddenly need 3 times as much CPU, then they get it immediately, and only pay for what they use.
This is different than the current situation where a company must always keep enough hardware around to handle peak loads, which is almost never. And then, if they guessed wrong, they are still screwed.
The problem with that scheme is that most business problems are more dependent on I/O bandwidth than on CPU crunching. Today, you can mail order a gigaflop of CPU horsepower for less than $100. Compute horsepower is not an issue.
The problem is that if you try to ship your computing problems to some other location, you've got to get the data from your site to theirs, so you still need I/O bandwidth at your site. What's worse, now you need a high-capacity WAN link to move it to these arbitrary locations.
You may also have massive databases of background data that need to be referenced to solve your problems. How do you handle this? Send terabytes of data offsite so that a third party can run their Opteron against it for a few minutes? Or do you install a massive Internet pipe so that they can mount your database remotely? Either choice costs more than buying your own Opteron.
but if you intended to give away the code for free in the first place, why are you so concerned that someone is taking it and profiting off of it?
Under current copyright law, your place as a user of a work is not to question the author's motives for enforcing his copyright; your place is to comply with the license. The author's motives are the author's business, not yours.
Your rambling about how licensing ought to be done is no more relevant than RMS's assertions that all proprietary licenses are wrong.
If Episode III isn't incredible, Mr. Lucas can forget about any other Episodes.
I disagree. No matter how many horrible sequels he puts out, millions of dorks will shell out their money for each one just so see for themselves how bad it is. If they fail to see one, they'll miss out on all the fun when their friends bitch about how bad it was.
When I feel that a program is in need of a structural overhaul, I don't just throw it away. I usually comment out all of the source code, back down to a blank 'main()' function. Then I build it back up piece by piece using a cleaner design. However, instead of writing a lot of new code, I uncomment and tweak the bits of the commented out old program that worked fine. I usually find that huge swaths of the original program needed little or any work to adapt to the new architecture.
Once all of the old code has been either pasted back in, revised or deleted, I've usually got a program that does everything the old one does and more, but it is smaller, simpler and cleaner.
Most of the subtle features and knowledge embedded in the old code is not lost by using this approach; it gets pulled back in.
What I meant was that these tracks are emitting very little electromagnetic radiation power relative to the electrical power being being pumped into them. The vast majority of the power ends up being driven into the train motion or wasted as heat.
Basically, a small magnet under the train makes a poor antenna for wavelengths this long. Thinking about it more, I'd speculate that there's actually a lot more EMF power emitted from the power supply cables than from the magnets, since these would have a fluctuating current in wires stretching out over miles. At these wavelenghts, those long cables would much more efficiently couple to free space.
They better change rapidly, unless you're suggesting the entire system is propelled by a huge bar magnet strapped to the bottom of the train and one at each end of the track.
It's changing, but not "rapidly" relative to most EMF fields. The rise and fall times of the magnetic fields are probably on the order of milliseconds. This would create electromagnetic waves in the kilohertz frequency range. The wavelength of these waves would be dozens of miles long, so concentrated localized effects would be unlikely.
Moreover, the power of electromagnetic waves depends on the frequency. The total power emitted by these fields would be very low relative to something like a megahertz radio transmitter driven with the same power input. (It's been a long time since I took an EMF class, but IIRC, to propagate waves, you need both an electrical and magnetic component. The tracks may have a very strong magnetic component, but since the associated electrical component depends on the rate of change of the magnetic field, it is very weak, so the total radiated power is low.)
Maybe if they didn't spend R&D time and money on useless features, their products would be more affordable.
I'm so sick of this argument. Just because you don't use a feature, it doesn't mean that nobody else needs it. Photoshop is a application designed for professionals. I'm a professional, and at least once per week I don't open an image of money. Just because Joe random geek in his parents' basement dabbles around with a few pictures and never has the need to not open an image of cash, it doesn't mean that Adobe should deprive the rest of us the from not opening images of money just to save a few cents.
Hey, if you don't think that you're ever not going to open an image of money, you've got plenty of free or cheap choices out there. Even Adobe makes consumer grade apps. Some of us, however, make a living with this software, and the price is a drop in the bucket compared to what we do with it. I sure as hell don't want to lose a job just because it involves not editing images of cash.
Despite the fact that even I, a Professional, may not use every feature in Photoshop, I still appreciate Adobe's efforts to provide me with every possible feature they can. And I don't care that this feature isn't bulletproof. If I use it to not open images of money and it works in 90% of the cases, that still saves me time.
A bottle of wine should be stored on its side in a dark, cool space.
Actually, I saw an article a while back (don't remember where) that thoroughly debunked storing bottles on their side. The argument was that the only thing that accomplishes is making your wine taste corky. It said that the cork will not dry out even in a bottle standing upright because the air space in the wine bottle is at 100% humidity.
Why do businesses sell underclocked hardware when they know some geek somewhere is going to try loading the higher software in and seeing what happens? If that test comes back positive and can be duplicated... we'll be reading it here on/.
You've answered your own question. Countless thousands of potential customers are eagerly reading about nVidia's products on/. right now, and it didn't cost them a cent in advertising budget.
Think of it like a discount coupon. The geeks reading about it here probably weren't going to buy either board until they saw this story. But now with the prospect of getting something "for free", many will rush out to grab one, and nVidia makes sales that otherwise would not have happened.
That's about $10/month; similar to the cost of adding a movie channel or two to your cable subscription. Something to think about for those that will use this CPU to volunteer for distributed number crunching projects.
If I were a more qualified sociologist, I'd think it may have inspired by the way that our children play today versus how they played twenty years ago.
I don't know about 20 years ago, but 35 years ago I used to play with plain rectangular Lego blocks and generic wheels. I had to use my own mind and imagination to assemble these general-purpose blocks into the wide variety of things I wanted to build.
From the look of today's Lego sets, children play today by using the custom single-purpose pieces to assemble a verbatim copy of the picture on the box.
There are billions if not trillions that could be cut from the budget allowing the people who WORK to keep their income.
They could be cut, but they HAVEN'T been cut, even though the GOP is now firmly in charge of government spending. That was my whole point. You need to look beyond what they say they're going to do, and see for yourself what they're actually doing, which is inescapably raising your future taxes well above an beyond what you were already going to pay.
Nicely put, but relies on the assumption that use of public services has a positive correlation to income. The correlation is in fact negative. Thus the argument is a failure.
It doesn't rely on who is taking what proportion of the services. By not having the political will and honesty to actually reduce government spending while cutting taxes, the total quantity of taxes that will eventually be paid by everyone will be increased.
I can rephrase my argument to say that you were paying for other peoples' services with your tax money, but now you're paying for those services with a cash advance. It doesn't change things.
Spending increases -> more taxes + interest will be paid. There is no way to get around that.
Keep more of my own income but increase my own personal responsibility
It's not keeping more of your own income; it's continuing to accept the services you formerly paid for with taxes (in fact taking more services), but now paying for them with a cash advance from a multitrillion dollar credit card. You're still going to pay it all back one day with money from your income, but with interest.
But these where low-level numeric benchmarks. Except for the I/O one, they wouldn't have changed due to linking against different libraries.
The review article is/.ed now, but from the test names on the summary table it looks like the tests are indeed mostly numeric. Unfortunately, only a small minority of people make their living writing number crunching code.
For the vast majority of business and web-based apps, the bulk of operations involves string manipulation. If an app is compute intensive and not I/O or GUI bound, then the bottleneck is usually creating, modifying and destroying strings. Benchmarks on string handling would be more useful to most developers.
However, doing string manipulation benchmarks isn't so simple. There are at least four approaches to strings, and some languages let you pick any of these:
-- dangerous and very fast: using static buffers and in-place modifications like old-school C
-- somewhat safer and may be fast: using semiautomatic memory management with mutable strings, like C++/STL or C with glib's g_string
-- safer still: using totally automatic memory management with mutable strings, like Ruby or (IIRC) Perl
-- safest: using totally automatic memory management with immutable strings, like Java or Python
Of course, for each problem the algorithms would need to be structured differently to get the maximum possible speed in each of the above four methodologies.
Basically, for string-intensive code, claiming that Java is just as fast as C will always be a false statement if you compare C code written in the first dangerous style vs. Java, which is always written in the fourth and safest style. No matter what technical tricks the VM writers come up with, there is just no way that they'll be able to match C's ability essentially zero-overhead in-place buffer operations over and over in the same spot that stays loaded in the L1 cache. (Actually, you probably could write Java code that operates on raw character arrays, and it might approach the speed of C. But that would probably look even uglier than the C code.)
In the few cases that I've ported a string-intensive high-level-language algorithm to raw low-level C code with few or no mallocs (not a trivial task), I've gotten at least a 10X speedup on the CPU-bound tasks, and at least 10X less memory usage. (Note that I did those tests largely out of curiosity. For most applications, even a 10X speedup is rarely worth the increased development time, bug vulnerabilities or maintenence issues. My opinion is that if you have to write code like this, you should confine it to a C extension library to a high-level language like Python.)
I've found that STL can be faster or slower than Java, depending on how smart you are. It's very easy to inadvertently get C++ to thrash around with needless automatic data copying.
Languages like Perl and Python can be very competetive on string operations if you know how to use their libraries. By using the most powerful operations that work on the largest chunks of data at one time (Python's re.findall(), for example), you take advantage of the fact that the library call is mostly written in C. Bit-banging in a dynamic interpreted language is usually dog slow, as the Python numbers seem to show on the summary chart.
To sum it up, most people write apps whose performance can't be predicted by a few simple language benchmarks, because the way the app is written can affect the performance more than the language it's written in.
Usually something as simple as moving the case can make a significant difference.
You know that forest people keep talking about where there's nobody around to hear things? I put my computer cases there, and now they don't make any sound at all.
(Unfortunately, one my systems did get destroyed when a tree fell on it.)
Actually, current "CISC" processors can be seen as having all of their instructions implemented in microcode because they're all translated into the internal RISC-like subops.
However, there are two major differences between traditional microcode ops and RISC-like subops. First, traditional microcode opcodes were usually very wide, with enough dedicated bits to simultaneously control all of the ALU parameters, address calculations and data path multiplexers in the processor.
Second, microcode worked like a little subroutine, serially stepping through a fixed sequence of steps in order over several clocks to perform one program opcode. RISC-like subops, OTOH, can usually be split out and issued independently to the various execution units in the CPU and execute in an arbitrary order, in parallel with each other or with subops from other assembly opcodes.
All things being equal, RISC gives you more bang for your buck.
Maybe, maybe not. However, it's hard to tell because nobody makes RISC or CISC processors anymore. The RISC concept, implemented in CPUs like the MIPS R3000, originally meant very simple hardware without pipeline interlocks, instruction schedulers, or more than an absolute bare-bones set of instructions. The current Power PC does not match this at all; it is closer to the current X86.
By the same token, CISC used to mean that many or most instructions were implemented in microcode on the processor. Once again, that's no longer the case. All X86s now have a RISC-like core and resemble the Power PC far more than the 80286.
Pure RISC designs and pure CISC designs have both been superceded by a hybrid approach, and neither one would be competetive today outside the embedded device market.
Basically, you were being fed a line of company FUD to get you all excited about their choice of CPU. Today, cache memory dominates the chip real estate, and CPU performance and power consumption are dictated almost exclusively by cache size and silicon process technology rather than these surface architectural details.
I don't see the requirement for many gigs of memory (on a single chip no less) without also having better technology to access it quickly.
Maybe this technology could create a RAM chip with a capacity that matches or beats any hard drive at a similar price. If so, that would eliminate rotational and head seek latency for accessing your data, speeding up nonlocal accesses by orders of magnitude.
The need for virtual memory and disk buffering would be essentially eliminated. It would precipitate a total rewrite of many of the data access algorithms and filesystems in use today, largely because this would be a better technology to access your data quickly.
(If the memory technology isn't nonvolatile though, you just better have a good standby power supply:)
The hulahoop wasn't hard to implement either but somebody got a patent on that. is that wrong too?
No, because it wasn't at all obvious that anybody would pay good money to swing a stupid plastic hoop around their hips. That insight required a true marketing visionary.
Slashdot Mirror
In my case, after reading the headline I was thinking for a second that O'Reilly had tried to interview some hacker known as "the Plone", and that the interview had gone horribly wrong.
Late 60s economy: good -> Thank Nixon
Early 70s economy: bad -> Blame Johnson
Late 70s economy: bad -> Blame Carter
Early 80s economy: bad -> Blame Carter
Late 80s economy: good -> Thank Reagan
1990 Economy: bad -> Blame Carter
Early 90s economy: good -> Thank Reagan
Late 90s economy: good -> Thank Reagan
Early 00s economy: bad -> Blame Clinton
This is different than the current situation where a company must always keep enough hardware around to handle peak loads, which is almost never. And then, if they guessed wrong, they are still screwed.
The problem with that scheme is that most business problems are more dependent on I/O bandwidth than on CPU crunching. Today, you can mail order a gigaflop of CPU horsepower for less than $100. Compute horsepower is not an issue.
The problem is that if you try to ship your computing problems to some other location, you've got to get the data from your site to theirs, so you still need I/O bandwidth at your site. What's worse, now you need a high-capacity WAN link to move it to these arbitrary locations.
You may also have massive databases of background data that need to be referenced to solve your problems. How do you handle this? Send terabytes of data offsite so that a third party can run their Opteron against it for a few minutes? Or do you install a massive Internet pipe so that they can mount your database remotely? Either choice costs more than buying your own Opteron.
Under current copyright law, your place as a user of a work is not to question the author's motives for enforcing his copyright; your place is to comply with the license. The author's motives are the author's business, not yours.
Your rambling about how licensing ought to be done is no more relevant than RMS's assertions that all proprietary licenses are wrong.
Hey, didn't that Slash guy get a patent on using Jim Morrison's belt to securely fasten a tophat to a huge fuzzball?
I disagree. No matter how many horrible sequels he puts out, millions of dorks will shell out their money for each one just so see for themselves how bad it is. If they fail to see one, they'll miss out on all the fun when their friends bitch about how bad it was.
Once all of the old code has been either pasted back in, revised or deleted, I've usually got a program that does everything the old one does and more, but it is smaller, simpler and cleaner.
Most of the subtle features and knowledge embedded in the old code is not lost by using this approach; it gets pulled back in.
What I meant was that these tracks are emitting very little electromagnetic radiation power relative to the electrical power being being pumped into them. The vast majority of the power ends up being driven into the train motion or wasted as heat.
Basically, a small magnet under the train makes a poor antenna for wavelengths this long. Thinking about it more, I'd speculate that there's actually a lot more EMF power emitted from the power supply cables than from the magnets, since these would have a fluctuating current in wires stretching out over miles. At these wavelenghts, those long cables would much more efficiently couple to free space.
It's changing, but not "rapidly" relative to most EMF fields. The rise and fall times of the magnetic fields are probably on the order of milliseconds. This would create electromagnetic waves in the kilohertz frequency range. The wavelength of these waves would be dozens of miles long, so concentrated localized effects would be unlikely.
Moreover, the power of electromagnetic waves depends on the frequency. The total power emitted by these fields would be very low relative to something like a megahertz radio transmitter driven with the same power input. (It's been a long time since I took an EMF class, but IIRC, to propagate waves, you need both an electrical and magnetic component. The tracks may have a very strong magnetic component, but since the associated electrical component depends on the rate of change of the magnetic field, it is very weak, so the total radiated power is low.)
I'm so sick of this argument. Just because you don't use a feature, it doesn't mean that nobody else needs it. Photoshop is a application designed for professionals. I'm a professional, and at least once per week I don't open an image of money. Just because Joe random geek in his parents' basement dabbles around with a few pictures and never has the need to not open an image of cash, it doesn't mean that Adobe should deprive the rest of us the from not opening images of money just to save a few cents.
Hey, if you don't think that you're ever not going to open an image of money, you've got plenty of free or cheap choices out there. Even Adobe makes consumer grade apps. Some of us, however, make a living with this software, and the price is a drop in the bucket compared to what we do with it. I sure as hell don't want to lose a job just because it involves not editing images of cash.
Despite the fact that even I, a Professional, may not use every feature in Photoshop, I still appreciate Adobe's efforts to provide me with every possible feature they can. And I don't care that this feature isn't bulletproof. If I use it to not open images of money and it works in 90% of the cases, that still saves me time.
Actually, I saw an article a while back (don't remember where) that thoroughly debunked storing bottles on their side. The argument was that the only thing that accomplishes is making your wine taste corky. It said that the cork will not dry out even in a bottle standing upright because the air space in the wine bottle is at 100% humidity.
Actually, GNE's not EFF.
You've answered your own question. Countless thousands of potential customers are eagerly reading about nVidia's products on /. right now, and it didn't cost them a cent in advertising budget.
Think of it like a discount coupon. The geeks reading about it here probably weren't going to buy either board until they saw this story. But now with the prospect of getting something "for free", many will rush out to grab one, and nVidia makes sales that otherwise would not have happened.
But microwaves use expensive and smelly burrito heat sinks that only have a service life of about 5 minutes each.
That's about $10/month; similar to the cost of adding a movie channel or two to your cable subscription. Something to think about for those that will use this CPU to volunteer for distributed number crunching projects.
I don't know about 20 years ago, but 35 years ago I used to play with plain rectangular Lego blocks and generic wheels. I had to use my own mind and imagination to assemble these general-purpose blocks into the wide variety of things I wanted to build.
From the look of today's Lego sets, children play today by using the custom single-purpose pieces to assemble a verbatim copy of the picture on the box.
They could be cut, but they HAVEN'T been cut, even though the GOP is now firmly in charge of government spending. That was my whole point. You need to look beyond what they say they're going to do, and see for yourself what they're actually doing, which is inescapably raising your future taxes well above an beyond what you were already going to pay.
It doesn't rely on who is taking what proportion of the services. By not having the political will and honesty to actually reduce government spending while cutting taxes, the total quantity of taxes that will eventually be paid by everyone will be increased.
I can rephrase my argument to say that you were paying for other peoples' services with your tax money, but now you're paying for those services with a cash advance. It doesn't change things.
Spending increases -> more taxes + interest will be paid. There is no way to get around that.
It's not keeping more of your own income; it's continuing to accept the services you formerly paid for with taxes (in fact taking more services), but now paying for them with a cash advance from a multitrillion dollar credit card. You're still going to pay it all back one day with money from your income, but with interest.
The review article is /.ed now, but from the test names on the summary table it looks like the tests are indeed mostly numeric. Unfortunately, only a small minority of people make their living writing number crunching code.
For the vast majority of business and web-based apps, the bulk of operations involves string manipulation. If an app is compute intensive and not I/O or GUI bound, then the bottleneck is usually creating, modifying and destroying strings. Benchmarks on string handling would be more useful to most developers.
However, doing string manipulation benchmarks isn't so simple. There are at least four approaches to strings, and some languages let you pick any of these:
-- dangerous and very fast: using static buffers and in-place modifications like old-school C
-- somewhat safer and may be fast: using semiautomatic memory management with mutable strings, like C++/STL or C with glib's g_string
-- safer still: using totally automatic memory management with mutable strings, like Ruby or (IIRC) Perl
-- safest: using totally automatic memory management with immutable strings, like Java or Python
Of course, for each problem the algorithms would need to be structured differently to get the maximum possible speed in each of the above four methodologies.
Basically, for string-intensive code, claiming that Java is just as fast as C will always be a false statement if you compare C code written in the first dangerous style vs. Java, which is always written in the fourth and safest style. No matter what technical tricks the VM writers come up with, there is just no way that they'll be able to match C's ability essentially zero-overhead in-place buffer operations over and over in the same spot that stays loaded in the L1 cache. (Actually, you probably could write Java code that operates on raw character arrays, and it might approach the speed of C. But that would probably look even uglier than the C code.)
In the few cases that I've ported a string-intensive high-level-language algorithm to raw low-level C code with few or no mallocs (not a trivial task), I've gotten at least a 10X speedup on the CPU-bound tasks, and at least 10X less memory usage. (Note that I did those tests largely out of curiosity. For most applications, even a 10X speedup is rarely worth the increased development time, bug vulnerabilities or maintenence issues. My opinion is that if you have to write code like this, you should confine it to a C extension library to a high-level language like Python.)
I've found that STL can be faster or slower than Java, depending on how smart you are. It's very easy to inadvertently get C++ to thrash around with needless automatic data copying.
Languages like Perl and Python can be very competetive on string operations if you know how to use their libraries. By using the most powerful operations that work on the largest chunks of data at one time (Python's re.findall(), for example), you take advantage of the fact that the library call is mostly written in C. Bit-banging in a dynamic interpreted language is usually dog slow, as the Python numbers seem to show on the summary chart.
To sum it up, most people write apps whose performance can't be predicted by a few simple language benchmarks, because the way the app is written can affect the performance more than the language it's written in.
You know that forest people keep talking about where there's nobody around to hear things? I put my computer cases there, and now they don't make any sound at all.
(Unfortunately, one my systems did get destroyed when a tree fell on it.)
However, there are two major differences between traditional microcode ops and RISC-like subops. First, traditional microcode opcodes were usually very wide, with enough dedicated bits to simultaneously control all of the ALU parameters, address calculations and data path multiplexers in the processor.
Second, microcode worked like a little subroutine, serially stepping through a fixed sequence of steps in order over several clocks to perform one program opcode. RISC-like subops, OTOH, can usually be split out and issued independently to the various execution units in the CPU and execute in an arbitrary order, in parallel with each other or with subops from other assembly opcodes.
Maybe, maybe not. However, it's hard to tell because nobody makes RISC or CISC processors anymore. The RISC concept, implemented in CPUs like the MIPS R3000, originally meant very simple hardware without pipeline interlocks, instruction schedulers, or more than an absolute bare-bones set of instructions. The current Power PC does not match this at all; it is closer to the current X86.
By the same token, CISC used to mean that many or most instructions were implemented in microcode on the processor. Once again, that's no longer the case. All X86s now have a RISC-like core and resemble the Power PC far more than the 80286.
Pure RISC designs and pure CISC designs have both been superceded by a hybrid approach, and neither one would be competetive today outside the embedded device market.
Basically, you were being fed a line of company FUD to get you all excited about their choice of CPU. Today, cache memory dominates the chip real estate, and CPU performance and power consumption are dictated almost exclusively by cache size and silicon process technology rather than these surface architectural details.
Maybe this technology could create a RAM chip with a capacity that matches or beats any hard drive at a similar price. If so, that would eliminate rotational and head seek latency for accessing your data, speeding up nonlocal accesses by orders of magnitude.
The need for virtual memory and disk buffering would be essentially eliminated. It would precipitate a total rewrite of many of the data access algorithms and filesystems in use today, largely because this would be a better technology to access your data quickly.
(If the memory technology isn't nonvolatile though, you just better have a good standby power supply :)
No, because it wasn't at all obvious that anybody would pay good money to swing a stupid plastic hoop around their hips. That insight required a true marketing visionary.