/home/lucio.albenga.es

Torificando programas en 2 minutos o menos.

lfa — Wed, 29 Apr 2026 00:00:00 +0100

Llevo un tiempo dándole vueltas a escribir esta entrada porque parece la típica entrada inútil o de "clickbait" demasiado habituales en estos últimos años pero la realidad es que, a un nivel básico, hacer que cualquier programa que se conecte a internet lo haga através de la red TOR lleva 2 minutos o menos.

Cualquier usuario de un sistema GNU/Linux o BSD tiene todo lo necesario en el repositorio de paquetes de su sistema. Vamos a ver cómo se hace con Devuan (o Debian) y con Artix (o Arch).

Primero se instala el software necesario:

sudo apt install tor torsocks # en el caso de Devuan 
sudo pacman -Su tor torsocks  # en el caso de Artix

Una vez instalados los dos programas arrancamos TOR con el comando:

sudo tor

A continuación se ejecuta el programa deseado con el comando:

torsocks nombre_programa

Por ejemplo, si se quiere que el navegador por terminal lynx se conecte via TOR, se haría con el comando:

torsocks lynx

Esto es todo. Ya tenemos lynx funcionando a través de TOR.

Obviamente esto es lo más básico. Te recomiendo que leas la página man de TOR y de torsocks para conocer todas las posibilidades de estos programas y que le saques todo su potencial.

LibreCan 2026

lfa — Tue, 24 Mar 2026 00:00:00 +0000

Los habituales ya sabéis que suelo ser mucho más activo en mi madriguera gopher¹ que en esta web pero la verdad es que he estado desaparecido de todos lados prácticamente desde principios de año porque he estado ocupado con algunas cosas personales y también organizando y preparando la LibreCan 2026.

Este año es un evento algo mayor que el del año pasado. La gente de Canarias GoRetro han sido muy amables al cedernos su espacio para llevar acabo el evento por lo que, a iniciativa de los miembros de LibreCan, decidimos aprovechar para incluir una serie de ponencias/demos cortas en el programa de este año. También habrá sorteos con alguna sorpresita que espero que le gusten a la gente. Aunque parezca una tontería organizar un evento por pequeño que sea requiere de tiempo, energía y, en este caso, también algo de dinero.

Hoy se ha publicado la página oficial del evento LibreCan 2026² así que ahora empezaré a ponerme al día con el resto de cosas y puede que a estar más activo en la red.

Si eres de Canarias espero verte en la LibreCan 2026 ;-)

Notas al pie de página:

gopher://lucio.albenga.es

https://librecan.com

Configurando una cadena de herramientas GCC para programar Arduino en C

lfa — Mon, 01 Dec 2025 00:00:00 +0000

Que vaya por delante que no soy un experto en Arduino pero cuando decidí empezar con ello tenía claro que quería programarlo en C puro y duro, y que de entrada compraría algo compatible en lugar que el original para ver si me iba a interesar o no. Probablemente porque sea programador me pareció mucho más interesante lidiar con los detalles de bajo nivel, datasheets¹ y ese tipo de cosas, en lugar que permitir que el Arduino IDE y sus librerías me ocultaran cosas. Tampoco le veía mucho sentido a aprender o usar un pseudo C++ sabiendo ya C.

En estas últimas semanas, desde que Qualcomm ha comprado Arduino, he visto que hay un montón de "preocupación" por parte de la gente sobre qué va a pasar ahora, sobre si Qualcomm va a fastidiarlo todo con las típicas prácticas corporativas y demás. Parece ser que mi decisión de hacer las cosas en C y no usar el software de Arduino ha sido más que acertada ya que ahora mismo a mi no me afecta en absoluto lo que sea que haga Qualcomm.

En este pequeño howto voy a explicarte cómo instalar una cadena de herramientas basada en GCC para que tu también puedas programar tu Arduino en C, o si lo prefieres en C++, y te voy a enseñar todos los pasos desde hacer un pequeño programa hasta cargarlo en tu placa sin utilizar el software oficial de Arduino.

Empezamos instalando los programas necesarios. Probablemente tu sistema operativo POSIX ya tenga todos los paquetes. En este howto vamos a ver cómo se hace con FreeBSD y Devuan GNU+Linux.

pkg install avr-gcc avr-binutils avr-libc avrdude      # FreeBSD
sudo apt install gcc-avr binutils-avr avr-libc avrdude # Devuan

Una vez instalados los programas, abre tu editor de textos favorito y escribe el programa que viene a continuación. Este programa es el típico que hace parpadear la luz del Arduino y lo vamos a usar para probar la cadena de herramientas y ver cómo encaja todo. Para que puedas seguir los pasos de este howto guarda este archivo con el nombre blink.c.

#include <avr/io.h>

#define F_CPU 16000000UL /* necesario para <util/delay.h> */
#include <util/delay.h>

#define DELAY 1500 /* milisegundos */

int
main (void) {
        DDRB |= _BV(DDB5);
        for(;;) {
                PORTB |= _BV(PORTB5);
                _delay_ms(DELAY);
                PORTB &= ~_BV(PORTB5);
                _delay_ms(DELAY);
        }
}

La constante F_CPU debe coincidir con la frecuencia de la CPU (velocidad de reloj) de tu Arduino. Yo tengo una placa compatible con Arduino UNO y en mi caso este valor es 16MHz

A continuación toca compilar el programa. Para ello teclea lo siguinte en tu terminal:

avr-gcc -Os -mmcu=atmega328p -o blink blink.c

Ahora hay que convertir el archivo binario blink, a un binario compatible con Arduino:

avr-objcopy -O ihex -R .eeprom blink blink.hex

Ha llegado el momento de conectar tu Arduino a uno de los puertos USB de tu ordenador. Comprueba en qué puerto se ha conectado. Para ello puedes usar, por ejemplo, el comando dmesg. En mi Devuan la salida de dicho comando, una vez conectada mi placa, es la siguiente:

[3975174.307519] usb 2-1: new full-speed USB device number 79 using xhci_hcd
[3975174.456593] usb 2-1: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.63
[3975174.456606] usb 2-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[3975174.456612] usb 2-1: Product: USB2.0-Serial
[3975174.458699] ch341 2-1:1.0: ch341-uart converter detected
[3975174.459258] usb 2-1: ch341-uart converter now attached to ttyUSB0

Esto quiere decir que la placa está conectada a /dev/ttyUSB0 (/dev/ttyU0 en mi FreeBSD). Para cargar el programa en tu placa Arduino utiliza el comando siguiente (sustituye /dev/ttyU0 o /dev/ttyUSB0 por el dispositivo que corresponda a tu caso):

avrdude -F -V -c arduino -p m328p -P /dev/ttyU0 -U flash:w:blink.hex    # FreeBSD
avrdude -F -V -c arduino -p m328p -P /dev/ttyUSB0 -U flash:w:blink.hex  # Devuan

La salida del comando anterior debería parecerse a esta:

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file blink.hex for flash
         with 176 bytes in 1 section within [0, 0xaf]
         using 2 pages and 80 pad bytes
avrdude: writing 176 bytes flash ...

Writing | ################################################## | 100% 0.06 s 

avrdude: 176 bytes of flash written

Tal y como decía antes, el programa es el típico que hace parpadear la luz del Arduino así que comprueba si la luz del tuyo está parpadeando. Si parpadea significa que todo ha ido como la seda. ¡Felicidades! Ya tienes tu cadena de herramientas operativa y ya sabes los rudimentos para crear y cargar tus programas en tu placa Arduino.

Espero que este howto te haya servido para dar tus primeros pasos a la hora de programar tu Arduino en C y ten en cuenta que esto es solo un punto de partida por lo que te recomiendo que leas la documentación y/o la ayuda de todos los programas y comandos que has visto.

Notas al pie de página:

Datasheet del ATmega328P en la web de Arduino

Versiones 100% "free as in freedom" de Devuan y Debian

lfa — Sun, 16 Nov 2025 00:00:00 +0000

He visto en el blog de Simon Joseffsson que ha lanzado el proyecto "Debian Libre Live" para producir imágenes "Live" de Debian GNU/Linux solo con software libre, vamos lo que era Debian antes de tomar la decisión de incluir cosas non-free dentro de las imágenes principales de la distribución. Simon presenta el proyecto en su blog¹ y también puedes echar un vistazo al repositorio en Gitlab².

También me he enterado, a través del propio Simon, de que existe un proyecto similar pero con Devuan GNU+Linux, la distribución que utilizo, que es un fork de Debian sin SystemD ni otras aberraciones. El proyecto en cuestión es Gnuinos Linux-Libre³ y utiliza el kernel linux-libre⁴ por lo que podríamos decir que, por lo menos sobre el papel, este proyecto sería lo que debería ser Debian si no llevaran tantos años tomando tantas malas decisiones.

Si usas Debian o Devuan y prefieres el software libre al "open source" aquí tienes un par de distribuciones 100% "free as in freedom" que te pueden resultar interesantes.

Notas al pie de página:

Simon Joseffson: Introducing The Debian Libre Live Images

https://gitlab.com/debdistutils/debian-libre/debian-libre-live

https://www.gnuinos.org/

⁴

https://www.fsfla.org/ikiwiki/selibre/linux-libre/

Video: Entrevista a Mark McCahill y Farhad Anklesaria sobre Gopher

lfa — Sat, 15 Nov 2025 00:00:00 +0000

Hace unos días encontré en Internet Achive un archivo de John Goerzen¹: "2007 Gopherspace Mirror"² y dentro de este un video con una entrevista a Mark McCahill y Farhad Anklesaria, parte del equipo que desarrolló el protocolo Gopher. Decidí subir el video a PeerTube³, de hecho es el primer video que subo a PeerTube, porque considero que es una pieza importante de la historia de Gopher y también de internet. Puedes ver el video aquí y espero que lo disfrutes tanto como yo.

Notas al pie de página:

Página web de John Goerzen

2007 Gopherspace Mirror en Internet Archive

Video en mi PeerTube

De Git a Fossil

lfa — Wed, 12 Nov 2025 00:00:00 +0000

Hace un tiempo que en Git han empezado a trabajar en una propuesta para hacer obligatorio el lenguaje de programación Rust¹. A mi no me gusta Rust y, sobre todo, no me gusta su comunidad de personajillos extremistas que pretenden hacer tragar a todo el mundo su basura reescribiendo proyectos que llevan décadas funcionando, haciendo campañas de acoso y derribo en redes sociales y otras lindezas dignas de cualquier grupúsculo con ínfulas totalitarias. Por eso cuando veo que un proyecto pretende "obligar" el uso de o migrar de C a Rust, en la medida de mis posibilidades, huyo de él como si me persiguiera el Balrog del Señor de los Anillos con su látigo de fuego.

A lo largo de mis años he conocido y usado (o probado) muchos sistemas de control de versiones: RCS (Revision Control System), CVS (Concurrent Version System), SVN (Subversion), HG (Mercurial), BZR (Bazaar) y el susodicho Git, lo que significa que no tengo mayor problema en volver a cambiar así que empecé a buscar un sustituto para mis proyectos personales.

Las opciones eran volver a uno de los ya conocidos o mirar otra cosa y me acordé de Fossil. Empecé echando un vistazo por encima al código fuente y a leerme la documentación oficial² para enterarme de lo que ofrecía, de sus dependencias, de cómo se instalaba y configuraba, etc., y ví que tenía muchas cosas que me gustan:

Está hecho en C (aunque utiliza algo de js y de tcl para su funcionalidad web) y es un programa pequeño y eficiente que consume pocos recursos de hardware.
Su uso es más sencillo y natural (por lo menos para alguien que conoce otros sistemas como Subversion) ya que no contiene funcionalidades rebuscadas como el staging area de Git, que puede que sean útiles en proyectos grandes y complejos como el kernel Linux pero que para mí no tienen ninguna utilidad práctica.
Permite autoalojar un servidor en tu propia infraestructura de forma rápida y sencilla porque ya viene preparado para ello. De hecho ya tiene integrado un servidor y un sistema web con las vistas del control de versiones, wiki, sistema de tickets, etc. Sin embargo con Git hay que recurrir a soluciones externas como GitLab, Gitea o Forgejo y cada una de ellas es como mínimo una nueva dependencia.
No utiliza direcciones de correo en los commits sino que utiliza nombres de usuario por lo que si tu repositorio es público te evitas el que tu correo caiga en manos de las redes de spam o el tener que usar una dirección de correo específica para este tipo de cosas.
Es interoperable con Git en el sentido de que si surge la necesidad de volver a cambiar un repositorio a Git se puede hacer e incluso soporta la sincronización bidireccional entre un repositorio Fossil y uno Git³ (que es lo que usan Fossil y el proyecto Sqlite para mantener sus repositorios espejo en GitHub).

Teniendo en cuenta todo esto decidí instalarlo y migrar mis proyectos de Git a Fossil. A continuación vamos a ir viendo cómo hacer eso mismo.

Instalación de Fossil

El primer paso es instalar Fossil y es más que probable que ya se encuentre entre los paquetes de tu sistema operativo:

sudo apt install fossil # Devuan GNU+Linux
pkg install fossil      # FreeBSD

Tras ejecutar la instalación podemos comprobar que efectivamente se ha instalado ejecutando en terminal el siguiente comando:

fossil version

Ese comando devolverá algo como lo siguiente:

This is fossil version 2.21 [3c53b6364e] 2023-02-26 19:24:24 UTC

Importación de repositorios Git

En la documentación⁴ de Fossil nos ponen como ejemplo para exportar de Git e importar en Fossil el siguiente comando con una tubería:

cd nombre_de_repo
git fast-export --all | fossil import --git nombre_de_repo.fossil

Sin embargo yo lo hice de otro modo para poder ajustar algunas cosas y dejar los nuevos repositorios importados "bien". Como tenía varios repositorios creé dos carpetas distintas, una, git-exported, para almacenar los repositorios exportados y otra, fossils, para almacenar los nuevos repositorios.

mkdir ~/git-exported
mkdir ~/fossils

Ahora ya podemos empezar a exportar nuestros repositorios de Git:

cd nombre_de_repo
git fast-export --all > ~/git-exported/nombre_de_repo.export

Una vez que ya tenemos exportados todos los repositorios de Git nos vamos a la carpeta ~/fossils y los importamos con el comando:

fossil import --git \
       --rename-master trunk \
       --attribute "tu@correo.es tu_usuario" \
       nombre_de_repo.fossil ~/git-exported/nombre_de_repo.export

La opción --rename-master trunk renombra la rama master de Git como trunk en Fossil ya que Fossil, al igual que otros programas de control de versiones como Subversion, utiliza el nombre trunk para indicar la rama maestra. Si eres de los desafortunados que en lugar de "master" tienen su rama principal nombrada como "main" esta opción no es para tí y tendrás que consultar la documentación de Fossil si quieres renombrarla.

