No sé si el interés por los gestores de ventanas está aumentando o me lo parece a mí. Existen desde hace mucho, pero se pueden contar con los dedos de las manos los que se usan extensamente. No nombraré más que a i3, Sway o Hyprland para evitar críticas de los fans de algunos WM, pero la llegada del último y del nuevo miracle-wm hacen que alguien como yo sienta que crezca este mercado.

miracle-wm, escrito así por lo menos de momento, es un compositor de Wayland basado en Mir, y su llegada se ha hecho pública en el Discourse de Ubuntu. Hace a penas unas horas se ha lanzado el la primera versión de su historia, aunque los que quieran probarlo deben bajar un poco su entusiasmo por diferentes razones. La primera es la que me parece más evidente, y es que está disponible como paquete snap y sólo de esta manera, a no ser que uno coja el código fuente de GitHub y lo instale por su cuenta.

miracle-wm: un compositor de Wayland basado en Mir

«Me complace anunciar la primera versión de miracle-wm, un compositor de Wayland basado en Mir. miracle-wm presenta un gestor de ventanas en mosaico, muy similar al que se encuentra en i3, sway e Hyprland. El objetivo del proyecto es satisfacer las necesidades de estos compositores y, al mismo tiempo, ofrecer gráficos más vistosos a los que preferimos un escritorio lleno de transiciones y colores suaves. Aunque el proyecto aún está en pañales, me encantaría recibir tus comentarios e informes de errores si tienes la oportunidad de usarlo, ya que yo he sido el único usuario hasta ahora. Dicho esto, ten en cuenta que todas las versiones anteriores a la v1.0.0 se consideran «versiones preliminares». Esto significa que puedes encontrarte con algún que otro problema por el camino. Si encuentras un error, te agradecería que registraras un problema en Github o incluso que contribuyeras tú mismo a solucionarlo. Cualquiera de las dos cosas sería muy apreciada«, dice Mathew Kosarek

Para poder usarlo es necesario hacerlo con el hardware del equipo, es decir, no se lleva muy bien con las máquinas virtuales. No es sorpresa, ya que por ejemplo GNOME Boxes no funciona muy bien en sesiones de Wayland. La mejor manera de probar miracle-wm va a pasar por hacerlo en el sistema operativo habitual o instalarlo en una unidad externa, bien sea un disco secundario o un pendrive.

Si tenemos lo necesario para instalar miracle-wm, podemos hacerlo con este comando:

sudo snap install miracle-wm --classic

