By: Rob Thorpe (rthorpe.delete@this.realworldtech.com), November 16, 2006 6:29 am
Room: Moderated Discussions
Carlie Coats (coats@baronams.com) on 11/16/06 wrote:
---------------------------
>Linus Torvalds (torvalds@osdl.org) on 11/14/06 wrote:
>---------------------------
>> Rob Thorpe (rthorpe@realworldtech.com) on 11/14/06 wrote:
>> >
>> > What you're describing isn't much of a problem.
>>
>> I disagree. It becomes a huge logistical problem...
>[snip]
>
>> > The second is software that is old, but is still being
>> > maintained. The vast majority of this software is written
>> > in high level languages.
>>
>> That's another totally idiotic argument.
>>
>> People simply do not want to recompile. In many cases
>> they even cannot recompile themselves, and they sure
>> as hell don't want to pay for a software upgrade for all
>> their critical software. If a new CPU needs a recompile,
>> that new CPU is largely broken, as far as 99% of all users
>> are concerned...
>
>This is important not just for hardware; it is important for software as
>well: One of the reasons I call my desktop operating system
>Linux and not GNU/Linux is exactly this: the FSF is all
>too willing to poo-poo the needs for compatibility and tell me just
>re-compile.
Well, the reason for calling it GNU/Linux is to be more accurate about it's origins. Deciding not to do so because you don't like the GNU perspective on compatibility is weird since that's a totally different issue.
I'm not sure what you mean about the FSF in this regard? Are you referring to the way binaries end up incompatible because of changes in libstdc++. That is irritating, but only a small number of people are perpetrating that, and they're irritating many people outside and inside GNU projects, as far as I can see.
Most of the time I don't understand the reason. If there were big changes happening often then introducing incompatability might be understandable, but there aren't really.
The last real big change was threading. I'm hoping things will quieten down after that, but I suspect they won't.
>And one of the reasons I do not like RedHat: there have been far too
>many occasions when they have broken (expensive!) third party compilers
>and other mission critical software in the past. Nor (given that I do
>environmental supercomputing on lots of other platforms (not just
>Linux/x86) is it easy even to build my environment under recent
>RedHat; it winds up being two or three days' "dependency hell" chasing
>down all the libraries involved and building everything in dependency
>order.
Yes, been there, RPM is just nasty. If you do build some bit of the dependence chain from source then convincing it to behave is difficult.
>Moreover, they are telling me they won't support OpenMotif at all
>on future releases. And don't tell me that Motif is an old obsolete
>tool-kit that I shouldn't be using; there simply isn't a viable
>alternative across a mix of Linux/x86, Linux/ia64, Solaris, AIX, IRIX,
>and HPUX.
The last time you mentioned that someone replied saying that they intend to support it, and Lesstif. I don't know if that's true though.
---------------------------
>Linus Torvalds (torvalds@osdl.org) on 11/14/06 wrote:
>---------------------------
>> Rob Thorpe (rthorpe@realworldtech.com) on 11/14/06 wrote:
>> >
>> > What you're describing isn't much of a problem.
>>
>> I disagree. It becomes a huge logistical problem...
>[snip]
>
>> > The second is software that is old, but is still being
>> > maintained. The vast majority of this software is written
>> > in high level languages.
>>
>> That's another totally idiotic argument.
>>
>> People simply do not want to recompile. In many cases
>> they even cannot recompile themselves, and they sure
>> as hell don't want to pay for a software upgrade for all
>> their critical software. If a new CPU needs a recompile,
>> that new CPU is largely broken, as far as 99% of all users
>> are concerned...
>
>This is important not just for hardware; it is important for software as
>well: One of the reasons I call my desktop operating system
>Linux and not GNU/Linux is exactly this: the FSF is all
>too willing to poo-poo the needs for compatibility and tell me just
>re-compile.
Well, the reason for calling it GNU/Linux is to be more accurate about it's origins. Deciding not to do so because you don't like the GNU perspective on compatibility is weird since that's a totally different issue.
I'm not sure what you mean about the FSF in this regard? Are you referring to the way binaries end up incompatible because of changes in libstdc++. That is irritating, but only a small number of people are perpetrating that, and they're irritating many people outside and inside GNU projects, as far as I can see.
Most of the time I don't understand the reason. If there were big changes happening often then introducing incompatability might be understandable, but there aren't really.
The last real big change was threading. I'm hoping things will quieten down after that, but I suspect they won't.
>And one of the reasons I do not like RedHat: there have been far too
>many occasions when they have broken (expensive!) third party compilers
>and other mission critical software in the past. Nor (given that I do
>environmental supercomputing on lots of other platforms (not just
>Linux/x86) is it easy even to build my environment under recent
>RedHat; it winds up being two or three days' "dependency hell" chasing
>down all the libraries involved and building everything in dependency
>order.
Yes, been there, RPM is just nasty. If you do build some bit of the dependence chain from source then convincing it to behave is difficult.
>Moreover, they are telling me they won't support OpenMotif at all
>on future releases. And don't tell me that Motif is an old obsolete
>tool-kit that I shouldn't be using; there simply isn't a viable
>alternative across a mix of Linux/x86, Linux/ia64, Solaris, AIX, IRIX,
>and HPUX.
The last time you mentioned that someone replied saying that they intend to support it, and Lesstif. I don't know if that's true though.