Acerca de Dani

Soy un ingeniero de software actualmente trabajando como desarrollador freelance. Estoy especializado en desarrollo backend aunque me estoy poniendo al día en cosas en las que antes era bueno y que dejé de lado. Me interesan las buenas prácticas en el desarrollo de aplicaciones, el código bien testado, la usabilidad y la accesibilidad del software. En internet, te enseño a programar a través de mi canal de YouTube, makigas.

¿Por qué no uso Feedly pese a que lo sigo recomendando?

Fui usuario de Google Reader hasta prácticamente su fecha de cierre. El cierre de Google Reader es curiosamente uno de esos eventos traumáticos donde pese a que ya han pasado prácticamente 10 años desde su cierre, para quienes lo usábamos sigue siendo algo que incluir en la tarjeta de presentación. «Hola, me llamo Dani y fui usuario de Google Reader».

¿Qué fue Google Reader?, se preguntará tal vez alguien que se perdió esa época del internet mágico. Era un lector de RSS. Por ponerlo en contexto de forma breve, RSS es un protocolo que permite que una página web comunique de forma automatizada de sus novedades, por ejemplo, las últimas noticias publicadas en un periódico o los últimos posts publicados en un blog.

Un lector RSS es un programa con el que podemos «suscribirnos» a varios sitios web, y se ocupará cada pocos minutos u horas de consultar mediante protocolo RSS si la web tiene algo nuevo que no hayamos visto todavía, y que lo mostrará en pantalla como si se tratase de un cliente de correo.

La mayoría de clientes RSS hacen un buen trabajo al detectar novedades duplicadas y así saber qué hemos visto ya y qué no, y tiene memoria suficiente como para guardar docenas de artículos que podemos leer vorazmente cada día, o dejar un tiempo esperando en una cola de lectura que finalmente podemos marcar como leída de golpe y sin compasión.


Tras su desaparición, estuve un par de años utilizando Feedly. Feedly es uno de esos servicios que suelo recomendar a cualquier persona que quiera probar el mundo del RSS. Es un servicio en el que puedes tirar un par de páginas web que quieras tener al día, y que cada vez que una de esas páginas publique algo interesante te lo mostrará al abrir la aplicación.

Quizá el mayor atractivo de Feedly es el motor de descubrimiento, y la posibilidad de encontrar nuevos sitios exclusivamente a través de feeds RSS. Esta es también una de las principales razones por las que, como digo, seguiría recomendando Feedly a personas que estén entrando ahora en el mundo del RSS.

Sin embargo, pese a que lo sigo recomendando, realmente no uso Feedly. Nunca terminé de cogerle gusto. Por lo menos en este caso veo más difícil que desaparezca, debido a que aunque tiene un modo gratuito, también tiene algunas limitaciones que te invitan a pagar por él si vas a usarlo mucho. Y mientras haya gente que siga pagando por el servicio, en principio debería seguir habiendo dinero para que Feedly siga existiendo como empresa ofreciendo su producto. A estas alturas Feedly ya ha vivido más años que Google Reader, así que parece que lo están consiguiendo.

Mi principal problema con Feedly está en la cantidad de características que ofrece, y en lo confusas que son algunas de estas características. No deja de ser un software cloud, y qué software cloud hoy en día puede denominarse un «servicio» si no está constantemente reinventándose y agregando nuevas funciones o cambiando su forma de ser cada pocos años para mantenerse fresco.

Durante mis últimos tiempos con Feedly, la mayoría de funciones que me encontré, como el algoritmo de prioridades o las funciones de equipo (¿por qué activarlas para todas las cuentas en vez de preguntarme si las quiero en primer lugar?), me resultaban muy complicadas de utilizar. No quiero que un algoritmo filtre las noticias por mí; precisamente la gracia del RSS es ver, como si fuese un cliente de correo, cada uno de los artículos nuevos de los sitios que explícitamente he solicitado seguir.

