Dando la chapa

El que no llora no mama, está más claro que el agua.

Hace una semana un friki postea en los foros de Ubuntu que ha estado haciendo pruebas y ha llegado a la conclusión de que un modelo de placa base tiene código específico para no funcionar bien en Linux. Además no sigue un estandar que dice seguir. Total que se pone en contacto con el fabricante, le explica el problema y el fabricante por supuesto pasa de su culo 100 pueblos. El cruce de mails no tiene desperdicio:

*** Foxconn:

Dear Ryan:

This board was never certified for Linux. It is only certified for Vista. See URL below. So please test under Vista. Does this issue also occured under Vista or Winxp?

*** Friki:

I’ve taken the liberty of filing the report in kernel.org, Red Hat, and Canonical’s Ubuntu bug tracking systems, and posting the contents of my kernel error log on my blog, which is in the first several results if you Google search “Foxconn G33M” or “Foxconn G33M-s”, “Foxconn Linux”, etc, as well as prominently in other search formats, so hopefully this will save other people from a bad purchase, and hopefully kernel.org can work around your broken BIOS in 2.6.26, as I understand that kernel is more forgiving of poorly written BIOSes built for Windows.

I’ve already gotten several dozen hits on those pages, so you guys are only hurting yourselves in the long run, by using bad BIOS ROMs, as people like me are quite vocal when dealing with a bad product.

*** Foxconn:

Making idle treats is not going to solve anything. As already stated this model has not been certified under Linux nor supported.

As you are unhappy with the product- using a non-support operating system nor certified, please contact your reseller for a refund.

*** Friki:

Yeah, well, I allege that you guys thoroughly suck. Learn how to write a BIOS before you go selling hardware with falsified specs.

*** Foxconn:

Dear Ryan, Stop sending us these!!!

Total, que como no hay más cosas que alegren Slashdot por las mañanas, allí que apareció claro: MoBo Manufacturer Foxconn Refuses To Support Linux.

Entonces a algún ingeniero de la compañía se le cae el sandwich de la boca una mañana cuando se entera por Slashdot de que un cliente suyo con Linux tiene problemas y está montando el 2 de Mayo en Internet. Y tiene toda la pinta de que el monkey de soporte para lo único que le pagan es para leer lo que pone en la etiqueta: “no certificado para Linux, funciona con Microsoft” en lugar de preocuparse de mandarle un mail al ingeniero a ver qué se puede hacer.

Resultado: una semana más tarde problema resuelto. El ingeniero sin sandwich se va a los foros de Ubuntu donde empezó todo y pide perdon:

And here I want to say Thank you to all the linux enthusiasts. From this case, Ryan and all of you gave us a lesson. And also as our plan, we will take more time on Linux OS testing.

Me quedo con este comentario de Slashdot:

So, you think it would have been fixed if there had not been angry, almost rabid, users? You know, the ones you refer to as “crazy zealots”?

I don’t believe so. I believe the issue would have been ignored, and Linux would have been patched in some obscene manner to “work around” the issue. Giving a bad reputation to Linux; “it doesn’t work — what kind of fucking shit is THIS?”. Hurting the reputations of many developers.

Sometimes, the only sane response is to be angry and rabid.

Bienvenido al club. Resulta que por lo menos Hardy tiene un problema con el Network Manager y las DNS. Básicamente las configuras y al reiniciar se pierden. Pero es que a mi me ha pasado hasta sin reiniciar, en la misma sesión de repente se le va y te quedas sin navegar.

El bug está más que reportado (Custom DNS settings lost on boot) pero está marcado como baja prioridad y no está arreglado. Solución: Enable OpenDNS: Unix/Linux Ubuntu, el punto 2 explica cómo evitar que se pierdan las DNS.

