• Del autor
  • Principios y algoritmos de concurrencia

Ricardo Galli, de software

~ De software libre, internet, legales

Ricardo Galli, de software

Archivos de etiqueta: linux

Por qué el núcleo Windows NT es peor que Linux: problemas sociales y de incentivos

11 sábado May 2013

Posted by gallir in desarrollo, programación

≈ 39 comentarios

Etiquetas

incentivos, kernel, linux, microsoft

En el artículo «I Contribute to the Windows Kernel. We Are Slower Than Other Operating Systems. Here Is Why.» se transcribe el comentario (luego eliminado) de un anónimo que se identificó y aportó pruebas como programador de Microsoft. En el comentario explica su opinión de por qué el núcleo Windows NT (el que se usa en todos los siguientes, 2000,XP, Vista, 7 y 8). Más allá de las anécdotas, y de que es una visión parcial y subjetiva, es muy interesante lo que desvela. En pocas palabras, la carencia de calidad y eficiencia son más un problema social más que técnico:

  • Falta de incentivos, o incentivos equivocados.
  • Dar mayor importancia a cumplir los planes establecidos sin desviaciones que aceptar cambios no planificados para mejorar la calidad del producto.
  • La carencia de programadores con experiencia, o el exceso de programadores recién graduados.

Es muy interesante la lectura, desvela los problemas de gestionar y programar sistemas complejos. Cualquier economista explicaría que hay que establecer los incentivos adecuados, sobre todo en entornos como la programación donde se trata de desarrollar sistemas tan complejos que tienen más componentes que el avión más grande del mundo y tantas formas de interacción -muchas órdenes de magnitud superior a cualquier sistema de componentes físicos- que escapan a nuestra capacidad de comprensión.

Ese incapacidad cognitiva de siquiera conocer la magnitud de la complejidad hace que sea imposible hacer un diseño inicial que tenga en cuenta todas las interacciones y casos. Por ello es imposible asegurar que no haya bugs y, por supuesto, que el sistema desarrollado sea eficiente. Eso requiere, tal como ya lo contaba Brooks en los ’70, el «mantenimiento» de los programas, que consiste en la mayor parte del ciclo de vida del software. Ese mantenimiento no consiste sólo en arreglar problemas, también en mejorar el código (para controlar mejor la creciente complejidad) y la eficiencia.

En el núcleo Linux es un buen ejemplo en ese sentido: se usaron las ideas y principios de modularidad de Unix, es software libre con todo a la vista del público (el código, y las discusiones técnicas), la gestión de Linus Torvalds (y los responsables de módulos) han creado una comunidad muy meritocrática (talk is cheap, show me the code) donde el respeto a los clientes (desarrolladores de programas a nivel usuario) es prioritaria, revisión de pares, se debate con dureza cada propuesta y cambio, se critica duro al que presenta propuestas malas, pero también se reconoce y halaga al que consigue mejorar funcionalidades ya establecidas y maduras.

Esa es una de las principales diferencias que se extraen del artículo.

En Microsoft [presuntamente] no funciona así, los responsables de módulos tienen más razones para rechazar mejoras que para introducirlas,  los Project Managers no ven con buenos ojos que haya desvíos del plan de trabajo, los grupos de testing no quieren saber nada de volver a probar y adaptar unidades de verificación. Es decir, no hay incentivos para mejorar las funcionalidades existentes y que no sean prioritarias en la empresa. En consecuencia, la eficiencia de sistemas con modelos de desarrollo más similares a Linux acaban siendo superior, sobre todo en las áreas y funcionalidades ya maduras.

Otro de los problemas que se menciona es el abandono de los programadores senior y la contratación de nuevos que acaban de salir de la universidad. Estos no son capaces de valorar la complejidad del sistema, ni de conocer por qué fueron tomadas las decisiones técnicas anteriores.

Este último punto es interesante, sobre todo en un gremio -y en un país- donde se valora poco la experiencia de los programadores. Salvo las empresas punteras en desarrollo de software equiparan los [excelentes] salarios de los programadores con la de los gestores (no es nada raro que un programador senior de Google cobre 150.000€). Ocurre en muchos países, pero sobre todo en España, tener 40 años y seguir programando parece más un fracaso profesional que el éxito de un programador apasionado.

Tampoco es culpa de las «empresas» o el «mercado», desde la propia universidad solemos transmitir el mensaje equivocado:

Un ingeniero informático no programa, dirige proyectos

Ese mantra lo oí muchas veces y los alumnos lo escuchan frecuentemente en clases. El error es múltiple, por un lado transmitimos la idea que un ingeniero graduado sabe todo lo necesario, que no hace falta experiencia en programación, y que programar es de pringaos.