En definitiva, creo que Feedly es un buen servicio, y que también es un producto que le puede gustar a la mayoría de personas que solo quieren una forma simple de consumir contenido sin complicarse con aplicaciones. Sin embargo, después de un tiempo utilizándolo, descubrí que no es para mí, y lo sustituí por otro tipo de aplicaciones que sí me eran más prácticas.

También, todo hay que ponerlo en su debido contexto. La época de Feedly y de la muerte de Google Reader es también la época del boom de las redes sociales. En esa época, como la mayoría de personas, había movido mi forma de enterarme de la actualidad a las redes sociales, fundamentalmente Twitter y Facebook, así que apenas consultaba el RSS. Sólo hace un par de años, probablemente 2018 o 2019, que volví a preocuparme por esta dieta informativa mía y decidí volver a estar más pendiente del RSS.

El plan para 2023 es no programar

Evidentemente, es mentira. Trabajo como desarrollador, así que si no programo, no entra el dinero. Mi plan es no programar fuera del trabajo. Excepto que eso también es mentira, porque sí voy a seguir programando fuera del trabajo. Y aun así, siendo freelance, ¿qué puedo considerar trabajar? Voy a explicarme un poco.

En 2022 han hecho 15 años desde que tiré mi primera línea de código. Ni siquiera había terminado la secundaria y no tenía muy claro nada de lo que estaba haciendo. Todo el código hecho por esta época está perdido, porque no hacía copias de seguridad de nada y perder carpetas era algo demasiado frecuente en mí por entonces. Por un lado, esto es algo que da un poco de pena debido a que se tratan de las primeras cosas que hice y pueden tener algo de valor simbólico. Por otro… tampoco es que ese valor sea mucho en cualquier caso.

Siempre me he caracterizado por ser una persona cuya forma de trabajar es crear prototipos de cosas, para probar tecnologías, para hacer experimentos, o para crear una maqueta de algo serio que pueda ser explotado más adelante. Estos prototipos siempre se han hecho tirando líneas de código a partir de la nada, en muchas ocasiones con poco diseño y poca arquitectura detrás, allá donde sea posible. En algunos casos, como mucho una pensada a alto nivel y poco más.

Sin embargo, nunca he invertido tiempo de verdad en simplemente sentarme a aprender bases, o a aprender despacio sobre alguna tecnología concreta, con calma y sin intentar tratar de responder desde el principio a la pregunta ¿qué puedo hacer con esto? Cuando llevas demasiado tiempo en esto, la tentación de tratar de buscar usos prácticos para cualquier tecnología desde el primer momento es un riesgo real que puede impedir ver algunas cosas con claridad.

Esto es lo que busco durante 2023, nada más y nada menos. No digo que no vaya a programar cosas fuera de mi trabajo, porque tengo algunos compromisos abiertos que cerrar y algunos incentivos para acabar algunos proyectos que tengo abiertos ahora mismo. Parte de la razón por la que me hice freelance es para poder construir producto propio que pueda distribuir por mi cuenta, y quiero terminar algunas de las ideas en las que he empezado a trabajar.

He guardado ya algunas listas de reproducción, algunos libros y algunos artículos que quiero revisar y mi objetivo es tomar parte del tiempo que de otro modo pasaría programando cosas por mi cuenta y convertirlo en tiempo para aprender con calma durante 2023. Veremos a finales de año cuánto he avanzado con este plan.

Actualizada clave GPG

La clave pública GPG que había subida a mi página de contacto caducaba mañana. Esta clave la uso fundamentalmente para firmar releases en GitHub y otras plataformas, aunque alguna vez he recibido correo firmado y alguna vez hasta correo cifrado.

El mes pasado extendí el periodo de validez por un par de años más pero olvidé actualizar también la subclave de cifrado. Hoy he extendido la fecha de validez y he subido una versión actualizada de la clave. No termino de comprender cómo funciona un keyserver, o si la actualización verdaderamente es efectiva, o qué pasa con las versiones antiguas de la clave, pero en principio he testeado el archivo que hay subido en https://danirod.es/contact/pgp.asc desde otro ordenador y todo está funcionando, así que bien.

La extraña transición de WordPress a un editor de sitios genéricos