La opción --attribute "tu@correo.es tu_usuario" cambia la dirección de correo tu@correo.es en los commits de Git por el nombre de usuario tu_usuario, que en Fossil por defecto coincide con tu nombre de usuario del sistema. Lógicamente la dirección indicada debe existir en algún commit de Git. Si quieres cambiar más de una dirección de correo puedes hacerlo utilizando varias opciones --atribute:

cd ~/fossils/
fossil import --git \
       --rename-master trunk \
       --attribute "tu@correo.es tu_usuario" \
       --attribute "rms@gnu.org rms" \
       --attribute "linus@kernel.org torvalds" \
       nombre_de_repo.fossil ~/git-exported/nombre_de_repo.export

La salida del comando de importación del repositorio será algo como:

Rebuilding repository meta-data...
  100.0% complete...
Vacuuming... ok
project-id: e64b112b40eb3db188060ddb8deeaa96a6ad3b71
server-id:  bfbcd4bf8f0f64eaa2d832ddc3b4af00639624a6
admin-user: tu_usuario (password is "XAxPVZcNQ6")

Si te fijas, cada vez que importas un repositorio te da la contraseña de tu usuario administrador. Guárdala ya que la necesitarás para realizar determinadas operaciones con tu repositorio.

Servidor Fossil

Fossil tiene un servidor web embebido así que lo podemos aprovechar para crear un servidor autoalojado de forma rápida y sencilla. El método que expongo a continuación es suficiente para un sistema con pocos usuarios, en una red privada que no se puede acceder desde el exterior. Hay diferentes formas de configurar un servidor Fossil y algunas son mejores que otras dependiendo de las necesidades, por lo que te recomiendo revisar la documentación oficial.

Primero creamos una carpeta donde se guardarán todos los repositorios *.fossil en el servidor:

mkdir /ruta/a/mis/fossils

Luego copiamos nuestros repositorios fossil a dicha carpeta en el servidor:

scp *.fossil usuario@mi_server:/ruta/a/mis/fossils/

Ahora arrancamos el servidor Fossil de la siguiente manera:

fossil server --port 8043 \
       --cert /ruta/a/mi_certificado.pem \
       --pkey /ruta/a/la/clave/del/certificado.pem \
       --repolist /ruta/a/mis/fossils/

Si no tienes un certificado válido puedes arrancarlo con:

fossil server --port 8043 \
       --cert unsafe-builtin
       --repolist /ruta/a/mis/fossils/

Una vez arrancado el servidor, si pones la url https://dirección_de_servidor:8043/ en tu navegador deberías de poder acceder a una página con el listado de tus repositorios. Pinchando en cada uno de ellos te llevará a la página del repositorio en cuestión y, una vez en la página del repositorio, si te fijas en el menú de navegación hay una opción login. Si pinchas en esa opción y pones tu nombre de usuario y la contraseña que te devolvió el comando fossil import accederás como administrador y podrás configurar el espacio del proyecto a tu gusto. Para saber más consulta la documentación oficial de Fossil.

Si no apuntaste o has perdido la contraseña de tu repositorio Fossil la podrás recuperar con los siguientes pasos:

Entra en el servidor y dirígete a la carpeta dónde están tus repositorios fossil.
Si no tienes instalado el programa sqlite, instálalo siguiendo el método habitual de tu sistema operativo.
Abre el archivo mi_repo.fossil con sqlite:
```
   sqlite3 mi_repo.fossil
```
Una vez dentro de sqlite haz la siguiente consulta:
```
   select login,pw from user;
```
Esta consulta te devolverá algo como:
```
   tu_usuario|My3w2jRxt1
   anonymous|57EBCBD1AAE663B4
   nobody|
   developer|
   reader|
```
La contraseña es el segundo elemento de la fila (en este ejemplo la cadena My3w2jRxt1).
Sal de sqlite3 tecleando .quit.

Usando Fossil

A continuación pongo una guía muy breve sobre cómo dar unos primeros pasos con Fossil. Esta guía presupone que sabes usar Git, de forma muy básica, y es solo un punto de partida por lo que te recomiendo que leas la documentación de Fossil y su manual⁵.

Obteniendo ayuda

El comando de ayuda es imprescindible para ver qué comandos ofrece Fossil y para ver los usos y opciones de cada uno de estos comandos. La ayuda funciona igual que en Git:

fossil --help
fossil nombre_de_comando --help

Creando y clonando repositorios

Estos procesos son parecidos a los de Git pero no del todo. En Git lo habitual es que el repositorio de trabajo coincida con la carpeta de trabajo. En Fossil esto no es así, hay una clara diferencia entre el archivo del repositorio nombre_de_repo.fossil y la carpeta de trabajo nombre_de_repo.

Creando un nuevo repositorio

Creamos un nuevo repositorio con el comando:

fossil init nombre_de_repo.fossil

Este comando creará solamente el repositorio, esto es, el archivo nombre_de_repo.fossil. Para empezar a trabajar con él tenemos que "abrirlo" por lo que crearemos la carpeta de trabajo y abriremos el repositorio en ella:

mkdir mi_carpeta_de_trabajo
cd mi_carpeta_de_trabajo
fossil open /ruta/a/nombre_de_repo.fossil

También podemos indicarle a Fossil el nombre de la carpeta de trabajo y si esta no existe Fossil intentará crearla:

fossil open --workdir mi_carpeta_de_trabajo /ruta/a/nombre_de_repo.fossil

Clonando un repositorio

Clonamos un repositorio utilizando el comando fossil clone seguido de la url del repositorio. La url puede ser una url web, una url ssh, una ruta en un sistema de archivos, etc.:

fossil clone https://host/nombre_de_repositorio

Este comando descargará automáticamente el achivo nombre_de_repo.fossil y creará, al mismo nivel, la carpeta de trabajo nombre_de_repo. Si no queremos que cree la carpeta de trabajo ejecutamos el comando como:

fossil clone --no-open https://host/nombre_de_repositorio

Una vez clonado el repositorio, si tienes permisos para ello y tu intención es enviar tus commits al repositorio remoto, necesitarás configurarlo en la carpeta de trabajo con el comando fossil remote:

fossil remote https://usuario@dominio/nombre_de_repositorio

Este comando nos pedirá la contraseña de nuestro usuario y nos ofrecerá la posibilidad de guardarla para usarla en el futuro.

Consejo: Teniendo en cuenta la peculiaridad de Fossil de tener un archivo de repositorio por un lado y las carpetas de trabajo por otro yo lo tengo organizado tal que en mi /home tengo una carpeta fossils donde guardo todos los repositorios y luego tengo las carpetas de trabajo en el lugar más adecuado en cada caso.

Obteniendo información

A la hora de obtener información sobre el estado del repositorio y de nuestra carpeta hay ciertas diferencias con respecto a Git, sobre todo en el nombre y uso de los comandos.

Viendo el histórico

En Fossil los comandos fossil time y fossil timeline son los equivalentes del comando git log de Git. A continuación pongo ejemplos ordenados desde el que proporciona menos información al que proporciona más:

fossil time --oneline # similar a git log --oneline
fossil time
fossil time --medium
fossil time --verbose # similar a git log

Viendo los cambios en nuestra carpeta de trabajo

Para ver los cambios en nuestra carpeta de trabajo con respecto del repositorio hay varios comandos y cada uno de ellos tiene distintas opciones.

Para ver los archivos y carpetas que no están bajo control de versiones usamos:

fossil extras

Para ver los archivos que están bajo control de versiones y que han sufrido cambios:

fossil changes

Para ver una combinación de los dos anteriores usaríamos el comando:

fossil changes --differ

Para ver el estado del repositorio estilo a cómo lo veríamos en Git con el comando git status usaríamos el comando:

fossil status --differ

Viendo las diferencias

Para ver las diferencias entre los contenidos de nuestros archivos en la carpeta de trabajo y lo que hay en el repositorio utilizamos, al igual que en Git, el comando diff:

fossil diff

Para ver las diferencias entre un commit específico y la carpeta de trabajo:

fossil diff --from 2c26dd6b69 # 2c26dd6b69 es el hashtag del commit

Para ver las diferencias entre dos commits concretos:

fossil diff --from 2c26dd6b69 --to cd086a1045

El comando diff de Fossil no muestra los diffs en color. Si quieres esta característica echa un vistazo a la Wiki de Fossil⁶

Obteniendo los cambios de los demás

Fossil tiene una opción llamada autosync que viene activada por defecto. Esta opción mantiene sincronizado nuestro repositorio local con el repositorio remoto. Si tenemos activada la opción autosync podemos obtener todos los cambios del repositorio remoto (si lo hubiera) con el comando:

fossil update

En caso contrario la dinámica sería más parecida a la de Git. Tendríamos que hacer primero un pull para obtener los cambios y luego un update para que estos aparecieran en nuestra carpeta de trabajo:

fossil pull
fossil update

Versionando nuestros cambios

Como Fossil no tiene staging area, el comado commit se parece mucho más al de sistemas de control de versiones como Subversion que al de Git.

Si queremos hacer un commit con todos los cambios pendientes:

fossil commit

Este comando ejecutado de esta manera mostrará un editor para que podamos introducir el mensaje del commit. Sin embargo podemos pasarle el mensaje directamente si lo ejecutamos tal que así:

fossil commit -m "Mi mensaje de commit"

Podemos hacer un commit con solo determinados archivos específicos:

fossil commit archivo1 archivo2
fossil commit archivo1 archivo2 -m "Mi mensaje de commit"

Si tenemos activada la opción autosync el comando commit enviará nuestros cambios también al servidor remoto (si lo hubiera). En caso contrario tendremos que enviar los cambios al servidor remoto con el comando:

fossil push

Añadiendo y borrando archivos

Cuando tenemos archivos nuevos que añadir al control de versiones utilizamos el comando:

fossil add nombre_de_arhivo

Para borrar archivos del control de versiones utilizamos cualquiera de los siguientes dos comandos:

fossil delete nombre_de_archivo
fossil rm nombre_de_archivo

Por defecto los comandos de borrado no borran el archivo físicamente del disco sino que simplemente lo marcan para indicar que ya no se encuentra bajo control de versiones.

También existe un comando fossil addremove que añade al control de versiones todos los archivos que están en la carpeta de trabajo pero que no están bajo control de versiones y "borra" del control de versiones todos los archivos que están bajo control de versiones pero que ya no se encuentran en la carpeta de trabajo.

Ignorando archivos

La configuración es uno de los puntos donde hay varias diferencias importantes entre Git y Fossil por lo que te recomiendo revisar la documentación. Para ignorar archivos tenemos que crear en la carpeta de trabajo el archivo .fossil-settings/ignore-glob

cd mi_carpeta_de_trabajo
mkdir .fossil-settings
touch .fossil-settings/ignore-glob

Luego editamos los contenidos del archivo y podemos usar patrones⁷:

build/
3rdparty/
*.o
*/a.out

Ramas y etiquetas

El paradigma de Git hace mucho hincapié en el uso intensivo de ramas y también de las etiquetas. Sin embargo Fossil tiene unas características y un paradigma diferente, más clásico podríamos decir, por lo que los flujos de trabajo son distintos a los de Git.

Como no hago mucho uso de las ramas en mis proyectos personales, creo que para que te hagas una idea de las diferencias y así poder adaptar las características de Fossil a tu flujo de trabajo, o viceversa, lo mejor es que leas los siguientes enlaces de la Wiki de Fossil:

Interfaz web en local

No quiero terminar esta pequeña guía de Fossil sin dejar claro que se puede acceder y usar el interfaz web sin tener Fossil en modo servidor. Para ello solamente hay que ejecutar, desde dentro de la carpeta de trabajo, el comando:

fossil ui

Conclusión

Fossil me ha gustado mucho y, en mi opinión, es una mezcla casi perfecta entre un sistema de control de versiones centralizado como Subversion y uno distribuido como Git. Me gusta la simplicidad para ponerlo en modo servidor, su interfaz web y, sobre todo, la sencillez de sus comandos y de las tareas más habituales.

Creo que es un pequeño gran programa que tiene muchísimo que ofrecer, sobre todo a programadores independientes y pequeños grupos que están interesados en sistemas autoalojados ya que como se ha visto es muy fácil de poner en marcha. Si buscas una alternativa sencilla y eficaz a Git no dudes en echarle un vistazo porque puede que Fossil sea exactamente lo que andas buscando.

Notas al pie de página:

Git Mailinglist [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

Wiki oficial de Fossil

How To Mirror A Fossil Repository On GitHub

⁴

Import And Export To And From Git

⁵

Fossil Book

⁶

Fossil Colorized Diffs

⁷

Fossil File Name Glob Patterns

Gopher.fr

lfa — Sat, 08 Nov 2025 00:00:00 +0000

Un amigo ha puesto en marcha una web para promocionar el protocolo Gopher. De momento el sitio es una introducción para neófitos. La web, originalmente, estaba solo en inglés y francés pero un servidor ha hecho las traducciones también al castellano y al italiano, y otra persona ha hecho lo propio para el alemán, así que poco a poco el sitio está adquiriendo un aire europeo, esto es, plurilingüe ;-)

Sin más aquí os dejo el enlace para que podáis echarle un vistazo y compartirlo: https://gopher.fr/

FreeBSD, resolviendo el error: KLD i915kms.ko depends on kernel - not available or version mismatch

lfa — Fri, 07 Nov 2025 00:00:00 +0000

Nota: Hace meses escribí y publiqué este artículo sólo en inglés, pero me he decidido a traducirlo ya que el contenido puede seguir siendo de utilidad para futuras versiones del sistema y/o para problemas similares.

Tras actualizar FreeBSD 14.1 a la versión 14.2 algunas personas sufrimos algunos problemas debido a que los módulos gráficos estaban compilados sólo para la versión 14.1. Uno de los problemas que me molestaban sobremanera era el no poder acceder a las terminales virtuales.

En este tutorial veremos paso por paso como resolví el problema y me quité de encima el error "KLD i915kms.ko depends on kernel - not available or version mismatch".

Primer intento

Lo primero que hice fue buscar en Internet y averigüé que era un problema que ya le había pasado a más gente. Muchos comentaban que la solución era volver a compilar el paquete drm-61-kmod desde el ports tree de FreeBSD, así que eso fue lo primero que intenté.

Siguiendo el manual de FreeBSD¹, cloné el ports tree desde el repositorio git, compilé el paquete y lo instalé:

git clone --depth 1 https://git.FreeBSD.org/ports.git /usr/ports
cd /usr/ports/graphics/drm-61-kmod/
make
make install

El sistema me devolvió un mensaje diciéndome que ya tenía el paquete instalado y cómo reinstalarlo, así que ejecuté el comando make reinstall en la terminal, reinicié el sistema y crucé los dedos. No funcionó.

