EM Hernández-Novich

Escribe los manuales en Markdown y usa Pandoc para publicar en el formato que te interese. No hay cosas más flexible hoy en día. Markdown es texto puro, la sintaxis es ridículamente simple, lo administras con tu VCS, y se puede manipular en cualquier editor de programación (algunos hasta modo «preview» tienen).

---

Para la documentación técnica, es importante que los lenguajes que uses tengan un mecanismo de documentación embebida inteligente (como Perl Pandoc o Haskell Haddock), o bien mecanismos de «literate programming» en los cuales el compilador extrae la documentación (escrita en Markdown o LaTeX) para su procesamiento.

---

Si un programador no es capaz de articular con claridad y precisión cómo funciona su código, cómo interactúa con el resto del sistema, y cuáles son las condiciones especiales de uso, no lo está haciendo bien. Programar es el arte de que otra persona comprenda lo que tu código logra que la computadora haga -- buen código, buena documentación.

View more

Si la máquina tiene partes móviles (discos rotacionales), encenderla y apagarla con frecuencia causa desgaste y reduce el tiempo de vida. Mucha gente tiene la noción de que la máquina «se puso lenta» y reiniciarla la arregla: eso es una ilusión.

---

Mis servidores y máquinas de escritorio corren Linux o FreeBSD. Mientras más tiempo estén encendidas, funcionan mejor, porque esos sistemas operativos convergen hacia un «working set» óptimo que mantiene en memoria sólo lo que se está usando -- con MacOSX reciente la situación es casi la misma en la mayoría de los casos. La pobre gente aún usando Windows en pleno siglo XXI no tiene otra que reiniciar su máquina con mucha frecuencia, porque el kernel de Windows es mucho menos eficiente que el de Unix.

---

Mis portátiles corren Linux, y sólo se apagan (hibernar) cuando los transporto o me quedo sin batería. La máquina está apagada, pero todo el estado estado conservado para que se restaure al encenderla de nuevo. Con discos SSD eso toma menos de 5 segundos. Sólo la reinicio cuando hay que actualizar el kernel.

View more

En el caso de Perl, lo recomendable es

---

use common::sense;

---

que incluye `strict` y otras cosas que Perl tiene desde finales de los noventa y que otros lenguajes consideran «moderno» hoy. Para desarrollo de aplicaciones profesional, no puedes aceptar menos que eso.

---

Hay construcciones en Perl que son particularmente útiles para lograr efectos de transformación de programas que no están al alcance de muchos novatos y que, desafortunadamente, son fáciles de activar accidentalmente. Antes de Perl 5, o conocías todo el lenguaje y sus peligros, o tus programas no hacían lo que querías por problemas de Capa 8. Al mismo tiempo, Perl mantiene compatibilidad con versiones previas, en las cuales no había `strict`, así que si estás manteniendo/convirtiendo desde versiones previas, vas a querer activar o desactivar `strict` selectivamente.

---

Ahora bien, el modo `strict` de Perl lo que hace es impedir que uses ciertas partes del lenguaje por error. Sin embargo, no cambia la semántica del lenguaje para nada. En otras palabras, lo que hace es eliminar un subconjunto del lenguaje potencialmente peligroso para inexpertos.

---

En JavaScript, el modo `strict` es menos altruista. Su efecto es, efectivamente, *cambiar la semántica del lenguaje*. Hay errores que se vuelven excepciones; hay errores del lenguaje que son «corregidos» sin decirte que los estás usando; hay formas del lenguaje que son interpretadas diferente. Entonces, escoger el modo `strict` en JavaScript no es For Your Own Good (tm) sino que depende del programa, del ambiente de ejecución, y de factores ajenos a la definición del lenguaje.

---

Para los que no son de computación o no les interesan mucho los detalles: el `strict` de Perl es el profesor de idiomas que te impide usar palabras a menos que sepas su significado; el `strict` de JavaScript es el creativo que cambia el significado de las palabras que cada persona interpreta diferente porque tienen vergüenza preguntar.

