Barrapunto

Puedes afirmar que originariamente no se hizo para parchear un bug en Linux?

1) Si hubiera un bug en la implementación ACPI del kernel al fabricante le cuesta menos avisar a la lista de desarrollo del kernel para que lo arreglen ellos que buscar una forma de sortear el bug por su cuenta. No es que cueste menos solamente, es que las cosas no se hacen así. En cualquier caso dicho supuesto "bug" no existe porque la implementación de ACPI del kernel se ajusta al estándar como un guante y las placas y bios que realmente lo cumplen no tienen ningún problema en absoluto.
2) Si simplemente se hubieran ceñido al estándar no tendrían que haber hecho ninguna tabla de códigos DSDT especial para Linux porque no la necesita. Los únicos que la necesitan son los sistemas de M$ que como siempre se salen de los estándares por su habitual repugnante política de intentar obligar por todos los medios que todo el hardware sea incompatible con la competencia.
3) Desde la primera vez que se implementó el soporte ACPI en el kernel se hizo siguiendo el estándar que para eso está así que las tablas DSDT específicas para Linux que han metido no funcionan en níngún kernel estable de Linux
4) Muchos fabricantes aún no dan soporte a Linux pero al menos no lo reconocen abiertamente lo cual puede indicar que lo hacen por falta de interés o de programadores expertos en el tema o simplemente falta de recursos. En cambio si un fabricante de hardware reconoce a estas alturas de la película, abiertamente y sin tapujos que no da ningún tipo de soporte a Linux da bastante que pensar sobre esa empresa. Se están jugando una mala reputación (lo último que le interesa a cualquier empresa) y una empresa no se arriesga a eso si no hay una razón de peso detrás. Suelen ser empresas con fuertes lazos comerciales con M$ las únicas que hacen eso. Además, si no da ningún tipo de soporte ¿porque se molestan en meter tablas DSDT específicas que casualmente están corruptas?
5) Si aún después de haberles descubierto y pedirles educadamente que solucionen el problema lo único que se les ocurre contestar es que "nuestro producto esta certificado por M$" y "pruebelo con vista" entonces ya su desfachatez ralla en la provocación. Máxime cuando para apoyar su empecinamiento de que su producto cumple con el estandar ACPI lo único que se les ocurre decir es que si M$ lo certifica tiene que ser estándar. Hace falta tener mas jeta que espalda. Igual con el escandalo de OOXML esta gente se ha pensado que ISO es una filial más de M$ y que el M$ ha pasado a ser ahora el organismo certificador por excelencia.

Por todo esto y alguna otra cosilla menor que no pongo para no extenderme demasiado pensar siquiera remotamente que todo este asunto ha sido un accidente sin mala intención por parte de Foxconn me parece de una ingenuidad difícil de creer en una persona adulta. No tienes ninguna razón mínimamente coherente para sugerir siquiera que esto haya podido ser un accidente y exiges pruebas para afirmar lo contrario. El tipo de pruebas que podrían dejar aún mas claro este asunto serían por ejemplo grabaciones en vídeo de una entrevista entre un directivo de M$ y otro de Foxconn acordando que M$ les da la etiquetita de "vista certified" a cambio de que lo hagan incompatible en Linux, o un vídeo de un directivo de foxconn dando instrucciones a un programador de bios para que meta unas tablas DSDT corruptas. Lamentablemente esas cosas solo se graban en peliculas de espias. En la vida real a menudo nadie se entera de esos tejemanejes. Por su puesto nunca hay pruebas irrefutables de ello porque esta gente no son tontos y los chanchullos se hacen de palabra, en privado y sin