Archivo

Archive for the ‘pijadas’ Category

La compleja coreografía porque presionaste la letra A

abril 29, 2014 19 comentarios

Tu teclado detectó que presionaste la letra A, sus chips lo codifican en un scancode, este código es convertido en un señales eléctricas que se transmitirán por el cable USB al controlador que está conectado a la placa del ordenador. Este controlador detecta las señales eléctricas, las reconstruye en números binarios que almacena en un área de memoria del dispositivo, a continuación genera una solicitud de interrupción (IRQ) que será transmitida al microprocesador.

Esta interrupción está codificada y se recibe en el procesador en unas pins especiales para ellas, cuando llega la generada por la tecla que presionaste el procesador decide a qué core o procesador enviar esa petición (enrutamiento de interrupciones). Éste interrumpe lo que estaba ejecutando en ese momento,  analiza el IRQ, accede a una tabla de interrupciones (que fue rellenada cuando el sistema operativo se inició) donde le indica la dirección de la rutina del kernel que debe ejecutar. Cambia los registros necesarios, posiblemente invalida (flush) las cache y TLB del proceso anterior, cambia el nivel de ejecución del procesador a uno de con más privilegios y pasa a ejecutar la dirección indicada en la tabla de interrupciones.

La rutina del núcleo del sistema operativo analiza los registros y llama al gestor del controlador USB, que puede acceder a la memoria del dispositivo vía instrucciones de E/S del procesaor para que copie los datos a la memoria RAM. También llamará al gestor específico de teclado por USB (lo más probable es que sea el usbhdi) que convierte el scancode original en un código de caracteres vía una tabla de conversión (o mapa del teclado).

Una vez realizada las operaciones de transferencia de datos desde el dispositivo, se llaman a las rutinas de E/S de caracteres del núcleo. Éstas analizan qué proceso es el que debe recibir esa entrada de teclado, si usas un GNU/Linux con interfaz gráfica el proceso es el servidor X (X.org), copian los datos al área de memoria de dicho proceso, lo desbloquean y llaman al scheduler para que decida qué proceso debe ejecutar a continuación.

Al desbloquearse el proceso, éste pasa de la lista de procesos bloqueado a la lista de procesos listos para ejecutar. Allí el servidor X competirá por el procesador con otros procesos, eventualmente será seleccionado por el scheduler, este procederá a preparar al procesador (o núcleo) para que lo ejecute (cambio de contexto o context switch), invalidará las caches del proceso anterior, preparará las tablas de páginas básicas, cambia el privilegio del procesador al de uno de proceso normal y finalmente transfiere el control al proceso X.

Éste continúa su ejecución desde la llamada epoll o select que hizo para recibir E/S, analiza los datos que le dejó el sistema operativo y decide que es un letra picada en el teclado (el editor de texto, o la terminal, o el navegador web….), analiza cuál era el proceso interactivo que tiene la ventana activa en ese momento, codifica el evento en el protocolo X11, y se lo envía a dicho proceso vía memoria compartido o socket UNIX.

Al enviar el mensaje a otro proceso, se llama otra vez a una rutina del sistema operativo en un proceso similar al IRQ inicial, pero esta vez iniciado por una instrucción especial (interrupción por software) que hace que el procesador la trate de forma similar, selecciona un procesador para que la trate, analiza el código de interrupción y los registros que dejó el programa, cambia a modo privilegiado y llama a la rutina del kernel que tratará esta interrupción (posiblemente las de UNIX socket).

Esta rutina mira en las tablas de sockets cuál es el proceso receptor (el editor, terminal, navegador…), copia los datos necesarios, desbloquea al proceso moviéndolo a la cola de listo para ejecutar y llama al scheduler.

Eventualmente el proceso que debe recibir esa letra A es seleccionado por el scheduler, pasa a ejecución, continúa su ejecución desde el select o epoll, analiza la entrada, decide que hay que mostrarlo en pantalla, codifica la información necesaria (caracter, tipo de letra, posición, color, etc.) y la envía nuevamente -mediante un mensaje en protocolo X11- al servidor X.

Se repite de nuevo el proceso, interrupción de software, llamada a una rutina del núcleo y desbloqueo del servidor X que eventualmente es ejecutado.