Y ya aprovecho para hablar de OpenDNS. Aunque muchos ya lo sabréis, los servidores de DNS son esas bonitas bases de datos que establecen la relación entre una IP (72.14.207.99) con un nombre de dominio (google.com). Normalmente la teleco que te de servicio te proporciona sus propias DNS, pero como siempre no lo hacen gratis. Hace no mucho YA.com decidió romper el protocolo DNS y redirigir el tráfico incorrecto a una página propia de ayuda en lugar de devolver el error correspondiente al navegador. Clásico.

Pues como siempre los frikis al rescate. OpenDNS da ese servicio gratis y con bastantes opciones (como filtros para contenido adulto) a quien le interese. Échale un ojo a cómo empezar.

O no :)

Este post es simplemente un recordatorio personal al que redirigir a todos los fanboys de Apple cuando vengan con el cuento del “Just works” y “Apple le da 100 patadas a Windows”.

Decían en Kriptópolis hace poco a cuento de los bugs de Firefox que tratar de tapar los problemas que tiene no ayuda precisamente, es mucho más constructivo reconocer los errores para poder arreglarlos. Bueno, pues los hay que todavía eso no lo tienen claro. Lo gracioso es que no son sólo los de márketing de Apple sino algunos de sus usuarios. Será que tienen acciones o algo así.

Desde la salida de Leopard me ha dado por guardarme enlaces a gente comentando pequeños problemas. Aquí va una muestra:

- MacBookPros que no arrancan después de actualizar.
- Discos duros que fallan 20 o 30 veces más de lo normal.
- El firewall no funciona e incluso deshabilita si lo tenías con Tiger.
- Reintroducción de bugs que habían sido corregidos en Tiger. En este caso AppleMail y los jpgs.
- El mayor evangelizador de Apple que yo me he encontrado. Preguntadle sobre el teclado que se bloquea o su experiencia con Leopard.
- Y para el final un artículo devastador de PC Magazine: Leopard is the New Vista.

Vaya o sea que Apple no “Just works”… Vamos, como Vista o… Ubuntu. Porque Ubuntu también tiene sus cositas, claro. La diferencia está en cómo se afrontan esos problemas. En el caso de Ubuntu, un listado público de bugs en Launchpad y una release que se va a dedicar exclusivamente a solucionar bugs y mejorar la estabilidad del sistema. En el caso de Apple, la respuesta es negar la evidencia todo lo que pueden hasta que el clamor es tal que no les quedan más cojones que aceptarlo públicamente.

En fin, que en todos lados cuecen habas y que los anuncios de “I’m a mac and I’m a PC” son muy graciosos pero más vale que aprieten el culo.

Andaba buscando en Google el listado de parámetros que acepta el compilador de AS3 cuando he llegado a Adobe Bug System. La verdad es que me he quedado o_O porque no lo he leído por ninguna parte pero tampoco tiene ninguna pinta de que sea algo que se les ha pasado.

Curioso ver como el DataGrid tiene 50 bugs abiertos o ver los bugs del player 10.

No sé, creo que voy a perder un rato el tiempo utilizando la búsqueda a ver qué encuentro.

Por cierto, un buen listado de los parámetros del compilador en Senocular.

¿Qué? ¿Que no se puede controlar una central nuclear con Flash y AS3? Pues vaya kk de lenguaje. Me voy a Java entonces. ¡Ups! Tampoco:

You acknowledge that Licensed Software is not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility

De la licencia de Java. Bueno pues ¿entonces con qué me monto mi central nuclear en casa? Nada de software, hay que hacerlo con interruptores:

Commercial nuclear reactors, at least in the US, are controlled via relays, not integrated circuits. The control room for a nuclear plant looks a lot like the array of switches and dials on the spacecraft in the movie Apollo 13, scaled up to fill a large room. You might see some more modern technology used for recording or monitoring purposes, but the fundamental operations are not based on anything as unreliable as software.

Si ya decía yo que tenemos demasiados bugs.

