All posts by morfil

Recogen nuestros compañeros de MCPRO una historia a la que merece la pena prestar atención: ¿Por qué algunas empresas Open Source están considerando un enfoque más cerrado? La pregunta tiene miga, pero más miga tiene el denominador común que la origina: la nube nada menos, a la postre segmento tecnológico en el que el código abierto ha alcanzado sus cotas máximas de éxito.

Se dice que el código abierto, el Open Source, ha cambiado el mundo. Y es cierto: Linux es la mejor muestra de ello. De unos años a esta parte, además, se ha establecido en la empresa como el modelo de desarrollo más eficaz, impulsando la innovación y lucrativos modelos de negocio -con Red Hat como referencia indiscutible- que son más justos para el cliente, debido a que el código abierto aporta una mayor transparencia y facilita la independencia del proveedor.

Sin embargo, el código abierto parece no funcionar para todas las partes por igual, y la razón sería su propia naturaleza y la libertad de uso que otorga a terceros. Abby Kearns, directora ejecutiva de la Cloud Foundry Foundation lo expone tal cual: “El papel que juega el código abierto en la creación de oportunidades comerciales ha cambiado. Lo diría de una manera muy contundente: durante muchos años fuimos unos tontos y les permitimos que tomaran lo que habíamos desarrollado y ganasen toneladas de dinero con ello“.

Ofer Bengal, CEO de la desarrolladora de bases de datos Redis Labs, apunta al problema: “AWS ha ganado cientos de millones de dólares ofreciendo Redis a sus clientes sin contribuir tanto a la comunidad de código abierto que construye y mantiene ese proyecto. Es imposible saber exactamente de cuánto dinero estamos hablando, pero es cierto que AWS y otros proveedores de la nube se benefician del trabajo de los desarrolladores de código abierto que no emplean“.

Pero la queja no se reduce a los beneficios económicos. “Hay un mito ampliamente instalado en el mundo de código abierto que dice que los proyectos son impulsados por una comunidad de contribuyentes, pero en realidad, los desarrolladores pagados contribuyen con la mayor parte del código en la mayoría de los proyectos de código abierto modernos“, señala el fundador de Puppet Luke Kanies, herramienta para la administración de sistemas.

No dicen nada que no se sepa, cabe aclarar, y es que una vez se traspasa la difusa línea que hay entre las iniciativas puramente comunitarias y las dirigidas a generar negocio, o entre lo que significa Software Libre y Open Source, es obvio que el papel que juega ha cambiado. Y de nuevo, no hay mejor ejemplo que Linux, el proyecto de código abierto más relevante de la actualidad: hace muchos años que incluso un desarrollo de su envergadura -del que dependen muchos otros sistemas de software libre- de debe en su gran mayoría a programadores que cobran por ello.

“Este es un problema no solo para nosotros sino para casi cualquier proyecto de código abierto exitoso hasta la fecha“, añade Kanies, mientras que Bengal aporta un dato propio: “El 99% por ciento de las contribuciones a Redis fueron hechas por nuestra empresa, Redis Labs“. Dev Ittycheria, CEO de MongoDB, comparte la opinión: “Cada vez que un nuevo proyecto de código abierto se vuelve popular, los proveedores de nube eliminan la tecnología, ponen el software gratuito en su plataforma, capturan la mayor parte del valor, pero le dan muy poco a la comunidad“.

Se refieren principalmente a los tres grandes proveedores de infraestructuras y servicios en la nube, Amazon Web Services (AWS), Microsoft Azure y Google Cloud, pero también a los intermediarios que hay entre los prestadores de software y servicios y el cliente final. Hay que tener en consideración que el software de código abierto no tiene por qué ser gratuito, pero lo cierto es que el libre acceso al código fuente hace imposible o extremadamente difícil comercializarlo, si no es mediante complementos cerrados o servicios -por lo general, de soporte y consultoría- adicionales.

“Nuestra opinión es que el software de código abierto nunca fue pensado para que las empresas de servicios en la nube lo tomasen y lo vendieran“, comenta Salil Deshpande, director gerente de Bain Capital Ventures e inversor de Redis Labs. Algo que ya sucedía antes de la nube, pero que la nube ha multiplicado de manera exponencial, generando un volumen de negocio que al parecer no se reparte como debiera.

