Las entrañas, las contrapartidas y las decisiones detrás de un producto y de los sistemas sobre los que funciona, incluido un sistema operativo y las herramientas que lo rodean. Es lo que nos habría gustado encontrar cuando estábamos descubriéndolo. Sin listas de relleno, sin «diez consejos».
El sistema de init es el primer proceso de la máquina y el padre de todo lo demás. Esta es la propiedad con la que juzgamos a los candidatos, lo que nos da runit y lo que costó la elección.
Juzga un gestor de paquetes por lo que pasa cuando una instalación muere a medias. Juzga un modelo de actualización por cuándo pagas el cambio. Por qué 0dyssey se está construyendo sobre xbps y una base de actualización continua.
Un gestor en mosaico manejado con el teclado elimina una decisión que de otro modo tomas cientos de veces al día. El argumento, una configuración real de i3 y un balance honesto de los dos días que te cuesta.
SIGNAL, el sistema sobre el que funciona este sitio: por qué el oscuro es el acto principal, por qué los tokens llevan roles y no valores, por qué el negro puro es una trampa y por qué hay exactamente un acento.
Profundidad y legibilidad son ejes distintos: la abstracción que sostiene frente a la que atrapa, los valores por defecto como opiniones, los errores como la verdadera documentación.
El modo estricto línea a línea, las comillas, los arrays en lugar de eval, la limpieza con trap y las trampas que sobreviven a set -e. Los hábitos que mantienen honesto un script a las 3 de la madrugada.
Hay seis artículos publicados. El resto describe para qué sirve esta sección y dice claramente qué líneas aún no tienen nada.
Sistemas, seguridad, Rust, funcionamiento interno de los sistemas operativos, sistemas de IA. Escritos para leerse una vez, con cuidado, por alguien que luego los va a usar, no para que los hojee de pasada quien los encontró en una búsqueda.
Notas del desarrollo de 0dyssey y de las plataformas, escritas mientras el trabajo ocurre, con los callejones sin salida incluidos. La bitácora con fechas está en la página del sistema operativo y todavía no tiene entradas; los dos ensayos sobre sistemas publicados aquí son lo más parecido que hay hasta ahora.
Explicaciones que enseñan el concepto en lugar de la API. De las que siguen siendo útiles después de que la biblioteca que mencionan haya sido sustituida dos veces.
La gente compra ingeniería a quienes entienden claramente de ingeniería, y la forma más rápida de demostrarlo es explicar algo difícil con claridad, en público, antes de que nadie te lo haya pedido.
Así que esto no es un calendario de contenidos ni marketing disfrazado de blog. Un texto se escribe cuando el trabajo produce algo que merece dejarse por escrito, lo que significa que el ritmo de publicación sigue a la ingeniería y no al revés.
La misma regla vale para las bitácoras de desarrollo: describirán lo que realmente pasó, incluidas las partes que estuvieron mal durante una semana. Una bitácora de desarrollo que solo contiene buenas decisiones es una nota de prensa.
Tres lectores, y las líneas de arriba están dirigidas a ellos. Si ninguno eres tú, esta sección no va a merecer tu tiempo, y es una respuesta perfectamente válida.
Personas que quieren entender las capas que hay debajo de sus abstracciones. El framework no es el fondo de la pila, y todo lo que hay debajo puede conocerlo cualquiera que esté dispuesto a leerlo.
Personas listas para ir más allá de la superficie y ser dueñas de su entorno: elegir qué se ejecuta al arrancar en lugar de heredarlo, y saber por qué está cada pieza.
Diseñadores que quieren la fluidez técnica para entregar en lugar de pasar el relevo. Suficiente conocimiento de la máquina para llevar un diseño hasta producción y defenderlo con argumentos técnicos.
Las formas que toma la escritura, desde una nota breve hasta algo que se extiende por varias piezas. Léelo como el alcance de la sección.
Nada de lo que sigue está en cola, programado o en producción, y nada es un compromiso de cadencia. Una pieza aparece cuando el trabajo que hay detrás produce algo que merece dejarse por escrito.
Un problema, una solución y el razonamiento que llevó a ella. De lo que, si no, se quedaría en un cuaderno privado y se volvería a deducir desde cero un año después.
Un solo sistema llevado hasta el fondo: el kernel, init, el empaquetado, el shell, la propiedad y los tiempos de vida en Rust. Escrito para leerse una vez, con cuidado, por alguien que luego lo va a usar.
Notas tomadas mientras se construye un sistema, incluida la semana que salió mal. Siguen a la ingeniería, así que empiezan cuando hay un desarrollo que merezca registrarse.
Un tema demasiado grande para una sola pieza, repartido en varias: un sistema entero en orden, en lugar del único rincón que da un buen artículo independiente. Ninguno está en marcha todavía.
Describe el problema con tus propias palabras. Recibirás una respuesta directa sobre lo que exige construirlo de verdad y sobre cómo funcionaría un encargo.