SCIENTIFIC-LINUX-USERS Archives

June 2009

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Anatoly Solomin <[log in to unmask]>
Reply To:
Date:
Fri, 26 Jun 2009 13:09:44 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (95 lines)
Hi Serguey,

see my answer in-line:

Serguei Mokhov wrote on 06/26/2009 11:06 AM:
> Hi,
>
> Not to rant but...
>
> On Fri, Jun 26, 2009 at 5:35 AM, Anatoly
> Solomin<[log in to unmask]> wrote:
>> Dr Andrew C Aitchison wrote on 06/26/2009 08:45 AM:
>>> On Thu, 25 Jun 2009, Anatoly Solomin wrote:
>>>
>>>> I'm running SL5.3 on DELL XPS M1530 laptop. And the "Wireless 355
>>>> Bluetooth"
>>>> does not work, though I installed the necessary software, I guess.
>>>>
>>>> All I know is that with Fedora 11, this Bluetooth on my XPS works 
>>>> out of
>>>> the box (apparently with the same suite of gnome's bluetooth software,
>>>> but of
>>>> later version, of course).
>>>>
>>>> The question is: Can the latest version of that software suite be
>>>> incorporated into SL5.3 as well ?
>>> You do know that SL5 is a port of Red Hat Enterprise Linux 5
>>> which came out in parallel with Fedora Core 6 and updates like
>>> this are up to Red Hat not Scientific Linux ?
>>>
>>> RHEL5 + SL5 exist to provide stability over a longer time frame than
>>> Fedora. It is not reasonable to expect the same bleeding edge
>>> functionality.
>>>
>> Yes, I'm well aware of this reasoning.
>>
>> Then why Scientific Linux can't make things pragmatically clear:
>>
>>  1. include in its official distribution only things that work well
>>     enough and exclude the rest,
>>  2. say in open text, that the rest of the things (and also newer
>>     versions of the provided software), even though many of them work
>>     fine in Fedora, are simply not available in Scientific Linux.
>
> IMNSHO this has been apparent and "pragmatically clear" for many years
> to the majority of RHEL/CentOS/SL and other derivatives' users...
>
>
>> That would be only fair towards the users. Otherwise apparency of our
>> wasteful efforts to find workarounds for bugs in old versions, that had
>> already been fixed in newer versions since long, only discredits SL and
>> Linux in general, etc.
>
> I don't think you can generalize like to discretid the whole of SL or
> Linux just like that just because of your particular case. SL, or any
> enterprise-derived Linux is striving for stability of the core components
> and tools, much better tested than the bleeding edge stuff.
>
> BTW, nothing stops you from getting the bleeding edge tools on SL from
> the other than sl-*.repo repositories, included in SL, but not enabled
> by default, such as dag, amftrans, finding rpms on rpmfind, for el5,
> or even livna, or, worst case, just compiling them yourself from the
> source code of the package you are interested in. Some people compile
> latest kernels on SL and live happily with that.
>
OK, but unfortunately, concerning that Bluetooth stuff I'm right, I'm 
afraid, because it is in "sl-base", and therefore, presumably is in an 
acceptable shape, but instead, it miserably fails to work with both: 
moderately new DELL XPS M1530 and relatively old DELL Precision M90.

So the Bluetooth example is a good illustration of my point: do not 
publish what can't work. Your statement that SL publishes only 
well-tested things - does not hold here. The "bleeding-edge" Fedora's 
Bluetooth version works, while "stable" SL's Bluetooth version - does not.

"Stable" is by definition - functioning, I think.

Sorry.

Thanks !!

- Anatoly
> If you need the bleeding-edge by default, effortlessly, without turning
> on extra repos or compiling, then maybe SL is not for you and you
> should stick to Fedora 11?
>
>
>> Thanks !!
>>
>> --
>> Dr. Anatoly Solomin   Researcher in Particle Physics   University of 
>> Bristol
>
>

ATOM RSS1 RSS2