Es por ello que compañías como Redis Labs y MongoDB -y otras, de momento minoría- habrían decidido modificar las licencias bajo las cuales se distribuye parte de su software, con el objetivo de bloquear o al menos dificultar su aprovechamiento por parte de los proveedores de turno. ¿Podría llegar a cerrarlo por completo? Ese es otro cantar. Lo peliagudo del asunto es que podrían cerrar los cambios futuros, porque lo que ya está publicado es accesible a todo el mundo: ¿qué impediría a sus antiguos usuarios -los proveedores- crear un desarrollo alternativo?

Llegados a este punto las preguntas se encadenan la una a la otra, porque si es posible bifucar un proyecto libre que se cierra, ¿no hubiese sido mejor colaborar con él antes y haber evitado el cierre? Si no se invierte y se mantiene con salud aquello que da beneficios, puede terminar por desaparecer.

Fuente: www.muylinux.com

Spectre, o más bien las mitigaciones necesarias para mejorar la seguridad de los procesadores expuestos ante este vector de ataque, amenazan con provocar una notable disminución del rendimiento en las correspondientes computadoras. De esto vimos ayer un episodio algo dramático, ya que una mitigación contra los ataques Spectre v2 con las iniciales STIBP provoca una disminución de hasta el 50% en algunas cargas sobre CPU Intel (marca para la cual va dirigida la mitigación).

La situación ponía muy en duda la habilitación de STIBP, algo que fue respaldado por Linus Torvalds, quien recomendó la no activación por defecto de la mitigación y que en su lugar se inhabilitara SMT (Hyper-Threading en Intel) desde la configuración de la placa base si se quería afianzar la mejor de la seguridad. La llegada de STIBP no solo está prevista para Linux 4.20, sino que también ha sido portada hacia atrás a las versiones LTS 4.14 y 4.19, cosa lógica si tenemos en cuenta que se trata de una medida de seguridad contra Spectre. Las cargas de trabajo afectadas abarcan Python, PHP, Java, compilación de código y hasta la ejecución de algunos juegos, por lo que los problemas de rendimiento podrían impactar de forma apreciable no solo en entornos de servidor, sino también en el escritorio del usuario final.

Tras el revuelo generado, se han producido algunos movimientos en las bambalinas de Linux, ya que en la rama release candidate estable de Greg Kroah-Hartman se ha revertido el código de STIBP en Linux 4.14 y 4.19, así que los problemas de rendimiento tendrían que haber desaparecido en esas versiones. Sin embargo, la mitigación todavía sigue presente en Linux 4.20, con la intención de sea revisada bajo un mejor enfoque y esté lista antes de la publicación oficial de dicha versión del kernel dentro de un mes. La que se pretende es depurar el código STIBP para evitar en lo máximo posible el impacto en el rendimiento.

Aunque esta mitigación va dirigida a los usuarios de Intel, esto no quiere decir que los de AMD puedan cantar victoria, ya que a pesar de que la primera marca parece estar más afectada por los problemas derivados de Spectre, la segunda también hace uso de SMT, por lo que no se puede descartar que se produzcan episodios similares en sus productos.

Fuente: www.phoronix.com

Hace poco comparamos Kubuntu y KDE Neon, dos de las mejores distribuciones para disfrutar de la experiencia de escritorio de KDE Plasma. Hoy vamos a ver cómo mejorar la integración de LibreOffice con ambas, pues no siempre se encuentra uno lo que cabría esperar.

Básicamente hablamos del aspecto de la aplicación, del estilo visual y los iconos, que puede parecer un asunto menor, pero que en realidad cuenta mucho. Más allá de la primera impresión, utilizar aplicaciones que rompen con la estética del entorno supone una merma en la ‘usabilidad’, dificultando encontrar los iconos de acciones comunes al resto de aplicaciones.

En resumen, cuando abres por primera vez LibreOffice en KDE Neon y Kubuntu (repetimos: solo tras la instalación mínima) te encuentras con esto:

Pero se puede solucionar con instalar dos paquetes, que por alguna razón que no alcanzo a comprender, no son dependencias obligatorias al instalar LibreOffice en KDE Neon y Kubuntu: “libreoffice-style-breeze” y”libreoffice-gtk”. Se pueden instalar por consola o a través del gestor de paquetes Muon. Así es como LibreOffice muestra su mejor cara:

