The FSF used to boycott Apple in exactly the same way they have now decided not to boycott SCO, namely by removing (or refusing to add) explicit support for Apple configurations from their software.
The Apple boycott was motivated by Apple's "look and feel" lawsuit against HP. If look and feel was copyrightable, the GNU projeect itself was threatened since GNU very much look and feel like Unix.
Evcantually, the FSF dropped the boycott with the reason that it was not effective, the Apple management didn't care if they even knew about it.
I believe the same reason will apply to SCO, their management no longer have any interest in their own products, they are solely a litigation company these days.
I consider boycotts a legitime weapon, despite that it also hits innocents. Nobody have a moral obbligation to buy or support anything. However, such weapons should only be used when they are effective.
Mostly because the GPL requires that "no additional restrictions" on derived products. A license has to be very close to PD, or very carefully designed, to be a strict subset of the GPL.
The easiest way is actually to dual-license it (like Mozilla does with MPL/GPL), or to have a trapdoor like the LGPL, which explicitly allows you to use the GPL instead.
If the answer to the questions cannot be found in the documentations, add it.
If the answer to the question *can* be found in the documentation, ask the user where he looked for an answer. That place may need a pointer to the place where the question is answered. Then tell the user where he can find the answer, never answer it directly.
The important thing to remember is that, unless the user pay you for support, they have no right to it. If they don't pay you with money, they must pay you in some other way. For example, by supplying enough information to make their questions useful for improving the product.
I'm with him on this one, with the usual caveats. Textual protocols are so much easier to debug. Just being able to telnet to the server can be a life saver.
The usual caveats is "unless you KNOW you need it.". If your application spend most of its time passing images over a slow network, it may indeed be a good idea to use PNG (binary) instead of XPM (textual).
Static compilation time does not grow linearly with project size, unless you either aren't using a dependency tool (like make) or have organized your code to that every module depends on every other module.
With regard to the first: consider learning thee build tools part of the cost of learning a static compiled language. It is not optional.
With regard to the second: If you have so many cross-dependicies, you will run into problems in any language as the project grow. A bug solved in one module may cause new bugs to appear in any other module.
In general, Based on many years experience with C++ and Lisp, I'd recommend compiled and statically typed languages for large projects, because of the discpline they encourage. Interpreted and run-time typed languages are usually superior for small projects.
Making software "do something useful" is only a first early step towards having a finished product. It does not really have to have much of an UI in order to "do something useful", and it may only handle the common cases of whatever problem it solves, and only on the common platforms. And it may have bugs with known workarounds.
If the software despite an awkward UI, bugs and silly limitations allows you to do your work faster than you could without it, it "does something useful", and it is time to invite other developers to play with the code.
Two interesting, two insightful, one underated. But zero "funny" moderations. I do hope this means the moderators appreciate unmarked humor (even from someone who seem to think the name "dick" is funny in itself), and not that they actually believe the possible thematic analogy (about obsessed men) constitutes a copyright violation (of a work that by the way has long ago entered the public domain).
The CD duplication company is not a monopoly, but MS is (at last legally, in the US). They may be limited in what kind of anti-competitive contracts they are allowed to enter.
When you are driving on a public road, your speed is a public concern.
I think many Americans think of their car as a "second home". It isn't, it is a transportation device, and when usd as such everything you do is potentially a matter of life and dead to the people you share the road with. If you want privacy, go home where your actions does not endanger the life of other people.
Or at least, I feared they might. It is common for very large companies to settle even poorly founded lawsuits, because it is cheaper than fighting them.
I make a few bucks out of "new and original" work
on
Steal This Idea
·
· Score: 1
and does not rely on IP to do so. I am paid to come up with "new and original" work, by people who believe they need it, just like most people are.
Comparable few people make a living of selling their IP rights directly.
GCC is one of the SPEC benchmarks, and the speed of running GCC matter a lot, judging by the flames about slow compile times after GCC 3.0 was released.
All the SPEC programs are supposed to be real applications which represent classes of problems real people cares about, allthough some of the floating point benchmarks may fall short of that.
Basides who cares about what 95% of the population needs. And who, beside you, cares about what you want. SPEC was never intended for "95% of the population", it was intended for high end enginering and scientific users. It was never intended for people whose main use of their computer is to write letters to their mom, surf for porno, and occasionally edit a spreadsheet.
And this is development section of site called "news for nerds", not the leisure section of a luser magazine. We are supposed to be either developers ourself, or at least technofiles enough to realise that faster cmputers open up for ebitrely new applications areas.
... enough in 14 years to make the original irrelevant, I *want* the original to enter the public domain. The idea behind the GPL is to encourage people share their improvements. If nobody in fact does that, the code might just as well be PD.
PCH vs. compile server
on
GCC 3.3 Released
·
· Score: 2, Informative
The compile server was still experimental last I heard.
You need to reorganize your Make files to use pch's efficiently. You should
1) Not change any of your source or header files.
2) Add a new "all.h" header including all other headers, and precompile that header and only that header, whenever any other header changes.
3) all.h should not be included directly from any file, instead compile with a special flag that "pre-includes" all.h.
4) Because of header guards (which you must use), none of the normal header files will be included.
5) Because no file include all.h directly, it will not figure in the autmatic generated dependencies, and you should not add it manually. Thus, any source file will be recompiled only when the header files it includes directly are changed.
This solves the "only one include file" problem AC mentions, and means the source and include files are identical to the non-PCH version.
The danger is that there might creep in hidden dependencies, i.e. source files that does not include all the headers they should, yet compile due to the pre-include of all.h. So you will have to make an occational build without PCH.
Re:If you care about performance...
on
GCC 3.3 Released
·
· Score: 1
None, really. I used -O2/arch/cpu/fast-math flags on gcc, these are default on icc (it got them anyway).
Both icc and gcc have profile based optimization, I haven't experimented with either.
One would obviously need two datasets, one for generating the profile, and another for testing performance.
If you care about performance...
on
GCC 3.3 Released
·
· Score: 1
install both and measure. My application, a numerical simulation written in C++, was 5% slower when compiled with icc. The better benchmarks show the same thing, icc is faster for some tasks and slower for others, but expect for very specialized tasks they tend to be in the same ballpark for real applications.
GCC 3.3 is binary compatible with the 3.2 series
on
GCC 3.3 Released
·
· Score: 1
And why release it?
It fixes lots of bugs, obviously people who have been bitten by these bugs will want them fixed as soon as possible. And those who need the new feautures tend to need them yesterday.
All these people are developers. I do not see any reason for non-developers to care, just use the compiler bundled with your OS.
BTW the last full release was 3.1, quite some time ago. All the intermediate releases (including 3.2) have been bug fix releases with no new features.
It is pretty easy to do with a parallel make (GNU make is fine) and a wrapper script that rsh gcc to apropriate machines. I did it back in school when I had access to lots of Unix machines.
I don't know if there is any projects to formalize this, but in these SourceForge days there most likely is.
KDE is not dominated by binary file processing
on
GCC 3.3 Released
·
· Score: 1
so it shouldn't be affected by this particular regression.
Yacc and similar tools are optimized for languages with "nice" grammars, and have hacks to support languages with less nice grammars. The number of hacks needed to support C++ is so large that it evidently slow down the whole parser, not to mention make it unreadable. At that point, writting an add-hoc parser is better.
Re:A bug in a deprecated GCC extension
on
GCC 3.3 Released
·
· Score: 1
> *(unsigned int *)(voidpointer) = intval;
I don't think that code has a problem, the "*" operator uses an rvalue, so you don't actually use the lvalue of the cast.
If you had written
(unsigned int *)(voidpointer) =
I believe you would have been in extension territory.
The hand written parser
on
GCC 3.3 Released
·
· Score: 4, Informative
Does amazing thing for correctness, and is much easier to understand. However, it is not faster in general. It is faster at some tasks and slower at others, same on average.
It also exposes tons of errors in existing C++ programs, so expect lots of whining when GCC 3.4 is released.
GCC 3.4 will have precompiled headers (thanks Apple), which will speed compilation up a lot for project that uses them.
Slashdot Mirror
Microsoft lobbyist have been one of the, if not the, major force for making EU accept software patents.
The FSF used to boycott Apple in exactly the same way they have now decided not to boycott SCO, namely by removing (or refusing to add) explicit support for Apple configurations from their software.
The Apple boycott was motivated by Apple's "look and feel" lawsuit against HP. If look and feel was copyrightable, the GNU projeect itself was threatened since GNU very much look and feel like Unix.
Evcantually, the FSF dropped the boycott with the reason that it was not effective, the Apple management didn't care if they even knew about it.
I believe the same reason will apply to SCO, their management no longer have any interest in their own products, they are solely a litigation company these days.
I consider boycotts a legitime weapon, despite that it also hits innocents. Nobody have a moral obbligation to buy or support anything. However, such weapons should only be used when they are effective.
Mostly because the GPL requires that "no additional restrictions" on derived products. A license has to be very close to PD, or very carefully designed, to be a strict subset of the GPL.
The easiest way is actually to dual-license it (like Mozilla does with MPL/GPL), or to have a trapdoor like the LGPL, which explicitly allows you to use the GPL instead.
Basically, version 1.2 of the license was OSI approved Open Source, while version 2.0 is Stallman approved Free Software.
If the answer to the questions cannot be found in the documentations, add it.
If the answer to the question *can* be found in the documentation, ask the user where he looked for an answer. That place may need a pointer to the place where the question is answered. Then tell the user where he can find the answer, never answer it directly.
The important thing to remember is that, unless the user pay you for support, they have no right to it. If they don't pay you with money, they must pay you in some other way. For example, by supplying enough information to make their questions useful for improving the product.
I'm with him on this one, with the usual caveats. Textual protocols are so much easier to debug. Just being able to telnet to the server can be a life saver.
The usual caveats is "unless you KNOW you need it.". If your application spend most of its time passing images over a slow network, it may indeed be a good idea to use PNG (binary) instead of XPM (textual).
With regard to the first: consider learning thee build tools part of the cost of learning a static compiled language. It is not optional.
With regard to the second: If you have so many cross-dependicies, you will run into problems in any language as the project grow. A bug solved in one module may cause new bugs to appear in any other module.
In general, Based on many years experience with C++ and Lisp, I'd recommend compiled and statically typed languages for large projects, because of the discpline they encourage. Interpreted and run-time typed languages are usually superior for small projects.
Making software "do something useful" is only a first early step towards having a finished product. It does not really have to have much of an UI in order to "do something useful", and it may only handle the common cases of whatever problem it solves, and only on the common platforms. And it may have bugs with known workarounds.
If the software despite an awkward UI, bugs and silly limitations allows you to do your work faster than you could without it, it "does something useful", and it is time to invite other developers to play with the code.
Not so for traditional project management.
Two interesting, two insightful, one underated. But zero "funny" moderations. I do hope this means the moderators appreciate unmarked humor (even from someone who seem to think the name "dick" is funny in itself), and not that they actually believe the possible thematic analogy (about obsessed men) constitutes a copyright violation (of a work that by the way has long ago entered the public domain).
--
Unfunny Per
The CD duplication company is not a monopoly, but MS is (at last legally, in the US). They may be limited in what kind of anti-competitive contracts they are allowed to enter.
When you are driving on a public road, your speed is a public concern.
I think many Americans think of their car as a "second home". It isn't, it is a transportation device, and when usd as such everything you do is potentially a matter of life and dead to the people you share the road with. If you want privacy, go home where your actions does not endanger the life of other people.
Or at least, I feared they might. It is common for very large companies to settle even poorly founded lawsuits, because it is cheaper than fighting them.
and does not rely on IP to do so. I am paid to come up with "new and original" work, by people who believe they need it, just like most people are.
Comparable few people make a living of selling their IP rights directly.
GCC is one of the SPEC benchmarks, and the speed of running GCC matter a lot, judging by the flames about slow compile times after GCC 3.0 was released.
All the SPEC programs are supposed to be real applications which represent classes of problems real people cares about, allthough some of the floating point benchmarks may fall short of that.
Basides who cares about what 95% of the population needs. And who, beside you, cares about what you want. SPEC was never intended for "95% of the population", it was intended for high end enginering and scientific users. It was never intended for people whose main use of their computer is to write letters to their mom, surf for porno, and occasionally edit a spreadsheet.
And this is development section of site called "news for nerds", not the leisure section of a luser magazine. We are supposed to be either developers ourself, or at least technofiles enough to realise that faster cmputers open up for ebitrely new applications areas.
... enough in 14 years to make the original irrelevant, I *want* the original to enter the public domain. The idea behind the GPL is to encourage people share their improvements. If nobody in fact does that, the code might just as well be PD.
The compile server was still experimental last I heard.
You need to reorganize your Make files to use pch's efficiently. You should
1) Not change any of your source or header files.
2) Add a new "all.h" header including all other headers, and precompile that header and only that header, whenever any other header changes.
3) all.h should not be included directly from any file, instead compile with a special flag that "pre-includes" all.h.
4) Because of header guards (which you must use), none of the normal header files will be included.
5) Because no file include all.h directly, it will not figure in the autmatic generated dependencies, and you should not add it manually. Thus, any source file will be recompiled only when the header files it includes directly are changed.
This solves the "only one include file" problem AC mentions, and means the source and include files are identical to the non-PCH version.
The danger is that there might creep in hidden dependencies, i.e. source files that does not include all the headers they should, yet compile due to the pre-include of all.h. So you will have to make an occational build without PCH.
None, really. I used -O2/arch/cpu/fast-math flags on gcc, these are default on icc (it got them anyway).
Both icc and gcc have profile based optimization, I haven't experimented with either.
One would obviously need two datasets, one for generating the profile, and another for testing performance.
install both and measure. My application, a numerical simulation written in C++, was 5% slower when compiled with icc. The better benchmarks show the same thing, icc is faster for some tasks and slower for others, but expect for very specialized tasks they tend to be in the same ballpark for real applications.
And why release it?
It fixes lots of bugs, obviously people who have been bitten by these bugs will want them fixed as soon as possible. And those who need the new feautures tend to need them yesterday.
All these people are developers. I do not see any reason for non-developers to care, just use the compiler bundled with your OS.
BTW the last full release was 3.1, quite some time ago. All the intermediate releases (including 3.2) have been bug fix releases with no new features.
It is pretty easy to do with a parallel make (GNU make is fine) and a wrapper script that rsh gcc to apropriate machines. I did it back in school when I had access to lots of Unix machines.
I don't know if there is any projects to formalize this, but in these SourceForge days there most likely is.
so it shouldn't be affected by this particular regression.
Yacc and similar tools are optimized for languages with "nice" grammars, and have hacks to support languages with less nice grammars. The number of hacks needed to support C++ is so large that it evidently slow down the whole parser, not to mention make it unreadable. At that point, writting an add-hoc parser is better.
thus, I can follow the development list.
> *(unsigned int *)(voidpointer) = intval;
I don't think that code has a problem, the "*" operator uses an rvalue, so you don't actually use the lvalue of the cast.
If you had written
(unsigned int *)(voidpointer) =
I believe you would have been in extension territory.
Does amazing thing for correctness, and is much easier to understand. However, it is not faster in general. It is faster at some tasks and slower at others, same on average.
It also exposes tons of errors in existing C++ programs, so expect lots of whining when GCC 3.4 is released.
GCC 3.4 will have precompiled headers (thanks Apple), which will speed compilation up a lot for project that uses them.