Ingeniería, Ciencia, Arte y Negocio

La importancia de programar eficientemente. Software crítico.

No se necesita un gran arquitecto para diseñar una casita de perro, ni un gran escritor para hacer una nota que ponga “vuelvo en 5 minutos”. La cosa cambia cuando lo que queremos es diseñar un edificio, o queremos escribir una gran novela. Lo mismo ocurre cuando se trata de diseñar y escribir software.

Depende mucho del software que pretendas hacer, y del entorno en el que quieras ejecutarlo, pero no se puede pretender construir un edificio moderno y complejo, con programadores a los que se les da bien construir casitas de perro.

Existe cierta tendencia a pensar que el desarrollo de software es algo irrelevante y que lo importante no es tanto la implementación como la idea en sí misma. Bueno, pues siento mucho traerte al mundo real, pero es más bien todo lo contrario. Una idea, no llevada bien a la práctica, no sirve de nada. Un ejemplo claro lo tenemos en Apple. Sus productos no introdujeron nada nuevo salvo la forma en como implementaron la idea. Cuando sacaron el iPod ya existían numerosos reproductores de mp3, sin embargo el iPod arrasó y lo mismo ocurrió con el iPhone. Apple no suele generar nuevos conceptos si no que rediseña la implementación de conceptos ya existentes.

Una idea mal implementada, es una mala idea.

Para que no se dé nadie por aludido, no voy a nombrar casos concretos, pero durante mis años en la industria del software, he visto grandes ideas sobre el papel que al ser implementado de manera burda la idea ha fracasado. Siento volver sobre el paralelismo, pero puedes imaginar un edificio espectacular pero si al ser implementado, haces mal los planos, y contrata a albañiles malos, de nada sirve si se derrumba.

Si se te ocurre un algoritmo que consigue converger a una solución que nos va a resolver un problema pero, la implementación del algoritmo es tan burda que tardamos días en encontrar la solución, puede que ya ni siquiera tenga sentido, y por lo tanto tu idea no valga de nada.

En la Fórmula 1 se contratan a los mejores ingenieros del mundo para conseguir arrancar unos milisegundos mejorando la aerodinámica del coche, sin embargo en la construcción del software basta con contratar a programadores de perfil bajo pensando que puedan llegar a los mismos resultados. Hago hincapié en que nada de esto es aplicable a tu caso, si tú a lo que te dedicas, es a vender casitas de perro.

Por supuesto, no necesitas a grandes ingenieros de software para software poco crítico, pero si de tu software depende de forma directa o indirecta la vida de las personas, entonces deberías replantearte la calidad de tus ingenieros de software. El software que va en las centralitas de los coches, el que gestiona el funcionamiento de las redes de comunicaciones, el de los teléfonos móviles, y cualquier otro tipo de software de control industrial debería estar diseñado e implementado por ingenieros de software de perfil alto. Es mucho más costoso el desastre que se puede producir por el fallo de este tipo de software que el coste que supone la contratación de buenos profesionales. No es admisible que por un fallo de programación, 1 millón de personas se puedan quedar incomunicados al no poder acceder a la red de telefonía movil. O que un coche no funcione como se espera cuando se pise el freno. O que un ascensor no dispare sus sistemas de seguridad si se produce una situación de emergencia.

Crítica sin sentido a Tanenbaum

A pesar de que llevo ya un tiempo sin querer entrar a trapo en debates estériles, el otro día por casualidad me encontré con una editorial donde se criticaba un artículo escrito por Andrew W. Tanenbaum, que para los que no sepan quien es, podeis echar un ojo a lo que dicen de él en la Wikipedia. También podeis tener una idea de sus conocimientos sobre sistemas operativos si visitais la web donde aparecen sus publicaciones.

Si visitais esos enlaces podreis deducir que este señor algo de sistemas operativos sabe. Sus libros son una referencia mundial en todas las universidades para el estudio de sistemas operativos en las facultades de informática. No sé que habrá estudiado quien lo critíca, pero si ha estudiado informática seguro que le suenan sus libros.

