Onion Information

Page Clicks: 0

First Seen: 03/11/2024

Last Indexed: 10/21/2024

Domain Index Total: 275

Saltar al contenido 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 El lenguaje HTML se adhiere al estándar WHATWG . Como es un lenguaje de marcado , un error en HTML no hace que la página web deje de funcionar, sino que el navegador la muestra lo mejor que puede. Tener errores en HTML es problemático, ya que puede producir fallos inesperados y difíciles de reproducir, sobre todo cuando solo ocurren en un navegador. Así pues, es vital escribir un HTML válido. Sin embargo, es muy fácil cometer errores y pasarlos por alto. Por eso es recomendable validar el código HTML; es decir, encontrar los fallos y corregirlos. Para eso existen los validadores, que, por lo general, simplemente muestran los errores. El más actualizado y recomendable es The Nu Html Checker . La W3C mantiene una instancia de ese validador que nos permite validar documentos HTML desde el navegador, ya sea introduciendo una URL , subiendo un archivo o introduciendo el código HTML en un formulario . Como este validador es libre, puedes instalarlo en tu ordenador fácilmente. El validador en línea funciona bien si solo tienes que validar unas pocas páginas web de vez en cuando, pero no sirve para validar un sitio web entero. Para ello recomiendo usar la versión de The Nu Html Checker que se ejecuta en terminal. Esta se encuentra en el archivo vnu.jar (hace falta tener Java instalado). En mi caso, yo utilizo el paquete html5validator , ya que trabajo principalmente con Python y no supone una dependencia adicional. Para instalar este paquete en una distribución de GNU/Linux basada en Debian solo hay que ejecutar... sudo apt install default-jre sudo pip3 install html5validator Al terminar la instalación tenemos un programa llamado html5validator que podemos ejecutar desde la terminal: html5validator index.html Un argumento súper útil es --root , que permite validar todos los archivos de un directorio, y del directorio dentro del directorio..., así hasta que haya validado todo. Yo lo uso especificando el directorio raíz de mi sitio web, validando así el sitio web completo en unos segundos. html5validator --root sitio-web/ Lo ideal es usar algún tipo de integración continua para no tener que ejecutar manualmente la anterior instrucción cada vez que cambias algo en la página web. Para ello yo uso GitLab CI . De este modo, mantengo este sitio web y muchos otros sin errores de HTML, y cuando rompo algo, me entero pronto. Ahora GitLab permite usar un CAPTCHA libre invisible llamado Invisible Captcha en lugar de reCAPTCHA. Esta funcionalidad ha sido integrada recientemente . Esto supone una mejora respecto a la situación anterior , ya que muchas instancias de GitLab podrán empezar a usar Invisible Captcha y deshabilitar reCAPTCHA. Al ser un CAPTCHA invisible, Invisible Captcha proporciona además una mejor experiencia de uso. GitLab contiene software privativo de Google y no parece que vayan a eliminarlo. En concreto, usa el programa reCAPTCHA de Google, documentando incluso su configuración . Esto es problemático no solo por la cuestión de la libertad de software , sino también por otros efectos secundarios de reCAPTCHA (como la explotación laboral y el reconocimiento facial para fines bélicos ). El código se carga directamente desde los servidores de Google, lo cual podría impedir la apertura de incidencias y el registro de nuevas cuentas cuando el servidor de Google estuviera caído. Hay desde hace tiempo varias incidencias abiertas en el gestor de incidencias de GitLab.