Seguí buscando información sobre el tema y encontré otro hilo en el que se comentaba que también había que recompilar el paquete drm-kmod, así que lo hice:

cd /usr/ports/graphics/drm-kmod/
make
make reinstall

Esto tampoco funcionó, por lo que decidí dejar de buscar y resolverlo por mi mismo (cosa que tendría que haber hecho desde el principio). Ejecuté el comando dmesg y ví el siguiente error: KLD i915kms.ko depends on kernel - not available or version mismatch. Sabía que el módulo estaba cargado así que me puse a buscar otros paquetes, especialmente los relacionados con el i915, que tal vez fuese necesario recompilar. En mi búsqueda encontré el paquete /usr/ports/graphics/gpu-firmware-kmod así que lo recompilé y reinstalé:

cd /usr/ports/graphics/gpu-firmware-kmod/
make
make reinstall

Reinicié el sistema y el error seguía ahí.

Segundo intento

Llegados a este punto pensé: "vale, puede que algo saliera mal por compilar los módulos en el orden equivocado o lo que fuere así que voy a volver a hacerlo". Empecé por desinstalar y limpiar las compilaciones previas de los módulos:

cd /usr/ports/graphics/gpu-firmware-kmod/
make deinstall
make clean

cd ../drm-61-kmod/
make deinstall
make clean

cd ../drm-kmod/
make deinstall
make clean

Volví a compilar los módulos. En esta ocasión empecé por el drm-kmod y averigüé que este paquete compila también el drm-61-kmod. Compilé el gpu-firmware-kmod, reinstalé los módulos y reinicié otra vez el sistema. Tras el reinicio, el comando dmesg seguía mostrando el mismo error.

Solución

Si bien estoy bastante verde con FreeBSD, llevo instalando, usando y administrando sistemas GNU/Linux desde los 90 así que supuse que la solución a ese error KLD i915kms.ko depends on kernel - not available or version mismatch seguramente se solucionaría recompilando el kernel del sistema y los módulos. De este modo todo estaría en la versión correcta.

Empecé clonando el repositorio con los fuentes del kernel de FreeBSD²:

git clone https://git.FreeBSD.org/src.git

Luego hice un checkout para la versión de FreeBSD 14.2 (en el momento en el que lo hice era la etiqueta release/14.2.0-p3):

git fetch --all --tags --prune
git checkout release/14.2.0-p3

Como no uso un kernel personalizado compilé e instalé el kernel GENERIC. Si utilizas un kernel personalizado ya sabes qué pasos tienes que dar para recompilarlo.

cd /usr/src
make buildkernel KERNCONF=GENERIC
make installkernel KERNCONF=GENERIC

Una vez compilado e instalado el kernel nuevo tocaba recompilar los módulos:

cd /usr/ports/graphics/gpu-firmware-kmod/
make deinstall
make clean

cd /usr/ports/graphics/drm-61-kmod/
make deinstall
make clean

cd /usr/ports/graphics/drm-kmod/
make deinstall
make clean
make
make install

cd ../drm-61-kmod/
make install

cd ../gpu-firmware-kmod/
make
make install

Después de esto reinicié el sistema y esta vez sí, todo estaba funcionando correctamente. ¡Misión cumplida!

Conclusión

Llevaba sin compilar un kernel alrededor de dos décadas y debo decir que toda la experiencia fue divertida y me retrotrajo a aquellos maravillosos años en los que tenías que recompilar el kernel Linux para que funcionara todo tu hardware. Es probable que haya una solución mejor para este problema pero esta a mi me ha funcionado.

Notas al pie de página:

FreeBSD Handbook

FreeBSD Git

De la imprenta a internet y vuelta

lfa — Mon, 20 Oct 2025 00:00:00 +0100

El querer expresarse de manera independiente y hacer llegar las cosas a nuestros semejantes es algo que siempre ha estado ahí. En la antigüedad se hacían pinturas rupestres y se relataban historias en forma oral, luego se pasó a la escritura en diferentes medios y la invención de la imprenta, por fin, hizo posible difundir la información a gran escala. El milagro de la imprenta no sólo permitió abaratar y difundir libros sino que también creó la posibilidad para que personas normales pudieran publicar y difundir sus opiniones y creaciones.

Los pliegos sueltos

Gracias a la imprenta, a partir del siglo XVI empezó a proliferar un tipo de publicación conocida como pliego suelto o pliego de cordel. En otros países adoptó otros nombres: chapbook en los países de habla inglesa, livre bleu en Francia, volksbuch en Alemania, libri da risma en Italia, etc. Estas publicaciones iban desde una hoja suelta doblada para formar varias caras hasta cuadernillos compuestos por varias páginas impresas, dobladas y sin encuadernar (de ahí el nombre de pliego suelto).

Esta literatura callejera fue un medio de información, entretenimiento y divulgación entre la gente corriente. Los contenidos eran de lo más variado e iban desde una canción o poema hasta el relato de acontecimientos de actualidad. Había publicaciones generalistas como las famosos almanaques, que no eran simples calendarios sino que contenían datos metereológicos, ciclos lunares, información para la siembra, etc., y publicaciones más especializadas orientadas a determinados sectores como por ejemplo los zapateros.

Contrariamente a lo que podamos pensar estas publicaciones se realizaban a una escala nada desdeñable teniendo en cuenta los recursos de la época así como la alfabetización de la gente, que ni de lejos era la de hoy en día. En la década de 1520, el librero de Oxford John Dorne anotó en su libro de cuentas la venta de hasta 190 baladas al día, el inventario del establecimiento The Sign of the Three Bibles en el Puente de Londres, en 1664, incluía libros y pliegos impresos suficientes para producir aproximadamente 90.000 pliegos sueltos y 37.500 hojas de baladas. El inventario del establecimiento The Sign of the Looking Glass, también en el Puente de Londres, en 1707, registraba 31.000 libros, además de 257 resmas de pliegos impresos. Una estimación conservadora de las ventas en Escocia únicamente, en la segunda mitad del siglo XVIII, supera los 200.000 ejemplares anuales¹.

Los fanzines y ezines

En el siglo XX, y sobre todo a lo largo de sus últimas tres décadas gracias al invento de la fotocopiadora, hicieron su aparición los fanzines que son, por norma general, un grupo de folios fotocopiados, doblados por la mitad con una cubierta de cartulina todo ello sujeto con grapas. Este tipo de publicaciones fueron la base de la conocida contracultura.

Aunque hay casos de fanzines que tuvieron tanto éxito que terminaron convirtiéndose en revistas² y que el fenómeno fanzine llegara a tener tanto peso como para que incluso hubiera publicaciones creadas y gestionadas por grandes corporaciones (como el conocido fanzine "U Don't Stop" que formaba parte de una campaña publicitaria de Nike), lo habitual es que estas publicaciones fueran operaciones de una sola persona, o de un grupo muy reducido, con una vida más o menos corta.

Al igual que los pliegos sueltos, los fanzines tratan temas diversos: literatura, música, ideas políticas, etc. y al igual que los pliegos sueltos algunos son generalistas mientras que otros están más especializados llegando incluso a haber fanzines tan especialiados que solamente tratan sobre un único tema como el fanzine "exclusively Elvis".

Más tarde, con la venida de las BBS, aparecieron los primeros ezines que por norma general eran archivos en formato de texto plano. De estos uno de los más antiguos y que aún sobrevive es Phrack³. La venida de Internet siguió impulsando el fenómeno ezine y un poco más tarde, con la venida de los blogs primero y de las redes "sociales" después , se terminó de dar la oportunidad potencial a todas las personas de publicar y compartir sus cosas a una escala sin precedentes. En este panorama algunos fanzines se convirtieron al formato digital y muchos otros simplemente desaparecieron, tal y como le ocurrió a otros medios impresos (revistas y periódicos).

Pasado y presente

Como hemos visto los avances tecnológicos como la imprenta y la fotocopiadora facilitaron el que la gente publicara sus propias cosas evitando todo tipo de censura y a finales del siglo pasado con la venida de Internet se generó un optimismo por lo digital, por la revolución que sería Internet para la gente normal y corriente.

Tres décadas después de esa promesa de internet, de esa utopía, solo quedan cristales rotos y de todo ello ha surgido una aterradora realidad de corporaciones, dispuestas a arrasar con todo con tal de incrementar en un céntimo sus beneficios, y de gobiernos corruptos cada vez más confiados en crear un sistema totalitario, en el que puedan medrar ellos y sus amos corporativos, subyugando a las masas sin ningún tipo de interferencia o resistencia. La tecnología que tenía que hacernos libres ha resultado ser la que se está usando para encadenarnos cada día un poco más.

Podemos ver a diario como Internet, y especialmente la web, se ha convertido en un lugar hostil e inhóspito donde grupos privados de impresentables pueden bloquear páginas web a su antojo⁴, donde se eliminan, escriben y reescriben publicaciones y libros electrónicos según las modas, gustos, afinidades y finalidades de determinados grupos e intereses organizados⁵, donde impera la cultura de la cancelación (y persecución) tan utilizada por los nazis y los comunistas durante el siglo pasado, y donde se sufre a diario el abuso de las mal llamadas inteligencias artificiales que rastrean la red 24 horas al día, 7 días a la semana, robando a su paso todo lo que se puede robar para ingerirlo, procesarlo, y vomitarlo después, sin pagar nada a nadie⁶, con el beneplácito de los diferentes gobiernos (sean del color que sean).

Ante tanto ultraje y sinsentido la gente está empezando a reaccionar. Lo físico⁷ y lo fuera de línea⁸ vuelve a estar de moda y vuelve a valorarse porque realmente tiene valor. Un objeto físico siempre generará una mejor experiencia que uno virtual ya que los seres humanos tenemos múltiples sentidos. Un objeto físico tiene bastantes más opciones de sobrevivir y perdurar en el tiempo que uno virtual, prueba de ello son los pliegos sueltos que han llegado hasta nuestros días y que tienen siglos de antigüedad, mientras que ya hay una infinidad de contenido digital de hace escasos años que se ha perdido para siempre a pesar de los esfuerzos por preservarlo. Un objeto físico y/o fuera de línea no es tan susceptible de ser bloqueado, interferido, espiado, robado y manipulado como uno virtual o en línea. Podrán reescribir el texto de un libro y publicar esa versión modificada, pero mi versión de 1984 de George Orwell publicada hace más de 30 años seguirá ahí, inalterada e inalterable, para las generaciones futuras.

Teniendo en cuenta este panorama y la facilidad que hay hoy en día para acceder a una impresora no es de extrañar que la gente esté volviendo paulatinamente a la divulgación en forma impresa, al pliego suelto⁹ y al fanzine¹⁰ de toda la vida, porque compartir nuestros pensamientos, nuestras opiniones y nuestras creaciones libremente es una necesidad inherente del ser humano y no cosa de máquinas.

Deshabilitando las "funcionalidades IA" de FireFox

lfa — Sat, 11 Oct 2025 00:00:00 +0100

Como ya muchos sabéis, la gente de mozilla decidió, hace un tiempo, meter "funcionalidades IA" en el navegador FireFox y los que no estamos de acuerdo con ello debemos hacer algunas cosas para deshabilitar dichas "funcionalidades".

En la barra de direcciones del navegador, donde escribes la URL o las palabras para realizar una búsqueda, escribe about:config para poder acceder a la configuración avanzada del navegador. A continuación te aparecerá un mensaje con un botón que pone algo como Aceptar el riesgo y continuar (Accept the Risk and Continue). Pincha en ese botón y en el cuadro de búsqueda que te permite buscar por opciones buscas los siguientes valores y los pones todos a false:

browser.ml.enable
browser.ml.chat.enabled
extensions.ml.enabled
browser.ml.linkPreview.enabled
browser.tabs.groups.smart.enabled
browser.tabs.groups.smart.userEnabled

Esta entrada se irá actualizando a medida que hayas cambios sobre este asunto. Si sabes de alguna otra opción que haya que ajustar no dudes en decírmelo para que esta entrada sea de utilidad para todos.

¿Cómo se convirtió Eric Blair en George Orwell?

lfa — Mon, 29 Sep 2025 00:00:00 +0100

La página 24 del libro "The Orwell Diaries", que se corresponde con la introducción al Diario 31 de Enero de 1936 - 25 de Marzo de 1936, empieza con el siguiente párrafo (traducido libremente por mí):

"Después de que Orwell hubiera completado varios borradores de lo que se convertiría en Sin blanca en París y Londres, y hubiera cambiado el orden de los acontecimientos (originalmente los de Londres precedían a sus experiencias parisinas), el libro fue rechazado por Jonathan Cape y por T.S. Eliot en nombre de Faber y Faber (más tarde ambos rechazarían también Rebelión en la granja). En ese momento Orwell se rindió. Sin embargo, una amiga suya, la Sra. Sinclair Fierz, envió el texto al hombre que se convertiría en el agente literario de Orwell, Leonard Moore de Christy y Moore, y este persuadió a Victor Gollancz para que lo publicara. Orwell deseaba publicar de forma anónima, en primer lugar porque pensaba que su vida en los barrios bajos podría disgustar a sus padres y, en segundo lugar, porque, como le dijo a su amigo, Sir Richard Rees (editor de la revista literaria The Adelphi para la que escribió), tenía un miedo extraño, una superstición, de que si aparecía el verdadero nombre de uno en forma impresa podría permitir a un enemigo 'obrar algún tipo de magia'. Sin embargo, Gollancz estaba ansioso por tener un nombre y, finalmente, Orwell sugirió, entre varios otros, el de George Orwell. Seguiría siendo Eric Blair en determinados contextos y para sus viejos amigos, pero sus escritos a partir de entonces, exceptuando algunos para la BBC, estuvieron bajo el pseudónimo de 'George Orwell'. El 9 de enero de 1933 Gollancz publicó Sin blanca en París y Londres, y seis meses después fue publicado en Nueva York".

En este extracto averiguamos el cómo y el por qué Eric Blair se convirtió en George Orwell y de paso comprobamos que T.S. Eliot era un capullo. A continuación pongo el párrafo original para los que no tengan problemas en leer en inglés ya que siempre es mejor la versión original que cualquier traducción:

After Orwell had completed several drafts of what would become Down and Out in Paris and London, and had changed the order of events (originally, those in London preceded his Parisian experiences), the book was rejected by Jonathan Cape and by T.S. Eliot on behalf of Faber & Faber (just as later on both would reject Animal Farm). Orwell then gave up. However, a friend, Mrs Sinclair Fierz, sent the typescript to the man who would become Orwell's literary agent, Leonard Moore of Christy & Moore. Moore persuaded Victor Gollancz to publish it. Orwell wished to publish anonymously, first because he thought his low-life slumming might upset his parents, and secondly because, as he told his friend, Sir Richard Rees (an editor of The Adelphi for which he wrote), he had a curious fear — a superstition — that if one's real name appeared in print it might enable an enemy to 'work some kind of magic on it'. However, Gollancz was keen to have a name and eventually Orwell suggested, among several others, George Orwell. He would still be Eric Blair in some contexts and to old friends, but his writing thereafter, except for some at the BBC, was under the name 'George Orwell'. On 9 January 1933, Down and Out in London and Paris was published by Gollancz and, six months later, in New York.

