Mandrake 8.1 Beta1 (Raklet) Released

keegnotrub writes: "Mandrake just dumped 8.1 Beta on their servers. Along with updated software (KDE 2.2, kernel 2.4.8, etc) they have reworked their control center to include many new features." Word to the wise: there are some reactions to this beta -- as well as a list of known bugs and fixes -- at mandrakeforum.com. What I'd like to know is if a Wacom Intuos USB tablet will work out-of-the-box on 8.1, since I just bought a refurbed one ;)

Comments

That's because it's the best thing out there

[Anonymous Coward]

• 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.

Trolling for GCC 2.96