Llegan los paquetes universales a las distribuciones de Linux

Los paquetes Snap dan el salto para intentar convertirse en una solución universal al llegar a ArchLinux, Fedora y Gentoo.

[#3 ailian]

Pues, sinceramente, me parece una mierda. Es adoptar el sistema guarripé del OSX, con aplicaciones que ocupan un montón de memoria porque incluyen sus propias librerías, creando duplicidades innecesarias y consumo no solo de disco, si no de memoria a saco.

[#6 seif]

#3 Lo suyo sería que comprobará si tu sistema tiene en sus repositorios propio una versión compatible de la dependencia, y solo instalara la del paquete si no la encontrara. De todas formas yo he tenido problemas cuando he necesitado instalar algo y resulta que he tenido que compilar a mano varias dependencias porque no se encuentra en los repositorios oficiales debido al uso de una una versión antigua del SO.
Y actualizar no es una opción, usar paquetes sacados de servidores de terceros tampoco suele serlo, si existen, puede no ser seguro. Trabajo con servidores en producción por lo que tengo que actuar con mucho ojo.

[#7 ailian]

#6 La versionitis me parece un problema. rara vez necesitamos realmente la ultimísima versión de un programa.

Y también le facilita la vida a los creadores de troyanos, van a windowizar linux.

[#9 Trigonometrico]

#7 No estoy de acuerdo contigo en absoluto. Yo defiendo la versionitis a capa y espada. Pero para mi el problema es otro.



Lo que voy a decir no es una exigencia, es una opinión, porque de hecho yo soy un profano en el tema.
Está bien que los programadores de software libre saquen nuevas versiones de sus programas, pero en las nuevas versiones lo más importante no son las nuevas características de su software, es más importante todavía la optimización. Cada nueva versión, debería venir mejor optimizada que la anterior, y consumir menos recursos. Eso sería algo realmente beneficioso.


Pero, unos programas de software libre que cada vez consuman menos recursos también tienen un inconveniente importante. Esos programas serán usados como referencia y como base por las compañías de software privativo para hacer su software comercial, y eso nos perjudicaría en muchos casos, ya que un programa de software privativo que quiere sacar un gran beneficio económico, intentará hacer daño a su competidor libre (o privado), aunque ese software libre sea el que tenga el código sin el que el programa privativo no habría existido nunca.

[#20 Desactivado]

#9 hace unos años:
"Se descargaran 400 mb de actualizaciones. Se liberaran 25 mb de espacio en disco"

[#53 anv]

#20 No sólo hace unos años... Todavía es así muchas veces.

[#22 Desactivado]

#9 "discrepo": la optimización, a veces, implica meter una cantidad de horas muy grande para conseguir una mejora mínima. En cuanto a menos consumo de recursos, depende de si la nueva actualización hace más cosas que la anterior.

Un profesor mío (el mismo que el de mi comentario de ayer de las copias de seguridad) siempre nos decía que había dos maneras de hacer las cosas en un entorno de usuario: u ocupas memoria u ocupas procesador (vale, lo simplifiqué un tanto, pero esta era la idea)

[#55 anv]

#22 Lo que pasa es que los desarrolladores de software libre no están presionados para sacar nuevas versiones "vendibles" con mejoras "visibles" por el usuario.

Muchas veces un programador está pensando en los pajaritos y cae en la cuenta de que lo que hizo la semana pasada podría hacerse de otra manera mucho más sencilla y óptima. Si trabaja para una empresa comercial descarta esa idea y se pone a pensar en algo "vendible". Si hace software libre corre a optimizar su código para que la próxima versión que saque aunque parezca idéntica a la anterior funcione más rápido o consuma menos memoria.

[#76 Desactivado]

#55 en ese punto estamos de acuerdo, el software siempre está sujeto a mejora...hasta cierto punto en el que, sencillamente, no compensa.

[#78 anv]

#76 Un viejo dicho de programadores decía "un programa sólo está terminado cuando es obsoleto"...

[#80 Desactivado]

#78 me expliqué mal: hay veces que, en vez de optimizar, terminas antes rehaciendo

[#97 anv]

#80 Ah, sí. Una vez que has parchado y modificado muchas veces un programa, adquieres un conocimiento mucho más profundo de como deberías haberlo hecho desde el principio. Entonces es cuando empiezas a pensar que lo mejor sería hacerlo de nuevo.
Obviamente eso "no vende". Imagina que te dijeran: Compre el nuevo Office Super Plus. Hace exactamente lo mismo que antes pero lo hemos hecho de nuevo con toda la experiencia adquirida a lo largo de los años. Vende mucho más si es el mismo de siempre pero ahora tiene el nuevo menú mejorado y más cómodo.

[#101 Desactivado]

#97 mmmmnop. No hablo de un programa entero, hablo de trozos de código concretos: cuando lleves x iteraciones sobre el mismo código conseguir una mejora de rendimiento mínima puede costar mucho esfuerzo. En ese punto es mejor rehacer. Y desde luego nada de "programa nuevo", es una actualización

[#25 pawer13]

#9 Si usas una licencia GPL nadie podrá usar tu código en una aplicación privativa

[#42 Aokromes]

#25 Eso no es asi, una empresa puede coger tu codigo GPL y usarlo internamente y no distribuir los cambios, por que oficialmente "no distribuyen binarios"

[#116 Desactivado]

#42 Podrá usarlo internamente en una aplicación GPL, no en una privativa comercial.

[#104 Trigonometrico]

#25 La misma relación que hay entre Linux y UNIX se puede dar a la inversa. Creo que Unreal Tournament empezó usando el motor de Quake Arena, pero Unreal Tournament siempre fue software privativo.

[#30 Desactivado]

#7 tonterías.

[#63 geaplanet]

#3 #6 #8 #10
¿No habría alguna forma de hacer un programa extra para, si uno quiere, reducir del espacio malgastado por dependencias redundantes? Por ejemplo, uno que checkee todos los archivos y si son idénticos los sustituya por enlaces duros (por decir algo).

[#64 pip]

#63 claro que se puede, pero tiene una aplicación limitada. Por ejemplo, yo hice un programa que en el momento de liberarse, dependía de Pollo 2.3.1; Sin embargo la semana pasada descubrieron un bug de seguridad y fue corregido, liberándose como Pollo 2.3.2. Ya no es idéntico, con lo cual mi programa sigue usando la 2.3.1 que es la incluída en su "paquete universal para AMD64"...con su bug de seguridad por arreglar ¡¡!!

Dirías, hombre pero la 2.3.2 no cambia funcionalidad respecto a la 2.3.1, solo un parche de seguridad, así que la 2.3.2 te vale igualmente. Ya claro, ¡pero eso es precisamente lo que hace un gestor de paquetes normal!

[#71 geaplanet]

#64 Pues actualiza al "paquete universal para AMD64" con su Pollo 2.3.2. actualizado ¿Qué problema hay?

[#83 pip]

#71 el problema de que tengo que estar pendiente de las posibles actualizaciones de todas mis dependencias y si es necesario re-empaquetar y actualizar el mío. Prefiero dedicar el tiempo a mi programa y no a estar pendiente de los paquetes ajenos. Hablo desde el punto de vista de desarrollador de software libre, claro.
En realidad nada impide hacer ese empaquetado monolítico ya, con cualquier sistema de paquetes, pero si se hace como se hace es por lo que digo.

[#90 geaplanet]

#83 ? Me parece que eso es un problema totalmente ajeno a lo que estamos hablando y, dicho sea de paso, es algo que no tiene solución. Si para hacer un programa te basas en algo que no has hecho tú (una biblioteca externa) por cojones tendrás que revisar que todo funciona bien cuando actualices dicha biblioteca, de lo contrario ¿Cómo puedes asegurar que todo marchará correctamente? ¿Y si ha cambiado alguna función? ¿O la forma de llamarla? ¿O los parámetros que necesita?.... Pero eso, como digo, no tiene nada que ver con lo que estamos hablando porque es independiente de la paquetería, es algo a nivel de programa, no de distribución.

[#94 pip]

#90 para eso se pone versión mayor y menor. Se supone que la versión menor no cambia el API, solo arregla bugs, así que es seguro actualizar. Eso lo decide el programador, si la política de versionado de esa dependencia le parece de correcta o no.
Como digo nadie obliga a nada en un sistema de paquetes normal, tu puedes incluso hacer un enlazado estático y punto, ni dependencia ni nada, pero en general es más ventajoso enlazar dinámico requiriendo solo la versión mayor.

[#8 Desactivado]

#3 No se snap, pero flatpack incluye un sistema de dependencias propio, que permite a varios paquetes compartir conjuntos de bibliotecas comunes. Por ejemplo, todas las aplicaciones GTK compartirían la biblioteca GTK y GLib. Y otras.

[#12 sechole]

#8 Flatpack usa OStree para evitar librerías duplicadas
https://ostree.readthedocs.io/en/latest/

[#10 pip]

#3 estoy contigo. Añadiría que los desarrolladores de software libre no tenemos esa necesidad, es más, sería raro porque un programa puede depender de muchas librerías y muy gordas, y no vas a hacer compilar al usuario todas tus dependencias. Yo soy de los que defienden que el auténtico método de distribución del software es en fuente, no en binario.

Estos paquetes vienen a enguarrar el sistema y hacerle la vida mas fácil a los desarrolladores de software propietario.

[#93 Nova6K0]

#10 Yo soy de los que defienden que el auténtico método de distribución del software es en fuente, no en binario.

Pués esa es una de las razones de porqué el usuario amateur o aficionado no se pone alguna distribución de Linux. Eso y porque automáticamente dependes de la consola para compilar.

Por cierto, respeto al hardware que hay ahora y lo que ocupan muchas aplicaciones, así como los recursos que gastan, poca optimización veo.

Salu2

[#17 sechole]

#3 Te invito a que leas un poco de documentación. Si bien todavía no hay un estandar, todos tienen un metodo para evitar la duplicación de librerías.
Diría que appimage, flatpack o snappy son una evolución de los paquetes de OSX.
Aca hay una entrada de Diego Calleja explicando un poco en lenguaje humano de que se trata:
http://diegocg.blogspot.com.ar/2015/02/snappy-ubuntu-core-una-manera-diferente.html

[#52 ailian]

#17 Pues más o menos lo que imaginaba, se pierde la ventaja de compartir librerías; menos eficiencia en el consumo de memoria tanto RAM como de disco. La única "ventaja" que se vislumbra, aparte de la cacareada verionitis (de verdad, que estupidez enorme querer siempre tener la última versión de algo), es la facilidad en revertir cambios. Ahora, se "gana" complejidad en el arranque del sistema, algo en mi opinión que es caldo de cultivo para errores y ralentizamiento del arranque.

Sigo sin ver que mejore a un sistema super eficiente como apt. ¿La universalidad de las aplicaciones? Bastaría que todas las distros adoptasen apt. Si incluso con el mismo sitema de Debian puedes satisfacer tu versionitis sin problemas sabiendolo configurar.

[#106 sechole]

#52 Es que esto es para casos concretos. vamos a poner un ejemplo, soy desarrollador y quiero distribuir mi aplicación por mi cuenta pero no incluirlo en ningún repositorio. Esta es la forma mas fácil de hacerlo.
Nadie dice que te vayan a sacar apt o que otras distros vayan a adoptar apt que no tienen porque hacerlo.
Y no, no se puede satisfacer la versionitis, siempre hay alguna librería concreta, versión concreta que no esta en los repositorios y tenes que bajartela y compilarla y luego resulta que también tienes que bajar otra porque depende de esta y compilarla. Te lo digo por experiencia porque me ha pasado.
Con esto, lo bajas, lo instalas y lo usas, punto. Complejidad en el arranque del sistema? Que tiene que ver el arranque del sistema con esto?
Para verificar el consumo de RAM bastaría hacer la prueba de arrancar un paquete autocontenido instalado contra uno instalado a través de repositorios a ver que sucede.

[#23 Desactivado]

#3 como si la memoria o discos fueran escasos en estos tiempos.

[#44 Desactivado]

#23 Por un lado es cierto que no son escasos, por otro lado la tendencia es intentar hacer los sistemas mas ligeros, sobre todo por los dispositivos móviles, fíjate que desde Windows Vista no han crecido los requisitos de ningún windows

[#29 Desactivado]

#3 a sí, el tema de compartir librerías en debían.

Instalas algo, se actualizan y algo va a la mierda.

Casi prefiero cada cosa con lo suyo.

[#67 ailian]

#29 Todos los sistemas linux comparten librerias, cuñaaao.

Lo de que actualizas y algo se va a la mierda, cuñao doble.

[#31 Zade]

#3 Si pones en una balanza los pros y los contras de cada sistema, gana de largo el "guarripé" del OSX. Esa optimización prematura (que en programación es un antipatrón) de Linux, trae en la práctica y en la mayoría de los casos muy pocos beneficios reales.

[#32 Sheldon_Cooper]

#3, por probar acabo de intentar instalar el hello world en Snap

$ snap find hello
Name Version Developer Notes Summary
hello 2.10 canonical - GNU Hello, the "hello world" snap
hello-unity 0.4-snap7 mhall119 - Unity APIs demonstration tool
hello-world 6.1 canonical - Hello world example
$ sudo snap install hello
1.91 MB / 61.82 MB [>_________________________________] 3.08 % 442.84 KB/s 2m18s

61.82 megas UN PUTO HELLO WORLD?

Descargar el mismo paquete por apt, sin embargo...
$ sudo apt-get install hello
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho
Se instalarán los siguientes paquetes NUEVOS:
hello
0 actualizados, 1 nuevos se instalarán, 0 para eliminar y 22 no actualizados.
Se necesita descargar 27,5 kB de archivos.
Se utilizarán 106 kB de espacio de disco adicional después de esta operación.

106 KAS DE MIERDA vs 61.82 MEGAS? ESTAMOS TONTOS?

[#34 Pijus_Magnificus]

#32 Se tendría que llamar Nap y no Snap, así echas una siesta mientras baja los paquetes.

[#37 Sheldon_Cooper]

#34 yo propondría más bien renombrarlo a Metastasis.

[#43 Aokromes]

#34 Super nap

[#45 jaspeao]

#32 te habrás bajado la versión que incluye un fondo de pantalla de foto de la NASA en resolución 24k

[#68 Acido]

I've got the Power!

It's getting', it's getting', it's gettin' kinda heavy
It's getting', it's getting', it's gettin' kinda heavy

cc #32 #3

[#79 Desactivado]

#32 Creo que tiene que ver con que se descarga todas las dependencias.

[#92 javielillo]

#32 Tal y como dice #79 Con ese paquete que incluye todas las dependencias básicas ya puedes actualizar y actualizar el SO que debería de valerte el paquete. Donde realmente se aprecia esta ventaja es al instalar varias versiones de un mismo programa o estar anclado a una versión vieja(estable) del SO pero con versiones recientes de software.

Y ya no son excusas válidas el espacio que te ahorras.

[#98 Sheldon_Cooper]

#92 pero ponte que metes con este sistema todos los programas de KDE como paquetes separados... cada uno con sus 400 megas de librerias de KDE y QT... El k3b pasando de los 4 megas que ocupa el paquete en si a 440...

[#113 javielillo]

#98 Si no quieres enguarrar tu sistema por la razón que sea pero necesitas ciertas versiones de software actualizados a la última versión ésta es la solución que de propagarse su uso a otras distros sería un estándar de facto beneficioso para todos.

[#99 deabru]

#32 porque evidentemente no es adecuado para instalar un hello world, un k3b o algo así. Pero para instalar un steam, o ese tipo de cosas sí es muy adecuado.

Si algún día adobe saca sus productos para linux esto le servirá mucho más.

[#117 Desactivado]

#99 Seguirán sobrando 60 MB por cada paquete que instales... y serán muchos más, porque los snaps no comparten ni una mísera librería.
Pero claro, como los discos duros están tirados, qué más da si hace falta 100 o 200GB cuando con otro sistema de paquetes podrían bastar 10GB; total, el disco será de 4TB mínimo... y quién va a notar si tarda 10 veces más en leer todo lo que necesita, o si usa 10 veces más de RAM, que de todas formas lo mínimo es tener 64GB

[#100 Desactivado]

#32 Sip, usan linux.

[#102 DoNoBaN]

#32 Probablemente te habrá instalado ubuntu-core y algún otro paquete. No habría descargado tanto de ya tener todas sus dependencias. No me parece algo significativo como para juzgarlo.

Lo que yo entiendo que usar una distribución u otra implica una confianza en la gente que mantiene esos paquetes, por lo que este tipo de cosas no les encuentro demasiado sentido, ni le veo mucho futuro.

Tampoco es la primera iniciativa de este estilo, muy sensacionalista la noticia...

[#108 Pepitorl]

#32 estás de coña? hay sistemas operativos que ocupan menos que eso!

[#115 neo22s]

#32 sudo snap install hello
0 B / 64.00 KB

[#122 sechole]

#32 Paradojicamente el paquete snap de Libreoffice 5.2 incluyendo java + base ocupa 287MB
Los paquetes oficiales para bajar de la web que no incluyen java
Linux x86 (deb) - 213MB
Linux x86 (rpm) - 213 MB
Mac OS X x86_64 - 201MB
Windows x86_64 - 238 MB

Así que no es exageradamente gordo y depende mucho de que casos.

https://skyfromme.wordpress.com/2016/06/16/a-third-of-a-libreoffice-snap/

[#50 anv]

#3 Yo diría que el hecho de que tengan una copia de una biblioteca en otra parte del disco no debería hacer que se cargue dos veces en memoria, ¿no? A no ser que la versión no sea la misma.

[#56 ailian]

#50 Es que precisamente se trata de eso, de que "ahora quiero la ultimísima versión de X", que viene con las últimas versiones de XX librerías, que obviamente no serán las que ya tienes instaladas. Así que sí, te van a zampar la memoria entre lo uno y lo otro.

[#59 anv]

#56 Eso es cierto. A no ser, claro, que también tengas la última versión de "Y" que usa las mismas versiones nuevas de bibliotecas. Pero tienes razón, será mucho más probable que haya diferentes versiones de una misma biblioteca cargadas en memoria.

Tenemos dos alternativas: evitamos usar paquetes snap (supongo que siemrpe quedará la alternativa de usar el sistema anterior (deb, rpm, etc.) o ponemos más memoria (total, los PCs hoy en día vienen "diseñados para windows", por lo tanto traen memoria y disco de sobra)

[#19 pandamanso]

Me recuerda a esto: https://xkcd.com/927/

[#96 alcornoque]

#19 jajajaj C-f 'xkcd' en la original... nada ('huy, que raro'). Meneame no defrauda.

[#5 Gualterio_Blanco]

Esto de los paquetes universales es bastante antiguo, lo que pasa es que nunca han tenido demasiado éxito entre los usuarios de GNU/Linux. Ya nadie se acuerda de Autopackage y Klik (por ejemplo). Y no es la primera vez que lo intenta Ubuntu, con CNR casi lo consigue.

[#13 sechole]

#5 Si es antiguo, la idea data del año 2004, Appimage es la continuación de Klik.
Cannonical con esta movida esta tratando de que su paquete se convierta en estándar.
Con mencionar que logro el apoyo de varios grandes va por buen camino.

[#14 Frederic_Bourdin]

#5 O de alien para pasar los RPM a DEB. Un infierno las dependencias porque las subversiones rara vez coincidían.

[#15 Desactivado]

#5
Snap sale de Klik.

[#11 Desactivado]

#2 En realidad no creo que fuera un problema la poca popularidad. Ten en cuenta que se descargaría a los servidores principales precisamente de lo que más ancho de banda se come. Podrían usarlo para esos programas menos populares mientras que los LibreOffice, Chromium, Firefox, Steam y compañía serían distribuidos más por P2P que tirando de los servidores principales.

[#1 Desactivado]

Y si se distribuyera con un protocolo P2P no sería necesario elegir el repositorio con mejor caudal de suministro y conseguiríamos balancear las descargas entre todos los disponibles.

[#2 Pepitorl]

#1 esta bien que existan repositorios oficiales y mirrors, eso si, es un coñazo cuando uno no va fino. Lo de un sistema por p2p molaría, el problema son los paquetes poco comunes, que tendrán pocos usuarios e irán mas lentos que ahora

A ver si debian da el salto a snap

[#27 chavi]

#2 Si te parecen lentos los repositorios, imaginatelos con snap....

[#24 Desactivado]

#1 ¿P2P? ¿Eso mismo que puede usar windows 10 para transmitir actualizaciones y por lo que os echásteis las manos a la cabeza?

Cómo se os nota el plumero.

[#28 anv]

#24 Es lo mismo que pensé. Pero hay que tener en cuenta que Microsoft es una empresa comercial que vende su software mientras que linux es gratis y libre. Por eso todos piensan en colaborar como pueden.

[#33 delawen]

#24 Es que no es lo mismo hacerlo con software libre, que puedes comprobar que el código no viene manipulado, que con software privativo, que te meten un troyano y ni te enteras.

[#40 joffer]

#33 No le veo sentido a tu comentario.
Si un paquete viene firmado y existe una comprobación de firma ¿qué más da que sea libre o privativo?

Si la empresa que crea el software privativo te quiere meter un troyano, lo hará, independientemente de cómo llega la actualización de tu equipo. Y la verificación de firma será correcta.

Y por otro lado, el hecho de ser software libre no te asegura que no tenga un troyano de forma intencionada o no.

[#41 delawen]

#40 Si un paquete viene firmado y existe una comprobación de firma ¿qué más da que sea libre o privativo?

Seguimos hablando de software cerrado. ¿Cómo sabes que la firma no ha sido comprometida también?

Al menos si se descarga de un servidor "sólo" estás en manos de ataques Man in the Middle. Si metes una P2P estás introduciendo muchos otros posibles problemas de seguridad además de ese.

Si la empresa que crea el software privativo te quiere meter un troyano, lo hará, independientemente de cómo llega la actualización de tu equipo. Y la verificación de firma será correcta.

Obviamente hablo de terceras personas, no de la empresa que crea el software. Hablo de paquetes alterados. Firma incluída. No es tan difícil hacer algo así.

Y por otro lado, el hecho de ser software libre no te asegura que no tenga un troyano de forma intencionada o no.

Te asegura mayor seguridad, ya que no sólo hay más ojos vigilando, sino que tú mismo puedes comprobarlo.

[#49 joffer]

#41 Si tu comentario inicial se centra sólo en la distribución.

¿Y cómo lo sabes en software libre?. No veo tan clara la diferencia.

Tanto si se descarga de un servidor, como haciendo uso del p2p (como hace MS Windows10) no veo la diferencia entre ser software privado o libre.

[#57 delawen]

#49 Pues hay muchas diferencias:

* Poder "leer" lo que viene en el paquete de actualización y comprobarlo
* Saber qué tipo de comprobaciones se hacen y comprobarlas con tus propios scripts de seguridad o a mano
* Saber qué tipo de comprobaciones se hacen y por tanto saber contra qué ataques tienes que estar preparado
* Saber qué es lo que se instala y poder comprobar que, efectivamente, lo instalado está correcto
* Saber qué es lo que se instala y poder comprobar que no hay ficheros "extraños"

Y eso así de primeras, que te pones a escarbar y hay más diferencias, claro.

[#60 joffer]

#57 Permiteme que insista , si la firma es correcta da igual que sea libre o privado. Vas a instalar lo que la fuente distribuye, sea algo super seguro o malware. Pero tiene la misma probabilidad de ataque tanto uno como otro (partiendo de que todo es atacable).

Otra cosas es que hablemos de las virtudes del software libre sobre el privado. Eso es otro asunto a discutir.

Pero tu contestación en #33 sobre #24 indicas que por el hecho de ser libre puedes comprobar que un paquete no viene manipulado. Yo pienso que si viene firmado lo puedes comprobar con los dos. Después hablas de MitM ya mezclando libre, privado con distribución centralizada o distribuida y ya me lio.

[#61 delawen]

#60 Entonces no has entendido nada.

Parto de que por muy firmado que esté, eso también tiene sus mecanismos de seguridad que alguien podría romper. Y darte una firma falsa. Y tú creer que como la firma encaja, entonces está todo bien.

Si tú quieres confiar ciegamente en que los paquetes firmados funcionan de forma perfecta, todo tuyo. Seguramente nunca te pase nada. Ahora, espero que no seas objetivo de personas maliciosas nunca.

[#65 joffer]

#61 Si eres objetivo de personas maliciosas y éstas son distintas a quién te distribuye el software (no es la empresa que ha compilado tu software) y son capaces de falsificar la firma haciéndose pasar por el repositorio original y tu lo que haces es bajarte un compilado (recompilado por los malos), entonces, lo mismo te da que sea software libre o privado ya que el golpe te lo vas a pegar igual.

No veo diferencias tampoco ahí entre software libre y privado.

Otra cosa es que tu no bajes compilados.
Bajes sólo fuentes y la compiles en tu equipo como hacen distribuciones como Gentoo. Ahí tendrías la posibilidad de comprobar cada una de las lineas de código antes de ser compilada. Claro, que tendrías que ser un robot y tener un patrón de comparación no corrupto por estar terceras personas.

[#62 Desactivado]

#57 Estoy de acuerdo con ambos , a efectos prácticos yo creo que no hay mucha diferencia, y aunque con software libre tienes todas esas ventajas, una vez más, a efectos prácticos el que cualquiera pueda leer las actualizaciones eso suele significar que nadie lo hará, y encima tienes la falsa percepción de seguridad que alguien lo ha hecho.

[#66 jhoker]

#41 ¿te pararias a comprobar si todas las actualizaciones para comprobar que un listillo no la cambio? De todos modos si fuese tan fácil hacerlo como dices ya había aparecido alguna noticia al respecto y por ahora nada de nada, solo suposiciones.

[#82 rocambolescus]

#41 ¿Cómo sabes que la firma no ha sido comprometida también?

Creo que no sabes bien cómo funcionan las firmas digitales, ni el P2P, entre otras cosas.

Una firma digital, por definición, no se puede "comprometer". Mejor dicho: no se puede "comprometer" (la palabra que buscas es forjar) sin que el destinatario se dé cuenta. Ésa es precisamente la función de las firmas digitales, protegerte ante modificaciones del objeto firmado.

Y el P2P funciona de forma similar. Un peer no puede modificar un fichero en tránsito sin que el destinatario se dé cuenta, simplemente porque el hash no coincide y el cliente re-descarga el trozo.

Al menos si se descarga de un servidor "sólo" estás en manos de ataques Man in the Middle. Si metes una P2P estás introduciendo muchos otros posibles problemas de seguridad además de ese.

No y no. Da igual de dónde lo descargues, y el protocolo que utilices. Si está firmado, y tu sistema operativo tiene a piñón las claves públicas de las entidades habilitadas para firmar actualizaciones (que es lo que pasa en Windows y cualquier distro Linux seria), entonces es prácticamente imposible modificar un paquete sin que tú te enteres.

[#85 delawen]

#82 Creo que eres tú el que no sabe cómo podría hacerse. Pero se puede.

Basta con que por ejemplo te cambien el certificado que crees que es el de tu remitente. Hacer que confíes en algo que no es confiable. Y ya lo tienes.

¿Es fácil? No. ¿Es posible? Sí. ¿Se ha hecho antes? Muchas veces. ¿Te lo van a hacer a ti en concreto? Lo dudo. ¿Pero podrían hacértelo si quisieran? Sí.

Lo mismo con el P2P. Basta con que te hagan un Man in the Middle y te descargues algo que compares contra un hash que te ha puesto tu atacante. ¿Coincidirán? Pues claro que sí, te ha modificado las dos cosas: el hash y el fichero.

De nuevo: ¿Es fácil? No. ¿Es posible? Sí. etc...

[#38 dreierfahrer]

#24 a mi me parece un idea de mierda y espero q no se implemente en linux, q conste.

[#46 scalvo]

#1 entonces tendríamos la obligación de pasar checksums a todos los paquetes... o se tendría que crear un sistema para hacerlo.

[#69 Mov]

#1 No lo he usado nunca. Sólo se que existe, pero tienes esto http://www.camrdale.org/apt-p2p/

[#110 Desactivado]

#1 Existe http://www.camrdale.org/apt-p2p/ , que fracasó. Pero la idea molaba.

[#77 Shotokax]

Vamos a cargarnos una de las grandes ventajas de GNU/Linux frente a Windows. Gran decisión.

[#4 Fingolfin]

Llegaron hace tiempo, con Flatpak. Lo de Ubuntu ahora no es más que propaganda para intentar evitar que su sistema particular, que diseñaron a espaldas de la comunidad y sin participación de nadie, se quede al margen.

[#21 senyorningu]

#4 Pero "lo de Ubuntu" tiene una semana mas que Flatpack, y funciona para algo mas que para Gnome.

[#86 Fingolfin]

#21 Flatpak lleva mucho tiempo funcionando, y mientras que Ubuntu ha desarrollado snap a espaldas de todo el mundo, manteniendo algunos componentes cerrados, sin opinión de la comunidad de software libre y exigiendo asignación de copyright a cualquier contribución, Flatpak se ha desarrollado en abierto desde el principio. Si te hubieras documentado un poco sabrías que, de hecho, está más extendido que snap y funciona para muchas más cosas que para Gnome. Ejemplo, https://community.kde.org/Flatpak (para snap, aun no hay nada equivalente)

[#87 Nitros]

#4 Ya ves, estos de Ubuntu son la hostia. Que en vez de esperar un par de decadas a que cuatro fumados de "la comunidad" saquen una versión estable y profesional de cosas como Wayland o Flatpak, se hacen las suyas propias.

Es como Torvalds, que en vez de esperar a que Stallman acabase GNU Hurd allá a principios de los 90, va el muy cabezón y saca su propio kernel. Total, si se hubiese esperado un par de siglos no habría hecho falta.

[#89 Fingolfin]

#87 Flatpak ya es estable desde hace más tiempo y está más extendido y más en uso que snap. Quizás no seas consciente de ello porque mientras Canonical utiliza estos anuncios grandiosos como publicidad para tener eco en los medios y convencer a gente sin mucha idea, Flatpak lleva funcionando en todas las distros desde el primer día, sin marketing de por medio. La prueba, como digo, es que mientras que proyectos como KDE llevan probando Flatpak desde hace tiempo, lo contrario simplemente no ocurre. Lo experimental y a medio hacer, por mucho que algunos os traguéis el marketing como los usuarios de Apple hacen con lo suyo, es snap.

Y Wayland estuvo, está y seguirá estando más avanzado y estable que Mir, y sobre todo sus APIs están más adoptadas en el resto de proyectos de software libre (que es lo que verdaderamente importa). La prueba es que algunas distros grandes ya están utilizando wayland por defecto en la pantalla de inicio, mientras que Mir sigue considerándose inestable y retrasándose su adopción una y otra vez...y otra...y otra. Eso si, tienen su marketing para que la gente como tú crea que aquellos es super profesional. Pero Canonical simplemente va por detrás, e irá siempre por detrás, porque hacer todo uno mismo al margen de la comunidad requiere mucha mano de obra, algo que Apple o Microsoft pueden permitirse, pero Canonical, a pesar de sus ínfulas de superioridad, no.

[#111 Desactivado]

#89 x d g-app probablemente lleve más tiempo y esté más establecido que ambos. Y no le importa a nadie, que es lo que cuenta, el developer mind-share. Y Snappy tiene pinta de estar ganando ahí.

[#18 llou]

No voy a negar que tengan su nicho este tipo de paquetes, pero por ejemplo, para construir contendedores docker, amis de amazon e imagenes de sistemas embebidos, vamos el 99% del mercado menos el ordenador de casa del pajillero de turno, se seguirá tirando de las mucho más eficientes distribuciones.

[#72 frg]

#18 Creo que es justo al revés. Cuando despliegas máquinas de forma automática, la resolución de dependencias y su instalación supone un tiempo mayor, contando que no falle la instalación de alguna dependencia, por lo que creo este sistema está justo pensado para estos casos, paquetes grandes pero con "todo incluido", para poder desplegarlos en un contenedor.

[#74 llou]

#72 Cuando despliegas máquinas de forma automática el sistema de gestión de configuraciones junto con el sistema de paquetes apt, pip, gem... te hacen todo el trabajo gordo. Solamente cuando puntualmente quieres correr un programa y te da problemas de dependencias, pongamos steam, te resuelve esto el problema porque en estos casos igual no te merece la pena ponerte a resolver problemas y terminas cambiando a windows o macos.

[#118 Desactivado]

#72 Cuando despliegas un contenedor, el contenedor es el "paquete". Para crearlo, como si copias los ficheros directamente a pelo.
Los snaps estos son más bien el equivalente casero de los contenedores, y no tiene mucho sentido crear contenedores (docker o lo que sea) a base de juntar "contenedores" (snaps).

[#39 pip]

Esto es querer arreglar por fuerza bruta algo que no puede solucionarse completamente, sólo sirve para casos puntuales de programas muy auto-contenidos como Chrome.
Un programa de Linux "normal" puede depender de muchos cientos de megas o gigas de librerías (pensemos en KdeLibs, Qt). ¿y hasta dónde empaquetar? ¿hasta libc?
¿y que pasa con la configuración del sistema, o la del entorno de escritorio?

[#47 anv]

#39 Pues mira, mi sistema completo tiene 2,1Gb de bibliotecas (recuerda que library significa biblioteca, no librería). Y dudo que algún programa las necesite todas pero supongo que si alguno necesita demasiadas dependencias y no es práctico empaquetarlo todo, se utilizará el sistema tradicional.

[#84 Lidenbrock]

Como dice #39 sólo lo veo bien para casos puntuales, por ejemplo, en mi debian+mate instalé Krita (appimage) sin tener que instalar un gritón de librerías/dependencias de KDE.

[#112 Desactivado]

#39 Si lees como va la cosa, el rollo es estilo docker, contenedores aislados pero anidados: hay unos snaps especiales que llaman 'frameworks' de los que dependen los paquetes normales. libc está en un framework, kde a su vez en otro y krita en un tercero que depende de ambos.

[#120 Desactivado]

#39 "¿y hasta dónde empaquetar? ¿hasta libc?"

Siempre puedes empaquetar hasta el kernel... y entonces tienes una VM

[#95 yemeth]

Hace tiempo que existe un sistema universal y se llaman .deb

Por lo demás, sí, ya, un nuevo standard "universal"

[#36 Desactivado]

¡Qué bien!, aunque hubiera sido mejor que lo hubiera creado Poettering, ya tenemos systemd, un demonio zeroconf que se instala por defecto para casi cualquier cosa, un gestor de paquete tipo Mac, etc, lo que hecho en falta es un lugar para guardar todas las configuraciones, no se, ¿un registro global jerárquico basado en clave valor?.

Parafraseando (con alguna modificacion) el viejo libro de Unix Haters, que por cierto es gratuito y descagable en http://web.mit.edu/~simsong/www/ugh.pdf, Linux es a Unix lo que un cancer de pulmón es a un pulmón.

¡Alabado sea Beastie!

[#119 Desactivado]

#36 "lo que hecho en falta es un lugar para guardar todas las configuraciones, no se, ¿un registro global jerárquico basado en clave valor?"

¿Qué pasa, el registro de Gnome no te gusta?
https://en.wikipedia.org/wiki/Gconf-editor

[#35 Peazo_galgo]

Anda, parece que me escucharon en el comentario que hice en la noticia de Windows 10, jeje.

Pues como decía por allí, lo de los paquetes snap estos puede venir bien para puntualmente instalar versiones recientes de aplicaciones que necesitemos usar y que no estén soportadas aún por nuestra distro de turno sin tener que esperar a que lo esté. Evidentemente hay desperdicio de espacio y duplicidad de librerías, pero te evitas tener que usar la versión experimental de la distro o una Rolling release para ello, con los problemas de estabilidad que ello conlleva...

[#70 usr]

No puedo hablar por casos muy concretos de servidores de produccion y cosas asi pero para casa (y para mu hos servudires), una vez superada la adolescencia de querer tener siempre lo último, con los repositorios de toda la vida vas que te matas. E incluso cuando no hay algo en el repositorio tampoco cuesta tanto buacar como instalarlo de otra manera.

[#81 mangrar]

Definitivamente, este es el año de linux en el escritorio

[#91 Desactivado]

#81 por fin... 81 comentarios... Casi lo tengo que poner yo...

[#88 Desactivado]

Espero que esto no tenga ningún éxito.

[#16 Desactivado]

http://snapcraft.io/

[#26 Marcus78]

empezando fuerte con un "Os acodáis"

[#48 alexwing]

Esperemos que así los linuseros puedan usar algún día su paquete.

[#51 Desactivado]

#48 si pones tu orificio anal a tiro, yo lo intento ehhh

[#54 alexwing]

#51 No gracias, yo fui linusero, y lo deje, ahora soy un hombre felizmente casado y con un hijo.

[#58 Desactivado]

#54 felizmente casado. ni recuerdo cuando fué la última vez que escuche eso

[#73 frg]

#58 La última vez que lo escuchaste fue unas semanas antes de escuchar, por boca de la misma persona, que estaba "felizmente divorciado".

[#75 Desactivado]

#73 jajaja ahora comprendo