I can't comment on Mandrake 9 but traditionally, at the kernel level,
Mandrake and RedHat have been quite similar (thats why we use it). The
only major difference I've ever really found is that the folks at
Mandrake seem to be a bit more switched on, and their distributions are
a quality level higher (enough of the Mandrake pitch ;)..

As Mandrake is also very fond of claiming they are 100% compatible with
RedHat this would lead me to suspect that what applies for one also goes
for the other

This has tweaked my interest though, so if anyone can provide a
definitive answer I'd also like to know....

Kris, are these new developments RedHat claims, or is this something
you've personally verified? Not that I'd *ever* suggest the RedHat folks
might claim something thats not quite true ;)

Simon

Kriston Rehberg wrote:

> No, I don't have any idea how or if any of this applies to Mandrake 9.
>
> Kris
>
>
> [EMAIL PROTECTED] wrote:
>
>> Kris
>>
>> Do you  (or anyone) know if these multithreaded benefits are spcific to
>> Redhat or some aspect of the kernel they are using. I've just downloaded
>> Mandrake 9.0 which is using the 2.4.19 kernel and wondered if these
>> changes would be seen here (I'll have a dig around myself but thought
>> I'd ask in case the answers already known).
>>
>> Thanks
>>
>>    Steve
>>
>> On Tue, 2002-10-01 at 05:00, Automatic digest processor wrote:
>>
>>
>>
>>> From: Kriston Rehberg <[EMAIL PROTECTED]>
>>> Subject: AOLserver and Red Hat 8
>>> Date: 30 Sep 2002 13:55:29 -0400
>>>
>>> Hi!  With today's release of Red Hat 8.0 there are significantly
>>> excellent changes to Red Hat to make life with multithreaded programs,
>>> like AOLserver, more convenient.
>>>
>>> 1) gcc-3.2 is used exclusively throughout Red Hat 8.0.  This means that
>>> C89, C99, C++, ANSI C++, and friends will work together in harmony as
>>> AOLserver shared objects.  Please note that there is an
>>> inconsistency in
>>> the Red Hat 8.0 release notes that claims that the C++ ABI will change
>>> in future releaes, but this directly contradicts the actual GCC 3.2
>>> release notes that state clearly that the C++ ABI will not change in
>>> future releases.  If you're a C++ head be sure to watch out for this
>>> but
>>> it's probably as easy as keeping your code easy for other people to
>>> recompile.
>>>
>>> 2) Multithreaded program support is getting better and better!  The top
>>> and ps commands now only display the main (initial) thread of
>>> thread-aware processes. To show all threads, use the command ps -m or
>>> type H in top.
>>>
>>> 3) gdb seems to know what it's doing with multithreaded programs and
>>> core dumps--I think the jury is still out on this one.
>>>
>>> 4) The version of Tcl does not have thread support enabled so AOLserver
>>> 3.5 users will  need to build their own copy of Tcl with
>>> "--enable-threads --enable-shared".  At runtime, AOLserver at this time
>>> does not "detect" that a proper version of Tcl with threads is
>>> installed
>>> but it's likely we can do this in a future release for all systems.
>>>
>>> 5) Long ago the default file descriptor limit on Linux was made
>>> configurable even if you don't have a 64-bit system.  The default Linux
>>> installaion has about three zillion times more file descriptors than
>>> even Solaris 9.
>>>
>>> 6) ns_sendmail will work as long as you use "localhost" or "127.0.0.1"
>>> as your smtphost.  Red Hat 8 only listens on localhost for security
>>> reasons.
>>>
>>> 7) OpenSSL should be rebuilt according to the documentation that comes
>>> with nsopenssl, otherwise nsopenssl will not recognize it.
>>>
>>>
>>> That's all I can think of right now.  In the meantime, download Red Hat
>>> 8.0 and tell us what you think!
>>>
>>> Kris
>>>
>>> ----
>>>
>>>
>>>
>>
>>
>>
>>
>
> .
>

--
Simon Millward
Director
OpenMSG Limited
+44 (0) 7818 045 801

Tel: +44 (0)1225 48 48 05   Fax: +44 (0)1225 31 6789   Web http://www.open-msg.net
Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of OpenMSG Ltd.

Reply via email to