#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.
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.
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.
#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: diegocg.blogspot.com.ar/2015/02/snappy-ubuntu-core-una-manera-diferent
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 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.
#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.
#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.
#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.
#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.
#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.
#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.
#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
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.
#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.
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.
#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!
#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.
#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.
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?
#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)
¡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 web.mit.edu/~simsong/www/ugh.pdf, Linux es a Unix lo que un cancer de pulmón es a un pulmón.
#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)
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...
#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.
#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.
#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
#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...
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.
#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 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.
#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.
#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, community.kde.org/Flatpak (para snap, aun no hay nada equivalente)
#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.
#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.
#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...
#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.
#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.
#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.
#41 Si tu comentario inicial se centra sólo en la distribución. <<Seguimos hablando de software cerrado. ¿Cómo sabes que la firma no ha sido comprometida tambié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 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 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.
#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.
#10Yo 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.
#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.
#107 Reitero, ¿que tiene que ver el arranque del sistema con el nro de particiones con los paquetes autocontenidos?
Él hace referencia a esta documentación que hace referencia al sistema de particiones de Snappy Ubuntu Core OS: developer.ubuntu.com/en/snappy/guides/system-updates/
Ni en Arch, ni en Debian, ni en Ubuntu ni en ninguna distro es necesario reparticionar para que funcione.
Si no me crees has la prueba. github.com/snapcore/snapd
#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.
#40Si 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.
* 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.
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.
#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.
#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.
#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.
El tema del tamaño del paquete no creo que sea relevante a día de hoy, la gente se baja peliculas de gigas. Quizas hasta abarate los SSD ;-D
Para mi lo mas importante es el consumo de RAM. Si 7 frameworks o aplicaciones de snap se ejecutan a la vez y tiran de la misma libreria, las librerias se cargan en RAM una vez o siete?
Lo pregunto por que si estan encapsuladas veo dificil la compartición.
Lo de las particiones para permitir el tema del rollback me parece un pifostio de la hostia. Ya es complicado explicar a la gente los distintos tipos de particiones/usos/tamaños recomendados.
Además añadira más complejidad en los instaladores y problemas derivados de las particiones.
#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
#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.
#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"
$ 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?
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:
diegocg.blogspot.com.ar/2015/02/snappy-ubuntu-core-una-manera-diferent
Estos paquetes vienen a enguarrar el sistema y hacerle la vida mas fácil a los desarrolladores de software propietario.
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.
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.
A ver si debian da el salto a snap
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.
ostree.readthedocs.io/en/latest/
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!
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.
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.
www.youtube.com/watch?v=100SHwUul_M
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
"Se descargaran 400 mb de actualizaciones. Se liberaran 25 mb de espacio en disco"
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?
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)
Por lo demás, sí, ya, un nuevo standard "universal"
Parafraseando (con alguna modificacion) el viejo libro de Unix Haters, que por cierto es gratuito y descagable en 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!
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)
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...
Y ya no son excusas válidas el espacio que te ahorras.
De hecho sus creadores están a punto de liberar el 1º bajo una licencia libre.
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...
Si algún día adobe saca sus productos para linux esto le servirá mucho más.
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...
Y también le facilita la vida a los creadores de troyanos, van a windowizar linux.
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.
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.
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.
Lo de que actualizas y algo se va a la mierda, cuñao doble.
<<Seguimos hablando de software cerrado. ¿Cómo sabes que la firma no ha sido comprometida tambié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.
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.
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.
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.
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
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.
Él hace referencia a esta documentación que hace referencia al sistema de particiones de Snappy Ubuntu Core OS:
developer.ubuntu.com/en/snappy/guides/system-updates/
Ni en Arch, ni en Debian, ni en Ubuntu ni en ninguna distro es necesario reparticionar para que funcione.
Si no me crees has la prueba.
github.com/snapcore/snapd
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.
skyfromme.wordpress.com/2016/06/16/a-third-of-a-libreoffice-snap/
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.
* 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.
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.
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.
Para mi lo mas importante es el consumo de RAM. Si 7 frameworks o aplicaciones de snap se ejecutan a la vez y tiran de la misma libreria, las librerias se cargan en RAM una vez o siete?
Lo pregunto por que si estan encapsuladas veo dificil la compartición.
Lo de las particiones para permitir el tema del rollback me parece un pifostio de la hostia. Ya es complicado explicar a la gente los distintos tipos de particiones/usos/tamaños recomendados.
Además añadira más complejidad en los instaladores y problemas derivados de las particiones.
0 B / 64.00 KB