¿Y si no se usa el tema por defecto de KDE, Breeze? Entonces el paquete”libreoffice-gtk” forzará a la utilización del tema GTK que figure como predeterminado en las preferencias del sistema; mientras que en los repositorios hay unos cuantos para elegir, buscando por”libreoffice-style-” en Muon.

Recordar que tanto Kubuntu 18.04 LTS como KDE Neon 18.04 LTS tienen LibreOffice 6.0 en los repositorios, por lo que el cambio con los iconos que llegó junto con LibreOffice 6.1 no está en estas versiones. Sin embargo, ni instalando el PPA de LibreOffice para mantenerlo actualizado corrige el problema. Hay que hacerlo a mano.

Fuente: www.muylinux.com

Esto es un Kubuntu vs KDE Neon, sí, pero meramente informativo y de buen rollo, y es que Kubuntu y KDE Neon son dos de las distribuciones más recomendables para disfrutar de la experiencia del escritorio Plasma en toda su plenitud. Y cuando digo de las más recomendables, quiero decir eso exactamente: están arriba del todo, junto con alguna otra. Sin embargo, ambas se parecen tanto entre sí que pueden generar dudas a quien no las conozca bien. ¿Es lo mismo usar una o la otra? ¿En qué se parecen y en qué se diferencian? Vamos a verlo.

Kubuntu vs KDE Neon: similitudes

Kubuntu y KDE Neon se parecen mucho por un motivo fundamental, y es que su origen es el mismo: Ubuntu, KDE y Jonathan Riddell, durante muchos años el líder de Kubuntu… hasta que dejó de serlo. Después creó Neon, un proyecto que un tiempo antes había servido para probar el software en desarrollo de KDE. Sea como fuere, desde el principio resultó obvio que Neon era una suerte de continuación de Kubuntu, con una gran diferencia: ahora Riddell tenía las manos libres para hacer lo que quisiera, como quisiera.

Atendiendo a sus características básicas, Kubuntu y KDE Neon son lo mismo: distribuciones basadas en Ubuntu con el entorno de escritorio KDE Plasma. Ambas disfrutan de las ventajas de su base, ambas ofrecen un KDE Plasma bastante ‘de fábrica’… Y lo dicho: ambas son muy recomendables.

Kubuntu vs KDE Neon: diferencias

Pero también hay muchas diferencia entre las dos, comenzando por las ediciones y ciclos de lanzamiento. A saber:

• Kubuntu cuenta con una sola edición y lanza nueva versión cada seis meses, incluyendo las versiones LTS de soporte extendido, que salen cada dos años y que renuevan sus imágenes de instalación y los componentes base (kernel, stack gráfico) cinco veces a lo largo de los dos años siguientes a su lanzamiento.
• KDE Neon cuenta con tres ediciones, aunque solo una está dirigida a los usuarios de escritorio que buscan un sistema estable: la User Edition, de la cual existe una única versión, que se va renovando cada vez que se lanza una nueva versión de Plasma y que mantiene su soporte hasta unos meses después de lanzar su siguiente versión mayor.

¿Lo has pillado? Si no estás familiarizado con los ciclos de actualizaciones de ambas distros, puede resultar confuso, así que vamos a reducir el problema eliminando de la ecuación la versión “regular” de Kubuntu, que solo ofrece nueve meses de soporte y que aquí en MuyLinux no recomendamos por ese mismo motivo (ni Kubuntu, ni Ubuntu ni ninguna otra de la tribu que no sea LTS).

De hecho, vamos al grano con datos concretos comparando las versiones actuales de Kubuntu LTS y KDE Neon User Edition, porque liarse con los detalles es muy fácil. Son estas:

• Kubuntu 18.04.1 LTS
• KDE Neon 18.04 LTS

Soporte

Las dos distribuciones se basan en Ubuntu 18.04 LTS, por lo que su soporte es a priori el mismo: hasta 2023. Sin embargo, en ambos casos ese “soporte hasta 2023” se refiere únicamente a la base de Ubuntu y al mantenimiento de Canonical relativo a parches de seguridad, no al escritorio en sí.

Kubuntu 18.04 LTS tendrá soporte completo (base y escritorio) durante tres años, hasta 2021.

KDE Neon no deja muy claro el tiempo de soporte que ofrece, pero se da a entender que una vez ha salido la siguiente versión mayor, la vieja queda en modo mantenimiento durante varios meses. Por ejemplo:

• Quienes todavía estén usando KDE Neon 16.04 LTS, verán cómo siguen recibiendo actualizaciones del escritorio, pero llegará el momento en el que paren y deban actualizar sí o sí a la nueva versión.
• Quienes hayan instalado KDE Neon 18.04 LTS no necesitarán actualizar o reinstalar hasta que a mediados o finales de 2020 aparezca KDE Neon 20.04 LTS.

¿Cuál es mejor? Pues depende. Que el escritorio deje de recibir actualizaciones tampoco es un drama, mientras no falten los parches de seguridad y las actualizaciones de las aplicaciones crítica, léase navegadores web… Pero si no actualizas el escritorio, KDE Neon pierde el sentido

Actualizaciones de la base

Si bien no vamos a salirnos de Ubuntu LTS, esta recibe a lo largo de su vida hasta cuatro actualizaciones que incluyen nuevas versiones del kernel y del stack gráfico, las conocidas como LTS Enablement Stack. Esto lo hemos explicado mil veces, así que lo dejamos ahí. ¿Cómo se lo montan las dos distros?

• Los usuarios de Kubuntu 18.04 o 18.04.1 tendrán la oportunidad de actualizar el LTS Enablement Stack manualmente, mientras que quienes instalen Kubuntu 18.04.2 o superior (o hayan habilitado el LTS Enablement Stack) recibirán esas actualizaciones directamente.
• Los usuarios de KDE Neon 18.04 recibirán las actualizaciones del LTS Enablement Stack directamente.

¿Cuál es mejor? Pues también depende. Habrá quien prefiera mantenerse con un kernel más viejo pero soportado en aras de una mayor estabilidad, y quien prefiera actualizar de vez en cuando en aras de un mejor soporte. Si cuando instalaste todo te iba bien, tampoco es un drama.

Actualizaciones del escritorio

Comienzan las diferencias más destacadas…

• Kubuntu 18.04 LTS llegó con KDE Plasma 5.12 LTS, y con esa versión se quedará hasta fin de ciclo. La posibilidad de actualizar a nuevas versiones del escritorio no se contempla, por algo usan una versión LTS del escritorio que recibirá mantenimiento, pero no nuevas funciones.
• KDE Neon 18.04 LTS llegó con KDE Plasma 5.13 y actualizará constantemente las bibliotecas del escritorio (KDE Frameworks), el entorno de escritorio (KDE Plasma) y las aplicaciones (KDE Applications) a su última versión estable hasta fin de ciclo.

¿Cuál es mejor? Sigue dependiendo del criterio: habrá quienes estén encantados de tener siempre lo último de Plasma, y a quienes les sobre con lo que ya tienen.

Otras diferencias

Kubuntu y KDE Neon tienen otras muchas diferencias entre sí, pero tienden a ser detalles sin la mayor importancia. Con una excepción:

• Cada actualización del escritorio en Kubuntu, ya sea de mantenimiento e incluso de versión mayor (por ejemplo vía backports, los repositorios adicionales del proyecto donde van colgando lo más reciente; pero no en el caso de la 18.04) se compilan siempre teniendo en cuenta todo el software de los repositorios de Ubuntu, lo que asegura la compatibilidad y que no se rompan aplicaciones Qt (no KDE).
• En KDE Neon, sin embargo, lo que prima es el software de KDE, por lo que si una actualización de Qt, KDE Frameworks o lo que sea rompe alguna aplicación Qt (no KDE) de los repositorios de Ubuntu, es lo que hay. Aunque hay que decir que esto no suele pasar a menudo.

¿Cuál es mejor? Dependerá, una vez más, de los requisitos del usuario.

Y hasta aquí llegamos. ¿Falta o falla algo? A los comentarios.

Pero si lo que te preguntas es cuál de las dos es mejor… Lo repetimos: Kubuntu y KDE Neon son dos de las distribuciones más recomendables para disfrutar de la experiencia del escritorio Plasma en toda su plenitud, aunque quizás por la cantidad de actualizaciones que recibe Neon puede haber usuarios, especialmente los más novatos, que prefieran quedarse en Kubuntu sin actualizar si quiera el LTS Enablement Stack.

Fuente: www.muylinux.com

