I remember playing games on a C64, and I'm under 25. Of course most of them were stupid edu-tainment things my parents got me. Curse you, Algebra Dragons!
I even have a framed picture of me playing with a paint program (Koala Paint) on my dad's C64 when I was 3 years old.
... in that area of the world, most males own firearms, usually at least an AK, for various reasons, and YES again, it is a big part of their culture to shoot them off at times of celebration.
Scenario 1: The US bombs a gathering of rebels. The rebels claim it was a "wedding party" (everyone has guns at wedding parties, right?). US and foreign journalists pick up conflicting reports.
Scenario 2: The US bombs a wedding party. US spokesmen claim it was a gathering of rebels (everyone has guns at wedding parties, right?). US and foreign journalists pick up conflicting reports.
Now, I won't say which I think is more likely. Are the rebels lying, or did the US make a mistake?
(Most of the rest of your criticisms are dead on. This particular one just irks me.)
I just see this as an extension to the whole "extreme programming" idea of "code something, anything, until you get the output you want for your test cases, then stop coding".
It's a good idea in theory, but it seems much better to have a well thought out approach.
Figuring out how different optimization passes interact is too complicated for humans to do correctly. The interactions tend to be subtle, unexpected, and sometimes completely counterintuitive. The only way to get it right is to run lots of real-world testcases with different combinations of optimizations and tune the defaults based on the results. Acovea just automates that for the nice folks working on gcc.
Q: How can you tell you have perhaps gone slightly overboard in making compiler optimization options available?
A: Your users have not just given up trying to reason out what they should do, or even brute forcing every possible combination, they're inventing fucking genetic algorithms to find out what works best.
Actually, this isn't intended for users, really. It's intended to help the compiler writers figure out what combinations of passes work best, so that the compiler writers can give the users simple options. Optimization passes tend to interact in subtle and unexpected ways, so a genetic algorithm is actually a good way to figure out what works.
Not officially released yet
on
GCC 3.4.0 Released
·
· Score: 5, Informative
This announcement is premature, it's still propagating to mirrors; the "announcment" is an error. The official release will be tomorrow.
First, I am not a physicist, but I suspect that "break-even" is defined as the TOTAL power output of the system!
All the energy put in comes out again (as heat, light, sound, etc), plus some additional energy released by the fusion. Since the total energy output must be greater than the input, but they haven't "broken even", they must be referring to the usable energy.
This article seems poorly thought out, fails to address the topic with many points, and is generally confused. Let's take a few examples...
Problems: Distributed Database vs. Brain I'd be more impressed with this if I knew what the author thinks distributed databases have to do with computer games. And "systemic pliability for quick changes and alterations to code blocks"? What does that mean?
The Adventure There's already nine starting stories, which is eight more than most games. How will you make the quest depend on class when the party can have up to five people of any combination of classes?
Solution: Standards Compliance The problem with this list is, as far as I can tell, D20 already has all this. Though I may be wrong, since the article is hardly clear.
I could go on but I can feel my IQ decreasing with every paragraph I read, so I'll stop here...
You are honestly suggesting that the video subsystem is not a "major component of the operating system"?
I'm saying that I don't think that it's so clear as to be beyond dispute.
Even to the extent that a compiler is? You can run/distribute a system without a compiler too.
You can't run a system without the compiler's runtime libraries. You can't run a system without the kernel, either.
XFree86 IS the operating system/kernel for my video card--it has the drivers and provides the hardware interface.
Interesting analogy, but that's all that it is. XFree86 runs on your CPU, not your video card. It's not an operating system any more than the driver for a printer, scanner, or digital camera is.
It comes with the distribution, and most any gui program assumes that (and rightly so).
You could replace it with any other X server and those GUI programs would still work. Not all distributions include XFree86, or even any X server at all. Probably almost as many distributions include vi, and I don't think it's part of the OS.
It's not even "normally distributed with"--it IS part of the OS.
This is begging the question.
How much clearer could it get for the OS exception?
Since you ask - it could be a kernel or compiler runtime library, which are specifically mentioned in the GPL.
I don't think anyone realistically could contest that XFree86 is a system library in pretty much any distribution (MacOS X and cygwin come to mind as the likely exceptions).
The exception is:
However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
Unfortunately XFree86 isn't a compiler or kernel, which means that determining whether it's a "major component" would probably involve lawyers. You might argue that it's "normally distributed" with the compiler or kernel, but there are certainly distros where it isn't (either because they use an alternate X server, or they don't include X at all).
The fact that it's not totally 100% clear will probably scare off a number of distributors.
Note: This doesn't stop you making GPLed applications which use X.
In practice it's next to impossible to get all the contributors to any nontrivial, existing project to agree to a license change so that you can use a non-GPL-compatible library. So you can make new GPLed applications that use X, but a bunch of existing apps are SOL.
Also, note that if XFree86 were GPL-compatable then placing any piece of GPLed code into it would force the whole program to be GPLed.
If XFree86 were GPL-compatible, then placing any piece of GPL code into it, and distributing the result under a license incompatible with the GPL, would not be allowed.
If XFree86 were GPL-incompatible, then placing any piece of GPL code into it, and distributing the result under any license at all, would not be allowed.
In either case you can simply avoid using any GPL code. No one can "force" you to release your program under the GPL.
It's only a problem if they wish to statically link such GPL software. In all other cases, all they are linking to is the X11R6 API. There is no problem with GPL programs linking to Sun's proprietary OpenWindows, so why would there by linking with XFree86's Free Software implementation?
You might want to read the GPL FAQ, particularly this question. Linking a GPL program to a non-GPL library, even dynamically, is problematic; you can only do it safely by using a version of the GPL modified with a "special exception" clause. Remember that the GPL, unlike the LGPL, doesn't make a distinction between static and dynamic linking.
Even the GPL does not claim that linking to GPL'ed libraries makes your program GPL
Oh yes it does, read this. If you link to a GPL library, your program must be GPL.
The situation in this case is the opposite - using a non-GPL-compatible library in a GPL program. Doing that requires a special exception, which means that all the existing GPL programs can't link to non-GPL-compatible XFree86 libraries. Even if you put an exception in your license, you can't also link to a GPL library unless that library also has the exception.
so I don't think linking to Xfree86-licensed libraries makes your program XFree86-licensed.
This is not the problem. The problem is that the libraries are XFree86-licensed, and the GPL won't allow you to use them in a GPL program if they contain the documentation clause. The XFree86 license doesn't care about linking, but the GPL does.
My mom is a molecular biologist who works on viruses for a living, and I've worked with molecular biologists before. Let me assure you that if you said "virii" in a scientific conference you would be laughed out of the room.
In my opinion it might be acceptable to use "virii" for computer viruses. If we can pluralize "box" as "boxen", why not. But it's definitely not the standard plural of "virus".
However, section 3b does allow the original distributor of the binary to charge a nominal fee for a copy of the source, so the you can't request the source "without paying".
I meant without paying for the binary. The fee for distributing the source under 3b can only be as much as it actually costs to send a copy, so the distributor won't make a profit on sending the source (or even enough to cover overhead).
For one thing, the GPL only requires you to make source code available to the people who have the binaries. In other words, if you haven't paid, you don't have any right to complain.
Re:So, we're awarding wasted duplication of effort
on
Open Source Awards 2004
·
· Score: 2, Informative
What I don't get is whether or not the GPL allow you to take software, add a few function calls Call_From_Closed_Source_Library();, link against said closed library, and redistribute for $$ w/o distributing source for your closed library...?
Re:The Grandmasters and Specials yet to be announc
on
Open Source Awards 2004
·
· Score: 4, Informative
Only one of those names gives me any semblance of a clue of what it might do.
Valgrind, okay, I'll give you that one. The name is from Nordic mythology, as explained in an interview with Julian Seward. It actually makes a bit of sense if you know what it means.
VideoLAN is obvious.
JACK is used to connect audio programs together. The name makes sense to me.
Pango, well, I got the name immediately, and I think it's a perfect description. But I admit that many people won't understand a combination of Greek and Japanese roots meaning "all languages".
four obscure flash-in-the-pan programs which do nothing to advance the cause of Free Software are getting a brief bit of exposure.
Obscure? To you, maybe. Flash-in-the-pan? Definitely not. And don't advance Free Software? All of them (except maybe JACK, which I've never heard of before) have improved OS/FS enormously. Valgrind is just amazing - although you may never have heard of it, the chances are you use daily a program that it's debugged. Pango makes using multiple languages actually easier on Linux than Windows in my experience. VideoLAN, well, try it yourself.
Garbage, you've never worked on a commercial enterprise scale product.
True enough, I've mainly done scientific programming. The project I work on is not performance-intensive, while the guy across the hall does heavy number crunching (and still uses gcc).
10% improvement in performance can make a significant difference to performance targets for an average software product, saving reasonable amount of development time, effort and cost.
Sorry, I've been thinking of compiling open-source and in-house software. I assume without saying that software developed for sale will use the compiler that makes the most economic sense.
I should have mentioned: the slow timings with icc (entries 4,5,6 in the table above) were done with -O0 (optimization turned off).
I assume that with icc, -O0 doesn't really mean no optimization, it just means not to do any optimizations that take extra time. Some optimizations actually decrease compile time, or at least have no effect, because they decrease the amount of work later stages have to do.
GCC currently interprets -O0 as meaning no optimization at all, which makes comparing the speed of gcc -O0 to anything (even gcc at a higher -O option) silly. Intel's -O0 is probably closer to gcc's -O1.
Since this is Slashdot, this will quickly turn into a stupid bashing of Intel in favor of gcc, since everyone likes Free stuff and hates corporations.
"Free stuff" and "corporations" are not mutually exclusive. Most of the work done on gcc is by people who are paid to work on it.
And everyone will talk out of their asses about how the Intel compilers couldn't possibly be faster than gcc.
There are still many interesting optimizations that gcc doesn't implement. A lot of work is being done on adding them to the tree-ssa branch, which hopefully will be merged into mainline gcc for 3.5.
So, I figured I'd throw out some real numbers:
It sounds like you're doing floating-point intensive number crunching code, which quite honestly is where icc should give the greatest benefit over gcc. On integer workloads they should be much closer. Number crunching gets a big boost from vectorization, and icc does automatic vectorization. GCC doesn't (though work is underway), and it won't use vector instructions at all unless you supply -mmmx, -msse, -msse2, and/or an -march option that specifies an appropriate CPU type. You can still get the advantage of vectorization if you're willing to code it explicitly.
Slashdot Mirror
I remember playing games on a C64, and I'm under 25. Of course most of them were stupid edu-tainment things my parents got me. Curse you, Algebra Dragons!
I even have a framed picture of me playing with a paint program (Koala Paint) on my dad's C64 when I was 3 years old.
I know that. It wasn't intended as sarcasm.
Scenario 1: The US bombs a gathering of rebels. The rebels claim it was a "wedding party" (everyone has guns at wedding parties, right?). US and foreign journalists pick up conflicting reports.
Scenario 2: The US bombs a wedding party. US spokesmen claim it was a gathering of rebels (everyone has guns at wedding parties, right?). US and foreign journalists pick up conflicting reports.
Now, I won't say which I think is more likely. Are the rebels lying, or did the US make a mistake?
(Most of the rest of your criticisms are dead on. This particular one just irks me.)
I just see this as an extension to the whole "extreme programming" idea of "code something, anything, until you get the output you want for your test cases, then stop coding".
It's a good idea in theory, but it seems much better to have a well thought out approach.
Figuring out how different optimization passes interact is too complicated for humans to do correctly. The interactions tend to be subtle, unexpected, and sometimes completely counterintuitive. The only way to get it right is to run lots of real-world testcases with different combinations of optimizations and tune the defaults based on the results. Acovea just automates that for the nice folks working on gcc.
Q: How can you tell you have perhaps gone slightly overboard in making compiler optimization options available?
A: Your users have not just given up trying to reason out what they should do, or even brute forcing every possible combination, they're inventing fucking genetic algorithms to find out what works best.
Actually, this isn't intended for users, really. It's intended to help the compiler writers figure out what combinations of passes work best, so that the compiler writers can give the users simple options. Optimization passes tend to interact in subtle and unexpected ways, so a genetic algorithm is actually a good way to figure out what works.
This announcement is premature, it's still propagating to mirrors; the "announcment" is an error. The official release will be tomorrow.
First, I am not a physicist, but I suspect that "break-even" is defined as the TOTAL power output of the system!
All the energy put in comes out again (as heat, light, sound, etc), plus some additional energy released by the fusion. Since the total energy output must be greater than the input, but they haven't "broken even", they must be referring to the usable energy.
This article seems poorly thought out, fails to address the topic with many points, and is generally confused. Let's take a few examples...
Problems: Distributed Database vs. Brain
I'd be more impressed with this if I knew what the author thinks distributed databases have to do with computer games. And "systemic pliability for quick changes and alterations to code blocks"? What does that mean?
The Adventure
There's already nine starting stories, which is eight more than most games. How will you make the quest depend on class when the party can have up to five people of any combination of classes?
Solution: Standards Compliance
The problem with this list is, as far as I can tell, D20 already has all this. Though I may be wrong, since the article is hardly clear.
I could go on but I can feel my IQ decreasing with every paragraph I read, so I'll stop here...
Engineering is taking a specification and making a product from it.
Reverse engineering is taking a product and making a specification for it.
This is clearly an example of normal engineering.
Scrapped Princess is definitely another anime in that category.
You are honestly suggesting that the video subsystem is not a "major component of the operating system"?
I'm saying that I don't think that it's so clear as to be beyond dispute.
Even to the extent that a compiler is? You can run/distribute a system without a compiler too.
You can't run a system without the compiler's runtime libraries. You can't run a system without the kernel, either.
XFree86 IS the operating system/kernel for my video card--it has the drivers and provides the hardware interface.
Interesting analogy, but that's all that it is. XFree86 runs on your CPU, not your video card. It's not an operating system any more than the driver for a printer, scanner, or digital camera is.
It comes with the distribution, and most any gui program assumes that (and rightly so).
You could replace it with any other X server and those GUI programs would still work. Not all distributions include XFree86, or even any X server at all. Probably almost as many distributions include vi, and I don't think it's part of the OS.
It's not even "normally distributed with"--it IS part of the OS.
This is begging the question.
How much clearer could it get for the OS exception?
Since you ask - it could be a kernel or compiler runtime library, which are specifically mentioned in the GPL.
The exception is:
Unfortunately XFree86 isn't a compiler or kernel, which means that determining whether it's a "major component" would probably involve lawyers. You might argue that it's "normally distributed" with the compiler or kernel, but there are certainly distros where it isn't (either because they use an alternate X server, or they don't include X at all).
The fact that it's not totally 100% clear will probably scare off a number of distributors.
Note: This doesn't stop you making GPLed applications which use X.
In practice it's next to impossible to get all the contributors to any nontrivial, existing project to agree to a license change so that you can use a non-GPL-compatible library. So you can make new GPLed applications that use X, but a bunch of existing apps are SOL.
Also, note that if XFree86 were GPL-compatable then placing any piece of GPLed code into it would force the whole program to be GPLed.
If XFree86 were GPL-compatible, then placing any piece of GPL code into it, and distributing the result under a license incompatible with the GPL, would not be allowed.
If XFree86 were GPL-incompatible, then placing any piece of GPL code into it, and distributing the result under any license at all, would not be allowed.
In either case you can simply avoid using any GPL code. No one can "force" you to release your program under the GPL.
It's only a problem if they wish to statically link such GPL software. In all other cases, all they are linking to is the X11R6 API. There is no problem with GPL programs linking to Sun's proprietary OpenWindows, so why would there by linking with XFree86's Free Software implementation?
You might want to read the GPL FAQ, particularly this question. Linking a GPL program to a non-GPL library, even dynamically, is problematic; you can only do it safely by using a version of the GPL modified with a "special exception" clause. Remember that the GPL, unlike the LGPL, doesn't make a distinction between static and dynamic linking.
Even the GPL does not claim that linking to GPL'ed libraries makes your program GPL
Oh yes it does, read this. If you link to a GPL library, your program must be GPL.
The situation in this case is the opposite - using a non-GPL-compatible library in a GPL program. Doing that requires a special exception, which means that all the existing GPL programs can't link to non-GPL-compatible XFree86 libraries. Even if you put an exception in your license, you can't also link to a GPL library unless that library also has the exception.
so I don't think linking to Xfree86-licensed libraries makes your program XFree86-licensed.
This is not the problem. The problem is that the libraries are XFree86-licensed, and the GPL won't allow you to use them in a GPL program if they contain the documentation clause. The XFree86 license doesn't care about linking, but the GPL does.
Okay... this, is an 'OLD' BSD style licence clause.
Not quite, but it has similar problems.
It conflicts with the GPL and thus, people wanting to put GPL software in XFree86 wont be able to.
Or, more to the point, people wanting to use XFree86 libraries in GPL software. That is a problem.
My mom is a molecular biologist who works on viruses for a living, and I've worked with molecular biologists before. Let me assure you that if you said "virii" in a scientific conference you would be laughed out of the room.
In my opinion it might be acceptable to use "virii" for computer viruses. If we can pluralize "box" as "boxen", why not. But it's definitely not the standard plural of "virus".
However, section 3b does allow the original distributor of the binary to charge a nominal fee for a copy of the source, so the you can't request the source "without paying".
I meant without paying for the binary. The fee for distributing the source under 3b can only be as much as it actually costs to send a copy, so the distributor won't make a profit on sending the source (or even enough to cover overhead).
For one thing, the GPL only requires you to make source code available to the people who have the binaries. In other words, if you haven't paid, you don't have any right to complain.
Even if they charge for the binary, someone can give a copy to someone else, and then that person can request the source without paying.
What I don't get is whether or not the GPL allow you to take software, add a few function calls Call_From_Closed_Source_Library();, link against said closed library, and redistribute for $$ w/o distributing source for your closed library...?
No, you can't.
Only one of those names gives me any semblance of a clue of what it might do.
Valgrind, okay, I'll give you that one. The name is from Nordic mythology, as explained in an interview with Julian Seward. It actually makes a bit of sense if you know what it means.
VideoLAN is obvious.
JACK is used to connect audio programs together. The name makes sense to me.
Pango, well, I got the name immediately, and I think it's a perfect description. But I admit that many people won't understand a combination of Greek and Japanese roots meaning "all languages".
four obscure flash-in-the-pan programs which do nothing to advance the cause of Free Software are getting a brief bit of exposure.
Obscure? To you, maybe. Flash-in-the-pan? Definitely not. And don't advance Free Software? All of them (except maybe JACK, which I've never heard of before) have improved OS/FS enormously. Valgrind is just amazing - although you may never have heard of it, the chances are you use daily a program that it's debugged. Pango makes using multiple languages actually easier on Linux than Windows in my experience. VideoLAN, well, try it yourself.
Garbage, you've never worked on a commercial enterprise scale product.
True enough, I've mainly done scientific programming. The project I work on is not performance-intensive, while the guy across the hall does heavy number crunching (and still uses gcc).
10% improvement in performance can make a significant difference to performance targets for an average software product, saving reasonable amount of development time, effort and cost.
Sorry, I've been thinking of compiling open-source and in-house software. I assume without saying that software developed for sale will use the compiler that makes the most economic sense.
I should have mentioned: the slow timings with icc (entries 4,5,6 in the table above) were done with -O0 (optimization turned off).
I assume that with icc, -O0 doesn't really mean no optimization, it just means not to do any optimizations that take extra time. Some optimizations actually decrease compile time, or at least have no effect, because they decrease the amount of work later stages have to do.
GCC currently interprets -O0 as meaning no optimization at all, which makes comparing the speed of gcc -O0 to anything (even gcc at a higher -O option) silly. Intel's -O0 is probably closer to gcc's -O1.
Since this is Slashdot, this will quickly turn into a stupid bashing of Intel in favor of gcc, since everyone likes Free stuff and hates corporations.
"Free stuff" and "corporations" are not mutually exclusive. Most of the work done on gcc is by people who are paid to work on it.
And everyone will talk out of their asses about how the Intel compilers couldn't possibly be faster than gcc.
There are still many interesting optimizations that gcc doesn't implement. A lot of work is being done on adding them to the tree-ssa branch, which hopefully will be merged into mainline gcc for 3.5.
So, I figured I'd throw out some real numbers:
It sounds like you're doing floating-point intensive number crunching code, which quite honestly is where icc should give the greatest benefit over gcc. On integer workloads they should be much closer. Number crunching gets a big boost from vectorization, and icc does automatic vectorization. GCC doesn't (though work is underway), and it won't use vector instructions at all unless you supply -mmmx, -msse, -msse2, and/or an -march option that specifies an appropriate CPU type. You can still get the advantage of vectorization if you're willing to code it explicitly.