Éste analiza el mensaje, detecta que tiene que dibujar una letra en la pantalla y llama a sus rutinas de dibujo de fuentes TrueType. Estas rutinas recuperan la información de la fuente necesaria (consisten de puntos en 2D), aplican los fórmulas necesarias que definen cómo debe dibujarse en la pantalla y llaman a las rutinas de DRI del kernel que lo harán, vía ayuda del gestor de la placa gráfica, en un complicado procedimiento de sincronización entre el servidor X, el gestor de la placa y la propia placa gráfica (que es otro ordenador muy potente y complejo, con su propio “sistema operativo”).

La letra A es dibujada así en la memoria del back buffer de la tarjeta, también se dibujan las otras ventanas con complicadas combinaciones y copias (compositing) para intentar minimizar todo lo que hay que re-dibujar. Cuando el back buffer está completo, se notifica a la placa gráfica que lo intercambie con el front buffer (lo que se visualiza por la pantalla), ésta espera que llegue el momento justo de sincronización con el monitor (para que no parpadee con mezcla de imágenes de ambos buffers) y finalmente hace el cambio y puedes ver lo que esperabas:

La letra A

Esta maravillosa coreografía de sincronización y paso de información ocurre cada vez que presionas una tecla, o mueves el ratón un pixel, o se empieza a bajar una imagen de la web. Y no sólo en tu PC o Mac, ocurre lo mismo en tu teléfono móvil, tu router WiFi, tu lector de libros, o tu smartwatch.

Todo esto que acabo de explicar ya funcionaba prácticamente igual desde finales de los años 70. Explico estas interacciones y algoritmos en mis clases de sistema operativo desde hace más de 20 años, pero nunca deja de maravillarme al nivel de complejidad y sofisticación al que hemos llegado en pocas décadas de informática.

 

 

 

Una técnica útil para el programador solitario (o sea, yo)

abril 24, 2014 13 comentarios

No sé si os pasa a todos, yo creo que sí, pero tenía serios problemas de organización y productividad en el desarrollo de Menéame. Quizás sea un caso especial, es un sistema complejo:

  • software relativamente grande y soy básicamente el único programador responsable de todos los módulos,
  • diversidad de lenguajes, PHP para la web, Python para scripts y programas “off line”, Perl por herencia de hace años,
  • base de datos grande e imposible de hacer alteraciones de las tablas por el tamaño de las mismas (ya veremos con el MySQL 5.6),
  • mucha manipulación de datos en la base de datos,
  • interacciones complejas de usuarios,
  • muchos controles de entradas y acciones de usuarios “externos”,
  • los usuarios piden muchas modificaciones, correcciones y detectan bugs que ni se te pasaron por la cabeza que podían ocurrir,
  • cada vez que se implementa una nueva característica (cada vez más complejas), aparecen nuevos bugs y sobre todo, los usuarios demandan muchas modificaciones y ań nuevas características complementarias.

Con todo esto, a veces me ocurría que me bloqueaba porque no sabía por dónde comenzar, o que pasos seguir, o cuál era el trabajo pendiente, cuáles son importantes, cuáles son urgentes, y cuáles secundarios que pueden esperar hasta tener ese momento de inspiración. Soy bastante desorganizado, y odio profundamente usar programas (los tipos “gestión de tickets”) para esto. Ya demasiado tengo con ventanas de editores, consolas de administración y páginas de manuales para encima tener que estar buscando una ventana perdida para ir leyendo y apuntando lo que estoy haciendo.

Leer más…

“Particionado funcional” económico en Amazon RDS… y cachea todo ¡estúpido!

marzo 17, 2013 6 comentarios

El miércoles pasado di una charla de cómo tenemos Menéame en Amazon AWS. Iba a explicar, al final de la charla, un truco de “particionado” [ver nota al final] económico, pero que no pudo ser: me tocó vivir en directo una saturación de la base de datos, producida por el nombramiento del nuevo Papa. Ahora explico cuál es ese “truco” de “particionado” económico y sencillo que sirve para ahorrar costes en RDS, y luego qué pasó y cómo solucioné la saturación de una de las bases de datos (de allí la frase “cachea todo ¡estúpido!”, el estúpido soy yo ;) ).

La base de datos principal de Menéame está en MySQL sobre Amazon RDS, con Multi AZ, lo que significa que tenemos failback y failover over automático y desantendido si el master falla. Da mucha comodidad, pero también tiene su coste: se paga el doble (el tamaño que tenemos es el large).

Leer más…

Un par de bellezas de algoritmos distribuidos que deberías implementar tú mismo

marzo 16, 2013 2 comentarios