Minientrada

Me ocupo de mantener el WordPress que hace funcionar danirod.es actualizado, pero no siempre le presto atención a las novedades. Recientemente, mirando las novedades de WordPress en los últimos 12 meses, me encontré que está despegando una función en WordPress llamada Edición de sitio completa o Full Site Editing.

Esta función permite tratar un sitio web como si fuese un SquareSpace o una de estas páginas web, porque deja editar completamente todos los aspectos del tema, incluyendo los bloques que mostrar en la página de portada o en la página de una entrada. Se basa en la tecnología de Gutenberg, pero llevada más allá para permitir ver todo el sitio web como si fuese una zona editable controlada por bloques. Algunos de estos bloques son los esperables para una plantilla de sitio, como por ejemplo el bloque «Bucle de entradas de blog», el bloque «Título de entrada» o el bloque «Fecha de publicación».

Me estoy ocupando de probar esta nueva función en un sitio de staging y no termino de saber cómo sentirme al respecto. Por un lado, me resulta una forma bastante fresca de ver los temas y que permite modificar todos los aspectos de un sitio web de una forma mucho más clara para que no quede sin tratar ni el último píxel. Sin embargo, por el otro me da un poco de pena que WordPress termine de integrarse en este mundo de páginas web de temas genéricos y superlimpios donde todos los sitios web se ven iguales.

En los últimos años, los temas por defecto se han caracterizado por un diseño más brutalista y tipografías más grandes. Aunque esto genera sitios webs más limpios donde solo hay una columna de texto sin distracciones a los lados, resulta un poco incómodo tener páginas web que griten tanto con esos tamaños de tipografía. Además, incluso en algunos casos considero que un aside en forma de barra lateral le puede dar un poco de personalidad a un blog pequeño e incluso un toque retro, ahora que está de moda que todos los sitios web se vean iguales.

Hasta ahora he intentado usar los temas preinstalados de WordPress de forma intencional, para poder centrarme en el contenido, pero también intentar permitir que el sitio comunicase unas intenciones sin decir nada, simplemente a base de una combinación de colores o widgets de barra lateral. Sin embargo, continúo jugando en un entorno de pruebas para ver si puedo encontrar una combinación bonita pero que a la vez no le quite la personalidad a lo que hago.

Mi workflow con KeePass

Minientrada

Llevo años utiliando KeePass para gestionar las contraseñas de mis sitios web. Mi base de datos tiene a estas alturas probablemente 6 o 7 años y ha sido usada a través de múltiples aplicaciones que son capaces de comprender el formato de la base de datos.

En este momento, la aplicación que utilizo en mis ordenadores para poder acceder a mi base de datos es KeePassXC. Como es multiplataforma, es muy fácil de instalar en todas partes: Windows, Linux, FreeBSD, MacOS… Por otra parte, también he usado aplicaciones para Android en el pasado, y ahora que uso iOS e iPadOS, utilizo KeePassium acceder a las contraseñas ahí.

KeePassium se vuelve mucho más directo y personal, por ejemplo, cuando se activa el desbloqueo con huella o con Face ID, para evitar tener que teclear todo el rato la contraseña. Esto también me resulta práctico si tengo que desbloquear una contraseña en algunos sitios donde no me gustaría que alguien me viese pulsar teclas en la pantalla de mi móvil, como es el transporte público. También soporta integración con el autocompletado de contraseñas nativo de iOS.