Hace tiempo que le doy vueltas a la idea de que el software en general tiene tantos bugs porque no se paga suficiente por ello. Es decir, un neurocirujano comete un error y el paciente muere. Un ingeniero comete un error y se cae un puente.

Sin embargo parece que estamos más que acostumbrados a los errores de software. Normalmente porque sólo generan algunas molestias, pero lo cierto es que cada vez hay menos cosas que no estén controladas por ordenadores, incluídas tareas críticas en las que un error puede significar pérdidas de miles de millones y vidas humanas.

Ahora pongámonos en el caso extremo. Supongamos que un fallo de software supusiera por ley la muerte del programador. Responsabilidad extrema. Se iban a acabar las alphas, las betas, y todo lo que no fuera software perfectamente probado y reprobado en todas las condiciones posibles. El número de bugs bajaría a casi 0. Pero claro, seguramente el número de programadores también bajaría mucho porque ¿quién quiere jugarse la vida en su trabajo? La parte buena sería que, al bajar la oferta de programadores, los sueldos subirían a la misma velocidad que la demanda. Se acabaron los picadores mileuristas y se nos consideraría poco menos que deportistas extremos, seguro que vendría Red Bull a patrocinarnos, tendríamos cláusula de rescisión y el PC World desbancaría al Marca en la lista de publicaciones más vendidas.

Y después de la tontería, el pensamiento profundo: parece que para que haya abundancia de picadores de software, las responsabilidades por lo errores tienen que ser bajas. Ummmm…. ¿De verdad es esto así? Desde luego es completamente cierto que hay mucho movimiento dedicado a mejorar la calidad del software: gestión de proyectos, control de versiones, unit testing, departamentos de calidad, validadores…. Pero tampoco es menos cierto que hay aplicaciones críticas que fallan. Y mucho.

Y cuando estaba escribiendo este post, me encuentro en VivaLinux con Red Hat Enterprise Linux 5, si lo hacemos, lo soportamos. Red Hat viene a decir, por escrito, sin letra pequeña y en sólo una página que su soporte abarca instalación, uso del producto, configuración, diagnóstico, y corrección de errores. ¿No estamos demasiado acostumbrados a aceptar sin pestañear en un click que el software que instalamos -libre o no- no se hace responsable de los daños que pueda causar?

[ACTUALIZACION]

Cómo estará la cosa, que la Free Software Foundation y Kriptópolis dicen que votar debería hacerse en papel:

Fíjense, sin embargo, en que votar es un caso muy especial. Sólo porque el software dentro de un ordenador sea libre no significa que se pueda confiar en el ordenador para votar. Nosotros creemos que no se puede confiar en los ordenadores para votar. Votar debería hacerse en papel.

Madre cómo estamos…

[/ACTUALIZACION]

Igual es un bug de estos que conoce todo el mundo por lo básico que es, pero yo no lo conocía. Bueno, por razones que no vienen al caso, tenía que hacer dos llamadas seguidas a JavaScript desde Flash. Y además no podía utilizar ExternalInterface porque el player tiene que ser 6.

Símplemente prueba esto:

getURL("javascript:alert('uno');");
getURL("javascript:alert('dos');");

En FF llegan las 2 llamadas, en IE, NO. Sólo llega la segunda. Buscando una forma de solucionarlo, fuimos a la chapuza de retrasar la segunda llamada con setInterval. En la pruebas que hicimos un intervalo de 200 milisegundos es suficiente. He de decir que no es algo que recomiende, yo creo que no es estable 100%.

Y como el parche no es estable 100%, nos pasamos a ExternalInterface y lo solucionamos. Pero me guardo para la próxima una prueba de concepto de uso “intensivo” de ExternalInterface que, otra vez, funciona en FF correctamente pero no en IE.

La alegre vida del programador Flash.

pd: no es un problema específico de alert porque interrumpa el flujo de JS o algo así. He probado llamando a una función “normal” y tampoco resulta. Tampoco creo que la version de IE o del player cambie el resultado.