Slashdot Mirror

People, bero sold www.linux-easy.com. I'm sure that will cover his unemployment leave for now.

I don't think he did a good job for RH. Let's face it. KDE was crippled in RH while he was there last two years. It was his job to maintain KDE. He had been failing for last two years. Now he says it's RH fault. Why didn't he care before?

• gcc 2.96 is actually more standards compliant than any other version
  of gcc released at the time Red Hat made this decision (3.0 is even more compliant, but not as stable) yet).
  It may not be "standards compliant" as in "what most others
  are shipping", but 2.96 is almost fully ISO C99 and ISO C++ 98
  compliant, unlike any previous version of gcc.
• gcc 2.96 has more complete support for C++. Older versions of gcc could
  handle only a very limited subset of C++.
  Earlier versions of g++ often had problems with templates and other
  valid C++ constructs.
• gcc 2.96 generates better, more optimized code.
• gcc 2.96 supports all architectures Red Hat is currently supporting,
  including ia64. No other compiler can do this. Having to maintain different
  compilers for every different architecture is a development (find a bug, then
  fix it 4 times), QA and support nightmare.
• The binary incompatibility issues are not as bad as some people and
  companies make you believe.
  First of all, they affect dynamically linked C++ code only.
  If you don't use C++, you aren't affected. If you use C++ and link statically,
  you aren't affected.
  If you don't mind depending on a current glibc, you might also want to
  link statically to c++ libraries while linking dynamically to glibc and other
  C libraries you're using:
  g++ -o test test.cc -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic
  (Thanks to Pavel Roskin for pointing this
  out)
  Second, the same issues appear with every major release of gcc
  so far. gcc 2.7.x C++ is not binary compatible with gcc 2.8.x. gcc 2.8.x C++
  is not binary compatible with egcs 1.0.x. egcs 1.0.x C++ is not binary
  compatible with egcs 1.1.x. egcs 1.1.x C++ is not binary compatible with
  gcc 2.95. gcc 2.95 C++ is not binary compatible with gcc 3.0.
  Besides, it can easily be circumvented. Either link statically, or
  simply distribute libstdc++ with your program and install it if necessary.
  Since it has a different soname, it can coexist with other libstdc++ versions
  without causing any problems.
  Red Hat Linux 7 also happens to be the first Linux distributions using
  the current version of glibc, 2.2.x. This update is not binary compatible with
  older distributions either (unless you update glibc - there's nothing that
  prevents you from updating libstdc++ at the same time), so complaining about
  gcc's new C++ ABI breaking binary compatibility is pointless. If you want
  to distribute something binary-only, link it statically and it will run
  everywhere.
  Someone has to be the first to take a step like this. If nobody dared
  to make a change because nobody else is doing it, we'd all still be using
  gcc 1.0, COBOL or ALGOL. No wait, all of those were new at some point...
  
• Most of gcc 2.96's perceived "bugs" are actually broken code
  that older gccs accepted because they were not standards compliant - or, using
  an alternative term to express the same thing, buggy.
  A C or C++ compiler that doesn't speak the standardized C language is
  a bug, not a feature.
  In the initial version of gcc 2.96, there were a couple of other bugs.
  All known ones have been fixed in the version from updates - and the version
  that is in the current beta version of Red Hat Linux. The bugs in the initial
  version don't make the whole compiler broken, though. There has never been
  a 100% bug free compiler, or any other 100% bug free non-trivial program.
  The current version can be downloaded
  here.
• gcc 3.0, the current "stable" release (released quite some time
  after Red Hat released gcc 2.96-RH), fixes some problems, but introduces many
  others - for example, gcc 3.0 can't compile KDE 2.2 beta 1 correctly.
  Until the first set of 3.0 updates is released, I still claim 2.96 is
  the best compiler yet.

