Hoy veremos algunas formas de verificar y depurar algunos errores comunes de ssh con los que podemos toparnos al intentar conectarnos a un servidor, y algunos tips útiles para solucionar problemas. Introducción El servicio de SSH es un servicio de tipo cliente-servidor, por lo que tenemos configuraciones tanto de cliente […]
La entrada Errores comunes de SSH: Guía de supervivencia aparece primero en Junco TIC.
nocart midisco.dsk cartucho.cpr -c 'RUN"disc'Esta es una aplicación de DOS y funciona bien con DosBox, aunque en teoría se podría compilar para GNU/Linux con el código que acompaña a los binarios pero al menos yo no lo he conseguido.
En Firefox Nightly podemos experimentar con nuevas funciones como añadir notas a las pestañas, o añadir widgets de crear listas o un temporizador enla página de nueva pestaña
Firefox Nightly es la versión en desarrollo del navegador Firefox. En esta versión en desarrollo podremos disfrutar antes que en la versión estable de nuevas funcionalidades que se irán mejorando y corrigiendo y que quizás lleguen a la versión final tiempo después, o quizás nunca si se decide que no son necesarias o útiles.
Desde que ofrecieron repositorios propios para poder instalar el paquete rpm, tengo instalado esta versión en mi equipo y de vez en cuando exploro las novedades que van incluyendo. Echemos un vistazo…
Una novedad es la de poder añadir notas a las pestañas que tenemos abiertas. Haciendo clic derecho sobre una pestaña podremos escoger la opción Añadir nota y una ventana en la que introducir un pequeño texto sobre algo que queramos recordar al abrir dicha pestaña.
Eso nos añadirá un pequeño icono de una nota en la pestaña, visible incluso si fijamos la pestaña. Al poner el cursor por encima veremos el contenido de la nota y haciendo clic derecho sobre ella podremos modificar el texto de la nota o eliminarla.
Puede resultar útil para tener un recordatorio de algo que queremos recordar al abrir de nuevo ese enlace.
Otro nuevo experimento de Firefox es la posibilidad de añadir un par de widgets en la página de pestaña nueva. Primero en Ajustes → Firefox Labs tendremos que habilitar la opción: Listas y temporizadores en Página de inicio de Firefox. Con eso, nos creará un par de widgets.
Uno para poder crear listas con diversos elementos y tenerlas siempre a mano. A día de hoy, estas listas no se sincronizan entre dispositivos. Se pueden exportar a texto al portapapeles. Y todo permanece en local en nuestro equipo. De momento admite 10 listas de 100 elementos cada una lo que no es poco.
Permite reordenar los elementos de la lista, marcarlos como realizados, editarlos o borrarlos.
Para mis gusto preferiría que los nuevos elementos que se añaden en la lista se pusieran debajo de los actuales y no por encima. Igual que cuando escribimos una lista en un papel, aunque se pueden reordenar.
Mediante otro Widget, también podremos establecer un temporizador que podremos modificar al tiempo que necesitemos y que nos permitirá establecer periodos de descanso o de concentración o utilizarlos como mejor nos parezca.
Existe otro widget que muestra el tiempo meteorológico, pero de momento sólo está disponible en ciertos países, aunque es algo que personalmente no me interesa en la página de nueva pestaña del navegador.
Además de la vista dividida y la posibilidad de gestionar de manera más pormenorizada el uso de IA en nuestro navegador que habrás podido leer en otras webs, yo he querido reseñar este par de mejoras que pronto llegarán a la versión final de Firefox. Y además de todo esto siguen corrigiendo errores, añadiendo mejoras en el uso del navegador Firefox.
Navegador que sigo utilizando y por el que sigo apostando como alternativa a el omnipresente Chrome de Google en sus diversos disfraces.
Puedes leer la documentación oficial de EasyPodcast en https://www.easypodcast.eu/.
Llevo tiempo dándole vueltas a una cosa: ¿cómo algo tan sencillo como publicar un podcast se ha convertido en una especie de gymkana tecnológica?
La opción fácil es darse de alta en una plataforma, pagar una cuota, aceptar quince pantallas de configuración, conectar servicios que no sabes muy bien para qué sirven… y al final tú solo querías subir un audio y que el RSS funcionase. La otra opción es montarte un WordPress, instalar un plugin enorme, instalar 10.000 dependencias y al final del todo tienes un podcast, pero creo que a veces no es lo que queremos.
Así que un día quería montar un podcast nuevo y no me apetecía ninguna de las dos opciones, y de ahí salió EasyPodcast.
EasyPodcast es un gestor sencillo para publicar podcasts usando PHP y SQLite. Nada de infraestructuras ni de ingeniería aeroespacial, nada de depender de terceros, nada de cosas que no se pueden controlar. Lo mejor: hacérselo uno mismo. Lo subes a tu servidor, lo configuras y te pones a publicar en 5 minutos. Como debería ser. Vamos, que no hace falta pedir audiencia en el Vaticano para sacar un episodio.
Yo quería algo que hiciera estrictamente lo necesario y ni una línea más. Al publicar un episodio, se guarda en SQLite, se actualiza el feed RSS y se muestra en la web pública. Punto.
Uso SQLite porque me parece una maravilla infravalorada. Un archivo y listo. No necesitas montar un servidor de base de datos aparte ni complicarte la vida. Al final son muy pocos datos y realmente no lo necesitas, sobre todo si es un proyecto personal. Pero incluso para algo más serio, SQLite es suficiente.
Si ya tienes un VPS pequeño o tu propio servidor, lo puedes tener funcionando antes de que termine el café.
No pretende competir con plataformas gigantes ni con soluciones empresariales. No es su guerra. EasyPodcast es para quien quiere control, simplicidad y autonomía. Para quien prefiere tener su feed RSS en casa, bajo su dominio, sin que mañana alguien cambie las condiciones y te deje mirando a Cuenca. Que ya nos conocemos.
El panel de administración es limpio y directo. Subes el audio, rellenas los datos del episodio y a correr. No hay tutorial de 40 minutos en YouTube para entenderlo. Si sabes usar un formulario web, sabes usar EasyPodcast. Y si sabes algo de PHP, además puedes abrir el código y entender qué está pasando. Sin magia negra.
Con el tiempo le he ido añadiendo las cosas que de verdad hacen falta. Las descripciones de los episodios se escriben en Markdown con vista previa en tiempo real, porque escribir en un textarea pelado en 2025 no tiene ningún sentido. Al subir un MP3, escribe automáticamente los metadatos ID3, incluida la portada, para que el episodio llegue bien presentado a cualquier app de podcast. Hay sitemap, Open Graph y datos estructurados JSON-LD, porque si publicas algo, que al menos Google se entere. Y hay un sistema de copias de seguridad integrado para exportar e importar la base de datos y los ficheros, que uno no quiere depender solo de que el servidor no se muera. Por si acaso.
A partir de la versión 0.7 también tiene modo oscuro, que ya sé que parece una tontería, pero cuando son las once de la noche y estás preparando el episodio de la semana, lo agradeces.
¿Es perfecto? No. Ni lo pretende. Es pequeño a propósito. Es mantenible a propósito. Es sencillo a propósito. Porque a veces lo mejor no es añadir más cosas, sino quitar las que sobran. Que eso parece que cuesta más.
En el fondo, EasyPodcast nace de una idea muy básica: si el estándar del podcasting es abierto y el RSS es abierto, ¿por qué necesitamos intermediarios para publicar un mp3?
La instalación es de las más sencillas que he podido hacer. Sin SSH, sin consola, sin complicaciones. Solo necesitas un servidor con PHP.
instalar.php. También puedes descargarlo directamente desde este enlace: descargar instalar.php (clic derecho → Guardar como).instalar.php en el directorio raíz donde quieres instalar EasyPodcast. Ese directorio debería estar vacío (o ser el único archivo que haya en él).https://tu-dominio.com/instalar.php y sigue los tres pasos del asistente: comprobación de compatibilidad, verificación del directorio e instalación./admin.php. El propio instalador intenta borrarse solo al terminar; si no puede, bórralo tú manualmente antes de empezar a usar la aplicación.Requisitos mínimos: PHP 8.0+ con las extensiones pdo_sqlite, sqlite3, zip, gd, fileinfo y xmlwriter. La mayoría de hostings compartidos modernos los tienen activados por defecto.
Si eres de los que tiene servidor propio, te gusta trastear y prefieres depender de ti mismo antes que de una plataforma con suscripción mensual, igual te encaja. Puedes ver el código completo en github.com/educollado/EasyPodcast y ver un ejemplo real funcionando en aratospodcast.com.
La verdad es que me haría mucha ilusión si lo probarais, porque nunca se sabe y a lo mejor es lo que estabais buscando.
Hablo con Blanca García-Orea (Blancanutri) y autora del libro 5 semanas para desinflamarte. Temas que tocamos: – ¿Qué es realmente ...
The post Claves para Desinflamarte, con Blanca García-Orea appeared first on Fitness Revolucionario.
Más noticias sobre “La Liga” y su intención de bloquear todo internet cuando hay partido de fútbol:
La entrada La Liga se publicó primero en Linux Hispano.
Bollyscripts,
Fastfetch incluye una serie de configuraciones ya creadas que dan más estilo a la información de tu equipo que muestra en la terminal este software
Por mi cuenta de Mastodon compartí algunas capturas de pantalla de mi terminal en openSUSE mostrando diferentes configuraciones ya creadas e incluidas en Fastfetch como la que puedes ver más arriba.
Estas configuraciones ya están creadas y sólo necesitas utilizar la que más te guste. Vamos a ver dónde se ubican, echarles un vistazo, y utilizar la que más nos guste.
Podemos echar un vistazo a las configuraciones instaladas de manera predeterminada con el siguiente comando:
fastfetch --list-presets
Veremos que hay una lista de archivos .jsonc que son los que contienen las distintas configuraciones para que la información que ofrece fastfetch se vea de una manera u otra.
Esas configuraciones suelen estar en la ruta /usr/share/fastfetch/presets/ y otras en la misma ruta, pero dentro de la carpeta examples.
Podemos ejecutar fastfetch con la configuración que queramos mediante la opción -c y especificando el archivo que queremos que utilice:
fastfetch -c all.jsonc
Y así ir recorriendo todas las opciones. Pero ¿Por qué no hacerlo mediante un script? Con este script, irá ejecutando fastfetch con todas las opciones encontradas:
#!/usr/bin/env bash
# Obtener las rutas donde pueden haber archivos de configuración
data_paths=$(fastfetch --list-data-paths)
# Recorrer cada ruta
for path in $data_paths; do
# Verificar que la ruta exista
if [ -d "$path" ]; then
# Buscar archivos con extensión .jsonc en la ruta
jsonc_files=$(find "$path" -type f -name "*.jsonc")
# Recorrer cada archivo .jsonc encontrado
for jsonc_file in $jsonc_files; do
clear
echo "=============================="
echo "Archivo de configuración: $jsonc_file"
echo "=============================="
echo
# Ejecutar fastfetch con el archivo de configuración
fastfetch -c "$jsonc_file"
echo
echo "Pulsa cualquier tecla para continuar..."
read -n 1 -s
done
else
echo "La ruta $path no existe o no es un directorio válido."
fi
done
Ya sabes lo guardas en un archivo (por ejemplo ff_demo.sh), le das permisos de ejecución (chmod +x ff_demo.sh) y lo ejecutas (./ff_demo.sh).
Haremos un recorrido por todos los temas instalados en nuestro equipo. Si alguno nos gusta y queremos reemplazar el actual predeterminado que utiliza fastfetch, simplemente copiaremos el archivo deseado a la nueva ubicación como en el siguiente ejemplo:
cp /usr/share/fastfetch/presets/16.jsonc ~/.config/fastfetch/default.jsonc
Si no existe la carpeta fastfetch dentro de .config en tu home tendrás que crearla.
Ahora al ejecutar de nuevo fastfetch utilizará la nueva configuración, que podrás modificar añadiendo o quitando cosas para dejarlo como a ti te guste.
Si decides volver a la configuración original predeterminada, simplemente borra el archivo que has copido en .config y ya estaría.
¡Ah! Otra cosa, supongo que para que algunas configuraciones se muestren correctamente deberás utilizar en la terminal una fuente Nerd Font para que se muestren algunos iconos.
Recopilatorio habitual de noticias y novedades recientes en nuestra comunidad KDE.
Cartagena está preciosa en Marzo, ¡apuntarse al Crespillos y Podcast!
Artículo original con los enlaces en https://kdeexpress.gitlab.io/69/
Puedes escuchar este episodio y seguir el podcast en tu propia aplicación facilmente con este enlace a Podlink o este a Podnews.
Transcripción a texto y subtítulos más abajo 👇, en la web steno.fm o en estas apps.
Este podcast tiene licencia Reconocimiento-CompartirIgual 4.0 Internacional (CC BY-SA 4.0).
Lo primero: no quiero arrancar este episodio sin dar las gracias como se merece a IPng Networks y, en especial, a Pim Van Pelt. Tuve la suerte de compartir un café con él en el ESNOG de Barcelona hace un par de años, y te das cuenta en cinco minutos de que no solo sabe una barbaridad, sino que además tiene la capacidad de explicar cosas muy complejas de forma clara y honesta. Su trabajo y su manera de compartir conocimiento han ayudado a muchos a entender qué demonios está pasando realmente dentro del plano de datos moderno. Este episodio, en buena parte, nace de esa base de conocimiento que otros han currado antes.
Y ahora sí, como dice Felipe, vamos al lío.
Este episodio es la primera parte de un análisis bastante serio —pero contado como lo contaría alguien que lleva más de veinte años en telecomunicaciones— sobre algo que casi todos hemos sufrido alguna vez: tienes un servidor Linux con buena CPU, buena RAM, tarjetas modernas… y de repente empieza a perder paquetes. O aparece jitter. O la latencia hace cosas raras. Y miras la CPU global y está al 20 %. Y piensas: “¿Pero qué está pasando aquí?”
La clave no está en la potencia bruta. Está en el modelo de procesamiento.
El stack de red del kernel Linux está pensado para ser generalista. Tiene que servir para servidores web, bases de datos, firewalls, virtualización, mil aplicaciones a la vez. Cada paquete que entra genera interrupciones, estructuras dinámicas, validaciones, decisiones del scheduler… Todo eso funciona muy bien cuando la carga es razonable.
Pero cuando empiezas a hablar en serio de paquetes por segundo, la historia cambia. No tanto por los gigabits, sino por los pps. Empiezan las invalidaciones de caché, la carga se concentra en una o dos colas, aparecen microbursts que no se absorben bien y el sistema empieza a comportarse de forma poco predecible. No es que Linux “no pueda”. Es que no está optimizado exclusivamente para forwarding masivo.
Aquí es donde entra el enfoque vectorial.
En vez de tratar cada paquete como si fuera un evento único que requiere atención inmediata, el modelo vectorial los agrupa en lotes y los procesa en bloque. Se reducen transiciones, se mantiene la caché caliente y la CPU hace lo que mejor sabe hacer: ejecutar el mismo código repetidamente sobre datos similares.
En lugar de vivir a base de interrupciones, los cores dedicados al plano de datos hacen polling continuo. Sí, están preguntando todo el rato si hay trabajo. A primera vista parece poco eficiente, pero cuando te mueves en millones de paquetes por segundo, el coste del polling es mucho menor que el de gestionar millones de interrupciones.
Sobre esta idea se construye VPP, el Vector Packet Processor. Es un plano de datos en espacio de usuario que, apoyándose en DPDK, toma control directo de las interfaces de red. Organiza el procesamiento como un grafo de nodos: uno clasifica capa 2, otro analiza IP, otro hace el lookup en la FIB, otro reescribe cabeceras, otro aplica ACLs… y todo eso lo hace sobre vectores de buffers ya reservados en hugepages. No hay malloc por paquete. No hay estructuras que se creen y destruyan constantemente.
Y aquí ya nos metemos en terreno físico de verdad: cachés L1, L2, L3, predicción de saltos, TLB, hugepages… Esto no va solo de “configurar BGP”. Va de entender cómo funciona la CPU por dentro. Si ejecutas el mismo código sobre datos contiguos, la caché trabaja a tu favor. Si accedes a memoria del otro socket NUMA, el coste sube. Si no alineas bien colas RSS con workers, puedes saturar un core mientras el de al lado está mirando.
Todo cuenta: CPU, memoria, NIC y cómo lo configuras.
Otro punto importante es que esto no elimina el kernel. Lo separa. El forwarding masivo lo hace el motor vectorial en el plano de datos, pero el plano de control sigue en Linux. Bird o FRR gestionan BGP, OSPF, lo que toque. La sincronización entre ambos mundos se hace por Netlink: el kernel mantiene el RIB y VPP ejecuta la FIB real.
Eso funciona muy bien… siempre que lo entiendas. En una reconvergencia gorda, con miles de rutas BGP entrando o saliendo, puedes generar una tormenta de mensajes Netlink. Si no dimensionas bien los buffers o no separas cores correctamente, puedes tener problemas de sincronización. No es magia. Es ingeniería.
También se habla de cosas muy de campo: caída de enlaces físicos, BFD reaccionando en milisegundos, microbursts, tráfico de paquetes mínimos que te revientan el pps aunque el Gbps no sea alto, y RSS repartiendo mal la carga.
Aquí aparece una métrica que me parece brutal: el “vector size”. Si ves que el promedio se acerca a 256 buffers por llamada, sabes que ese worker está cerca del límite. Mucho más útil que mirar la CPU global y quedarte tranquilo. Es una manera mucho más honesta de saber dónde estás.
A partir de ahí, el dimensionamiento cambia completamente. Dejas de hablar de “este servidor es más potente” y empiezas a hablar de ciclos por paquete. Si el forwarding básico consume X ciclos y añadir NAT o VXLAN suma Y más, puedes estimar cuántos millones de paquetes por segundo puede manejar cada core. Eso ya no es intuición, es matemática.
También se compara de forma honesta con ASIC. Los ASIC siguen siendo impresionantes. Para ciertas escalas y latencias mínimas, son imbatibles. No desaparecen ni mucho menos. Pero el espacio intermedio ha cambiado mucho. Hoy un servidor bien diseñado puede hacer cosas que hace diez o quince años solo estaban al alcance de hardware muy especializado.
La diferencia es que aquí tienes flexibilidad software. Puedes evolucionar, automatizar, versionar configuración, integrar métricas con Prometheus, tratar el router como infraestructura como código.
Y eso cambia la mentalidad.
El plano de datos deja de ser una caja negra. Empiezas a medir ciclos por nodo, vectores procesados, presión de buffers. Dejas de sobredimensionar “por si acaso” y empiezas a dimensionar con números reales.
No es una solución mágica ni sirve para todo el mundo. Requiere entender CPU, hugepages, NUMA, afinidad de cores y cómo se comporta el sistema bajo carga real. Pero si te dedicas a esto desde hace años y te gusta entender lo que pasa de verdad debajo del capó, es difícil no interesarse.
En el fondo, este episodio no va solo de reenviar más tráfico. Va de entender cómo se mueven los paquetes dentro de una máquina moderna, por qué a veces todo parece ir bien hasta que deja de irlo, y cómo rediseñar el plano de datos para que, cuando aprietes de verdad, el sistema responda de forma estable y predecible.
Artículos de VPP en IPngNetworks: https://ipng.ch/s/articles/
Foto de Alex wolf mx: https://www.pexels.com/es-es/foto/carretera-coche-deportivo-deportes-de-motor-carrera-14401648/
mjpg-streamer toma archivos JPG de cámaras web, sistemas de archivos u otros complementos de entrada compatibles con Linux-UVC y los transmite como M-JPEG a través de HTTP a navegadores web, VLC y otro software.
Mediante este software libre publicado bajo una licencia GNU GPL, que realmente es muy ligero de uso que podemos ejecutarlo en un equipo de bajos recursos como una Raspberry por ejemplo, podremos transmitir via streming vídeos que captamos con nuestros dispositivos de vídeo.
En mi caso he instalado el software en mi portátil viejo con openSUSE Tumbleweed y utilizo su webcam integrada para emitir en streaming el vídeo. Pudiéndolo ver incluso fuera de mi red local, veamos cómo.
El software lo conocí gracias a un artículo publicado en el blog Un bruto con Debian:
Así que quise probarlo yo mismo en mi openSUSE.
En ese artículo anterior, se muestra cómo compilar el software para tenerlo funcionando. En mi caso, una rápida búsqueda en los repositorios de openSUSE me dió como resultado que ya estaba disponible para utilizarlo. Así que medianta un simple comando como sudo zypper in mjpg-streamer ya lo tenía instalado en mi equipo.
Es hora de probarlo. Así que abrí la tapa de la webcam de mi equipo y ejecuté este comando
mjpg_streamer -i "input_uvc.so -d /dev/video0" -o "output_http.so -p 1234"Mediante el argumento de -i le estoy diciendo qué dispositivo de entrada utilizar para emitir el streaming. En mi caso es /dev/vidoe0 pero ¿será igual en tu caso?
Para saberlo puedes ejecutar esto:
for device in /dev/video; do udevadm info "$device" | { grep -q 'CAPABILITIES=.:capture:' && echo "$device" ;}; doney te dará el dispositivo que podrás utilizar como entrada.
Mediante el argumento -o le decimos que queremos que emita en http levantando un servidor al que conectarnos desde otro equipo de nuestra red. Y un puerto diferente que utilizar, en mi caso he optado por el 1234, pero puedes utilizar el que quieras.
Con esto, si todo va bien ya estará emitiendo el streaming. A mí me da algunos errores del tipo: «UVCIOC_CTRL_ADD – Error at Pan (relative): Inappropriate ioctl for device (25)» pero son más bien informativos de que algunas funcionalidades no están soportadas por el dispositivo, pero se pueden ignorar.
Ahora comprobaremos si todo está funcionando bien. Lo primero sera testearlo desde el propio equipo. Para ello abrimos un navegador y metemos esta dirección: localhost:1234/?action=stream y deberíamos ver lo que captura la webcam del portátil.
Muy bien. Ahora vamos a otro equipo de nuestra red local y vamos a ver si también podemos acceder al streaming. Ahora necesitamos poner la IP del equipo que está ejecutando el software en vez de localhost: 192.168.1.42:1234/?action=stream
¿Vemos algo? si la respuesta es sí, genial!! Si no nos conecta a esa IP pero sí lo veíamos cuando ejecutábamos localhost, entonces quizás es problema del cortafuegos. Necesitamos abrir ese puerto para poder acceder. En openSUSE ejecuté:
sudo firewall-cmd --zone=public --add-port=1234/tcp --permanent
sudo firewall-cmd --reloadY confirmar mediante:
sudo firewall-cmd --list-portsDonde debería aparecer algo como: tcp/1234 confirmando que el puerto está abierto. Volvemos a navegar por la url anterior: 192.168.1.42:1234/?action=stream y debería ya aparecer nuestra emisión en streaming.
Al igual que en el artículo del bruto con Debian, también tuve que aumentar el número de frames capturado para ver una secuencia más real y fluida. Así que en mi caso también lo subí a 60 frames que especificamos mediante la opción -f
La respuesta es sí, pero utilizando un servicio de dns dinámica y tocando en nuestro router para redirigir el tráfico que hagamos a ese puerto a la IP de nuestro equipo local (que deberá ser siempre la misma).
Para esto yo he utilizado el servicio https://freemyip.com/
Así mi desde fuera de la red puedo acceder mediante la url:
http://midominio.freemyip.com:1234/?action=streamSi no quieres que cualquiera pueda conectarse, igual es buena idea correr mjpg-streamer con contraseña mediante la opción -c
Yo a mayores lo que hago es incrustar el streming en un documento html y le digo a mjpg-streamer que para el servidor abra ese archivo. Así en una carpeta miusuario/www/ tengo uno archivo index.html con su archivo de estilo css y todo. Y dentro del index.html incrusto el streaming mediante un bloque iframe
http://midominio.freemyip.com:1234/?action=streamY al final el comando completo de mjpg-streamer en mi caso quedaría así:
mjpg_streamer -i "input_uvc.so -d /dev/video0 -f 60" -o "output_http.so -p 1234 -w /home/victorhck/www/"Y desde el navegador iría a la dirección:
http://midominio.freemyip.com:1234/Así si apuntas con la webcam al rincón preferido de tus gaticos les podrás ver cómo duermen durante todo el día esperando a que llegues tu para empezar a correr por toda la casa…
Myrlyn vino a sustituir a YaST a la hora de tener una interfaz gráfica para la gestión de paquetes de software (borrado, búsqueda, instalación) y de repositorios
A finales de 2024, YQPkg vino a sustituir a YaST como interfaz gráfica desde la que gestionar el software en openSUSE. Y más tarde se convirtión en Myrlyn.
La nueva herramienta ofrecía una interfaz basada en Qt6 e independiente de YaST que se basa en Libzypp la biblioteca que utiliza Zypper, el gestor de archivos para la terminal. Y el pasado 19 de enero Myrlyn ya ha alcanzado la versión 1.0.0.
Poco a poco Myrlyn va ganando en funcionalidades y en mejoras a la hora de realizar las tareas de búsqueda de nuevos paquetes, de instalación o eliminación de software mediante su interfaz.
Siguiendo las notas de publicación del proyecto:
Mozilla ha creado unos repositorios en los que ofrece la versión Nightly del navegador Firefox para poder instalar directamente el paquete .rpm
Mozilla ha creado un repositorio donde ofrece en paquete .rpm la versión Nightly de su navegadore Firefox. Veamos cómo podemos añadir ese repositorio en openSUSE e instalar esa versión del navegador.
También está disponible para otras distribuciones de GNU/Linux que usen el empaquetado .rpm como Fedora, CentOS, Red Hat, etc.
En un artículo anterior del blog expliqué qué son las diferentes versiones de Firefox. La versión Nightly es una versión del navegador Firefox que contiene mejoras y nuevas funcionalidades antes de que se incluyan en la versión final.
Estas funcionalidades de Nightly se van actualizando de manera constante y son probadas antes de incorporarse en la versión final. Si te gusta echar un vistazo antes que nadie a lo que está por llegar, esta versión es la tuya, pero eso conlleva un riesgo. Quizás algunos complementos no funcionen o esas mejoras no sean del todo estables.
En todo caso, esta versión Nightly puede convivir juntamente con tu navegador Firefox en su versión estable, así que puedes tenerla en tu equipo ambas y usar la versión Nightly cuando te apetezca echar un vistazo a las novedades.
Esta versión Nightly también ofrece varias mejoras:
Si te animas a instalar este repositorio en openSUSE del que podrás instalar esta versión de Firefox, que recuerdo que puede convivir con tu Firefox normal, sigue los siguientes pasos.
Desde una terminal mediante zypper vamos a añadir el repositorio de Mozilla:
sudo zypper ar -G https://packages.mozilla.org/rpm/firefox mozillaRefrescamos los repositorios para que se actualicen las bases de datos locales:
sudo zypper refreshE instalamos el paquete:
sudo zypper install firefox-nightlySi no se instala el idioma en español, si quieres instalar el español de España tendrás que instalar además este paquete:
sudo zypper in firefox-nightly-l10n-es-ES