Linux

Algunos apuntes sobre tecnología moderna y no tan moderna

I.

Las X han cumplido 40 años (y urge jubilarlas).

II.

Escribes código en el panel de la izquierda, eliges el compilador y ves el código generado (típicamente, ensamblador) en el panel de la derecha de esto.

III.

Alguien hizo ingeniería inversa de Github Copilot y escribió esto.

IV.

Esta aplicación convierte PDFs en podcasts. Muy alineada con las tendencias de estos tiempos que vivimos.

V.

Aquí no solo se estima el consumo de energía que realiza un LLM al generar texto sino que también se compara con el del sujeto al que reemplazaría. Eso sí, no menciona a Jevons por ninguna parte.

Sobre mi nueva infraestructura de backups

Tengo dos ordenadores, tiramisu y ede. Uno va conmigo y el otro me espera en casa.

Hasta hace 4 días, usaba OwnCloud para mantenerlos sincronizados y, de paso, gestionar mis backups: siempre tenía tres copias de mis datos en tres sitios distintos (mis dos ordenadores y un VPS). Pero:

  • Alquilar un disco duro en la nube no es tan barato.
  • OwnCloud es un coñazo: hay que actualizarlo cada que se te olvida cómo.
  • OwnCloud es demasiado… aparatoso. Es más adecuado para organizaciones que para uso personal.

Buscando alternativas, llegué a una lista corta de dos:

Mi infraestructura para Python

Resumen:

  • He decidido usar RStudio como IDE para Python. RStudio no es el mejor IDE para desarrollar, pero es incomparablemente mejor que cualquier otro IDE para explorar, etc. Funciona muy bien y solo puede mejorar.
  • He decidido pasar de Jupyter. Los notebooks valen para lo que valen, pero no para lo que hago. En caso de necesidad, uso Rmarkdown con bloques de Python. De nuevo, funcionan muy bien y solo pueden mejorar.
  • Finalmente, he decidido pasar de Anaconda. Tiene incompatibilidades con RStudio. Particularmente, cuando los módulos de Python tratan de cargar shared libraries. Los módulos de Anaconda tienen el vicio de buscarlos dentro del directorio de instalación, pero al lanzar el intérprete de Python a través de reticulate, en Linux parece que los busca en el sistema (por debajo de /usr/lib y similares). Y todo se rompe mucho. Mucho y muy, muy feo.

Así que uso los Python (3.7 cuando puedo, otras versiones cuando me obligan) del sistema. Pero la instalación del sistema es mínima. He creado varios environments ad hoc (y dentro de un directorio ad hoc para ellos) y obigo a reticulate a usarlos (vía use_virtualenv()) según conveniencia. En ellos tengo todas las dependencias (de numpy para arriba).

Windows Subsystem for Linux

Igual todo el mundo conoce ya WSL. Pero por si acaso queda entre la audiencia algún otro despistado, pues, eso: que existe en Windows 10 (¿solo?) un subsistema Linux que permite correr comandos de consola, instalar paquetes (p.e., con apt-get), etc. Incluso R. Me queda solo la duda del entorno gráfico, sobre el que no he visto nada.

En su día, Windows fue un programa de MS-DOS que arrancaba al escribir win en la consola. Después hubo que arrancar la consola como un programa más de Windows.

Unix para poetas

Existe una breve obrita, Unix for Poets, que utiliza el análisis cuantitativo de texto como excusa para aprender a manejar una serie de comandos inexcusables de Unix y sus derivados: wc, grep, etc.

Se la recomiendo particularmente a aquellos que se compraron una Mac y no saben que cuentan con una terminal decente oculta en alguna parte de su sistema (en serio, los hay: el otro día se la descubrí a una maquera).

Dónde guardar los paquetes de R (en Linux, al menos)

R

En todos mis Linux, desde el principio de los tiempos, R guardaba los paquetes en

  • /usr/lib/R/library
  • /usr/lib/R/site-library (¡a veces y no sé por qué!)
  • /usr/local/lib/R/site-library

Bajo /usr/lib deberían instalarse solo aquellos que vienen de serie con la instalación de R (o que se instalan usando el sistema de actualización de paquetes de la distribución de Linux) mientras que bajo /usr/local vivirían los instalados posteriormente por el usuario (véase esto).

Por supuesto, para escribir /usr/local/lib/R/site-library hacen falta permisos de superusuario y los paquetes ahí instalados están disponibles para todos los usuarios de la máquina. Pero de un tiempo a esta parte y por culpa, creo, de RStudio (tanto en versión de escritorio como de servidor), se me han comenzado a instalar paquetes en ~/R, bajo mi directorio personal. ¡Anatema!

Mis copias de seguridad

Por referencia mía y de otros, voy a dejar acá escrito y explicado cómo gestiono mis copias de seguridad. Porque los discos duros se rompen y los ordenadores desaparecen. Etc.

Primero, mi instalación: tengo un ordenador de bajomesa (tiramisu) y un netbook (kropotkin). Ambos corren la misma versión de Xubuntu, la última estable.

Mi primera línea de defensa contra las pérdidas de información es la sincronización de ambas máquinas. Aquellos directorios que contienen cosas que no quiero perder (documentos, fotos, código, ¡copias de seguridad de otras máquinas, incluido esto que lees ahora!, cosas que no son documentos en desarrollo, etc.) se guardan en el directorio .bck de ambos ordenadores. Los directorios que veo son enlaces blandos (vía ln) a subdirectorios de .bck.

¿Creer o no creer?

El otro día me llegó por correo el Informe sobre el Uso del Software Libre en los Hogares Españoles 2011. Lo realiza el CENATIC, Centro Nacional de Referencia de Aplicación de las Tecnologías de Información y la Comunicación basadas en Fuentes Abiertas, por lo que uno espera, de antemano, cierto sesgo.

Una de las tablas de resultados es:

Entiendo que los porcentajes de uso se refieren al universo de la población española, extrapolados mediante un […] muestreo por cuotas, donde se incluyen cuotas con afijación proporcional al peso real de la población objeto, obteniendo estos datos del Instituto Nacional de Estadística, en el período más actualizado.