HAL must die!

Da Rock freebsd-questions at herveybayaustralia.com.au
Fri Mar 18 14:06:26 UTC 2011

On 03/18/11 23:03, Jerry wrote:
> On Thu, 17 Mar 2011 18:26:57 -0600
> Chad Perrin<perrin at apotheon.com>  articulated:
>> On Thu, Mar 17, 2011 at 07:48:58PM -0400, Jerry wrote:
>>> On Thu, 17 Mar 2011 16:36:37 -0600
>>> Chad Perrin<perrin at apotheon.com>  articulated:
>>>> No, not really.  It's more the fault of the hardware manufacturer.
>>> Chad, up until this point I had taken your response seriously. In
>>> fact, I thought it was well presented. Then, you went and blew it.
>> You're joking -- right?
>> You haven't taken anything seriously so far other than your own
>> attempts to misrepresent everything I've said.
>> If you want to continue misrepresenting what I said back at me, I
>> recommend you do so off-list rather than clutter up this list any
>> further with it.  Maybe, if you contact me off-list, you can explain
>> your clear anti-Chad bias a bit, too.
>>> I know you are now going say that the hardware manufacturer should
>>> be responsible for the driver.
>> Once again, you demonstrate only that you do not know anything about
>> me. This seems to happen every time you use words like "I know" when
>> referring to me, my motivations, my actions, and my opinions.  Maybe
>> you should stop.
>> The manufacturer does not need to take responsibility for any driver
>> development it does not want to undertake.  That does not change the
>> fact that many manufacturers bend over backwards to support one OS
>> and fail to provide sufficient documentation for their hardware
>> interfaces to make it easy for the developers of other OSes to
>> develop drivers independently, so that though the hardware
>> manufacturers are in no way obligated to write drivers (or even
>> provide the documentation needed to support independent driver
>> writers), they *are* to some extent susceptible to blame for the lack
>> of drivers.
>> Even as simple a step as opening up the source to the drivers they
>> provide, preferally under maximally reusable (i.e. copyfree or public
>> domain) licensing terms, for some OSes would be a big help to
>> independent driver writers -- but many hardware manufacturers and
>> vendors fail to do so for no good reason they have ever articulated.
>> That is part of what is to blame for the lack of drivers for some
>> hardware in some OSes.
>> You act as though all it takes for a driver to get added to an OS is
>> for some developer with commit access to snap his fingers, and it
>> must be the fault of the OS developers that a driver is missing.  The
>> truth of the matter is that developers must prioritize their work,
>> and tend to do so based not only on what they think is important but
>> also on what they are most qualified to address and what will take
>> more time than they have to devote to the project.  Requiring
>> developers to reverse-engineer drivers for other OSes creates some
>> really awful speedbumps on the path to driver development.
>>> Look how much trouble nVidia had getting 64 bit drivers into
>>> FreeBSD.
>> If nVidia opened the source to just one of its drivers under a license
>> that effectively guaranteed everyone could use the code, it would give
>> everybody in the open source community a tremendous leg up on doing
>> the work that nVidia did, saving nVidia a lot of time.  I have read
>> that there are some patent issues that make it difficult for nVidia
>> and AMD/ATI to do so, involving patents that Intel holds in fact, but
>> I also see that while nVidia goes to the trouble of producing closed
>> source drivers for FreeBSD, AMD/ATI has been working with an open
>> source development group to provide documentation for everything not
>> protected by patent to aid in the development of open source
>> drivers.  While the latter takes a little longer up front, it also
>> offers much greater returns on investment in the form of someone
>> other than internal development teams doing the work to create
>> drivers for many OSes.
>> Somewhere in the chain, there's someone involved in those network
>> adapters' manufacture that is standing in the way of easier
>> development of drivers.  As a result, somebody -- a patent holder, a
>> vendor executive, whatever -- is preventing the documentation and
>> release of clear specs or source code that could be used to
>> jump-start driver development.  If nobody does that, then yes,
>> someone out there in the hardware manufacturing chain is at least in
>> part to blame for the lack of drivers, given that it is obvious no
>> developer has unlimited resources to write all the source code the
>> universe needs in the next thirty seconds.
>>> You can blame the open-source community in general and *BSD in
>>> particular for that problem. Even if they did come to some
>>> consensus, they would end up in a pissing contest over the license.
>> There wouldn't need to be any arguments over licensing if the most
>> basic functionality were provided under licenses that are broadly
>> compatible. I really don't see why anyone would think that using a
>> license that precludes license compatibility with other software is a
>> good idea.  It just forces people to duplicate effort endlessly:
>>      Code Reuse and Technological Advancement
>>      http://blogstrapping.com/?page=2011.
>>>> I don't know why you have such a problem with me that you are
>>>> unwilling to read my words as written, and just make up your own
>>>> unreasonable interpretations and misrepresentations instead, but
>>>> it isn't very amusing.
>>> I wasn't trying to be amusing. Like I previously stated, I thought
>>> your response was fine, until you stated preaching the company
>>> gospel.
>> I think you thought it was fine until you found an excuse to get
>> pissed off by way of misinterpreting something I said -- to some
>> extent, *wilfully* misinterpreting it.  That's really your problem,
>> and not mine.
> Chad, you are an intelligent individual. I have no doubt of that.
> However, I think you have failed to think your entire "hardware
> manufacturers are evil for not supporting brand X" operating systems
> concept.
> Did you ever attend a real business school? If so, you might be
> familiar with the term "ROI" which stands for "return of investment".
> Before gong there, lets explore the world of open-source computing.
> According to what documentation I could locate, there are at least 23
> different operating systems, in one form or another, presently
> available. Microsoft controls +/- 90%, with Mac at approximately 5%.
> The rest divide up what is left. FreeBSD is listed at a minuscule
> 0.01%. I found these at:
> <http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=8>.
> I obviously cannot vouch for their authenticity although they do seem
> consistent with other published reports I have seen in the past year.
> Now, it is a given that the conglomeration of non-Microsoft/non-Apple
> operating systems fail to offer a consistent/uniform API for the
> detection of and installation or procurement of drivers for devices on
> their respective systems. This can be attributed to several phenomena
> including testosterone poisoning (there was a rumor that the developers
> of their respective OSs carry rulers around with them). It has also
> been rumored that they suffer from Kainolophobia, Cenophobia and/or
> Cainophobia. They most definitely suffer from Allodoxaphobia when it
> does not agree with theirs.
> Now, I have a proposal. If the fragmented open-source community really
> wants to advance, and maybe FreeBSD actually reach a full percentage
> point, it has to agree on a common interface/API for the detection of,
> installation and configuration of devices on their respective systems.
> A uniform driver base is a must. I am not talking about a semi-uniform
> system; but rather a fully uniform system take works exactly the same
> on each system. This won't be easy for reasons previously mentioned;
> but it is doable. An additional benefit is that the time wasted now by
> each vendor attempting to create and maintain their own API would be
> eliminated. One common interface could be maintained by a far smaller
> group of developers thereby freeing up time to work on other system
> improvements. Obviously, licensing problems would have to be over come.
> Not impossible; although each vendor would indubitably do an academy
> award performance praising their own licensing implementation and
> ridiculing the others. Break out the rulers and let the pissing and
> moaning begin.
> Now, back to my ROI reference. If the above were to actually happen,
> hardware vendors would now only have to code and maintain one single
> driver database. Actually three is you include Microsoft and Apple.
> Interestingly enough, Microsoft and to a lesser degree Apple write
> drivers for some hardware on their respective systems. In any case, I
> believe hardware vendors would be willing to invest the time and money
> in such a venture since they would be able to shown a return on their
> investment without the need to divulge patented information regarding
> their devices. Even better, if such a plan were put into effect, any OS
> that refused to join the alliance would lose their right to blame the
> hardware manufactures since the blame would then unequivocally be
> theirs. A win-win solution for all involved.
I have studied business, and if managers, CEO's, whoever, actually 
looked at the whole picture instead of just trying to hide their answers 
from the person at the next table they might actually improve their own 
stability and performance in the short term, and ensure their own 
existence in the long term- mergers or no. But I digress...