---

A cualquiera que programe en Perl le recomiendo que use `common::sense` todo el tiempo, porque el resutaldo es absolutamente predecible y está documentado. A cualquiera que programe en JavaScript, `strict` es más bien Suerte y Gaceta Hípica.

View more

Primero, separa la zona estática de la zona dinámica.

---

Segundo, considera que el DNS no tiene ninguna provisión para múltiples primarios por diseño. No, no es una buena idea que sea multimaster. Sólo puede haber un primario. Entonces una estrategia posible sería, a grandes rasgos:

---

1. El servidor primario autoridad atiende peticiones usando una IP «flotante». Tanto para las consultas DNS como para las actualizaciones dinámicas. Lee acerca de servicios con IP flotantes usando `ucarp` -- el punto es que es una IP que le pertenece temporalmente y no es ninguna de sus IP configuradas.

---

2. Tienes un servidor secundario *oculto* que está constantemente en sincronía (vía NOTIFY) tanto de la zona estática como dinámica del primario usando las IP fijas configuradas (de primario y secundario). Este servidor forma parte del mismo grupo `ucarp` para poder tomar control de la IP flotante, llegado el caso.

---

3. En el caso de falla, `ucarp` va a «quitarle» la IP flotante al servidor primario inalcanzable, se la va a asignar al servidor oculto, y podría ejecutar un script que convierte este secundario en primario haciendo lo que hay que hacer en la configuración de BIND.

---

Esa solución tiene una cantidad moderada de partes móviles, y la única restriccion de que ambos servidores tienen que estar en la misma subred. Si lo último no es posible, entoces necesitas un mecanismo alterno a `ucarp` para migrar las direcciones IP, y posiblemente un mecanismo «out of band» para replicar las zonas que ofrezca más libertades -- por ejemplo, podrías aprovechar que BIND9 puede usar a PostgreSQL par almacenar las zonas, y replicar la base de datos..

View more

Si es conveniente o no, depende de tus políticas de seguridad y las condiciones de tu red.

---

Si tuviera que operar el dominio example.com con ubicaciones en varios países, lo primero que haría es tener delegación de las zonas por país, i.e. ar.example.com, ve.example.com, etc. Cada país tendría su propio servidor autoridad local para la zona particular, además de réplicas locales.

---

La zona principal (example.com) incluiría, además del «glue» para las subzonas, los RRs para servicios globales independiente de países, y posiblemente CNAMEs astutamente seleccionados para servicios regionales.

---

Cada zona delegada (ve.example.com) tendría los RR fijos en la zona para servicios dependientes del país, y una sub-zona (dyn.ve.example.com) en la cual ocurren las actualizaciones dinámicas con una llave TSIG para cada país.

---

Esto maximiza la descentralización administrativa, tolerancia a fallas en caso de pérdida de conectividad, separación de administración estática de la dinámica, y mejores prestaciones para la supervisión de la red.

---

Si tienes usuarios móviles que pueden registrarse dinámicamente en diferentes países, consideraría dos posibilidades. Si son pocos, generaría una llave TSIG para cada uno, porque así es más fácil determinar dónde están e incluso sacarlos del servicio. Si son muchos, generaría una llave TSIG para el grupo.

View more

Slackware siempre tendrá un lugar en mi memoria porque la usé durante mucho tiempo. Allí aprendí a construir, reconstruir, y ajustar todo sin asistencia de scripts, manejadores de paquetes, ni todas las comodidades que tiene cualquier distribución Linux en este siglo.

---

Dejé Slackware en favor de Debian, precisamente porque cuando uno aprendió lo que tiene que aprender, prefiere ahorrarse la «carpintería» y pasar menos tiempo en un despliegue. Comprendo a los fanáticos que continúan usando Slackware, porque no se ha dejado influenciar y mantiene su visión de decidir lo menos posible y minimizar la complejidad.