Además de lo mejorable que es nuestra educación, y como últimamente me está apasionando el tema de gestión de desarrollo de software, del comentario me han quedado algunas cosas más claras:

  • Los planes y metodologías son herramientas, no un fin en sí mismo, como terminan de creerse sus responsables y evangelistas.
  • Se deben crear incentivos, no sólo monetarios, para motivar a que los programadores desarrollen mejoras para cualquier parte del sistema. Esto implica, entre otras cosas, descontar un porcentaje de los recursos disponibles para implementar nuevas funcionalidades y reservarlos para mejora de la «calidad global».
  • Valorar debidamente a los programadores experimentados, que empieza por reconocer -sobre todo entre nosotros mismos- las carencias inevitables de un recién graduado, y la rápida evolución de la ciencia y tecnologías informáticas.
  • Debemos empezar a esforzarnos en formar a profesionales cuyo objetivo sean jubilarse como programadores, no sólo un camino intermedio para lograr mejores salarios en otros puestos de gestión o dirección.
  • Sobre todo, reconocer que tenemos problemas cognitivos para visualizar mental y adecuadamente la enorme complejidad de los grandes sistemas informáticos.

Android, iOS, tiempos de respuestas y por qué nada es gratis en sistemas informáticos

07 miércoles Dic 2011

Posted by gallir in desarrollo, programación

≈ 89 comentarios

Etiquetas

android, gestión de memoria, ios, linux, scheduler

Hace unas pocas horas escribí esta respuesta sobre Por qué iOS es más fluido que Android (con buen criterio, eliminaron la entrada). Obviamente, por cuestiones de longitud y la «respuesta rápida» que requiere un comentario, no me quedó todo lo completo que requiere el tema. Lo que me gustaría explicar daría para muchas horas de charlas. De hecho, enseño estos temas en mi asignatura de Sistemas Operativos (II), dedico al menos unas 12 hs de clase, y aún así no entramos en muchos detalles importantes. Pero intentaré resumirlo en este apunte, fundamentalmente para que se entiendan los problemas de arquitectura, y de cómo toda decisión que se tome en una arquitectura, lenguaje o programa tiene implicaciones positivas y negativas, siempre.

Sigue leyendo →

De software libre…

11 jueves Jun 2009

Posted by gallir in cultura, software libre

≈ 19 comentarios

Etiquetas

colaboración, linux, software libre

Escribo poco en el blog, como comenté antes le doy prioridad a cosas que son más fructíferas y divertidas que estar en constante discusiones en el blog: la familia, mi trabajo de investigación [*], programar cosas del Menéame… y en estas épocas corregir prácticas y examenes como loco. Pero además de ello hace tiempo no escribo sobre software libre.

La verdad es que se me secaron las ideas sobre el tema. Todo lo importante está dicho, el que tenía deseos de aprender ya lo sabe, los demás no habrá forma de explicarlos. No saldrán del eslogan «talibán».

Pero en la conferencia de Carlos Almeida alguien del público comentó que era una pena que no hubiésemos hablado de software libre. Mi respuesta fue que ojalá el tema de la cultura, libre o encerrada, estuviese en la misma situación que el software libre:

  • Se produce mucho software que se libera y se utiliza por individuos y empresas.
  • Los programadores de software libre no reclaman que el gobierno les subsidie o les asegure ingresos a pesar que el númer de usuarios de software libre es infinitamente mayor de los que ven pelis españolas (sólo contando a usuarios de Firefox o los GNU/Linux en móviles y empotrados ya se gana por goleada).
  • Se produce y divulga mucho conocimiento útil y de efectos prácticos inmediatos.
  • etc. etc.
  • Ganan dinero.

Pero lo mi respuesta fue que hace 15 años hubiese sido imposible imaginar que grandes corporaciones, competidoras entre sí, trabajasen de forma conjunta para desarrollar software que es fundamental para sus negocios, y que además lo liberasen.

A un no iniciado eso le sonará a utópico o exageración, pero a los hechos me remitiré. Cogiendo una pequeña parta de las cosas nuevas cool que se implementaron en la última versión del núcleo Linux (obvío las contribuciones personales):

  • Contributor: NTT Labs (Nippon Telegraph and Telephone Corporation)
  • Contributor: www.openfabrics.org (Particularly, Oracle)
  • Contributor: Intel
  • Contributor: Atheros
  • Contributor: Red Hat
  • Contributor: Panasas
  • Contributors: Panasas, Netapp and IBM
  • Contributor: Red Hat
  • Contributor: NTT DATA CORPORATION
  • Contributor: Michal Simek, with donations from PetaLogix and Xilinx
  • Contributor: IBM

Luego se se ven los detalles de los commit de cada cambio se podrán ver las firmas de empleados de casi todas las empreas inportantes de hardware y software. Es casi un Who is who en informática.