No mucha gente sabe que una base de datos de KeePass vale para algo más que para guardar usuarios y contraseñas. Cada entrada de KeePass soporta archivos adjuntos y otro tipo de datos extra, de modo que aquí algunos trucos avanzados que uso en mis bases de datos:

  • Gracias a la función de archivos adjuntos, utilizo mi base de datos de KeePass para guardar otro tipo de cosas que no son contraseñas. Una copia de mis claves SSH, una copia de mi certificado GPG, los PKCS de la administración pública, y el keychain que hace falta para firmar APKs antes de subirlos a la Google Play Store.
  • La función de atributos también es ideal para guardar notas secretas, por ejemplo, con los códigos de un solo uso necesarios para recuperar una cuenta que tenga activo el 2FA en caso de emergencia.
  • Algunas copias de seguridad de archivos sensibles, como el archivo que uso para controlar mis finanzas personales, también lo puedo cargar como adjunto en una entrada de KeePass que no tiene contraseñas ni nada.
  • Es posible utilizar KeePassXC también como proveedor OTP, en vez de aplicaciones del móvil tipo Google Authenticator. Esto lo pongo a prueba constantemente en mi ordenador del trabajo, donde tengo otra base de datos diferente para las cuentas del trabajo, y funciona de forma excelente.
  • Es posible personalizar las carpetas y las entradas con iconos propios. KeePassXC también tiene la opción de descargar automáticamente el favicon de un sitio web para emplear como icono, lo que hace más fácil ubicar una cuenta en una tabla muy grande gracias a que se puede encontrar por el icono.
  • Aparte de crear contraseñas aleatorias y asociarlas automáticamente a nuevas entradas en la base de datos, es posible usar un generador independiente que no está conectado a nada, pero que te deja igualmente copiar la contraseña generada. Empleo esta función bastante en el trabajo para generar contraseñas aleatorias cuando me piden que registre en algunas aplicaciones de intranet cuentas de usuario de otras personas, si luego voy a tener que mandarles una contraseña inicial. Al margen de que se acuerden de cambiarla o no luego, por lo menos es más seguro que iniciarla a 123456.

Dos meses usando Apple Sillicon

Hace un par de meses, me cambiaron el ordenador del trabajo por un modelo más reciente. Cuando me lo renovaron, el modelo que me asignaron era uno de los recientes que utiliza la arquitectura Apple Sillicon y un procesador M1, como el que están usando ya en algunos iPad. Aquí cuento algunas de las cosas buenas y malas que me he encontrado en estos dos meses.

Cosas positivas

Mi opinión está posiblemente sesgada debido a que este ordenador no deja de ser un ordenador de trabajo. No es mío realmente, es prestado y no me pertenece, y tampoco tiene cargado software que no tenga que ver con mi trabajo, así que más allá de editores de textos, entornos de Node.js y otras aplicaciones que necesito para trabajar, no tiene gran cosa. No hay editores de vídeo, no hay juegos, no hay nada de lo que emplearía en un ordenador más personal.

También mis impresiones podrían estar sesgadas por el anterior modelo, que era un 2015, de modo que su procesador ya tiene unos cuantos años y eso puede hacer que algunos programas recientes no vayan tan bien. Y, sin embargo, lo poco que tengo lo veo con un rendimiento bastante bueno. Por hacer una comparación a base de lo que he visto en mi día a día:

  • En mi anterior ordenador tardaba en torno a unos 10 minutos en instalar Ruby a través de rbenv. Para instalar Ruby, rbenv compila Ruby desde el código fuente, así que el proceso de instalación incluye asegurarse de que hay compiladores de C instalados, descargar y compilar OpenSSL, y finalmente descargar y compilar todo el runtime de Ruby. En mi ordenador con Apple Sillicon y procesador M1, esto le toma 3 minutos, o sea, una tercera parte del tiempo.
  • En mi anterior ordenador, ejecutar una suite de tests completa del proyecto con el que más tiempo paso le podía llevar entre 20 y 25 minutos. En el Apple Sillicon, toma de 5 a 6 minutos.

De cara a la parte térmica, en dos meses todavía estoy esperando a escuchar alguna vez el ventilador de mi ordenador. Ni siquiera cuando estoy ejecutando tests más complejos o haciendo operaciones más intensas lo he llegado a escuchar. Alguna vez lo he notado un poco caliente, pero muy poco. Casi ni podría decir que se calienta mucho.

Y de batería, resulta impresionante como puedo estar toda la mañana trabajando con él sin enchufarlo a la red para luego encontrarme la batería al 70% o al 75%. Incluso lanzando servidores, corriendo tests, usando el navegador web, teniendo varias aplicaciones Electron en ejecución o entrando en videollamadas.

