Are you on drugs? What you are telling about is equivalent to the
statement
that "theoretically one can for example calculate the results of NP hard
problems, so one should be patient and wait for the calculation to
finish".
You seemt to don't know much about the intrinsics of compilers ABI's and
such
in the world out there. Get real please! BTW. Source release gives you
one
thing more which you don't event try to address: Mostly cross platform
compatible drivers. If you care concearned about some wired kind of
"proprietary information which should remain hidden", then at least
you could just release some kind of "precompiled" but in fact obfuscated
C
source as well. At least this way the kernel interface would remain
open,
but the inner workings specific to the driver in mind hidden.
> Take XFree86 4.0 for instance. They support binary loadable modules
> and they don't have these problems.
Ahhhhhh! Anounce Anounce this is the first message from the future.
Could you please beam the XFree86 4.0 to me from the future.
I would be eager to see how it will be alike...
> > Binary compatibility killed windows. Windows 98 could have been a
> > much nicer OS without back compatibility.
>
> Sorry, I completely disagree here. Backwards compatibility in Windows
> 9x was a choice that Microsoft made to sell the OS (and it worked;
> OS/2 would have killed NT otherwise).
Just a question: What is this funny anti trust court case about one
hears
such much last time in the media about. Please enlighten me.
Are are you trying to tell me that Win-Shit won the market due to
suprerioty
in technology?
> The binary driver model has *absolutely* nothing to do with the
> stability of the Windows platform, and given the amount of respect I
> have for you, I feel you should understand this quite well. The
> Windows 9x platform is unstable because the foundation it was built
> on (the 16-bit Windows 3.1 kernel) was not well designed to begin
Let me paraphrase you: "Win is unstable becouse it is unstable. But the
binary interface for drivers there is rock solid." Ajeee fine logics...
> with. Win32 services were wrapped around an inherently archaic, 16-
> bit kernel. Windows NT is a totally different story, and a hell of a
> lot more stable than Windows 9x.
Beeing more stable then Shit 9x is not a great achievement in fact.
> Windows NT supports binary drivers, but you didn't say that binary
> drivers killed Windows NT? OS/2 has binary drivers, and OS/2 is
> probably one of the most stable OS'es around (Warp Server for e-
> Business is incredibly stable). One reason why OS/2 is so much more
> stable than Windows NT is because IBM takes binary compatibility and
> conformance/regression testing *very* seriously (I know, because we
> license our technology to IBM).
OS/2 isn't cross platform too indeed. And OS/2 isn't eactly what I would
call a success and an example one should follow. BTW. What works fine in
a fully controlled developement model doesn't neccessarly must be the
best way to go for something like Linux.
> > I see no reason to kill Linux by re-enacting proprietary OS history
> > with a free OS.
>
> It got nothing to do with this. It is all about what mechanisms can
> be put in place to allow for better compatibility with the vast
> number of devices that Linux supports. A *real* operating system is
> just not going to be able to survive unless some procedures and
> policies are put in place to ensure future compatibility with legacy
> hardware.
Ahh... Let me just say: Porzyjom uwidiom -- Lieve will tell us.
> > You can (and people do) swap drivers between kernels. What we need
> > to get better if anything are the tools for building modules for
> > users transparently. So I can for example do
> >
> > rpm --install emu10k.i386.rpm
> >
> > and have it build my a SBLive! module for my system and do the
> > dependancies. Ditto for dpkg.
>
> You miss one very important point which you did bring up briefly as
> as something against binary portable drivers. Pure source drivers are
> adversely affected by compiler compatibilty concerns, and unless the
> user is bulding the updated sources with the *exact* same compiler
> revision and kernel source code, you don't really have any idea
> whether it will work. It should work, but how many times have you
> seen compatibility problems where something should work (and did work
> before) but a minor change, compiler bug or something else stopped it
> from working in a future revision?
Fortunately we know about C quite well and the compilers we use are
quite OK too.
You hypohtesize on a problem which didn't really show up during the last
several years.
> This is one reason why when IBM does builds of OS/2, if there are
> updates to legacy components those components get built with the
> compiler version the component was originally built with. If the
> component was written 5 years ago with MSC 6.0c, it is re-built with
> MSC 6.0c for the latest Warp Server for e-Business platform. Why?
> Because that is one way to ensure repetable results.
Ohh shit. You are not telling me I should use gcc-2.6-hacked-for-kernel
0.98pl14 still those days. No! Ehem. BTW. What's today called
a i386 processor is quite a different beast from what it was those
days...
> > > 2. Binary portability requires more solid and clearly defined
> > > interfaces between the kernel internals and the modules themselves.
> >
> > You mean slower, multiple and in frequent cases legacy overhead.
> > You want every Linux user to have a slower more buggy system so a
> > few people can use your product, how considerate you are.
>
> Sure I would like to see binary portable drivers in the Linux kernel
> so we can better support our products (of which some don't fit at all
> well with Open Source). But that is not what this is about. If I need
> to solve this problem, we will create our own Linux distribution
> (they only way we can actually ensure compatibility anyway). We
> probably will end up doing that anyway.
Go ahead...
> I am more interested in the future stability of Linux. I want to see
> Linux succeed, but it needs better support for compatibility and
> regression testing IMHO.
Yess anybody here is seriously interrested in serious bug
reports/improvements!
But there is really no need here to tech us about software engineering
by
using trivally invalid arguments.
> > > EtherExpress XL PCI boards). In particular note the lack of *any*
> > > NE2000 compatible adapters in this list.
> >
> > No NE2K vendor ever submitted some for evaluation and testing to
> > my knowledge. If you look at tier1 you'll generally see products
> > that vendors are shipping now and care about. NE2000 clones are
> > something vendors shipped and have no desire to do any more with
> > other than their customer obligations. It doesnt help their bottom
> > line.
>
> What has this got to do with vendors? NE2000 compatible boards are
> the most common boards around. Sure vendors don't want to support
Wrong they where the most common board. Nowdays I see mostly tons of SMC
out there.
> them anymore, because they would always rather sell you a new network
> card. That is how they make money.
>
> But Linux *should* fully support those boards. Surely there are lots
> of people who have those boards, and proper testing and certification
> can be done regardless of whether a vendor submits NE2000 compatibile
> hardware or not.
>
> Imagine how bad the compatibile of XFree86 would be if no-one
> bothered to ensure that the latest servers work properly on the old
> S3 Vision chipsets? You can be sure no-one at S3 wants to help
> support those boards, because they would much rather upgrade you to a
> Savage2000. But developers on the XFree86 list have those boards, and
> do reguarly test them to ensure backwards compatibility.
>
> > > The *reason* binary portable drivers are not implemented in Linux, is
> > > because Linus and Alan are wielding the power of Linux to *force*
> > > hardware vendors to implement Open Source device drivers. IMHO this
> > > is just as bad as Microsoft using their monopoly power to force
> > > vendors to ship Windows on their PC's.
> >
> > You do yourself no favours. You have a personal agenda to ship
> > proprietary Linux modules. As Linus and I both told you, feel free
> > - but _YOU_ and not the community can support the results. Its a
> > simple matter of maintainability and debugging.
>
> You do yourself no favours when you try to force people who want to
> help Linux grow, to be forced into a model that is fraught with
> compatibity issues. This is the whole crux of the matter. You are
You miss one point. Linux trievs from developement. And even the
kernel currently is far far away from a stage where one could
grave all the needed APIs in stone. Just give us time or help driectly
but don't try to suggest we should starv like strawmanns on the
current stage.
> totally against the concept of building support for binary portable
> modules, because it might enable companies to develop proprietry
> drivers for Linux? What about the fact that there are a ton of
> positive benefit for compatibility issues in doing this? Are you
> willing to jeapordise the future of Linux, just to stop my company
> from being able to build binary portable modules? I didn't realise
> that what I do has such a tremendous impact on the Linux community...
Befor you actually start to develop your own linux distro you could as
well
spend the enegry on the binary only interface you are requesting.
If it turns out to be good --- why not. But please don't hypothesize on
the usefullness of it.
> Why not look at the substance of my post, and respond to some of the
> technical issues for why binary portable modules can help to make
> Linux a much more compatible product? All you have done in your
> response is try to downplay my reasoning by saying that I have some
> hidden agenda to get binary portable modules into Linux so I can sell
> my products.
>
> Regards,
-- Marcin Dalecki- 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/