---

Aprendí a utilizar (y colecciono) reglas de cálculo, sin embargo prefiero usar una calculadora electrónica, porque tardo menos tiempo. Para mi, esa es la diferencia entre tener que usar Slackware vs. Debian en el día a día: podría lograr el resultado con ambas, pero con Debian lo alcanzo más rápido y tengo menos cosas que hacer.

---

Espero que los entusiastas la mantengan mucho tiempo más, y se diviertan en el camino.

View more

La mayoría de los usuarios de laptops serían igual de felices con un ARM en términos de rendimiento, y el ahorro de energía sería bárbaro, si se suman las nuevas tecnologías de almacenamiento NVMe.

---

La arquitectura ARM (junto con MIPS) es mucho más amena para implantar lenguajes con compiladores mucho más eficientes, que generen mejor código que para un Intel.

---

En el caso de ARM, el soporte para virtualización por hardware luce más que suficiente para estar al mismo nivel que lo que ofrece Intel. La diferencia es que varios núcleos ARM consumen mucha menos energía y requieren menos circuitería que la misma cantidad de núcleos Intel.

---

Al final, terminan siendo los fabricantes de hardware, y los consumidores, los que mueven el mercado. La mayoría de los usuarios no técnicos no tienen idea de nada y sólo les importa que «corra Windows» o «es una Mac» -- hace falta que más gente aprenda a sacarle provecho a sus máquinas a fondo usando Software Libre, y que más gente técnica comience a exigir alternativas. Hay que educar más.

View more

El diseño de las criptomonedas que pretende dificultar hasta que sea impráctico la aplicación de leyes de impuesto, el seguimiento al camino del dinero, y el impedir pagos a personas, organizaciones, o países, es uno que podría o no ser deseable para una moneda. Desde la ventaja de haber estado en el medio financiero, siempre ha sido verdad que donde hay dinero hay más mendigos y vagabundos, que productores e innovadores, así que en el estado actual de las cosas me parecen una idea peligrosa, porque hay más amenazas que ventajas para el usuario final. Que sirva para defenderse de algunos delincuentes, no oculta que permita operar a otros delincuentes. No puedo participar en una apuesta moral así.

---

Desde el punto de vista técnico me parece una combinación de ideas de criptografía y operaciones que eran ampliamente conocidas antes, pero que nunca se habían aplicado para este nicho. Si bien la combinación de ideas es muy creativa, también evidencia mucha inocencia en el impacto global de su aplicación -- como siempre, porque la gente rara vez diseña (mucho menos implementa) pensando en el uso y abuso. El «como venga viniendo, vamos viendo» forma parte del ethos de las criptomonedas -- un valor al cual rehuyo.

---

Un defecto grave, en mi opinión, es no haber notado que basta la mitad más uno de vagabundos, para perjudicar a la otra mitad de gente que quizás quiera actuar honradamente. Justificaciones como «eso es muy difícil», «los buenos somos más», «yo no creo», y similares, son inocentes -- las buenas intenciones no son suficientes cuando el sistema tiene defectos como ese. Praa tener la mitad más uno lo único que hace falta es dinero para desplegar más minadores o para impedir que los minadores honestos hagan su parte. Cuando el problema es dinero, el dinero aparece para el que tiene más ganas de ganar -- usualmente el menos altruista del grupo.

---

La tecnología subyacente, el «blockchain», que se ha convertido en la mayonesa de todos los pastichos de tecnología de los últimos años, es extremadamente costosa en términos de cómputo. La cantidad de electricidad que se consume en todo el mundo para minar criptomonedas es obscena; no importa que sea barata de pagar o no, o que minar deje ganancias: esa electricidad hay que producirla, y eso en muchos casos resulta en polución y calentamiento. Almacenar (y replicar) el contable es un consumo importante de espacio en disco (que requiere más electricidad), además del ancho de banda para que todas esas réplicas estén en sincronía.