Ojalá la «industria» cultural estuviese en la misma situación. El equivalente sería ver a los majors colaborando entre ellos, con productoras pequeñas y músicos de todo tipo, liberando todo con licencias libres, promoviendo el remix, con páginas webs para que cualquiera se baje la última versión de cualquier obra, organizando conferencias y conciertos para explicar el porqué es bueno compartir, sin SGAEs ni reclamando subvenciones y cánones, y además ganando dinero en el proceso.

Sí, quizás nunca lleguemos a esa situación. Pero si IBM, Oracle o Intel ya lo han tomado como parte natural de sus negocios no hay que perder las esperanzas.

Claro que la gente que suele dirigir empresas como IBM Oracle o Intel suelen ser muy listas, con doctorados o másters de universidades prestigiosas, y una larga experiencia en la empresa y el área. Aquí en cambio cualquier guionista de pelis subvencionadas puede llegar a ser ministro sólo por haber repetido una y otra vez lo de «la piratería de Internet nos está matando». Vaya si hay diferencias.

Tant de bo! que a la cultura le pase lo que al software libre. A nadie se le hubiese ocurrido leyes hadopis y estupideces similares.

PS: Sí,  hay contradicciones, doble juego y cosas no tan bonitas, pero cada año mejora la colaboración e igualmente –en el peor de los casos– no hay color en la comparación con la «industria cultural», que son peores que el temido y odiado Big Brother de IBM en los 60-70.

[*] Estoy metido en dos cosas. Una que desarrollaré poco a poco y cuya idea surgió de la chapucilla rápida que hice para sindemocracia.net, técnicas de clustering para organizar noticias a partir de seguimineto en sitios sociales y de noticias a partir de palabras claves. La otra es muyteórica, coloreado de grafos con algoritmos polinomiales. El coloreado de grafos es un problema NP-Completo, es decir, puede ser resuelto por una máquina de Turing no determinística y se puede verificar la solución en tiempos polinomiales,  pero no se conoce un algoritmo óptimo polinomial para hallar la solución. Para encontrar soluciones se usan heurísticas, por ejemplo ordenar los nodos y asignar colores con el [simple] algoritmo greedy. Ya desarrollé un algoritmo de ordenamiento que es no sufre los problemas de los conocidos –fundamentalmente con «prismas»– y que encuentra soluciones con menos colores, pero la diferencia es pequeña para que sea importante. Por ejemplo para grafos –de bases de datos de «grafos reales»– de 1.000 nodos y con 60 colores en su solución óptima asigna 121 colores, tres menos que el conocido smallest-last. Ahora estoy trabajando con heurísticas un poco más complejas, pero todavía sencillas y de tiempos de ejecución polinomiales, basadas en la freucencia de colores usados y las restricciones de nodos previos como «grados de libertad» para la asignación de los siguientes.

Comprar el libro

Principios y algoritmos de concurrencia

gallir@twitter

  • RT @jlhortelano: Siempre ha sido un manipulador. Pero encima es muy tonto si trata de colar esta foto de Septiembre de 2021, época donde no… 12 hours ago
  • ¿Qué? Por algo se re-empieza. https://t.co/dJ16CcMu9J 21 hours ago
  • "sexeafectives" twitter.com/La_Directa/sta… https://t.co/or6E5bOLvT 1 day ago
  • RT @IrvingGatell: 1. No, no se va a armar la Tercera Guerra Mundial. Pero el asunto sí se puso candente. Todo parece indicar que #Iran ha s… 1 day ago
Follow @gallir

RSS Notas recientes

  • Se ha producido un error; es probable que la fuente esté fuera de servicio. Vuelve a intentarlo más tarde.

Archivos

Comentarios recientes

PM en Cuidado con las «clever soluti…
Me matan si no traba… en Cuando el periodismo cede el c…
surco en Cuando el periodismo cede el c…
pancho pérez (@lonch… en Cuando el periodismo cede el c…
Fernando en Cuando el periodismo cede el c…
@beoxman en Cuando el periodismo cede el c…
gallir en Cuando el periodismo cede el c…
Jan Smite en Cuando el periodismo cede el c…
Alejandro en Cuando el periodismo cede el c…
Galletor en Cuando el periodismo cede el c…

Meta

  • Registro
  • Acceder
  • Feed de entradas
  • Feed de comentarios
  • WordPress.com

Licencia

Creative Commons License
Esta obra está bajo una licencia de Creative Commons.

Blog de WordPress.com.

  • Seguir Siguiendo
    • Ricardo Galli, de software
    • Únete a 667 seguidores más
    • ¿Ya tienes una cuenta de WordPress.com? Accede ahora.
    • Ricardo Galli, de software
    • Personalizar
    • Seguir Siguiendo
    • Regístrate
    • Acceder
    • Denunciar este contenido
    • Ver sitio web en el Lector
    • Gestionar las suscripciones
    • Contraer esta barra