EM Hernández-Novich

«Colaborador» implica que laboré en conjunto con otros, y eso no es preciso.

---

Construí la primera versión de Canaima trabajando sólo, como una Custom Debian Distribution (CDD), en un par de días. Tuve que hacer eso, porque después de dos meses y medio de esperar por decisiones no técnicas de los procrastinadores de oficio al cargo del proyecto, entraron en crisis pues les ordenaron un resultado. Esa es una de las razones por las cuales nunca más quise estar involucrado: me disgusta la pérdida de tiempo y la subyugación a la militancia antes que al profesionalismo.

---

Entregué el ejemplar original junto con un documento (que se hizo muy popular) que explicaba paso a paso cómo hacer una CDD, de manera que pudieran reproducir el procedimiento por su cuenta. Hice la demostración del procedimiento, y comprobé el CD que se generó en las máquinas que tenían que usar para su urgente demostración. Al mismo tiempo entregué otro documento (que nunca se hizo popular) que explicaba todo lo que NO debían hacer y todo lo que iba a pasar si hacían caso omiso de esas recomendaciones (como en efecto pasó en mayor o menor medida, según el consejo). Todos los involucrados leyeron el segundo documento, dijeron haberlo comprendido, y se dió por completado el asunto.

---

A partir de ese momento, no he tenido ninguna vinculación con el proyecto Canaima porque, como es público y notorio, sólo me interesa colaborar con Debian.

View more

No sé si existe ese listado.

---

El error más común es usar un lenguaje con un sistema de tipos pobre. El segundo es pensar que todo se resuelve con Strings, y «parsers» hechos con expresiones regulares. El tercero es no programar defensivamente pensando que el mundo es ideal -- en particular, programar sin usar y manejar excepciones. El cuarto es no saber usar un debugger (y poner banderas), ni saber usar banderas (que se llama instrumentación).

---

El libro «Writing Solid Code» es muy bueno. Es viejo y habla de progrmar en C, sin embargo los principios que enseña son pertinentes. Más aún ahora que la gente escribe código en lenguajes cada vez menos estrictos. Si escogiste un lenguaje que no te protege, entonces tienes que trabajar más en protegerte tú, a costa de tu tiempo y escribir más pruebas.

---

También es conveniente que leas «The Art of Unix Programming». Nuevamente, por los principios de diseño y estructuración, además de enfrentar la programación menos como carpintería y maś como ebanistería.

---

Si no programas en Unix, comienza por corregir ese problema.

View more

No hay provisión para registrar los logs de BIND9 en una base de datos. En mi opinión tiene muy poco sentido. Tiene
más sentido usar una base de datos roundrobin -- ciertamente PostgreSQL tiene una extensión para hacer roundrobin, pero es innecesario para operaciones normales de BIND.

---

Si quieres ver estadísticas de funcionamiento te basta hacer `rndc stats` y analizar el archivo de texto que se genera. Haces eso cada cinco minutos con algo como Munin y tienes un gráfico de tendencia. No necesitas SQL para eso.

---

Si eres hipster puedes configurar usar el API statistics-channel para obtener la misma información y algunas cosas más bastante detalladas, en un documento XML o JSON via HTTP. Nuevamente, lo haces cada cinco minutos.

---

Con cualquiera de los dos métodos anteriores tienes exactamente la información que necesitas para hacer análisis de desempeño, con mínimo impacto en la operación.

---

Si quieres analizar errores y notificar automáticamente, es *mucho* más rápido usar cosas como logwatch o mon.

---

Si insistes, entonces envía los mensajes a syslog, y de allí a una base de datos (al menos syslog-ng permite hacerlo con relativa facilidad). Enviar los logs a una base de datos directa o indirectamente, va a requerir más I/O, así que si lo pones todo en la misma máquina, perdiste. Por otro lado, los logs de BIND9 no son uniformes como los de nginx o sendmail, así que vas a tener que escribir un parser, y cualquier modelo relacional que se te ocurra va a tener debilidades.

---

Después de escribir la respuesta y pensar al respecto, no hay nada razonable en guardar los logs de BIND en PostgreSQL. Es más caro, más impráctico, y agrega al menos tres partes móviles a la operación.

View more

There's one way to resolve names: DNS protocol.

---