Los diarios de Orwell

lfa — Sat, 27 Sep 2025 00:00:00 +0100

Hace unos días empecé a leerme The Orwell¹ Diaries (Los diarios de Orwell). En la introducción del libro se menciona la siguiente página web: https://orwelldiaries.wordpress.com/ donde puedes encontrar los diarios, en inglés, para leer en línea y además tiene varias imágenes escaneadas de algunas páginas de los diarios, entre otras cosas.

La versión actual de la web tiene un scroll infinito pero puedes empezar por el principio siguiendo este enlace: https://orwelldiaries.wordpress.com/page/65/

Espero que, si el idioma no es una barrera, los disfrutes.

Notas al pie de página:

George Orwell novelista, poeta, periodista, ensayista y crítico británico famoso por sus libros 1984, Rebelión en la granja y Homenaje a Cataluña.

Tres días sin luz

lfa — Fri, 19 Sep 2025 00:00:00 +0100

Llevo tres días sufriendo cortes de luz. Cortes de luz que duran un período que abarca unas 4, 12 o más horas, aunque según E-Distribución¹, la compañía que tiene el monopolio de las distribución eléctrica, son microcortes temporales. Tres días en los que varias viviendas y comercios del barrio no pueden hacer vida normal ya que nos guste o no, en nuestro mundo, todo está estructurado y pensado para que la energía eléctrica esté siempre disponible o que no se vaya durante más de una o dos horas a lo sumo.

Vas a la web y tienes una mierda de chat bot que muy amablemente te indica que no detecta ninguna incidencia en tu zona y que si quieres abrir una incidencia lo autorices a que si mandan a alguien y resulta que no ven que sea cosa del suministro te cobren 82 euros. Llamas por teléfono y ocurre exactamente la misma situación con la salvedad de que, si persistes y no te asustas, al final puedes hablar con alguien de atención al cliente.

La persona que te atiende, que es de un call center en algún lugar de Latinoamérica y que con casi total seguridad estará hasta el gorro de escuchar penas, gritos e insultos por un mísero sueldo, te atiende lo mejor que puede y se limita a hacer lo único que puede hacer: abrir una incidencia y darte el número de referencia.

Luego te vas a la web de averías de E-Distribución² dónde tienen un mapa en el que por fin aparece tu incidencia y marca un número de afectados que son los mismos que han estado llamando mientras lo hacías tú y te pone una "hora estimada de resolución". Cuando llega esa hora y sigues sin luz, vuelves a la web y la hora automágicamente se ha incrementado en 45 minutos. Tras los 45 minutos la hora vuelve a incrementarse en otros 90 minutos tras los cuales vuelve a incrementarse en otros 90, y así hasta que por fin tienes la luz y cierran la incidencia.

Si tienes poca suerte a los 15 minutos vuelves a estar sin luz, si tienes más puede que la cosa aguante 120 minutos y vuelta a empezar hasta que, por fin, llega un momento, bien entrada la noche, donde la luz se mantiene hasta la mañana siguiente donde se repite el baile con la distribuidora de la luz.

Al margen de los cuentos que cuentan los políticos, en España, la electricidad sigue siendo un monopolio privado, ya que si bien puedes elegir qué empresa te factura la luz, no puedes elegir la distribuidora que siempre es la misma, así que a ellos plin. Ya te ponen a una persona explotada en Latinoamérica para que descargues tu frustración y al pobre desgraciado del electricista que va ver qué pasa, y digo pobre desgraciado ya que ayer la gente, al verlos pasar por la calle, empezaron a insultarlos porque la cosa ya estaba calentita, y no sólo por las altas temperaturas (que también).

Estos tres días de cortes se deben principalmente a un problema en una subestación eléctrica que lleva fallando años. La diferencia es que antes fallaba muy de cuando en cuando, la incidencia se solventaba en pocas horas y hasta dentro de X meses mientras que ahora, con el incremento de los consumos por el calor, por las obras nuevas que donde antes habían cuatro casas ahora hay otros tantos edificios con viviendas, garajes, trasteros y bajos comerciales, se vé que ha empezado a pedir auxilio.

Como la distribución de la luz es un monopolio, supongo que no les compensan los costes de resolver este problema para unas, aproximadamente, 100 familias afectadas y una veintena de comercios locales. El hecho de que haya personas con movilidad reducida que no pueden salir de su casa porque no hay electricidad en los ascensores es evidente que no le quita el sueño ni a los ejecutivos, ni a los politicos enchufados, de E-Distribución.

Sin embargo, en estos 3 días que llevo consultando prácticamente cada hora el mapa con las incidencias eléctricas en Tenerife, no he visto ni una sola incidencia, ni una sola vez, en las zonas turísticas donde están los hoteles. Veo incidencias en las zonas aledañas tanto en el norte como en el sur de la isla, pero no en las zonas realmente turísticas. ¡Qué casualidad!

Notas al pie de página:

https://www.edistribucion.com/es/index.html

https://www.edistribucion.com/es/averias.html

Gopher una respuesta sencilla a los excesos de la web

lfa — Mon, 01 Sep 2025 00:00:00 +0100

English on this site.
Français sur linuxfr.org

Hoy en día cada vez más gente está harta de todos los excesos y abusos que se sufren en la World Wide Web. Cuando salió "al público" en 1993, la web, era un sistema para publicar y compartir documentos con hyperenlaces. Treinta años después ha pasado a ser un hervidero de bots, de sistemas de rastreo, de sistemas de publicidad invasivos, notificaciones que no paran de exigir la atención del público, invasiones a la privacidad de todos y otras barbaridades.

En la actualidad se ha normalizado el hecho de que visitemos una página web para leer un artículo, ver una receta de cocina o ver los horarios del autobús y que para ver dicha información tengamos que descargarnos una cantidad ingente de datos habitualmente repartidos entre una ventana invasiva con la política de cookies que nos pide autorización para rastrearnos y compartir nuestros datos y hábitos de navegación con la entidad que gestiona la web y sus 7126 socios, un montón de anuncios que no queremos ver, algún banner de suscripción a algo a lo que no queremos suscribirnos, una infinidad de imágenes y vídeos que no son relevantes y finalmente, con un poco de suerte, en medio de todo ello, la información que sí queremos ver, mezclada con más anuncios.

También se ha normalizado el hecho de que para ver algo tan simple como el resultado de la quiniela tengamos que tener javascript activado en nuestro navegador. Para el que no lo sepa, javascript es un entorno que existe en nuestro navegador y que permite ejecutar en nuestras máquinas programas que hacen lo que sea que se le ocurra enviarnos a la página que estamos visitando. Esto ha generado y sigue generando todo un mundo de problemas de seguridad, invasiones a la privacidad, apropiación de datos de forma indebida y un largo etcétera.

Para hacernos una idea, en una web de hoy en día si queremos ver una receta de cocina no es para nada descabellado que tengamos que descargarnos entre 2 y 10 megabytes de datos con una media de 50 peticiones para cargarlo todo¹. Si hacemos la cuenta veremos que una receta de cocina en texto plano ocupa una media de 2 kilobytes. Si cogemos esa receta y la formateamos con el lenguaje HTML y le añadimos estilos CSS para que se vea bonita en un navegador web, la cosa rondaría unos 3 kilobytes, pongamos 4 kilobytes para ser generosos. ¿Así que como es posible que para ver algo que ocupa 4 kilobytes tengamos que descargarnos entre 2 y 10 megabytes de datos que equivalen a la friolera de entre 500 y 2500 veces más cantidad de datos? Ese exceso son todos los anuncios, videos, imágenes, rastreadores y demás cosas que nos obligan a descargar nos guste o no.

Aunque se nos pretenda hacer creer que esto es inevitable o incluso que es justo por "ponga usted aquí los motivos que le vengan bien al lobby, empresa o administración de turno", la realidad es que esto no es así. La web antes no era así y siguen habiendo otras opciones. Una de esas opciones es Gopher.

¿Qué es Gopher?

Gopher, al igual que la WWW, es un protocolo para compartir y acceder a documentos y archivos en internet que se publicó en 1991, dos años antes que la World Wide Web. Se desarrolló en la Universidad de Minessota, de ahí su nombre ya que la mascota de la universidad y de los equipos deportivos de la misma es Goldy Gopher².

Gopher tiene un sistema de navegación, mucho más estructurado que la web, basado en un sistema de menús conocidos popularmente como gophermaps. Este sistema de menús contiene enlaces a diferentes tipos de archivos y a otros menús. Es un interfaz en texto plano por lo que es muy rápida y consume muy pocos recursos.

Sin duda es un protocolo de su tiempo, en el que las conexiones eran lentas y costosas, y las máquinas no eran tan potentes como ahora por lo que el objetivo era compartir la mayor cantidad posible de información relevante con el menor consumo de datos posibles.

Gopher está libre de los excesos tan habituales en la web

A diferencia de la WWW que favorece los excesos y los abusos, Gopher por su simplicidad los impide y favorece el contenido por encima del continente. Gopher es un protocolo muy sencillo en el que por cada petición que se le hace al servidor, este devuelve un único menú en texto plano o un único documento (archivo) y cierra la conexión.

La sencillez del sistema es precisamente lo que imposibilita o dificulta muchísimo los abusos y excesos que son tan habituales en la web por varios motivos entre los que cabe destacar los siguientes:

En Gopher no existen sesiones ni cookies por lo que es imposible rastrear a la gente³ e innecesario mostrar una política de cookies.
Al ser un sistema en el que cada petición es única, el servidor sólo devuelve el documento que se le ha solicitado y nada más y que lo que recibimos es un único archivo, se evita el que se hagan automáticamente otras peticiones para recibir al mismo tiempo imágenes, vídeos u otros documentos ya sea del mismo servidor o de otros servidores distintos.
Como es un protocolo que solamente comparte archivos no soporta javascript ni niguna otra cosa parecida por lo que en ningún caso puede cargar y ejecutar directamente un programa en el ordenador del usuario.
Al tener solamente un interfaz textual y carecer de un sistema de diseño y maquetación de contenidos la información suele ser mucho más ligera ya que se presenta en texto plano. Si se quiere algo maquetado o con diseño siempre se podrán poner archivos en formatos como ODF, PDF, PS, etc., y el usuario siempre podrá decidir si quiere y puede descargarlos o no.

De todo esto se desprende que Gopher es un sistema ligero en el que se va al grano y que no requiere de mucho ancho de banda para funcionar. En Gopher el contenido es lo realmente importante ya que carece de los mecanismos estéticos de la web y además nos proporciona la tranquilidad de que no invade nuestra privacidad⁴.

Gopher no es para todos y está bien así

Aunque a mucha gente no le gustan los anuncios, que los rastreen y las ventanitas de políticas de cookies y consensos de privacidad, también es cierto que creen no poder vivir sin mucho de ese mismo bloatware que hace que funcionen las cosas que no les gustan.

La web es como un mercadillo de fin de semana o un parque de atracciones en temporada alta mientras que Gopher es más parecido a una biblioteca de ciudad. Son dos cosas diferentes para públicos diferentes y/o para momentos diferentes. Si en la WWW estamos en un mercadillo donde todos nos gritan para vendernos su mercancía, en Gopher estamos en la cafetería de tertulia con amigos y personas con inquietudes. A veces nos gusta una cosa y otras veces nos gusta (o necesitamos) otra y está bien así, no todo tiene que ser para todo el mundo ni para todos los momentos.

El uso de Gopher decayó en favor de la WWW a finales de los 90, pero este protocolo ha sobrevivido hasta nuestros días principalmente gracias a pequeñas comunidades conocidas como Pubnixes (del inglés Public Unixes, sistemas Unix de acceso público) y tildes. Aunque en estas comunidades hay muchas personas con un perfil y/o inquietudes técnicas, hay variedad de personas con inquietudes y aficiones dispares.

Los pubnixes suelen ser, por norma general, máquinas con pocos recursos que costea una sola persona, junto can algunas donaciones, por lo que cada pubnix tiene un número limitado de usuarios lo que favorece que se vayan creando más comunidades pequeñas a medida que aumenta el número de personas interesadas. Al ser comunidades pequeñas favorecen el que la gente interactúe más entre sí y se conozcan mejor por lo que da lugar a interacciones más auténticas y relevantes.

Además las personas de unas comunidades interactúan con personas de otras lo cual mantiene un tejido social entre todas ellas. Lo habitual es que alguien que forma parte de un comunidad, en un momento determinado, decida crear su propio pubnix para dar cabida a nuevas personas por lo que siempre hay intercambios entre comunidades y hay personas que pertenecen a más de una.

Todo este ecosistema social constituye una parte importante de la belleza del Gopherespacio. Aquí la gente escribe y comparte porque tienen algo que decir o porque sienten la necesidad o el deseo de hacerlo. Nadie publica veinte banalidades diarias para mejorar su posicionamiento SEO y los que leen lo hacen porque realmente tienen interés y no porque tengan "miedo a perderse algo"⁵.

Por otro lado, las personas que necesitan o desean interactuar casi en tiempo real con un montón de contenido multimedia que se va actualizando a cada instante, crear una marca personal para vender cosas, conseguir miles de seguidores y obtener decenas de miles de me gusta, con casi total seguridad se sentirán fuera de lugar en el Gopherespacio.

¿Qué tengo que hacer para explorar el Gopherespacio?

Ahora que ya tenemos una idea de lo qué es y de lo que no es Gopher lo más probable es que queramos echar un vistazo. Al igual que para navegar por la WWW hace falta un navegador web, para explorar el Gopherespacio hace falta un cliente Gopher.

Hace años muchos navegadores web soportaban tanto la WWW como Gopher pero luego decidieron ir eliminando ese soporte. Uno de los navegadores que lo han mantenido es Lynx. A continuación hay una una lista⁶ de clientes Gopher para todos los sistemas y públicos así como extensiones para activar Gopher en los navegadores basados en Firefox y para los basados en Chrome:

Lagrange: es un cliente gráfico disponible para GNU/Linux, BSDs, Macos, Windows y también tiene versiones beta para móviles iOS y Android. Aunque en su web pone que es un cliente de Gemini también soporta Gopher y otros protocolos similares.
Bombadillo: es un cliente con interfaz de texto para sistemas GNU/Linux, BSDs y Macos.
Elpher: cliente para GNU Emacs.
OverbiteWX: add-on para los navegadores basados en Firefox.
Burrow Gopherspace Explorer: add-on para los navegadores basados en Chromium.

