En un hecho casi sin precedentes y que me llena de orgullo y satisfacción, las principales distribuciones GNU/Linux y multitud de proyectos ligados al software libre se han puesto de acuerdo en algo: nada menos que en adoptar y colaborar en el desarrollo de los paquetes snaps, algo que sin duda contribuirá a reducir la fragmentacíon que siempre ha rodeado al sistema del pingüino y el ñu.
Entre los contribuidores figuran Dell, Samsung, The Linux Foundation, The Document Foundation (que desarrolla LibreOffice), Krita, Mycroft, Horizon Computing y distribuciones GNU/Linux como Arch, Debian, OpenWrt, y Ubuntu.
En estos momentos los formatos snaps estarían trabajando de forma nativa en Arch Linux, Debian, Fedora, Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu MATE, Ubuntu Unity y Xubuntu. Mientras tanto se están realizando progresos para su uso en CentOS, Elementary, Gentoo, Mint, OpenSUSE, OpenWrt y RHEL (Red Hat Enterprise Linux).
Aquí siempre nos gusta probar las cosas (¿sino donde esta la maldita gracia?), así que he cogido mi Antergos y he instalado snapd desde AUR, lo que nos permitirá manejar este nuevo formato:
yaourt -S snapd
A continuación he probado a instalar krita directamente de la tienda de aplicaciones de Ubuntu (en un futuro, un repositorio común e independiente para todas las distros quizás fuera mejor, ¿no creéis?)
sudo snap install krita
con satisfactorios resultados, como podéis ver en la imagen del post.
Todavía no tengo mucha idea como funcionan esto de los snaps (es mi primerita vez), pero dado que por el menú de GNOME no me aparecía nada de Krita, encontré un ejecutable en la nueva carpeta snap creada en el directorio raíz, para salir del paso:
/snap/bin/krita
y bueno, para eliminar la aplicación basta con un:
sudo snap remove krita
Ya pero…¿Que diablos es esto de snaps?
Recordar que estamos hablando de un sistema de paquetes autocontenido en cuanto a las dependencias (es de esperar que utilizando algún sistema de deduplicación que permita ahorrar espacio).
Una vez implementado tirando de sandboxing y combinado –en un futuro– con otros elementos como los protocolos de servidor gráfico Wayland/Mir, deberían proporcionar mayor seguridad, al estar aislados del resto del sistema.
La ventaja para los creadores de software y empaquetadores es otro de los puntos fuertes de snap, al no tener que lidiar con diferentes versiones de bibliotecas del sistema base, conflictos con otros paquetes o formas de empaquetado distintas para cada distro.
Se les va a simplificar el trabajo a la hora de mantener sus programas y también a los usuarios a la hora de recibir las actualizaciones verificadas directamente upstream. Pudiendo tener sus aplicaciones favoritas a la última o utilizar diferentes versiones de la misma, aunque estén utilizando una LTS con unos añitos de antigüedad.
Las snaps no significan el adiós (por lo menos inmediato) de binarios RPM o DEB, ambos podrán coexistir en el mismo sistema. Otras soluciones similares como las AppImages o el sistema de paquetes FlatPak desarrollado por GNOME también se pueden constituir en alternativa.
Tenéis más información sobre este tema y declaraciones de personajes relevantes pertenecientes a los diferentes proyectos implicados, en Ubuntu Insights.
SI!! JODER SI!
ahora que pasa con xdg-apps y appimage?
Respecto a Flatpak (antes conocido como xdg-app), no pasa nada, flatpak sigue existiendo y para este verano se espera que implementen los primeros portales para añadir seguridad [1].
Flatpak tiene desde su creación un plan para usar de forma segura las aplicaciones, el llamado «sandboxing». La seguridad en flatpak se consigue mediante los llamados portales, que permite el acceso de las aplicaciones a los recursos del sistema de forma controlada.
Por cierto, si usas X, es imposible asegurar una aplicación maliciosa no haga de las suyas, ya que X es inseguro.
[1] https://blogs.gnome.org/mclasen/2016/06/14/dispatches-from-the-gtk-hackfest/
@juanjo Cierto, hasta que funcione waylando o mir, tiene la misma seguridad que cualquier otra aplicación en Linux. Ni mejor ni peor.
Todo esto está muy bien y es un paso mas. Ojalá que en un tiempo, mas próximo que tarde, se puede probar y testear un hardware propio a fin de verificar el mas apropiado para la confección de ordenadores GNU/Linux y mandar a freír espárragos al monopolio, y al mismo tiempo que estos ordenadores además de buena calidad sean duraderos.
Lo del hardware es un problema gordo. Al final de poco sirve usar software libre, si Intel te mete un firmware cerrado que te puede monotorizar o cualquier otra cosa.
Al fin buenas noticias para Linux. Mierda de fragmentación. Esto ya era necesario desde hace siglos .
Me sorprende (para bien) que tantos proyectos y distros se hayan puesto de acuerdo…
Yo no he leído que a ninguna distro pronunciarse a favor de snap, solo se que debian lo implemento en sid(Y que canonical a tomado todos los software que encontró y los hizo snap). Por otro lado tmb se que RedHat y familia va por Flatpak(xdg-apps que existe desde antes y a estado a la espera del lanzamiento de wayland, fedora 25 lanza wayland por defecto). Ademas la mayoría va por wayland. Snap va hacia mir(por ahora,no se si va por wayland. Ahora snap se desvió de mir y se implemento en xorg, yo supongo que por la presión de seguir siendo relevante). Otro dato interesante es que ubuntu plantea ser una ubuntu store para todas las distros y plantea hacer cobros para que distribuyan software desde la ubuntustore(A empresas si, a usuarios no se). Se que se puede instalar snap de manera manual(cualquier paquete deb,rpm,etc) pero seguro habrá una gran critica a hacerlo, pues tildaran de que sera inseguro instalar software fuera de la ubuntustore. Algo interesante Snappy Ubuntu Core esta plagado de «ubuntu» en su código y como sabemos ubuntu declara que es una palabra con licencia y no se puede copiar.
Seguro habrá mas detalles en los próximos días, esto sera interesante.
Si, ademas el código del servidor de Snap es cerrado, así que la intención de Canonical es que haya una sola tienda, la de ellos
Algo bueno tambien es que un programa puede usar una versión diferente de una dependencia de otro. Por ejemplo Krita necesita X dependencia en version 2.3 …. y Gimp necesita la misma pero en otra version …
snap ya se puede instalar en ubuntu ?
Snap ya está en Ubuntu desde la propia salida de 16.04 Xenial, viene instalado por defecto.
@tannhausser, ya te has lanzado «¿qué tal un repositrio común?». Bueno, eso sería la bomba. Y ya que estamos: ¿por qué no una distribución común?
Eso sería demasiado para el cuerpo, no se si lo resistiríamos.
Lo del repositorio o tienda común se me ocurrió porque me parecía raro estar en antergos descargándome algo de la store de Ubuntu (o como se llame)
La FSF ha respondido a dichas preguntas con GuixSD y el gestor de paquetes Guix.
A mí, en principio, me parece muy buena noticia.
Otra cosa son los dichosos problemas de seguridad de x11. Y siempre que se relaciona este problema con los paquetes snap me queda la duda de si el famoso problema de sólo es un riesgo para los paquetes snap, o si es un riesgo en si, que afecta al sistema con independencia del tipo de paquetería que usemos… Nunca nadie me ha aclarado esto.
Pero la idea me parece muy, muy buena, con las dos salvedades que menciona el propio tannhausser:
-Estaría bien que las dependencias ya instaladas en el sistema base no ocupasen espacio en la instalación del snap. Obviamente, si eliminásemos la dependencia de marras la aplicación instalada con el paquete snap debería controlar esto para actualizarse con esa librería que antes non necesitaba.
-El repositorio común, que eso ya sería la leche!
Saludos!
Me respondo a mí mismo para contaros que, finalmente, he probado a instalar el snap de Krita en Ubuntu 16.04 desde Ubuntu Software. Y se instaló rapidito y bien, pero al ejecutarlo he tenido algún problemita que os cuento.
Igual es porque mi sistema está en gallego, pero Krita se ha quedado en inglés y de ahí no se mueve. He probado a ejecutar el gestor de idiomas y ofreció descargar los paquetes de idioma de KDE. Así que pensé que ya estaría hecho, reinicié, por si acaso, pero nada, y no es que no se pueda cambiar el idioma, es que Krita solo me ofrece inglés americano.
Vamos, que, o tiene que ver con el hecho de que mi sistema esté en gallego (que tampoco sería escusa porque el español es el segundo idioma en el orden de preferencias), o es que este snap no resuelve satisfactoriamente el tema del idioma.
Por lo demás, no he visto ninguna otra cosa rara.
Espero que estas cosas se vayan resolviendo con el tiempo.
Y me vuelvo a responder después de leer las notas del snap de Krital. Aunque en inglés, están ahí.
Por lo que se ve, no es que no funcionen bien las traducciones, es que no existen según esta nota:
Notes: no translations are available yet, and due to a bug in Ubuntu, this snap doesn’t work with proprietary video drivers, e.g. for NVidia.
Si lo he entendido bien, también hay problemas con drivers nVidia.
No me malinterpreten, yo también deseo la unificación de los binarios de las aplicaciones de GNU/Linux, pero ya me parecía que ayer el tema se había tocado con mucho bombo y platillo y se había exagerado este anuncio de parte de Ubuntu, al menos eso me pareció cuando en el subreddit de Linux se abrieron 3 o 4 tópicos sobre el mismo tema. Ayer mismo, quise probar en mis 3 distros actuales (Linux Mint 18 Beta, Debian Testing y Arch Linux) los mentados snaps y mi experiencia como usuario final no es muy satisfactoria, por decir lo menos:
1) Los snaps funcionan, al fin y al cabo… cuando funcionan.
2) En Debian sólo fue cuestión de jalar desde el repositorio de sid (aunque estoy en testing) el paquete snapd (sudo apt -t testing snapd). El paquete advierte sobre la replicación de binarios en /usr/bin/snap, ya que existe un programa de análisis genético que usa el mismo nombre. Más allá de eso, instalar una aplicación fue sencillo y funcionó, pero los repos estaban lentos. En Arch, es un paquete del AUR, lo cual le quita lo oficial (si fuera oficial estaría en «extra» o al menos «community») y compila, pero no encontraba aplicaciones en el repositorio (me mandaba un handshake out of time o algo así). Lo más curioso fue que en Linux Mint ni siquiera pude encontrar el paquete «snapd» en los repos, lo cual fue de plano increíble. No sé si estoy usando un mirror algo mal sincronizado o qué, pero apt sugiere que snapd existe dentro de otro paquete «ubuntu-core-snappy», cuando otros usuarios de Xenial dicen que existe el paquete «snapd». Pero bueno, es beta…
3) Hoy, Michael Larabel, de Phoronix, publicó un artículo sobre su experiencia usando snaps ayer, en Fedora. Él pudo hacerlos funcionar (al igual que yo en Debian), sin embargo menciona varios problemas. En primer lugar, hay que deshabilitar la seguridad que ofrece SELinux, habilitada por default en Fedora; en segundo lugar, que algunos snaps son muy grandes (el snap de LibreOffice es cuatro veces más grande que cualquier instalador DEB, EXE o como se llame el de MacOS, es decir, más de 1 GB de descarga, sumado a mi problema de velocidad de los repositorios…), en segundo lugar es que parecen estar compilados para Ubuntu y, por ejemplo, los menúes de LibreOffice no aparecen en la UI (reconocer que se trata de un snap beta, sí) y finalmente, que los snaps son difíciles de «debuggear» pues mandan mensajes confusos en la consola.
4) Finalmente, me molesta la idea de iniciar sesión en una tienda de snaps para instalarlas. Usando privilegios administrativos no es necesario, pero aún así, es algo que preferiría no hacer como usuario. Sobre Arch, me parece que lo compilé antes que tú tanhausser y tuve problemas con una dependencia de snapd (snap-contain… algo así), yaourt me informaba que hubo dependencias que no pudieron compilarse, pero en realidad el paquete sí se compilaba y era instalado por pacman… algo raro.
En fin, esto apenas comienza, pero hay que ver cuál es la respuesta de flatpak, ya que según Michael Larabel, en Fedora están respaldando plenamente a este proyecto que espero se encuentre en un estado menos beta. Él está decantado ahora por flatpak, yo leí un día pasado que la compresión de los snaps usa el algoritmo ZIP, lo cual es francamente mediocre en términos de eficiencia, aunque rápido de descomprimir y usar para aplicaciones, ¿quizá de aquí viene el tamaño pesado de los snaps? No lo sé, como dije antes, hay que darle tiempo y creo que es importante no adelantar vísperas con el anuncio un tanto halagüeño del tipo «al fin un binario universal para GNU/Linux».
Es posible que fuera snap-confine esa dependencia que mencionas. Te comento que yo no tuve problemas con yaourt. Además instaló (o accedió si ya estaban ) otras dependencias como squashfs-tools, go, y go-tools.
Gracias, tannhauser. Hoy pude hacer el build a partir del AUR y además, el problema en Mint era con un repositorio espejo que no se había sincronizado con el repositorio oficial y que no estaba incluyendo el paquete snapd. Hoy he podido correr «snap install» en las tres distros (Mint, Debian y Arch Linux) sin problema alguno. Sin embargo, la discusión respecto a los paquetes snap sigue y se ha diversificado ya bastante, sobre todo siguiendo el tema en reddit.
A mí me parece un golpe mediático el anuncio hecho con respecto a la universalidad de los paquetes snap, sobre todo en el sentido de cómo lo ha abrazado la comunidad FOSS. Canonical aprovecha la posición de Ubuntu como distro preferida, pero ciertamente, flatpak está soportada oficialmente por varias distros importantes y posiblemente sea una mejor solución a largo plazo y una vez más un punto de divergencia con respecto a Ubuntu.
Bueno, proviniendo de ubuntu no creo que sean muy estables los snaps; la idea es buena pero desconozco cual es su sistema de empaquetado. Creo que la mejor forma de que un programa funcione entre distros son los builds. Hace poco me imaginaba que un determinado paquete se compilara y funcionara en cualquier arquitectura de procesador AMD64, X86 (incluyendo sus sub-arquitecturas) alpha, arm, hppa, ia64, ppc, sparc…etc eso si sería unificación
Mira un ejemplo claro son los juegos en Linux, un problema común cuando crean un sh cómo el del torchlight, el juego falla porque el sdl usado en los sistemas actuales no funciona bien y hay que extraer el sdl del paquete original del juego para que cargue, este tipo de cosas se habrian solucionado con paquetes snap, es un gran proyecto y si ya se crea un mega repositorio a lo Aur, tendríamos un sistema universal y potente sistema de archivos.
¿Pero el comando snap en si no es el repositorio global que mencionas? Por lo menos viendo la fuente colocan un enlace con las guias para crear los paquetes snap y mencionan algo sobre una “global snap store”. Enlace: http://snapcraft.io/
Tengo que leerlo con mas cuidado pero a simple vista parece algo como ese repo global que mencionas.
Cuando ejecuté el comando para instalar krita, enlazaba con la ubuntu store para descargar el programa.
En esa página que comentas el procedimiento es algo distinto, porque sugiere que hay que loguearse antes para acceder a esa global store (demasiado rollo me parece).
Pero ya te digo, es la primera vez que instalo un paquete snap y tan solo pretendía saber si funcionaba en Arch y derivadas.
A todo esto gracias por el enlace, trae información interesante sobre como hacerlo funcionar en varios distros.
Voy a pegar un texto que escribió el señor Ikey Doherty (creador y desarrollador de la distro Solus):
NOTA: el texto original esta en ingles, yo solo traduje al español para que se pueda entender, por favor leer completo.
Ikey: «Por favor, dejar de preguntar sobre, las solicitudes de comparación de, o la inclusión de Ubuntu, broches de presión (Snap)
Objetivo..
Ubuntu conectores están diseñados específicamente para aliviar los problemas que Solus no tiene. Si necesita más pruebas, leer cómo muchas citas se refieren específicamente a los paquetes de Debian. Solus no está basada en Debian, y es realmente muy fácil de construir paquetes para Solus. Este es un tema en el ecosistema Ubuntu, no la nuestra.
Problema
Se recuerda que el almacén principal es propiedad de Canonical, y la propietaria de back-end.
Concepto
Es esencialmente el mismo que el Chakra Lotes.
Tecnología inferiores
Desde una perspectiva de embalaje, Snap son más débiles que nuestra propia ypkg, por lo que no tenemos ninguna razón para adoptar basado en el valor técnico. ypkg ha avanzado modelado y la división automática de paquetes que, en conjunción con eopkg, proporcionan gráficos de dependencia de autoconstrucción.
También tenemos un soporte especializado para la construcción de paquetes multilib simplemente permitiendo la tecla emul32 o edificio con la optimización del perfil guiada mediante el paso de perfil, o un edificio con plena LTO utilizando la opción de optimizar la velocidad …. Podemos usar globos simples para crear automáticamente subpaquetes con la correcta inter-paquete y dependencias de pase binarios con una política de retorno para rellenar los sub-paquetes predeterminados a través de una política de estratificación …. etc ….
También tenga en cuenta que nuestro propio formato es YAML, y aprovecha toda la potencia de un archivo declarativa y estructurado. El uso de Snap es más parecido a un documento JSON simple en términos de estructura.
La confianza de la cadena del sistema operativo
Los paquetes proporcionados por Solus están implícitamente confianza, ya que son proporcionado por el proveedor. No hay problema de confianza, ya que no están siendo descargados de sitios web al azar (.exe …) – es decir, que no necesitamos, ya sea caja de arena.
código Aportes
El código base Snap nos obliga a firmar un acuerdo de licencia para colaboradores con Canonical, por lo tanto, no es verdaderamente libre.
Integración
Solus se enorgullece de ofrecer un sistema bien integrado. Estamos a favor de la calidad. Por lo tanto todos los paquetes proporcionados son probados, y nos aseguramos de que encajan completamente con la visión Solus y la experiencia del usuario.
Actuación
Solus se enorgullece de ser un sistema operativo de escritorio de alto rendimiento. Tenemos especial cuidado en la construcción de nuestros tiempos de ejecución, por lo tanto aleatorios bibliotecas-de-internet son totalmente fuera de la cuestión.
También tenga en cuenta que los broches de presión son de hecho imágenes SquashFS, por lo tanto afectada por la descompresión bloque transparente (La idea de que no hay penalidad es de risa.) Una vez más, este es exactamente el mismo concepto que el Chakra Lotes. En una nota técnica los soportes deben ser ocultados al sistema operativo anfitrión a través del uso de espacios de nombres, pero no parecen estar ..
Home Platform Computing
Este, es exactamente lo que es Solus. Así, todos los puntos de un sistema operativo que no sea genérica optimizado meta-construido para un solo vertical, con un estricto punto de vista de desarrollo hacia ningún conflicto, los proveedores individuales ABI, y una única arquitectura, nos deja libre y exento de problemas que afectan a otros sistemas .
Gracias por su tiempo en leer esto, espero que esto pone fin a la discusión.»
Traducido por vos o por Google Traductor? Jajajaja
La verdad que el post de Ikey me pareció una de las respuestas mas geniales de los que aún tenemos cordura 😀
AJAJAJAJAJAJA …. google traductor …
Déjame la fuente por favor (google translate) hay cosas que no entiendo en tu traducción y el tema es interesante.
Si realmente el traductor de Google no hizo muy bien su trabajo pero lo que se logra entender alli es barbaro
Por lo que entendí, si es que entendí lo traducido, me parece que esté Ikey tiene un poco de bronca y envidia porque aceptaron el nuevo paquete de Ubuntu y no el de ellos. Entiendo lo que plantea Doherty y lo comprendo, incluso creo que debería tomar nota Canonical y mejorar los paquetes a futuro, aunque veo resentimiento en sus declaraciones con un nivel narcisismo increíble
… narcisismo increíble hacía su propio hijo
No aceptaron el qué de ellos? Snap de Canonical e `ypkg` de Solus ni siquiera son la misma cosa, uno hace lo que ya sabemos y el otro es el programa que construye los paquetes de Solus. Ikey solo está comparando el proceso de construcción de los paquetes entre ambos… No entendiste nada 😛
Pues a mi me parece que no es mala idea pero es una mala opción. Como bien dicen por ahí se trata de crear paquetes que duplicarán archivos y consumirán esfuerzos y recursos para cada aplicación, abstrayendo al dueño de la máquina de la libertad de elegir ,en otras palabras, crear un sistema que al final nos hará esclavos tal y como lo son en MacOS. Todo el mundo lo apoya por que estandariza un modelo que a la larga supondrá la eliminación completa de la libertad del usuario , en pro de un modelo de negocio. Mientras pueda , no lo usaré.
Yo como usuario de Mac os comento que cuando quiero borrar una aplicación y eliminar además las dependencias sin dejar nada abandonado en el sistema uso AppZapper, la mecánica consiste en una ventana en la que hacer drag&drop arrastras dentro la aplicación que quieres eliminar y debajo de ella aparecen las dependencias y la ubicación de estas, haces click en el boton Zap! y suena un disparo en el que la aplicación y todos los archivos asociados a ella acaban en la papelera de reciclaje y tu ya una vez ahí decides si eliminar, recuperar o eliminar con otro software de borrado seguro por si eres muy paranoico.
Id pensando en un clon pingüinero de esto que os cuento porque imagino vuestras comunidades tirándose de los pelos por esta simpleza.
No se trata de quitar o añadir software, todo sistema de paquetes que yo conozca en linux permite eliminar una aplicación con sus dependencias. Se trata de distintas maneras en que los diferentes sistemas de gestión manejan las dependencias. Ahora que lo sabes vete a cobrar tus dividendos proporcionales a tu paquete accionario en Apple Inc. Porque un chico tan listo como tu no hace publicidad gratuita, no?
Gracias majo acabo de ganar una apuesta xDD
Genial! Un par de tragos gratis nunca vienen mal! Igual no creí que un simple comentario pudiera herir tu susceptibilidad como para soltar un mar de lágrimas en forma de tweets. Mis más sinceras disculpas. De todos modos, ten en cuenta que mi respuesta a tu valioso comentario fue puramente a título personal, no se a que te refieres con eso de las «comunidades», pero deberías relajarte un poco y dejar atrás los complejos y la paranoia.
Ahora parece que con esto nos bajaremos un paquete para linux y se instalará en todas las distros, parece un buen punto.
Pero ¿porque cuando salió fatelf toda la comunidad criticaron a ryan por la idea?
La gente no se acostumbra a cambios tan abruptos, y encima suele no contribuir con mejoras.
Esta verde aún. La idea es buena pero para sustituir apt, yum, etc., falta hacer ajustes. De momento en la prueba que realicé en kubuntu (haciendo precisamente un snap install krita), kde si integró la aplicación al menú (en aplicaciones > gráficos > krita) pero la aplicación no se integra en idioma y aspecto…supuse que como está autocontenido en términos de dependencias también traería la traducción correspondiente pero no. Es solo un ejemplo, pero la sensación que me da aún es la misma de appimage: una plataforma que sirve para testear lo último pero que no termina de integrarse de conjunto al sistema para un flujo real de trabajo. Al final la última palabra la tendrán los desarrolladores, ellos decidirán el sistema que mejor se les adapte para empaquetar, y los usuarios dando preferencia a un sistema sobre otro a la hora de bajar e instalar apps (porque la coexistencia creo yo que durará hasta que uno se imponga sobre el otro). De todos modos sí surgiera un estándar de paquetería para todas las distros… that’d be great!
Que tema Linuxeros .. .Seguramente detrás de esto hay todo tipo de intensiones, algunas quizás no tan buenas .!
Lo realmente positivo es que gran parte del universo GNU / LINUX se aglutine en un mismo proyecto es un comienzo y todos los detalles seguramente se irán puliendo con el tiempo. Hoy Snap esta en fase Beta pero unificar de una vez por todas un método o paquete puede significar la llegada de software nuevo incluso juegos. Linux necesita su (punto exe) para avanzar.
No se si sera Snap pero la bola comenzó a rodar ………
Pido, disculpas. Estoy soberanamente cansado hoy. Quería hacer una consulta. Al usuario final, por ej. de una distro como Antergos (yo también uso antergos) qué beneficios obtiene??? digo, porque en arch hay todo… disculpa en serio por lo estúpida de la pregunta pero…….. saludos y gracias
Respuesta corta: muy pocos.
En una comunidad tan comprometida como la de Arch Linux, que apenas sale un software por minoritario que sea ya lo encuentras en AUR, en estos momentos suena superfluo todo esto de las snaps. Lo veo mas como algo puramente complementario.
Otra cosa diferente es si usas una Debian estable o alguna LTS de Ubuntu y te apetece tener lo último de algún programa (libreoffice sin ir más lejos) sin tocar la base del sistema o depender de PPA’s/backports mejor o peor mantenidos. Adicionalmente existen un montón de paquetes que carecen de mantenedor y esto podría ser una buena solución.
Existe un artículo de un mantenedor de paquetes en Arch Linux, que creo que te puede interesar. No estoy totalmente de acuerdo con él (en lo referente a la seguridad de los paquetes por ej.) pero es muy interesante de leer, y reivindica el papel que juegan las personas que empaquetan y mantienen los programas en las diferentes distros.
http://kmkeen.com/maintainers-matter/
…[ y que me llena de orgullo y satisfacción]…
No sé si mi idiosincrasia cínica ha notado la falta de un «smyle» tras esos palabros (… a la Deina y yo nos zhllena de ordgullo y shatisfacción… la shzopa eshztá fría).
Otra cosita:
«Aquí siempre nos gusta probar las cosas (¿*sino* donde esta la maldita gracia?»
Hay, hay; ahí el sino: «fatalidad, destino, hado, sino, fortuna, suerte».
Que levante el brazo quién jamás dejó sin espacio el «si no»… 🙂
En cuanto al tema de la publicación, debo manifestar mis dudas con tanta alegría manifiesta por la «convergencia» entre distros.
El sistema de paquetería es lo que es, con sus dependencias y sus no redundancias. Entramos en la era «smartphone» donde cada dos años hay que cambiar, de forma inexorable, el p*to aparato porque nos quedamos sin espacio en disco duro. Diréis: con el precio de los discos duros de hoy no hay excusa. Pero la hay: en cada disco duro puedo tener varias distros instaladas; y cada una con su sistema de dependencias entre paquetes. ¿Alargar hasta tropecientos gigas cada distro para albergar esos «snaps»?. No gracias. La convergencia, caso de ser necesaria (en mi caso es un *NO* rotundo) debería pasar por una confluencia de paquetería entre distros. Y eso es más que improbable. Cuando mi compu no puede con Gnome (extensible a KDE), utilizo XFCE y tan ancho (y con compu por muchos años). En la variedad está el gusto (o era en colores?). Otra cosa es que a los desarrolladores les vaya mejor un sistema tipo «snap». A eso también añado mis objeciones, ya que en una compu muy viejuna con Debian el «Firefox» empaquetadoanda como el culo, me bajé el «tarball» (o como demonios se llame eso) de la güeb de Mozilla, lo desempaqueté en Descargas y a furrular (sin «make config, make install ni bobadas) con enlace al binario. ¿En serio hace falta un sistema de empaquetado tipo «snap»? Hay cosas más simples sin necesidad de pasar por una tienda de apps.
Sólo es una opinión más y abrazos a toda la comunidad.
Salud.
Gracias por la sugerencia @Carlos, pero me quedo con el «sino» todo junto que es conjunción adversativa.
Por cierto es «ay! ay! ay! andale andale arriba arriba iepa iepa» en vez de «hay, hay».
Un saludo de la Deina y Yo 🙂
Agradddezco a la Deina y a Udzted ;.) por el zasca en toda la boca. Como bien decía mi abuela: «estás más guapo calladito, calitos» 🙂
Perdón por mi metedura de pata. Se lo debo.
Nada hombre! tranquilo. Los «sinos» y los «porqués» siempre son motivo de discusión …al contrario, agradezco que me corrijáis las faltas que se me cuelan de vez en cuando.
Un saludo!