• gcc 2.96 is actually more standards compliant than any other version
  of gcc released at the time Red Hat made this decision (3.0 is even more compliant, but not as stable) yet).
  It may not be "standards compliant" as in "what most others
  are shipping", but 2.96 is almost fully ISO C99 and ISO C++ 98
  compliant, unlike any previous version of gcc.
• gcc 2.96 has more complete support for C++. Older versions of gcc could
  handle only a very limited subset of C++.
  Earlier versions of g++ often had problems with templates and other
  valid C++ constructs.
• gcc 2.96 generates better, more optimized code.
• gcc 2.96 supports all architectures Red Hat is currently supporting,
  including ia64. No other compiler can do this. Having to maintain different
  compilers for every different architecture is a development (find a bug, then
  fix it 4 times), QA and support nightmare.
• The binary incompatibility issues are not as bad as some people and
  companies make you believe.
  First of all, they affect dynamically linked C++ code only.
  If you don't use C++, you aren't affected. If you use C++ and link statically,
  you aren't affected.
  If you don't mind depending on a current glibc, you might also want to
  link statically to c++ libraries while linking dynamically to glibc and other
  C libraries you're using:
  g++ -o test test.cc -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic
  (Thanks to Pavel Roskin for pointing this
  out)
  Second, the same issues appear with every major release of gcc
  so far. gcc 2.7.x C++ is not binary compatible with gcc 2.8.x. gcc 2.8.x C++
  is not binary compatible with egcs 1.0.x. egcs 1.0.x C++ is not binary
  compatible with egcs 1.1.x. egcs 1.1.x C++ is not binary compatible with
  gcc 2.95. gcc 2.95 C++ is not binary compatible with gcc 3.0.
  Besides, it can easily be circumvented. Either link statically, or
  simply distribute libstdc++ with your program and install it if necessary.
  Since it has a different soname, it can coexist with other libstdc++ versions
  without causing any problems.
  Red Hat Linux 7 also happens to be the first Linux distributions using
  the current version of glibc, 2.2.x. This update is not binary compatible with
  older distributions either (unless you update glibc - there's nothing that
  prevents you from updating libstdc++ at the same time), so complaining about
  gcc's new C++ ABI breaking binary compatibility is pointless. If you want
  to distribute something binary-only, link it statically and it will run
  everywhere.
  Someone has to be the first to take a step like this. If nobody dared
  to make a change because nobody else is doing it, we'd all still be using
  gcc 1.0, COBOL or ALGOL. No wait, all of those were new at some point...
  
• Most of gcc 2.96's perceived "bugs" are actually broken code
  that older gccs accepted because they were not standards compliant - or, using
  an alternative term to express the same thing, buggy.
  A C or C++ compiler that doesn't speak the standardized C language is
  a bug, not a feature.
  In the initial version of gcc 2.96, there were a couple of other bugs.
  All known ones have been fixed in the version from updates - and the version
  that is in the current beta version of Red Hat Linux. The bugs in the initial
  version don't make the whole compiler broken, though. There has never been
  a 100% bug free compiler, or any other 100% bug free non-trivial program.
  The current version can be downloaded
  here.
• gcc 3.0, the current "stable" release (released quite some time
  after Red Hat released gcc 2.96-RH), fixes some problems, but introduces many
  others - for example, gcc 3.0 can't compile KDE 2.2 beta 1 correctly.
  Until the first set of 3.0 updates is released, I still claim 2.96 is
  the best compiler yet.