En cuanto a compatibilidad, existen varias aplicaciones que todavía son Intel, pero no lo notas, debido a que funcionan igual que una aplicación ARM, sin pérdida de rendimiento. Fundamentalmente, veo esto en aplicaciones Electron, donde usan algunos runtimes antiguos que todavía son Intel y que aún no han actualizado a Sillicon.

Para la línea de comandos también es posible usar binarios Intel si se ejecuta a través del wrapper arch, por ejemplo arch -arch x86_64 terraform para ejecutar una versión x86_64 de Terraform. He elegido Terraform como ejemplo, precisamente, porque algunos plugins que no estén actualizados puede que sólo tengan versión Intel en el registry; así que al final es más conveniente instalar todo Terraform como una aplicación Intel para no llevarse sorpresas cuando un Terraform ARM trata de invocar un plugin que no es compatible.

Cosas negativas

No obstante, no es oro todo lo que reluce, y aquí algunas de las cosas negativas que he encontrado en el M1 en estos meses:

  • Aunque es algo que en los últimos modelos ya están corrigiendo, mi ordenador es de primera generación, de modo que el número máximo de pantallas externas que puedo enchufar por lo general es… una y no más. Reportan que con docks compatibles con DisplayLink es posible usar más de una, pero con un cable USB-C ordinario o con un adaptador genérico HDMI a USB-C, aparte de la pantalla interna sólo se hace posible trabajar con una pantalla a la vez.
  • El único punto donde he encontrado conflictos en la compatibilidad con el procesador es, irónicamente, en línea de comandos. Todavía está pendiente de salir una versión de GCC que tenga soporte real para darwin-arm64, de modo que la única alternativa al clang es utilizar una versión de GCC en modo Intel. Por otra parte, algunas bibliotecas nativas de Node.js tienen problemas para compilar, por lo que al final lo más seguro que encuentro es emplear versiones Intel de Node.js a través de Rosetta. Tengo dos instalaciones de Homebrew, una Intel y otra ARM, por esta razón.
  • Como el procesador es ARM y no Intel, si se usa Docker o Podman se usará también un kernel Linux para ARM dentro del hipervisor, así que hay que tener esto en cuenta si los Dockerfiles no son compatibles o descargan directamente binarios para la arquitectura incorrecta.

Opinión final

No obstante, pese a que lo de que no acepte más de una pantalla en los primeros modelos es una cagada bastante grande, mi resumen general sobre el procesador M1 (y todos los que han venido detrás de él) es que es una tecnología revolucionaria. El M1 ha agitado bastante las bases de los procesadores para ordenadores normales. Quitando algunos modelos de la Surface que pueden tener un buen rendimiento parecido al de un iPad Pro, ARM hasta ahora ha sido visto principalmente como procesador para computación móvil o para ordenadores pequeños como la Raspberry Pi o los Pinebook (1). Sin embargo, para ordenadores normales de escritorio hasta ahora nunca ha habido nada excesivamente sorprendente. El M1 es uno de los primeros procesadores que busca llevar ordenadores con rendimiento equivalente a un Intel a las mesas de trabajo o de entretenimiento. Algunos fabricantes se han empezado a animar. Por ejemplo, Lenovo está preparando el lanzamiento del X13s para este 2022, un portátil general que utiliza Snapdragon que pretende darle algo de vidilla al ecosistema Windows ARM, el cual lleva existiendo varios años sin que esté destacando demasiado por el momento.


(1) En realidad, esta frase está ignorando procesadores ARM como el A64FX, el cual está siendo usado por algunos computadores como el que desde hace un par de años lidera el Top 500.

GitHub Code Search es un buen invento

Minientrada

Estas semanas estoy aprendiendo demasiadas cosas nuevas.

  • Decidí empezar a probar Emacs, lo que me ha llevado a consultar cómo utilizar algunas propiedades para meter en mi archivo de configuración, o cómo utilizar algunos de los paquetes que he instalado en mi distribución.
  • También estoy volviendo a intentar aprender Rust, lo que me lleva a necesitar buscar información sobre cómo utilizar una determinada función, estructura o crate.

