[wellylug] Asus is anti-linux?

[Tony Wills]

At 20:04 16/07/04 +1200, Jamie Dobbs wrote:
>That article is laughable, its not up to hardware vendors to support 
>Operating Systems, it is up to the Operating System to support the hardware.
>Attitudes of this type are will just continue to make the Linux community 
>be looked at as a bunch of whingers. Rather than complain people need to 
>work out how to solve the issue rather then duck-shoving it back to the 
>hardware manufacturer.

The essence of the problem was that Vital Product Data, VPD, was no longer 
forth coming from the hardware - this really looks like a fault as it 
wasn't present in previous versions of the hardware.  The manufacturer 
should either have been able to say "we no longer support that standard" 
and refer them to whatever new standard they use, or log it as a 
fault.  They were clearly unwilling to bother doing anything simply because 
they "didn't support open source" - once they started down that line of 
thinking they switched off and didn't actually address the reported fault.


At 22:32 16/07/04 +1200, Jamie Dobbs wrote:
>Damon Lynch wrote:
>
>>Impossible to do when they don't release specs and it cannot be reverse
>>engineered.
>EVERYTHING can be reverse engineered if analysed closely enough. Over the 
>years the entire Mac ROMs were reverse engineered, if some people can do 
>this then surely they can sit down with some hardware and work out how to 
>get an OS/driver/whatever to talk to it.

If you had to reverse engineer drivers for a piece of hardware like that 
without reference to any documentation or code (either built in BIOS code 
or other high level drivers) you are talking about a major undertaking.  So 
yes 'impossible' within reasonable time and money constraints.  It would 
have to be something you wanted very very badly (or useful to a huge number 
of people) to bother.
(presumably if they're not supporting open source they won't provide the 
documentation and reverse engineering other drivers no doubt puts you in 
violation of some license agreement etc)

And that's exactly the wrong way to write drivers anyway, you will be using 
detailed information about the low level structure and operation of the 
device with no knowledge of the design parameters assumed by the 
manufacturer.  If the manufacturer changes anything your driver is likely 
to break.

That sort of problem may be exactly what happened with the ASUS board, 
without any published specs the driver authors are liable to be caught out 
by every little tweak to the hardware.
But in this case the manufacturer didn't seem interested in even looking 
into it, to decide whether it was a fault with their product or a 
deliberate design change.

So yes the operating system needs to support the hardware and no doubt 
sooner or later someone will write a kludge to get around the problem and 
maybe ASUS will acknowledge the problem when it bites them from another source.

(Maybe they have other more appropriate avenues for reporting design 
issues, as the technical help desk is not there to support their hardware 
so much as to support Windows usage of that hardware)

ASUS are responsible for their policy and the attitudes of their help line 
staff, so they must have accepted that valid fault reports may not get 
through their technical help desk ... this will have an impact upon how 
their products are viewed - it is the usual story about how many people a 
dissatisfied customer will tell about their experiences ...