• gcc 2.96 is actually more standards compliant than any other version of gcc released at the time Red Hat made this decision (3.0 is even more compliant, but not as stable) yet). It may not be "standards compliant" as in "what most others are shipping", but 2.96 is almost fully ISO C99 and ISO C++ 98 compliant, unlike any previous version of gcc.
• gcc 2.96 has more complete support for C++. Older versions of gcc could handle only a very limited subset of C++. Earlier versions of g++ often had problems with templates and other valid C++ constructs.
• gcc 2.96 generates better, more optimized code.
• gcc 2.96 supports all architectures Red Hat is currently supporting, including ia64. No other compiler can do this. Having to maintain different compilers for every different architecture is a development (find a bug, then fix it 4 times), QA and support nightmare.
• The binary incompatibility issues are not as bad as some people and companies make you believe. First of all, they affect dynamically linked C++ code only. If you don't use C++, you aren't affected. If you use C++ and link statically, you aren't affected. If you don't mind depending on a current glibc, you might also want to link statically to c++ libraries while linking dynamically to glibc and other C libraries you're using: g++ -o test test.cc -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic (Thanks to Pavel Roskin for pointing this out) Second, the same issues appear with every major release of gcc so far. gcc 2.7.x C++ is not binary compatible with gcc 2.8.x. gcc 2.8.x C++ is not binary compatible with egcs 1.0.x. egcs 1.0.x C++ is not binary compatible with egcs 1.1.x. egcs 1.1.x C++ is not binary compatible with gcc 2.95. gcc 2.95 C++ is not binary compatible with gcc 3.0. Besides, it can easily be circumvented. Either link statically, or simply distribute libstdc++ with your program and install it if necessary. Since it has a different soname, it can coexist with other libstdc++ versions without causing any problems. Red Hat Linux 7 also happens to be the first Linux distributions using the current version of glibc, 2.2.x. This update is not binary compatible with older distributions either (unless you update glibc - there's nothing that prevents you from updating libstdc++ at the same time), so complaining about gcc's new C++ ABI breaking binary compatibility is pointless. If you want to distribute something binary-only, link it statically and it will run everywhere. Someone has to be the first to take a step like this. If nobody dared to make a change because nobody else is doing it, we'd all still be using gcc 1.0, COBOL or ALGOL. No wait, all of those were new at some point...
• Most of gcc 2.96's perceived "bugs" are actually broken code that older gccs accepted because they were not standards compliant - or, using an alternative term to express the same thing, buggy. A C or C++ compiler that doesn't speak the standardized C language is a bug, not a feature. In the initial version of gcc 2.96, there were a couple of other bugs. All known ones have been fixed in the version from updates - and the version that is in the current beta version of Red Hat Linux. The bugs in the initial version don't make the whole compiler broken, though. There has never been a 100% bug free compiler, or any other 100% bug free non-trivial program. The current version can be downloaded here.
• gcc 3.0, the current "stable" release (released quite some time after Red Hat released gcc 2.96-RH), fixes some problems, but introduces many others - for example, gcc 3.0 can't compile KDE 2.2 beta 1 correctly. Until the first set of 3.0 updates is released, I still claim 2.96 is the best compiler yet.