A pesar de que muchas bibliotecas de desarrollo tienen manuales, wikis y otros archivos de documentación, una de mis formas favoritas de buscar ayuda sobre cómo emplear una biblioteca, paquete o este tipo de cosas es GitHub Code Search. Sinceramente, desconozco si en este momento sigue siendo una beta privada o si ya todo el mundo tiene acceso a CS, pero a estas alturas me resulta un recurso vital, y creo que más gente debería conocerse estos trucos. A veces puedes aprender más a usar una función o una biblioteca consultando cómo otras personas la están empleando en sus programas de código abierto que hayan publicado en GitHub, que intentando comprender una documentación que puede estar escrita mejor o peor.

Sistemas operativos alternativos interesantes

Minientrada

Algunos sistemas operativos que son software libre o código abierto que sigo, de cara a ver tendencias o a modo de referencia para consultar arquitecturas interesantes o aprender. El requisito para salir en esta lista es:

  • Tener el código fuente abierto de tal forma que se pueda consultar la implementación de piezas concretas del sistema operativo.
  • Estar disponible preferentemente para una de las plataformas de Intel (x86 o x86-64).
  • Estar programado de una forma simple o que no sea una pesadilla de comprender o navegar (lo siento, ReactOS).

Estos son más académicos:

  • xv6: está pensado como sistema operativo académico que se usa en universidades donde se enseñan cosas relacionadas con el desarrollo de sistemas operativos. Tiene código fuente y también un libro en PDF.
  • ULIX: otro sistema operativo de tipo UNIX. Está escrito en programación literaria así que el código fuente está dentro del PDF del libro. Muy ligado a la arquitectura x86, pero bien documentado.
  • HelenOS: un micronúcleo. Me gusta como referencia porque soporta muchas arquitecturas, y porque al ser otro sistema operativo académico, tiene muchos papers con información para aprender.
  • GNU Mach: GNU Hurd es un microkernel, pero GNU Mach es el núcleo del microkernel. En este repositorio es donde está el código dependiente de arquitectura y el entrypoint Multiboot, así que es un buen punto durante las primeras etapas para tener como referencia.

