Seems like things need to be clarified there - I've been using RH since their 4.0 release - and i've always downloaded the latest official kernel and customized it for my machine (smaller size, modules).
I've never had problems with the init scripts and "my" kernels. Now I'm using the RH 6.1 release with "my" kernel and while the init script spits out a warning, everything still works ok.
If you have trouble applying standard kernel patches to RH kernel source, install their kernel source RPM, apply your patch and then apply their patches.
In the end these little forks in the kernel source amount to very little difference in the overall kernel. 99.99% (if not 100%) of the apps still work on forked kernels. The main addition seems to be drivers just to support new hardware.
In my opinion little forks are actually quite healthy, as it keeps the development process moving along quickly. But to journalists used to seeing products from one company and only that one company makes modifications to their product, something like multiple forks alarms them, just because it is different. They write about it from their point of view (read: spreading FUD) not understanding the dynamics behind the open source method of development.
Perhaps we should educate the masses about about the fork phenomena. Little forks are good (example: Linux and the AC patches). Big forks are bad (example: the pathetic BSD wars). However even big forks can be good sometimes, as was the case with gcc/egcs. I'm sure there's a goldmine here in explaining the dynamics of forking.
I agree with your analysis, and this leads into another area: speculatively executing "roughly" translated code would take a long time if there are a few sets of it and only one target host. Either the host would have to be really fast (10 gigahertz range) to make this viable, or have multiple complete execution units, ( akin to multiple integer units in a Pentium, but more complex ).
Since a 10 gigahertz CPU is unatainable with current technology, the host CPU would have to be like a SMP machine - eg. 16 copies of the exact same CPU, but all on one silicon.
If the invididual execution units are too complex they'd be expensive (to design and make) and not able to do high clock rates, so we're looking at relatively primitive execution units, probably with the complexity of, say, Motorola 68000, but cranked up to, say, 1 GHz.
This would sit well with making a cheap and cheerful processor, able to undercut the price of Intel stuff by a wide margin, due to a much larger yield per silicon waver. The problem with this is who would actually want your CPU unless it runs x86 stuff - and this is where the translation software and translation-assisting hardware (ie. this patent) comes in. I doubt that this extra hardware would take much silicon real estate.
Now I can see how it can actually run stuff faster - even if 10 of the 16 execution units ran translated code which was crap, there's still 6 sets of code that were OK. If one unit runs at 1 GhZ, we have in effect a 6 GHz execution.
All sounds good in theory - I wonder how it actually turns out, or didn't turn out, seeing as this patent was filed in 1996 and I remember Linus saying something about a change of direction last year.
Let's look at the economics of introducing a new processor into the market. For the demand to be there, it would have to satisfy these conditions: 1) run x86 stuff 2) _much_ cheaper to produce than current Intel stuff. Look at AMD and Cyrix - they have nice processors, but not really that much cheaper. 3) runs stuff at a comparable speed
If the above conditions are satisfied, then it would sell well... however 3rd condition could also be: 3) run stuff much faster
which would allow Transmeta to charge about the same as Intel and make a very nice profit.
Slashdot Mirror
Seems like things need to be clarified there - I've been using RH since their 4.0 release - and i've always downloaded the latest official kernel and customized it for my machine (smaller size, modules).
I've never had problems with the init scripts and "my" kernels. Now I'm using the RH 6.1 release with "my" kernel and while the init script spits out a warning, everything still works ok.
If you have trouble applying standard kernel patches to RH kernel source, install their kernel source RPM, apply your patch and then apply their patches.
In the end these little forks in the kernel source amount to very little difference in the overall kernel. 99.99% (if not 100%) of the apps still work on forked kernels. The main addition seems to be drivers just to support new hardware.
In my opinion little forks are actually quite healthy, as it keeps the development process moving along quickly. But to journalists used to seeing products from one company and only that one company makes modifications to their product,
something like multiple forks alarms them, just because it is different. They write about it from their point of view (read: spreading FUD) not understanding the dynamics behind the open source method of development.
Perhaps we should educate the masses about about the fork phenomena. Little forks are good (example: Linux and the AC patches). Big forks are bad (example: the pathetic BSD wars). However even big forks can be good sometimes, as was the case with gcc/egcs. I'm sure there's a goldmine here in explaining the dynamics of forking.
I agree with your analysis, and this leads into another area: speculatively executing "roughly" translated code would take a long time if there are a few sets of it and only one target host. Either the host would have to be really fast (10 gigahertz range) to make this viable, or have multiple complete execution units, ( akin to multiple integer units in a Pentium, but more complex ).
Since a 10 gigahertz CPU is unatainable with current technology, the host CPU would have to be like a SMP machine - eg. 16 copies of the exact same CPU, but all on one silicon.
If the invididual execution units are too complex they'd be expensive (to design and make) and not able to do high clock rates, so we're looking at relatively primitive execution units, probably with the complexity of, say, Motorola 68000, but cranked up to, say, 1 GHz.
This would sit well with making a cheap and cheerful processor, able to undercut the price of Intel stuff by a wide margin, due to a much larger yield per silicon waver. The problem with this is who would actually want your CPU unless it runs x86 stuff - and this is where the translation software and translation-assisting hardware (ie. this patent) comes in. I doubt that this extra hardware would take much silicon real estate.
Now I can see how it can actually run stuff faster - even if 10 of the 16 execution units ran translated code which was crap, there's still 6 sets of code that were OK. If one unit runs at 1 GhZ, we have in effect a 6 GHz execution.
All sounds good in theory - I wonder how it actually turns out, or didn't turn out, seeing as this patent was filed in 1996 and I remember Linus saying something about a change of direction last year.
Let's look at the economics of introducing a new processor into the market. For the demand to be there, it would have to satisfy these conditions:
1) run x86 stuff
2) _much_ cheaper to produce than current Intel stuff. Look at AMD and Cyrix - they have nice processors, but not really that much cheaper.
3) runs stuff at a comparable speed
If the above conditions are satisfied, then it would sell well... however 3rd condition could also be:
3) run stuff much faster
which would allow Transmeta to charge about the same as Intel and make a very nice profit.