• gcc 2.96 is actually more standards compliant than any other version of gcc released at the time Red Hat made this decision (3.0 is even more compliant, but not as stable) yet). It may not be "standards compliant" as in "what most others are shipping", but 2.96 is almost fully ISO C99 and ISO C++ 98 compliant, unlike any previous version of gcc.
• gcc 2.96 has more complete support for C++. Older versions of gcc could handle only a very limited subset of C++. Earlier versions of g++ often had problems with templates and other valid C++ constructs.
• gcc 2.96 generates better, more optimized code.
• gcc 2.96 supports all architectures Red Hat is currently supporting, including ia64. No other compiler can do this. Having to maintain different compilers for every different architecture is a development (find a bug, then fix it 4 times), QA and support nightmare.
• The binary incompatibility issues are not as bad as some people and companies make you believe. First of all, they affect dynamically linked C++ code only. If you don't use C++, you aren't affected. If you use C++ and link statically, you aren't affected. If you don't mind depending on a current glibc, you might also want to link statically to c++ libraries while linking dynamically to glibc and other C libraries you're using: g++ -o test test.cc -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic (Thanks to Pavel Roskin for pointing this out) Second, the same issues appear with every major release of gcc so far. gcc 2.7.x C++ is not binary compatible with gcc 2.8.x. gcc 2.8.x C++ is not binary compatible with egcs 1.0.x. egcs 1.0.x C++ is not binary compatible with egcs 1.1.x. egcs 1.1.x C++ is not binary compatible with gcc 2.95. gcc 2.95 C++ is not binary compatible with gcc 3.0. Besides, it can easily be circumvented. Either link statically, or simply distribute libstdc++ with your program and install it if necessary. Since it has a different soname, it can coexist with other libstdc++ versions without causing any problems. Red Hat Linux 7 also happens to be the first Linux distributions using the current version of glibc, 2.2.x. This update is not binary compatible with older distributions either (unless you update glibc - there's nothing that prevents you from updating libstdc++ at the same time), so complaining about gcc's new C++ ABI breaking binary compatibility is pointless. If you want to distribute something binary-only, link it statically and it will run everywhere. Someone has to be the first to take a step like this. If nobody dared to make a change because nobody else is doing it, we'd all still be using gcc 1.0, COBOL or ALGOL. No wait, all of those were new at some point...
• Most of gcc 2.96's perceived "bugs" are actually broken code that older gccs accepted because they were not standards compliant - or, using an alternative term to express the same thing, buggy. A C or C++ compiler that doesn't speak the standardized C language is a bug, not a feature. In the initial version of gcc 2.96, there were a couple of other bugs. All known ones have been fixed in the version from updates - and the version that is in the current beta version of Red Hat Linux. The bugs in the initial version don't make the whole compiler broken, though. There has never been a 100% bug free compiler, or any other 100% bug free non-trivial program. The current version can be downloaded here.
• gcc 3.0, the current "stable" release (released quite some time after Red Hat released gcc 2.96-RH), fixes some problems, but introduces many others - for example, gcc 3.0 can't compile KDE 2.2 beta 1 correctly. Until the first set of 3.0 updates is released, I still claim 2.96 is the best compiler yet.

• gcc 2.96 is actually more standards compliant than any other version of gcc released at the time Red Hat made this decision (3.0 is even more compliant, but not as stable) yet). It may not be "standards compliant" as in "what most others are shipping", but 2.96 is almost fully ISO C99 and ISO C++ 98 compliant, unlike any previous version of gcc.
• gcc 2.96 has more complete support for C++. Older versions of gcc could handle only a very limited subset of C++. Earlier versions of g++ often had problems with templates and other valid C++ constructs.
• gcc 2.96 generates better, more optimized code.
• gcc 2.96 supports all architectures Red Hat is currently supporting, including ia64. No other compiler can do this. Having to maintain different compilers for every different architecture is a development (find a bug, then fix it 4 times), QA and support nightmare.
• The binary incompatibility issues are not as bad as some people and companies make you believe. First of all, they affect dynamically linked C++ code only. If you don't use C++, you aren't affected. If you use C++ and link statically, you aren't affected. If you don't mind depending on a current glibc, you might also want to link statically to c++ libraries while linking dynamically to glibc and other C libraries you're using: g++ -o test test.cc -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic (Thanks to Pavel Roskin for pointing this out) Second, the same issues appear with every major release of gcc so far. gcc 2.7.x C++ is not binary compatible with gcc 2.8.x. gcc 2.8.x C++ is not binary compatible with egcs 1.0.x. egcs 1.0.x C++ is not binary compatible with egcs 1.1.x. egcs 1.1.x C++ is not binary compatible with gcc 2.95. gcc 2.95 C++ is not binary compatible with gcc 3.0. Besides, it can easily be circumvented. Either link statically, or simply distribute libstdc++ with your program and install it if necessary. Since it has a different soname, it can coexist with other libstdc++ versions without causing any problems. Red Hat Linux 7 also happens to be the first Linux distributions using the current version of glibc, 2.2.x. This update is not binary compatible with older distributions either (unless you update glibc - there's nothing that prevents you from updating libstdc++ at the same time), so complaining about gcc's new C++ ABI breaking binary compatibility is pointless. If you want to distribute something binary-only, link it statically and it will run everywhere. Someone has to be the first to take a step like this. If nobody dared to make a change because nobody else is doing it, we'd all still be using gcc 1.0, COBOL or ALGOL. No wait, all of those were new at some point...
• Most of gcc 2.96's perceived "bugs" are actually broken code that older gccs accepted because they were not standards compliant - or, using an alternative term to express the same thing, buggy. A C or C++ compiler that doesn't speak the standardized C language is a bug, not a feature. In the initial version of gcc 2.96, there were a couple of other bugs. All known ones have been fixed in the version from updates - and the version that is in the current beta version of Red Hat Linux. The bugs in the initial version don't make the whole compiler broken, though. There has never been a 100% bug free compiler, or any other 100% bug free non-trivial program. The current version can be downloaded here.
• gcc 3.0, the current "stable" release (released quite some time after Red Hat released gcc 2.96-RH), fixes some problems, but introduces many others - for example, gcc 3.0 can't compile KDE 2.2 beta 1 correctly. Until the first set of 3.0 updates is released, I still claim 2.96 is the best compiler yet.