Una vez que se tiene el cliente, el funcionamiento es con URLs del tipo gopher://. En español hay menos recursos y sitios que en inglés pero puedes empezar visitando la comunidad Texto Plano gopher://texto-plano.xyz/ que es una tilde en español, principalmente gente de latinoamérica. También puedes visitar mi propia madriguera de geómido⁷ en la URL gopher://lucio.albenga.es/1/es en la que encontrarás una sección con enlaces a varios agregadores de phlogs⁸, pubnixes y otros recursos Gopher.

Conclusión

Sin ninguna duda la mayoría de la gente directamente descartará Gopher alegando que es una "tecnología obsoleta" u otros argumentos similares, otros tendrán curiosidad por ver de qué va y pasado un tiempo ni se acordarán de ello, un número menor seguirán visitando sus madrigueras favoritas y unos pocos terminarán creando sus propias madrigueras o incluso montarán un servidor pubnix. Todo eso está bien, Gopher no pretende vender nada a nadie ni solucionar los problemas del mundo.

Como decía al principio, Gopher es una de las soluciones a los excesos y abusos de la web. Hay otras como Spartan o Gemini pero lo importante es saber que en un momento donde mucha gente se queja del bloatware de la WWW, habla de indie web, small web y smolweb, de permacomputación, de comunidades sostenibles, y de otras cosas similares, Gopher lleva proporcionando mucho de todo ello desde 1991 y ahí está, esperando a que decidamos conocerlo y darle una oportunidad como un artesano veterano que puede que no luzca tan bien como cuando era joven, pero cuya habilidad y precisión de movimientos son capaces de crear un utensilio que nos dure toda la vida.

Nos vemos en el Gopherespacio (o no).

Notas al pie de página:

He hecho la prueba con varias webs de entre los primeros resultados de búsqueda y si tenemos en cuenta que tengo bloqueadores de cosas las cantidades de datos podrían ser incluso superiores.

Gopher en español se traduce como geómido (Geomyidae), un roedor de la familia de los castores conocidos vulgarmente como tuzas que se encuentran en el continente Americano.

Hay gente que ha montado un sistema primitivo de sesiones y rastreo que solamente funciona en su propio gopher hole mediante la generación automática de enlaces con un identificador único, pero en ningún caso se instala o almacena algo en el ordenador del usuario que permita rastrearlo en el tiempo y en toda la red.

⁴

Hay que tener en cuenta que Gopher no es una comunicación encriptada por lo que si alguien te monitoriza sí que podrá ver los contenidos a los que accedes pero esa monitorización tendría que ser un man in the middle o tu propio proveedor de conexión a internet. Aunque hay formas de tener el equivalente en Gopher del https de la WWW, esto no forma parte de la especificación del protocolo.

⁵

Wikipedia Síndrome FOMO

⁶

La lista propuesta son solo algunas opciones pero no contiene ni de lejos todos los clientes Gopher que existen. A diferencia de la WWW que es tan complicada que prácticamente solo hay dos o tres navegadores, hacer un cliente Gopher es relativamente sencillo por lo que hay muchos, lo cual es otra ventaja ya que la variedad evita el monopolio.

⁷

Del inglés Gopher Hole, es el término que equivale al de página web en la WWW.

⁸

De Gopher Log, el equivalente de un blog en la WWW.

¿Por qué no uso la Creative Commons?

lfa — Fri, 29 Aug 2025 00:00:00 +0100

Desde hace unas dos décadas es bastante habitual que muchos de los contenidos que se publican en internet se hagan bajo alguna licencia Creative Commons. En el pasado yo también lo he hecho pero este año, a raíz de una serie de acontecimientos, he decidido dejar de hacerlo.

En el pasado ya tuve un incidente con contenidos míos que se compartieron, a mi entender, de forma indebida para presentar una web como si fuera mía cuando no lo era y tuve una experiencia bastante complicada con el proveedor de servicios que se negaba a intervenir porque yo mismo admitía que esos contenidos eran Creative Commons. Sin embargo lo que me ha hecho cambiar realmente de opinión sobre CC han sido las siguientes dos cosas:

La iniciativa Creative Commons Signal¹. Te recomiendo que no te pierdas las discusiones en GitHub² donde se ve como la gente de CC hace oídos sordos a lo que no les interesa.
Un publicación que me llegó posteriormente vía Mastodon de un artículo, a mi entender, bastante pro IA por parte de Creative Commons³.

Si tenemos en cuenta que un número ingente del contenido licenciado bajo Creative Commons lo está bajo las licencias CC BY-NC-SA⁴ y CC BY-NC-ND⁵, y que ambas licencias obligan por un lado a reconocer la autoría de la obra y por otro lado prohíben su uso de cualquier forma comercial, obtenemos que Creative Commons ha pasado de ser una organización que se suponía que estaba a favor de artistas y creadores a una que parece ser que ha terminado por estar a favor de empresas y organismos que, entre otras cosas, vulneran en gran medida los términos de sus propias licencias.

Así que ante este panorama y por motivos éticos yo no puedo seguir utilizando licencias Creative Commons ni apoyar y/o publicitar su uso.

Notas al pie de página:

Creative Commons Signal Proposal

CC Signals Open Feedback, Suggestions and Ideas

Should CC-Licensed Content be Used to Train AI? It Depends.

⁴

Resumen de la Licencia Creative Commons BY-NC-SA

⁵

Resumen de la Licencia Creative Commons BY-NC-ND

De Software, Licencias, Morales y Éticas

lfa — Sun, 20 Jul 2025 00:00:00 +0100

De cuando en cuando ocurre que se genera un debate sobre temas de licencias de software libre y open source. En este tipo de debates siempre suelen haber acérrimos defensores del software libre que defienden la GPL y la AGPL a ultranza y acérrimos detractores del software libre y, más concretamente, de Richard Stallman y de la Free Software Foundation, que defienden a ultranza el open source y el que se utilicen licencias más permisivas como la MIT o las BSD.

En general cuando se habla de open source, una parte limita la cuestión estrictamente a lo técnico: desarrollo colaborativo, mejor calidad del producto al ser desarrollado por más gente, mayor seguridad al haber más ojos para revisarlo, etc., y otros se centran más en lo económico que principalmente es que no tienen que pagar por el software. Sin embargo cuando se habla de software libre, inevitablemente se habla de conceptos de caracter más humanista: de ética y de moral, de lo que es justo para la gente y de lo que no lo es, del bien de la mayoría por decirlo de algún modo.

Licencias más o menos libres

Dentro del mundillo open source el argumento clásico en contra de la GPL y de la AGPLv3 es que dichas licencias, al imponer determinadas restricciones, no son realmente libres mientras que las licencias más permisivas si que lo son. En pocas palabras, la queja es que las licencias GPL y, sobre todo, la AGPLv3 no permiten que alguien coja un programa libre y pueda hacer una versión cerrada del mismo.

El otro argumento bastante típico, al hilo de las "restricciones" de estas licencias, es el de que si pones tu proyecto bajo la GPLv3 o la AGPLv3 no lo va a usar nadie debido a dichas restricciones así que para qué quieres hacer algo que nadie va a usar. Este argumento es un despropósito ya que mucha gente usa software bajo estas licencias a diario, con mucha probabilidad incluso los que hacen este tipo de comentarios absurdos.

Para Stallman, la Free Software Foundation y el movimiento del software libre, cuando se habla de libertad, se habla de la libertad de los usuarios, entendiendo como usuario a alguien que utiliza un programa y/o el código fuente de un programa. Así que la libertad que se defiende es principalmente la libertad de los individuos. Por lo tanto la GPLv3 y la AGPLv3 procuran dar una serie de derechos al mismo tiempo que procuran eliminar la posibilidad de que alguien pueda restringir estos derechos.

Ese es el motivo de que estas licencias contengan cláusulas que "obligan" a entregarle a los usuarios el código fuente de los programas que utilizan, para que puedan estudiarlo y cambiarlo, y además se les permite redistribuir a su vez los programas con o sin cambios, de forma gratuita o cobrando por ello, con la obligación de hacerlo bajo la misma licencia. Por otro lado las licencias más permisivas no incluyen estas cláusulas "restrictivas" de obligar a usar la misma licencia por lo que en la práctica permiten que alguien pueda quitarle a los usuarios los derechos de los que él se está beneficiando.

Tanto la GPL como la AGPL dan estos derechos cuando se distribuye el programa, esto es, se le entrega al usuario una copia del mismo. La principal diferencia entre la GPLv3 y la AGPLv3 es lo que se entiende como distribución de un programa. Según la GPLv3, la distribución se produce cuando se le da al usuario el programa para que lo ejecute en su dispositivo, ya sea mediante una descarga online de un archivo o conjunto de archivos, ya sea mediante la distribución en un soporte físico: diskette, cinta de datos, pendrive, cdrom, etc. Como se suele decir, quién hizo la ley hizo la trampa y determinados actores encontraron un modo de aprovecharse del software libre, de lucrarse con él y de no dar nada a cambio precisamente buscando la forma de invalidar la distribución del softwmare según la definición de la GPL. Así nació el Software como Servicio, más conocido por las siglas SaaS (Software as a Service en inglés).

Los que ofrecen software como servicio, según los términos de la GPL, no lo "distribuyen" por lo tanto no tienen la obligación de darle a sus usarios el código fuente de la versión modificada. La AGPLv3 viene a resolver este vacío legal añadiendo en la cláusula 13 lo siguiente:

…if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version…

que se traduce como "…si modifica el Programa, su versión modificada debe ofrecer de manera visible a todos los usuarios que interactúen con él de forma remota a través de una red informática (si su versión admite dicha interacción), la oportunidad de recibir el Fuente Correspondiente…". Esta cláusula hace que sea prácticamente imposible ofrecer el software sin darle al usuario una copia del código fuente del mismo.

¿Quién se beneficia de qué?

Teniendo en cuenta todo lo anterior, es bastante fácil darse cuenta de que un programa bajo una licencia open source más permisiva beneficia principalmente a empresas de cierta envergadura que tienen los medios para explotar este software ya sea vendiéndolo como servicio, ya sea haciéndole algunos cambios y revendiéndolos de forma cerrada. Los casos típicos son, como no, las empresas conocidas como big tech. Apple cogió software licenciado de forma permisiva bajo BSD, lo modificó y lo revendió de forma cerrada dentro de Mac OS X e iOS. Microsoft y Amazon con sus plataformas de computación en la nube son un ejemplo de cómo lucrarse con software licenciado bajo GPL sin tener que dar nada a cambio.

En lo referente al argumento de para qué haces algo si nadie va a usarlo, creo que ese "nadie" hace referencia principalmente a este tipo de empresas ya que mismamente Google prohíbe a sus ingenieros el uso de cualquier código licenciado bajo la AGPLv3¹, aunque con esta licencia si solamente "venden el servicio", sin realizar ningún tipo de cambio, con enlazar al código fuente del proyecto original tienen más que suficiente para cumplir.

Entre los perjudicados hay muchos casos dónde escoger. Algunos ejemplos famosos son el caso de los paquetes de javascript colors y faker² (licenciados bajo la licencia MIT), el caso de Log4j³ (licenciado bajo Apache APL 2.0) y los cambios de licencias de Redis⁴ (originalmente licenciado bajo BSD 3-clause license), MongoDB⁵ (originalmente licenciado bajo AGPLv3) y ElasticSearch⁶ (originalmente licenciado bajo Apache APL 2.0) que además fueron muy criticados por dichos cambios de licencias.

Pero sea como sea el software tiene que ser libre u open source, ¿no?

Viendo la cantidad de críticas realizadas por parte de miembros de la comunidad open source a Redis, MongoDB, ElasticSearch e incluso al desarrollador de colors y faker, Marak Squires, cualquiera podría pensar que la única cosa en la que parecen estar prácticamente todos deacuerdo es que sea como sea el software tiene que ser libre u open source. Sin embargo los hechos parecen indicar que, como todo en esta vida, depende.

Si eres un actor pequeño como un desarrollador independiente, un pequeño equipo de desarrollo o una empresa que no sea extremadamente grande, importa y mucho el que tu software no sea privativo. Por el contrario se le da mucha menos importancia al tema cuando el software privativo resulta ser el sistema operativo MacOS de un MacBook, portátiles bastante utilizados entre lo desarrolladores de la comunidad open source, o si sirve para que funcionen adecuadamente las tarjetas gráficas de nVidia y los chipsets WiFi de Qualcomm en los sistemas con kernel Linux.

Claro que esto no debería de extrañar a nadie ya que un número importante de los que van dando lecciones de ética y moral, y aconsejan sobre licencias de software al resto, lo hacen mientras van de camino al banco a ingresar su cheque de RedHat (IBM), Google, Meta, o Microsoft, por mencionar a algunos. En este panorama tenemos casos para todos los gustos, desde líderes de la comunidad open source que entran en barrena porque alguien intenta hacer ingeniería inversa para hacer una versión libre de un programa privativo⁷, hasta el buque insignia de las empresas open source que directamente coge todo el software libre que quiere y lo convierte, de facto, en un producto de software privativo⁸.

Conclusión

El tiempo y la experiencia me han enseñado que se pueden hacer y usar programas de software libre y open source con fines abusivos de igual manera que también he visto desarrolladores individuales y pequeños equipos de desarrollo hacer programas privativos que les proporcionan unos ingresos dignos sin explotar ni extorsionar a nadie, por lo tanto opino que cada cual puede hacer con su tiempo y su dinero lo que considere siempre y cuando no dañe a nadie.

A mi me parece bien que alguien haga software libre bajo la licencia que sea, aunque yo siempre recomiende la AGPLv3, porque quiere contribuir de forma altruista a la sociedad y/o ganarse los garbanzos con ello, y también me parece bien que otros quieran ganarse la vida honradamente haciendo software privativo y venderlo. Lo que no me parece bien son las personas que actúan de mala fe, que dicen una cosa mientras están haciendo la contraria, que pretenden dar una apariencia de compromiso con la sociedad cuando en realidad manipulan las cosas para que las corporaciones que firman sus cheques obtengan pingües beneficios, engañando y explotando a todos los demás.

Lo malo no está en las licencias ni en los programas. Lo malo no está en si haces software libre, open source o privativo. Lo malo reside en la falta de criterio y de honestidad. Lo malo está en los egos y ambiciones enfermizas de las personas.

Notas al pie de página:

Google Open Source AGPL Policy

Bleeping Computer: Dev Corrupts NPM libs Colors and Faker Breaking Thousands of Apps

The Register: Log4j doesn't just blow a hole in your servers, it's reopening that can of worms: Is Big Biz exploiting open source?

⁴

Redis Adopts Dual Source-Available Licensing

