edición general
27 meneos
541 clics
Una comparación técnica entre snaps y debs. (ENG)

Una comparación técnica entre snaps y debs. (ENG)

La introducción del formato de aplicación autónomo, como los snaps, ha creado un cambio de paradigma en la forma en que las aplicaciones de Linux se crean, distribuyen y consumen. En este artículo, nos gustaría ofrecerle una descripción general de algunas de las principales diferencias entre los dos formatos de archivo y cómo pueden adaptarse mejor a sus necesidades.

| etiquetas: snap , deb , paquetería , linux , gnu
20 7 0 K 50 linux
20 comentarios
20 7 0 K 50 linux
Comentarios destacados:        
  1. xkill #1 xkill
    Vaya, no me esperaba que snapcraft apueste porque el formato snap es mucho mejor que el formato deb. Pero creo que se han sobrado con cosas que no son ciertas.
    5 K 57
  2. #2 --526666--
    La foto es 100% random?
    1 K 16
  3. zoezoe #3 zoezoe
    #1 MI aptitude solo me lo quitaran de mis manos frías y muertas.
    6 K 76
  4. Am_Shaegar #4 Am_Shaegar *
    #1 Y tanto.

    En Phoronix, explican que esos formatos (fltpak, snap) degradan el rendimiento del sistema por la duplicidad de bibliotecas cargadas en memoria.

    Básicamente que como cada aplicación tiene cargadas sus bibliotecas, no se hace un uso adecuado de la caché del procesador.
    2 K 15
  5. #5 --164239--
    Infinitamente mejor los programas empaquetados en .deb linkados dinamicamente de toda la vida, y donde actualizando una librería se actualizan todos los programas que la usan.
    Para programas de fuera de distribucion ya existe el empaquetado appimage que cumple perfectamente, y no necesita las mierdas que pide snap como tener un servicio activo en memoria.
    5 K 39
  6. xkill #6 xkill
    #4 si, eso no lo dicen en la comparación y sin embargo, dice que no se verifica casi nunca la firma de los paquetes Debían, cuando en realidad se verifica siempre (a no ser que te descargues el paquete deb a mano y lo instales a mano, cosa que no suele ocurrir) aunque la firma de los paquetes SNAP es casi peor que los repositorios Debían que tienen una firma verificada y no una firma arbitraria por cada paquete, o que las actualizaciones son malas (cuando eso tampoco es así). Y así mil cosas más....
    Vamos que casi diria que esta comparación es publicidad engañosa y amarillista de los paquetes SNAP.
    7 K 67
  7. #7 --620144-- *
    Donde se ponga un arbol de ports, que se quiten todas las tonterías. Emerge rulez, pacman rulez, bsd ports rulez, etc. Y si no os gusta, os jodéis y aprendéis a tunear el /etc/make.conf y así de paso leéis la página man del GCC :-P

    Además, los "snaps" esos no tienen ni comprobación de alteración de código binario mediante firmas, certificados u cosa parecida, por lo que más que un sistema de distribución de binarios lo que parece es un sistema de distribución de malware. Los debs por lo menos usaban firmas GPG. Resumiendo: los snaps son el systemd de los paquetes.

    Venga, empezad a odiadme l-users ubunteros :troll:
    2 K 22
  8. #8 dameAbrazos
    #4 ¿sucede igual con docker en el server?
    0 K 7
  9. #9 --112174--
    Sin animo de polemizar, me parece algo corto el post para ser técnico. ¿Y como que los .debs no van firmados? :shit:
    1 K 22
  10. Yrithinnd #10 Yrithinnd
    #7 puto systemd. ¿Qué necesidad había?
    2 K 30
  11. #11 chavi
    Por qué no comparan snap con jpg ? También son dos formatos de archivos.

    Ya puestos...
    2 K 26
  12. Sandevil #12 Sandevil *
    #7 Por alusiones(l-user ubuntero), y habiendo sido gentooza varios años(lo abandone por tener que esperar un día a actualizar todo el sistema como hubiera algo que implicara entornos gráficos, los procesadores daban lo que daban en aquel entonces) ... Sabes que capacidad de espanto a futuros usuarios has generado en ese comentario? Tu déjales que prueben las drogan blandas, que ya habrá tiempo para las duras :troll:

    Ya volviendo a la noticia.. Aha, nos venden que un sistema que calca la distribución de software en windows/OSx es mejor...
    1 K 22
  13. #13 --620144--
    #12 Déjalos que se asusten, así los demás cobraremos mejores salarios por el plus de pr0 (o de BOFH) de la nómina :troll:
    0 K 6
  14. #14 --565990--
    #8 Pues claro
    0 K 8
  15. #15 dameAbrazos
    #14 Oh...
    0 K 7
  16. #16 luisfeser
    #7 #10 veo opiniones en contra de systemd pero la verdad desconozco el motivo. A mi me resulta bastante cómodo de usar con systemctl restart xxxx o similar.
    Que tiene de malo y qué otras opciones hay y en qué distribuciones? lo digo por si me convencéis para el cambio (ahora uso Arch con systemd)
    1 K 10
  17. #17 --620144--
    #16 Pues se diría que parece que no tienes mucha experiencia con Arch, porque cualquier arch-user sabe que en la wiki esta TODO (sobretodo cuestiones como sysrc vs systemd, archivos de conf, etc). No pasa nada compi, no te ralles y sigue mi consejo: empieza por aquí: wiki.archlinux.org/index.php/Systemd ;-D
    1 K 19
  18. #18 luisfeser
    #17 tengo mucha experiencia con Arch (busca mi nick en sus foros y mira la fecha de mi registro). Pero precisamente lo que no quiero es investigar, sino un resumen rapidito, ese enlace es un poco largo para mi gusto

    Si me da por investigar no pregunto, ya me apaño yo como buen linuxero ;)
    0 K 7
  19. #19 --620144--
    #18 Es que es mu largo de explicar, no se puede hacer un resumen en un comentario. Es algo que tienes que mirar tú si quieres enterarte de la movida y eso implica navegar la wiki de Arch y tener ganas de leer. No te puedo resumir el "man 1 systemd" en Arch y el "man 1 init" en un *BSD o en una debian Woody, tendría que empezar por el doble fork () del proceso init (pid=1) y terminar por los putos logs binarios del journalctl :-P
    0 K 6
  20. Jakeukalane #20 Jakeukalane
    pues a mí ya me importa poco. Donde esté pacman...
    0 K 10
comentarios cerrados

menéame