---

TODOS los conceptos técnicos de las criptomonedas existen desde mucho antes de Bitcoin. Aplicados por separado sirven para muchas cosas y son más económicas. Aplicados en conjunto *sólo* sirven para criptomonedas, y a un costo material prohibitivo. La gente que ofrece «blockchain» para resolver otros problemas de tecnología, miente por audaz o por ignorante.

---

Si tienes ganas de invertir en criptomonedas, mejor juguemos «Dale plata a iamemhn», conocido como póker.

View more

Pareciera, en efecto, una pérdida de tiempo.

---

Tiene sentido instalar un antivirus en Linux/FreeBSD para detectar virus que afecten a Windows o macOS en los casos que mencionaste: un MTA que recibe y envía correo electrónico, y un servidor de archivos que exporta directorios para que computadores no-Linux los lean.

---

También tiene sentido si el servidor ofrece alguna aplicación web en la cual es posible agregar contenido arbitrario, por ejemplo un WiKi o un CMS. De este modo, cada vez que un usuario de la aplicación web intenta incorporar contenido con virus, se detecte y rechace.

---

Ahora, instalar antivirus en los servidores Linux/FreeBSD para proteger al servidor Linux/FreeBSD es ignorancia sobre el tema. Es probable que provenga de personas que apenas están pasando de plataformas inseguras, o que están sometidas a «políticas de seguridad» escritas el siglo pasado, para organizaciones del siglo pasado, con criterios de seguridad basado en lo mejor que los noventa podía ofrecer.

---

En el sentido estricto de virus y application malware, no existe ninguno para Linux/FreeBSD que sea capaz de operar con un usuario regular. Es decir, los «ejemplos» de virus y malware para Linux/FreeBSD siempre necesitan tener privilegios de superusuario. Si el administrador de la máquina instala programas o abre contenidos de origen desconocido como superusuario directo (`root`) o indirecto ( `sudo`), no necesitas un antivirus, sino un administrador que sepa lo que está haciendo.

View more

On the Intel compatible platform, a 32-bit OS is limited to 4Gb of RAM for direct addressing. If the machine has more than that, the kernel has to do a lot of tricks in order to use RAM above 4Gb and up to 64Gb in PAE-capable hardware, making it somewhat slower.

---

In contrast, a 64-bit OS can directly address up to 16Eb (Exabytes) of RAM. In practice, they directly address way less than that, usually in the order of Tb (Terabytes) of RAM. The reason being there are currently no hardware configurations that can support contiguous cache-coherent amounts of RAM exceeding 64Tb of RAM. Multi node cache-incoherent RAM is not directly addressable, so those machines don't count. Since access is linear, there are no performance penalties.

---

Every operating system has to reserve part of the address space for the kernel, that must *always* live in RAM and at the same virtual address so every process «sees» the same kernel. In 32-bit Linux, the kernel occupies 1Gb of RAM starting at 3Gb, effectively allowing no more than 3Gb for direct addressing, and whatever is above 4Gb for (slow) trampolining. In 64-bit Linux, the kernel occupies 1Gb of RAM starting at virtual address 128Tb, effectively leaving 128Tb for direct addressing (if you have less than 128Tb of RAM, the kernel «seems» to live there anyway thanks to translation tables handled by the CPU). Other OSes have the same restriction -- consult the sources to figure out how much, or trust the vendor if you must.

---

If you have less than 4Gb of RAM, it's better to use a 32-bit operating system -- you'll save some space since binaries are smaller as is the kernel footprint. If you have more than 4Gb of RAM, it's better to use a 64-bit OS on a 64-bit system.

---

Most modern Intel/AMD processors are 64-bit. They could run a 32-bit compatibility mode or native 64-bit. You should use the native 64-bit for the OS.

---

The same applies for other architectures, say MIPS or ARM, where you can have 32-bit or 64-bit operating systems.