Antes de irme a acostar pensé: “En vez de escribir quejas o de temas políticos-sociales, ¿qué tweet puedo dejar sobre temas de programación que entusiasme y sirva de algo a un programador”. Lo hice, pero luego pensé, son tweets a las 2:30 de la madrugada, los leerán sólo un par de insomnes frikis que no salen de marcha un viernes. Así que mejor lo dejo en mi blog (no pondré ningún enlace, todo está en Internet y es fácil encontrarlo con los nombres).

Este año me tocó dar Programación Concurrente y Distribuida, por lo que tuve que dedicar tiempo no sólo a aprender los algoritmos, sino a estudiarlos en profundidad para poder explicarlos, responder a todas las preguntas posibles, y además diseñar las prácticas en laboratorio. Así, de tanto estudiarlos llegó un momento que dije ¡hostia, que guapo y simple es!. Me pasó con el algoritmo de Chandy-Lamport para “snapshots” de sistemas distribuidos.

El estado de un sistema distribuido en un momento dado es imposible de obtener, ni tiene sentido. Pero sí que tiene encontrar un “estado consistente”. Este estado se refiere a qué mensajes se enviaron desde cada nodo (u ordenador), y qué mensajes estaban en tránsito en cada arista (o canal de comunicación). Es lo que hace el algoritmo de Chandy-Lamport. Si estás flojo en algoritmos distribuidos, o no recuerdas, o piensas que es muy complicado, te recomiendo que lo implementes. Es una “belleza”, en muchos sentidos. Pero mejor que lo saborees tú mismo ;)

Alerta

Implementar y probar algoritmos distribuidos en un único ordenador suele ser un coñazo. Hay muchos sistemas, pero hay que aprenderlos. Yo encontré que lo mejor es un sistema de paso de mensajes distribuidos, pero usándolo desde un único ordenador. Creo que no hay sistema de mensajes más simple, y con librerías para casi todos los lenguajes, que el Beanstalkd. Te lo recomiendo. De paso aprendes los conceptos básicos de estos sistemas, si es que no lo sabes. Recomendación: que cada nodo tenga un canal (o tubería en terminología beanstalkd) para recibir mensajes hacia él, es lo más simple, y simula perfectamente un sistema distribuido (cada nodo puede ser un proceso, o un hilo, tanto monta, siempre que las variables de los algoritmos no sean compartidas).

Quizás es recomendable implementar antes el algoritmo de “terminación distribuida” de Dijkstra-Scholten. Se usa la misma estructura de procesos y colas de mensajes, es más sencillo de entender (creo), y también es un algoritmo guapo.

Si implementas esto, y los entiendes, será como andar en bicicleta, no te olvidarás más. Y te gustará más la informática ;)

Categorías:píldoras, pijadas, programación Etiquetas:

Éxito rotundo en las redes del artículo de Ricardo Galli sobre el ‘caso Bárcenas’

enero 22, 2013 3 comentarios

Ricardo GalliEl Mundo: dar una primicia periodística importante, y dispararse en el pie con su paywall”. Así se titula el artículo de su blog que escribió Ricardo Galli el pasado viernes y que sigue triunfando en las redes. El artículo, con un título que recuerda a las bromas hechas por los hackers con la etiqueta #foobar, repasa el periodismo de El Mundo por el ‘caso Bárcenas’.

“Si la semana pasada fue demoledora, ¿qué decir de esta? La verdad es que van faltando las palabras, incluso a quienes nos dedicamos a escribir”, asegura el bloguero, que muestra su indignación ante la continua aparición de casos de corrupción. “Como mínimo, y sin que me conste nada más grave de qué acusar a El Mundo, fueron unos irresponsables y negligentes porque no controlaron a quien debían mostrar la información.”, denuncia Galli, entre otros temas, en el escrito de su blog.

ÉXITO BRUTAL EN TWITTER
Los tuiteros han felicitado con fervor al bloguer por su “concisión, claridad y valentía” y han convertido el artículo en uno de los más leídos durante varios días en su blog y, sin duda, en uno de los más compartidos en las redes.

—-

Absoluta y tremendamente ridículo, ¿no? Antes de insultarme en los comentarios por favor lee Éxito rotundo en las redes del artículo de Pepa Bueno sobre el ‘caso Bárcenas’ que salió en un “medio serio”, escrito por “periodistas”. Luego me dices.

Vía http://www.meneame.net/story/exito-rotundo-redes-articulo-pepa-bueno-sobre-caso-barcenas

