A raíz de nuestro artículo sobre los repositorios de Ubuntu, el lector Carlos nos pregunta sobre como trabajar con ellos. Quiero aclarar que aunque la mayoría de los tutoriales explican como hacerlo usando la terminal, esto es porque resulta mucho más cómodo para quienes los escribimos. Se puede trabajar de maravillas con ellos usando una herramienta gráfica.

Cómo trabajar con repositorios. La herramienta Software y actualizaciones

Nuestro primer paso para trabajar con los repositorios es abrir la herramienta que se encarga de gestionarlos. Esa herramienta se llama Software y actualizaciones y puedes encontrarla escribiendo cualquiera de las dos palabras en el lanzador. Una vez que lo hacemos veremos algo como esto.

La herramienta Software y actualizaciones nos permite gestionar repositorios en forma gráfica

Presta atención al sector de la captura de pantalla recuadrado. Dependiendo de la opción que elijas esto determinará la rapidez con que se descargan e instalan los programas y actualizaciones en tu equipo.

Puedes optar por tres opciones

• El servidor que Ubuntu destina para las descargas de tu país (es la opción que viene activada por defecto)
• Un servidor cercano a tu ubicación geográfica cedido por un tercero para la descarga de Ubuntu (Permite descargas más rápidas.
• El servidor principal de Ubuntu (Tendrás las actualizaciones disponibles antes que usando los otros servidores pero la descarga puede tardar un poco más)

Seleccionando un servidor de descarga

Cuando pulses sobre la derecha del sector recuadrado, verás un menú con 3 opciones. Si quieres seleccionar el servidor con descargas más rápidas, solo tienes que pulsar en la palabra Otro.

Ubuntu nos permite seleccionar el servidor de descargas más rápido según nuestra ubicación geográfica

La ventana inicial nos muestra los servidores correspondientes a nuestros país, pero no siempre suelen ser los más rápidos. Esto puedes comprobarlo pulsando en Seleccionar el mejor servidor.

Ubuntu realiza rápidamente pruebas a los distintos servidores de su lista para encontrar el mejor según nuestra ubicación.

El proceso de prueba dura unos pocos minutos tras lo cuál nos ofrece su sugerencia.

Si estás de acuerdo con el servidor propuesto por Ubuntu, debes pulsar sobre Elegir servidor.

Es buen momento para aclararte que para que cualquier cambio que hagas con la herramienta Software y actualizaciones tenga efecto, debes pulsar el botón Cerrar y permitir que la lista de repositorios se actualice.

Descarga de código fuente y desde medio de instalación

Antes de pasar al tema sobre cómo trabajar con repositorios de terceros, debemos dedicar nuestra atención a dos cosas más de la pantalla inicial.

Si observas los rubros listados bajo el título Descargable de Internet verás una lista de repositorios. Cuatro son los que comentamos en un artículo anterior, pero del quinto, Código fuente, no habíamos dicho nada hasta ahora.

Anteriormente dijimos que Ubuntu utiliza dos formatos de programas principales. DEB y Snap. Aunque ambos se instalan, se manejan y funcionan de manera diferente, el Centro de software de Ubuntu puede trabajar indistintamente con  cualquiera de los dos.

Por el contrario, la herramienta Software y actualizaciones trabaja únicamente con repositorios de paquetes DEB y, en caso de activar la opción con código fuente. En este último caso estamos hablando de programas que los desarrolladores de Ubuntu no llegaron a convertir al formato de paquetes DEB y deben ser compilados en nuestra computadora para poder utilizarse. La compilación es el proceso de convertir un programa escrito en un lenguaje de programación amigable para los seres humanos en otro legible para la computadora.

Activar esta opción no es obligatorio y puede hacer un poco más lento el proceso de instalación. Sin embargo, si por algún motivo necesitas la última versión de un programa o simplemente no soportas la espera, puedes marcarla. Tampoco  es que afecte demasiado.

La última opción que quería comentarte antes de abandonar la primera pantalla del Centro de Software es la de instalar programas desde el medio de instalación. Nunca se molestaron en cambiar el título por lo que sigue hablando de CD-ROM, pero, lo mismo vale para medios de instalación en pendrive. En caso de marcar el recuadro, los programas se instalarán desde ahí en lugar de buscarlos en un servidor de Internet. Por supuesto, no tendrás actualizaciones hasta que no lo desmarques.

En el próximo artículo veremos como activar repositorios de terceros de manera gráfica

from Linux Adictos https://ift.tt/2JrZFXl
via IFTTT

Hay un viejo chiste en el mundo de la tecnología que dice que cada vez que alguien intenta crear un formato que junte lo mejor de todos los demás para evitar la dispersión, lo único que logra es agregar uno nuevo a la lista. Algo de eso hay con las iniciativas de crear un formato de paquete que pueda ejecutarse en todas las distribuciones Linux sin modificaciones. En lo que va del siglo ya llevamos tres.

Snap, Flatpak y Appimage. Diferencias con los formatos tradicionales

La principal diferencia entre los formatos de paquetes nativos y los formatos de paquetes independientes es que los primeros comparten dependencias con otros programas instalados en el sistema operativo. Es decir que si el programa Y necesita la dependencia 1 y esa dependencia fue instalada por el programa X que también la necesita, esa dependencia no volverá a instalarse.

Los programas empaquetados con formatos independientes incluyen todas las dependencias que necesitan para su funcionamiento. Es decir que la dependencia 1 se instalará cada vez que se instale un programa que la necesite.

La segunda diferencia es que los formatos de paquetes tradicionales deben ser construidos con las especificaciones de cada distribución. Es por eso que por más que Ubuntu sea una distribución derivada de Debian, las diferencias son lo suficientemente importantes como para que los repositorios de la primera no puedan ser usados en la segunda.

La tercera diferencia es que cualquier modificación a una dependencia de los paquetes tradicionales puede afectar el funcionamiento de todos los demás que la necesitan. En cambio, las modificaciones a un programa en un formato independiente, no afectará al resto del sistema.

Dependiendo de las particularidades de cada distribución, es posible instalar las aplicaciones en formatos independientes desde un gestor de paquetes y automatizar su actualización con el gestor encargado de las mismas.

En Ubuntu, el Centro de Software permite instalar tanto programas en formatos tradicionales como Snap, dándole preferencia a estos últimos. Por más que existe un plugin que permite que el Centro de Software de GNOME (del cuál se deriva el de Ubuntu) no funciona con esta distribución.

En el caso de Ubuntu Studio, es posible activar la opción de usar paquetes Snap mientras que KDE Neon y Manjaro pueden funcionar con ambos formatos.

Snap

Es el más nuevo de los formatos independientes ya que su desarrollo comenzó en el 2014.  Está pensado no solo para ser usado en distribuciones Linux de escritorio  si no también para Internet de las cosas, dispositivos móviles y servidores. Aunque es posible crear tiendas de aplicaciones independientes, en este momento solo existe una operada por Canonical, Snapcraft.

Aunque Snapcraft tiene un surtido de las aplicaciones más populares de código abierto, su fuerte son los programas desarrollados por empresas desarrolladores de software privativo y prestadoras de servicios en la nube.

Flatpak

Aunque oficialmente Flatpak  se lanzó en el 2015, es la continuidad de otro proyecto de formato universal conocido como xdg-app.  Este proyecto nació con el  objetivo de poder ejecutar aplicaciones en una caja de arena virtual segura, que no  requiera privilegios de root ni suponga una amenaza de seguridad para el sistema.

Flatpak está enfocado en las distribuciones de escritorio también utiliza el concepto de tienda de aplicaciones siendo Flathub la más conocida.

El punto fuerte de Flathub es que suele tener las versiones más actualizadas de las principales aplicaciones de código abierto.

Appimage

AppImage es el más antiguo de los formatos de paquetes independientes ya que se lanzó por primera vez en 2004.

Fue el primer formato en seguir el paradigma de «Una aplicación- unarchivo». Eso significa que  cada vez que descargamos un archivo Appimage estamos descargando la aplicación y todo lo que necesita para funcionar.  Si queremos usar la aplicación solo debemos darle permisos de ejecución y hacer doble clic sobre el icono que la identifica.

Appimage no utiliza el  sistema de tienda de aplicaciones, pero, hay una página web en la que podemos encontrar una lista de todos los títulos disponibles. 

Para actualizar las Appimage, podemos utilizar esta herramienta.

from Linux Adictos https://ift.tt/3ehA130
via IFTTT

En nuestro artículo anterior enumeramos los diferentes orígenes del software que se puede instalar en Ubuntu 20.10 Groovy Gorilla y dijimos que el método principal era el uso de repositorios. En este post vamos a explicar cuál es el contenido de cada uno de ellos.

Los repositorios de Ubuntu

Los repositorios son archivos de software. Ellos contienen no solo los programas si no información adicional para el correcto funcionamiento de los mismos como por ejemplo que bibliotecas del sistema operativo necesita para su funcionamiento. No necesariamente a los repositorios se accede en forma remota. El propio medio de instalación de Ubuntu puede funcionar como tal y permitir la instalación de programas en caso de que no tengamos conexión a Internet.

Para hacer más clara la explicación podemos distinguir entre 3 tipos de repositorios

• Repositorios tradicionales
• Archivos personales de paquetes
• Tienda de Snap

Los repositorios tradicionales

Los repositorios tradicionales fueron la primera forma de instalar paquetes en Ubuntu y aún hoy ocupan un rol principal aunque la intención de los desarrolladores es reemplazarlos paulatinamente por la tienda de Snap. Los programas instalados de esta forma utilizan un esquema de dependencias, es decir que las funciones comunes con otros programas (como por ejemplo guardar un archivo o imprimir) es realizada por otros programas que también deben instalarse en caso de que no se hubiera hecho con otra aplicación instalada anteriormente. Cualquier modificación de una dependencia puede afectar el funcionamiento de todos los programas que la necesitan.

Los repositorios tradicionales se dividen en cinco categorías:

• Main
• Restricted
• Universe
• Multiverse
• Asociados de Canonical

Main

En este repositorios encontramos aplicaciones que al ser de software libre o de código abierto, pueden ser redistribuidas libremente. Además, los desarrolladores de Canonical (la empresa detrás de Ubuntu) se ocupan de que estén permanentemente actualizadas y de encontrar soluciones a cualquier problema de funcionamiento. En los repositorios Main se incluyen aquellas aplicaciones que Canonical, la comunidad del software libre y los usuarios consideran imprescindibles.

Restricted

En este apartado tenemos los controladores para dispositivos que no están disponibles bajo licencias libres y que por lo tanto no pueden ser modificados ni redistribuidos sin permiso de los desarrolladores originales. Estos controladores pueden ser desinstalados sin comprometer la integridad del sistema operativo, aunque su eliminación puedec ausar que el funcionamiento no sea del todo eficiente.

Universe

Este repositorio incluye una selección de programas de código abierto sin soporte garantizado por Canonical, aunque se agregan las actualizaciones y correcciones de seguridad en el momento en que estén disponibles.

Multiverse

Aquí tenemos programas con licencias que restringen su modificación y redistribución, siendo los usuarios los responsables de garantizar el cumplimiento de las mismas. Los desarrolladores de Ubuntu no son responsables de su mantenimiento ni actualización. Un ejemplo de programas que podremos encontrar en este tipo de repositorios son los programas para reproducir determinado contenido multimedia.

Asociados de Canonical

Aquí encontramos aplicaciones con licencias restrictivas cuyos desarrolladores acordaron con Canonical permitir su distribución con Ubuntu. No se garantiza la actualización ni la corrección de errores y problemas de seguridad.

Archivos personales de paquetes

Para que un programa sea incluido en los repositorios principales de Ubuntu es necesario un riguroso proceso de testeo que lleva tiempo. Con el objetivo de brindar a los desarrolladores una forma más rápida de publicar sus aplicaciones y de ampliar la oferta para los usuarios, se desarrollaron los archivos personales de paquetes (PPA)

Estos repositorios no están alojados en los mismos servidores que utilizan los repositorios oficiales de Canonical si no que utilizan los de un servicio llamado Launchpad propiedad también de Canonical. Para poder instalar este tipo de programas debemos agregar el repositorio.

Los programas instalados desde los archivos personales de paquetes se comportan exactamente igual que los programas instalados desde los repositorios tradicionales. Es decir que un programa disponible en el repositorio ppa es de una versión posterior al que se encuentra instalado lo reemplazará.

Cabe mencionar que es posible que se produzcan problemas de compatibilidad entre programas instalados de una y otra forma y, que cada mantenedor de un archivo personal de paquetes es responsable de su actualización y de la corrección de brechas de seguridad

Tienda de Snap

Con el objeto de tratar de reducir la dispersión de formatos de programas que utilizan las distribuciones Linux, se iniciaron distintos proyectos de un formato universal. Uno de ellos es el formato Snap.

A diferencia de los formatos de paquetes tradicionales, un paquete snap contiene todo lo necesario para su funcionamiento y se lo puede actualizar o eliminar sin afectar el resto del sistemas operativo

Dado que la intención de los desarrolladores de Ubuntu es que el formato Snap a la larga reemplace a los paquetes DEB, el Centro de Software se ocupa de su instalación y el gestor de actualizaciones de mantenerlos actualizados.

from Linux Adictos https://ift.tt/3jL1GKz
via IFTTT

Hace algunos años, una de las cosas que había que explicarles a los usuarios que venían de Windows era que Linux tenía un paradigma diferente a la hora de instalar programas. En lugar de tener que descargarlos desde la web del desarrollador se usaban repositorios y gestores de paquetes.

Gracias a la popularización de los dispositivos móviles y sus tiendas de aplicaciones, hoy esto ya no suena como algo de otro planeta. Sin embargo, nos queda el desafío de explicarles los distintos formatos de programas disponibles para Linux, sus diferencias y sus características.

Dado que es la distribución que más ha contribuido a la confusión general, nos vamos a centrar en Ubuntu. Más concretamente en la última versión disponible al momento de escribir este artículo Ubuntu 20.10 Groovy Gorilla.

Los programas para Ubuntu. Diferentes tipos de orígenes

En Linux existen varias formas de instalar programas

• Usando un gestor de paquetes
• Utilizando el emulador de terminal
• Descargando de Internet y haciendo doble clic sobre el archivo.
• Compilando

Usando un gestor de paquetes

En Ubuntu, el gestor de paquetes por defecto (en todos los sentidos de la palabra) Es el Centro de software de Gnome (CSG) . El centro de software no es diferente de las tiendas de aplicaciones de los dispositivos móviles. Podemos buscar los programas por nombre o por función e instalarlos y desinstalarlos haciendo clic en un botón.

Cuando pulsamos sobre el nombre de un programa podemos ver una descripción sobre lo que hace, el tipo de licencia y las valoraciones de otros usuarios.

No soy precisamente un fanático de esta aplicación y prefiero otras alternativas como el Gestor de Paquetes Synaptic que, sin ser tan bonito, es mucho más práctico y contiene información más completa sobre los programas que el CSG

Utilizando el emulador de terminal

Otra forma de instalar programas es escribiendo los comandos adecuados en el emulador de terminal. Este método suele ser más rápido que utilizar el Centro de Software además de que nos permite detectar errores y conocer información sobre bibliotecas o programas cuya instalación no es obligatoria pero, que mejoran la funcionalidad del que estamos instalando.

Los dos primeros métodos se basan en el uso de repositorios. Los repositorios son archivos de software alojados en servidores externos. Los programas incluidos en los repositorios oficiales son controlados por los responsables de cada distribución para garantizar su correcto funcionamiento al momento de la instalación. Cada cierto tiempo el sistema operativo verifica los repositorios para ver si es necesario actualizar los programas ya instalados.

Las distribuciones Linux suelen permitir la utilización de repositorios mantenidos por terceros, aunque no se hacen responsables de la compatibilidad ni la seguridad de los programas incluidos.

Descarga de Internet

En Ubuntu es posible instalar programas descargándolos de Internet e haciendo doble clic sobre ellos. Son programas empaquetados en el formato de paquetes DEB (nativo de las distribuciones derivadas de Debian como Ubuntu). Al hacer doble clic se abre el Centro de software que los instala como si fuera un programa de los repositorios. La diferencia es que, al menos que el desarrollador de ese paquete haya incluido la opción de agregar un repositorio, no será posible instalar actualizaciones.

Otra posibilidad es que se trate de archivos ejecutables escritos en lenguajes de programación multiplataforma como Java o de paquetes autocontenidos como los que están en formato. Appimage.

En todos los casos debemos asegurarnos que provengan de fuentes confiables antes de instalarlos.

Compilación

La compilación consiste en transformar un archivo de código fuente (escrito en un lenguaje de programación amigable con los humanos) en otro lenguaje más amigable con el procesador que lo ejecutará con mayor rapidez. No es un procedimiento complejo cuando uno sabe lo que está haciendo, pero lleva su tiempo. Por lo que la mayoría de las personas prefieren utilizar los otros métodos de instalación.

En el próximo artículo vamos a explicar cuál es la diferencia entre los diversos repositorios propios y de terceros que utiliza el gestor de paquetes de Ubuntu.

from Linux Adictos https://ift.tt/2TIjPy1
via IFTTT

La Fundación Wikimedia, que administra Wikipedia, ha decidido oficialmente trasladar sus repositorios de código de Gerrit, su sistema de revisión de código actual, a una instalación Gitlab Community Edition autohospedada.

Según el grupo de trabajo de la asociación, la fricción con Gerrit ralentiza el desarrollo en lugar de favorecerlo, lo que lleva a los desarrolladores a migrar a hosts de terceros. Sin embargo, la opción de recurrir al alojamiento de código por parte de terceros es perjudicial para la colaboración, tanto interna como externa, en Wikimedia.

Wikimedia ha descubierto que los resultados de una encuesta de satisfacción de desarrolladores realizada durante los últimos dos años han provocado quejas sobre el sistema de revisión de código Gerrit.

En particular, la interfaz de Gerrit tiene la reputación de ser difícil de usar, según Wikimedia, y el flujo de trabajo es diferente del método habitual de la industria, por lo que muchos desarrolladores no lo tienen. apreciado.

La Fundación Wikimedia también dijo que el personal de tecnología tardó un tiempo en acostumbrarse a Gerrit, lo que puso el listón más alto para los recién llegados a la comunidad Wikimedia.

“Esta insatisfacción es particularmente evidente para nuestras comunidades de voluntarios. La evidente insatisfacción con la revisión del código, junto con una revisión interna de nuestras herramientas y prácticas de CI, hace que este sea un momento oportuno para revisar nuestras opciones de revisión de código ”, escribió el grupo. de trabajo en un post de la semana pasada.

La Fundación Wikimedia reconoce que el flujo de trabajo de Gerrit es en muchos sentidos el mejor de su clase, pero “su interfaz adolece de deficiencias de usabilidad y su flujo de trabajo difiere de las prácticas habituales de la industria.

Esto crea barreras de entrada para la comunidad y ralentiza la integración del personal técnico de WMF. Además, un número cada vez mayor de personas y equipos (personal y no personal) están optando por renunciar al uso de Gerrit y, en su lugar, utilizan una opción alojada por terceros como GitHub ”.

Según el grupo de trabajo, los desarrolladores están insatisfechos por varias razones, tres de las cuales son muy importantes. Parten de Gerrit para beneficiarse de la reducción de la fricción al crear nuevos repositorios; instalación más sencilla y configuración de autoservicio de integración continua; y más familiaridad con los flujos de trabajo de solicitudes de extracción.

Sin embargo, si algunos equipos o personas están utilizando un servicio de alojamiento que no sea de Gerrit, no podrán compartir el código con Gerrit y otros, creando una mayor confusión entre el personal técnico, según Wikimedia.

A menos que se resuelvan los problemas de usabilidad que los usuarios tienen con Gerrit, cada usuario continuará con el proyecto utilizando el servicio de su elección. GitHub ya cuenta con 152 proyectos relacionados con la Fundación Wikimedia, de los cuales 127 son los equipos oficiales de investigación y análisis de datos de la Fundación Wikimedia.

La Fundación Wikimedia recurre a GitLab Community Edition, ya que GitLab fue desarrollado en Ruby on Rails, un marco web gratuito escrito en el lenguaje Ruby.

Wikimedia Foundation califica este sistema de revisión de código como «funcional y extensible», y el propio GitLab señala en su sitio web que puede autohospedar GitLab Community Edition (CE) en los propios servidores de los desarrolladores. GitLab CE es una plataforma de desarrollo de software de código abierto de extremo a extremo con control de versiones integrado, seguimiento de problemas, revisión de código y más.

«GitLab está disponible para autohospedaje, según se requiera para la paridad con el resto de nuestra infraestructura de herramientas para desarrolladores y para aliviar las preocupaciones sobre la privacidad de los datos o las restricciones de uso de hospedaje de terceros», de después del equipo de Wikimedia que revisó GitLab. Además, debido a que «GitLab ofrece una Community Edition (CE) con licencia del MIT, se adhiere al principio rector de la Fundación de libertad y código abierto».

A partir del 23 de octubre de 2020, la Fundación Wikimedia decidió mover el repositorio de Gerrit a GitLab Community Edition.

Además, los repositorios alojados en GitLab se reflejarán en GitHub, por motivos de visibilidad, escribió el grupo de trabajo de Wikimedia en respuesta a otra pregunta, a saber, qué pasará con los repositorios desarrollados en GitHub si nos movemos a GitLab.

from Linux Adictos https://ift.tt/2TCXEcQ
via IFTTT

Hace pocos días Apple dio a conocer la noticia de que ya se encuentra desarrollando su propia tecnología de búsqueda para abordar el dominio de Google en el panorama de los motores de búsqueda.

Este esfuerzo se vuelve más notorio a medida que las autoridades antimonopolio de EE. UU. amenazan con pagos multimillonarios que Google está haciendo para asegurar la ubicación de su motor en el iPhone. Esto amenaza con forzar el fin de su asociación de investigación y reducir el control del líder de investigación en la industria.

En un cambio poco notorio con respecto a la última versión del sistema operativo iPhone, iOS 14, Apple comenzó a mostrar sus propios resultados de búsqueda y a vincular directamente a sitios web cuando los usuarios escriben consultas desde su pantalla de inicio. Esta capacidad de búsqueda web marca un avance importante en el desarrollo interno de Apple y podría formar la base de un ataque más completo a Google.

La compañía es notoriamente reservada sobre sus planes internos, pero la medida se suma a la creciente evidencia de que está trabajando para construir un rival para el motor de búsqueda de Google.

Sin embargo, por ahora, el motor de búsqueda predeterminado en los dispositivos de Apple sigue siendo Google, algo por lo que el gigante de las búsquedas le paga a Apple entre $8 mil millones y $12 mil millones al año.

Los especialistas en marketing de búsqueda también señalan el aumento de la actividad de Applebot, el rastreador web del fabricante del iPhone, que se utiliza para construir la vasta base de datos de material en línea que forma la base de cualquier motor de búsqueda.

Otras señales de que Apple está intensificando sus esfuerzos para desarrollar su propia tecnología de búsqueda es que la compañía contrató al jefe de búsqueda de Google, John Giannnandrea, hace más de dos años.

La contratación aparentemente tenía como objetivo aumentar sus capacidades de inteligencia artificial y su asistente virtual Siri, pero también aportó ocho años de experiencia dirigiendo el motor de búsqueda más popular del mundo.

La creciente capacidad de búsqueda interna de la empresa le ofrece una alternativa si los reguladores bloquean su lucrativa asociación con Google. Cuando el Departamento de Justicia de EE. UU. lanzó un caso la semana pasada sobre los pagos que Google hace a Apple por ser la herramienta de búsqueda predeterminada del iPhone, se agregó urgencia a la iniciativa.

Otra pista más importante es que iOS 14 ha dejado de lado a Google para algunas funciones de búsqueda. Las consultas realizadas en la ventana de búsqueda deslizable desde la pantalla de inicio del iPhone, que Apple llama «Vista de hoy», muestran una lista de sugerencias de búsqueda generadas por Apple en lugar de los resultados de Google.

Estos resultados incluyen sugerencias de «autocompletar» generadas por Apple, lo que demuestra que está aprendiendo de las solicitudes más comunes de sus mil millones de usuarios.

Apple se enfrenta a la elección de defender su contrato de búsqueda con Google o volverse contra su socio desde hace mucho tiempo

Construir un verdadero rival para el motor de búsqueda de Google podría llevar años. Pero Apple es una de las pocas empresas que tiene los recursos para enfrentarse a Google.

Con una capitalización de mercado de más de $ 2 billones y alrededor de $ 200 mil millones en efectivo, la empresa tiene la oportunidad no solo de rechazar el dinero recibido de Google, sino también de invertir en la infraestructura de servidor necesaria para la creación de un motor de búsqueda competitivo.

También vale la pena señalar que Apple siempre ha intentado poseer y controlar los componentes más importantes de sus productos, desde los chips personalizados que alimentan todo, desde el iPhone hasta sus AirPods y accesorios de reloj, hasta una estrecha integración entre su software y su hardware.

Sin embargo, durante más de diez años, Apple ha mantenido a Google como el motor de búsqueda predeterminado para el iPhone.

Fueron necesarios reguladores para obligarlo a elegir entre defender su relación con Google o volverse en contra de su antiguo socio de búsqueda, para impulsar al gigante tecnológico a buscar el cambio.

from Linux Adictos https://ift.tt/3e8K36a
via IFTTT

A principios de agosto, The Document Foundation lanzó LibreOffice 7.0. Fue un lanzamiento con mejoras importantes, entre las que yo destacaría su mejorada compatibilidad con Microsoft Office. Más tarde lanzó las dos primeras actualizaciones de mantenimiento, introduciendo la v7.0.2 más de 130 correcciones, algo importante si tenemos en cuenta que sistemas como Ubuntu 20.10 usa la séptima versión de la suite de ofimática. Hace unas horas, TDF ha hecho oficial el lanzamiento de LibreOffice 7.0.3.

Esta nueva actualización de punto ha llegado con otras más de 90 correcciones de errores, entre los que mencionan algunos molestos que se introdujeron en la v7.0.2, por lo que no tengo claro de si aquí podríamos hablar de una regresión. Además, también mencionan que se han introducido mejoras de seguridad y funciones de interoperabilidad, lo que mejora el soporte y compatibilidad con formatos como los que usa Microsoft Office.

LibreOffice 7.0.3 ya disponible para descargar

Como siempre, en este punto tenemos que recordar que TDF ofrece al menos dos opciones de su suite de ofimática: la más moderna está destinada a los que queremos las nuevas funciones sin pensar tanto en la productividad. Si necesitamos estabilidad, tenemos que quedarnos en la versión recomendada, que en estos momentos es LibreOffice 6.4.7. Esta serie no se recomendará para equipos de producción hasta por lo menos diciembre o enero, momento en el que lanzarán la v7.0.5 de la famosa suite de ofimática libre.

LibreOffice 7.0.3 ya se puede descargar desde la pagina web del autor, a la que podemos acceder desde este enlace. Desde allí, los usuarios de Linux podemos descargar paquetes DEB, RPM o el código/binarios. Los usuarios que tenemos instalada la versión que nos ofrece nuestra distribución Linux deberíamos poder actualizar en unos días, siempre y cuando ya estamos usando la v7 de la suite de ofimática. Si estáis usando un sistema como Manjaro o Arch Linux, para usar esta versión tenéis que desinstalar la versión que trae por defecto e instalar la del canal «Fresh».

from Linux Adictos https://ift.tt/3jG1axA
via IFTTT

Una vez liberada Ubuntu 20.10 Groovy Gorilla, los desarrolladores ponen manos a la obra en la siguiente versión. Aunque es muy pronto para saber cuales serán sus características finales (sobre todo estando Mark Shuttleworth de por medio, podemos sacar algunas conclusiones razonables sobre con qué podemos encontrarnos.

Acerca del hipopótamo peludo y sus características

El nombre

Es sabido que el nombre de cada distribución sigue un orden alfabético y que incluyen un adjetivo y un animal. Le tocó turno a la hache y ayer trascendió que el adjetivo elegido era   (peludo).

Para los fanáticos de las estadísticas mencionemos que es la tercera distribución que utiliza la letra H, la primera fue Hoary Hedgehog en el 2005 y la segunda fue Hardy Heron en el 2008 y tuvo soporte extendido.

El animal que va a acompañar al adjetivo peludo es nada menos que el hipopótamo; es decir que el nombre elegido es Hirsute Hippo.

El hipopótamo es un mamífero africano semiacuático de gran tamaño, piel gruesa, mandíbulas grandes, e impresionantes colmillos

Su nombre significa caballo de río en griego y pueden correr muy rápido en tierra hasta 30 km/h, y en agua  hasta 8 km/h. Siendo herbívoros, comen hasta 36 kilos de pasto por día y un macho adulto puede pesar hasta 4,5 toneladas.

Antes de que me acusen de poner estos datos para cumplir con el número mínimo de palabras que me pide Linux Adictos (¡Que nos conocemos!) les recuerdo que el animal y el adjetivo elegido para nombrar cada versión de Ubuntu intenta representar las características buscadas para la nueva versión.

Imagino que lo que van a buscar los responsables de Ubuntu es que la nueva versión sea más rápido en todos los entornos. Pero, si quieren hacer el chiste de que va a ser una distro pesada que consuma muchos recursos, ahí abajo tienen el formulario de comentarios.

Calendario de liberaciones.

El desarrollo de Ubuntu 21.04 Hirsute Hippo comenzará el próximo jueves 29 de octubre  y días después estarán disponibles las primeras imágenes que no variarán demasiado de la 20.10

El 1 de abril (Si, el día de los tontos de los anglosajones) se podrá descargar la primera beta, mientras que la versión final, si va todo bien, estará disponible el 22 del mismo mes.

Actualización de paquetes

A menos que a Shuttleworth se le ocurra volver a Unity o cambiar a KDE (Ojalá Dios lea Linux Adictos) el escritorio de la versión principal será GNOME 3.40 que será liberada en marzo del año que viene. Probablemente, la versión del núcleo Linux lleve el número 5.11. La versión de Python incluida podría ser la 3.39.

Paquetes Snap más rápidos

Si en algo coincidimos todos es que los programas que utilizan el formato de paquetes Snap son muy lentos en arrancar. Con suerte, esto puede cambiar.

Los desarrolladores están probando el uso de un nuevo algoritmo de compresión para los Snap que ofrecen una mejora de entre dos y tres veces en los tiempos de inicio de las aplicaciones.

Por defecto, los Snap se empaquetan como un sistema de archivos squashfs comprimido y de sólo lectura usando el algoritmo XZ. Esto da como resultado un alto nivel de compresión pero, que requiere más potencia de procesamiento para descomprimir y expandir el sistema de archivos para su uso. De ahí la lentitud que tarda la aplicación en arrancar. Esto también se nota mucho más sólo en el primer lanzamiento, antes de que los datos de la aplicación se almacenen en la memoria. Los lanzamientos siguientes esto ya no se nota tanto.

Para mejorar los tiempos de inicio, se decidió utilizar un algoritmo diferente – LZO – que ofrece una menor compresión, pero necesita menos potencia de procesamiento para completar la acción. Además tiene un mayor nivel de compatibilidad con los diferentes escenarios de uso de los paquetes Snap.

Las primeras pruebas se hicieron con el navegador Chromium y dieron los siguientes resultados:

• El snap comprimido con el algorimto XZ pesa 150 MB, mientras que el que usa la compresión LZO tiene un tamaño de 250
• El Snap que usa el algoritmo de compresión LZO ofrece entre un 40 y un 74% de mejoras en el arranque en frío sobre el que usa la compresión XZ.
• En Kubuntu 18.04 El paquete con formato LZO tarda en arrancar casi el mismo tiempo que el instalado desde repositorios tradicionales.
• En Fedora 32 el paquete Snap con formato LZO fue más rápido que el paquete RPM de repositorios.

from Linux Adictos https://ift.tt/3jyVF3L
via IFTTT

No hace mucho NVIDIA hizo otro movimiento estratégico comprando Arm, con una serie de consecuencias. Positivas para la propia Graphzilla, y negativas para los que actualmente dependen de la tecnología del ecosistema ARM. Ahora ha sido AMD la que ha vuelto a hacer otro movimiento estratégico comprando Xilinx.

Y es que AMD está en su mejor momento, por eso ha aprovechado eso para pagar nada más y nada menos que 35.000 millones de dólares para hacerse con Xilinx y toda su cartera de productos y tecnología, especialmente importante la referente al 5G y a las FPGA.

Consecuencias positivas

En este caso no hay un impacto tan importante como en el caso de la compra de Arm por parte de NVIDA. Es cierto que los productos de Xilinx cuentan con multitud de clientes y empresas que también dependen de ello, pero en este caso existen algunas alternativas y, además, no tiene un impacto tan enorme como en el caso de ARM.

Evidentemente, AMD será el mayor beneficiado de esta compra, aunque podría implicar riesgo por la enorme cantidad de dinero que ha desembolsado. Algunos expertos auguran de que podría ser el fin de esta empresa, como el ex de Intel François Piednoël. Y es que, a pesar del buen momento de AMD, es demasiado dinero para las arcas de la compañía.

Todos recordarán lo sucedido cuando AMD compró ATI. Fue un movimiento clave, pero también es cierto que supuso un duro golpe para la fortaleza de AMD, y le costó bastante recuperarse de aquello. Es cierto que en aquel momento no era la misma AMD de la actualidad, pero habrá que ser cautos…

Como puedes comprobar, cada vez son más las fusiones de compañías. Las grandes necesitan cada vez más poder para poder competir en ciertos mercados clave, y eso responde a estas compras que se están sucediendo, como las de NVIDIA y Arm, o la anterior de Mellanox, y también ésta de AMD-Xilinx.

Intel, en cambio, no solo no está comprando, sino que están vendiendo su división de memoria flash a SK Hynix por 9.000 millones de dólares. Y no precisamente porque necesiten dinero, ya que sus cuentas están saneadas, sino porque no son competitivos en ese sector y se deshacen de su negocio de NAND flash (sus memorias Intel Optane pasan a manos chinas).

Intel se queda así con un negocio aún poderoso en cuanto a CPUs, y con una apuesta en GPUs con sus Intel Xe que aún está bastante verde y que no puede competir con AMD y NVIDIA por ahora. La situación de Chipzilla no es demasiado buena, habrá que esperar a ver si se hacen movimientos dentro de ella para revertir la situación.

Pero si no logran reaccionar, NVIDIA es una gran amenaza ahora que tiene todo para triunfar en el sector de GPUs siendo el líder actual, y también ahora las herramientas para hacerlo en el sector de las redes (con Mellanox) y las CPUs (con Arm), lo que la posiciona como una candidata a dominar el sector HPC.

AMD por su parte podrá contar ahora con tecnología móvil 5G de Xilinx para, quizás atacar también el sector de la movilidad (recordemos que erraron al vender su división de gráficos para móviles a Qualcomm, lo que se ha transformado ahora en las poderosas gráficas Adreno… ), por ejemplo, contra NVIDIA SmartNICs y contra el 5G de Intel.

También obtiene en su portafolio de productos las poderosas FPGAs de Xilinx, con las que poder incluir aceleradores específicos para ciertas tareas, los Adaptative SoC junto a sus EPYC, lo que podría ser una ventaja también en HPC. Recuerda que Intel también adquirió el negocio de FPGAs de Altera en 2015, por lo que podrá competir con es, con la diferencia de que Altera era un grande de los FPGA, pero Xilinx es líder en este sentido… La apuesta de AMD ha sido más fuerte.

La computación heterogénea es el futuro, usar procesadores específicos para ejecutar las tareas de la forma más rápida y eficiente posible. No tiene mucho sentido usar CPUs de propósito general para todo. Ya lo han demostrado las GPGPUs, pero también otros aceleradores específicos, como los de IA. Eso es el presente y futuro para los centros de datos…

Y por supuesto, cuenta con buena salud en cuanto a sus GPUs. Aunque no estén a los niveles de dominio de NVIDIA, pero les pueden hacer gran daño, y por el momento están muy por delante de Intel.

¿Consecuencias negativas?

Lo cierto es que aún no se conocen demasiados detalles del acuerdo de AMD y Xilinx, pero ante tal desembolso de dinero, es probable que sigan con todo el portafolio de productos de Xilinx adelante para obtener ganancias de ese sector. Intel lo ha hecho con los productos de Altera, que ahora ha continuado. Así que todo indicaría a que AMD también seguirá, y no cancelará ningún producto de los que ahora tiene Xilinx.

Lo que sí hará es usarlos en su beneficio, pero eso no debería preocupar demasiado a todos los actuales clientes de Xilinx. Además, las licencias no cambiarían como se temía en el caso de Arm.

Altera era la segunda en discordia y es propiedad de Intel. El líder Xilinx ahora lo será de AMD. Ya quedan pocas compañías en el negocio de las FPGAs que sean grandes. Algunos ejemplos son Lattice Semiconductor, Microsemi, y QuickLogic.

El que sí podría tenerlo más complicado es NVIDIA, el competidor directo de AMD. Ya que sus productos Mellanox de redes usan FPGAs de Xilinx para el diseño de sus interconexiones de alta velocidad. ¿Ahora seguirá manteniendo este trato con NVIDIA sabiendo que son competidores? Puede que AMD no tenga ningún deseo de surtir de tecnología a su competidor, por lo que NVIDIA tendría un serio problema.

Algunos expertos aseguran que no tendría mucho sentido retirar esta tecnología, ya que NVIDIA también puede ayudar a AMD en el sentido de que es un gran cliente que le aportará ganancias. Lo que sí pueden hacer es usar Xilinx en beneficio propio para su pila de red Ethernet completa de alta velocidad, y poder lanzar un producto competidor de la tecnología NVIDIA.

from Linux Adictos https://ift.tt/34BC0fh
via IFTTT

Desde que mi mentor me convenciera de pasarme a Linux por allá 2005, conocía su existencia desde 2002, he probado muchas distribuciones, pero las que más me han gustado siempre han estado basadas en Ubuntu. Así, he estado usando principalmente el sistema de Canonical hasta principios del año pasado, cuando vi que Plasma funcionaba mucho mejor que en el pasado y decidí pasarme a Kubuntu. Pero recientemente he estado «jugando» con Manjaro y decidí volver a cambiar… pero no lo hice.

¿Por qué? Y, ¿por qué había pensado hacerlo? Eso es lo que voy a tratar de explicar aquí, pero dejando claro que hablo de mi experiencia personal en el presente. Ambas me parecen grandes opciones, y de hecho uso Manjaro en mi Raspberry Pi y la versión xfce-usb en mi portátil más viejo, pero me he quedado en Kubuntu en mi equipo principal por un par de razones: estabilidad y porque la comunidad e información existente es mucho más extensa.

Por qué me planteé abandonar Kubuntu…

La historia viene de largo. Aunque ya conocía su filosofía, mi compañero Diego consiguió llamar un poco más mi atención con su artículo del año pasado. Y es que Kubuntu, como el resto de sabores de Ubuntu, lanza una nueva versión cada seis meses, y actualiza muchas aplicaciones con mucho retraso. Como ejemplo, la versión de GIMP de Groovy Gorilla sigue siendo la v2.10.18, cuando la de los repositorios de Manjaro está en la v2.10.20 y seguramente se actualice a la última mucho antes que la de X-buntu.

Pero lo que me pareció más grave fue que Kubuntu 20.04 se quedara en Plasma 5.18 porque requería una versión más actualizada de Qt y KDE no haría el «backport», algo que no pasa en una distribución como Manjaro por ser Rolling Release. De hecho, mi Raspberry Pi se acaba de actualizar a Plasma 5.20.1 y mi portátil principal con el Backports PPA sigue en el Plasma 5.19.5 con el que ha llegado Groovy Gorilla. Y así con todo.

Repositorios de Manjaro vs. Repositorios de Kubuntu

Pamac en Manjaro Xfce

Aún más, en mis pruebas, tanto en xfce-usb (desde donde escribo este artículo en un portátil que es un poco tartana) como en la Raspberry Pi con Manjaro ARM en su edición KDE, he podido examinar bien AUR, y algo así es lo que hecho de menos en los sistemas operativos basados en Ubuntu. AUR es Arch User Repository, y la comunidad mete ahí prácticamente todo el software existente. Se llega a decir que, si no está en AUR, no existe para Linux, y el Pamac de Manjaro lo compila todo por nosotros. Allí podemos encontrar, por ejemplo, navegadores web como Vivaldi o Brave, lo que también me recuerda que los repositorios de Manjaro tienen disponible una versión de Chromium libre de snapd. Y no, añadir repositorios de terceros ni se acerca a ser lo mismo.

No deja de ser importante algo que sabía que podía pasar y comprobé ayer mismo: mi portátil con Manjaro saca vídeo y audio vía HDMI, algo que no me pasa con Kubuntu (de hecho, tampoco en mi instalación con Windows). Me llegó a pasar por la cabeza que fuera por el kernel que usa y, sea así o no, eso nos lleva a otro tema: Manjaro tiene una herramienta para usar el kernel que mejor nos parezca, y ahora mismo estoy en Linux 5.9.

… y por qué no lo hice

Cuando ya estaba casi decidido, me di cuenta de algunas cosas. De repente, me daba error al entrar en algunas páginas, como el Numbers de Apple (tengo que usar una hoja allí), lo que me hizo comprobar también el resto de opciones y iCloud Drive tampoco funcionaba. Viendo que tenía un problema, busqué por la red si a alguien más le pasaba, y lo que encontré fueron grillos cantando (cri cri… cri cri…). Eso me hizo leer más, mucho más, para ver como la comunidad decía justamente eso: «a veces tendrás un problema y serás el primero en experimentarlo», no habrá información al respecto. Y por si os lo estáis preguntando, el fallo al entrar en ciertas webs con Firefox me pasaba también en el resto de navegadores, como Chrome, Chromium y Vivaldi.

Lo peor fue leer a los usuarios que aseguran que las actualizaciones tan rápidas por parte de algún software hace que cosas que funcionaban dejan de hacerlo hasta que lo reparan. Así que tomé una decisión, por lo menos temporal: en mi ordenador principal, voy a tener un poco de paciencia con las actualizaciones, pero voy a tener un equipo más estable. Siendo alguien que se mueve mucho, probablemente en el futuro me pase a Manjaro, pero volveré a Kubuntu si veo que me encuentro con problemas. De hecho, es un camino que he leído que han hecho muchos, pero probablemente en el futuro sea diferente.

from Linux Adictos https://ift.tt/3mpQUeo
via IFTTT