I doubt that any uniform api would ever be possible. However, I do 
_strongly_ believe that hardware manufacturers _should_ be looking 
further down the line and aiming to help their customers or market 
(whichever way you/they choose to look at it) achieve satisfaction.

There are no real secrets, let's be honest here. Patents will provide 
some protection, sure, but inevitably there will always be a suit due to 
infringement or another alternative- the cost of patents is more than 
the manufacture of the product. Especially given the speed of change in 
the tech arena, perhaps they should be focusing more on moving ahead and 
producing a better product then draining every last cent out of a shitty 
one? At the end of the day, what I propose here would not change the 
state of affairs much at all except provide an almost 100% coverage on 
the consumer base which would then produce a "survival of the fittest" 
market- something I doubt anyone with a mindset like M$ would like to see.

What I propose to manufacturers is to produce documentation for their 
hardware (like header file?) and make it available publicly so that the 
OS communities can simply write their own driver. Eases the pressure off 
the manufacturer to support multiple OS api's, and places the 
responsibility on the OS community (whether commercial or not) to 
produce a workable driver.

A paradigm shift is taking place, and even the FOSS community is looking 
for change. Corporations and even small businesses are looking to 
something other than M$ and other commercial options and looking more at 
the OSS options. The FOSS community... well, look at the discussion 
taking place now in this thread- and this is not just on the FBSD lists, 
but others as well.

Food for thought.
> By the way, you noticed that I did not say that the vendors should
> implement a system that uses drivers developed for Microsoft or Apple
> systems directly on their systems. That would almost be to easy since
> it would eliminate the need for hardware vendors to code additional
> drivers. I would not even vouch that it is totally possible; although I
> am willing to bet that if enough money were involved, it would happen.
> Obviously, the major players have nothing to gain by creating just that
> sort of API.
> Now Chad, I know that you would never publicly approve of this solution
> since it goes counter to the "company line". Never-the-less, it would
> work and is doable. Now feel free to blame Microsoft, Apple, hardware
> manufacturers, the governor of Wisconsin or whomever else you feel is
> responsible for the sad state of device compatibility and driver
> availability that now exists in the open-source community.
> If you have a better solution please state it as long as it is not the
> same old, tired, socialistic propaganda that everyone should give us
> something for nothing including divulging patented and or company
> secrets. A philosophy that has proven to not work. The "they owe us"
> rhetoric is worn out and really makes a fool out of those who express
> such beliefs.

More information about the freebsd-questions mailing list