Instalar servidor Nginx con PHP en Debian 11

En este artículo enseño cómo instalar un servidor Nginx que pueda ejecutar programas de PHP en Debian 11.

Primero hay que instalar los siguientes paquetes:

sudo apt install nginx php php-fpm

A continuación, hay que descomentar las siguientes líneas del archivo de configuración predeterminado de Nginx (/etc/nginx/sites-available/default):

#location ~ \.php$ {
#   include snippets/fastcgi-php.conf;
#
#   # With php-fpm (or other unix sockets):
#   fastcgi_pass unix:/run/php/php7.4-fpm.sock;
#   # With php-cgi (or other tcp sockets):
#   fastcgi_pass 127.0.0.1:9000;
#}

Quedando así Continúa leyendo Instalar servidor Nginx con PHP en Debian 11

Snaps en Ubuntu: menos seguridad y actualizaciones automáticas

Con su nueva versión 22.04, que será publicada el 21 de abril, Ubuntu hará que más programas usen paquetes Snap en vez de los .deb. Estos paquetes se actualizan de forma automática sin pasar por una fase de prueba como sucede con los paquetes de Debian y otras distribuciones. En el caso del paquete de Firefox, es el equipo de Mozilla (no Ubuntu) quien decide cómo y cuándo se actualiza el navegador.

Firefox es software libre, pero incluye componentes privativos como Pocket. Mozilla puede mediante Snap añadir otros componentes parecidos y funcionalidades desagradables.

Los Snaps tienen algunas ventajas: permiten empaquetar un programa con todas sus dependencias, funcionan en cualquier distribución, etc. Sin embargo, ralentizan el proceso de arranque, son mucho más lentos cuando se ejecutan por primera vez, ocupan más espacio (pues contienen en ellos bibliotecas que podrían usarse por varios programas), su repositorio predeterminado («tienda») es privativo, requiere el uso de systemd, etc.

Si el uso de los Snaps fuera opcional en Ubuntu, no habría tanta controversia, pero Ubuntu los ha impuesto para varios paquetes, para los que ya no existe una alternativa .deb.

Otro ataque a la cadena de suministro en npm: EventSource polyfill

Por si npm no había demostrado ser un gestor de paquetes inseguro —recientemente con el malware de node-ipc—, otra biblioteca muy utilizada, descargada más de 600 000 veces por semana con npm, llamada EventSource polyfill ha añadido mensajes propagandísticos escritos en ruso a favor del régimen de Ucrania dirigidos a quienes tienen su zona horaria configurada como una región de Rusia, llegando a abrir una ventana en el navegador con la URL de una recogida de firmas contra la guerra.

Muestra mensajes falsos como «El 91 % de los ucranianos apoya plenamente a su presidente Volodímir Zelenski», cuando la participación política en las elecciones de 2019 fue del 49,84 % y el partido de este político consiguió en total 6 307 793 votos (un 43,16 %). También recomienda acceder al periódico de la BBC (un periódico estatal británico) mediante Tor (pues está censurado en Rusia) como fuente de información fiable.

Escribir letras especiales del esperanto con teclado español en GNU/Linux

En la distribución del teclado española por defecto no se puede escribir la ŭ del esperanto, pero sí las ĉ, ĝ, ĥ, ĵ y ŝ, pulsando ^ y la letra correspondiente (c, g, h, j o s).

Puedes seleccionar una distribución de teclado para el esperanto y alternar entre esta y la distribución española para no tener que pulsar varias teclas a la vez cuando escribes en esperanto. Sin embargo, si solo escribes esporádicamente en esperanto, quizás te resulte más sencillo escribir esos caracteres especiales con combinaciones de teclas. Vale, ¿pero cómo escribes la ŭ?

En el algunos entornos de escritorio existe la opción de habilitar las teclas especiales del esperanto. Continúa leyendo Escribir letras especiales del esperanto con teclado español en GNU/Linux

Es importante que el software libre use infraestructuras de software libre

Este artículo es una traducción del artículo «It is important for free software to use free software infrastructure» publicado por Drew Devault bajo la licencia CC BY-SA 2.0.

Aviso: he fundado un proyecto y una empresa centrada en infraestructura de software libre. Decido no nombrarlos en esta publicación y solo recomendaré soluciones en las que no tengo un interés personal.

Los proyectos de programas libres necesitan infraestructura; un lugar para facilitar cosas como la revisión de código, apoyo al usuario final, seguimiento de errores, mercadotecnia, etc. Un ejemplo común de esto es la plataforma de «forja»: infraestructura que se anuncia como una tienda de todo en uno para muchas de las necesidades de proyectos libres, como alojamiento y revisión de código, seguimiento de errores, discusiones, etc. Muchos proyectos también recurrirán a plataformas adicionales para proporcionar otros tipos de infraestructura: salas de chat, foros, redes sociales y demás.

Muchas de estas necesidades tienen a su disposición soluciones no libres, privativas. GitHub es una popular forja de código privativa, y GitLab, el mayor competidor de GitHub, es parcialmente no libre. Algunos proyectos usan Discord o Slack para salas de chat, Reddit como foro, o Twitter y Facebook para mercadotecnia, divulgación y soporte; todos estos son no libres. En mi opinión, depender de que estas plataformas proporcionen infraestructura para tus proyectos libres es un error.

Cuando tu proyecto libre elige usar una plataforma no libre, le das un voto de confianza oficial en nombre de tu proyecto. En otras palabras, le prestas parte de la credibilidad y legitimidad de tu proyecto a las plataformas que eliges. Estas plataformas son fruto de efectos de red, y tu elección es una inversión en esa red. Yo cuestionaría esta inversión por si sola, la conciencia de que estás brindando a estas plataformas tu confianza y legitimidad; pero también hay una consecuencia más preocupante de esta elección: una inversión en una plataforma no libre también es una no inversión en las alternativas libres.

Repito, los efectos de red son el principal motivo del éxito de estas plataformas. Las grandes plataformas comerciales tienen un montón de ventajas en este sentido: grandes presupuestos de mercadotecnia, mucho capital de inversores y la ventaja de la titularidad. Cuanto más grande sea la plataforma titular, mayor dificultad entraña la tarea de competir con ella. Compara esto con las plataformas de software libre, que generalmente no tienen el beneficio de grandes sumas de inversiones o grandes presupuestos de mercadotecnia. Asimismo, las empresas son más propensas a jugar sucio para asegurar su posición que los proyectos de software libre. Si tus propios proyectos compiten con opciones comerciales privativas, ya debes estar muy familiarizado con estos desafíos.

Las plataformas libres están en una inherente desventaja, y tu fe, o falta de fe, en ellas tiene mucho peso. A GitHub no le quitará el sueño que tu proyecto decida alojar su código en otro lugar, pero elegir Codeberg, por ejemplo, significa mucho para ellos. En efecto, tu elección les importa de manera desproporcionada a las plataformas libres: elegir GitHub daña a Codeberg mucho más de lo que elegir Codeberg daña a GitHub. ¿Y por qué debería un proyecto elegir tu oferta en vez de las alternativas privativas si no le das la misma cortesía? La solidaridad del software libre y de código abierto es importante para elevar el ecosistema en conjunto.

Continúa leyendo Es importante que el software libre use infraestructuras de software libre