Portada
mis comunidades
otras secciones
#28:
#13 es odiado porque es una puta mierda.
Te hace un jail (jaula) donde instala todo, pero no tienes acceso directo a eso, por lo que, por ejemplo, si tienes el /home en otro sistema, pues te jodes. Suele ser más lento, más "oculto" y menos visible, tiene su propio buscardor de programas, que es una mierda... es el típico:
https://imgs.xkcd.com/comics/standards.png
Lo utilicé unas horas (por programas que sólo estaan ahí) hasta que me cansé y lo desinstalé y a tirar con wine para lo que necesitaba...
Te hace un jail (jaula) donde instala todo, pero no tienes acceso directo a eso, por lo que, por ejemplo, si tienes el /home en otro sistema, pues te jodes. Suele ser más lento, más "oculto" y menos visible, tiene su propio buscardor de programas, que es una mierda... es el típico:
https://imgs.xkcd.com/comics/standards.png
Lo utilicé unas horas (por programas que sólo estaan ahí) hasta que me cansé y lo desinstalé y a tirar con wine para lo que necesitaba...
#19:
#13 ¿Y por qué es tan odiado?
Una vez que lo usas, las cosas que tienes instaladas se dividen en dos: Las que has instalado con APT y las que has instalado con ese sistema. A partir de ese momento, "dpkg -l" ya no te da una lista de todo lo que tienes instalado (como pasa también cuando haces "make install").
Las ventajas de saber que todo está bajo el control de APT empiezan a desaparecer.
Una vez que lo usas, las cosas que tienes instaladas se dividen en dos: Las que has instalado con APT y las que has instalado con ese sistema. A partir de ese momento, "dpkg -l" ya no te da una lista de todo lo que tienes instalado (como pasa también cuando haces "make install").
Las ventajas de saber que todo está bajo el control de APT empiezan a desaparecer.
#27:
#13 Linkados estáticos VS linkados dinámicos
Si usas windows, y buscas en tu disco duro archivos llamados msvcr*.dll -por ejemplo- verás que tienes docenas de archivos con el mismo nombre: el .dll es una libreria y cada programa lleva las suyas. Esto tiene la parte positiva de que cada programa lleva las suyas (y no hay problemas de incompatibilidad de versiones) y tiene la parte negativa que a veces tienes 20, 30 o 40.. o 100 copias de cada libreria en el disco duro (y hay muchas comunes). Cuando tienes muchos programas instalados, a veces se llega al absurdo.
Si usas linux, solo tienes una libreria de cada, aunque a veces traiga algun problema de incompatibilidad de versiones.
Snap pretende traer el sistema de windows (linkados estáticos) a linux (linkados dinámicos) y la gente no quiere, porque vino a linux huyendo de windows
Está bien para instalar algún programa de pago concreto, y que no de problemas de compatibilidades, pero si, que venga todo asi es un horror.
Si usas windows, y buscas en tu disco duro archivos llamados msvcr*.dll -por ejemplo- verás que tienes docenas de archivos con el mismo nombre: el .dll es una libreria y cada programa lleva las suyas. Esto tiene la parte positiva de que cada programa lleva las suyas (y no hay problemas de incompatibilidad de versiones) y tiene la parte negativa que a veces tienes 20, 30 o 40.. o 100 copias de cada libreria en el disco duro (y hay muchas comunes). Cuando tienes muchos programas instalados, a veces se llega al absurdo.
Si usas linux, solo tienes una libreria de cada, aunque a veces traiga algun problema de incompatibilidad de versiones.
Snap pretende traer el sistema de windows (linkados estáticos) a linux (linkados dinámicos) y la gente no quiere, porque vino a linux huyendo de windows
Está bien para instalar algún programa de pago concreto, y que no de problemas de compatibilidades, pero si, que venga todo asi es un horror.
#22:
#17 Define el desprecio a el usuario. Porque la ultima hornada de interfaces planas en Windows e incluso OSX las hace inusables en PCs.
Si te refieres al pasado de Gimp multiventana... ten en cuenta que Gimp fue disenyado con escritorios virtuales en mente, y no con escritorios limitados como los de Windows y Mac.
Si te refieres al pasado de Gimp multiventana... ten en cuenta que Gimp fue disenyado con escritorios virtuales en mente, y no con escritorios limitados como los de Windows y Mac.
Comentarios
#4 Es que apt no tiene cargas . . .
Titular alternativo "Ubuntu: Linux Mint, ¿estás bien,quieres que hablemos?
#1 No es por ti, es por los snap
#3 He conocido a un tal flatpak o he vuelto con mi ex apt.
#1 Esto tiene pinta de acabar en kiki, o de reconciliación o de coraje, pero en kiki
¡Pacman, pacman, pacman! ¡Yay!
#8 y no se hable más.
El mejor sistema sigue siendo APT.
#12 No.
#15 Si. Y de.largo.
#43 No has visto pkg_add en OpenBSD entonces. Nada mas simple y funcional.
Y con los ports para lo que no se puede distribuir en paquetes (literalmente dos o tres, plan Eduke32/Xephem, poca cosa), es darle 200 vueltas a APT y su gestion.
#12 synaptic
#21 Es el mismo, usa a APT debajo. Lo mejor es Slackware de lejos. Que no hay dependencias? Tampoco son tantas; entre slackpkgplus y sbotools instalas primero las que te pida el slackbuild (estan todas indicadas) y luego con sbotools te compila/instala el resto.
Total, las actualizaciones son automaticas con slackpkg upgrade+sboupgrade.
#23 para encotrar dependencias viejuunas lo mejor es synaptic packet manager, también es cuestión de aptitude
#24 En Slack no hay dependencias como tales. La version "correcta" de instalacion es instalar todo por defecto, pero en realidad puedes saltarte KDE y KDEi o XFCE (segun te de) sin problema, luego instalar Kaffeine por ejemplo a pelo no es tan dificil.
Con los repos de AlienBob tienes una lista ingente de software de Slackbuilds ya precompilados y donde instalarlo es sencillico, solo es meter Slackpkgplus y editar la configuracion. La ventaja es que los paquetes son vanilla, sin parchear ni hostias. Todo puro. Y sin SystemD.
Si, los SlackBuilds compilados de AlienBob piden dependencias, pero te las ponen en su web por paquete asi que solo es "slackpkg install loquesea bla bla blo" y a tirar millas.
Para el resto: https://slackbuilds.org/ y https://pink-mist.github.io/sbotools/
Lioso? Depende, aunque cierto es que instalar Virt-Manager con Spice
esera pesadillesco, hoy ya sbotools entiende todo.https://slackbuilds.org/repository/14.2/system/virt-manager/
#25 slackpkg install loquesea bla bla blo
No es funcional. Es un absurdo esperar que los usuarios normales vayan a hacer eso (y francamente, yo hace anhos que no lo hago y no estoy dispuesto a volver a eso).
Si el sistema no funciona con una orde única, entonces no es adecuado para escritorio.
#34 Para escritorio no se, para que los maneje un sysadmin con compilaciones propias es mas que adecuado. Tiene una estabilidad comparable a Debian Stable, si no mas. Para el resto que no este en el DVD, siempre puede compilar slackbuilds propios y redistribuirlos, hoy con los SSD y maquinas de i3 para arriba te compilas mas de 100 paquetes en una hora, asi que para los extras necesarios (pocos, repito, los repos de AlienBob tienen todo lo gordo), se compilan en media hora y los paquetes valen para todas las maquinas. Por cierto, Slackware 15 introducira PAM (tras mucho pensarselo), por lo que valdra para empresa con necesidades de seguridad anyadidas (y soporte AD con otras opciones). Aunque SystemD por supuesto nunca se introducira.
La gente no es consciente de los entornos reproducibles facilmente sin lios de dependencias raras al instalar, cosa que me ha pasado con Mageia y dependencias circulares.
#62 totalmente. Yo empezé con mandrake, pero me pasé a slackware rapidamente, allá por los primeros dosmiles. Luego pasé a redhat, fedora, estuve un gran tiempo con rocklinux (en esa época probé decenas de distros y esa me funcionaba de lujo, así que la deje) y desde hace años estoy con ubuntu.
Slack me encataba por estabilidad y que no había carpetas raras en la raiz...pero eso de tener que toquetear cosas me cansa.
#64 Bueno, la ventaja de Slackware es que una vez instalada no hay que tocar nada en siglos, sbotools y slackpkg actualizan todo, y nunca hay que compilar mucho la verdad, en los repos de AlienBOB esta qt5, Java, LibreOffice, VLC, ffmpeg, Chromium, paquetes de Netflix para Chromium, emuladores, juegos... paquetes gordos y sus dependencias. Cuesta al principio, pero luego slackpkg update, slackpkg upgrade-all cada semana (eso en cron, que se encargue el solito de todo) y sboupgrade -z cada dos meses (puedes hacer tareas de mientras perfecetamente) y listo.
Con las SSD hoy sboupgrade en un Celeron dual core chatarrer me tarda 40 minutos.
#21 Synapric es una aplicación, no un sistema de paquetes
¿Me podréis explicar que es el snap? ¿ Y por qué es tan odiado? ¿No es lo mismo que un .deb?
#13 no es lo mismo, el snap incluye las dependencias, se parece más a los MSI de Microsoft, haciendo que se dupliquen bibliotecas y se comparta menos código.
#16 tanto costaría un "snap" que antes de instalar una dependencia viera si esta ya en el equipo?
#32 es que no es sólo un 'empaquetado'. Snap ejecuta la aplicación aislada del resto del sistema, en una especie de entorno virtualizado, estilo contenedor. Hace que sea 'más segura' por un lado, a costa de perder integración con el resto (por ejemplo, no comparte el mismo tema/apariencia del resto de ventanas gráficas). También esa virtualización supone cierta pérdida de rendimiento, sobre todo en el arranque de la aplicación.
#35 Exactamente. Es lo único bueno de snap.
Muy útil para escenarios concretos. Nunca como sistema de paquetes general
#32 Ya existe, se llama apt, o si quieres aislar el programa en un sandbox, docker.
#38 Docker funciona demasiado aislado. No cumple la misma función que snap.
Los tres se.cimpñementan.
#38 Docker es una mierda que no es para hacer sandbox, es para hacer un build reproducible. Muchas veces la seguridad es infame.
#63 depende de cómo lo configures. Digo yo que si google, Amazon y Microsoft están haciendo sus deploys con docker, es porque saben de esto un poco más que un cuñado random.
#67 Pero no es para aislar, repito. Es para hacer reproducciones de deploys. Si usas docker como herramienta de seguridad vas a flipar despues.
#68 no es una herramienta de seguridad, pero repito, añade capas de aislamiento entre contenedores que impiden las escaladas.
#69 No es comparable a Jail en FreeBSD la verdad, FreeBSD lo implementa mucho mejor. Y en su dia Solaris con las "zonas" era bastante mas seguro (y trazable).
#13 Un deb es un paquete instalable, que instala como APT pero con la aplicación en cuestión empaquetada en vez de un repo; Snap es un contenedor que limita los permisos de las aplicaciones.
Yo lo odio porque en mi local instalé un entorno de desarrollo web procedente de Debian que tenía un Chromium headless para convertir páginas web en PDF. Pues bien, una aplicación dentro de Snap no puede escribir fuera de ciertos directorios y me petaba muy fuerte la aplicación web y fue un infierno encontrar el fallo.
Link: https://askubuntu.com/questions/1184357/why-cant-chromium-suddenly-access-any-partition-except-for-home
#18 En flatpak es configurable a qué recursos, rutas, etc. puede acceder una app concreta, probablemente en snap también, revisa la documentación.
#40 No, Snap no puede, por diseño. Hay un bug abierto:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1849371
#13 ¿Y por qué es tan odiado?
Una vez que lo usas, las cosas que tienes instaladas se dividen en dos: Las que has instalado con APT y las que has instalado con ese sistema. A partir de ese momento, "dpkg -l" ya no te da una lista de todo lo que tienes instalado (como pasa también cuando haces "make install").
Las ventajas de saber que todo está bajo el control de APT empiezan a desaparecer.
#19 para mi ese es un gran problema. Lo mismo tener corriendo contenedores.
Reglamente digo sin entender porque son necesarios snaps y flatpacks. Apt , yum, dnf tienen resuelto el chino gestionar dependencias de hace mucho.
#33 para poder instalar con doble click como en Windoze.
#36 Eso lo puedes hacer con apr
#33 En el momento en el que para poder instalar un programa o aplicación que no está en los repositorios y de la que no te terminas de fiar es cuando snap o flatpak cobran sentido. Aparte de que muchas veces, instalar un repositorio de terceros provoca desastres en algunas dependencias al instalar versiones más nuevas (o incluso antiguas) que las del sistema y tus programas empezar a fallar o no dejarte hacer actualizaciones o nuevas instalaciones.
También son muy útiles para probar betas o nuevas versiones de una aplicación dada, teniendo ambas coexistiendo y pudiendo ejecutarse a la vez para poder compararlas y demás (que no es que no se pueda hacer normalmente, pero es un coñazo)
#41 A mi me parece una manera de escapar hacia delante en lugar de resolver problemas, y acabar con problemas peores.
#72 ¿Como qué problemas peores? ¿peores que corromper el sistema por instalar unas librerías que provoquen que algún programa más o menos vital no funcione?
Recuerdo un servidor donde por alguna razón alguien instaló a saber cómo un python3 en un sistema python2, sobreescribiendo todo lo de esta versión. Las herramientas de gestión de paquetería iban sobre python2 y estaban tirando de python3 como runtime y evidentemente no funcionaban y no había forma de revertir los cambios (aparte de otros programas no tan vitales que sólo funcionaban en python2).
Recuerdo otro equipo donde por razones de poder tirar un programa que necesitaba lo último se instaló también una versión de gtk que rompía cosas hacia atrás, se podría decir que se quedaron sin aplicaciones gráficas (ni iba gdm, ni usando kdm como gestor de sesión luego iban las aplicaciones de gnome).
Con un flatpak o un snap o un appimage, lo peor que podría pasar es que la propia aplicación empaquetada no funcione (total o parcialmente o no vaya alguna funcionalidad o esté muy capada desde la configuración y no pueda acceder a algún recurso externo), nada de fastidiar al resto del sistema.
#75 Por supuesto que peor; antes podía tener muy claro si algo no funcionaba, el sistema de paquetes te permite identificar si algo no anda bien. Ahora tiene fragmentación en la gestión de esos paquetes, duplicación de librerías, y realmente, no te soluciona el problema, solo lo aísla a una parte. Esa puede ser el único aspecto, pero no lo veo como ventaja, mas bien como un parche a dos cosas:
- Usuarios que no quieren hacer un mínimo esfuerzo para entender como mantener su sistema, de la misma manera que uno tiene un coche pero se despreocupa de llevarlo al mantenimiento o ponerle gasolina porque 'yo el coche lo quiero para conducir'.
- Desarrolladores superstar que, de la misma forma, solo se preocupan de su código, como si el resto del mundo no fuera con ellos. Otro producto de este pensamiento mágico son los contenedores en si, Docker y mas mierdas. Porque? a) realmente no solucionen problemas, solo lo aíslan, creando en si nuevos problemas y b) perpetúan una tendencia a ofuscar el software. Es mas difícil trincar dentro de un contenedor.
No quiero una informática de dos velocidades, y menos dentro del mundo del software libre. Para la infromatica cerril ya tenemos a Microsoft y Apple.
Ya mencionados, no, no creo que seguir el modelo de Apple o Microsoft para gestionar software sea la manera. Es un paso atrás en varios aspectos.
#77 No sé cómo va snap, pero en flatpak puedes hacer un flatpak list y ya te muestra todo lo instalado vía flatpak. Y habiendo integración con software de gnome, te muestra todos los paquetes, del sistema y de flatpak. Salvo que tires por una distribución que flatpakee o snapee todo el software, en principio tú empaquetadas sólo vas a tener cuatro cosas, tampoco es que se vaya a convertir en un "infierno para identificar si algo no anda bien". Por cierto, define "algo no anda bien" y por qué usas apt/rpm para comprobarlo.
"- Usuarios que no quieren hacer un mínimo esfuerzo para entender como mantener su sistema, de la misma manera que uno tiene un coche pero se despreocupa de llevarlo al mantenimiento o ponerle gasolina porque 'yo el coche lo quiero para conducir'."
Con un flatpak o snap o appimage se despreocupan igual, están aislados en un sandbox en mayor o menor medida, así que deberían ser lo suficientemente seguros (o incluso más que la instalación de cualquier software en tu distro, que tú puedes configurar mal y abrir huecos y problemas de seguridad que con un flatpak/snap/appimage no tendrías).
"Porque? a) realmente no solucionen problemas, solo lo aíslan, creando en si nuevos problemas y b) perpetúan una tendencia a ofuscar el software. Es mas difícil trincar dentro de un contenedor."
¿A qué te refieres que es más difícil trincar dentro de un contenedor? de hecho, sirven para eso, para aislarlo todo de lo demás y que no haya problemas con el resto del sistema y del software, debería ser una ventaja para todos. Cuanto menos "daño" hagan los superstar mejor, si se quedan en sus aplicaciones contenidas, menos problemas dan al resto.
No puedes obligar a todo el mundo a seguir el mismo modelo. Y flatpak/snap/appimage aportan más libertad sin afectar al sistema o al resto de aplicaciones sin convertir esto en un reino windows/mac es un paso positivo para todos.
#80 Creo que tenemos puntos de vista muy diferentes. No creo que lo que dices no tenga valor intrínseco, solo que yo no se lo encuentro.
Para mi tener una manera solida y madura para hacer una cosa, y que este suficientemente documentada como para que se pueda hacer cambios con facilidad, es la manera correcta.
Tener que recurrir a:
- varios comandos para sacar una lista unificada
- O una abstracción que me muestre esa lista
Es en ambos casos un atraso. Y si, aislar partes del sistema lo veo como un atraso a menos que sea para justificar un modelo de seguridad máxima.
Tener que repetir una librería X veces para X software corriendo en el sistema es una somera estupidez, que no hace mas que perpetuar un modelo de perdedores; como no sabemos como resolver algo, hacemos una agujero y ahora este es nuestro agujero donde estamos seguros, con nuestra librerías.
Esto nos lleva a que todo se vea como un micro-servicio, desmontando funcionalidades como comunicación hoste-to-host, paso de mensajes entre procesos, etc. Estamos convirtiendo el PC de escritorio a un modelo como los teléfonos móviles, donde todo acaba comunicándose con una API.
Simplemente no me gusta ese modelo. Se carga el buen trabajo hecho durante décadas en los sistemas operativos y entrega el poder a otra capa, donde se tienen que re-implementar muchas funciones, reinventar la rueda, introduciendo mas capas de abstracción para algo que a mi no me resultaba en absoluto un problema.
Así que no, no me gusta la solución, porque se que acabare teniendo que trabajar con un sistema de mierda para que un grupo de gente que no quiere dedicar dos minutos a arreglar algo, o leer como funciona lo que usan.
Ya esta, /rant off/
#81 "Tener que repetir una librería X veces para X software corriendo en el sistema es una somera estupidez, que no hace mas que perpetuar un modelo de perdedores; como no sabemos como resolver algo, hacemos una agujero y ahora este es nuestro agujero donde estamos seguros, con nuestra librerías. "
Por eso flatpak usa el concepto de runtimes: descargas un runtime, este se actualiza de manera independiente (parches de seguridad, para no romper compatibildiad, claro) y es válido para varias apps. Se evita la excesiva duplicación, garantiza que el runtime es seguro y está todo lo mantenido y parcheado posible y no haces responsable al empaquetador de la aplicación de ese mantenimiento "externo" (tener que actualizar toda la app porque se ha descubierto un parche de seguridad en una librería externa y esas cosas).
"Estamos convirtiendo el PC de escritorio a un modelo como los teléfonos móviles, donde todo acaba comunicándose con una API."
En un pc todo acaba comunicándose con una API. ¿Qué piensas que son las llamadas al sistema? ¿qué piensas que es un protocolo como wayland? ¿qué crees que es usar librerías?. Nunca usas ni deberías usar directamente los recursos, para eso está el sistema operativo. Desde que has empezado a usar un sistema multiproceso y multiusuario ya has tenido que delegar la gestión en un SO. En flatpak al menos, el uso de portales (o sea, la forma de acceder desde las aplicaciones dentro del flatpak a los recursos del sistema) debería ser transparente (es GTK o QT quien lo gestiona, tú sigues programando tus aplicaciones igual que antes y del mismo modo que el soporte Wayland, mientras uses correctamente las APIs). Desde el punto de vista del desarrollador, no hay que hacer nada (si usas gnome builder, por ejemplo, te hace el empaquetado directamente, sólo tendrás que configurar los permisos que pide la aplicación al sistema y alguna cosa más).
"Using portals in apps
The good news is that most of these will just work transparently in GTK+ applications, since GTK+ and GLib have suitable APIs that can be made to use the portals without any changes required from the sandboxed application. This support is already in place in the master branches; and will be in the 3.22 releases. We are working on a similar level of support for qt/KDE."
Desconozco cómo hace esto snap (appimage si mete todo dentro de un solo fichero, librerías y demás, aunque esté chrootado no es lo mismo).
#19 cuando haces make install a continuación puedes registrar el paquete para que dpkg lo conozca. Hace años que no uso eso, ahora tengo Manjaro, pero existe, búscalo.
Lo que no sé es si existe para snapd pero me extrañaría que no.
Cc #33
#51 Lo que dices me suena a un apaño para "paquetizar" cosas que hayas instalado, no a algo que tenga dpkg de serie. Te agradezco la sugerencia, pero por el mismo precio, haces make install en un chroot, haces un paquete aunque sea chapucero (con tar y alien), lo pones en tu repositorio privado (por ejemplo con reprepro) y de nuevo puedes volver a hacer apt-get install.
Cuando tienes que administrar decenas o cientos de máquinas lo de hacer make install no mola nada.
#56 no recuerdo cómo se hacía pero aparecía en la lista y podías dwsibstalarlo con apt/dpkg. Yo uso mucho github ahora y no me quiero ni imaginar como tendría que ser usar una distro .deb... y tener que hacer "make install"...
Por otro lado nunca aprendí a hacer chroot bien. No he encontrado ni un solo tutorial en español que empiece de 0 absoluto de ese tema.
#57
- mkdir target
- desempaquetas el "rootfs" de tu distro en target
- mount --bind /dev $PWD/target/dev
- mount --bind /proc $PWD/target/proc
- mount --bind /sys $PWD/target/sys
- mount -bind /dev/pts $PWD/target/pts
- cp /etc/resolv.conf $PWD/target/etc/resolv.conf
- cp /etc/group $PWD/target/etc/group
- chroot $PWD/target /bin/sh -l
#65 gracias, eres un máquina
#51 estais de acuerdo que eso es un tinglado no?
Lo mejor es tener TODO el sistema, de arriba a abajo, con un solo sistema de paquetes. Asi TODO el sistema se puede actualizar de una tirada.
#71 yo uso Manjaro, a mí no me mires. Tiene Yay que a su vez llama a pacman y las cosas que no tienen paquete para arch las compila él solito de su correspondiente github.
#73 Si te da una vista unificada de que ha instalado y sabe que necesita actualizar y sigue las dependencias, entonces es un sistema correcto.
Yo llevo prácticamente desde que deje Gentoo con RHEL/CentOS/Fedora, en casa y profesionalmente y raramente tengo problemas. Y cuando los hay el sistema te dice que es lo que esta mal.
#78 nunca he usado una rpm pero la ventaja que tengo con respecto a una distro así es que no tengo que hacer una instalación limpia cada 4 años. Usé Ubuntu 11.10 hasta que se me rompió hace un año el portátil porque la cantidad de personalizaciones / paquetes compilados era muy alta y no tenía espacio como para poder hacer una instalación limpia.
Otras ventajas para mí incluyen: usar software muy reciente o poder usar mucho software extraño compilado (AUR) que desde Ubuntu/Fedora no podría debido a que yo realmente no sé compilar. Un make install sin saber falla muchísimo (e incluso sabiendo) mientras que Yay no (o te ayudan a solucionarlo). (https://aur.archlinux.org/packages/qosmic/ )
En Manjaro también tengo acceso a flatpaks/snaps (creo que solo he instalado pycharm así) y a alien y debtap. Es decir tengo todo el software de las rpm/deb con posibilidad de poder usarlo y además tengo una herramienta que me permite compilar muchos paquetes extraños sin tener casi idea.
Las distros rpm/deb basan su éxito en tener mucho software precompilado y empaquetado. Arch/Manjaro no puede competir en eso por lo que coge paquetes de todos los sitios que puede.
Bueno, lamento el tocho. Un saludo grande.
#79 Tengo un portátil donde llevo desde Fedora 26 a Fdora 32, todo con actualizaciones de sistema.
En todo caso, prefiero usar una version un tanto antigua, en pro de la estabilidad. La unica razon para usar algo a pelo seria muy extrema para mi. En muchos casos me os encuentro con pip o gem, y si se trata de algo mas ratito como algo de escritorio... en esa caso tal vez si que algunas distros siq ue lo tienen un poco mejor que otras.
Pero vaya, algo como esto:
https://gitlab.com/corectrl/corectrl
Cuesta tanto esto?
Como lo instalo:
dnf install corectrl
keybase 14 kB/s | 3.3 kB 00:00
Slack 709 B/s | 1.0 kB 00:01
Dependencies resolved.
...
...
Installed:
botan2-2.11.0-2.fc31.x86_64 corectrl-1.0.8-1.fc31.x86_64 qt5-qtcharts-5.13.2-1.fc31.x86_64 vulkan-tools-1.2.131.1-1.fc31.x86_64
Complete!
menos de 30 segundos!
Cual es el problema, para que cojones quiero un flatpack o un snap o tros mierdos?
#82 yo no defiendo los snapd o los flatpak. Pero aunque anthk me fíjese ayer como hacer un chroot a mi solo me ha salido una vez. Es una alternativa en casos extremos. Es como alien o debtap. Sólo los vas a usar en el caso de que no haya otra opción.
Y luego hay gente que tiene burradas de espacio y quieren aislar procesos. Yo ni una cosa. Ni I la otra.
#13 snap trae todas las librerías de las que depende el ejecutable y además se monta en un sistema de ficheros virtual y controla los permisos al estilo android (acceso a webcam, micrófono, ficheros...)
Tiene sus desventajas y sus ventajas... La genteo "odia" porque los paquetes están aún un poco verdes y los permisos y demás fallan mucho pero si el paquete está bien hecho no dan mayor problema. Lo único que ya no los controlas con apt y como cada paquete instala todas las dependencias abultan más ...
#13 Linkados estáticos VS linkados dinámicos
Si usas windows, y buscas en tu disco duro archivos llamados msvcr*.dll -por ejemplo- verás que tienes docenas de archivos con el mismo nombre: el .dll es una libreria y cada programa lleva las suyas. Esto tiene la parte positiva de que cada programa lleva las suyas (y no hay problemas de incompatibilidad de versiones) y tiene la parte negativa que a veces tienes 20, 30 o 40.. o 100 copias de cada libreria en el disco duro (y hay muchas comunes). Cuando tienes muchos programas instalados, a veces se llega al absurdo.
Si usas linux, solo tienes una libreria de cada, aunque a veces traiga algun problema de incompatibilidad de versiones.
Snap pretende traer el sistema de windows (linkados estáticos) a linux (linkados dinámicos) y la gente no quiere, porque vino a linux huyendo de windows
Está bien para instalar algún programa de pago concreto, y que no de problemas de compatibilidades, pero si, que venga todo asi es un horror.
#13 es odiado porque es una puta mierda.
Te hace un jail (jaula) donde instala todo, pero no tienes acceso directo a eso, por lo que, por ejemplo, si tienes el /home en otro sistema, pues te jodes. Suele ser más lento, más "oculto" y menos visible, tiene su propio buscardor de programas, que es una mierda... es el típico:
https://imgs.xkcd.com/comics/standards.png
Lo utilicé unas horas (por programas que sólo estaan ahí) hasta que me cansé y lo desinstalé y a tirar con wine para lo que necesitaba...
#13 Normalmente la distribución de software en las distribuciones es centralizada: tú tienes un repositorio de aplicaciones, mantenidas, parcheadas, compiladas y verificadas y de las que te puedes fiar. Al instalar directamente binarios confiables, tienes un rendimiento "extra" y un menor consumo de recursos, y al estar compilados pensando en tu distro, tienen una mejor integración con el ecosistema de aplicaciones.
Si necesitas un software que no está en tu distribución, siempre puedes compilarlo o descargarlo a pelo y ponerlo en algún lado (y tener suerte con las dependencias, claro) o instalar un nuevo repositorio de aplicaciones externo. Todo esto tiene implicaciones en la seguridad y estabilidad de tu distro, lo usas bajo tu propio riesgo.
Esto sería lo que hace un .deb o un .rpm a grandes rasgos.
Snap es un sistema de paquetes tipo android (.apk); aunque puede ser la distro quien los empaquete, la gracia está en que cualquiera puede hacer un paquete y al meterse en un entorno aislado y poder controlar qué permisos y qué accesos puede tener a los recursos del sistema, se supone que es seguro tenerlas (se supone, mira a android :P). Aunque la distribución de snaps está centralizada en una tienda (la tienda de software de ubuntu, snapcraft), puedes descargar snaps de cualquier lado. La ventaja es que puedes instalar software sin preocuparte de las dependencias y sabiendo que va a funcionar software viejuno o más moderno que tu distro porque cada aplicación lleva su entorno de ejecución.
El problema es cómo está haciendo ubuntu para implantar snap como herramienta de facto de empaquetado de aplicaciones (ya sabes que hay otras alternativas, como appimage o flatpak, cada una con sus ventajas y sus desventajas). Por lo pronto, al contrario que otras distros donde el centro de software está conectado con el repositorio (o sea, con .debs o .rpms) está conectado con snapcraft, con lo que todo lo que instales más allá del sistema base son snaps (con el aumento de consumo de recursos y la disminución en la respuesta del sistema, haciendo la distro menos adecuada para equipos más modestos).
Y de lo que se queja específicamente linux mint: han convertido al menos algunos paquetes .deb en falsos paquetes que simplemente se encargan de descargar el snap correspondiente, de manera que las personas que no quieran trabajar con snaps y se estuvieran instalando las aplicaciones a pelo en lugar de desde el centro de software/tienda de ubuntu estarían instalándose snaps igualmente. Ubuntu se escuda en decir que lo hacen por cuestiones de seguridad, para proteger a la gente, Mint opina que lo hacen adrede y que están haciendo daño a las distros basadas en ubuntu que no quieren seguir sus pasos en torno a que todas las aplicaciones se instalen como snaps.
Snap de por si no creo que sea odiado (más allá de si es la mejor solución técnica al problema del empaquetado y los piques con otras opciones como appimage o flatpak), sino la forma de obligarte a usarlo y la forma de intentar que otras distros tengan que hacerlo también (recordemos que Linux Mint tiene tantos usuarios o más que ubuntu, y la misma ubuntu dice que más de la mitad de paquetes snap descargados de la tienda e instalados son por parte de usuarios de Mint).
#54 genial haber servido de ayuda. Abrí Gimp y no lo encontraba y ya estaba pensando 😨 "me he vuelto a colar".
Yo no uso esa herramienta. Solo hago foto manipulaciones y recortes.
Esta noticia es la continuación a Linux Mint se planta con Snap por Chromium, pero no aporta soluciones
Linux Mint se planta con Snap por Chromium, pero n...
muylinux.comYo hace años entendí que para ciertos aspectos da igual software libre que privado, el problema está en la arrogancia del ser humano y por desgracia en el mundo open source se ve mucho más.
En el mundo de Linux para servidores parece que se ponen más de acuerdo, quizá porque hay dinero de por medio, pero en el mundo desktop siguen con las mismas batallitas dentro de la comunidad que hace 15 años y ya empiezan a aburrir a los usuarios.
#9 A mí lo que me alucina de los proyectos de software libre es que desprecian al usuario de forma constante excepto honrosas excepciones como Blender que se está poniendo las pilas desde hace tiempo con la experiencia de usuario o Krita que está diseñado alrededor de lo que necesita el usuario y no la decisión arbitraria del programador con complejo de superioridad de turno y que no va a usarlo jamás.
#17 Define el desprecio a el usuario. Porque la ultima hornada de interfaces planas en Windows e incluso OSX las hace inusables en PCs.
Si te refieres al pasado de Gimp multiventana... ten en cuenta que Gimp fue disenyado con escritorios virtuales en mente, y no con escritorios limitados como los de Windows y Mac.
#22 Windows ahora tiene escritorios virtuales y antes los podías poner con programas de terceros aunque no sé en qué ayuda eso al Gimp multiventana ¿no te referirás a varios monitores?
Gimp tiene mala usabilidad y no por las multiventanas sino porque no puedes hacer, p ej, algo tan simple como rotar, redimensionar y mover la imagen sin tener que estar cambiando entre las herramientas de rotar, redimensionar y mover.
#49 estás desactualizado. Ya se ha unificado en una sola herramienta.
#50 Tengo la última versión y sigo necesitando cambiar de herramienta. ¿cómo se hace? porque es incómodo cambiar de herramientas para eso.
#52 a lo mejor me he colado y tienes razón pero pensaba que la Herramienta de transformación unificada (Mayús+T) hacía eso mismo. Uso GIMP 2.10.18
#53 Eso es, yo no lo hacía así. Gracias porque de la otra forma me resultaba incómodo.
#9 Sencillo y fácil. Usa.Windows.o OS.
#9 yo también quiero que todos los coches sean exactamente iguales.
Snap es malo pero flatpak no se queda corto, no me sorprende en absoluto que Mint hay decidido eliminarlos y que Ubuntu que ahora es amiguito de M$ esté por lo contrario para llenar de mierda el sistema fuera de control de dependencias. Si lo que se busca es un empaquetado estático me parece mejor solución los appimage, muchas aplicaciones pequeñas están optando por publicar estos empaquetados.
#31 Pues a mi me parecen unos inventazos tanto, flatpak como snap. Te permite instalar algo con todas sus dependencias, luego si lo desinstalas, lo hace de forma limpia. Está bien para cuando quieres probar la última versión de un programa, pero no quieres estar actualizando librerías del sistema. No entiendo por qué tanto odio.
#37 Para pruebas está.bien. Para trabajo no sirven
#37 Todo depende de cómo se use. Un flatpak con firefox es perfecto. Vim... no.
#59 Para las cosas que uso a menudo como firefox y vim, prefiero usar el apt.
Van camino de windows 11
Tanto odian a Mint?
Criticamos a los snaps e introducen los controladores privativos de NVIDIA en la ISO. Muy bien, Clement.
Yo no hablo de Linux que me llevo negativos
#6.
#6 efectivamente