⁵

The Register: Fed up with cloud giants ripping off its database, MongoDB forks new 'open-source license'

⁶

Geeker's Digest: Elastic changes its open source license, becomes "less open"

⁷

Torvalds knifes Tridgell

⁸

Red Hat strikes a crushing blow against RHEL downstreams

Mega65 una retromáquina moderna: primera toma de contacto mediante su emulador

lfa — Sat, 14 Jun 2025 00:00:00 +0100

Figura 1: Foto del Mega65 obtenida de la web oficial.

Hace unos años me enteré de la existencia del Mega65¹, un nuevo ordenador de 8 bits que pretende ser el Commodore C65 que nunca salió a la luz. De hecho esta máquina está basada en prototipos del C65 y su ROM parte de la del C65 que lógicamente contenía muchos errores por pulir ya que sólo era un prototipo en desarrollo.

Este ordenador utiliza un FPGA y aparte de ser un Commodore C65 mejorado tiene compatibildad con un C64 tanto desde el propio core del Mega65, que imita la capa de compatibilidad que tenían prevista incluir los ingenieros de Commodore en el C65, como un core propio que imita un Commodore C64 completo. Ahora mismo hay otros cores como uno de ZX Spectrum y otro de GameBoy.

Hace unos días quise echarle un vistazo de nuevo al proyecto para ver cómo había evolucionado. Me interesó sobre todo ver que aparte de en BASIC y en ensamblador, se podía ya programar en C e incluso hay un PASCAL para este sistema. También ví que había un emulador llamado Xemu² así que me decidí a instalarlo y probar el Mega65.

Instalación y configuración del emulador Xemu

Aunque se puede instalar desde el código fuente que está en GitHub³, el desarrolador proporciona algunos paquetes⁴ entre los cuales se encuentra uno para Ubuntu que funciona perfectamente en mi sistema Devuan GNU+Linux. Así que lo descargué y lo instalé.

Como es habitual, el emulador requiere de la ROM del sistema. Yo he seguido los pasos indicados en la documentación oficial de Xemu⁵ para obtenerla. El proceso no es muy complicado pero requiere algo de trabajo por nuestra parte ya que por un lado debemos obtener la ROM original del Commodore C65 que puedes encontrar en internet (suele estar bajo el nombre 910828.bin) y por otro lado debemos obtener los archivos con los cambios propios de la ROM del Mega65 que son software libre y que puedes descargar desde el repositorio de archivos oficial⁶ (busca por BDF).

Una vez que tenemos todos los archivos hay que parchear la ROM del C65 para aplicarle los cambios de Mega65. Para parchear la ROM en mi sistema Devuan GNU+Linux instalé bsdiff y luego utilicé el comando bspatch que forma parte de bsdiff.

sudo apt install bsdiff
bspatch 910828.bin new-920364.bin 920413/920413.bdf

910828 es la ROM original del C65
new-920364.bin es la ROM parcheada que vamos a utilizar
920413/920413.bdf son los cambios en la ROM del Mega65

Ahora que tenemos la ROM y el emulador instalado solamente nos queda ejecutar el emulador y configurarlo. Lo podemos ejecutar desde el entorno gráfico o desde la terminal con el comando

xemu-xmega65

Durante el primer arranque nos pedirá si queremos que nos cree el archivo SD virtual necesario por el emulador y demás cosas necesarias. Le indicamos que sí y una vez que esté todo arrancado y ejecutado procedemos a añadir la ROM haciendo click derecho sobre la ventana del emulador y seleccionando "Disks" -> "SD-card" -> "Update files on SD image".

Una vez hecho esto hacemos click derecho sobre la ventana del emulador y seleccionamos "Reset/ROM Switching" -> "Reset". En este momento ya debería de arrancar el emulador en el modo Mega65.

Figura 2: Imagen del Mega65 una vez arrancado en el emulador Xemu

Probando y disfrutando el Mega65

Lo siguiente que hice fue descargar la documentación oficial del Mega65 para saber cómo funcionaba el sistema por encima e hice un par de pruebas muy simples en BASIC. También me descargué y probé el juego "Meteor Defense" para comprobar si el emulador funcionaba. Puedes descargarte el juego, la documentación y más cosas desde el repositorio oficial de archivos del Mega65 (ver notas al pie).

Figura 3: Imagen del juego Meteor Defense en el emulador de Mega65 Xemu

Tras comprobar su funcionamiento me decidí a transcribir un programa más grande así que tecleé el programa "Monster Chase" del libro Stimulating Simulations de C. William Engel⁷, lo ejecuté, lo guardé en una imagen de diskette virtual, lo volví a cargar y lo volví a ejecutar.

El juego en BASIC funcionó sin problemas y la verdad es que me agradó mucho tanto el hecho de que funcionara como la experiencia de tener que escribir en un ordenador un juego en BASIC copiándolo de un libro para poder jugar con él. Aunque esto hoy en día pueda parecer una broma, cuando yo empecé con los ordenadores en los 80 era muy habitual y dudo que alguien que no haya pasado por este ritual pueda entenderlo o apreciarlo en su justa medida.

Figura 4: Imagen del juego Monster Chase en el emulador de Mega65 Xemu

Tras la experienca con BASIC que me sirvió para comprobar si el emulador funcionaba, instalé el compilador llvm-mos⁸ para compilar el código en C ya que este compilador tiene tanto un target mos-c64-clang para Commodore C64 como un target propio para el Mega65, mos-mega65-clang. Aquí debo decir que las cosas no fueron tan bien como me habría gustado.

Compilándolo para el C64 y ejecutándolo en el emulador con la capa de compatibilidad del C64 en Mega65 el programa funcionaba sin problemas, sin embargo compilándolo para el Mega65 y ejecutándolo en el emulador en modo Mega65 el programa no funcionaba. No tengo muy claro si el problema está en el compilador o en el emulador pero por lo que he visto incluso la gente que dispone del hardware real tiene ciertos problemas, de momento, con sus programas en C.

Figura 5: Programa de C ejecutado en la capa de compatibilidad del C64 en el emulador de Mega65

Figura 6: El mismo programa de C ejecutado en la en el emulador de Mega65 en modo Mega65

Conclusión

Tengo sentimientos encontrados con esta máquina ya que el precio no es precisamente bajo y el hecho de que no funcionara un programa tan simple hecho en C me desanimó bastante, pero seguiré pendiente de la evolución del proyecto. Mientras tanto seguiré disfrutando del Mega65 mediante el emulador Xemu.

¡Quién sabe que sorpresas podría deparar esta máquina en un futuro!

Notas al pie de página:

Web Oficial de Mega65

Web Oficial de Xemu

Xemu en GitHub

⁴

Página de descarga de Xemu

⁵

MEGA65 ROM "how to get it" tutorial for Xemu

⁶

Repositorio Oficial Mega65 Files

⁷

Stimulating Simulations en Archive.org

⁸

Web Oficial de llvm-mos

LibreCan 2025 Postmortem

lfa — Wed, 04 Jun 2025 00:00:00 +0100

El pasado 10 de Mayo se celebró la LibreCan 2025¹, un meetup de software libre, organizado por un servidor. He estado atareado con otras cosas así que aún no había escrito nada al respecto hasta ahora. Hoy es el día de hacer un breve análisis del evento.

Como ya he mencionado, el evento era un meetup informal que se celebró en una cervecería/cafetería de Santa Cruz de Tenerife. No había charlas preparadas ni nada por el estilo. Como nadie se conocía en persona pensé que era mejor este formato abierto en el que los que quisieran podían aparecer por el establecimiento, sentarse y participar de la conversación.

El evento comenzaba a las las 16:00 y asistimos personas de todas las edades, tanto de Tenerife como de Gran Canaria. Desde aquí quiero volver a agradecerle a los que venían de Gran Canaria su asistencia ya que para ellos, participar, suponía costearse el desplazamiento más una noche de alojamiento en un hotel.

La conversación fue muy fluida y se habló de muchas cosas. Por un lado se habló de muchos temas filosóficos del software libre como las diferencias entre software libre y open source, la Free Software Foundation y las licencias de GNU. También se habló mucho de historia de la informática y de retroinformática, de cómo las cosas han evolucionado o involucionado, según se quiera ver.

Hablamos, como no, de sistemas GNU/Linux pero también se habló mucho de los sistemas de la familia BSD, de la obsolescencia programada y de open hardware. Hubo mucho interés sobre equipos portátiles que están saliendo hoy en día que son sostenibles, fáciles de reparar y que funcionan bien con sistemas abiertos.

Como no podía ser menos, se tocó el tema de los LLMs (la mal llamada IA), y sus implicaciones éticas y profesionales. También hablamos de privacidad y se tocó en bastante profundidad el tema de los navegadores web y buscadores alternativos.

El meetup fue muy interesante y entretenido, tanto que nos fuimos pasadas las 20:00. No había una hora estimada de finalización y tanto yo como otros asistentes, si hubiésemos podido, nos habríamos quedado más tiempo. Para mí esto y el hecho de que todos queramos repetir significa que el meetup ha sido un éxito :-)

Ahora seguimos la conversación en el foro de la comunidad LibreCan² y en un futuro organizaremos un nuevo meetup, así que si resides en Canarias te invito a que entres a formar parte de nuestra comunidad.

Notas al pie de página:

Página Oficial de LibreCan

Foro de la Comunidad Librecan

¡LibreCan ya está aquí!

lfa — Mon, 03 Mar 2025 00:00:00 +0000

Hace unas semanas comentaba por aquí que con motivo del 40 aniversario de la FSF podíamos organizar un meetup informal sobre software libre en Canarias. Esa idea inicial ha evolucionado y hoy me hace muy feliz presentaros el meetup y comunidad LibreCan.

LibreCan es un punto de encuentro informal para personas que tienen curiosidad e interés por la cultura libre, el software libre, los derechos digitales, las redes sociales descentralizadas, el derecho a reparar, el libre acceso a la información y otros temas afines, en Canarias.

El lema del meetup, que se celebrará el próximo Sábado 10 de Mayo, es: "Conoce. Comparte. Debate." y desde aquí te invito a participar y conectar con gente con tus mismas inquietudes en la primera #LibreCan2025, y también a que participes en el foro.¡Súmate y hagamos crecer esta comunidad entre todos!

Se agradece muchísimo que compartas el enlace a LibreCan, https://librecan.com, para que le llegue a todas las personas que puedan estar interesadas. Muchas gracias por tu colaboración.

LibrePlanet Canarias

lfa — Thu, 06 Feb 2025 00:00:00 +0000

Con motivo del 40 aniversario de la Free Software Foundation¹ que se celebra este año, una de las muchas propuestas que hay sobre la mesa es la de realizar eventos locales de software libre (LibrePlanet) y se me ha ocurrido que podríamos organizar una LibrePlanet aquí en Canarias o más concretamente en Tenerife, dependiendo de las personas que se apunten y lo que decidamos entre tod@s.

La idea principal es hacer una quedada informal en algún bar, pub, guachinche o dónde se decida, para conocernos, compartir experiencias, despejar dudas, dar opiniones sobre el software libre, etc. Si estás interesad@ o conoces a alguien que pueda estarlo no dudes en contactar conmigo y así entre todos decidir la mejor manera de organizar el evento.

No hace falta ser un experto en informática para participar, simplemente hacen falta ganas y curiosidad por el software libre. Lo ideal es que participen personas de todo tipo y condición.

Por favor, compártelo para que pueda llegar a cuantas más personas mejor. También hay una publicación en Mastodon que puedes compartir y en la que puedes participar.

Notas al pie de página:

FSF Forty years of commitment to software freedom

Textbringer, un Emacs hecho con Ruby

lfa — Wed, 13 Nov 2024 00:00:00 +0000

Recientemente me he encontrado por casualidad con un editor EMACS like hecho completamente con Ruby: Textbringer¹. Este editor es extensible como GNU Emacs, pero en lugar que con elisp, como es lógico se puede extender con Ruby².

En cuanto me he enterado de su existencia me ha picado la curiosidad por probarlo. La instalación se realiza mediante RubyGems³ y como no me gusta cargar mi sistema con software que no utilizo he usado una máquina virtual con Debian GNU/Linux. Además el uso de la máquina virtual ha servido para tener exactamente las mismas condiciones para la comparativa que veremos más adelante.

A diferencia del editor mg del que hablo en otra publicación⁴, este editor tiene coloreado de sintaxis para C y Ruby y además soporta UTF-8. Como ya he mencionado, también permite extender el editor con Ruby, cosa que con mg no se puede hacer con ningún lenguaje. Otras características si son más estándar, dentro de las características de los "otros EMACS", como por ejemplo el hecho de que la ventana solamente se pueda dividir verticalmente o que, al seleccionar texto, este no queda resaltado por lo que debemos confiar en haberlo hecho bien a la primera.

He querido hacer una prueba con el consumo de memoria entre Textbringer, mg y GNU Emacs. Para la prueba, sin pretender hacer un benchmark exhaustivo, he utilizado el programa pmap(1) que viene instalado en todos los sistemas GNU/Linux. Todos los editores se han ejecutado recién instalados en la misma máquina virtual con los paquetes que vienen por defecto en Debian 12 (excepto Textbringer que como hemos visto hay que instalarlo con RubyGems), en una terminal, sin ningún paquete extra ni configuración personalizada y sin ningún archivo abierto. Los resultados han sido los que podemos ver en la siguiente tabla:

programa	consumo de memoria en kB
mg	6000
Textbringer	91000
GNU Emacs	172312

Como podemos observar Textbringer consume más de 10 veces lo que mg y solo la mitad que GNU Emacs. El hecho de que consuma más que mg es lo esperado ya que al ser un programa interpretado tiene la sobrecarga de tener que cargar el intérprete pero, considerando las pocas características extras que tiene con respecto de mg y las grandes carencias que tiene con respecto de GNU Emacs, el consumo que tiene Textbringer me parece increíblemente elevado.

Teniendo en cuenta que yo utilizo la última versión de GNU Emacs⁵, compilada a mano para mi sistema y que cargándolo en una terminal, con todos los paquetes extra y mis configuraciones personalizadas, sin tener ningún archivo abierto, me da un consumo de memoria de 163768 kB que es menos del doble que el consumo de Textbringer, definitivamente no es un programa que yo vaya a utilizar ni tampoco es un programa que pueda recomendar.

Notas al pie de página:

Repositorio de Textbringer en GitHub

Sitio oficial del lenguaje de programación Ruby

Sitio oficial de RubyGems

⁴

Publicación sobre mg

⁵

En realidad yo ejecuto GNU Emacs como demonio y luego uso emacsclient pero para hacer esta prueba comparativa lo he ejecutado normalmente.

Sobre el mal uso del término propietario

lfa — Thu, 24 Oct 2024 00:00:00 +0100

