RedHat 7.2 Beta: Roswell 321
LinuxNews.pl writes: "Few days ago RedHat uploaded new Beta release of their distro -
Roswell. If you want to find out more about it just go to the LinuxNews.pl"
And I won't even make a snide comment about how I haven't run Red Hat in 2 years!
Re:Can't wait... (Score:5, Informative)
There are 2 reasons why we're still using 2.96 even though 3.0 has been released.
The first is binary compatibility - gcc 3.0 is not binary compatible with anything else, and we don't break binary compatibility between minor releases.
The second is that 2.96 is way more stable than the 3.0 release (though the current 3.0 branch in CVS works somewhat better). If you've ever tried compiling KDE with gcc 3.0, you'll know what I mean.
I don't think you can come up with any program that uses correct code and doesn't work with gcc 2.96 - if you can, report it [redhat.com] so we can fix it. If you can't, don't complain.
The final will include KDE 2.2 and a proper compiler (namely 2.96
Re:For those that actually care about this stuff.. (Score:3, Informative)
7.1 was released, 7.2 will be. I could tell you the release date, but I'd have to kill you afterwards.
That's because your code is broken (Score:1, Informative)
- 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 [mailto] 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 [linux-easy.com].
- 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.96looks pretty nice.. (Score:3, Informative)
GNOME 1.4.x.. ... XFree 4.1.x.. nautulus(sp).. mozilla.. new config tools eventually phazing out linuxconf... easy GUI ISP dial tool..
I am running 7.1 right now and except for a few setup issues it is actually pretty good.
Hopefully they'll put mozill 9.3 in or the latest version of mozilla at the time of release...
Re:Journaling File System (Score:2, Informative)
Well, if the current discussions taking place in linux-kernel are anything to go by, it provides a journalling FS that doesn't corrupt your data, which can't be said of Rieser at the moment.
The ability to get a journaling FS trivially is actually a very useful one. One incentive to use journalling is to avoid long recovery times for big partitions. If you have big partitions, say 100GB, which is easier - finding a spare 100GB while you do a mkfs for resierfs, or simply poking ext2 a bit and magically aquiring ext3 in place?
Moreover, ext3 provides some more journalling choices than Rieser.
RedHat do provide Rieser as an option, and have since 7 as an install-time FS. But there's no way to convert an extisting ext2 partition to RieserFS.
Re:Interesting that I got rejected for this story (Score:3, Informative)
Re:Another update? (Score:2, Informative)
.2 Redhat releases (Score:2, Informative)
The X.2 releases of Redhat are usually pretty refined. There is not much ground breaking stuff in here, just evolution of the existing packages (gcc 3.0 is not used by default, just included in addition to 2.96).
2.4.6 is now included, as is Xfree 4.1.0 and Gnome 1.4
RH 7.1 is already a pretty nice distribution. It will be interesting to see what the installer changes look like.
The explanation for this (Score:5, Informative)
Or rather, it's because I didn't have the time to build the packages when the beta was current (if you've ever worked for a linux distributor, you know there are more important things to do a couple of days before a feature freeze...), and I don't think it makes much sense to build them now (now that the beta is pretty much obsolete).
That's precisely why I chose to put a recent CVS snapshot that should be pretty close to the 2.2 release in Roswell.
If you don't like it, send some of your spare time to bero@redhat.com.
Re:usability? (Score:3, Informative)
If you are coming from Windows with zero knowledge of Linux - them you might try Mandrake at first. Mandrake is much better suited to people who don't know linux and don't want to mess with the command line...
Now - in terms of usability tests - both GNOME and KDE are doing usability tests. Sun did it for GNOME and the KDE team did look at the Sun results and they did their own on LinuxTag in europe and keep doing so in shows - if you're going to LinuxWorld - then you're welcome to visit the KDE booth and make your remarks - comments are always welcome.
As for your comment "can't see the forest for the trees" - I know exactly what you mean, been there before - and I know lots of others did - and they give advice here and there about usability.
You are of course always welcome to join KDE or GNOME team and give advice or a hint or participate in the desktop enviroment development - people that can point out some wrong GUI decision are always welcome - as long as they are willing to EXPLAIN what is wrong and suggest an alternative (programming knowledge is not necessary)