Crear un sistema operativo es algo complejo. No es lo mismo crear un sistema operativo que usarlo. Y no se aprende  sistemas operativos por muchas distribuciones de linux que te instales y por mucho que juegues con el apt-get o con el rpmfind.  Eso también debería quedar claro.

Sin embargo un tal Paul C. Brown, director de una revista de Linux, en su editorial, dice cosas como “no sé de que árbol se habrá caido”. En realidad como veremos más adelante, hay muchas cosas que tampoco sabe.

El artículo criticado de Andrew está accesible en este enlace:

http://www.linux-magazine.es/issue/46/087-088TanenbaumLM46.pdf

Este señor, que tan tonto le parece al emitente Paul C. Brown, ha sido receptor de algunos importantes premios. Entre ellos tenemos los siguientes:

• En 2007 recibe la IEEE James H. Mulligan, Jr. Education Medal.
• En 2004 miembro de la Real Academia Holandesa de Artes y Ciencias.
• En 2003 ganador del premio de TAA McGuffey
• En 2002 ganador del premio de Excelencia de Libro de texto Texty
• En 1997 ganador de ACM CSE Contribuciones Excepcionales a Premio de Educación de Ciencias Informáticas
• En 1994 ganador de Karl V. Karlstrom ACM Premio de Educador Excepcional
• Premio al trabajo distinguido, 10º Simposio ACM a Principios de Sistema Operativo
• Puesto en una lista en Quién es Quien en el Mundo

He intentado encontrar en internet, los premios recibidos en esta materia por Paul C. Brown, pero no tuve suerte.

Tanunbaum además, es  el creador de Minix. Un sistema operativo que fue la inspiración de Linus Torvals para la creación de Linux. Por lo tanto, sin Minix no hubiera existido, es muy muy posible que Linux tampoco. Así que ya ha hecho algo importantes para los seguidores de Linux entre los que me incluyo.

Sin embargo, Paul C. Brown hace algunos comentarios en su editorial con los que no estoy de acuerdo. Me gustaría comentar, sin que sirva de precedente, estos comentarios. Como he dicho anteriormente, estoy cansado de leer y oir comentarios que carecen de sentido, y mucho más cansado aún de comentarlas. Pero en esta ocasión lo voy a hacer porque me aprece injusto e incluso peligroso que un comunicador de tecnología desprecie de esta manera a un científico de la talla de Tanenbaum.

Voy a reproducir ciertas partes de editorial donde lo critíca. Supongo que teniendo en cuenta que está disponible para todo el público en esta url, no creo que suponga un problema legal, ya que además cito la fuente.

Crítica: http://www.linux-magazine.es/issue/46/003-003EditorialLM46.pdf

El título de la editorial ya promete:

Perdió el bus, doctor…

Quizás Paul C. Brown piensa que todo el mundo quiere coger el mismo bus que a él le gustaría, pero lamento comunicarle que no todos van al mismo sitio. Es muy posible que el Dr Tanenbaum no esperara ese bus. Y digo lo de Doctor porque aunque en el título de la editorial se use con un tono sarcástico, Andrew, a diferencia de Paul es Doctor. Y bajo mi punto de vista eso le da de entrada, una mayor autoridad en esta materia.

La cuestión es que Tanenbaum vuelve a la carga con la versión 3 de su propio SO y quiere darlo a conocer. Dispuestos como habitualmente a dar cancha a proyectos semejantes, nos sentimos honrados de que nos haya elegido, aunque siempre nos quede la duda de si a estas alturas tendrá alguna relevancia.

Yo discrepo. De hecho, estoy seguro que a todas las personas interesadas en los sistemas operativos, están encantadas de leer la opinión del Dr. Tanenbaum.

Si se revisa la lista de software que se puede ejecutar en MINIX 3, es más bien exigua. No hay nada en el área de administradores de ventanas avanzados (ni básicos, por lo que se ve), por tanto todas las herramientas de productividad, para juegos y de conectividad personal a las que el usuario está acostumbrado quedan fuera. Incluso las herramientas de la línea de comandos son pocas y desfasadas. Parece, doctor Tanenbaum, que a estas alturas de milenio, ha perdido usted el bus.