ownCloud y ONLYOFFICE han anunciado un acuerdo de colaboración por el cual la suite ofimática se pone a disposición de los usuarios de la plataforma en la nube “de manera formal”, según informan.

Como es sabido, hasta ahora ha sido la propuesta de Collabora, lo que conocemos como LibreOffice Online, la primera en integrarse en software como ownCloud o Nextcloud, ofreciendo capacidades de edición de documentos. Algo que no va a cambiar. Pero de un tiempo a esta parte también ONLYOFFICE está disponible para quien desee tener una alternativa ofimática en su propia nube. 

A partir de ahora los usuarios de ownCloud podrán instalar más fácilmente los editores en línea de ONLYOFFICE. Sin embargo, esta nueva asociación va más allá e incluye ampliar y mejorar el soporte, cooperación técnica entre ambas compañías para una mejor integración del software y un acuerdo comercial dirigido a empresas con todos los beneficios comentados.

Algunas de las ventajas que destacan de ONLYOFFICE es su compatibilidad con los formatos de Microsoft Office, pero también con Open Document, edición colaborativa y opciones avanzadas como revisión, comentarios y chat en vivo.

Como se ha mencionado, ONLYOFFICE ya funciona junto con Nextcloud y ownCloud, y de hecho el conector para instalarlo está disponible en las tiendas de aplicaciones de los dos proyectos. Pero en esta ocasión es ownCloud la que se adelanta a una mejor integración, con especial atención en el mercado corporativo, que es el que más demanda este tipo de soluciones.

Os recordamos que ONLYOFFICE es esa suite ofimática libre con el ‘ribbon’ que tanto te gusta, cuyas aplicaciones de escritorio están disponibles para instalar en Linux de manera independiente. Y aunque en comparación con LibreOffice puede resultar más moderna visualmente, pero menos potente en en funciones, en comparación con Collabora Online la cosa cambia.

Fuente: www.muylinux.com

El cliente de Google Drive Insync lanza nueva versión y… siempre es una buena noticia, porque a falta de aplicación oficial, se trata de la herramienta más completa, efectiva y accesible para sincronizar archivos con la nube del gigante de Internet.

Tras un par de años relativamente tranquilos, en Insync se han revolucionado y este 2018 han caído ya dos versiones del cliente, la última de las cuales está siendo anunciada estos días. ¿Qué hay de nuevo, viejo? Pues muchas cosas, pero sobre todo de cara al futuro. Un camino que comenzó con el lanzamiento de Insync 1.4 el pasado, que continúa con el que ahora nos ocupa y que seguirá progresando hasta convertirse en… No está claro.

Dicen sus desarrolladores que “si Google Drive y Spotify tuvieran un bebé, sería Insync 1.5“, lo cual no ayuda a esclarecer el asunto, aunque es de suponer que se refieren a su evolución de “simple” cliente de sincronización a aplicación de propio derecho, con cada vez más opciones con las que evitar abrir el navegador web para realizar determinadas acciones. Por ejemplo, agregando las opciones de los atajos de teclado de Google Drive para que se muestren cuando pasas el cursor por en encima de lar carpetas sincronizadas, o reorganizando el menú contextual.

Lo más llamativo de Insync 1.5 es el remozado de la interfaz, que además de los cambios mencionados recibe un ligero refresco estético; pero hay más novedades bajó el capó, incluyendo una sincronización más pulida (siempre ha ido muy bien, pero ahora resolverá mejor los errores) y soporte para HiDPI en la aplicación de escritorio para Linux, Windows y Mac.

Si ya tienes Insync instalado en tu sistema, la actualización te llegará en las próximas semanas, siempre que tengas agregado el repositorio. Si no te quieres esperar, la descarga de la nueva versión está disponible en la página web oficial. Te recordamos que es software de pago (29,99 por cuenta de Google), pero vale la pena si estás en Linux y Google Drive es importante para ti.

Fuente: www.muylinux.com

Es de suponer que ya estará todo el mundo al tanto de que Google+ cierra sus puertas en breve. La red social del gigante de Internet ha sido un fracaso y a ello se le suma una vulneración masiva de datos a lo largo de tres años, motivos por los cuales la compañía dará carpetazo a la plataforma el próximo agosto de 2019.