.barra {display: flex;justify-content: flex-end;height: 25px; background-color: #333;border-radius: 5px 5px 0 0;}.rojo, .naranja, .verde{width: 12px;height: 12px; position: relative;border-radius: 50%;top: 7px; margin: 0 3px;}.rojo{background-color: rgb(248, 82, 82); margin-right: 7px;}.naranja{background-color: rgb(252, 186, 63);}.verde{background-color: rgb(17, 187, 17);}.terminal{background-color: black !important; border-radius: 5px !important;}pre{font-family:monospace !important; padding: 0 10px 10px; line-height: 1.5em; overflow: auto; background-color: black !important; color: #0EE80E !important}

Tras la instalación, que dura unos segundos, hay que cerrar sesión y elegir Miracle en la pantalla de login. La eliminación se consigue sustituyendo «install» por «remove» en el comando anterior y sin añadir la parte de «–classic».

Características

Entre lo que es capaz de hacer este gestor de ventanas recién nacido encontramos mucho de lo que ofrecen la mayoría:

• Gestión de apilado de ventanas, como abrirlas, cerrarlas o cambiarles el tamaño.
• Soporte para zonas para paneles, como los que solemos ver en las partes superior e inferior del «escritorio».
• Soporte para ventanas a pantalla completa.
• Permite usar multi-salida.
• Soporte para espacios de trabajo.
• Separación entre ventanas, a lo que los gestores de ventanas se refieren como «gap».
• Archivo de configuración, similar al que vemos en i3.

La idea que ha llevado a Kosarek a crear miracle-wm ha sido diseñar un compositor de Wayland que ofrezca más funciones que otros gestores de ventanas como los mencionados aquí. Al mismo tiempo, debe servir para los que prefieren un escritorio o mejores transiciones y colores. A mí todo esto me recuerda un poco a lo que vi en Hyprland cuando lo probé, pero no he tenido ocasión de probar este nuevo gestor como es debido.

En un principio está como paquete snap, ya que parece salido directamente de la fábrica de Canonical, pero su desarrollador no cierra la puerta a que se usen otros tipos de paquetes y aceptará subir esas versiones si alguien se las entrega. Mirando al futuro, ¿lo veremos como opción nativa en Ubuntu?

from Linux Adictos https://ift.tt/ovrpaUf
via IFTTT

Es probable que haya personas, sobre todo los que actualmente son adolescentes, que desconozcan cómo manteníamos conversaciones fluidas por mensajes antes de WhatsApp o Facebook Messenger. Pues antes solíamos usar chats, y aquello no era una aplicación que nos permitía hablar con nuestros contactos. Para eso también existía algo, el MSN Messenger de Microsoft que murió para dar paso a Skype. Pero los chats de verdad eran los del IRC (Internet Relay Chat), y a ellos podíamos entrar directamente con un navegador web o con un cliente IRC como HexChat.

Ahora mismo, esos esa manera de comunicarse parece ser cosa del pasado. Eso de ir a una web o configurar un servidor en un cliente IRC ya no es lo que se lleva. Se sigue «chateando», pero para ello usamos los mencionados WhatsApp y Facebook Messenger, Instagram, Telegram u otras plataformas algo menos conocidas como Discord o Matrix. Esa falta de interés por parte de los usuarios puede haber tenido algo que ver en que HexChat haya lanzado su versión final. O dicho de otro modo, ya no habrá más actualizaciones.

HexChat 2.16.2 será la última versión del ciente de IRC

El motivo que dan los desarrolladores para abandonar el proyecto es que ha estado sin mantener durante mucho tiempo, y nadie da un paso al frente para hacerse cargo de él. La última versión será la v2.16.2, e incluye una lista de novedades en la que predominan las correcciones.

HexChat 2.16.2 llegó hace ya más de dos semanas. En ese tiempo, su desarrollador principal ha subido los datos a GitHub, y cualquiera puede crear un fork del cliente de IRC y avanzar si le parece apropiado.

HexChat nació en 2010 como derivado de XChat y se ha usado bastante en los últimos 14 años. De hecho, está instalado por defecto en algunas distribuciones Linux. Ahora que HexChat ha decidido dar fin a su aventura en la menasjería instantánea, los usuarios de Linux tenemos que buscar alternativas, y una de ellas es Pidgin.

from Linux Adictos https://ift.tt/0nW7a6b
via IFTTT

Linus Benedict Torvalds es un ingeniero de software, conocido por iniciar y mantener el desarrollo del kernel Linux

Hace unas pocas semanas compartimos aquí en el blog la noticia sobre una propuesta que se ha reavivado después de muchos años en relación a la viabilidad de adoptar el código C++ en el kernel de Linux, una propuesta que fue lanzada en el 2018 a modo de broma.

La propuesta fue nuevamente lanzada en las listas de correo del Kernel, pero ya de manera seria por Hans Peter Anvin, un desarrollador clave del kernel de Intel y el desarrollador planteaba la viabilidad de la inclusión de C++ como un tercer lenguaje de programación en Linux.

Con la introduccion de Rust en Linux, muchos desarrolladores y parte de la comunidad vieron un gran camino por delante en Linux, además de que también han surgido diversas «ideas» de implementar otros lenguajes de programación, la propuesta de implementar C++  abre nuevamente un debate entre muchos de los desarrolladores del Kernel e incluso que Linus Torvalds nuevamente explique de la manera más pasiva y comprensiblemente posible, el porqué Linux no está preparado para C++ (sarcasmo).

Hay que recordar que Rust no fue aceptado en Linux de un momento a otro, pues el proyecto de Rust en Linux (Rust for Linux) tuvo una serie de revisiones por parte del mismo Linus Torvalds antes de que fuera aceptado en la rama principal del Kernel para que fuera incluido y cabe mencionar que el padre de Linux no fue nada blando al momento de realizar las revisiones y comentar sobre los cambios propuestos.

Ahora en el caso de la propuesta de C++ como tercer lenguaje de programación, en el supuesto caso, y digo “supuesto”, la implementación debería de pasar por una serie de revisiones similar, si no hasta más rigurosa de lo que fue para Rust. Y es que el hecho de mencionar esto es debido a que C++ y Linus tienen su historia, pequeña, pero que tiene ya muchos años.

La razón de mencionar que el caso de C++ como un tercer lenguaje de Linux como un “supuesto”, es debido a que el padre de Linux, Linus Torvalds, no ha visto ni verá con buenos ojos a C++, ya que en más de una ocasión en cada oportunidad que tiene ha mencionado que C++ «es un lenguaje terrible».

Por mencionar algunos de los momentos en los que se ha planteado el uso de C++ en Linux y Linus Torvalds ha expresado no solo su desacuerdo, sino un «cierto odio» hacia C++ el cual sobrepone para mencionar el porqué «simplemente no es una opción para Linux», uno de los más recientes fue durante las revisiones de la implementación de Rust, ya que durante una discusión en una la publicación de Google, se mencionó la inclusión de C++ en forma de sugerencia:

«La solución aquí es simple: simplemente use C++ en lugar de Rust»

A lo cual Linus Torvalds no pudo evitar reírse y su respuesta fue:

«LOL». «C++ no resuelve ninguno de los problemas de C y sólo empeora las cosas, realmente es un lenguaje basura.

Para las personas a las que no les gusta C, opten por un lenguaje que realmente les ofrezca algo que valga la pena. Como lenguajes con seguridad de memoria y «que» pueden evitar algunos de los peligros de C, o lenguajes que tienen soporte interno de GC «recolección de basura» y facilitan la administración de la memoria. C++ resuelve todos los problemas equivocados, y cualquiera que diga ‘reescribir el núcleo en C++’ es demasiado ignorante para siquiera saberlo.»

Linus Torvalds siempre ha considerado C ++ como un “desperdicio” y lo ha considerado “inútil” pues para el “C++ no puede resolver el problema del lenguaje C en absoluto, solo empeorará las cosas». Torvalds cree a quienes no les gusta el lenguaje C pueden buscar un lenguaje que realmente pueda aportar valor. Por ejemplo, lenguajes que tienen seguridad de memoria y pueden evitar peligros ocultos causados ​​por C (como por ejemplo Rust).

En comparación con C ++, Linus ha mencionado el porqué C, es su elección estándar:

“Cuando la gente habla de los peligros causados ​​por C, también habla de una parte de la razón por la que C es tan poderoso: ‘Te permite implementar eficientemente todas estas cosas de bajo nivel’”, mencionó Linus. Además, aunque GC es bueno para simplificar la programación en la mayoría de los casos, generalmente no es algo que se pueda hacer en la programación de sistemas de bajo nivel.

De hecho, en las listas de correo se menciona que en algún momento se intentó usar C++ en Linux, en 1992 (más o menos un año después del nacimiento de Linux), pero esto se quedó solo asi como «un intento», ya que Torvalds menciona sobre este intento:

Es terrible. Créeme: escribir código de kernel en C++ es una IDEA ESTÚPIDA DE MIERDA.

El hecho es que los compiladores de C++ no son confiables. Eran aún peores en 1992, pero algunos hechos fundamentales no han cambiado:

– todo el asunto del manejo de excepciones en C++ está fundamentalmente roto. Está «especialmente» roto para los kernels.
– cualquier compilador o lenguaje que le guste ocultar cosas como asignaciones de memoria a sus espaldas simplemente no es una buena elección para un kernel.
– puedes escribir código orientado a objetos (útil para sistemas de archivos, etc.) en C, «sin  la basura que es C++.»

Ante estos y otros tantos comentarios, podemos entender un poco sobre el porqué para Linus Torvalds C++ es un lenguaje horrible, además de que ha criticado al lenguaje por ser utilizado por «programadores de baja calidad, hasta el punto en que es mucho, mucho más fácil generar basura total y absoluta con él.» Y es que pareciera que C++ fue en algún momento, un amargo sabor de boca para Torvalds, ya que en sus críticas da a pensar que intento probar con C++, pues menciono en un correo que:

«C++ conduce a elecciones de diseño realmente malas. Invariablemente comienzas a usar las características «agradables» de la biblioteca del lenguaje como STL y Boost y otra basura total y absoluta, que pueden «ayudarte» a programar, pero causan:

cantidades infinitas de dolor cuando no funcionan (y cualquiera que me diga que STL y especialmente Boost son estables y portables está tan lleno de tonterías que ni siquiera es divertido)
modelos de programación abstractos ineficientes donde dos años más tarde notas que alguna abstracción no fue muy eficiente, pero ahora todo tu código depende de todos los bonitos modelos de objetos a su alrededor, y no puedes arreglarlo sin reescribir tu aplicación.»

Entonces, retomando el titulo de la publicación y ya habiendo entendido un poco la punta del iceberg del odio que tiene Linus Torvalds hacia C++, no hace falta indagar mucho puesto que para Torvalds, Linux no necesita ningún otro lenguaje porque C le basta y durante todo este tiempo C es, ha sido y será el lenguaje que se adapta a su trabajo y Linus seguirá atacando a los lenguajes de programación que no le gustan, en especial a C++.

Y es que una de entre las tantas razones por la que C++ simplemente no es considerado para Linux, es que admite excepciones, mientras que Rust no al igual que C, ya que en la programación del kernel, no se puede permitir que una excepción no detectada pueda desactivar el sistema operativo, además de que ni siquiera se debe pensar que el kernel falle alguna vez.

Y en el dado «supuesto» que Torvalds llegara a considerar a C++ en Linux, esto podría suponer más que un beneficio la inclusión de un tercer o más lenguajes de programación, se convertirían en un problema, ya que por ejemplo con la implementación de Rust actualmente ya están empezando a salir a la luz algunos problemas, tales como los que ya mencionamos en una publicación sobre el estado actual de Rust en Linux.

Dentro de los desafíos actuales mencionamos en el artículo que uno de ellos es el «reclutar más revisores para el código que se está desarrollando» además de que el progreso del compilador Rust basado en GCC se ha ralentizado, también hay muy pocas posibilidades de que reescriban grandes porciones del kernel en Rust corto plazo e incluso muy bajas posibilidades de que puedan hacerlo sin introducir todo tipo de errores y sobre todo los problemas de compatibilidad.

Si estos problemas, que se están viendo reflejados en Rust los sumamos en C++ o cualquier otro lenguaje que se llegue a sumar en Linux, el desarrollo del Kernel se vería afectado en gran medida y con ello de inicio no estaríamos recibiendo una versión cada dos meses, sino que sería el desarrollo entre versiones de más tiempo, se requerirían de más desarrolladores, más revisores y todo esto se traduce en un mayor esfuerzo.

Sin dudas el planteamiento de la introduccion de C++ como un tercer lenguaje de programación, está lejos de ser considerado y como ya mencionamos, uno de los impedimentos principales para ello es el mismísimo Linus Torvalds.

from Linux Adictos https://ift.tt/p2kbyaP
via IFTTT