You have completely missed the point. You have just quoted the completely arbitrary rules of Larry McVoy which are subject to change at his whim. When/if CVS makes some strategic feature addition Larry will once again quote you yet another arbitrary set of rules for you to follow.
And I personally refuse to use inferior tools because of ideology. In fact, I will go as far as saying that making excuses for bad tools due to ideology is _stupid_, and people who do that think with their gonads, not their brains.
This argument does not hold water. Why did Linus create the inferior Linux of 1991 at all? There were many superior UNIXes at that time. Go back in time and substitute "BitKeeper" with "Minix" to see the hypocracy of his statement.
The most productive thing people could do might be to just do a BK->CVS gateway, if you really feel like it. Or just go on and ignore the fact that some people are using BK - you don't actually have to ever even know.
Linus
The BK->CVS gateway is now explicitly prohibited by the BK license. The only way around it would be a non-realtime solution whereby one individual makes available BK->patch files and another individual makes a patch->CVS gateway. This solution is a non-solution - it's slow and awkward and is not protected from a future licensing whim change of Larry McVoy.
Linus does not realize that this is more than a productivity issue. Aspiring free software authors are greatly influenced by his decisions. He is sending the wrong message.
People change over time and their ideology also changes. Perhaps Alan Cox or someone else might be a better maintainer for the official Linux tree?
I just built something much larger: the Parrot (perl6) VM: 266 MHz Linux box without distcc: 6 minutes, 45 seconds. 266 MHz Linux box + distcc + 2.0 GHz Windows box (with linux cross compiler): 1 minute, 52 seconds. Who says Windows boxes are good for nothing?;-)
It took me several hours to correctly build a gcc-3.2 Windows (cygwin) hosted Linux targetted compiler (see instructions in parent) and to build distcc on cygwin - but the thing actually works. I can launch a `make' on linux and distcc actually performs the compiles via cross compiler on Windows.
The Windows box is several times faster than the Linux box in the test. I have distccd (the distcc daemon) running on the Windows box. The linux cross compiler on the Windows box is named 'i686-pc-linux-gnu-g++' so it is not confused with my native Windows Cygwin compiler.
Timing for a completely local build on Linux:
(linux) $ time make CCC=g++ g++ -c FileA.cpp g++ -c FileB.cpp g++ -o Program FileA.o FileB.o 7.40user 0.25system 0:07.66elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (3097major+7464minor)pagefaults 0swaps
And now a timing with distcc farming compiles to the remote Windows box:
I know my test file sizes are a joke, but it shows a distcc distributed build time of 3.44 seconds versus a regular (non-distributed) build time of 7.66 seconds. Twice as fast as a local build.
Run a gcc cross compiler on the remote machine that will make Linux object files. distcc is operating system agnostic. For distcc's purposes you don't even need the target operating system's header files or runtime libraries since the files are already pre-processed on the host machine, and only compilation of.o files takes place remotely. Here, for example, is how to build a Linux cross compiler hosted on Cygwin.
Why so negative? They are aware of the gdb issue and are working to fix it. This does not make distcc 'worthless' by any stretch. Even if you do have a crash gdb will still give you the stack trace of a distcc-compiled -g program complete with function names and line numbers - you just don't get the source code without setting a directory directive within a gdb session. Big deal. It's perfectly usuable. Sometimes I'll launch production builds mid-day to correct - wait for it - mid-day production problems. This has to be done as quickly as possible, and distcc is very useful. The gdb thing is by no means a showstopper.
distcc & ccache Has anybody yet thought of integrating distcc & ccache?
Yes, of course. They work pretty well as separate programs that call each other: you can just write CC='ccache distcc gcc'. (libtool sometimes has trouble with that, but that's a problem that we will fix shortly and it is a separate question.)
This is very nearly as efficient as making them both part of a single program. The preprocessor will only run once and the preprocessed source will be passed from ccache straight to distcc. Having them separate allows them to be tested, debugged and released separately.
Unless there's a really strong argument to do otherwise, having two smaller programs is better practice, or at least more to my taste, than making one monolithic one.
If you have a large cluster of distcc compile computers it is often better to remove the host machine (localhost) from the environment variable DISTCC_HOSTS so distcc does not actually compile files locally, but instead only does preprocessing, remote machine file delegation and final linking. You might also consider reducing the "make -j" number to reduce network traffic if your network is slow.
First of all, Java builds are around 100X faster than C or C++ builds, so you probably do not need this technology. I have never seen a Java build take more than 5 minutes from scratch (with thousands of source files); whereas a C++ project built from scratch such as Mozilla might take hours. Java compile jobs are much harder to farm out to remote machines because the java compiler must see either all the related source files and/or class files related to the compilation of each java file.
This is due to the fact that Java source is a combination of interface and implementation. C and C++ divide these two aspects: interfaces go in the header files, and the implementation in the.c or.cpp files. So basically you'd have to share the entire java project source tree via Samba or NFS to each remote node which defeats the purpose of this exercise.
To speed a Java build - try Jikes. It's around 5 times faster than Javac in my experience.
Distcc has a problem with gdb. It appears when a file is pre-processed on the host machine gcc does not record the directory to the pre-processed output file. When the pre-processed file is farmed out to a remote gcc build machine the remote gcc compiler (not knowing any better) compiles the file and records the remote machine's directory to the object file. Now when a user tries to debug the program gdb cannot find the source directories. Unfortunately, this "debugging" bug has to be fixed within GCC itself. This thread describes how GCC might be patched to allow gdb to work correctly with distcc, but at this time no action was taken. This is not a huge problem - distcc is still great for production builds.
Whine, whine, whine. The game server was not relevant to creating a contest entry. A clever programmer would have written his/her own server to test against (as many entrants did). In fact, writing a server would have been desirable if for no other reason than to have a graphical shell to observe the robot participants in action and to enhance your robot's algorithms. The contest was designed to test your ingenuity as much as your programming ability. No problem is perfectly designed. You are supposed to deal with it.
You're a moron spreading FUD. C++ is as popular as ever. How do you explain the great success of KDE? Gee, what language do you think that is written in? It's good ol' C++ code written in the last few years. And it's only getting better with each new release. Add to the list: Microsoft Office and Sun's OpenOffice. Face the fact that there does not exist a general systems language that can rival C++ for low memory footprint and speed (other than C). Java has its place - but not in the desktop or operating system arena.
I agree that a large feature-filled standard library (J2SE not J2EE) was key to Java's success. I would also add that late (runtime) method binding and standard binary class file formats also helped Java tremendously. Extensive run time type identification (reflection) was also key as this filled a hole left by the lack of generics and Java's lack of first-class function pointers. I for one wish Bjarne would add all of these features to C++. It's all doable of course, but it goes against his vision of imposing details on C++ compiler implementors and breaking C compatability. And one last point - C++'s iostream library has got to go - what a useless, slow, needlessly complicated and unextendable piece of shit that is! Ironically, C++'s own IO library is the worst example of design that a new C++ programmer could face. At least C++ projects such as Boost are starting to catch up with Java's standard library functionality, so there is hope.
critical mass most important element
on
Open Source Studies
·
· Score: 3, Insightful
If your open source project does not have a critical mass of developers it will fail. Critical mass can only be acheived if the program being developed is largely finished or already useful in some way. Everyone likes to back a winner. The exception to this rule is when you have a project started by someone with past successes such as Miguel starting the Mono project after the successful GNOME project. But then you could argue that C# was already a mature specification for Mono to exploit, so it was already a "winner" in a sense. The Parrot project, by comparison has the disadvantage of not having pristine design specification and documentation (courtesy of Microsoft) to mimic. Often, the majority of work in a pre-critical mass project has already been done by a single individual. This is conveniant because they usually become the defacto project leader. It is just as useful to prevent poor contributions into the project as it is to add quality code to the project. This is due to the fact that no one likes code audits. And the final mark of a good open source project - the leader cannot be a prick. There's too much bullshit to put up with in day to day life, why would you want to get harassed without being payed?
Congratulations, you've been duped by RSA
on
RC5-64 Success
·
· Score: 1
into doing very expensive PR for them. This is exactly this sort of result they had hoped for - even their low-grade keys need a world-wide network of computers and months to crack their marketing deptartment will report. The $10K prize is a joke compared to the cost/time of the compute power involved. Surely we can put our spare cycles to better use to society than this?
I can't seem to find any info on whether Linux core files still produce one core file per thread or just one core file per process (as does Solaris).
Has `gdb' been enhanced to handle multithreaded programs (or multithreaded core file) on Linux?
If I have a thousand threads - I sure don't want 1000 core files in the event of a crash. Is there a way around this?
Currently in Linux every thread is assigned a distinct process ID, and as such, a process has as many entries in `top' and `ps' as it has threads. This makes it difficult to monitor processes externally, or even see the other processes' information. Has this issue been addressed? (I realize this is a user-space program issue, not a kernel issue).
The parent post is moronic and uninformed, as are the moderators who modded it up. Designing fonts is not as difficult as he makes it out to be, and it certainly can be learned - as can anything in life. There are hundreds (if not thousands) of good artists out there that are more than capable of learning how to design a font who are also familiar with programming. There are also a few open source font designing utilities. t1utils is a good Type 1 designing tool. It is a commandline font compiler/decompiler that uses an ascii file to define the postscript font outlines of each character directly.
References, please. AFAIK, if I want to resell a GPL'ed piece of software for $ 100.000,00 I am free to do so.
Please see section 3b of the GPL, and then re-read sections 1 and 2. I guess the phrase "for a charge no more than your cost of physically performing source distribution" is up to interpretation. There are obviously many Linux distributions (for example) that include GPL code that sell for considerably more than the cost of physically performing source distribution. Perhaps they are charging for proprietary packages on the same medium as the GPL code? I've never really understood that. AFAIK this has never been challenged in court either, so you may be right.
6) finally, company license is like the GPL but with a different name.
It is not like the GPL by a long shot. Under the GPL no other party may sell your contribution (beyond, say, a reasonable price for the media it is distributed on). If I interpret Sun's new agreement correctly, under the JCA any contribution to OpenOffice.org is still owned (actually now jointly owned) by Sun. Basically this agreement suggests that only Sun - not a contributor or any other company - can profit from OpenOffice with the work of all third party contributors since Sun alone either owns or jointly owns all the OpenOffice code AND every contributors' contribution. If the contributor is fine with Sun (and only Sun) making money off the contributor's work, then there is no problem. Yes, the end result may be that people may be able to use OpenOffice for no cost, but the GPL it clearly ain't.
Contrast that press release with this recent statement by Bill Joy:
Joy said the SCSL, which he helped develop to cover Java and several other Sun software technologies, "fixed the flaws in the open-source licensing" by providing a better foundation for profiting off the software. The SCSL permits others to see and modify source code, but gives Sun the authority to accept or reject those changes. Sun also has the authority to charge royalties to companies shipping products using the software.
Every JVM opcode has a.Net CLR equivalent opcode. However, not every CLR construct has an efficient JVM equivalent: unsigned types, auto (un)boxing, versioned assemblies, delegates, stack-based structs, and unmanaged code just to name a few. Any code written in Java can trivially be ported to C# (see Ant/Nant, JUnit/NUnit) but porting from C# to Java is more difficult if programmers take advantage of these extra CLR features - and most do because they reduce coding time and complexity. Microsoft certainly knows how to play the game.
Slashdot Mirror
You have completely missed the point.
You have just quoted the completely arbitrary rules of Larry McVoy which are subject to change at his whim.
When/if CVS makes some strategic feature addition Larry will once again quote you yet another arbitrary set of rules for you to follow.
http://marc.theaimsgroup.com/?l=linux-kernel&m=101 552903701385&w=2
And I personally refuse to use inferior tools because of ideology. In fact, I will go as far as saying that making excuses for bad tools due to ideology is _stupid_, and people who do that think with their gonads, not their brains.
This argument does not hold water. Why did Linus create the inferior Linux of 1991 at all? There were many superior UNIXes at that time.
Go back in time and substitute "BitKeeper" with "Minix" to see the hypocracy of his statement.
The most productive thing people could do might be to just do a BK->CVS
gateway, if you really feel like it. Or just go on and ignore the fact
that some people are using BK - you don't actually have to ever even
know.
Linus
The BK->CVS gateway is now explicitly prohibited by the BK license. The only way around it would be a non-realtime solution whereby one individual makes available BK->patch files and another individual makes a patch->CVS gateway. This solution is a non-solution - it's slow and awkward and is not protected from a future licensing whim change of Larry McVoy.
Linus does not realize that this is more than a productivity issue. Aspiring free software authors are greatly influenced by his decisions. He is sending the wrong message.
People change over time and their ideology also changes. Perhaps Alan Cox or someone else might be a better maintainer for the official Linux tree?
I just built something much larger: the Parrot (perl6) VM: ;-)
266 MHz Linux box without distcc: 6 minutes, 45 seconds.
266 MHz Linux box + distcc + 2.0 GHz Windows box (with linux cross compiler): 1 minute, 52 seconds.
Who says Windows boxes are good for nothing?
It took me several hours to correctly build a gcc-3.2 Windows (cygwin) hosted Linux targetted compiler (see instructions in parent) and to build distcc on cygwin - but the thing actually works. I can launch a `make' on linux and distcc actually performs the compiles via cross compiler on Windows.
The Windows box is several times faster than the Linux box in the test. I have distccd (the distcc daemon) running on the Windows box. The linux cross compiler on the Windows box is named 'i686-pc-linux-gnu-g++' so it is not confused with my native Windows Cygwin compiler.
Timing for a completely local build on Linux:
(linux) $ time make CCC=g++
g++ -c FileA.cpp
g++ -c FileB.cpp
g++ -o Program FileA.o FileB.o
7.40user 0.25system 0:07.66elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (3097major+7464minor)pagefaults 0swaps
And now a timing with distcc farming compiles to the remote Windows box:
(linux) $ export DISTCC_HOSTS='windowsbox'
(linux) $ time make -j2 CCC='distcc i686-pc-linux-gnu-g++'
distcc i686-pc-linux-gnu-g++ -c FileA.cpp
distcc i686-pc-linux-gnu-g++ -c FileB.cpp
distcc i686-pc-linux-gnu-g++ -o Program FileA.o FileB.o
1.09user 0.39system 0:03.44elapsed 43%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (2059major+1207minor)pagefaults 0swaps
I know my test file sizes are a joke, but it shows a distcc distributed build time of 3.44 seconds versus a regular (non-distributed) build time of 7.66 seconds.
Twice as fast as a local build.
So put those idle Windows to work!
Run a gcc cross compiler on the remote machine that will make Linux object files. distcc is operating system agnostic. For distcc's purposes you don't even need the target operating system's header files or runtime libraries since the files are already pre-processed on the host machine, and only compilation of .o files takes place remotely.
Here, for example, is how to build a Linux cross compiler hosted on Cygwin.
Why so negative? They are aware of the gdb issue and are working to fix it. This does not make distcc 'worthless' by any stretch.
Even if you do have a crash gdb will still give you the stack trace of a distcc-compiled -g program complete with function names and line numbers - you just don't get the source code without setting a directory directive within a gdb session. Big deal. It's perfectly usuable.
Sometimes I'll launch production builds mid-day to correct - wait for it - mid-day production problems. This has to be done as quickly as possible, and distcc is very useful.
The gdb thing is by no means a showstopper.
using distcc and ccache
from the above link:
distcc & ccache
Has anybody yet thought of integrating distcc & ccache?
Yes, of course. They work pretty well as separate programs that call each other: you can just write CC='ccache distcc gcc'. (libtool sometimes has trouble with that, but that's a problem that we will fix shortly and it is a separate question.)
This is very nearly as efficient as making them both part of a single program. The preprocessor will only run once and the preprocessed source will be passed from ccache straight to distcc. Having them separate allows them to be tested, debugged and released separately.
Unless there's a really strong argument to do otherwise, having two smaller programs is better practice, or at least more to my taste, than making one monolithic one.
If you have a large cluster of distcc compile computers it is often better to remove the host machine (localhost) from the environment variable DISTCC_HOSTS so distcc does not actually compile files locally, but instead only does preprocessing, remote machine file delegation and final linking. You might also consider reducing the "make -j" number to reduce network traffic if your network is slow.
First of all, Java builds are around 100X faster than C or C++ builds, so you probably do not need this technology. I have never seen a Java build take more than 5 minutes from scratch (with thousands of source files); whereas a C++ project built from scratch such as Mozilla might take hours. Java compile jobs are much harder to farm out to remote machines because the java compiler must see either all the related source files and/or class files related to the compilation of each java file. This is due to the fact that Java source is a combination of interface and implementation. C and C++ divide these two aspects: interfaces go in the header files, and the implementation in the .c or .cpp files. So basically you'd have to share the entire java project source tree via Samba or NFS to each remote node which defeats the purpose of this exercise.
To speed a Java build - try Jikes. It's around 5 times faster than Javac in my experience.
Distcc has a problem with gdb.
It appears when a file is pre-processed on the host machine gcc does not record the directory to the pre-processed output file. When the pre-processed file is farmed out to a remote gcc build machine the remote gcc compiler (not knowing any better) compiles the file and records the remote machine's directory to the object file. Now when a user tries to debug the program gdb cannot find the source directories.
Unfortunately, this "debugging" bug has to be fixed within GCC itself. This thread describes how GCC might be patched to allow gdb to work correctly with distcc, but at this time no action was taken.
This is not a huge problem - distcc is still great for production builds.
Whine, whine, whine.
The game server was not relevant to creating a contest entry. A clever programmer would have written his/her own server to test against (as many entrants did). In fact, writing a server would have been desirable if for no other reason than to have a graphical shell to observe the robot participants in action and to enhance your robot's algorithms.
The contest was designed to test your ingenuity as much as your programming ability. No problem is perfectly designed. You are supposed to deal with it.
You're a moron spreading FUD. C++ is as popular as ever.
How do you explain the great success of KDE?
Gee, what language do you think that is written in?
It's good ol' C++ code written in the last few years. And it's only getting better with each new release.
Add to the list: Microsoft Office and Sun's OpenOffice.
Face the fact that there does not exist a general systems language that can rival C++ for low memory footprint and speed (other than C).
Java has its place - but not in the desktop or operating system arena.
I agree that a large feature-filled standard library (J2SE not J2EE) was key to Java's success. I would also add that late (runtime) method binding and standard binary class file formats also helped Java tremendously. Extensive run time type identification (reflection) was also key as this filled a hole left by the lack of generics and Java's lack of first-class function pointers.
I for one wish Bjarne would add all of these features to C++. It's all doable of course, but it goes against his vision of imposing details on C++ compiler implementors and breaking C compatability.
And one last point - C++'s iostream library has got to go - what a useless, slow, needlessly complicated and unextendable piece of shit that is!
Ironically, C++'s own IO library is the worst example of design that a new C++ programmer could face.
At least C++ projects such as Boost are starting to catch up with Java's standard library functionality, so there is hope.
If your open source project does not have a critical mass of developers it will fail. Critical mass can only be acheived if the program being developed is largely finished or already useful in some way. Everyone likes to back a winner. The exception to this rule is when you have a project started by someone with past successes such as Miguel starting the Mono project after the successful GNOME project. But then you could argue that C# was already a mature specification for Mono to exploit, so it was already a "winner" in a sense. The Parrot project, by comparison has the disadvantage of not having pristine design specification and documentation (courtesy of Microsoft) to mimic.
Often, the majority of work in a pre-critical mass project has already been done by a single individual. This is conveniant because they usually become the defacto project leader. It is just as useful to prevent poor contributions into the project as it is to add quality code to the project. This is due to the fact that no one likes code audits.
And the final mark of a good open source project - the leader cannot be a prick. There's too much bullshit to put up with in day to day life, why would you want to get harassed without being payed?
into doing very expensive PR for them.
This is exactly this sort of result they had hoped for - even their low-grade keys need a world-wide network of computers and months to crack their marketing deptartment will report.
The $10K prize is a joke compared to the cost/time of the compute power involved.
Surely we can put our spare cycles to better use to society than this?
Sun's N1 sounds exactly like OpenMosix which you can already get for free - today - not in a few years.
I can't seem to find any info on whether Linux core files still produce one core file per thread or just one core file per process (as does Solaris). Has `gdb' been enhanced to handle multithreaded programs (or multithreaded core file) on Linux? If I have a thousand threads - I sure don't want 1000 core files in the event of a crash. Is there a way around this?
Currently in Linux every thread is assigned a distinct process ID, and as such, a process has as many entries in `top' and `ps' as it has threads. This makes it difficult to monitor processes externally, or even see the other processes' information. Has this issue been addressed? (I realize this is a user-space program issue, not a kernel issue).
The parent post is moronic and uninformed, as are the moderators who modded it up.
Designing fonts is not as difficult as he makes it out to be, and it certainly can be learned - as can anything in life.
There are hundreds (if not thousands) of good artists out there that are more than capable of learning how to design a font who are also familiar with programming.
There are also a few open source font designing utilities.
t1utils is a good Type 1 designing tool.
It is a commandline font compiler/decompiler that uses an ascii file to define the postscript font outlines of each character directly.
References, please. AFAIK, if I want to resell a GPL'ed piece of software for $ 100.000,00 I am free to do so.
Please see section 3b of the GPL, and then re-read sections 1 and 2. I guess the phrase "for a charge no more than your cost of physically performing source distribution" is up to interpretation. There are obviously many Linux distributions (for example) that include GPL code that sell for considerably more than the cost of physically performing source distribution. Perhaps they are charging for proprietary packages on the same medium as the GPL code? I've never really understood that. AFAIK this has never been challenged in court either, so you may be right.
6) finally, company license is like the GPL but with a different name.
It is not like the GPL by a long shot.
Under the GPL no other party may sell your contribution (beyond, say, a reasonable price for the media it is distributed on).
If I interpret Sun's new agreement correctly, under the JCA any contribution to OpenOffice.org is still owned (actually now jointly owned) by Sun.
Basically this agreement suggests that only Sun - not a contributor or any other company - can profit from OpenOffice with the work of all third party contributors since Sun alone either owns or jointly owns all the OpenOffice code AND every contributors' contribution.
If the contributor is fine with Sun (and only Sun) making money off the contributor's work, then there is no problem.
Yes, the end result may be that people may be able to use OpenOffice for no cost, but the GPL it clearly ain't.
Contrast that press release with this recent statement by Bill Joy:
Joy said the SCSL, which he helped develop to cover Java and several
other Sun software technologies, "fixed the flaws in the open-source
licensing" by providing a better foundation for profiting off the
software. The SCSL permits others to see and modify source code,
but gives Sun the authority to accept or reject those changes. Sun
also has the authority to charge royalties to companies shipping
products using the software.
A ClearCase-like system for Linux: Katie
Every JVM opcode has a .Net CLR equivalent opcode. However, not every CLR construct has an efficient JVM equivalent: unsigned types, auto (un)boxing, versioned assemblies, delegates, stack-based structs, and unmanaged code just to name a few. Any code written in Java can trivially be ported to C# (see Ant/Nant, JUnit/NUnit) but porting from C# to Java is more difficult if programmers take advantage of these extra CLR features - and most do because they reduce coding time and complexity. Microsoft certainly knows how to play the game.