It's not that easy. You always have the choice for what you want to search. If you're a drug company exec, do you tell your scientists: "Let's search for a drug that eliminates AIDS from your blood" or "Let's search for a drug that controls AIDS"? Well, if all you care about is money and shareholders, you choose the second choice because it costs less and because such a drug provides a long term revenue instead of a one-shot. Also, if you are already making lots of money selling drugs that "control AIDS", selling one that cures it will decrease your profits.
Re:Is Intel doing the right thing?
on
Itanium Problems
·
· Score: 2
Are you sure about that 3.3V? Most current x86 CPU's run at a voltage around 1.5V. That would mean a current around 85 A. That's just insane!
Right now, with DDR, it takes 5 bus (133 MHz) cycles just to send the row and column address (RAS & CAS) to the DIMM. That means 50 CPU cycles if you have a 1.33 GHz CPU. While it takes a lot of time to access one byte of data, the memory current systems are designed so they can send the next bytes much faster. With DDR, all the other consecutive reads will only take half a cycle (that's why we say the bus is at 266 MHz, while the bus clock is really 133 MHz), which is much faster. That's how it's been working ever since the Pentium came out (with EDO memory, correct me if I'm wrong) and much longer than that with super-computers.
If you want your computer to work fast, you need to access data in memory sequentially. The first byte takes lots of time but the rest comes fast. The speed of light will eventually impose a hard limit on the memory latency one can have in a PC. Despite that, there's nothing preventing bandwidth from continuing to increase. You can keep sending the bytes faster, all it means is that while the CPU is receiving the first byte, you might already be sending the 10th one. No big problem here. Once again the super-computers have been dealing with that for a while because their memory is often far from the processor...
I know that signal speed is a substantial fraction of lightspeed
The signal goes around 2/3 of the speed of light (for those who don't know, the signal travels much faster than the electrons themselves).
As for propagation delays, it's not a new problem. Super-computers have been having that problem for years because of their size. There's no real problem, as long as you account for the delays. In the case of super-computers, it was necessary to check the length of the wires correctly. For CPU, manufacturers will have to be careful with the length of the traces. It'll add come challenge but I doubt it'll be that hard to overcome...
How the hell is marketing responsible for crap code? Because they forced the product out too soon?
No. By saying "stop fixing holes, we want all these new features in Outlook for the next release" or by pushing for all kinds that are inherently hard to make secure. The UNIX way is to not implement a feature until we can implement it safely. The MS way is to implement the feature anyway and blame hackers/crackers once holes are found.
Actually, because of the low resolution and the fact that the recordings are pre-emphasized, I'd expect to hear severe aliasing in the resulting audio. I vote "hoax" too...
That way, Apple can tell M$: "If you don't release Word for OS X, we'll release OS X on x86"...
Re:Slashdotted, but GNOME2 *is* leagues better
on
KDE Gets The Hat
·
· Score: 3, Informative
I know plenty of developers who use GTK 1.x out of licensing issues, when they openly admire Qt but can't touch it.
I thought those issues were fixed about 2 years ago. Heck, even RMS is cool with the QPL, last I checked.
Well it depends what you're talking about. For an open-source developer, there's no problem with Qt. For someone who wants to write a closed-source application, Qt costs a lot of money. Then again, it's fair since Troll Tech has to make money somehow and making Qt GPL was already very nice of them...
How long before kernel developers are sued for patent infringement?
This brings up an interesting question. Who gets sued in this kind of situation? The one who writes the code, the one who compiles it, the one who distributes it or the user? Technically, there shouldn't be anything wrong with the source code itself, since it is not a product or a device. An example is that the ISO source code is freely distributable, even though there are many patent problems. Now it's it's not the developers, who is it? Unisys seems to have tried going after GIF users (web sites), while some others seem to try differt approaches. This is one really bad thing about software patents.
'I will answer you from the mouth of my canon' - Le Marquis de Montecalm to General James Wolfe
I'm sorry, but the quote is from Frontenac to William Phips in 1690: "Je n'ai point de réponse à faire à votre général que par la bouche de mes canons et à coups de fusil".
GPL includes some good ideas in communism. Why does anything that could resemble communism necessarily has to be bad? It's like saying "capitalism = bad", thus anything that has to do with money is bad. I think McCartism is still not that forgotten in the US.
Fair enough. BTW, have you tried -mfpmath=sse (for IA32, of course) ? Makes _real_ difference.
Tried it on two (FPU intensive) programs. On the first one, I got a ~5% performance gain and on the second one, I got NaN's so I'm not too impressed so far (that was gcc 3.1). I have however written some routines with SSE assembly and *that* provided a real gain (3x in the case I remember).
AFAIK, -mfpmath=sse only makes use of the scalar fp instructions. Any idea when the vector ones will be supported? 3.2?
I believe that the GNU and at least a few commercial fortran compilers translate the code to C before it compiles.
While this may be true (although I think both C and FORTRAN are translated to an intermediate form), I'd say that gcc doesn't qualify as a high performance FORTRAN compiler. On the other side, if you look at the compilers provided with super-computers, the FORTRAN compiler is usually much faster than the C compiler. I heard the main reason is because of the C pointers. In fortran, when a function receives two arrays as input, the compiler can assume (it's part of the language) that they are different arrays. In C, for the same function, you are allowed to send it the same array twice (it's called aliasing), so because of that, the compiler is restricted in the optimizations it can perform. This kind of ambiguities happen in other places too. That being said, I HATE FORTRAN and for me, C++ when carefully coded can be nearly as fast (Of course, I'm also using gcc which performance is adequate but not more...).
This has probably been said before, but why are we getting pissed off at spammers? It's the companies we need to "educate" as to the evils of unsolicited e-mail.
Not exactly. You won't see well established companies sending spam (ever received spam from IBM?). Spam is most of the times for fraudulent/make money quick products. If 1/10000 people fall for it these companies still make a profit and they don't care if they piss off the other 99.99% since they wouldn't be buying anyway.
What NeoNapster did is bad, but what you're proposing would be much worse. There's just too much potential for abuse. Personally, I won't contribute to a project that has such a restrictive license, as it's just too easy for the original owner to "pull the plug" pretending you're developing a "competitive product". Plus that would mean I can't just fix bugs/add new features without consent from the original author. This is definitely FAR from open-source.
I've often needed to search patents to see if my software is infringing. One of the most difficult task I found was to understand what was described in the patent. It's hard even for patents that apply to my field (speech processing), so I'd like to understand how you (and other patent examiners) handle incomprehensible patents applying to fields that's not necessarly yours. Do you think that's the reason why so many dumb/obvious patents get through?
It's not that I don't like the parentheses. I don't like C macros because even with all the parentheses you add they can still be unsafe. For example:
#define max(x,y) ((x)>(y)?(x):(y))
it will work with max(x*x,y/z) but it won't work for max(x++,--y) and there isn't much you can do about it... C/C++ inline functions don't have this problem and that's why they're much safer.
This is all nice, but the idea of open-source is being able to take the source and adapt it to your needs. This sometimes means taking many different programs and putting the source together... What happens to click-through licenses in thoses cases? You end up with 10 different?
Also, it is clear that any license that *requires* a click-through would be GPL-incompatible for obvious reasons (GPL forbids adding any restriction). That being said, nothing prevents me from taking a GPL program and adding a click-through license to it, as long as others are free to remove it from the source... For example, I could distribute a GPL binary and add an EULA that says: "if you use this binary, you accept not to sue me..."...
What are the current guesses on how much smaller we can get?
Usually, the current guesses are about twice smaller than current technilogy:-)
Seriously, there are two (in fact more) limits: there's the smallest transistor possible that works correctly and there's the smallest features size we can mass-produce with reasonnable (well, it's already unreasonnable...) cost.
Right now, the most limiting factor is the second. The visible light is already much too big (wavelength) for lithography so they're using (AFAIK) ultra-violet, but one of the problems is that the smaller the wavelength, the harder it is to find a transparent material at that wavelength (glass doesn't work past a certain wavelength).
Slashdot Mirror
It's not that easy. You always have the choice for what you want to search. If you're a drug company exec, do you tell your scientists: "Let's search for a drug that eliminates AIDS from your blood" or "Let's search for a drug that controls AIDS"? Well, if all you care about is money and shareholders, you choose the second choice because it costs less and because such a drug provides a long term revenue instead of a one-shot. Also, if you are already making lots of money selling drugs that "control AIDS", selling one that cures it will decrease your profits.
Are you sure about that 3.3V? Most current x86 CPU's run at a voltage around 1.5V. That would mean a current around 85 A. That's just insane!
Right now, with DDR, it takes 5 bus (133 MHz) cycles just to send the row and column address (RAS & CAS) to the DIMM. That means 50 CPU cycles if you have a 1.33 GHz CPU. While it takes a lot of time to access one byte of data, the memory current systems are designed so they can send the next bytes much faster. With DDR, all the other consecutive reads will only take half a cycle (that's why we say the bus is at 266 MHz, while the bus clock is really 133 MHz), which is much faster. That's how it's been working ever since the Pentium came out (with EDO memory, correct me if I'm wrong) and much longer than that with super-computers.
If you want your computer to work fast, you need to access data in memory sequentially. The first byte takes lots of time but the rest comes fast. The speed of light will eventually impose a hard limit on the memory latency one can have in a PC. Despite that, there's nothing preventing bandwidth from continuing to increase. You can keep sending the bytes faster, all it means is that while the CPU is receiving the first byte, you might already be sending the 10th one. No big problem here. Once again the super-computers have been dealing with that for a while because their memory is often far from the processor...
I know that signal speed is a substantial fraction of lightspeed
The signal goes around 2/3 of the speed of light (for those who don't know, the signal travels much faster than the electrons themselves).
As for propagation delays, it's not a new problem. Super-computers have been having that problem for years because of their size. There's no real problem, as long as you account for the delays. In the case of super-computers, it was necessary to check the length of the wires correctly. For CPU, manufacturers will have to be careful with the length of the traces. It'll add come challenge but I doubt it'll be that hard to overcome...
See, in this case, the nice part about commercial software is that you have someone to blame, and you at least stand a chance in court...
If that was true, Microsoft would be bankrupt by now...
How the hell is marketing responsible for crap code? Because they forced the product out too soon?
No. By saying "stop fixing holes, we want all these new features in Outlook for the next release" or by pushing for all kinds that are inherently hard to make secure. The UNIX way is to not implement a feature until we can implement it safely. The MS way is to implement the feature anyway and blame hackers/crackers once holes are found.
Actually, because of the low resolution and the fact that the recordings are pre-emphasized, I'd expect to hear severe aliasing in the resulting audio. I vote "hoax" too...
That way, Apple can tell M$: "If you don't release Word for OS X, we'll release OS X on x86"...
I know plenty of developers who use GTK 1.x out of licensing issues, when they openly admire Qt but can't touch it.
I thought those issues were fixed about 2 years ago. Heck, even RMS is cool with the QPL, last I checked.
Well it depends what you're talking about. For an open-source developer, there's no problem with Qt. For someone who wants to write a closed-source application, Qt costs a lot of money. Then again, it's fair since Troll Tech has to make money somehow and making Qt GPL was already very nice of them...
How long before kernel developers are sued for patent infringement?
This brings up an interesting question. Who gets sued in this kind of situation? The one who writes the code, the one who compiles it, the one who distributes it or the user? Technically, there shouldn't be anything wrong with the source code itself, since it is not a product or a device. An example is that the ISO source code is freely distributable, even though there are many patent problems. Now it's it's not the developers, who is it? Unisys seems to have tried going after GIF users (web sites), while some others seem to try differt approaches. This is one really bad thing about software patents.
Plus, didn't Wolfe defeat Montcalme?
Sort of... Wolfe himself died during the battle (so did Montcalme I think), but his army won...
'I will answer you from the mouth of my canon' - Le Marquis de Montecalm to General James Wolfe
I'm sorry, but the quote is from Frontenac to William Phips in 1690: "Je n'ai point de réponse à faire à votre général que par la bouche de mes canons et à coups de fusil".
What? The RIAA didn't tell you that not buying enough CD's is terrorism?
GPL includes some good ideas in communism. Why does anything that could resemble communism necessarily has to be bad? It's like saying "capitalism = bad", thus anything that has to do with money is bad. I think McCartism is still not that forgotten in the US.
when the goverment buys software... it becomes public domain
Public domain is fine for MS, what they don't want is that software to be GPL'd.
Fair enough. BTW, have you tried -mfpmath=sse
(for IA32, of course) ?
Makes _real_ difference.
Tried it on two (FPU intensive) programs. On the first one, I got a ~5% performance gain and on the second one, I got NaN's so I'm not too impressed so far (that was gcc 3.1). I have however written some routines with SSE assembly and *that* provided a real gain (3x in the case I remember).
AFAIK, -mfpmath=sse only makes use of the scalar fp instructions. Any idea when the vector ones will be supported? 3.2?
equivalent to storing the contents of 7,800 DVDs in one square inch of material ...how much data could be fitter in one *cubic* inch!
I believe that the GNU and at least a few commercial fortran compilers translate the code to C before it compiles.
While this may be true (although I think both C and FORTRAN are translated to an intermediate form), I'd say that gcc doesn't qualify as a high performance FORTRAN compiler. On the other side, if you look at the compilers provided with super-computers, the FORTRAN compiler is usually much faster than the C compiler. I heard the main reason is because of the C pointers. In fortran, when a function receives two arrays as input, the compiler can assume (it's part of the language) that they are different arrays. In C, for the same function, you are allowed to send it the same array twice (it's called aliasing), so because of that, the compiler is restricted in the optimizations it can perform. This kind of ambiguities happen in other places too. That being said, I HATE FORTRAN and for me, C++ when carefully coded can be nearly as fast (Of course, I'm also using gcc which performance is adequate but not more...).
This has probably been said before, but why are we getting pissed off at spammers? It's the companies we need to "educate" as to the evils of unsolicited e-mail.
Not exactly. You won't see well established companies sending spam (ever received spam from IBM?). Spam is most of the times for fraudulent/make money quick products. If 1/10000 people fall for it these companies still make a profit and they don't care if they piss off the other 99.99% since they wouldn't be buying anyway.
What NeoNapster did is bad, but what you're proposing would be much worse. There's just too much potential for abuse. Personally, I won't contribute to a project that has such a restrictive license, as it's just too easy for the original owner to "pull the plug" pretending you're developing a "competitive product". Plus that would mean I can't just fix bugs/add new features without consent from the original author. This is definitely FAR from open-source.
I've often needed to search patents to see if my software is infringing. One of the most difficult task I found was to understand what was described in the patent. It's hard even for patents that apply to my field (speech processing), so I'd like to understand how you (and other patent examiners) handle incomprehensible patents applying to fields that's not necessarly yours. Do you think that's the reason why so many dumb/obvious patents get through?
It's not that I don't like the parentheses. I don't like C macros because even with all the parentheses you add they can still be unsafe. For example:
#define max(x,y) ((x)>(y)?(x):(y))
it will work with max(x*x,y/z) but it won't work for max(x++,--y) and there isn't much you can do about it... C/C++ inline functions don't have this problem and that's why they're much safer.
This is all nice, but the idea of open-source is being able to take the source and adapt it to your needs. This sometimes means taking many different programs and putting the source together... What happens to click-through licenses in thoses cases? You end up with 10 different?
Also, it is clear that any license that *requires* a click-through would be GPL-incompatible for obvious reasons (GPL forbids adding any restriction). That being said, nothing prevents me from taking a GPL program and adding a click-through license to it, as long as others are free to remove it from the source... For example, I could distribute a GPL binary and add an EULA that says: "if you use this binary, you accept not to sue me..."...
It's a simple one, but the first time (it happened to me a couple years ago), you really search for it:
...
#define square(x) x*x
value = 1/square(x);
Ever since, any C macro I'd write has a dozen ('s in them... That's why I like inline functions...
What are the current guesses on how much smaller we can get?
:-)
Usually, the current guesses are about twice smaller than current technilogy
Seriously, there are two (in fact more) limits: there's the smallest transistor possible that works correctly and there's the smallest features size we can mass-produce with reasonnable (well, it's already unreasonnable...) cost.
Right now, the most limiting factor is the second. The visible light is already much too big (wavelength) for lithography so they're using (AFAIK) ultra-violet, but one of the problems is that the smaller the wavelength, the harder it is to find a transparent material at that wavelength (glass doesn't work past a certain wavelength).