#32#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.
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.
#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
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.
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.
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 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.
#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.
#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.
#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.
#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.
#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 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
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.
#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)
#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.
#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.
#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.
#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.
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...
¡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.
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?
#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.
#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.
#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"
#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
#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.
#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.
#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.
#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.
#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.
#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.
* 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.
#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)
#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.
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.
#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.
#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).
#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!
#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.
#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.
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.
#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.
#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.
#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.
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.
#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)
#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.
#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.
#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.
#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.
#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.
#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.
#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.
#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...
#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.
$ 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?
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.
Y también le facilita la vida a los creadores de troyanos, van a windowizar linux.
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.
Estos paquetes vienen a enguarrar el sistema y hacerle la vida mas fácil a los desarrolladores de software propietario.
ostree.readthedocs.io/en/latest/
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.
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
"Se descargaran 400 mb de actualizaciones. Se liberaran 25 mb de espacio en disco"
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)
Instalas algo, se actualizan y algo va a la mierda.
Casi prefiero cada cosa con lo suyo.
$ 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?
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...
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!
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?
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.
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.
<<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.
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.
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.
* 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.
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)
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.
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.
¿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).
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!
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.
Lo de que actualizas y algo se va a la mierda, cuñao doble.
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
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.
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.
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...
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.
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.
Y ya no son excusas válidas el espacio que te ahorras.
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
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.
Por lo demás, sí, ya, un nuevo standard "universal"
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.
Si algún día adobe saca sus productos para linux esto le servirá mucho más.