Any companies that have essential patents for an IEEE standard are required to disclose them and give letters of assurances that they will license them to users under FRAND conditions. Samsung did do this.
In my opinion, the terms that Samsung offered were not "Reasonable" and were completely out of line compared to all other license fees associated with IEEE standards. Typically these fees are "one time fees per company, often less than $1000.00 USD". I feel that this causes a "chilling effect" with all existing IEEE standards until IEEE defines what exactly "Reasonable" means. (disclaimer: I am technical editor for two IEEE standards)
Regardless of my opinions, ITC said the fees to Apple were reasonable. I guess here the government steps in and says that the fees still stand but the ruling can't block the shipment of devices.
The reality is that the original code was not portable between supercomputers and already comes up with incorrect answers but yet people didn't realize it until now! Do you realize that this means that all the weather forecasts from the first supercomputer implementation of this program are now known to be wrong too? What is the cost of having answers that have unknown accuracy?
You don't have to use Boost - but you HAVE TO manage your intervals and accuracy and rounding errors! If you don't then you can not know what the accuracy is of your answers! Note this has relevance beyond supercomputing too - Digital Signal Processing of Audio also is adversely affected by people programming floating point filters incorrectly, causing noise artifacts and inharmonic distortion due to improper noise shaping and bad coefficient rounding and fading.
In the cast of the boost-interval library, the link I posted has a very clear warning about that; so I don't understand why that quote is relevant here. This warning shows that "floating point is hard" and that is MORE reason to be careful with your intervals!
Warning! Guaranteed interval arithmetic for native floating-point format is not supported on every combination of processor, operating system, and compiler. This is a list of systems known to work correctly when using interval and interval with basic arithmetic operators.
x86-like hardware is supported by the library with GCC, Visual C++ 7.1, Intel compiler ( 8 on Windows), CodeWarrior ( 9), as long as the traditional x87 floating-point unit is used for floating-point computations (no -mfpmath=sse2 support). Sparc hardware is supported with GCC and Sun compiler. PowerPC hardware is supported with GCC and CodeWarrior, when floating-point computations are not done with the Altivec unit. Alpha hardware is supported with GCC, except maybe for the square root. The options -mfp-rounding-mode=d -mieee have to be used. The previous list is not exhaustive. And even if a system does not provide guaranteed computations for hardware floating-point types, the interval library is still usable with user-defined types and for doing box arithmetic.
Good points - in fact in this case one can say that ALL of the calculations done by the different computer architectures are in fact wrong. to varying degrees When doing floating point math without rounding analysis being done then all bets are off. Measurements always have accuracies, and floating point math also adds it's own inaccuracies.
Of course all this extra interval management costs in terms of development and performance. But what is the cost of having supercomputers coming up with answers with unknown accuracy?
What is the problem here? Why couldn't the web browser just make sure that the cookies are passed via RFC3514 ( http://www.ietf.org/rfc/rfc3514.txt ) compliant packets (with the E bit field set to FALSE) if the advertiser is trustable?
They haven't said which image bank they used. It doesn't matter how they got ahold of stolen material, right? The photographers need to sue the infringing party. The infringing party can then sue the image bank or the employee or whoever was responsible.
Also, the Xilinx FPGA design tools are only officially supported on RHEL. While I run Xilinx tools (and Impact JTAG programmer) with patched drivers, if I ever run into a problem they would look at the log file and refuse to help if they see that I am not running the supported RHEL.
No, really, it is Steve Job's fault - personally - that since the devices are loved so much by users, the re-sale black market price is high allowing big profits for people who steal them. If ONLY Steve Job made the products lousy, no one would pay for them! and no one would steal them!
Uh.... I wonder if the criminals DON'T steal the Android phones?
One could make a library that just spawns a sub-process running GCCXML, then grab the result and pass the appropriate parts of the parse tree to the caller.
GCC has been effectively re-written many times during that time. I myself was involved in the porting of G++ v1.38 (before GNU G++ was part of GCC) to run self-hosted on the Atari ST, back in 1989 or 1990. I don't think anything still exists from that code base in GCC 4.7 at all.
...More like the barber shows you the cool new shaver that you didn't understand and that he helped design.
An interesting exercise is to compare the internals of Clang, written in more modern C++ versus gcc, written in C, and to decide for yourself which one you'd rather maintain.
This is what I don't understand - If GCC is under the GPL, and was modified to be a library, under the GPL the front ends / library clients that use it would ALSO have to be released under the GPL. The original developers had no problem with that. So what, exactly, would the problem be for RMS? It could only have increased the pervasiveness of GNU/GCC. And if there was some problem that RMS knows about then this would be a problem with the specific license that GCC uses.
Slashdot Mirror
Well, apparently the people who wrote the software that this whole article was about did not know that their software was broken because of this. http://journals.ametsoc.org/doi/abs/10.1175/MWR-D-12-00352.1
All patents related to IEEE standards are listed on the IEEE website:
http://standards.ieee.org/about/sasb/patcom/patents.html
Any companies that have essential patents for an IEEE standard are required to disclose them and give letters of assurances that they will license them to users under FRAND conditions. Samsung did do this.
In my opinion, the terms that Samsung offered were not "Reasonable" and were completely out of line compared to all other license fees associated with IEEE standards. Typically these fees are "one time fees per company, often less than $1000.00 USD". I feel that this causes a "chilling effect" with all existing IEEE standards until IEEE defines what exactly "Reasonable" means. (disclaimer: I am technical editor for two IEEE standards)
Of course that in itself can be a huge problem for GPL and any open source implementations - for instance see the patents that Samsung has on Precision Time Protocol ( http://standards.ieee.org/about/sasb/patcom/loa-1588-samsung-12apr2007.pdf ) which were blocking RedHat from releasing ptpd: https://bugzilla.redhat.com/show_bug.cgi?id=556611 - It looks like in this ptpd case, Samsung was reasonable and allows people to do time stamping of packets for free as in GPL.
Regardless of my opinions, ITC said the fees to Apple were reasonable. I guess here the government steps in and says that the fees still stand but the ruling can't block the shipment of devices.
The difference here is that Samsung did agree to license essential patents for an IEEE standard under FRAND with the IEEE and then refused to do so.
Thank you for bringing attention to this! I did not know about what they are doing.
The reality is that the original code was not portable between supercomputers and already comes up with incorrect answers but yet people didn't realize it until now! Do you realize that this means that all the weather forecasts from the first supercomputer implementation of this program are now known to be wrong too? What is the cost of having answers that have unknown accuracy?
You don't have to use Boost - but you HAVE TO manage your intervals and accuracy and rounding errors! If you don't then you can not know what the accuracy is of your answers! Note this has relevance beyond supercomputing too - Digital Signal Processing of Audio also is adversely affected by people programming floating point filters incorrectly, causing noise artifacts and inharmonic distortion due to improper noise shaping and bad coefficient rounding and fading.
Jeff
In the cast of the boost-interval library, the link I posted has a very clear warning about that; so I don't understand why that quote is relevant here. This warning shows that "floating point is hard" and that is MORE reason to be careful with your intervals!
Good points - in fact in this case one can say that ALL of the calculations done by the different computer architectures are in fact wrong. to varying degrees When doing floating point math without rounding analysis being done then all bets are off. Measurements always have accuracies, and floating point math also adds it's own inaccuracies.
The Boost library can help: http://www.boost.org/doc/libs/1_54_0/libs/numeric/interval/doc/interval.htm
Of course all this extra interval management costs in terms of development and performance. But what is the cost of having supercomputers coming up with answers with unknown accuracy?
Please see http://www.eetimes.com/document.asp?doc_id=1280095 for more information on interesting developments with regards to automotive usages of Audio Video Bridging in Infotainment and control - http://avb.statusbar.com/faq.html - typically using Linux.
Pardon my ignorance but.... Isn't there a law against Snowden exercising his free speech rights to disclose what he learned about the NSA?
:-(
Yes, you are right.
Until RFC3514 is updated for IPv6, we can't expect IPv6 to gain full acceptance simply because of the lack of the E bit.
What is the problem here? Why couldn't the web browser just make sure that the cookies are passed via RFC3514 ( http://www.ietf.org/rfc/rfc3514.txt ) compliant packets (with the E bit field set to FALSE) if the advertiser is trustable?
I have a 20 meg MFM hard drive that is not readable by any computer anymore... just because of the interface.
He either outright knowingly lied before, or is incompetent. Not much intelligence there....
Wow! Thank you for that fix!
That event could have been a whole lot worse!
They haven't said which image bank they used. It doesn't matter how they got ahold of stolen material, right? The photographers need to sue the infringing party. The infringing party can then sue the image bank or the employee or whoever was responsible.
Why are people assuming that the BATF's concern is safety, or criminals?
Perhaps their primary concern is the market for firearms.
Currently, 3D printed firearms will not impact the sales of real firearms.
Also, the Xilinx FPGA design tools are only officially supported on RHEL. While I run Xilinx tools (and Impact JTAG programmer) with patched drivers, if I ever run into a problem they would look at the log file and refuse to help if they see that I am not running the supported RHEL.
No, really, it is Steve Job's fault - personally - that since the devices are loved so much by users, the re-sale black market price is high allowing big profits for people who steal them. If ONLY Steve Job made the products lousy, no one would pay for them! and no one would steal them!
Uh.... I wonder if the criminals DON'T steal the Android phones?
Criminal: "Give me your iPhone!"
Geek: "I have an Android phone!"
Criminal: "Darn, ok you can keep your Android."
???
For me, with GCC 4.7.2, the -ftree-vectorize fails miserably compared to GCC 4.3 for code that is already prepared for SSE or NEON vectorization.
Good points. So the issue is really with the GPL license enforceability....
I wonder if the same issues are at hand with GCCXML : http://www.gccxml.org/HTML/Index.html
One could make a library that just spawns a sub-process running GCCXML, then grab the result and pass the appropriate parts of the parse tree to the caller.
No linking involved, no GPL violations either.
That's not true in general, and not true specifically when generating SIMD code for SSE4 or ARM NEON.
All the latest GCC versions 4.4, 4.5, 4.6 have serious regressions in SIMD optimizations, it actually went backwards in efficiency over the years.
Final code efficiency is the primary reason why I needed to switch to Clang.
It is a real pain btw to have to have two C compilers for a single embedded device!
GCC has been effectively re-written many times during that time. I myself was involved in the porting of G++ v1.38 (before GNU G++ was part of GCC) to run self-hosted on the Atari ST, back in 1989 or 1990. I don't think anything still exists from that code base in GCC 4.7 at all.
...More like the barber shows you the cool new shaver that you didn't understand and that he helped design.
An interesting exercise is to compare the internals of Clang, written in more modern C++ versus gcc, written in C, and to decide for yourself which one you'd rather maintain.
http://llvm.org/svn/llvm-project/cfe/trunk/
http://gcc.gnu.org/viewcvs/trunk/gcc/
Note that Clang is written in modern C++ and is also faster than GCC.
One benchmark shown is that clang loading a parse tree of 'precompiled headers' is almost the same time as it takes to just compile the headers.
FWIW, I'm switching to Clang wherever it is supported because of all of the regressions in GCC for vectorization in C and C++ since GCC 4.2
This is what I don't understand - If GCC is under the GPL, and was modified to be a library, under the GPL the front ends / library clients that use it would ALSO have to be released under the GPL. The original developers had no problem with that. So what, exactly, would the problem be for RMS? It could only have increased the pervasiveness of GNU/GCC. And if there was some problem that RMS knows about then this would be a problem with the specific license that GCC uses.
Absolutely.
Also, one of the interesting points about the primary reasoning behind the creation of the CLANG compiler was not because of the GPL license.
it was because the developers wanted to make GCC more powerful, so that it could be used as a library.
Stallman refused to allow the features to be added even though they were not asking for the GPL licensing to be changed.
So the developers started CLANG. In c++. as a library.
Watch this for some very interesting history and features:
http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Clang-Defending-C-from-Murphy-s-Million-Monkeys