Actualmente el porcentaje de usuarios de Linux es del 1%. Esto es debido a la introducción de Linux en los dispositivos móviles y en otros dispositivos embebidos. Dispositivos que no necesitan todas esas aplicaciones de las que habla ud.  Seguro que Tanenbaum no está pensando en un sistema operativo para jugar al Quake.

Pero lo de la falta de aplicaciones era algo que se le achacaba a Linux en sus primeros años, algo que se utilizaba como argumento, incluso aún hoy, para evitar que usuarios migrasen, por ejemplo, de Windows a Linux. Pero por favor, recordad lo que ha costado llegar hasta aquí y todo el camino que nos queda por recorrer. Así que, antes de que alguien se lance a portar Totem a Minix:Que. Nadie. Mueva. Ficha.
No derrochemos esfuerzos a menos que estemos muy seguros de que va a valer la pena.

Menos mal que los desarrolladores de Linux como sistema operativo y de los desarrolladores de linux en un sentido más amplio, como los desarrolladores de KDE, Gnome, y el resto de aplicaciones que hacen que linux sea hoy lo que es, no pensaban como el señor Paul. Si hubieran pensado así, hubieran dicho…, “mejor nos dedicamos a hacer aplicaciones para windows en vez de mover ficha en favor de linux” Que teme el Sr. Paul?, que haya un Minix-Magazine que le haga la competencia? Sr. Paul, permita al resto de los mortales decidir que proyectos merecen la pena y cuales no. Que cada uno dedique sus esfuerzos a lo que considere oportuno.

Según Tanenbaum, lo que más le importa a un usuario (y menciona a una niña de 12 años y a su abuelito como perfiles
de usuarios) es que su sistema funcione todo el tiempo. No sé de qué árbol habrá caido últimamente el buen doctor, pero de ser cierto, Microsoft y todas las empresas de antivirus del mundo serían hoy en día escombros calcinados a lo largo de la costa oeste de los EE.UU.

De verdad Paul, desea ud. que se le explique por qué productos de baja calidad triunfan? Ha oido hablar de la falta de opciones?, de los departamentos de marketing?, de los intereses políticos?. De verdad cree ud. que windows esta en las universidades por su calidad? No se Sr. Paul de que árbol se habrá caido ud. para hacer ese tipo de silogismos.

A mi desde luego, cuando tenía 12 años, queria que las cosas funcionaran, y cuando sea abuelo, seguiré queriendo lo mismo. Se ha dado cuenta ud. que además de Windows y Linux, hay otros sistemas operativos..? Sabe lo que llevan las centralitas de los coches? y los aviones?, y los telefonos? Ha oido hablar ud. de Android? de Symbian?. Su mundo es Windows/Linux, pero su mundo no es real.

Entonces, el motivo de que “le damos a los usuarios lo que piden” lo hemos de tachar de la ecuación, porque es evidente que Tanenbaum no tiene ni idea de lo que es eso.

Bueno, yo creo que Tanenbaum si sabe perfectamente lo que un usuario de un sistema desea. Y es que funcione todo el tiempo. Asi que yo no puedo estar más de acuerdo con él.

Parece ser que MINIX 3 es lo más, perfecto en todos los detalles y comprobado matemáticamente sin errores. Tengo dos problemas con eso: (1) sacar código del kernel (o no introducirlo) para pasarlo al espacio de usuario, alegando que se decrementan los errores graves, es un poco… cómo decirlo suavemente… ¡Ah, sí! MENTIRA. Lo único que en realidad estás haciendo es mover los errores de un sitio a otro.

Pero que osada es la ignorancia!!!. Esta afirmación que ud. hace en su crítica, ummm como decirlo suavemente, ¡Ah si! ES MENTIRA. Primero porque un fallo a nivel de usuario no cuelga el sistema operativo, y esto hace que aunque las X se cuelguen, se puede acceder desde otro terminar y tomar el control. También es muy util para que otro usuario conectado con otra cuenta no note este problema, mientras que si el fallo es un Kernel Panic… amigo mio!! eso jode a todos. Ya se que ud. no quiere consejos, pero le vendría bien, antes de hacer este tipo de afirmaciones, leer al menos uno de los libros de Tanenbaum. Eso le dará culturilla sobre este tema para no meter tantas veces la pata en tan pocas lineas.

