-----Original Message-----
From: Dave Reed [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 10, 2000 6:55 PM
Subject: Re: winmodems vs. Lucent vs. open source
>> From: Alan Mead <[EMAIL PROTECTED]>
>>
>> A lot of people have slammed Ed's perspective. I think we should
separate
>> distaste for the hardware from our dismay that the manufacturers do not
>> support Linux. The hardware may make sense in some contexts where the
>> modem is rarely used.
>>
>> And even if we think the hardware sucks, it remains somewhat of an
>> Achilles' heel for "desktop Linux" that most people's modems don't work
>> with Linux.
>>
>> The real villain here is the manufacturers who refuse to support Linux at
all.
>>
>> -Alan Mead
Alan, I agree with your statement here.... but I'd take it further. As
Edward
said, most people DO have spare cycles... a lot. If RH 6.2 will operate
fine on
a 486-25, how many spare cycles do folks running P233 have? Quite a few...
and that's after being more responsive, etc. Look at your load levels,
folks!
Most people (well, those not running something like Seti@home) are averaging
a good bit under 50% load, EVEN with Gnome and X running. With faster
machines,
I doubt 3% of the CPU would need to be used for the modem. So yes, the
villain
here is the manufacturers who haven't yet supported Linux (I wouldn't say
"refuse
to support Linux".... they just haven't started yet.) Also, there is
another
villain in the drama... one that's going to get me some boos. See below.
>>
>> At 02:47 PM 7/8/00 , you wrote:
>> >The same logic of why a winmodem might be appropriate
>> >for an OEM system also applies to linux - most of us running
>> >systems in the hundreds of MHz _do_ have some spare cycles.
>> >
>> >So why not take advantage of a cheaper modem? Hell, most of
>> >us DONT have true PS printers - does using GS and printfilters
>> >to make a "software PS printer" make is bad?
>> >
>> >And, what's wrong with a binary-only driver?
>> >--
>> >Edward Schernau, mailto:[EMAIL PROTECTED]
>
>
> While I agree with Alan, I do think there are problems with
> binary-only drivers. For example, nvidia only provides binary drivers
> to take advantage of the 3D graphics hardware with XFree 4.0. When
> XFree 4.0.1 came out, the binary-only drivers didn't work with them.
> You had to stay with XFree 4.0 (which has bugs) at least until nvidia
> releases new drivers (which I think they since have somewhere, but not
> on their main web page for drivers).
>
> This situation may be the one thing that keeps me from buying a nvidia
> card (which I am currently contemplating).
>
> Dave
Dave, you've just pointed out another villain... and strangely enough,
you're
pointing the finger the wrong way. The reason binary-only drivers stop
working
with new versions is because the interfaces to the libraries change. It's
not
required that a SPECIFIC set of libraries be used (unless they are signed!)
for
a binary only driver... only that the interface, how the libraries interact,
stay the same. But they don't. Granted, the new libraries are better, and
solve
bugs, but if they were link-in compatible (which IS possible), as opposed to
compile time compatible, the driver wouldn't care if they were updated...
it would work better with the updated libraries, in all probability, but it
would be functional regardless.
This is an interesting point, because it shows two very important things
that separate Linux from the "mainstream" OSes.... it's still under primary
development, i.e., the base OS is still being developed. This differs, for
example, from WinNT as WinNT is NOT under development (the interfaces are
defined)
but is under more of a maintenance mode... When the new WinNT (Win2000)
came out,
it was a different target, and things had to be checked all over again.
Updating the drivers once every 4 years for a new OS is doable... updating
every 2-3 months is a nightmare.
So the >OTHER< "villain" (and I hesitate to actually call all those good
developers
who are trying so earnestly to improve Linux villains) is the developers of
the
dynamic link libraries who write the code such that it does require a
recompile,
as opposed to a replacement. Note, this is the way Unix has been for
years...
but that doesn't mean that you can't change it.
Hmmmm.... I think they could combine the two by putting in a translation
layer
in the middle that interfaces with the new libraries (and would have to be
recompiled
every time) but has a uniform signature and interface every compile for the
binaries.... Or of course, the driver authors could simply eschew using
dynamic
linking and use only static linking (boo, hiss! No one likes static
linking! It
wastes too much resources!)
Bill Ward
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