Dejando a un lado el problema de seguridad o cómo Google monetiza todo lo que ofrece gratuitamente, Google+ ha sido -todavía lo es- una red social con conceptos de usabilidad muy interesantes, y que en lo que respecta a la comunidad linuxera ha servido de refugio para usuarios, comunidades y proyectos de todo tipo (es la única red social en la que está presente Linus Torvalds, por ejemplo), aunque de un tiempo a esta parte parece que Telegram le ha robado el protagonismo. 

Sea como fuere, MuyLinux está en Google+ y aunque la actividad de quienes nos siguen por ahí, ya sea dando más uno o comentando, se ha reducido considerablemente en los últimos tiempos, aguantaremos un poco más. No sé si hasta finales de año o hasta el cierre definitivo, dependerá de el feedback que nos hagáis llegar. No obstante, es conveniente ir haciéndose a la idea y cambiar a soluciones con mejor salud.

Conociendo el funcionamiento de Google+, a pesar de haberlo abandonado hace tiempo, recomendaría como sustituto un buen lector de RSS y para comentar, el sitio que leáis o el grupo de Telegram de vuestra elección (¡en breve publicaremos un artículo con los mejores!). Dicho lo cual, también nos tenéis en Telegram, además de en Facebook, Twitter y correo electrónico.

Más allá de que esto haya sido la crónica de una muerte anunciada.

Fuente: www.muylinux.com

En el pasado mes de marzo adelantamos que JavaFX se convertiría en un módulo desarrollado por separado de JDK 11, siendo este un movimiento derivado de una decisión de Oracle, actual propietaria de la implementación oficial de Java.

JavaFX 11, que ya actúa como un módulo independiente con su propio sitio web, ofrece una plataforma de aplicaciones cliente para el escritorio, los móviles y sistemas embebidos, siendo un entorno de ejecución disponible como un SDK específico a la plataforma, ya sea como ficheros jmod o un conjunto de artefactos centrales de Maven. Esto obligará a partir de JDK 11 el tener que incluir explícitamente los módulos de JavaFX en el código.

Sin embargo, que JavaFX actúe como un módulo independiente no quiere decir que vaya a ser abandonado a su suerte, ya que según InfoWorld, la versión 11 incluye importantes como la API FX Robot para la simulación de interacciones de usuario, incluyendo entradas de teclado, utilización del ratón y captura de información gráfica; no tendrá permisos por defecto; se han añadido propiedades para personalizar el tiempo de repetición de pasos para el control Spinner; soporte para la interoperabilidad con FX Swing, que está compuesto por JFXPanel y SwingNode, utilizando una API pública; actualización del renderizador MarlinFX a la versión 0.9.2, el cual tiene una mayor precisión de curva y un muestreo de subpíxel mejorado, mejorando la calidad visual de los segmentos casi verticales sin coste en el rendimiento; los colores estándares han sido añadidos a la paleta de colores ColorPicker; la clase Bound ha sido mejorada con el método GetCenter; y GTX (Gimp Toolkit) ha sido cambiado a la versión 3, siendo este un importante conjunto de herramientas de gráficos a bajo nivel en GNU/Linux. A todo lo mencionado hasta aquí, y como suele ser habitual en el desarrollo de software, se suman una gran cantidad de fallos que han sido corregidos.

JavaFX 11 puede ser descargado desde el sitio web de OpenJFX y parece dar problemas cuando se combina con Wayland y OpenJDK 11 en GNU/Linux, o al menos esa es incidencia de la que han informado en InfoWorld sobre Ubuntu 18.04, recomendando la utilización de Xorg como servidor gráfico.

Fuente: www.muylinux.com

KMail puede ser interpretado como la respuesta del Proyecto KDE a Evolution, la solución de organización personal y cliente de correo de GNOME. Sin embargo, hasta el día de hoy no parece que haya sido una gran competencia, y aquí no se puede dejar olvidado a Thunderbird, posiblemente la solución más popular para gestionar correo electrónico en GNU/Linux.

Pese a todo, eso no quiere decir que KMail haya quedado en abandono, sino que sus desarrolladores todavía ponen de su parte para añadirle características que le den valor frente a sus competidores, pudiéndose destacar la recientemente añadida bandeja de entrada unificada, que permitirá ver de una vez los correos electrónicos de todas las cuentas configuradas en la aplicación, la cual también está acompaña de bandejas de salida y borradores unificadas, tal y como se puede ver en la imagen publicada por el desarrollador Nate Graham.

