>> What I find frightening about this whole argument is that so far the only
>> person who has even mentioned a technical viewpoint is Alan Cox.. Why is
>> this ?
>>
>> This is very gratifying news. I can't be sure of other people's
>> motives, of course, but maybe some of them share my view that freedom
>> is important for its own sake, and that we should not lose sight of the
>> main goal for technical subgoals such as speed.
> Speed is only a subgoal to working.
Yes.
>> right now I'm
>> tired of telling people "sorry Linux doesn't support that" I'd rather say
>> "yea it works but it's gonna be slower then the competition"
>>
>> If Linux the free kernel cannot handle a certain piece of hardware on
>> its own, if it needs the help of a non-free driver, what does that mean?
>> It means that *as far as free software is concerned*, we don't support
>> that hardware.
>>
>> So we should tell people, "That hardware is not supported--so buy some
>> other model!"
> If only the whole world thought this way but welcome to real life.
We talk about real life and only about real life. You mix real life in
long-terms and "this second real life".
> I give out advice on what to buy according to how it performs with Linux
> simply because Linux shows the difference between good and bad hardware, so
> in essence that is exactly what I do. But what of people who already
> have computers an run windows on them? The vast majority of people I know
> don't care one bit about who makes the drivers or whether source is
> provided or not, they ask one simple question "will my computer work
> with Linux?" I lot of the time I don't like the answer I am forced to
> give them.
That's HER choice. If they want freedom they must use their heads not only for
hats (even Red :-)
> When I jumped on the Linux bandwagon it wasn't over phillosphical issues,
> windows wasn't doing the job thanks to some script kiddies who discided I
> shouldn't have a working computer, I changed over and my computer worked
> much better - no other reason.
It's Ok for you and it's Ok for a lot of users who does not think about long
future -- thay think "hey, this will help me HERE and NOW, why the hell I'm
need to think about what happens in next 10-15-20 years". Remember: only since
not all peoples back in early 80th accepted "real life" now we have Linux as
it's now (i.e. working :-). If we'll acccept "real life" now 15 years later
we'll have total mess in Linux and also in GNU project as whole and no chances
to fix anything there. We'll not have working software anymore at all. Good
sample, not related to UDI at all:
-- cut --
> On Wed, 7 Oct 1998, Geert Uytterhoeven wrote:
>>
>> Do I read this correct?!? Is it more acceptable to have a bug[*], than a not
>> optimal fix?!?!?
> Yes.
> - the bug is purely aesthetic
> - the bug only happens on 68k and sparc, ie <1% fo the installed base
> Finally, even if the above isn't true, I often reject bug-fixes.
> Bug-fixes are _often_ worse than the bug they fix, even with serious bugs.
> Because a lot of bug-fixes are "band-aid" - not fixing the bug properly.
> And band-aid is BAD. It's worse than even a crashing machine. Because
> band-aid never goes away, and nobody cleans it up.
> I prefer to have a known bug that will eventually get fixed than an ugly
> solution that will hide it forever.
> Geert, go away. You don't seem to understand what being a maintainer
> means. It means saying no to crap.
> Linus
-- cut --
It's better to have no drivers at all then to have crappy binary-only UDI
drivers. Since if there are no drivers at all A LOT OF users will complains
and eventually free, open source drivers will be created. If there are will be
binary-only drivers a lot of users will not bother itself with complains about
drivers and will blame Linux for instability. We ALREADY have here binary-only
drivers for all OS'es -- APM BIOS. And look how ugly and unstable this works
and how many workarounds there are in the Linux APM support! Do you really want
to have Linux kernel with the same mess for essentional subsystems (APM could be
turned off after all -- it's not essentional susbsystem; what you'll do when
all computers will become I2O based and will use buggy UDI drivers?). We still
have chances to prevent this -- if Linux will be unable to use I2O then or I2O
specifiation will be eventually opened or few vendors will create other standard
with open specification since Linux support will become more and more important
for them. If we'll accept UDI in just 5-7 years all Linux computers will be
unable to operate without bloated slow buggy binary-only I2O driver.
> Free source drivers will almost always outperform binary only drivers, so
> what's the deal? UDI is an attack on MS, first we win the war then we
> can dictate terms.
You are wrong. UDI will help us to win BATTLE and will help us to lose WAR.
Bad deal. We'll win BATTLE with M$ (may be, just may be) but we'll got
binary-only I2O drivers in heart of Linux! And this Pyrrhic victory will cost
us freedom (and may be even existance in really long terms) of Linux! VERY BAD
deal.
> If someone converted to Linux, buys a new machine I'm sure they will prefer
> drivers that are open simply because they will perform better. Right now
> most of those new machines are for windows, UDI (if feasible) could allow
> us to do more to change that.
We do not need Linux HERE and NOW. Freedom is more important then marketplace.
If Linux will do better then NT then marketplace will come -- may be not so fast
as without freedom but inevitable. If freedom will be lost (UDI offers us just
this just now) marketshare will come and gone. Bad deal.
In short. UDI as offered just here and just now is BIG THREAT to long-term
future of Linux. UDI could be fixed (read first letter of subject from RMS)
but now it's absolutely unacceptable. Linux will be forced to use UDI in
current form when (and only when) there are will be no vendors who'll offer
modern hardware with open specifications... If this happens then yes, corruption
will be unevitable and Linux will accept UDI since this will be only way to
survive at all...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/