DNSSEC is a standard extension to the DNS protocol that guarantees integrity, and integrity only. If a program queries a resolver that does not do DNSSEC, any device in between can alter the response and the program will not notice it. If the application queries the resolver demanding to use DNSSEC and the resolver refuses, it's better to use a different resolver. If the application queries a resolver demanding to use DNSSEC and the answer comes back modified, the application will notice.

---

But DNSSEC does not provide privacy. Any query you make will travel in plain text. Interested parties can look at your query and the answers you receive. They can't touch them. If you don't use DNSSEC, queries can be changed on the fly -- this is being done in many places where would be censors don't want the average «internet user» to look at some content. It's a cheap way to block pages for the majority of people that have no idea how the Internet works -- almost everyone.

---

DNS over HTTPS is NOT a standard. It can be defined as an «experimental technique» (at best) that attempts to provide integrity by tunneling the DNS query on top of an HTTP + SSL transaction. This protects the query from your application issuance to the HTTP + SSL endpoint. But the rest of the transaction is in the hands of whatever the HTTP + SSL service wants to do. This could include changing the query, recording the query, and other nasty things. Any DNS over HTTPS provider really wants you to use them to harvest queries, answers, and other protocol-related information. Don't use them.

---

The correct way to provide integrity and privacy is to always request DNSSEC (integrity) using DNS over TLS (this IS a standard to provide privacy for DNS) to a trusted resolver. That trusted resolver would be using the same technique to fulfill the query -- thanks to the way DNS works, this is all you need.

---

This can be achieved by setting up either Unbound or BIND9 on a safe location, setting up a TLS tunnel, and configuring your applications to use said resolver. That's it. Anyone saying there's «a simpler way», doesn't understand DNS, cryptography, or is trying to sell you to someone.

---

