RH 9
TH
Here, only a couple of weeks before EH 9 is released, does anyone have some
information on what new things this release will deliver?
I cant seem to find any information on the RH site...
--
TH
Keith Clark
TH wrote:
Here is what RedHat is emailing to the subscriber list:
"Dear Colleague:
You may know that Red Hat Network is the best way to keep your
systems running the latest errata and always up to date. What you
might not know is that Red Hat Network passed the one million users
mark earlier this year. We've listened to valuable feedback and have
added two items of interest to keep those users happy - early release
of Red Hat Linux 9 ISOs and improved technical support.
Beginning March 31, 2003, paid subscribers to Red Hat Network will
have access to Red Hat Linux 9 ISOs - a full week before retail store
and Red Hat FTP availability. Also, Red Hat Network subscribers will
receive dedicated Red Hat Network Technical Support. "
TH
> Here is what RedHat is emailing to the subscriber list:
Yes..I got that too...but it doesnt say anything about what changes version
9 will offer....
--
TH
Keith Clark
XFree86 4.3 is a big one. Mozilla with XFT font support... There's a lot more
but those were the things that struck me when using the beta. Of course there's
Gnome 2.2 and KDE 3.1 also...
J.O. Aho
more or less a bugfix of RH8 with of course updated sofatware as Gnome2 (IMHO
it's a downgrade, but), Mozilla 1.3, XF86 4.3, KDE 3.1, RPM 4.2 ...
//Aho
Keith Clark
"J.O. Aho" wrote:
I don't see why it should be called "9", and not "8.1".
--Keith
TH
> I don't see why it should be called "9", and not "8.1".
Ok, I thought so :)
Probably because Mandrake is hitting with 9.1 allready this week.
--
/TH
J.O. Aho
It's quite silly this... I hope that the RH9 will be less buggy than RH8,
damn, need to build up a new Gnome1.4 environment if "upgrading" :(
//Aho
TH
> So why not hit RH10 at once ... :P
So true..
> It's quite silly this... [snip]
I agree, the more widespread Linux becomes, the faster the biggest distros
get kicked out...sadly they also tend to have more flaws...kinda :) Its all
about catching noobs, and what better way than to have the highest
versions-number :)
--
TH
Keith Clark
The biggest reason I hear is binary compatibility.
Apparently the new version doesn't have binary compatibility with 8.0 so they
rolled the major number.
J.O. Aho
> The biggest reason I hear is binary compatibility.
>
> Apparently the new version doesn't have binary compatibility with 8.0 so they
> rolled the major number.
I guess this is the change of ABI in GCC when changing from 2.9x to 3.x, but
all that happen between 7.3 and 8.0, so I don't think this is the case.
I agree more with TH, that all is about catching more noobs, the higher
version number you have on your distro the better, and of course you get more
ex sold when you have big changes than small changes in version number.
//Aho
Plex
> all that happen between 7.3 and 8.0, so I don't think this is the case.
>
> I agree more with TH, that all is about catching more noobs, the higher
> version number you have on your distro the better, and of course you get more
> ex sold when you have big changes than small changes in version number.
Lots of speculation, so here's a dump of what I've been able to put
together, both from a friend (Howard Pearlmutter, a geek/guru who's
been around unix since the 70's), and from digging around on the net:
Red Hat 9 uses Linux kernel 2.4.20 & GNU libc 2.3 (with NPTL).
The key deep-level differentiator is inclusion of the Native POSIX
Thread Library; NPTL may break binary compatibility, so that's why the
major version number had to change.
From the readme included with the Pre-9.0 beta test (8.0.94, Phoebe):
--------------------------------------------------------------------------
Red Hat Linux 8.0.94 includes the Native POSIX Thread Library, a new
implementation of POSIX threads for Linux. This library provides
performance improvements and increased scalability for i686 or better
processors.
This thread library is designed to be binary compatible with the old
LinuxThreads implementation; however, applications that rely on the
places where the LinuxThreads implementation deviates from the POSIX
standard will need to be fixed. Notable differences include:
- Signal handling has changed from per-thread signal handling to
POSIX process signal handling.
- getpid() returns the same value in all threads.
- Thread handlers registered with pthread_atfork are not run if
vfork() is used - no manager thread
Applications that are known to have problems using NPTL include:
- IBM JRE prior to version 1.4.1
- Sun JRE prior to version 1.4.1
If an application does not work properly with NPTL, it can be run
using the old LinuxThreads implementation by setting the following
environment variable:
LD_ASSUME_KERNEL=2.2.5
NPTL support in the kernel can be disabled for the entire system by
using the following boot-time option: nosysinfo
------------------------------------------------------------------------
For the guts:
glibc-2.3.1-46.i686.rpm
------------------------------------------------------------------------
Native POSIX threads will finally allow Linux to scale properly,
erasing yet another advantage that "enterprise" unix's have had over
Linux til now.
In fact, threads are so important to Java that the VM guys (Sun, IBM)
had to adapt (kludge) their code to the old Linux threading model to
port their VM's to Linux with half-decent performance. So it's ironic
that now that Linux is getting cleaned up (in part due to IBM's NGPT
prodding; see below), IBM & Sun have to go back and undo their
adaptations/kludges. But post 1.4.1 versions should be getting pretty
tuned for this (1.4.1_01, 1.4.1_02).
NPTL is good news for databases and other server-side apps, but it is
especially key to getting top-notch Java performance. Howard
Pearlmutter said to expect a noticeable increase in java-linux
synergy, enabled by such OS-level improvements as NPTL, and driven by
J2EE hosting and development/app platforms such as Eclipse. Redhat 9.0
paves the way.
This is important stuff, and not just at the geek level. Even the
business press is getting a clue:
http://www.businessweek.com/technology/cnet/stories/994074.htm
(excerpts:)
"We felt it was important to get NPTL to a mass audience soon,"
Wilson said. Better threading improves server tasks such as running
Java programs and databases; it also helps the performance of some
desktop software, such as the Mozilla Web browser and the OpenOffice
software suite, Wilson said.
But the change to NPTL means some older software won't work,
including 3D graphics support for Nvidia and ATI graphics cards and
some versions of Sun Microsystems' software for running Java programs,
Red Hat said.
For threading, stars have aligned for NPTL. One key endorsement came
from Linux leader Linus Torvalds, who has accepted NPTL into the 2.5
version of the Linux kernel, the test version that will be numbered
2.6 when ready for real-world use.
Another endorsement came on March 14, when IBM programmers working on
their own threading improvements--a project called Next Generation
Posix Threading--announced they were focusing their attention instead
on NTPL. "We don't want to split the community to choose one over the
other," the developers said in a statement, and NPTL has successfully
dealt with the problems the IBM team had set out to solve.
While Red Hat programmers Ulrich Drepper and Ingo Molnar were
instrumental in making NPTL a reality, IBM programmers such as Rusty
Russell also have helped, Wilson said.
--- end ---
That provides a context for understanding these next 2:
---------------------
http://oss.software.ibm.com/developer/opensource/linux/news/byproject.php?project_id=55
January 10, 2003
The Next Generation POSIX Threading project has released NGPT 2.2.0.
In this release, performance and scalability were the key focus of
NGPT developers. Performance and scalability were improved to the
point where NGPT bests both LinuxThreads and the new NPTL threading
package in benchmarks. No changes were made to the kernel patches and
thanks to the NPTL effort, all changes required to run NGPT on the
latest 2.5.x kernels are already included.
Performance and scalability were measured using a benchmark program
developed by Sun Microsystems to "prove" that a 1:1 threading model is
better than the M:N threading model. As can be seen in the benchmark
results NGPT is the performance and scalability leader on both a 2-way
and 4-way machine running this benchmark. The benchmark results can be
found on the NGPT website. The benchmark itself can be downloaded from
the Sun Microsystems site.
--------------------
March 24, 2003
http://www-124.ibm.com/developerworks/oss/pthreads/docs/announcement
On behalf of the NGPT team, we would like to announce a change in
direction
for the Next Generation POSIX Threading (NGPT) project.
As many of you may know by now, a new POSIX threading library NPTL
(http://people.redhat.com/drepper/nptl-design.pdf) is now available
for Linux
and we don't want to split the community to choose one over the other.
The Linux 2.5 kernel has added many new features in the areas of
Scheduler,
POSIX signal handling, clone() improvements and futexes that make
highly
scalable and performing threads a more viable solution in Linux.
With this in mind, we have decided to stop adding new functionality to
the
NGPT pThread library and will go in pure support mode. We will provide
full
support for the existing NGPT releases and to those who have
incorporated NGPT
in their current releases, and work to bring solutions for other
threading
requirements to the NPTL community for discussion and dispositioning.
Currently, using Glibc-2.2.x, NGPT can be used as Linuxthreads
replacement
library. However, NGPT will not be supported under Glibc-2.3.
Our original goal was to make threading in Linux more scalable and
POSIX
compliant, and it seems clear that NPTL has addressed such issues
quite well.
We will continue focus and working in the direction of improving
overall
threading performance in Linux.
In summary, we feel that this decision is the best way to support the
community
for the long term. We would also like to participate to improve
threads
scalability and POSIX compliance for threading package in Linux.
--end--
Here's the abstract from --
http://people.redhat.com/drepper/nptl-design.pdf
"Today's demands for threads can hardly be satisfied by the Linux-
Threads library implementing POSIX threads which is currently part of
the standard runtime environment of a Linux system. It was not written
with the kernel extensions we have now and in the near future
available,
it does not scale, and it does not take modern processor architectures
into account. A completely new design is necessary and this paper will
outline the design we came up with."
IMHO, quite enough by itself to justify incrementing a marketing
moniker from
"8.0" to "9.0" ;-)
-Plexa
BTW: anything to pl...@redivision.com goes right into the spam bucket,
so dont waste your time.
'I don't care if its hard of soft,
just "semper ubi sub ubi"'
------------------------------------------------------------------------------