• gcc 2.96 is actually more standards compliant than any other version of gcc so far, not counting CVS snapshots of 2.97. It may not be "standards compliant" as in "what most others are shipping", but 2.96 is almost fully ISO C99 and ISO C++ 98 compliant, unlike any previous version of gcc.
• gcc 2.96 has more complete support for C++. Older versions of gcc could handle only a very limited subset of C++. Earlier versions of g++ often had problems with templates and other valid C++ constructs.
• gcc 2.96 generates better, more optimized code.
• gcc 2.96 supports all architectures Red Hat is currently supporting, including ia64. No other compiler can do this. Having to maintain different compilers for every different architecture is a development (find a bug, then fix it 4 times), QA and support nightmare.
• The binary incompatibility issues are not as bad as some people and companies make you believe. First of all, they affect dynamically linked C++ code only. If you don't use C++, you aren't affected. If you use C++ and link statically, you aren't affected. If you don't mind depending on a current glibc, you might also want to link statically to c++ libraries while linking dynamically to glibc and other C libraries you're using: g++ -o test test.cc -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic (Thanks to Pavel Roskin for pointing this out) Second, the same issues appear with every major release of gcc so far. gcc 2.7.x C++ is not binary compatible with gcc 2.8.x. gcc 2.8.x C++ is not binary compatible with egcs 1.0.x. egcs 1.0.x C++ is not binary compatible with egcs 1.1.x. egcs 1.1.x C++ is not binary compatible with gcc 2.95. gcc 2.95 C++ will not be binary compatible with gcc 3.0. Besides, it can easily be circumvented. Either link statically, or simply distribute libstdc++ with your program and install it if necessary. Since it has a different soname, it can coexist with other libstdc++ versions without causing any problems. Red Hat Linux 7 also happens to be the first Linux distributions using the current version of glibc, 2.2.x. This update is not binary compatible with older distributions either (unless you update glibc - there's nothing that prevents you from updating libstdc++ at the same time), so complaining about gcc's new C++ ABI breaking binary compatibility is pointless. If you want to distribute something binary-only, link it statically and it will run everywhere. Someone has to be the first to take a step like this. If nobody dared to make a change because nobody else is doing it, we'd all still be using gcc 1.0, COBOL or ALGOL. No wait, all of those were new at some point...
• Most of gcc 2.96's perceived "bugs" are actually broken code that older gccs accepted because they were not standards compliant - or, using an alternative term to express the same thing, buggy. A C or C++ compiler that doesn't speak the standardized C language is a bug, not a feature. In the initial version of gcc 2.96, there were a couple of other bugs. All known ones have been fixed in the version from updates - and the version that is in the current beta version of Red Hat Linux. The bugs in the initial version don't make the whole compiler broken, though. There has never been a 100% bug free compiler, or any other 100% bug free non-trivial program. The current version can be downloaded here.