Hoy he recibido un correo electrónico de un compañero de la FSF que tuvo la amabilidad de hacerme ver que estaba utilizando de forma incorrecta el término "propietario" ya que en determinados contextos es más adecuado usar el término "privativo". También me pasó un enlace de un vídeo, en español, de RMS sobre el tema¹.

Sin que sirva de excusa, a veces me pasa que hay algunos términos en inglés que en mi cabeza entiendo perfectamente pero que, por los malos hábitos de cuando empecé a aprender inglés por mi cuenta, traduzco al español con una palabra similar, que significa casi lo mismo pero que no significa exactamente lo mismo. En mi caso las palabras con las que cometo este fallo habitualmente son "librería" por library en lugar que biblioteca y "propietario" por proprietary.

Tras el correo he hecho las correcciones necesarias en los contenidos de esta web así que ahora ya no hay propietario dónde debería ir privativo ni librerías donde deberían haber bibliotecas (aunque con este último estoy tan acostumbrado que seguro que seguirá pasándome).

Desde aquí quiero darle las gracias a @isf por haberse tomado el tiempo y la molestia de hacerme llegar sus comentarios.

Notas al pie de página:

Enlace al vídeo de RMS: https://video.hardlimit.com/w/tgFsM3fg5HKCdNS3NnFcS2

mg El editor de la familia Emacs que deberías conocer

lfa — Mon, 30 Sep 2024 00:00:00 +0100

mg es un pequeño, gran, editor que pertenece a la familia EMACS. Está basado en MicroEMACS y uno de sus objetivos es ser compatible con GNU Emacs (de hecho su nombre original era MicroGnuEmacs pero se cambió a petición de Richard Stallman).

Es un programa que está en el dominio público y actualmente se encuentra en los paquetes del sistema OpenBSD (dónde se mantiene), en los ports de FreeBSD, en los ports de NetBSD, en Devuan GNU/Linux y en Debian GNU/Linux. Seguramente se encuentre en más sistemas pero estos son los que yo he podido comprobar.

Características

Es un progama hecho en C por lo que es un editor muy rápido a la hora de arrancar y que utiliza muy pocos recursos. Incluye dired lo cual me parece muy acertado ya que podemos gestionar el sistema de archivos desde dentro del editor.

A diferencia de GNU Emacs no dispone de un lenguaje para extensiones pero es configurable y dispone de una cantidad de comandos nada desdeñables para un editor cuyo objetivo es minimizar el consumo de recursos. Para conocer todos los comandos y las posibilidades de configuración disponibles pudes consultar la página de manual oficial en OpenBSD¹

¿Qué uso se le puede dar a este editor?

Si usas GNU Emacs la curva de aprendizaje es prácticamente cero y, al ser un editor muy rápido y que consume muy pocos recursos, te resuelve la papeleta en todas esas circunstancias donde la gente suele tirar de otros editores como nano o vi. Piensa en mg como el nano para los usuarios de Emacs.

Yo lo utilizo principalmente en equipos remotos dónde no quiero o no puedo acceder con el modo TRAMP de GNU Emacs, como editor por defecto para otros programas que requieren de una edición simple como por ejemplo GIT (cuando no lo uso a través de Magit) y también lo utilizo en máquinas virtuales y equipos que tienen muy pocos recursos por lo que usar GNU Emacs es desaconsejable, imposible, o muy lento.

Sea como sea, lo vayas a utilizar o no, siempre es bueno saber que está ahí para cuando puedas necesitarlo.

Notas al pie de página:

mg página de manual en OpenBSD

Riesgos y desventajas de usar software privativo

lfa — Tue, 06 Aug 2024 00:00:00 +0100

En determinados círculos la noticia del día es que se ha colgado en internet la última versión de WordStar (7.0d) para sistemas operativos DOS. Este programa es un editor de textos lanzado en 1978 y desarrollado por la empresa MicroPro, que ha pasado por varias manos en distintas rondas de adquisiciones a lo largo de los años. La última versión publicada de este programa, para sistemas DOS, data del año 1992.

WordStar fue muy utilizado en su época y a día de hoy sigue teniendo usuarios entre los que cabe destacar a los escritores George R. R. Martin y Robert J. Sawyer, que es la persona responsable de haberlo colgado en internet en un archivo zip¹ que contiene el programa, los emuladores necesarios para poder ejecutarlo en sistemas windows, los manuales originales escaneados, y otros materiales diversos.

El escritor dice que ha subido el paquete porque, cito textualmente: "The program has never been updated since, and the company that made it has been defunct for decades; the program is abandonware." (El programa nunca ha sido actualizado desde entonces y la empresa que lo hizo lleva muerta décadas; el programa es abandonware).

Sin embargo el escritor se arriesga a que le caiga una demanda por infringir derechos de autor ya que WordStar es un programa privativo cuyo copyright está en manos de alguna entidad aunque el programa esté "abandonado". De hecho no solo está vulnerando el copyright de quien sea que tenga los derechos del programa WordStar, sino que vulnera los de todos los demás programas y documentos que vienen incluidos en el archivo zip a excepción de aquellos cuyos derechos de autor sean propiedad de Robert J. Sawyer y aquellos de los que este tenga una autorización del propietario de los mismos para distribuir los programas, manuales y demás recursos que contiene dicho archivo zip.

Probablemente nadie vaya a demandarlo por esto y por eso mismo es por lo que el escritor ha hecho lo que ha hecho, pero la realidad es que esta acción es ilegal, es demandable y es punible por la ley. De hecho supongo que Robert J. Sawyer es consciente de la infracción porque él mismo tiene en su web una nota de copyright propia² para sus propios contenidos que prohíbe expresamente almacenar o poner a disposición sus contenidos en cualquier sistema informático destinado a ser accedido por el público o subir sus contenidos a cualquier otro sistema informático, tablón de anuncios, red o servidor.

Sinceramente creo que el propietario de los derechos de WordStar ni siquiera debe saber que los tiene, estarán en algún archivo cogiendo polvo y esta es la realidad del software privativo; cuando deja de ser rentable el propietario se olvida del programa y los que sufren son los usuarios que lo compraron que se quedan con un software sin soporte abocado a desaparecer ya que al no disponer nadie del código fuente no se puede mantener ni portar a otras plataformas. También es problable que dichos usuarios pierdan todos sus datos porque si estos están almacenados en archivos con un formato privativo, cabe la posibilidad de que que no se puedan abrir en ningún otro programa.

Ahora tomemos como ejemplo el programa GNU Emacs³ que es software libre, licenciado bajo la licencia GNU GPL⁴, y cuya documentación oficial también es libre, licenciada bajo la licencia GNU FDL⁵. Cada uno de los usuarios de Emacs gracias a las licencias libres tenemos entre otros los siguientes derechos:

El derecho a tener el código fuente del programa y de la documentación.
El derecho a modificar dicho código fuente a nuestro antojo.
El derecho a redistribuir tanto el programa, como la documentación a quien nosotros queramos bajo las mismas condiciones.
El derecho a redistribuir nuestras modificaciones del programa y de la documentación bajo las mismas condiciones.

Esto quiere decir que si se diera el improbable caso de que Emacs se convirtiera en "abandonware", todos los usuarios podríamos (de hecho podemos) hacer lo que ha hecho Robert J. Sawyer de forma 100% legal sin tener que preocuparnos porque alguien vea que estamos compartiendo su software en nuestra web y decida demandarnos por infringir su copyright. Aún más importante es el hecho de que como todos tenemos el código fuente y podemos mantener el software y su documentación, o pagar a alguien para que lo haga, es prácticamente imposible que llegue a darse el caso de que el software quede abandonado y mucho menos que no podamos acceder a nuestros datos.

Notas al pie de página:

WordStar for DOS 7.0 Archive

No enlazo la nota de copyright citada porque enlazar a ella supondría, según el contenido de la misma, que este artículo está sujeto al copyright de este señor, pero podéis verla pinchando en el enlace copyright en el pie de página de su web.

Web oficial de GNU Emacs

⁴

GNU General Public License

⁵

GNU Free Documentation License

Como crear y publicar tu sitio web con Emacs y Org Mode

lfa — Fri, 05 Jul 2024 00:00:00 +0100

Hace tiempo que están bastante de moda los generadores de sites estáticos para crear un sitio web y en general estos generadores usan Markdown como lenguaje de marcas para generar el contenido html del sitio web.

Muchos usuarios de Emacs utilizamos Org Mode en nuestro día a día y la verdad es que una vez que te has acostumbrado a usarlo es una gozada de utilizar así que ¿por qué no usarlo también para crear el contenido de nuestro sitio web?

En este howto vamos a ver cómo utilizar el generador de sites estáticos Pelican para crear un sitio web con documentos de Org Mode en Emacs. Quiero dejar claro que no es el objetivo de este howto el explicar todas las características, funcionalidades y configuraciones posibles con Pelican, para eso te recomiendo que utilices su documentación¹ que además es bastante buena y completa.

Doy por hecho de que ya sabes qué es Emacs y qué es Org Mode y que además sabes utilizar ambos. De hecho si estás leyendo esto es porque probablemente seas usuario habitual de Org Mode.

Instalando Pelican y creando nuestro sitio base

Lo primero que debes hacer es descargar e instalar Pelican. En mi caso yo lo hago con virtualenv (puedes consultar otros métodos de instalación en el sitio web de Pelican ²), abro una terminal, voy a la ruta donde guardo mis entornos virtuales y luego ejecuto lo siguiente:

virtualenv pelican              # crea el entorno virtual
source pelican/bin/activate     # activa el entorno
pip install pelican             # instala Pelican

Si no tienes virtualenv en tu sistema seguro que está en el repositorio de paquetes de tu distribución de GNU/Linux. Si usas otro sistema consulta la documentación oficial de virtualenv³.

El entorno virtual seguirá activo en esta terminal hasta que ejecutemos el comando deactivate. No ejecutes el comando porque necesitamos el entorno para ejecutar los siguientes pasos.

Ahora que ya tenemos Pelican instalado y funcionando seguimos los pasos del inicio rápido para crear nuestro sitio web:

mkdir -p /ruta/local/del/proyecto/nuestra-web   # creamos una carpeta para nuestro proyecto web
cd /ruta/local/del/proyecto/nuestra-web         # entramos en la carpeta
pelican-quickstart                              # ejecutamos el inicio rápido

Durante el proceso de inicio rápido Pelican nos hará una serie de preguntas para configurar el proyecto de nuestro sitio web. Las respuestas probablemente serán distintas para tu caso pero, para que te hagas una idea, esto es lo que nos va a preguntar con unas posibles respuestas de muestra:

> Where do you want to create your new web site? [.] 
> What will be the title of this web site? Mi Sitio Web
> Who will be the author of this web site? yomismo
> What will be the default language of this web site? [es] 
> Do you want to specify a URL prefix? e.g., https://example.com   (Y/n) Y
> What is your URL prefix? (see above example; no trailing slash) https://misitio.com
> Do you want to enable article pagination? (Y/n) Y
> How many articles per page do you want? [10] 
> What is your time zone? [Europe/Rome] 
> Do you want to generate a tasks.py/Makefile to automate generation and publishing? (Y/n) Y
> Do you want to upload your website using FTP? (y/N) N
> Do you want to upload your website using SSH? (y/N) y
> What is the hostname of your SSH server? [localhost]
> What is the port of your SSH server? [22] 
> What is your username on that server? [root] user
> Where do you want to put your web site on that server? [/var/www] 
> Do you want to upload your website using Dropbox? (y/N) N
> Do you want to upload your website using S3? (y/N) N
> Do you want to upload your website using Rackspace Cloud Files? (y/N) N
> Do you want to upload your website using GitHub Pages? (y/N) N

De momento podemos ejecutar el comando deactivate y salir del entorno virtual ya que tenemos varias cosas que hacer antes de que nos haga falta de nuevo.

Configurando Pelican para Org Mode

Para nuestro objetivo necesitamos el plugin org_reader⁴, así que vamos a obtener los plugins de Pelican. La forma más rápida de obtener los plugins es descargarlos desde su repositorio en GitHub⁵ y ponerlos en la carpeta que queramos. Ya le indicaremos a Pelican la ruta a esa carpeta en el siguiente paso. Para ello vamos a la carpeta dónde queramos descargar los plugins y ejecutamos el siguiente comando:

git clone --recursive https://github.com/getpelican/pelican-plugins

Una vez que tenemos los plugins, procedemos a configurar Pelican para que use el plugin org_reader que es la pieza fundamental para generar nuestro sitio web a partir de archivos *.org de Org Mode.

Abrimos el archivo pelicanconf.py y le añadimos lo siguiente justo al principio:

import os # esta línea ya está en el archivo

PLUGIN_PATHS = ["/ruta/a/la/carpeta/donde/están/los/plugins/de/pelican"]
PLUGINS = ["org_reader"]

En el caso de que tengamos una instalación de Emacs en una ruta distinta a las habituales también añadimos la siguiente línea:

ORG_READER_EMACS_LOCATION = "/ruta/al/ejecutable/de/emacs"

Añadiendo coloreado de sintaxis

Para mi sitio web me faltaba una cosa importante que era añadir el coloreado de sintaxis para las publicaciones que, como esta, contienen código fuente. Así que tras buscar di con el sitio web de Anten Linevich⁶ donde solucionaba el problema creando un export backend personalizado.

Para hacer esto mismo volvemos a abrir nuestro archivo pelicanconf.py y añadimos lo siguiente:

ORG_READER_EMACS_SETTINGS = os.path.abspath("lisp/pelican-html.el")
ORG_READER_BACKEND = "'pelican-html"

Ahora vamos a crear nuestro backend personalizado pelican-html siguiendo estos pasos:

Creamos en el raíz de nuestro proyecto web la carpeta lisp/. Podemos llamarla como queramos pero debe coincidir con lo que hemos definido en la constante ORG_READER_EMACS_SETTINGS de arriba.