Pero, a pesar de su potencia y versatilidad, las máquinas de hoy en día siguen estando polarizadas en dos roles muy concretos: las hay que sirven de terminales cliente para usuarios finales y las hay que sirven de servidores.

Esto es mentira también. Si yo le pregunto cual es el procesador más extendido en el mundo, seguramente me dirá que Intel, o quizás AMD, sin embargo, sabe ud. cual es el más común? ARM!. Y eso? pues porque hay un ARM en casi todos los móviles y en casi todas las PDAs. Donde por cierto, ni windows, ni linux es el sistema operativo mayoritario. Por lo tanto, esa polarización donde se supone que va a funcionar Minix, es de nuevo, en su mundo imaginario. Y que conste, que con esto no quiero decir que Minix solo pueda funcionar en esos entornos.

En el caso de cuelgues en este tipo de máquinas, lo normal es que se te quede frita la interfaz gráfica y el usuario tenga que reiniciarla o tenga que reiniciar todo el sistema si ha perdido el controltambién del teclado. Y ¿a que no sabes qué? Igualito, igualito pasaría con MINIX. Que el kernel estuviera en el sótano runnn, runnn, feliz y contento, pero preguntándose dónde han ido todas esas señales que le venían de las plantas superiores, ¡como que le va a dar igual a la niñita y al abuelo!

Bueno, la diferencia es que no tendría que bajar al sótano… Podría intentar explicárselo con más detalles pero seguro que si piensa sobre ello sabrá lo que quiero decir. Y eso sin quitar que, el hermano de esa chica, podría estar conectado a ese servidor que hay en el sótano y podría seguir trabajando. Si el error hubiera sido del kernel, … la cosa hubiera sido diferente. Asi que de “igualito, igualito, nada de nada” de nuevo se confirma su ignorancia sobre este tema. De nuevo Tanenbaum habla con más sentido que ud.

En el caso de máquinas servidores, pues estamos en las mismas. En Linux, si se te cuelga Apache, no afecta a Sendmail, ni a Bind, pero sigues teniendo que reiniciar Apache… exactamente igual que en MINIX.

Precisamente eso ocurre porque ese fallo del Apache es un fallo en el anillo del usuario y no del kernel.  Creo que tiene un problema de base un problemilla de concepto. Hablar de sistemas operativos sin saber de ellos, no es un juego facil. Mejor deje de jugar a eso.

Uno de los puntos de debate más intensos entre Tanenbaum y Torvalds versaba sobre el hecho de que MINIX no era libre.

Lease también la historia de Linux y entérese de como Linux llegó a ser software libre. Cree que su creador lo quiso hacer libre desde el principio… pues se equivoca. Leáse tambien lo que opina su creador del Free Software y del Open Source y por qué. El código fuente de MINIX siempre ha estado disponible… diga eso tambien, no era GPL, pero el código estaba accesible para cumplir con la mision para la que se diseñó y que fue como herramienta para enseñar a sus estudiantes de sistemas operativos.

Aparte de lo cuestionable moralmente de que un profesor universitario cobrase a sus alumnos por un SO didáctico de su propia invención.

Y? que problema hay con eso?. De hecho ni siquiera el software libre te prohibe pedir dinero por tu software. Además que alguien quiera cobrar por algo que ha hecho.. no se.. no me parece mal. Seguro que me dirá ud. que lo hizo en el tiempo de trabajo de la universidad donde cobra un sueldo bla bla bla… pues no me lo diga! y aprenda también como funcionan las Universidades.

Ya se que una editorial es una opinión. Considere tambien esta entrada del blog como una opinión donde yo me doy la libertad de escribir lo que me place,  “pa eso es mío”.

Atte.