Blocking DNS over HTTPS (don't use it) is somewhat simple if providers use the standard 443 port. If providers are smart, they would use a well known technique to «make it look» like a legit website, but tunnel DNS when the client «does something special» that's incredibly expensive to detect for would be blockers.

---

Blocking plain DNS is easy (just block port 53!) but that means no one can resolve, so that's not only obvious but also backfires on the would be blocker. Blocking selectively means being able to look at DNS traffic -- you prevent that using TLS.

View more

No es posible y es intencional.

---

Registrar la respuesta a la consulta en un log es bastante más caro que confeccionar y emitir la propia respuesta. Una configuración así nunca funcionaría en producción salvo para instalaciones ridículamente pequeñas.

---

Si necesitas hacer ese tipo de análisis, tendrás que capturar los paquetes en tránsito y cotejarlos, usando `dnscap` y unos programas a la medida según tus intenciones. Con BIND 9.11 puedes intentar usar el plugin `dnstap` para enviar los logs a otra máquina para su análisis. Consumirá muchos recursos de I/O y CPU.

---

En cualquier caso, registrar las respuestas a las consultas no tiene ninguna justificación técnica, más allá de hacer debugging del servicio. Registrarlo sólo por registrarlo es una clara violación a la privacidad del que consulta, en el caso de consultas recursivas. En el caso de consultas a un autoridad, para cualquier argumento a favor («son mis dominios») se puede contestar («¿y qué te podría sorprender de las respuetas?»).

View more

Programación por eventos («Event Driven Programming»).

---

Cualquier curso introductorio de Interfaces de Usario *tiene* que enseñar a programar así, tanto por lo conveniente como por lo inconveniente.

---

No necesitas hilos para hacer eso. Consume todo el CPU porque está «busy waiting» a que «pase algo». Si la máquina *sólo* está corriendo el juego (como ocurría en DOS) entonces nadie se queja y todo el mundo es feliz. Pero si hay otros programas en ejecución, entonces es un estilo de programación incivilizado para el resto de los programas en la máquina, porque cede el control cuando le dá la gana. Todas las interfaces de usuario gráficas se escribían así antes de que tuvieran sistemas operativos multiprogramables (concurrencia simulada) e incluso hilos. Por eso las versiones de Windows originales eran aún más frágiles que las actuales -- porque los programas por eventos no necesariamente cooperaban entre si.

---

Ese es el modelo de programación de JavaScript: un sólo hilo esperando por eventos. Del lado del cliente, afortunadamente JavaScript corre «encerrado» en el navegador, así que sólo maltrata al navegador cuando no coopera. Hay gente que quiere usar ese modelo en el servidor, y «no le vé nada de malo» al modelo.

View more

Porque SGML era demasiado complejo y la proliferación de la web permitió revisar y refinar la definición.

---

XML correctamente usado permite facilitar el intercambio de información generalizada con documentos cuya estructura se puede verificar de manera sistemática, de manera que sus componentes respeten reglas de tipos.

---

Es un error usar XML para la interacción entre humanos y aplicaciones. XML no fue inventado para ser «fácil de leer/escribir» por humanos. XML fue inventado para ser fácil de generar y aceptar por programas.

---

Es un error usar XML sin DTD. XML fue inventado para que cada tipo de documento sea definido de manera clara, tanto en estructura como en restricciones de contenido, y luego todos los documentos respeten esa definición. Existen reconocedores XML que hacen la validación automáticamente; mucha gente no sabe usar un reconocedor XML, ni de secuencia (streaming) ni por eventos, y en su inocencia cree que puede manipularlo con expresiones regulares y «validaciones».

---

Esas son las dos razones fundamentales por las cuales la gente fracasa usando XML: usarlo como si fuera un documento de texto y despreciar (por ignorancia o por audacia) la teoría y práctica de lenguajes de tipos fuertes.

---

La alternativa es JSON, que es el equivalente a verificación dinámica, hecha a las patadas, de estructuras arbitrarias. ¿Por qué existe JSON? Porque es más la gente que no entiende XML y las herramientas adecuadas que está dispuesta a aceptar errores de verificación a tiempo de ejecución.

---

Un principio fundamental en redes es ser conservador con lo que se emite y liberal con lo que se recibe. Un emisor XML apoyado en un DTD siempre va a ser estricto, y por ende conservador -- de ese modo todo lo que sale de mi aplicación va a ser conservador y no puedes acusarme de «pirata» ni «panchero». Un validador XML apoyado en un DTD siempre va a advertirme (con justificación) de documentos inválidos entrando, y yo decido cuán liberal ser contra el «panchero» de turno.

---

Con JSON, panchero es una forma de vida, y te obligan a ser liberal en todo sentido. Eso es lo que pasa cuando hay igualdad en el lenguaje... hacia abajo.

---

Pienso que la discusión entre XML y JSON, es la misma que entre verificación estática estricta y verificación dinámica relajada. El primero te permite ahorrar una cantidad brutal de trabajo a priori, siempre que dediques tiempo a entender las herramientas y tengas la preparación sobre lenguajes; el segundo te otorga toda la libertad del mundo para hacer lo que quieras, con el riesgo de pegarte varios tiros en el pie por tener que contar con tu atención al detalle. Todos tenemos poca atención al detalle y nos cansamos.

View more

No conozco estadísticas al respecto.

---

Las organizaciones que no pueden reutilizar nada de código, seguramente pensaron muy poco respecto a los problemas que estaban tratando de resolver, y lo combinaron con estilos de programación y modelos de datos que lo hacen más difícil. Hay muchas causas para esto, que tienen que ver con poner los procesos por encima de la ingeniería, y la urgencia por encima de la importancia.

---

Es cierto que cuando se comienza a resolver un problema, no se sabe lo suficiente. No es menos cierto que la buena ingeniería pasa por agregar un juicioso «coeficiente de ignorancia» para poder refinar.

---

Por otro lado, a veces reutilizar código sólo por reutilizarlo, te hace perder tiempo después. Hay que tener experiencia y confianza para poder declarar código como inútil o inapropiado, y comenzar de nuevo -- no confundir con el Síndrome «no lo escribimos aquí/no lo escribí yo» sumamente contagioso entre comunidades que giran alrededor de lenguajes «sólo hay una forma de hacerlo». Ese Síndrome se agrava cuando un desarrollador medianamente competente sube a posiciones gerenciales y decide que es mejor comenzar de nuevo lo que no se comprende, bien sea en la organización actual o al cambiar de organización. El «Principio de Peter» es inexorable.

---

Personalmente, reutilizo muchísimo código todo el tiempo, porque los lenguajes que utilizo lo fomentan con librerías estándar bien pensadas y constantemente refinadas, además de una organización del espacio de librerías públicas que converge hacia la reutilización. Participar en las comunidades de esos lenguajes te obliga a pensar bien en los problemas que resuelves, y a notar cuando otros lenguajes están signados por el «copy paste» y «repetir la carpintería con otra madera».

---

Es un compromiso delicado.

View more

No puedo decir qué te conviene más a ti.

---

A mi nunca me conviene un teclado numérico, así que la T580 no la escogería.

---

Si te interesa duración de batería, el modo tarjeta de video dual de la T580 te permite usar la Intel integrada todo el tiempo y activar la nVidia sólo cuando es necesario para OpenGL o para cómputo vectorizado.

---

Si te interesa economía de espacio y peso, la X1 gana.

---

Para cualquiera de las dos, compra toda la memoria que puedas pagar y que quepa en la máquina, y compra disco NVMe. Usar discos duros SSD sobre rotacionales es un cambio notable -- usar NVMe es otra liga, por un lado por el ahorro energético, y el ahorro de tiempo si tienes actividades I/O intensivas derivadas de máquinas virtuales, carga/manipulación masiva de datos, o procesos de compilación larga.

---

No encuentro ventaja alguna en tener una pantalla portátil de menos de 14". Un buen consejo a mi yo del pasado sería no ser un idiota y usar tipos de letra bastante más grandes. No tiene nada de «rudo» usar fonts de menos de 16 puntos para programar -- rudo va a ser el momento en que no puedas ver bien ni de lejos ni de cerca por haber abusado de los músculos ciliares.

View more

Si tienes un portátil y quieres usar hibernación, necesitas que el área de swap sea al menos tan amplia como la cantidad de RAM.

---

Cuando hay área de swap, el kernel puede haer algunas optimizaciones de memoria para evitar asignar memoria real a procesos que no la van a usar nunca. Cuánto espacio poner en el área de swap para soportar estos casos depende de la combinación particular de aplicaciones que estés ejecutando,.

---

La regla de «reserva tanto swap como el doble de memoria RAM» surgió después de estudiar el menajador de memoria de AT&T System V R3.2 que requería tener al menos tanto swap como RAM, y la cantidad adicional de RAM extendía la memoria virtual. Las primeras versiones de Linux seguían ese modelo. Una vez que Linux adaptó y refinó algunas ideas de BSD, esa regla dejó de tener sentido en Linux y BSD a finales de los 90 -- cualquiera que te salte con esa regla no está suficientemente informado.

---

Pon siempre algo de swap. Usar LVM es muy conveniente porque siempre puedes crear un LV con algo de swap, y luego agregarle si hiciera falta una vez que aprendes sobre el sistema. El disco es tan barato hoy en día, que tener swap no es un problema económico.

View more

La documentación de BIND9 te explica como configurarlo para tener al menos dos maneras de obtener estadísticas, dependiendo de lo que quieres analizar. Las más «básicas» se emiten a un archivo de texto en disco, con un formato que es trivial de analizar. Las más «complejas» se emiten a través de un socket, en formato XML o JSON según tu gusto.

---

Hay cosas similares para PowerDNS y Unbound.

---

Entonces, instrumentar esas estadísticas para tener gráficos de tendencias es algo que deberías tener todo el tiempo. Es la única forma de entender a fondo cómo operan tus DNS (autoridad, réplica, o recursivo). Por ejemplo, masajeando un poco las métricas «crudas» puedo decirle a mis clientes cuántas veces se consultan sus nombres, nombres que podrían tener, zonas del mundo donde su nombre es consultado, y así.

---

PowerDNS incluye varios programas útiles (dnsbulktest pareciera servirte), que funcionan contra cualquier otro DNS que quieras analizar.

---

También existe dnsperf, pero tiene el problema de que no es multihilo y tampoco es asíncrono. Eso quiere decir que puede servirte para hacer pruebas razonablemente útiles, pero se hace difícil usarlo para pruebas distribuidas que imiten mejor la realidad de un DNS en servicio.

---

Siempre puedes construir tus propias pruebas de stress usando cosas como la librería adns y bindings en el lenguaje de programación de tu preferencia.

---

Finalmente, evita poner el «verdadero» maestro autoridad al aire. El verdadero maestro autoridad siempre es un servidor oculto que replica a los anunciados como NS.

View more