Tweet
It is funny to see what are the consequences of certain design decisions after some years ... and economical reality.
RMS chose to build an operating system on top of a mach micro kernel which was supposed to be better or at last neater than a traditional monolithic kernel. Some years passed (decades actually) and Linux does a better job even if it is a big, uh, freakin? bunch of code. Mach is slower by design, but probably not so slow on every architectures (after all, a mach kernel was used for UniCOS on the CRAY-2 supercomputer, if it was a burden, such a design wouldn't have been used on a batch computer). The fact the FSF was unable to port Hurd on top of another microkernel is a proof behind each design there is (are ?) a nasty reality. Those difficulties didn't prevent some free operating systems to be based on top of modern microkernels (haiku-os and minix are probably the most well know cases).
With GCC it is more or less the same story. Choosing a design difficult enough to discourage dishonest industrialists to violate a license and create their own product based around the code of GCC has some drawbacks. And maybe RMS didn't saw how much GCC would evolve back then. And, if it is effectively possible than LLVM/clang will be used in some proprietary compilers, does that mean its development as a free software will stop? I don't think so. The same way it's not because you can put a proprietary nvidia blob in the FreeBSD kernel, or even copy the code and create something proprietary with it (actually lots of companies do it) that the project died or will die anytime soon.
What can make a project die is the lack of interest of the current developers or the sponsors, and the latter is exactly what happen when the project costs more than it pays, for instance if the code base is too hard to work with and a cleaner alternative is available or the project goes totally out of the scope of any market shares. I think it's a bit too early to tell if GCC will lose interest because of it's old codebase, but I am sure a new modular design would be more than welcome (same story with bind 9/10 vs powerDNS).
The opposite is also true, if you look back some years ago, (ok lots of some years ago, in the middle on 80'), when Sun created the NewS display system, superior to X11 (even having a compatibility layer), it didn't have any success beside of early Sgi workstations (they used it to replace their own Mex display system until Sun lose interest in it and both adopted a full X11 environment).
What does that means? It's not always the best technology who win, but how you sell it (look at a certain "operating system' produced by a huge Redmond based company ...).
I personally think GCC and LLVM/clang are both good technologies and it's not even sure if one of them will "lose" to the other, but the oldish design decisions made in GCC since its early days seem to become a burden. Whatever is it true or not, it's something that can't just be ditched with a "We are totally right because they are allowing proprietary plug-ins, so they whole stuff is a plain shit.", because it would be the stupidest thing to do. LLVM/clang learned from what it was considered as GCC's mistakes, maybe it is time for Gcc's guys to take a step back?
RMS chose to build an operating system on top of a mach micro kernel which was supposed to be better or at last neater than a traditional monolithic kernel. Some years passed (decades actually) and Linux does a better job even if it is a big, uh, freakin? bunch of code. Mach is slower by design, but probably not so slow on every architectures (after all, a mach kernel was used for UniCOS on the CRAY-2 supercomputer, if it was a burden, such a design wouldn't have been used on a batch computer). The fact the FSF was unable to port Hurd on top of another microkernel is a proof behind each design there is (are ?) a nasty reality. Those difficulties didn't prevent some free operating systems to be based on top of modern microkernels (haiku-os and minix are probably the most well know cases).
With GCC it is more or less the same story. Choosing a design difficult enough to discourage dishonest industrialists to violate a license and create their own product based around the code of GCC has some drawbacks. And maybe RMS didn't saw how much GCC would evolve back then. And, if it is effectively possible than LLVM/clang will be used in some proprietary compilers, does that mean its development as a free software will stop? I don't think so. The same way it's not because you can put a proprietary nvidia blob in the FreeBSD kernel, or even copy the code and create something proprietary with it (actually lots of companies do it) that the project died or will die anytime soon.
What can make a project die is the lack of interest of the current developers or the sponsors, and the latter is exactly what happen when the project costs more than it pays, for instance if the code base is too hard to work with and a cleaner alternative is available or the project goes totally out of the scope of any market shares. I think it's a bit too early to tell if GCC will lose interest because of it's old codebase, but I am sure a new modular design would be more than welcome (same story with bind 9/10 vs powerDNS).
The opposite is also true, if you look back some years ago, (ok lots of some years ago, in the middle on 80'), when Sun created the NewS display system, superior to X11 (even having a compatibility layer), it didn't have any success beside of early Sgi workstations (they used it to replace their own Mex display system until Sun lose interest in it and both adopted a full X11 environment).
What does that means? It's not always the best technology who win, but how you sell it (look at a certain "operating system' produced by a huge Redmond based company ...).
I personally think GCC and LLVM/clang are both good technologies and it's not even sure if one of them will "lose" to the other, but the oldish design decisions made in GCC since its early days seem to become a burden. Whatever is it true or not, it's something that can't just be ditched with a "We are totally right because they are allowing proprietary plug-ins, so they whole stuff is a plain shit.", because it would be the stupidest thing to do. LLVM/clang learned from what it was considered as GCC's mistakes, maybe it is time for Gcc's guys to take a step back?
Comment