Leer más…

Yo no tengo por qué trabajar

abril 8, 2011 13 comentarios

Hace un par de días me encontré con este vídeoclip amateur, no conozco de nada el grupo, sólo dice “La Gota de Leche” (¿será de aquí?). Me gustó mucho la composición de las imágenes con las letras, el humor y la referencia a temas muy recientes, como el famoso tweet de Bisbal y, por supuesto, a #nolesvotes.

Abajo puse la letra, disculpad si hay un error (soy un negado para música y la lírica ;) ). Gracias a Sin salir de la cama por la ayuda (y sus canciones).

Leer más…

Resumen de estudio de las discusiones en foros y Twitter

abril 1, 2011 7 comentarios

Patrones observados por los entrevistados

  1. Si no contestas porque sabes no que llevará a ningún lado salvo quizás a un enorme flame y descalificaciones: no dialogas, no conversas.
  2. Si no contestas porque no te has enterado, o se te pasó: no dialogas, no conversas.
  3. Si intentas dialogar, explicar tu punto de vista: no aceptas críticas, te lo tomas de forma personal.
  4. Si les pides evidencias de lo que afirman o acusan: no aceptas críticas, te lo tomas de forma personal.
  5. Si te critican duramente y respondes con críticas a esas críticas: no aceptas críticas, atacas, te lo tomas de forma personal
  6. Si insistes en tus argumentos, o reclamas más explicaciones: tienes un ego enorme, atacas, te lo tomas de forma personal.
  7. Si te dicen que no tienes ideas y respondes con datos objetivos: te crees que lo sabes todo, atacas, te lo tomas de forma personal.
  8. Si pillas a alguien mintiendo, manipulando u ocultando una parte importante de la historia: tienes un ego enorme, eres un prepotente, insultas.
  9. Si haces un sarcasmo y está de acuerdo: ¡qué bueno!
  10. Si haces un sarcasmo y no está de acuerdo, o no lo ha entendido: ¡insultas! ¡vaya subnormal! ¡psicópata!
  11. Si después de una discusión reconoces que la has cagado en algo: ¡al fin lo reconoces! reconoce también que llevas equivocándote desde 1977.
  12. Si criticas a un político de esos que suele dar muy duro a sus adversarios políticos: ¡difamación e injurias inadmisibles!
  13. Si te escucha o lee un aspirante a “gurú”: ¡gurú! ¡vaya ego! ¡insultos!
  14. Si usas un taco, por ejemplo “mierda”, en una frase aunque sea retórica y te lee un cortito con mucha bilis: sólo sabes insultar.

Conclusiones

  1. Los que son más duros criticando más se enfadan si les responden a las críticas.
  2. Una gran mayoría están convencida que su opiniones son razonables y humildes. La de los demás, prepotentes.
  3. Cuando ya no quedan argumentos, o sólo interesa desacreditar más que debatir, se recurren a los “modernos insultos”: gurú, ego, prepotente, ¿y este se dedica a [profesión u oficio]?
  4. Los troles se enfadan mucho si le responden de la misma manera. Al ser preguntados se justifican en que ya es sabido que ellos sólo trolean y que son simpáticos, por lo que no se merecieron esa respuesta.
  5. Un anti “gurús” es siempre un aspirante a “gurú”.
  6. En todos los foros y Twitter se verifica la tesis de Cipolla.

Hipótesis a evaluar

  • Uno que está convencido que es gurú nunca discute, ni se enfada, ni contesta porque no les entienden, son todos necios.
  • Uno que va de gurú pero sabe sus limitaciones hace lo mismo, pero para que no descubran que es un charlatán.
  • Los periodistas usan mucho el término “gurú” para que sus jefes y lectores crean que tiene contactos importantes.
  • Los periodistas no pueden admitir apellidos italianos acabados con “i”, le agregan siempre una “r”.

Ficha técnica

Este estudio siguió métodos de medición y estadísticos similares a los usados para medir la pérdidas de dinero por la piratería en Internet. También se usaron métodos de validación y control similares a los demás estudios sobre Twitter publicados recientemente.

Disclaimer

El autor reconoce que en Internet es donde más aprendió y donde tuvo las mejores discusiones. Y que salvo excepciones, no puede hacer lo mismo con amigos o conocidos en el “mundo real”.

Categorías:blogs, internet, pijadas Etiquetas:
Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 486 seguidores