Las bandejas unificadas de KMail han sido incorporadas a KDE Applications 18.12.0. Por otro lado, en KDE Plasma 5.14 se están preparando otras muchas cosas, como mejoras en el manejo del ratón y el panel táctil con Libinput, ordenación de iconos desde el Gestor de Tareas en LibreOffice, corrección de un cuelgue que se producía después de perder la conexión con una ubicación remota, el administrador de tareas ahora se ajusta a los escritorios virtuales cuando se decide agrupar varias instancias o ventanas de una aplicación en ejecución, la eliminación de falsas advertencias cuando se usa el atajo Ctrl+T mientras se ejecuta Dolphin fuera de KDE y las marcas de tiempo de Spectacle son ahora fijados cuando la captura de pantalla es tomada y no cuando se graba el fichero. A todo eso se suma el pulido y mejora de la interfaz gráfica, destacando la utilización de terminologías “menos técnicas y más consistentes” en KRunner.

Como vemos, desde hace años el Proyecto KDE aplica una visión bastante conservadora en el desarrollo tanto del entorno como de las aplicaciones que están bajo su paraguas, aplicando los cambios poco a poco para no romper la experiencia de usuario ni introducir regresiones a nivel de rendimiento y estabilidad, algo que podría derivar de los duros comienzos de KDE 4.

Fuente: www.muylinux.com

Pocas áreas de negocio le están dando al gigante del software tantas alegrías como su plataforma de servicios en la nube, y lo que quizás antaño hubiesen tomado como una ofensa, hoy lo celebran sin tapujos: Linux ya es el sistema más utilizado en Microsoft Azure.

La noticia la da Scott Guthrie, vicepresidente de la división de nube y empresa en Microsoft, en una entrevista de la que se hace eco ZDNet. “Algo más de la mitad de las máquinas virtuales de Azure son Linux“, comenta el ejecutivo, añadiendo que “Linux sube todos los meses“.

No pasa nada. Tal y como se suele decir, en Microsoft están por la labor de darle la razón al cliente. “Vamos a donde están los clientes“, apunta Raghu Ramakrishnan, director de tecnología en la división de datos de la compañía. “Si quieres Linux, te daremos Linux, si quieres MySQL, te daremos MySQL; si no quieres NoSQL, no te daremos NoSQL“.

Pero Microsoft no se queda ahí. No solo están para ofrecerle al cliente lo que quiere: cada vez usan más Linux internamente, según Guthrie. “Los servicios Native Azure a menudo se ejecutan en Linux. Microsoft está creando más servicios de este tipo. Por ejemplo, la Red Definida por Software (SDN) de Azure se basa en Linux“.

No obstante, hay Linux en Microsoft más allá de Azure: “Fíjate en nuestro lanzamiento simultáneo de SQL Server para Linux. Todos nuestros proyectos se ejecutan ahora en Linux“, agrega Guthrie. Y no le falta razón, siempre que no nos salgamos del ámbito servidores y desarrollo.

Hace años que vemos cómo las principales distribuciones ha ido llegando a Azure y, más recientemente, cómo los grandes proveedores de Linux corporativo adaptan sus productos para la nube de Microsoft, incluyendo a Canonical, Red Hat y SUSE. La del sombrero rojo, sin embargo, es la que más afinadas tiene sus soluciones a este respecto, así como la colaboradora más destacada de la compañía dirigida por Satya Nadella.

En todo caso, no es nada fuera de lo normal. Hace tiempo que Microsoft reconoció que aceptar Linux y el código abierto era “una decisión de negocio práctica“. Lo cual es correcto. Pero no se conforman con eso, parece.

“Reconocimos que el código abierto es algo de lo que todos los desarrolladores pueden beneficiarse. No es bueno, es esencial. No es solo código, es comunidad. No nos dedicamos simplemente a lanzar código en un sitio web, ahora publicamos nuestra hoja de ruta y trabajamos con colaboradores externos“, comenta Guthrie.

Y culmina, recordando de paso la última gran compra de la compañía y un hecho destacado previo: “Tenemos más de 20.000 empleados de Microsoft en GitHub. Tenemos más de 200 proyectos de código abierto. Somos el mayor partidario del código abierto en el mundo“.

Fuente: www.muylinux.com