This is not a suggestion I have heard yet (except indirectly in some people's mention of the FreeBSD maintenance system), and I expect it to be an unpopular one, but perhaps those in charge should be thinking not about "How do we decentralize or otherwise modify the process so that we can maintain the current rate of development?", but rather, "Would it be wise to reduce the current rate of development?" Such a reduction would (some may disagree) result in an overall increase in the quality of code getting into the kernel. And arguably, a modicum of new development work would suffice to keep Linux running on new, common hardware; is it really necessary to support every new ethernet or graphics chipset that comes out? This would at least allow for a favorable marketing argument about the "stability" (not necessarily synonymous with "reliability") of Linux. There is perhaps a connection with the "Worse is Better" philosophy which has worked well for Unix in the past. It would also free up developers to work on other aspects of the overall Linux system, such as applications, desktop issues, perhaps ease of installation, and so on. Maybe I'm rambling, or off base, but this seems reasonable to consider.
But how many Linux applications do you see at CompUSA? Maybe a couple: WordPerfect for Linux, CodeWarrior, etc.; but the idea is that if and when major software vendors start shipping.NET apps, there will at least be a fighting chance that an application that was only intended to run on Windows will actually run on the Linux.NET runtime.
Here's an idea: Set up a campus sponsored mp3 sharing network, and flood it with mp3s containing subliminal messages:
"For any integer a not divisible by a prime p, a to the (p minus 1) is congruent to 1 mod p."
Slashdot Mirror
This is not a suggestion I have heard yet (except indirectly in some people's mention of the FreeBSD maintenance system), and I expect it to be an unpopular one, but perhaps those in charge should be thinking not about "How do we decentralize or otherwise modify the process so that we can maintain the current rate of development?", but rather, "Would it be wise to reduce the current rate of development?" Such a reduction would (some may disagree) result in an overall increase in the quality of code getting into the kernel. And arguably, a modicum of new development work would suffice to keep Linux running on new, common hardware; is it really necessary to support every new ethernet or graphics chipset that comes out? This would at least allow for a favorable marketing argument about the "stability" (not necessarily synonymous with "reliability") of Linux. There is perhaps a connection with the "Worse is Better" philosophy which has worked well for Unix in the past. It would also free up developers to work on other aspects of the overall Linux system, such as applications, desktop issues, perhaps ease of installation, and so on. Maybe I'm rambling, or off base, but this seems reasonable to consider.
But how many Linux applications do you see at CompUSA? Maybe a couple: WordPerfect for Linux, CodeWarrior, etc.; but the idea is that if and when major software vendors start shipping .NET apps, there will at least be a fighting chance that an application that was only intended to run on Windows will actually run on the Linux .NET runtime.
Here's an idea: Set up a campus sponsored mp3 sharing network, and flood it with mp3s containing subliminal messages: "For any integer a not divisible by a prime p, a to the (p minus 1) is congruent to 1 mod p."