Dentro de esa carpeta creamos el archivo pelican-html.el y dentro del mismo ponemos lo siguiente:

   ;; Este código es (c) 2017 Anten Linevich y está licenciado bajo 
   ;; Creative Commons Attribution 4.0 Internacional License
   ;; https://linevi.ch/en/org-pygments.html

   (require 'org)
   (require 'ox)
   (require 'ox-html)

   (org-export-define-derived-backend 'pelican-html 'html
     :translate-alist '((src-block .  pelican/pygments-org-html-code)
                        (example-block . pelican/pygments-org-html-code)))

   (defvar pygments-path "pygmentize")

   (defun pelican/pygments-org-html-code (code contents info)
     "Process code block with Pygments See http://pygments.org/ for details"

     ;; Generate temp file path by hashing current time and date.
     (setq temp-source-file(
          format "/tmp/pygmentize-%s.txt"(md5 (current-time-string)))
     )
     ;; Writing temp file
     (with-temp-file temp-source-file (insert (org-element-property :value code)))
     ;; Processing
     (shell-command-to-string (format "%s -l \"%s\" -f html %s"
                                      pygments-path
                                      (or (org-element-property :language code)
                                          "")
                                      temp-source-file)))

   (provide 'pelican-html)

Guardamos el archivo y ya lo tenemos todo listo para que nos haga el coloreado de sintaxis.

Escribiendo nuestra primera publicación

Vamos a escribir nuestra primera publicación para ver una plantilla básica que nos será muy útil a la hora de crear nuevas publicaciones.

Hay un montón de propiedades, metadatos en la jerga de Pelican, que podemos usar para "configurar" una publicación. Aquí solamente aparecen las que yo considero más habituales y/o importantes. Para verlas todas puedes ir a la documentación de Pelican y del plugin org_reader (ver notas al pie).

Dentro de la carpeta content/ de nuestro sitio Pelican vamos a crear un archivo hola-mundo.org con el siguiente contenido:

#+TITLE: ¡Hola Mundo!
#+DATE: 2024-05-24
#+AUTHOR: admin
#+LANGUAGE: es
#+CATEGORY: Programación
#+PROPERTY: LANGUAGE es
#+PROPERTY: SLUG hola-mundo
#+PROPERTY: SUMMARY Este es el resumen de la publicación
#+PROPERTY: SUMMARY+ que puede ir así en varias líneas
#+PROPERTY: TAGS programación, c

A continuación vamos a ver el código fuente del programa Hola Mundo en C.
#+BEGIN_SRC c
  #include <stdio.h>
  int main(void)
  {
          printf("¡Hola Mundo!");
          return 0;
  }
#+END_SRC


#+BEGIN_EXPORT html
<hr>
<center><small>
Y esto es un bloque HTML a modo de muestra.
<p>
<a href="https://creativecommons.org/licenses/by-nd/4.0/legalcode.es">Licencia Creative Commons Atribución-SinDerivadas 4.0 Internacional (CC BY-ND 4.0)</a>
</p></small>
</center>
<hr>
#+END_EXPORT

A continuación una breve descripción de las propiedades/atributos del documento:

#+TITLE: ¡Hola Mundo! es la única propiedad obligatoria.
#+DATE: 2024-05-24 la fecha del documento puede ser una fecha en formato iso (como en el ejemplo) o un timestamp de Org Mode.
#+AUTHOR: admin el nombre del autor
#+LANGUAGE: es el idioma en el que está el documento para Org Mode
#+CATEGORY: Programación categoría de la publicación
#+PROPERTY: LANGUAGE es el idioma en el que está el documento para Pelican
#+PROPERTY: SLUG hola-mundo si no se especifica es el nombre del archivo *.org de la publicación
#+PROPERTY: SUMMARY resumen de la publicación
#+PROPERTY: TAGS programación, c las etiquetas que queramos ponerle

Aparte de las propiedades que se ven en el ejemplo hay una que a mi me parece fundamental, la de estado, #+PROPERTY: STATUS. Esta propiedad puede tener los siguientes valores:

published (publicado): es el estado por defecto aunque no lo pongamos.
draft (borrador): las publicaciones se guardan en la carpeta drafts/ del sitio web y no están enlazadas en ningún sitio.
hidden (oculto): las publicaciones no aparecen enlazadas en ningún sitio y para acceder a ellas hay que conocer el enlace exacto.

Por lo tanto si queremos tener una publicación oculta añadiríamos esta etiqueta:

#+PROPERTY: STATUS hidden

Previsualizando y publicando nuestro sitio web

Ha llegado la hora de la verdad, de ver los resultados de todo el trabajo que hemos hecho, comprobar si todo funciona y ver como generar y publicar nuestro nuevo sitio web.

Desde la carpeta de nuestro proyecto web hacemos lo siguiente:

Volvemos a activar el entorno virtual:

   source /ruta/a/nuestro/virtualenv/pelican/bin/activate

Ponemos en marcha la previsualización del sitio:
```
   make devserver
```
Si nos fijamos, el comando anterior nos devolverá, entre otras cosas, lo siguiente:
```
   Serving site at: http://127.0.0.1:8000 - Tap CTRL-C to stop
```
Así que copiamos y pegamos la url http://127.0.0.1:8000 en nuestro navegador favorito para poder ver nuestra web.

Este modo, devserver, regenera automáticamente nuestro sitio web con cada cambio que hacemos en nuestro archivo *.org por lo que siempre podremos ver los cambios recargando nuestro navegador.
Salimos del modo devserver pulsando las teclas CTRL-C y si queremos publicar nuestro sitio web ejecutamos:
```
   make rsync_upload
```
Este comando volverá a generar todo el sitio y lo subirá a dónde le hayamos indicado cuando hicimos la configuración inicial en el inicio rápido. Si por cualquier motivo no funciona o no existe esta opción, abre el archivo Makefile en el raíz de tu proyecto web y al final del mismo deberían de aparecer todas las opciones disponibles para subir tu sitio web al hosting (ssh_upload, sftp_upload, etc.).

Siguientes pasos

En este howto hemos dado los primeros pasos para crear un sitio web con Pelican y gestionar sus contenidos escribiéndolos con Emacs y Org Mode. Ahora es el momento de profundizar con Pelican para crear tu sitio web a tu gusto así que utiliza la documentación de Pelican y busca un tema⁷ que te guste para tu web, o crea el tuyo propio.

Agradecimientos

Quiero darle las gracias a BxCx del canal #emacs-es en Libera.chat⁸ ya que la idea de este howto surgió porque estando en el citado canal empezó a hablar del tema de cómo crear un sitio estático con Emacs y me estuvo preguntando sobre cómo estaba hecho este sitio.

También quiero darle las gracias a Anten Linevich porque sin su publicación no habría dado con la tecla para poner el coloreado de sintaxis.

Copyright

Notas al pie de página:

Documentación oficial de Pelican

Documentación oficial de Pelican: Instalación

Documentación oficial de Virtualenv

⁴

Plugin Org Reader

⁵

Plugins de Pelican en GitHub

⁶

Sitio web de Anten Linevich

⁷

Pelican Themes

⁸

Libera.chat

Inaugurando versión en inglés

lfa — Thu, 16 May 2024 00:00:00 +0100

Hoy he puesto en marcha una versión en inglés de esta web. El motivo principal de la versión en inglés es la de tener un lugar "internacional" donde compartir mis proyectos para un público más amplio que no sea hispanoparlante.

En ningún caso pretendo mantener una traducción 1-1 al inglés, eso lo intenté en el pasado y nunca salió bien, simplemente no me gusta traducirme a mí mismo.

Las expectativas ahora mismo son que esta versión en español siga siendo el sitio principal por lo que tendrá más contenido que la versión en inglés aunque es probable que en la versión en inglés haya publicaciones que no aparezcan aquí y viceversa, del mismo modo que en Mastodon hay publicaciones en uno de los dos idiomas y a veces hay publicaciones 1-1.

Esto es todo, gracias por leerme.

Libre Planet 2024: cultivando la comunidad

lfa — Wed, 15 May 2024 00:00:00 +0100

Durante el primer fin de semana de este mes se celebró la Libre Planet 2024¹, el evento de referencia sobre Software Libre organizado por la FSF². Este evento se realiza tanto de forma presencial como virtual por lo que no es necesario viajar para participar y disfrutarlo.

Yo no suelo participar más allá de ver la charla inaugural, que por cierto este año me he perdido, y la charla de RMS³, que este año fue una ronda de preguntas y respuestas que no estaba en el programa y que casi me pierdo, pero gracias a que avisaron por el IRC llegué a tiempo. Por lo demás lo que suelo hacer es ver, cuando me viene bien, los vídeos del evento una vez que los publican.

Sin embargo este año sí que decidí asistir de forma online al evento y además el tema de este año era Cultivating Community (cultivando la comunidad) por lo que incluso podemos decir que era una señal para participar ;-)

Había ponencias para todos los gustos: técnicas, filosóficas, workshops, etc. y es imposible participar en todas porque se realizan de forma simultánea en 3 salas diferentes: Jupiter, Saturn y Neptune (esta última solo online), así que tienes que escoger y dejar para después, cuando se publiquen los vídeos, el resto de ponencias que te interesan. Hubo ponencias estupendas y otras me decepcionaron un poco ya que esperaba otra cosa, pero es lógico no a todos nos gusta todo y a veces una descripción no es suficiente para hacerte una idea de los derroteros que va a tomar una ponencia.

Una de las cosas que más me gustaron de participar fue que en todo momento puedes interactuar desde el IRC⁴ y hacer preguntas que después los organizadores pasan al ponente para que conteste y, en este proceso, también puedes comentar con el resto de la gente que está en el chat. Esta interacción me sirvió para hacer algunas amistades. Otra de las cosas que disfruté bastante fue la reunión para miembros de la FSF y ahí también hice algunos amigos. Estuvo tan interesante que a todos se nos hizo muy corta.

Para mí estar ahí con un montón de personas que, a pesar de las muchas diferencias que pueden tener, comparten unos mismos ideales, puntos de vista e inquietudes ha sido estupendo, he hecho alguna amistad nueva y, en resumen, es una experiencia que le recomiendo a cualquiera que tenga interés en el Software Libre.

El evento iba de cultivar la comunidad y en mi opinión ha sido así al 100%. Me he sentido muy bien integrado y desde aquí quiero dar las gracias, otra vez, a la organización del evento. El año que viene podéis apuntaros y participar vosotros para vivir una experiencia que espero que os resulte igual de agradable que a mi.

Happy hacking.

Notas al pie de página:

Web de Libre Planet 2024

Web de la Free Software Foundation

Web de Richard M. Stallman

⁴

Libera.chat es la red IRC donde se alojan los canales de la FSF: #fsf #fsf-members #gnu #gnu-es

Ya disponibles las licencias de la FSF en español

lfa — Thu, 12 Oct 2023 00:00:00 +0100

Para facilitar e impulsar la adopción de las licencias de la FSF¹ por parte de otros programadores y autores de documentación técnica he traducido al español las principales licencias de la FSF.

Estas traducciones no son oficiales por lo que a la hora de utilizar la licencia correspondiente en nuestros proyectos debemos añadir la versión original en inglés de la FSF. Sin embargo, al ser un documento legal, creo que estas traducciones resultarán útiles para comprender en qué condiciones liberamos nuestros proyectos de software libre.

En mi caso por ejemplo la elección es sencilla. Yo uso siempre la AGPL² ya que hoy en día es muy fácil que nuestro software acabe formando parte de algún backend en algún servicio en internet. Con la AGPL nos aseguramos de que siempre se redistribuya el código fuente con los cambios que haya podido hacer quien sea que lo esté utilizando y, más importante aún, nos aseguramos (al menos legalmente) de que nadie utilice el trabajo que tan alegremente donamos a la sociedad para crear un proyecto privativo.

Las traducciones están disponibles en el proyecto: Traducción de Licencias de la FSF al Español³ en esta web.

Espero que te resulten útiles y que, si no lo estás haciendo ya, te animes a empezar a usar estas licencias para tus proyectos de software libre. Cualquier corrección o comentario ya sabes que puedes hacerlo por correo electrónico⁴

Notas al pie de página:

Página oficial de las licencias de GNU

AGPL en español / AGPL original en inglés

Traducción de Licencias de la FSF al Español

⁴

Ver apartado Contacto en la sección Acerca de de esta web.

Quasijarus2Gzip, cómo se empieza un programa por casualidad

lfa — Sat, 19 Aug 2023 00:00:00 +0100

Resulta que recientemente cayó en mis manos un viejo archivo *.tar que contenía código fuente de diferentes programas de Unix y entre estos programas había varios, como una antiquísima versión de sendmail, que me picaron la curiosidad. Cuando fuí a descomprimir uno de los archivos me encontré con que no podía.

Anteriormente ya había descomprimido archivos *.tar.Z con gzip así que lo siguiente que hice fue ver qué era exactamente ese archivo *.tar.Z. Para ello utilicé el comando file y me encontré conque era un archivo del tipo Quasijarus Strong Compression Data. Como no sabía lo que era, seguí investigando.

Ahora había que averiguar qué era exactamente el formato Quasijarus Strong Compression Data. Primero encontré una breve descripción del formato¹ que contenía enlaces a la web del proyecto Quasijarus. Estos enlaces ya no están operativos pero gracias a archive.org² pude repescar la web del proyecto Quasijarus³ y concretamente la información sobre el formato de compresión⁴.

Tras leerlo todo, lo más importante que averigüé fue que:

Este formato de archivo está basado en Gzip y que ambos formatos solamente difieren en sus cabeceras.
La cabecera del formato Quasijarus Strong Compression Data solamente está compuesta por los bytes 0x1f 0xa1 (número mágico).

Así que decidí hacerme un conversor de Quasijarus Strong Compression Data a Gzip ya que no podía ser muy complicado y además iba a proporcionarme la excusa de echar un rato divertido ;p.

El siguiente paso fue averiguar el formato de la cabecera del formato Gzip y según su especificación⁵, este tiene una cabecera de 10 bytes repartidos del siguiente modo:

2 bytes que son el número mágico 0x1f 0x8b
1 byte que indica el algoritmo de compresión (08 para DEFLATE).
1 byte que son banderas de cabeceras que, para el caso que nos ocupa, se podían dejar a 0.
4 bytes para el timestamp del archivo que también se puede dejar a 0 porque no es obligatorio indicarlo.
1 byte para las banderas de compresión que también se puede dejar sin asignar.
1 byte para el identificador del sistema operativo (3 para Unix)

Con toda la información clara me hice el conversor de Quasijarus Strong Compression a Gzip y puedes descargártelo aquí.

Notas al pie de página:

Quasijarus Strong Compression

Wayback machine en archive.org

Quasijarus Project

⁴

Quasijarus Compress

⁵

RFC1952

¡Hola Mundo!

lfa — Fri, 31 Mar 2023 00:00:00 +0100

Cuando uno aprende un nuevo lenguaje de programación es costumbre hacer el programa ¡Hola Mundo!. Mi primer lenguaje de programación fue BASIC y no hice el ¡Hola Mundo!, hice un programa que mostraba en pantalla mi nombre.

Mi primer ¡Hola Mundo!, al igual que el de muchos otros programadores, fue el del libro: El Lenguaje de Programación C, también conocido como K&R por las iniciales de los apellidos de sus autores: Brian W. Kernigham y Dennis M. Ritchie.

Así que como primera publicación me ha parecido adecuado seguir la tradición y empezar publicando un ¡Hola Mundo! y nada mejor que publicar un hola mundo en C.

#include <stdio.h>
int main(void)
{
        printf("¡Hola Mundo!");
        return 0;
}