View more

Visité Kerala, la capital de (presuntamente) la provincia más progresista de la India, en 2005.

---

El calor es indescriptible. Eso no es tan grave, considerando que soy nativo de Ciudad Bolívar. El problema es que todo está sucio, tanto por falta de pulcritud, como por falta de sanidad. No hay «brisa fresca», ni siquiera al lado del mar.

---

Nos atendieron con una amabilidad y cortesía notables. Sin embargo, los «superiores» dejaban muy claro a los «subordinados», que ellos eran menos. Los miraban mal cuando en lugar de «servirnos» nos poníamos a fraternizar. Muchos de ellos eran jóvenes en sus 20, con PhD en matemática o física que *aspiraban* ser profesores de bachillerato.

---

Caminé por varios espacios de la ciudad, y el factor común era la suciedad, el desorden, el ruido, y mucha pobreza. Que resaltaba aún más cuando pasabas alrededor de las tiendas que vendían joyas, justo al frente del Mercado Popular. Interactuar con la gente giraba en torno a «cuánto me vas a dar», con muy poca empatía. Feo.

---

Si has visto en las películas esos autobuses atiborrados, con gente en el techo, como animales y con animales, en vivo y en directo es más espeluznante. Porque además hay animales circulando por las rutas. La autopista más importante de la región, es prácticamente como la vía de Higuerote, pero con agua estancada a ambos lados, más maleza, y gente con rosto adusto y mirada perdida, arreando cabras. A nosotros nos asignaron un autobús así -- pero los jóvenes que nos atendían no podían venir con nosotros, a pesar de que había espacio.

---

Y en medio de esa ruta con ese paisaje tan duro, un cruce a la derecha te deja en un campus de investigación muy similar a la USB Sartenejas, llena de gente que sabe lo que hay afuera, pero lo disimula.

---

La playa no fue consuelo. Los 400 metros que separan al hotel de la playa fueron un ejercicio en precaución (*hay* serpientes) devenido en desilusión (el mar olía mal). Pintoresco el montón de tiendas improvisadas donde se venden libros y ropa usada, y donde es necesario regatear. Pero no es pintoresco que la terraza del restaurant tenga una malla de nylon, porque de lo contrario los cuervos vienen a tu mesa a robarte la comida. Y los dejas.

---

Visité templos de varias religiones y castas. En uno no me dejaron entrar por blanco. En otro me pidieron no tomar fotos. En otro, el pozo de agua más verde que he visto, y la gente se aseaba allí.

---

Creo que el único que pudo comer todos los días fui yo, porque todo era muy picante, y ninguno del grupo estaba preparado para eso. Ni siquiera los andinos. En esa provincia se come pescado, pollo, y cordero, así que no fue «debilitante».

---

Nos organizaron un espectáculo de Kathakali, sin duda lo más edificante de todo el viaje.

---

NatGeo hizo un programa sobre Kerala. Impresiona lo que se puede lograr cuando haces tomas cerradas. Para camaradas cinco estrellas quizás sea diferente.

---

No quise ir al Taj Mahal. Prefiero las fotos.

---

No hay virtud en la miseria. Fue duro.

View more

Personalmente no tengo un uso que darle. Supongo que para un sistema embebido crítico en el cual es muchísimo más barato tener una pantalla de caracteres que una pantalla gráfica.

---

Mucha gente ha crecido sólo interactuando con pantallas gráficas, y no tienen idea de lo costoso y complejo que es tener controladora gráfica, potencia para esa controladora gráfica, la cantidad grotesca de CPU adicional que hace falta, y lo inestable que puede ser una aplicación gráfica.

---

Un terminal de caracteres, incluso usado en modo framebuffer, requiere bastante menos potencia, bastante menos memoria (que implica menos potencia), y tiene una interfaz de programación bastante más sencilla, eficiente, y predecible.

---

