EM Hernández-Novich

Los micro-kernels ya contribuyeron lo que tenían que contribuir: el concepto de «hipervisores» para controlar kernels monolíticos indpendientes. Por lo demás, se sabe que son ineficientes porque:

---

* Requieren más memoria.

---

* La comunicación entre los «servicios» es onerosa en memoria y CPU.

---

* Es mucho más difícil hacer debugging en pasaje de mensajes a través de interfaces, que en la simple copia de espacio kernel a espacio usuario en los monolíticos.

---

* La escalabilidad es mediocre cuando aumenta la cantidad de procesos o la necesidad de comunicación entre procesos.

---

Todos los microkernels «rápidos y mejorados» lo lograron... convirtiendo las partes lentas en tareas dentro del microkernel (o sea, volviéndolos monolíticos), o bien escribiéndolos para un propósito MUY específico y restringiendo la cantidad de procesos a correr sobre ellos.

---

Ninguno ha sido suficientemente estable, eficiente, y flexible, para ser de propósito general. El más exitoso, sin duda, es QNX, que quedó para teléfonos.

---

Que sea GPL no es diferenciador. GNU Hurd, un microkernel basado en Mach, también GPL, es uno de los fiascos más importantes de la historia de los microkernels.

---

Que algo sea GPL (o BSD, o la licencia libre que te guste) no lo hace automáticamente bueno, ni interesante, ni útil. Sólo lo hace libre.

View more

En mi experiencia y contexto de trabajo, es más fácil forzar la actualización de las herramientas de desarrollo, corrigiendo las «pequeñas» incompatibilidades que puedan surgir, antes de atacar las malas prácticas de diseño y programación. No creo que eso funcione en todos los escenarios.

---

He tenido discusiones a priori y cureles «te lo dije» silenciosos a posteriori, en escenarios donde lo más barato era borrar todo y comenzar de cero, pero los equipos se negaban porque les faltaba el valor para verlo como el fracaso rotundo que era. Así que fracasaron dos veces.

---

Cualquiera de las dos circunstancias que describes es un fracaso muy grande de parte de los supervisores, y hace falta ser muy buen profesional para admitirlo. El problema que tienes que atacar primero es hacer entender que los errores que se ocultan, siempre vuelven para perjudicarte, y que aquellos que causaron deudas técnicas, son responsables de asumirlas y resolverlas, o quitarse del medio.

---

El software bien diseñado y escrito con la claridad de aquel que comprende el problema, puede seguir operando con herramientas viejas, sin problemas. El apuro sin destino y la impaciencia del que enfrenta el desarrollo de software como prototipos fungibles, que cumplen con un «checklist de buzzwords» es el principal enemigo.

View more

GCC, como todo compilador, está dividido en fases. En el caso particular de GCC está el front-end (análisis sintáctico y de contexto para producir un Abstract Syntax Tree), middle-end (generación y mejoramiento de código intermedio), y back-end (emisión de código de máquina).

---

Esa división permite agregar (lo que tu llamas «unir», supongo) nuevos lenguajes a la familia con rapidez razonable. Basta que alguien escriba el front-end y luego se conecte al resto del flujo de datos del compilador. Para eso es necesario cubrir la «frontera» entre el AST y la representación intermedia de GCC denominada GIMPLE; no es para nada complicado, en todo caso es fastidioso porque GIMPLE es horrendo en comparación con LLVM (la representación intermedia de CLANG).

---

Para que un lenguaje en particular forme parte de la familia de GCC, es necesario que exista el front-end GPL, que haya suficientes personas que lo mantengan, y suficientes personas interesadas en usar ese lenguaje.

View more

There's no predefined ordering for evaluating pure code, therefore it makes little sense to try and add «Kilroy was here» tracing messages.

---

You can only predict ordering for the IO monad, so yes, you'll need to intersperse your evaluations within the IO monad. There are functions in Debug.Trace that can help with what you want for debugging purposes. They WILL make your code slower because they WILL prevent many optimizations to be applied since they introduce impure side effects.

---

Having to trace pure code means you're not confident in your pure code. Instead of doing trace-debugging, write better property tests (QuickCheck) and improve your types. «printf debugging» is a terrible imperative programming practice.

---

