As pointed out by others, your problem is clearly that your developers are not doing a 'cvs update' before they 'cvs ci'. The tutorials and HOWTO's recommend this consistantly. Otherwise, you end up patching *out* what another developer patched *in*.
Have your developers read the CVS Book: http://cvsbook.red-bean.com/. If it helps, consider buying a copy or several. Helps the authors, and makes good reference for your developers library.
They recommend upgrading some 22 packages on a Redhat 7.2 system.
Most of those packages are related to gcc3 and vnc, which you probably don't have installed. Leave off those two, and you have about 6 or 7 updates left, including the zlib package.
This includes several packages for the kernel...
Actually, kernel 2.4 is absent from the list of updates.
I think the automakers are the only ones who ever successfully pulled off this paradigm well; cars are extremely complex
The problem with the comparison between cars and computers, in this case, is that cars are a complex mechanism for a simple purpose. They go forward and backward, turn left and right. The complexity of using that machine is learning to use the wheel, the accelerator, the brake, the shifter, keeping it fueled and taking it for regular maintenance. If you don't understand the machine, it can be severely damaged.
A computer, in comparison is infinitely more flexible than a car. As the number of tasks increases on a computer, the complexity does too, to a certain point. Computers could easily be made as simple as a car (or a typewriter) if their functionality were as limited.
Um... At that time, neither Red Hat nor Debian was shipping KDE due to licensing conflicts. KDE was under GPL. It depended on QT, which was not licensed in a compatible manner, which isn't allowed by the GPL.
Note that this situation was not resolved by Red Hat bending to their users requests, but by Trolltech's licensing QT under the GPL.
Netscape may have been closed-source and commercial, but its license allowed Red Hat to distribute it, and no GPL'd applications linked against its closed-source libraries.
"Red Hat" doesn't hate KDE. Bero is a big KDE advocate, and maintains daily builds here:
http://www.linux-easy.com/daily/
Red Hat probably doesn't provide packages through other channels because they aren't going to support them. The KDE people are free to use the packages that Bero's put up, and they have in the past.
In responce to the many questions of 'why?', I'd submit some of the following:
I've used Fink. I've built all of the packages in the stable tree. I've read many of the patches. Not to belittle the excellent work that the Fink developers do, it feels hackish at times. Darwin's BSD layer isn't a very good UNIX, and causes many applications to not compile, or compile with bad hackish workarounds. Darwin imposes a lot of limitations that Linux doesn't have, and is buggy or not POSIX compliant in other respects. From a UNIX developers position, Linux is far and away a better UNIX platform.
Running Linux results in a much smoother UI, anyway. The Mac OS X interface lacks proper keyboard window switching, so users have to resort to the mouse more often. Introduce XFree86 into that picture, and you suddenly have separate keys for window switching in each environtment. Cmd+Tab will switch *applications*, including X, but you need a separate key combo for window switching inside X. I used Opt+Tab. So, if I wanted to switch from the Gimp to gnome-terminal, I can Opt+Tab. If I want to switch to Mozilla running in OS X, I Cmd+Tab to it.... Hackish.
The performance of XFree86 on OS X is also really pretty awful. The SysV shared memory implimentation on Darwin is too limited for the MIT-SHM extention to be used, and graphics under Quartz are largely unaccelerated. Things draw *slow*. If you're interested in X apps, Linux will perform much better.
Interested in KDE? Not available from Fink. Apparently KDE does some things assuming that work with ELF binary objects that don't work on Darwin (probalby in Kparts, but I don't know). KDE users are going to want to run Linux.
Personally, I'm not all that interested in OS X. I don't like it much. However, I *do* really like PowerPC hardware. Resume from suspend is much betther than on x86, which is great for laptops. Power use is better, and heat output is lower. Hardware is easier to configure.
First, I have to say that I agree with the comments already posted suggesting that you just compress the audio and make it available for download. It's much more efficient. Especially when semester end comes and students want to review data from several lectures, not swapping disks frequently will be more convenient.
I'd mod them up if I didn't have to say that RAM disks are a bad idea. If you simply add the RAM to the system, then the OS can cache the data in the most efficient manner possible. As long as you have the RAM to cache the image, the OS shouldn't be reading it from the drive constantly. Using a RAM disk is actually harmful to system performance, because the OS may not be able to cache disk sectors that are frequently needed. Statically allocating the RAM only works if you have more information about disk use than your OS, which you almost certainly do not.
Nobody seems to have noticed that if anything has been turned upside down, it's the Net
Well, I think it's clear what happened. Corporate America went up to the Net, slapped it in the face, and said "That's enough of your shit! You fucking bitch!"
What you attribute to the intelligence of the installer is actually an effect of the total and complete brain damage of the OS. What you see is not an effect of the installer optimizing for the processor; it is the effect of the hardware installation wizard being a fucknut.
The more you change your hardware, in any Windows OS that I've used, the slower the system runs. Over time, just swapping PCI cards around can leave your system performance in the realm of "miserable".
It's one of the reasons that almost all of the gamers that I know are so familiar with the words "reformat and reinstall".
While most people are expressing their concerns over the future of their desktop, I get the feeling that the buyout could be much worse for Linux than the possible loss of a good desktop.
Red Hat is (in North America) a huge presence in the market for large scale server deployments, Linux support, development, and embedded tools. They own a lot of unique and valuable IP, like CCVS and Cygnus. They fund the development of GNU libc, GCC, and a lot of kernel development.
Red Hat has done a f*cking excellent job of supporting the Linux community, and furthering the development of Linux. I hope that nothing changes their direction.
Conspicuously missing from the list of updates is glibc. Since Red Hat released a security update for the revision used in Potato, I'm assuming that Potato is also vulnerable to the heap corruption bug in glibc's glob() function. The fix is simple, so where's the update? AFAIK, the only major distributions that haven't addressed this problem are Debian and Slackware.
For higher-end applications, expect the cost of Fibre Channel connections to come down, which will essentially put an end to SCSI.
You should be aware that fibre channel isn't the death of SCSI, it's a new life for SCSI.
Fibre channel is a physical transport. SCSI is a data transport/command set on top of a physical transport (which is also called SCSI). Fibre channel is just going to provide a newer, faster physical transport for the next generation of SCSI devices. Furthermore, SCSI is expensive because it requires complex controllers on the host and on devices. Fibre channel won't change that. As the cost of fibre channel comes down, it'll approach the current cost of SCSI, but won't make them any less expensive.
Darn tootin'. In the meantime, use LVM with stripes.:)
Cheap SMP. I'll take my dual 550 over a single 1 GHz any day of the week. How about 8x500 MHz on the desktop, instead of 1x4GHz which is still crippled by 1 CPU hogging app?
If your one app is hogging the CPU, then your OS isn't doing its job. I love SMP. Most of my boxen have been SMP systems for several years. However, until *all* of your apps are heavily threaded, they're limited to a fraction of your availalbe processing power. When they are, they'll be able to hog all of your CPU's, instead of just one.
A decent NFS client for Win32
Uh... no. Most NFS implimentations suck. A decent client needs a decent server, and there aren't a lot of those available. How about something smarter, like CODA?
The problem is that users don't really know what they want, they only know what they're told they should want. The parent post may be a troll, and it may not, but it's full of frequently posted bullshit that people need to stop believing.
don't try and convince me that an almost 20 year-old architecture is going to bode well these days
OK, why are you even considering Linux then? It's a 10 year old OS replicating a 30 year old architecture. It can't *possibly* be any good, right?
Modular, extensible software isn't new. X11 was designed that way years ago. The only problem has been the proliferation of slow, monolithic implimentations. XFree86's implimentation is much much better than many in the past. X11 itself is a fine drawing layer, even if libx11 is a bitch to interface with.
There is no compelling reason for people to use Linux on the desktop
Maybe not. I don't know. My mom's been using it for 3 or 4 years, since before Windows had ICS. That was the killer feature. Even after that, Windows didn't have a good personal firewall. Even still, it's vulnerable to about a million virii that will never affect her computer. Everyone has something that they desire from their computer...
Xfree86 my ass, move off that clunker and have a nice thin layer at the bottom
There's that frequently quoth bullshit. X11 IS THIN. Thin == little memory: X11 works on Compaq iPAQ's in something like 2MB of RAM, and provides better services than the Linux frame buffer. Thin == low level, which is what most *real* X11 programmers bitch about. X11 is so thin that it provides a mechanism without any policy! That's its design goal. It's just the mechanism, so policy can be decided by anyone who needs a graphical environment without rewriting their drawing layer from scratch. As GUI's evolve, and their internal designs change, X11 will always be there for them to be built upon, without rewriting the low level hardware interface bits.
Why does everyone bitch about X11, but no one ever thinks that Linux should be replaced with something that isn't 100MB of source, and 20 MB of binary? What? No one thinks that an OS would be much faster if it were "thin"?
Remember, THIN == few features. X11 provides all of the features that you need to draw in an extensible architecture, without anything that belongs somewhere else.
Linux needs a completely IE compatible browser.
Compatible in what way? If browsers on Linux aren't compatible with IE, then the fault lies not in the Linux browser developers; it's with MS. There *IS* a standard for this crap, you know? It's all written out, and anyone should be able to understand it. Mozilla and Opera are far better at being standards compliant than IE, so why don't you bitch at MS. Why should we have to degrade from written standards to implimentation standards that are likely to change as IE does?
Fonts suck
*GOOD* fonts are really hard to create, and therefore very expensive. Perhaps you would like to develop some? Or maybe fund their development? Not that you're wrong here... The fonts we've got would be a lot better if they were scalable and hinted, but that's where we loose out.
The truth is that UNIX users are users, too. Just like the Windows users we all flame and bitch about, UNIX users are still using their old tools because they resist change. Once they've learned a set of tools and procedures, they don't want to learn the new generation every year when the old way still works. No one does. All the same, new tools DO come out from time to time, and the time saved by learning them is frequently made up by the time you save using them.
Perl is not only required by the build system, but by several drivers:
$ cd/usr/src/linux-2.4
$ find . -name '*.pl' -print
./drivers/net/starfire_firmware.pl
./drivers/scsi/script_asm.pl
./drivers/usb/serial/ezusb_convert.pl
./scripts/checkincludes.pl
./scripts/checkconfig.pl
./scripts/checkhelp.pl
In./Makefile, three rules requiring perl:
checkconfig:
find * -name '*.[hcS]' -type f -print | sort | xargs $(PERL) -w scripts/checkconfig.pl
In./drivers/scsi/Makefile, four rules require perl scripts.
It is downright stupid to make a package as large as python an essential system component. If anything we should reduce the number of base dependencies.
Uh... you've never heard of cross compiling, have you? Getting linux to scale down, and work on minute devces is certainly a goal that a lot of people are working on. However, using Python to build the kernel isn't going to present a greater barrier to overcome. Any system for which Python is too much of a barrier, a compiler is going to be *way* over the top. Compare the relative size of gcc, supporting libs, headers, devel packages to the size of Python. On my system, gcc *alone* is larger than Python.
Cross compiling is how those systems has always been done, and always will be done.
I think you (and the AC you quote) do injustice to ESR AND to Linus. ESR's been developing software for a sight longer than you, I'd wager, and Linus is not swayed by "fame". He makes decisions based on technical merits. If CML2 makes it into the kernel proper, then Linus has decided that it's the best thing for Linux. Who are you to disagree?
The CML project got started when kernel developers started complaining about how hard it was to maintain the current configuration tool.
The current configuration tool *is* CML. The tool that ESR has produced is CML2. CML does its work with a mix of shell, perl, other tools. It's nasty. CML2 is pure Python.
That obviously hasn't happened yet, but mostly only because Eric decided to implement CML in Python
No, it hasn't happened yet because it's not material for a *stable* kernel series. It'll go into the development kernel, and all of the stuff that needs to be updated to make it work will get updated in the devel tree.
because it wasn't GPL compatibly licensed
Python has had a few releases that the FSF thought were not compliant, but Guido and co. thought that they were. Python has always tried to be GPL compatible. 1.5.2 and lesser are compatible, and so are all of the current newer branches of Python.
Anyway, the idea was not so much to improve on xconfig, but to give you the ability to continue configuring your kernel once xconfig was no longer being maintained.
The idea was to create a uniform set of configuration tools that got dependancy checking right and were easy to maintain. CML was none of those things.
If you have to give the source code away for free to others, how can you make money from it in a practical sense?
By selling the software, the same as proprietary vendors do. Duh! Nothing in the GPL states that you can't sell the software that you create. It only requires that you provide the source code to your customers (on request).
If your customers want to peruse the source to your product (which they've paid for) to confirm or fix bugs that they encounter, what justification have you for disallowing this?
It's irresponsible to sell software that's "black box" as it's irresponsible to *use* software that's "black box".
Slashdot Mirror
As pointed out by others, your problem is clearly that your developers are not doing a 'cvs update' before they 'cvs ci'. The tutorials and HOWTO's recommend this consistantly. Otherwise, you end up patching *out* what another developer patched *in*.
Have your developers read the CVS Book: http://cvsbook.red-bean.com/. If it helps, consider buying a copy or several. Helps the authors, and makes good reference for your developers library.
Really? I thought he was just singing along to the music in his head...
They recommend upgrading some 22 packages on a Redhat 7.2 system.
Most of those packages are related to gcc3 and vnc, which you probably don't have installed. Leave off those two, and you have about 6 or 7 updates left, including the zlib package.
This includes several packages for the kernel...
Actually, kernel 2.4 is absent from the list of updates.
No, no no... it's "oh ess ten" baruz...
I think the automakers are the only ones who ever successfully pulled off this paradigm well; cars are extremely complex
The problem with the comparison between cars and computers, in this case, is that cars are a complex mechanism for a simple purpose. They go forward and backward, turn left and right. The complexity of using that machine is learning to use the wheel, the accelerator, the brake, the shifter, keeping it fueled and taking it for regular maintenance. If you don't understand the machine, it can be severely damaged.
A computer, in comparison is infinitely more flexible than a car. As the number of tasks increases on a computer, the complexity does too, to a certain point. Computers could easily be made as simple as a car (or a typewriter) if their functionality were as limited.
CTRL+ALT+D? What is this, Microsoft EMACS?
Um... At that time, neither Red Hat nor Debian was shipping KDE due to licensing conflicts. KDE was under GPL. It depended on QT, which was not licensed in a compatible manner, which isn't allowed by the GPL.
Note that this situation was not resolved by Red Hat bending to their users requests, but by Trolltech's licensing QT under the GPL.
Netscape may have been closed-source and commercial, but its license allowed Red Hat to distribute it, and no GPL'd applications linked against its closed-source libraries.
*cough*bullshit*cough*
"Red Hat" doesn't hate KDE. Bero is a big KDE advocate, and maintains daily builds here:
http://www.linux-easy.com/daily/
Red Hat probably doesn't provide packages through other channels because they aren't going to support them. The KDE people are free to use the packages that Bero's put up, and they have in the past.
In responce to the many questions of 'why?', I'd submit some of the following:
I've used Fink. I've built all of the packages in the stable tree. I've read many of the patches. Not to belittle the excellent work that the Fink developers do, it feels hackish at times. Darwin's BSD layer isn't a very good UNIX, and causes many applications to not compile, or compile with bad hackish workarounds. Darwin imposes a lot of limitations that Linux doesn't have, and is buggy or not POSIX compliant in other respects. From a UNIX developers position, Linux is far and away a better UNIX platform.
Running Linux results in a much smoother UI, anyway. The Mac OS X interface lacks proper keyboard window switching, so users have to resort to the mouse more often. Introduce XFree86 into that picture, and you suddenly have separate keys for window switching in each environtment. Cmd+Tab will switch *applications*, including X, but you need a separate key combo for window switching inside X. I used Opt+Tab. So, if I wanted to switch from the Gimp to gnome-terminal, I can Opt+Tab. If I want to switch to Mozilla running in OS X, I Cmd+Tab to it.... Hackish.
The performance of XFree86 on OS X is also really pretty awful. The SysV shared memory implimentation on Darwin is too limited for the MIT-SHM extention to be used, and graphics under Quartz are largely unaccelerated. Things draw *slow*. If you're interested in X apps, Linux will perform much better.
Interested in KDE? Not available from Fink. Apparently KDE does some things assuming that work with ELF binary objects that don't work on Darwin (probalby in Kparts, but I don't know). KDE users are going to want to run Linux.
Personally, I'm not all that interested in OS X. I don't like it much. However, I *do* really like PowerPC hardware. Resume from suspend is much betther than on x86, which is great for laptops. Power use is better, and heat output is lower. Hardware is easier to configure.
First, I have to say that I agree with the comments already posted suggesting that you just compress the audio and make it available for download. It's much more efficient. Especially when semester end comes and students want to review data from several lectures, not swapping disks frequently will be more convenient.
I'd mod them up if I didn't have to say that RAM disks are a bad idea. If you simply add the RAM to the system, then the OS can cache the data in the most efficient manner possible. As long as you have the RAM to cache the image, the OS shouldn't be reading it from the drive constantly. Using a RAM disk is actually harmful to system performance, because the OS may not be able to cache disk sectors that are frequently needed. Statically allocating the RAM only works if you have more information about disk use than your OS, which you almost certainly do not.
Nobody seems to have noticed that if anything has been turned upside down, it's the Net
Well, I think it's clear what happened. Corporate America went up to the Net, slapped it in the face, and said "That's enough of your shit! You fucking bitch!"
Dude, you have been so misled.
What you attribute to the intelligence of the installer is actually an effect of the total and complete brain damage of the OS. What you see is not an effect of the installer optimizing for the processor; it is the effect of the hardware installation wizard being a fucknut.
The more you change your hardware, in any Windows OS that I've used, the slower the system runs. Over time, just swapping PCI cards around can leave your system performance in the realm of "miserable".
It's one of the reasons that almost all of the gamers that I know are so familiar with the words "reformat and reinstall".
While most people are expressing their concerns over the future of their desktop, I get the feeling that the buyout could be much worse for Linux than the possible loss of a good desktop.
Red Hat is (in North America) a huge presence in the market for large scale server deployments, Linux support, development, and embedded tools. They own a lot of unique and valuable IP, like CCVS and Cygnus. They fund the development of GNU libc, GCC, and a lot of kernel development.
Red Hat has done a f*cking excellent job of supporting the Linux community, and furthering the development of Linux. I hope that nothing changes their direction.
Conspicuously missing from the list of updates is glibc. Since Red Hat released a security update for the revision used in Potato, I'm assuming that Potato is also vulnerable to the heap corruption bug in glibc's glob() function. The fix is simple, so where's the update? AFAIK, the only major distributions that haven't addressed this problem are Debian and Slackware.
BTW, High-end servers tend to use fibre channel as a physical interconnect for SCSI devices, anyway.
For higher-end applications, expect the cost of Fibre Channel connections to come down, which will essentially put an end to SCSI.
You should be aware that fibre channel isn't the death of SCSI, it's a new life for SCSI.
Fibre channel is a physical transport. SCSI is a data transport/command set on top of a physical transport (which is also called SCSI). Fibre channel is just going to provide a newer, faster physical transport for the next generation of SCSI devices. Furthermore, SCSI is expensive because it requires complex controllers on the host and on devices. Fibre channel won't change that. As the cost of fibre channel comes down, it'll approach the current cost of SCSI, but won't make them any less expensive.
Hard disks that are faster, not bigger.
:)
Darn tootin'. In the meantime, use LVM with stripes.
Cheap SMP. I'll take my dual 550 over a single 1 GHz any day of the week. How about 8x500 MHz on the desktop, instead of 1x4GHz which is still crippled by 1 CPU hogging app?
If your one app is hogging the CPU, then your OS isn't doing its job. I love SMP. Most of my boxen have been SMP systems for several years. However, until *all* of your apps are heavily threaded, they're limited to a fraction of your availalbe processing power. When they are, they'll be able to hog all of your CPU's, instead of just one.
A decent NFS client for Win32
Uh... no. Most NFS implimentations suck. A decent client needs a decent server, and there aren't a lot of those available. How about something smarter, like CODA?
This article should have been called:
"We've found a way to fit more advertising in less space and get people to pay attention at the same time."
The problem is that users don't really know what they want, they only know what they're told they should want. The parent post may be a troll, and it may not, but it's full of frequently posted bullshit that people need to stop believing.
don't try and convince me that an almost 20 year-old architecture is going to bode well these days
OK, why are you even considering Linux then? It's a 10 year old OS replicating a 30 year old architecture. It can't *possibly* be any good, right?
Modular, extensible software isn't new. X11 was designed that way years ago. The only problem has been the proliferation of slow, monolithic implimentations. XFree86's implimentation is much much better than many in the past. X11 itself is a fine drawing layer, even if libx11 is a bitch to interface with.
There is no compelling reason for people to use Linux on the desktop
Maybe not. I don't know. My mom's been using it for 3 or 4 years, since before Windows had ICS. That was the killer feature. Even after that, Windows didn't have a good personal firewall. Even still, it's vulnerable to about a million virii that will never affect her computer. Everyone has something that they desire from their computer...
Xfree86 my ass, move off that clunker and have a nice thin layer at the bottom
There's that frequently quoth bullshit. X11 IS THIN. Thin == little memory: X11 works on Compaq iPAQ's in something like 2MB of RAM, and provides better services than the Linux frame buffer. Thin == low level, which is what most *real* X11 programmers bitch about. X11 is so thin that it provides a mechanism without any policy! That's its design goal. It's just the mechanism, so policy can be decided by anyone who needs a graphical environment without rewriting their drawing layer from scratch. As GUI's evolve, and their internal designs change, X11 will always be there for them to be built upon, without rewriting the low level hardware interface bits.
Why does everyone bitch about X11, but no one ever thinks that Linux should be replaced with something that isn't 100MB of source, and 20 MB of binary? What? No one thinks that an OS would be much faster if it were "thin"?
Remember, THIN == few features. X11 provides all of the features that you need to draw in an extensible architecture, without anything that belongs somewhere else.
Linux needs a completely IE compatible browser.
Compatible in what way? If browsers on Linux aren't compatible with IE, then the fault lies not in the Linux browser developers; it's with MS. There *IS* a standard for this crap, you know? It's all written out, and anyone should be able to understand it. Mozilla and Opera are far better at being standards compliant than IE, so why don't you bitch at MS. Why should we have to degrade from written standards to implimentation standards that are likely to change as IE does?
Fonts suck
*GOOD* fonts are really hard to create, and therefore very expensive. Perhaps you would like to develop some? Or maybe fund their development? Not that you're wrong here... The fonts we've got would be a lot better if they were scalable and hinted, but that's where we loose out.
The existance of SP4 (not to mention 5 and 6) don't inspire me with the same confidence you exhibit.
The truth is that UNIX users are users, too. Just like the Windows users we all flame and bitch about, UNIX users are still using their old tools because they resist change. Once they've learned a set of tools and procedures, they don't want to learn the new generation every year when the old way still works. No one does. All the same, new tools DO come out from time to time, and the time saved by learning them is frequently made up by the time you save using them.
It looks like ICQ on the mobile phone is closer than ever!
Great, now I can lose important messages where ever I am!
Thanks, but I'll wait for a Java capable phone that'll run a Jabber IM client.
FACT: CML1 does not require PERL.
/usr/src/linux-2.4
./Makefile, three rules requiring perl:
./drivers/scsi/Makefile, four rules require perl scripts.
Perl is not only required by the build system, but by several drivers:
$ cd
$ find . -name '*.pl' -print
./drivers/net/starfire_firmware.pl
./drivers/scsi/script_asm.pl
./drivers/usb/serial/ezusb_convert.pl
./scripts/checkincludes.pl
./scripts/checkconfig.pl
./scripts/checkhelp.pl
In
checkconfig:
find * -name '*.[hcS]' -type f -print | sort | xargs $(PERL) -w scripts/checkconfig.pl
checkhelp:
find * -name [cC]onfig.in -print | sort | xargs $(PERL) -w scripts/checkhelp.pl
checkincludes:
find * -name '*.[hcS]' -type f -print | sort | xargs $(PERL) -w scripts/checkincludes.pl
In
It is downright stupid to make a package as large as python an essential system component. If anything we should reduce the number of base dependencies.
Uh... you've never heard of cross compiling, have you? Getting linux to scale down, and work on minute devces is certainly a goal that a lot of people are working on. However, using Python to build the kernel isn't going to present a greater barrier to overcome. Any system for which Python is too much of a barrier, a compiler is going to be *way* over the top. Compare the relative size of gcc, supporting libs, headers, devel packages to the size of Python. On my system, gcc *alone* is larger than Python.
Cross compiling is how those systems has always been done, and always will be done.
I think you (and the AC you quote) do injustice to ESR AND to Linus. ESR's been developing software for a sight longer than you, I'd wager, and Linus is not swayed by "fame". He makes decisions based on technical merits. If CML2 makes it into the kernel proper, then Linus has decided that it's the best thing for Linux. Who are you to disagree?
I know, I know.... "Don't moderate, reply."
The CML project got started when kernel developers started complaining about how hard it was to maintain the current configuration tool.
The current configuration tool *is* CML. The tool that ESR has produced is CML2. CML does its work with a mix of shell, perl, other tools. It's nasty. CML2 is pure Python.
That obviously hasn't happened yet, but mostly only because Eric decided to implement CML in Python
No, it hasn't happened yet because it's not material for a *stable* kernel series. It'll go into the development kernel, and all of the stuff that needs to be updated to make it work will get updated in the devel tree.
because it wasn't GPL compatibly licensed
Python has had a few releases that the FSF thought were not compliant, but Guido and co. thought that they were. Python has always tried to be GPL compatible. 1.5.2 and lesser are compatible, and so are all of the current newer branches of Python.
Anyway, the idea was not so much to improve on xconfig, but to give you the ability to continue configuring your kernel once xconfig was no longer being maintained.
The idea was to create a uniform set of configuration tools that got dependancy checking right and were easy to maintain. CML was none of those things.
If you have to give the source code away for free to others, how can you make money from it in a practical sense?
By selling the software, the same as proprietary vendors do. Duh! Nothing in the GPL states that you can't sell the software that you create. It only requires that you provide the source code to your customers (on request).
If your customers want to peruse the source to your product (which they've paid for) to confirm or fix bugs that they encounter, what justification have you for disallowing this?
It's irresponsible to sell software that's "black box" as it's irresponsible to *use* software that's "black box".