Otros sistemas operativos que son catalogables como homebrew. No creo que sea de muy buena educación copiar o sacar ideas, porque la gracia está en innovar, pero a modo de referencia práctica para poder resolver problemas que en la teoría no se explican bien (como el

Nota: posiblemente lo mejor si quieres una lista viva es que te suscribas al hilo del foro OSDev donde la gente comparte pantallazos de su progreso. Muchos proyectos desaparecen sin que se vuelva a saber nada de ellos, pero otros proyectos nuevos aparecen frecuentemente. El topic OSDev de GitHub también te mantiene al día.

Menciones honoríficas:

  • ToaruOS: el veterano en cuanto a sistemas operativos homebrew, está a punto de alcanzar la versión 2.0. Se ha vuelto mucho más complejo con la inclusión de algunos componentes, pero seguir su desarrollo es interesante.
  • Manganarm: apuesta muy fuerte por un micronúcleo, busca compatibilidad con POSIX y Linux, se acerca a Wayland, soporte para virtio.
  • Essence: estéticamente muy avanzado, innovación en interfaces de usuario (todo el sistema está orientado a pestañas).
  • SerenityOS: obligatorio mencionarlo; fuertes estéticas vintages noventeras. Si te pillas un año sabático y te dedicas exclusivamente a un proyecto de este tipo (cosa que no tengo muy claro si está bien o mal), consigues algo como esto.

Pero también hay otros que sigo como:

  • MollenOS: modular, soporte para múltiples arquitecturas.
  • MOROS: escrito en Rust, con una estructura limpia basada en un monorepo. 64 bits pero BIOS.
  • SOSO: Monolito escrito en C, UNIX-like, simple de comprender y seguir. Pasa la prueba del DOOM.

Recursos para empezar a programar núcleos

Minientrada

Así que quieres programar tu propio núcleo como base para fabricar un sistema operativo que destrone a GNU/Linux, eh. Te lo advierto: apenas vas a pasar tiempo programando. La mayor parte del tiempo se va a ir en consultar información en internet, escribir el pseudocódigo de funciones y diseñar algoritmos.

Estos son los recursos que suelo consultar más, por si te sirven de algo:

  • La wiki de OSDev.org es territorio sagrado. Hay cosas que están un poco anticuadas. Hay cosas que están mal. Hay cosas que están a medio escribir desde hace 15 años. Pero sin embargo, es mejor que nada. Aunque hoy en día está más modernizado, y cuenta cosas como desarrollo para la plataforma ARM, su punto fuerte es desarrollo para la plataforma Intel (x86 y x86_64).
  • Por relación, el foro de OSDev.org. Si te abres una cuenta, el software del foro te mostrará los nuevos hilos para que puedas ver qué se cuenta. Se hacen preguntas y en general es un buen recurso para buscar ayuda a veces. Su hilo vivo de libros recomendados te puede dar ideas para consultar más, y su hilo vivo de más de 200 páginas y 15 años de historia donde puedes enseñar el aspecto de tu proyecto te puede inspirar o matar de envidia.
  • El topic #osdev en GitHub. Hay bastante movimiento y puedes encontrar repositorios con otros sistemas en los que están trabajando otras personas, también para ver qué se está moviendo. Hay también algunos tutoriales y guías en algunos repositorios en este tag.
  • El Discord de Low Level Programming contiene discusiones y conversaciones interesantes y hay canales dedicados a esto, además de hablar de programación de bajo nivel. Te vas a inflar a programación de bajo nivel, así que más vale que te guste y te encuentres confortable.

Según el camino que quieras seguir, hay más recursos en esa categoría. Salvo que te apetezca comenzar creando un cargador de arranque de los de toda la vida de 0x7C00 o te interese programar para EFI, lo más probable hoy día es que empieces jugando con programas que puedan ser cargados por algo ya existente como GRUB o Limine.

  • La especificación Multiboot 1 es necesaria tenerla a mano si quieres entender la estructura de datos que GNU GRUB te proporciona cuando arranca tu programa. Es antigua, pero muy portable. Incluso QEMU es capaz de lanzar programas compatibles usando el flag -kernel, sin necesidad de incorporar un cargador de arranque ni generar una ISO.
  • La especificación Multiboot 2, aunque también tiene muchos años, es todavía experimental. No todos los cargadores de arranque (además de GNU GRUB) lo soportan, así que puede ser un poco más complicado de depurar y arrancar. Sin embargo, soporta aspectos novedosos como más arquitecturas de ordenador además de Intel 32 bit.
  • Limine busca ser un cargador de arranque moderno y alternativo a GNU GRUB. Además de valer como cargador de arranque de propósito general (es capaz de cargar Linux), tiene su propio protocolo de arranque llamado stivale, que puede ser una alternativa a crear una imagen para Multiboot.

Aunque estos protocolos de arranque son técnicamente compatibles con cualquier tipo de archivo binario que contenga código máquina, es probable que empieces creando tus primeros ejecutables de tu núcleo usando un compilador que genera binarios que siguen el formato ELF. La especificación de la ABI SystemV contiene un capítulo dedicado a comprender el formato ELF, algo que puede ser necesario para hacer cargadores dinámicos más adelante.

Eso sería todo por ahora. Próximamente, más.

Notas: estructura del formato de archivos TAR

Minientrada

Ayer en Twitch tocó desarrollo de sistemas operativos y empecé a trabajar en la implementación de un driver de sistema de archivos TAR para mi sistema operativo. El objetivo es poder incrustar en la distribución un archivo TAR que contenga un ramdisk y montarlo al arrancar el sistema para poder acceder a más archivos (por ejemplo, recursos gráficos, archivos de texto…)

Este es un sistema parecido al que usan muchos otros sistemas operativos cuando introduces un CD de instalación al encender la máquina. El cargador de arranque del CD carga el ejecutable con el programa principal, pero los recursos, como el entorno LiveCD de Linux, vive en un archivo compacto que se carga en memoria para dar la apariencia de un entorno real.

Elegí el formato TAR porque es un formato muy sencillo de comprender. No aplica compresión, esencialmente cuando creas un archivo TAR estás concatenando el contenido de todos los archivos que quieras incorporar en el archivo. Cada archivo lleva al principio una cabecera que contiene sus metadatos: nombre, tamaño, tipo de archivo, permisos…

Un archivo TAR está dividido en bloques. Un bloque tiene 512 bytes. O sea, los primeros 512 bytes del archivo (bytes 0 a 511) forman el bloque 0. Los siguientes 512 (bytes 512 a 1023) forman el bloque 1. Los siguientes 512 (bloque 1024 a 1535) forman el bloque 2… todos los componentes de un TAR están alineados respecto a un bloque. Por ejemplo, la cabecera de un archivo siempre empieza al principio de un bloque y ocupa todo el bloque. Si sobra sitio después de cada bloque, se rellena con ceros para que la siguiente sección empiece al principio del siguiente bloque.

Entonces, ¿de qué manera está compuesto un archivo TAR? Para cada uno de los archivos que haya dentro, se vuelca un bloque con los metadatos y luego cero, uno o varios bloques con el contenido del archivo. Esto se repite en bucle para cada archivo que haya en el TAR. Un TAR no tiene metadatos generales: haz un hexdump de un TAR (no comprimido) que tengas a mano y verás que empieza directamente con los metadatos del primer archivo. Al final del archivo TAR hay dos bloques en blanco (o sea, 1 KB lleno de ceros).

La estructura de metadatos es binaria y puede ser accedida a través de registros. El manual de usuario de GNU TAR tiene un capítulo dedicado a la especificación del formato también, y ahí se encuentra un ejemplo de cómo sería la estructura de datos para acceder a los metadatos:


struct posix_header
{                              /* byte offset */
  char name[100];               /*   0 */
  char mode[8];                 /* 100 */
  char uid[8];                  /* 108 */
  char gid[8];                  /* 116 */
  char size[12];                /* 124 */
  char mtime[12];               /* 136 */
  char chksum[8];               /* 148 */
  char typeflag;                /* 156 */
  char linkname[100];           /* 157 */
  char magic[6];                /* 257 */
  char version[2];              /* 263 */
  char uname[32];               /* 265 */
  char gname[32];               /* 297 */
  char devmajor[8];             /* 329 */
  char devminor[8];             /* 337 */
  char prefix[155];             /* 345 */
                                /* 500 */
};

Un pequeño detalle es que, para mejorar la compatibilidad con procesadores que sean big endian, se decidió que el formato TAR guardaría los números directamente en ASCII, en vez de codificados como binario. O sea, que el número 1000 no se guarda convertido a binario, porque entonces habría que saber si el sistema es big endian (0x03 0xE8) o little endian (0xE8 0x03). En su lugar, se guarda tal cual en ASCII, codificado como octal («1750», que es 1000 en base 8). Al final de cada cadena de estas, hay un caracter \0 de fin de string. Es posible convertir entre una de estas «cadenas octales» y número int normal.

Después del bloque de metadatos, el siguiente bloque contiene el contenido del archivo. Puede ocupar uno, dos, los bloques que sea. El último bloque del archivo también tiene ceros al final del bloque si sobra espacio, para que el siguiente archivo empiece al principio del siguiente bloque.

El campo typeflag de la estructura de metadatos indica el tipo de archivo: archivo regular, directorio… esto es importante porque en las carpetas se guarda su nombre y sus permisos, pero como son carpetas, el tamaño es 0 y no tiene contenido. Después de un bloque de metadatos de una carpeta, viene otro bloque de metadatos que describe el siguiente archivo que haya en el archivador TAR.

Además de eso, TAR es capaz de representar enlaces simbólicos e incluso archivos de dispositivo, ya que tiene campos para guardar el devmajor y el devminor.