Claro que la mayoría de los usuarios también cree que si no es gráfico es feo, y ese prejuicio del grafiarcado clicador es terrible.

---

Por supuesto que está escrito en JavaScript porque de lo contrario no sería cool, sin embargo seguro que es más lenta y menos flexible que la honorable libcaca, que tiene una década proveyendo ese tipo de servicios, como una mejora sobre aalib, que ya tenía 10 años haciéndolo bien. La gente siempre está reinventando la rueda, sobre todo cuando desprecia la historio que no conoce por desinterés u «ombliguismo».

---

Más de una vez miré videos usando AA o CACA, en máquinas que no tenían tarjeta gráfica, pero tenían CPU suficiente, para el estupor de los que estaban al lado, con Windows, pero no podían ver el video porque no les daba la tarjeta de video.

---

Siempre habrá gente que piensa que es inútil, y para ellos es apropiada la cita de Cyrano de Bergerac que está en la página de CACA.

---

Que dites-vous ?... C’est inutile ?... Je le sais!
Mais on ne se bat pas dans l’espoir du succès!
Non! Non, c’est bien plus beau lorsque c’est inutile!

---

¿Por qué? Porque pueden.

View more

Puedes usar cualquier Linux o FreeBSD para construirlo (FreeNAS no es más que un FreeBSD).

---

Mientras más discos puedas incluir, no solamente aumenta la capacidad total, sino que mejora el desempeño general. Así, es mucho mejor tener 8 discos de 2Tb, que 4 de 4Tb, que 2 de 8Tb. Estoy cansado de ver organizaciones que compran un gabinete de discos de 16 posiciones, y compran, si acaso, cuatro discos grandes -- si vas a construir storage, compra todo el disco que puedas pagar de una vez.

---

Invierte en una máquina que tenga puertos SATA independientes, llénala de discos SSD o NVMe. El RAID por software de Linux es más que suficiente, y es preferible usar RAID 10 que usar RAID 5. Una estrategia razonable es construir un RAID 10 con *todos* los discos, alternando miembros en cada una de las controladores (porque la máquina *tiene* que tener varias controladoras). Encima de eso pones un VG, y luego repartes el espacio con LVs para cada cliente.

---

Asegúrate que la máquina tenga tarjetas de 1Gbps o 10Gbps, y que el switch tenga esa capacidad. Una red de 10/100Mbps sólo es suficiente para una demanda mínima.

---

La velocidad del CPU no es tan importante como la cantidad de núcleos, para poder soportar varios hilos simultáneos de abstracción de sistema de archivos. La cantidad de RAM tiene que ser tal que el buffer cache tenga una eficiencia del 80% o más -- ciertamente no puedes saber eso a priori, a menos que conozcas muy bien la disciplina de trabajo de tus usuarios, pero ciertamente puedes instrumentarla para determinar si tus cálculos son suficientes o no.

---

Luego es cuestión de que configures los protocolos que quieres ofrecer para exponer el disco: NFS, iSCSI, Samba... Eso dependerá de los clientes que se conecten.

---

Para muchos clientes, no tienes que hacer nada especial más allá de compartirles un volumen. Por ejemplo, las Apple hacen su «Time machine» simplemente si las apuntas a un disco en red.

---

Hasta ahora no he tenido buena experiencia con los FreeNAS. Uno estaba configurado en RAID5, otro tenía graves problemas de desempeño de red, y en ambos, el sistema de I/O (hardware) no era suficientemente rápido para las necesidades de la plataforma.

---

No es lo mismo una red casera, o una red de empesa pequeña de 10 personas, que tratar de construir un servidor de almacenamiento para una red grande, para virtualizar, o para tráfico intenso de I/O. Así que tienes que inverir bastante tiempo probando la capacidad de la red, la capacidad bruta del disco, la capacidad del sistema de archivo subyacente, y la capacidad iSCSI. Hay Software Libre que sirve para probar todas esas cosas.

View more