If you're looking to add instrumentation, what you need is a logger and it needs to work on IO. Either low level logging via GHC's Eventlog (better know what you're doing) or simple syslog logging (I like hslogger) which is usually the case for system's software. Logging to stderr is a standard error.

---

The only way to trace is by guaranteeing a sequence in time. This can only be done within IO because of the separation of pure and impure code. Trying to force sequencing on functional pure code is an oxymoron.Re-read until you get it.

View more

Con «Mucho Cuidado»®

---

Más que una recomendación, es lo que más o menos me funciona a mi en términos de comodidad y habilidad de cooperar con otros. Estas ideas no son mías. Estuve buscando el sitio en el cual encontré la sugerencia hace cuatro o cinco años, pero no lo logré. Admito que muchas veces no aplico la guía al pie de la letra por «razones». Trabajo en un equipo pequeño donde hay mucha experiencia, lo que reduce el desorden y facilita hacer control de daños.

---

El principio fundamental es que la historia en Git debe ser inmutable, fácil de seguir, y razonablemente atómica. Si tienes que «cambiar el pasado» o hay «cambios con errores en master», no lo estás haciendo bien. Entonces, para trabajar en cambios:

---

1. Creo una rama privada a partir de una pública (o master).
2. Hago commits simples (pequeños) con mucha frecuencia.
3. Cuando todo funciona, «limpio» la historia.
4. Combino (merge) con la rama originaria (o master).

---

«Limpiar» la historia depende de la situación particular:

---

1. Es un cambio sencillo que se logró en poco tiempo. Eso requirió hacer *varios* commits pequeños en la rama. En ese caso

---

git checkout master
git merge --squash mi-rama-privada
git commit -v

---

Me tomo el tiempo de escribir un mensaje de commit que sea la explicación (y no la combinación) de todos los cambios pequeños.

---

2. El cambio es más complicado, se logró en un tiempo más largo, y no lo puedo explicar en un solo gran cambio. Si lo hago como un sólo gran cambio, la revisión del código se hace compleja. En ese caso

---

git rebase --interactive master

---

y de la lista de cambios, hago `pick` o `squash` selectivamente, para agrupar varios cambios pequeños entre si. Por ejemplo, en vez de 20+ cambios detallados, los reagrupo para que queden cuatro o cinco «sustanciosos». Explico con más detalle cada cambio sustancioso, y listo.

---

3. Mi rama da lástima porque la «dejé morir». Eso pasa si me tardé mucho, hubo cambios en la rama originaria y los tuve que traer para no perder el hilo, cambiaron las prioridades y ahora hay que volver a trabajar en esto. Cualquier razón por la cual la historia se complicó. En ese caso, literalmente «dejo morir» la rama:

---

git checkout master
git checkout -b limpiar-aqui
git merge --squash la-deje-morir
git reset

---

y limpio el rancho en un «gran diff» en lugar de ponerme a ver cada cambio pequeño.

---

En todo caso, aprendí que si te estás peleando con Git, es porque lo estás usando mal.

View more

I don't clone disks -- each disk is filled with random data before installation over LUKS.

---

0. Current laptop is full up-to-date Debian-wise.
1. Buy a new laptop (or disk for the current laptop).
2. Copy /etc/apt/ from current installation
3. Save `dpkg --get-selections` from current installation
4. Install exact same version of Debian on the new disk.
5. Restore /etc/apt/
6. dpkg --set-selections ; apt-get dselect-upgrade
7. Restore $HOME
8. Wipe the old disk.

---

I've been doing this since 2005, because Debian upgrades work as expected all the time. I upgrade Debian stable to testing in place, only after the freeze. Then tweak whatever configuration needs to be tweaked.

---

The last time I installed a Debian laptop «from scratch» was the MacBook Pro at work. I wouldn't clone it -- I'd just save $HOME without the Git clones, install a new machine, restore $HOME, and run `mr up`.

View more

La verificación de tipos con TypeScript: (1) es opcional, (2) si tu programa tiene errores de tipos, igual permite emitir JavaScript. Eso no es un sistema de tipos.

---

Flow es una herramienta de análisis estático, y es mucho más práctica y conveniente que TypeScript. Pero tampoco es un sistema de tipos. En el mejor de los casos es una herramienta que intenta adivinar la intención de las expresiones, pero no puede establecer con certeza los contextos, porque el lenguaje subyacente es una mezcla arbitraria de contexto nominales y estructurales -- lo mejor que puede hacer Flow es adivinar: si sale bien, bien, si no, también.

---

JavaScript no fue diseñado para tener sistema de tipos. Es una decisión (o defecto) de diseño. No se le puede «montar» un sistema de tipos sin hacer cambios fundamentales al lenguaje subyacente, en particular al front-end del interpretador JavaScript que está en los navegadores.

---

Aunque la mona se vista de seda, mona se queda.

View more

La licencia de OpenSSL establece (Cláusulas 3 y 6) que cualquier redistribución de OpenSSL *debe* incluir menciones explícitas al Proyecto OpenSSL. No es cualquier mención: es la mención particular que indica la licencia, con ese texto.

---

La licencia GPL establece (Cláusula 6) que cada vez que redistribuyes un programa o trabajo derivado, el que recibe el software recibe *implícitamente* el derecho de copiar, modificar, y redistribuir *todo* el trabajo, y no le puedes imponer ninguna restricción adicional.

---

Esto, naturalmente causa un conflicto: la licencia OpenSSL exige que incluyas las menciones, pero la licencia GPL dice que no se pueden imponer restricciones -- incluso una tan inocua como esa.

---

Ciertamente la GPL tiene una excepción que permite a un programa GPL enlazarse con una librería no-GPL siempre y cuando esta última sea *fundamental* en el sistema operativo. Se puede argumentar que OpenSSL es fundamental, o no. También se puede argumentar que la excepción descrita en la GPL está sujeta a muchas interpretaciones, y es uno de esos casos en que «democracia» no sirve para zanjar la discusión (no importa cuánto griten los militantes).

---

El proyecto OpenSSL recomienda que si desarrollas Software Libre que necesita OpenSSL, (1) *no* uses la GPL, o (2) ejercites la excepción indicando en tu licencia que «todo es GPL excepto que se puede compilar y enlazar con la GPL» (esto puede desatar la furia de RMS y sus acólitos, cosa que siempre es buena). Finalmente, te indican que si quieres incorporar OpenSSL a software GPL escrito por otros, pidas permiso a *todos* los autores (Copyright Holders) antes de redistribuir.

---

El Proyecto Debian, respetando los derechos de los autores de Squid (GPL), de los autores de OpenSSL, y evitando interpretaciones ambigüas, decidió que no es conveniente distribuir el software enlazado con OpenSSL. Si el usuario quiere hacerlo, es su problema.

---

El soporte de Squid para usar GNUTLS es un trabajo en proceso. Quizás cuando esté completo, Squid pueda distribuirse con soporte SSL completo en Debian.

---

Este problema ocurre con cualquier software GPL que use OpenSSL y necesite ser redistribuido. Puedes leer

---

https://lists.debian.org/debian-legal/2004/05/msg00595.html

---

que tiene una explicación adicional.

---

Este problema no ocurre si el software tiene una licencia como la Apache, Artistic, BSD o MIT, y quiere enlazar con OpenSSL.

---

Esta es una de las razones por las cuales se dice que la GPL es «infecciosa»: no le basta con proteger un conjunto de software en particular, dificulta (hasta impedir) que lo combines con software que no es GPL. Es también una de las razones por la cual la GPL es la «menos libre» de las licencias, pues restringe tu libertad de combinar con cosas que no sean GPL.

View more

No es posible.

---

Partiendo de la suposición que tienes uno o dos NTP Stratum N que se sincroniza con el exterior, y *todos* los demás son NTP Stratum N+1 en tu red local, puedes estudiar la calidad de los RTC de estos últimos. Agrega instrumentación para medir el «offset» reportado por NTP. Si el «offset» no converge, y el «jitter» es relativamente constante, entonces el RTC no es de buena calidad. Si el «jitter» no es constante, el problema es tu red local, no los RTC.

---

La precisión del RTC no es realmente importante (en un sistema Unix) precisamente porque NTP hace el trabajo de mantenerlo sincronizado. El servidor NTP típicamente cambia la hora del RTC al reiniciar el equipo, y según la configuración podría hacerlo con más regularidad -- eso no es realmente importante, porque la «hora» es ajustada constantemente por NTP.

View more

Los archivos pueden no estar. Quizás no tienes privilegios de acceso. No hay suficiente memoria. Los discos se llenan. Las conexiones se rompen. Los datos se corrompen. Otros programas pueden fallar. El proceso padre muere y arrastra a sus hijos. Muchas cosas pueden salir mal.

---

Un programa robusto tiene que reaccionar de manera ordenada ante esas anomalías. «Dejar que explote» no solamente denota falta de prolijidad y atención al detalle, sino que también puede causar una cascada de problemas posteriores: asumir que algo salió bien (que no) y borrar cosas que después no puedes recuperar. El programa debe detectar la condición de error, reportarla con detalle y contexto, liberar cualquier recurso tomado, y terminar -- «explotar» no es lo mismo que «terminar con error».

---

Un programador cuidadoso se reconoce porque conoce y revisa todas las llamadas que podrían resultar en errores inesperados, como reservas de memoria, apertura de archivos, conexiones a base de dato. Además, tiene que estar preparado para recibir excepciones asíncronas, enviadas por otros procesos en el ambiente de ejecución. No hacer esas cosas, es trabajo de calidad insuficiente. Escribir todo eso a punta de condicionales (if todo-bien else corregir) no solamente es incomodísimo, te hace repetir trabajo por todos lados, y resulta en programas más complejo de comprender, sino que causa que el código generado sea particularmente ineficiente (no es bueno saltar a cada rato).

---

Al programar con bloques de excepciones, te ahorras las verificaciones línea por línea, puedes suponer que si todo el bloque try terminó es porque tuvo éxito, y en el bloque catch recuperarte si puedes, y si no puedes, repetir la excepción al invocante. El código dentro del bloque try es fundamentalmente lineal, y sólo salta al bloque de excepciones usando mecanismos de bajo nivel, que son más eficientes.

---

La «programación defensiva» es uno de los atributos del programador competente. El software de mejor calidad es aquel que opera de manera transpartente tanto cuando todo sale bien como cuando algo sale mal. Entonces, es necesario escribir programas de manera que si algo sale mal, el programa recupere, reporte, y recicle recursos, explicando de manera clara el contexto y causa del problema. Los bloques de excepciones son precisamente la herramienta para estructurar programas que se comporten así.

View more