• Install your favorite Linux distribution (I used Red Hat Linux 7 + fixes)
• Install KDE 2.0 (download RPMs)
• Install autologin so they don't need to handle users and permissions
• Install StarOffice - anyone who has used M$ office before can learn to use it quickly, they're not that different UI-wise
• Create a link to StarOffice on the desktop
• Install wine and set up binfmt_misc to execute .exe files out of the box for some Windows applications they want to use

• Lack of Productivity Software: What exactly are you missing? StarOffice is at least as good as Word for normal use, KMail is at least as good as Outlook (and not vulnerable to VBS viruses)
• Lack of fonts: Linux can use the exact same TrueType fonts Windows can use. At least any modern distribution can. XFree86 4.0 has TrueType support by default, Red Hat and Mandrake (and probably others) have shipped patched XFree86 3.x servers to handle TrueType fonts before that, SuSE has shipped xfstt (an alternate TrueType fontserver).
• Lack of popular games: There are currently more Windoze games than Linux games, yes. But a lot of very good games ARE available for Linux. For the others, there's always wine and dual boot.
• Lack of drive support: Such as??? I've never had a problem with my drives on Linux
• No easy way of doing things: What's hard about KDE 2.0? And what functionality do beginners need that KDE 2.0 doesn't provide?

• They can't mess up their system anymore (thanks to the fact that, unlinke Windows 9x, you don't work as root all the time in Linux)
• Stability. No more bluescreens.
• Much better net access (Last time I checked, Windoze couldn't share an ISDN connection between 2 computers. Did they fix this in ME?)
• Easy way to get things fixed up - if they have a problem, I can just ssh in and fix it. Show me a way to do that with Windows without spending a lot of money on extra software.
• It's free as in $0 - no need to waste money on buying updates to the OS and Office suite

• Install your favorite Linux distribution (I used Red Hat Linux 7 + fixes)
• Install KDE 2.0 (download RPMs)
• Install autologin so they don't need to handle users and permissions
• Install StarOffice - anyone who has used M$ office before can learn to use it quickly, they're not that different UI-wise
• Create a link to StarOffice on the desktop
• Install wine and set up binfmt_misc to execute .exe files out of the box for some Windows applications they want to use

• Lack of Productivity Software: What exactly are you missing? StarOffice is at least as good as Word for normal use, KMail is at least as good as Outlook (and not vulnerable to VBS viruses)
• Lack of fonts: Linux can use the exact same TrueType fonts Windows can use. At least any modern distribution can. XFree86 4.0 has TrueType support by default, Red Hat and Mandrake (and probably others) have shipped patched XFree86 3.x servers to handle TrueType fonts before that, SuSE has shipped xfstt (an alternate TrueType fontserver).
• Lack of popular games: There are currently more Windoze games than Linux games, yes. But a lot of very good games ARE available for Linux. For the others, there's always wine and dual boot.
• Lack of drive support: Such as??? I've never had a problem with my drives on Linux
• No easy way of doing things: What's hard about KDE 2.0? And what functionality do beginners need that KDE 2.0 doesn't provide?

• They can't mess up their system anymore (thanks to the fact that, unlinke Windows 9x, you don't work as root all the time in Linux)
• Stability. No more bluescreens.
• Much better net access (Last time I checked, Windoze couldn't share an ISDN connection between 2 computers. Did they fix this in ME?)
• Easy way to get things fixed up - if they have a problem, I can just ssh in and fix it. Show me a way to do that with Windows without spending a lot of money on extra software.
• It's free as in $0 - no need to waste money on buying updates to the OS and Office suite