Después de casi una década utilizando Linux de forma exclusiva en todos y cada uno de mis equipos tengo la sensación que la gente cuando me dice que Linux es demasiado complicado ¡tiene razón!
Personalmente considero que hemos perdido una gran oportunidad y no hemos sabido aprovechar la gran ventaja (imitada por otros sistemas como podría ser el Play Store de Android o el Mac App Store de Apple) que suponían los gestores de paquetes (con Synaptic por bandera) frente a la búsqueda de instaladores (esquivando publicidad y fakes) en Windows o Mac.
Problema
Pero el problema al que quiero hacer referencia hoy es otro; quiero manifestar mi malestar y pesar frente a lo complicado que puede llegar a ser instalar programas en Linux.
Por muy sencillo que pueda parecer buscar en los repositorios determinada aplicación hay ocasiones (más de las deseables) en la que los programas, simplemente, no pueden ser instalados debido a la existencia en el sistema de librerías (de las que depende) obsoletas o más recientes de lo esperado por el programa que quieres instalar.
En mi caso particular, con las actualizaciones de Arch Linux (o cuando he tenido que instalar algo en los Guadalinex del instituto con su Ubuntu subyacente) siempre me echo a temblar ante las consecuencias que puede tener la actualización de determinadas librerías (de las que dependen «demasiados» programas). Por poner un par de ejemplos
- Actualizar TexLive me puede mandar el programa Pyromaths a la inopia o
- Tratar de instalar Deepin Screenshot puede resultar totalmente imposible
La «competencia»
No diré que la política de instalación adoptada por Microsoft sea más eficiente pues, ya en mi época de desarrollador para Windows (todos tenemos un pasado «oscuro» ;)), tener que lidiar con lo que se denominaba el «infierno de las DLLs» se convirtió en un auténtico quebradero de cabeza. Eso sí, no cabe duda que, para el usuario final, resulta más sencillo poder hacer doble click sobre el ejecutable y dejar que sea el instalador el que se encargue de instalar todo aquello que se necesite.
Apple por contra lo hace infinitamente mejor (deberíamos aprender de ellos): hasta donde tengo entendido (mi urticaria por la «manzanita» me impide acercarme demasiado) instalar una aplicación es tan sencillo como arrastrar el paquete a la carpeta Aplicaciones o hacer doble click sobre él (si ando muy confundido agradeceré comentario). Por lo que parece, y creo que es fantástico, los paquetes de instalación no son mas que archivos comprimidos con todo lo que necesita (dependencias) para funcionar. La única preocupación debe ser encontrar la aplicación para la versión concreta de tu sistema operativo (Snow Leopard, Tiger, …)
Mi opinión
Entiendo que cuando las conexiones a Internet eran caras y lentas la mejor solución pasaba por crear paquetes lo más pequeños posibles (y el uso de mirrors cercanos) y reutilizar todo aquello descargado (e instalado) previamente. En este contexto, el uso de librerías tenía sentido. A día de hoy, en el que
- la inmensa mayoría contamos con ADSL sin limitaciones
- el precio/GB de los dispositivos de almacenamiento se encuentra en unos precios más que aceptables
no creo que merezca la pena andar «enredando» con dependencias rotas o inexistentes.
Prefiero volver a la época del MS-DOS en la que pasarle un programa a alguien era tan sencillo como copiar la carpeta (comprimiendo si no te cabía en el disquete de 1.4MB y/o 720KB) y al llevarla a otro equipo (metiéndolo en la entrada de directorio que te diese la gana) funcionaba sin problemas.
Actualmente creo que es Apple (y negaré haberlo dicho) la que mejor lo está haciendo.
Tecnológicamente es totalmente posible usarlo en nuestro querido pingüino; y estoy pensando tanto en
- la compilación estática
- como en las aplicaciones portables
como vías para llevarlo a cabo.
Vuestro parecer
Y vosotros
- ¿soléis pelear a la hora de instalar programas?
- ¿cuántas veces os han comentado que Linux es demasiado «complicado»?
- ¿qué solución daríais para facilitar la instalación de aplicaciones?
- ¿consideráis que (la inmensa mayoría) las librerías deberían ser «abolidas»?
- …
Informático de Guardia 
Si bien comparto hasta cierto punto tu opinión de que llega a ser un dolor de trasero el tener que satisfacer dependencias y que las conexiones a Internet (y agregaría que el espacio en disco) ya no son una buena razón para tener bibliotecas separadas
Por otro lado considero que a la hora de (y corríjanme si estoy en lo equivocado) ejecutar programas el hecho de tener una sola biblioteca que sea llamada por todos ellos ahorra el consumo de RAM y con ello no se sobrecarga el sistema, algo bastante benéfico para uno que no se puede dar el lujo de cambiar de PC muy seguido y que permite usar sistemas más o menos actualizados en equipos relativamente viejos.
Una vez dicho esto, creo que, al igual que tú, la manzana hace las cosas de la forma más simple (claro que también negaré haber dicho esto xD).
Me gustaMe gusta
Sospecho que es mucho mejor tener N librerías independientes que una mastodóntica puesto que las primeras pueden ser cargadas y/o descargadas en función de la disponibilidad de memoria en el sistema (la grande debería ser cargada completamente para hacer una simple llamada a una de sus «funciones»)
Personalmente apuesto por que cada aplicación tenga una copia (aunque se «desperdicie» espacio en disco) de las librerías que necesita de modo que siempre funcione (por haberse ocupado de incluir todo lo que necesita) sin tener que depender de que en el sistema se encuentre la misma versión que había cuando se compiló o una compatible
Me gustaMe gusta
Sí, tu punto no deja de ser válido en ningún sentido.
La realidad es que muchas veces me ha tocado sufrir infiernos por que tengo problemas con reproductores multimedia y cosas así que no tienen la biblioteca adecuada en repositorios, que si otros tienen, pero el primero no, etc.
No me imagino la migraña que has de pasar con una rolling release como Arch.
Me gustaMe gusta
Touché… Arch, a pesar de tener un gran soporte y una gran recopilación de programas puede llegar a ser «mortal» en ciertas actualizaciones del sistema.
A pesar de todo, la prefiero a otras (como Ubuntu) con ciclos semestrales de actualización
Me gustaMe gusta
Totalmente de acuerdo, las dependencias pueden convertirse en un infierno.
Cuando la aplicación en cuestión se encuentra en el repositorio de la distro ningún problema, pero cuando hay que tirar de apps externas la cosa cambia y perfectamente puedes quedarte sin poder instalarla.
Por ello, y en mi opinión, siempre hay que tener en cuenta para escoger una distro que ésta tenga un buen soporte por parte de los desarrolladores externos. Para este cometido, Ubuntu se lleva el premio gordo y, en menor medida, Debian en su versión estable. Las demás, tristemente, están todavía más marginadas por los desarrolladores externos.
Me gustaMe gusta
Incluso con Ubuntu he tenido problemas de este tipo 😦
Cada día estoy más convencido que el truco es no tener que «depender» de nadie 😉
Me gustaMe gusta
A mí me gustaría que fuese más fácil compilar programas. Por ejemplo para instalar http://shapebugs.org/software/ este software me he instalado sin problemas tcl tcl-dev tk-dev tk librerías de xpm que no tenía, hdf5 y los programas requeridos. Aún así aunque hago
./configure -with-xpmlibdir=/usr/lib/ –with-tcldir=/usr/include/tcl8.5/ me pregunta por el lugar de tcl aunque se lo estoy especificando y no me deja compilar. Siempre que quiero instalar algo medianamente extraño me enfrento a estos problemas de compilación.
Sería genial por ejemplo poder instalar algo con todas sus dependencias en un directorio aparte sin que afectara al resto de la instalación aunque haya dependencias duplicadas. Es decir, cuando finalmente me harte de estar en Ubuntu 11.10 y me pase a Ubuntu 14.04 me quedaré sin Amarok 1.4 y un montón de programas que he compilado en Ubuntu 11.10 y de los que yo sepa no hay ninguna manera para meterlos “directamente” en Ubuntu 14.10.
También eso me fastidió con GIMP, porque no hubo manera de instalar GIMP 2.8 y después de estar años con GIMP 2.7 (en mi opinión aunque versión de desarrollo es mucho mejor) pues tener que volver a GIMP 2.6 fue muy duro.
En resumidas cuentas, el método de instalación en la compilación debería ser más sencillo. No digo que se abandone la compilación, para nada, puesto que es una herramienta muy útil, pero realmente en menos del 75% he conseguido instalar algo a través de compilaciones (puesto que también hay que compilar dependencias).
Además cada paquete requiere un montón de cosas que instalar que a lo mejor ya están en el sistema, pero eso significa que no tienes control sobre lo que has instalado y si quieres recrearlo en otro ordenador (o una vez actualizado) pues tendrías que tener una lista de todo lo que has hecho y todos los programas que has instalado. Yo lo he intentado (también con el historial) pero no lo he conseguido.
Hace poco descubrí una utilidad en ubuntu (de hecho en el FAQ de Ubuntu sobre compilar) que era una herramienta que registraba en apt los paquetes compilados por make. Aún no lo he usado pero considero que esa herramienta debería venir por defecto y explicarse en los INSTALL.
Con respecto a Mac y Windows, considero que lo hacen todo muchísimo más chapuceramente y la situación es peor que en la peor de las pesadillas de un linuxero.
En windows ni siquiera sabes lo que instalas ni donde está y en Mac más de lo mismo, aunque sea un bastardo de Unix luego al desinstalar deja mucha mierda detrás.
El único aspecto positivo de las aplicaciones en windows sea quizás eso de que no necesitan dependencias, pero igualmente no puedes usar nada a nivel de usuario (es decir, con firefox en un linux no necesitas instalar nada, lo descomprimes y ya lo tienes).
También en Linux hecho de menos aplicaciones portables.
Saludos
Me gustaMe gusta
Ni en python utilizando pip (y con todas las librerías indicados en la sección de importaciones) es sencillo que el programa termine funcionando en algunos equipos.
Me gustaMe gusta
creo que mis comentarios no han llegado por poner mal el correo o algo.
Me gustaMe gusta
O algo… habías sido etiquetado como spam por WordPress 😛
Me gustaMe gusta
Creo que has dado en el clavo, no depender de nadie. A veces son un infierno y ya ni te cuento cuando quieres generar un .exe de algún proyecto creado en Linux.
Me gustaMe gusta
Depender, depender… ni de la mujer 😉
Por cierto Rafa ¿qué has estado «empaquetando» para Windows? (me tienes intrigado)
Me gustaMe gusta
pues yo.como bicho raro diré que en.mis tiempos que cacharreaba el pc la que me dio menos problemas fue arch.Despues y con mucha diferencia fedora o Centos.Me parece increible que rpm maneja mejor las dependencias que .deb hubiendo más distros de esta ultima. Centos los problemas que tuve fue con los gestores de red a.k.a. (NetworkManager y wicd).En fedora solo me pasaba con lxde (probablemente por mi tarjeta de wifi una de esas broadcom 4318).Es más fedora fue la unica distro después de arch que me mantuvo quieto.creo que dure un año.opensuse nunca la llegue a probar.pero guardo unos recuerdos maravillosos de yum sin duda. linux complicado? ?? si, pero menos que antes gracias a ubuntu
Me gustaMe gusta
Me estás animando a probar Fedora (que junto a Debian Testing se encontraba en la lista de distros a probar antes de volver, o no, a Arch), ¡qué lo sepas! 😉
Me gustaMe gusta
Este tema es bastante interesante y que debería de ser algo prioritario para mejorar la experiencia de usuario en GNU/Linux. Según mi propia experiencia, esta problemática se acentúa mucho en las distribuciones derivadas o basadas en Debian, incluyendo a esta última (levante la mano a quien no le ha aparecido el famoso mensaje «existen paquetes retenidos o rotos»), viéndose el usuario forzado a cambiar entre las distintas ramas (testing, unstable, etc.) para tratar de resolver esta situación. Con las distribuciones que utilizan paquetería RPM no es muy frecuente que surjan situaciones como esta por lo que he apreciado…
Al igual que tu pienso que adoptar el sistema de bundles como un estándar para la instalación de aplicaciones en GNU/Linux traería muchas más ventajas que desventajas, ya que sus bondades no solo se apreciarían al momento de instalar, sino también al momento de desinstalar programas, ya que de esta forma se disminuiría considerablemente la mala práctica de la conservación de «paquetes huerfanos» o dependencias innecesarias, y digo práctica ya que algunos gestores de paquetes no cumplen con la tarea de remover todo aquello que ya no es útil para el sistema o su desempeño deja mucho que desear.
Por otro lado, permíteme resaltar que PC-BSD recientemente ha adoptado el uso de bundles para la instalación de aplicaciones pensando precisamente en estos aspectos, por lo que ya no tendremos la necesidad de «establecer» a Mac como estandarte probunldes :).
Me gustaMe gusta
Fantástica aportación Ícaro, ¡gracias!
Verás que al final me voy a tener que ir a BSD 😉
Me gustaMe gusta
El sistema de incluir todo dentro del paquete resuelve el problema de las dependencias pero a costa de:
1- Un mayor espacio en disco duro
2- Un mayor uso de memoria RAM, al cargar varias versiones (o incluso la misma pero compilada diferente) de librerías en memoria.
3- La actualización de una librería supondría descargas mucho más grandes al tener que actualizar un montón de paquetes y no sólo la librería que usan todos ellos. Esto podría reducirse parcialmente con un sistema de parches sobre paquetes que sólo incluya los cambios.
4- Debian por ejemplo soporta 13 arquitecturas. debido a los puntos 1 y 3, los repositorios aumentarían en varios órdenes de magnitud el espacio y el ancho de banda usados.
5- Se pierde la modularidad de la que hacen gala los sistemas herederos de Unix: hacer programas que hagan una sola función pero que la hagan bien, y luego interconectarlos para hacer cosas más grandes.
6- La facilidad de instalar paquetes de otros sitios, también implicaría un menor control sobre la seguridad/estabilidad del sistema pues si en algún paquete no se actualiza una librería que tiene un fallo importante de seguridad te puedes quedar con un programa que suponga un riesgo. Esto ya te puede ocurrir, pero si resulta muy fácil, es más probable que se haga y que por tanto se pierda más control.
Creo que no me dejo nada, de hecho los puntos 5 y 6 son de menos importancia relativa.
Me gustaMe gusta
El punto 6 suena interesante; es cierto que no todos los desarrolladores aplican de inmediato los parches de seguridad.
Por otro lado Fedora ya hace lo que mencionas en el punto 3 sobre parches que solo incluyan los cambios, mediante el uso de paquetes delta.
Me gustaMe gusta
Vaya, veo que hemos coincidido en la importancia del punto 6 (la seguridad)
Considero que el matiz importante está en que sería responsabilidad del «empaquetador» mantener el «bundle» fuera de peligro y no del desarrollador.
El programador que haga lo que mejor sabe hacer y que el encargado de distribuirlo se preoucupe (una sola persona y una sola vez) de hacer funcionar el programa evitando al resto de usuarios tener que lidiar con las dependencias ¿no sería de agradecer?
Me gustaMe gusta
No es tema baladí el de la seguridad aunque no quieras darle tanta importancia como al resto amigo Malki. No creo que se pierda, mas bien se delegaría en el autor del paquete (que no en el desarrollador) el tenerlo actualizado y evitar los posibles agujeros de seguridad que se pudiesen producir.
Me resulta interesante las actualizaciones «modo parche».
No creo que se pierda la modularidad del sistema: cada librería seguiría haciendo lo que mejor sabe hacer y, a partir de ella, seguiríamos construyendo cosas mayores y ¿mejores? pero sin dejar de funcionar cuando evolucione alguno de los componentes en los que nos basamos o no se encuentre en el sistema en el que queremos utilizar la aplicación.
El consumo de disco puede ser considerado despreciable y el de ram siempre podría tratar de solucionarse reutilizando las instancias en memoria en caso de coexistir dos versiones iguales en un instante de tiempo.
Me gustaMe gusta
Se paliaría en parte reutilizando librerías, pero incluso la misma versión de librería podría compilarla un empaquetador diferente a como lo hace otro y provocar que sean diferentes. Habría que estandarizar las opciones de compilación y tal parar tratar de aprovechar esto al máximo.
Hay que tener en cuenta que el software de GNU/Linux se actualiza más y mucho más rápido que el de Windows o MacOS. Eso dificulta cualquier tipo de gestión de versiones, sea vía dependencias o vía bundles. Windows y MacOS mantienen un base estable hasta que sacan una versión nueva e incluso entre versiones, para evitar incompatibilidades. En GNU/Linux hasta las bases se modifican y actualizan, manteniendo la compatibilidad, pero a veces no es posible, y ocurre más frecuentemente (debido a la mayor frecuencia de actualización) que en Windows y MacOS. El sistema de dependencias permite tener control de cambios incluso en las bases del sistema, para que no se líe parda.
Usar un sistema de bundles supongo que significaría tener bases estables durante un tiempo y trabajo añadido para mantener la retrocompatibilidad. O eso o hacer un sistema mixto de bundles para el software general pero con dependencias de las bases del sistema. ¿O me equivoco? No se como lo hacen en FreeBSD…
Me gustaMe gusta
Ubuntu intentará corregir este problema con los «clicks packages» en futuras versiones, estos paquetes no necesitará dependencia externa a ninguna librería ya que solo usará las librerías internas QT-5 incluidas por defecto en Ubuntu.
Me gustaMe gusta
En todos mis años de con GNU/Linux, solo he tenido un problema de este tipo, con las librerías de MySql, que gracias a los links symbolicos fue relativamente sencillo cambiar de una a otra. El motivo es que no instala prácticamente NADA que no venga de la distro oficial.
La solución es hacer compilación static, de esta manera, tus librerias/dlls están dentro del ejecutable, ignorando a las del sistema, o quizás , crear una especie de sandbox para esa aplicación, pero a veces, la licencia si haces uso de la static library, te obliga por ejemplo , a liberar los fuentes o comprar licencia.
El tema es que esto haría crear el espacio, generando un desperdicio considerable. Tendriamos libc hasta la sopa 😉
En Windows pasa exactamente igual, por eso lo del HELL DLL, y que me ha ocurrido una sola vez, con la OpenSSL que entra en conflicto con otra version instalada en el sistema por otro programa en el espacio del sistema, en vez de su propia carpeta.
Pero para mi, el tema de las dependencias, si está bien, es el mejor sistema que existe.
Me gustaMe gusta
Sí es cierto que cuando intentas instalar programas de terceros «que no están en los repos» puedes tener problemas de dependencias, pero en general como al compañero Rafa Carmona apenas he tenido problemas de este tipo.
Yo apenas necesito compilar en mi opensuse, si alguna aplicación no se encuentra en los repos oficiales seguro que alguien de la comunidad lo ha empaquetado para las versiones de la distro que están en mantenimiento así que es difícil encontrar problemas de este tipo.
Lo que sí me fastidia un poco es que las dependencias se llamen de manera diferente en según que distro, en este sentido debería haber uniformidad. Hace poco me descargué una aplicación de la web de los autores de la misma empaquetada en rpm también está en deb para opensuse y me dió error al instalar porque no se cumplía una dependencia. El tema es que la dependencia sí estaba instalada pero con un nombre diferente, por suerte me dio por buscar la dependencia, por lo que al final instalé el paquete ignorando sus dependencias y funcionó sin problemas, a un usuario novato estas cosas le matan, por eso hecho en falta a veces más uniformidad en linux.
Por cierto para el autor, no te recomiendo debian testing para nada. Dejé un buen tiempo opensuse para probar debian, en su momento me instalé la testing «wheezy» que ya tenía tiempo de salida y me fue bien pero cuando se congeló y pasó a estable, permanecí un mes en estable porque los usuarios no me recomendaban tan pronto el paso a testing hasta que pasara unos 3 o 4 meses aprox. para que madurara un poco.
El tema que como en ese momento tenía kde 4.8 y necesitaba nuevas características de kde 4.10, al mes me pasé a testing de nuevo aunque aún no había llegado la nueva versión de kde a esta rama pero para testear como iba la cosa y al cabo de varias actualizaciones me dejaron de funcionar bien algunas cosas y no pude arreglarlo. Por eso los usuarios que usan debian la mayoría me recomendaban quedarme en estable porque como me pasó a mí, supongo que también en testing tuvieron lo suyo. Debian estable está bien para entornos en producción pero no lo veo para pc doméstico aunque para gustos colores 🙂 y testing al contrario de lo que otros dicen no es una roca.
Al final me volví a opensuse que me funciona mejor y encima no tengo que estar esperando durante muuucho tiempo por actualizaciones que necesito. No hay nada como probar las cosas uno mismo pero no tuve buena experiencia con testing y por algo muchos fan de debian recomiendan sólo estable.
Saludos.
Me gustaMe gusta
Yo uso Debian testing en mi sobremesa desde el año 2000 y mi portátil desde que lo tengo en 2008 o así sin problemas. Bueno, en 2005 o por ahí estuve un año con Kubuntu y luego me volví a Debian. He cambiado de ordenadores y de discos duros, pero jamás he reinstalado por eso, la misma Debian ha seguido funcionando (así que en mis sobremesas realmente sólo he instalado Debian 2 veces en 14 años). En el portátil sólo una instalación, aunque cambié el disco duro una vez.
Tengo los repositorios configurados para que apunten a «testing» y no al nombre de la que sea la testing actual. Jamás he parado de actualizar o cambiado a estable cuando congelan una estable, yo sigo en testing y punto. Se nota que en esas fechas hay muchas menos actualizaciones y que tras las actualizaciones entran muchas actualizaciones de golpe, pero sin más.
Eso sí, me considero usuario avanzado y si surge algún problema lo resuelvo no reinstalo. Para servidores uso Debian estable. OpenSuse la recomiendo para novatos y si yo no usara Debian, probablemente usaría OpenSuse. Yast es cojonudo. Eso sí, echaría de menos los paquetes deb, pero la familia Ubuntu no me convence.
Me gustaMe gusta
Gracias Javier por darme el bastón en un momento de «debilidad mental» y plantearme si sería excesivamente arriesgado tirar a Debian testing tras los comentarios de jony127 (gracias compi por compartir tus experiencias).
Llevo unos días con Fedora y ando bastante contento con el resultado (no añoro openSuse pero si Arch ;)). La única pega un comportamiento muy extraño al capturar las pantallas (no coincide lo que capturo con lo que selecciono ¿?)
Os mantendré informados
Me gustaMe gusta
Corrección al final del segundo párrafo: «y que tras la salida de la nueva versión entran muchas actualizaciones de golpe, pero sin más.
Me gustaMe gusta
Ahora sí cuadra (gracias)
Me gustaMe gusta
hola, a ver…..
A lo mejor mi comentario les hizo pensar que debian testing es un desastre y no lo es, pero tampoco es estable para eso está debian estable valga la redundancia. No quiero decir que por usar testing tras una actualización te vayas a quedar sin sistema porque rara vez se dará ese caso (no es como Arch en ese sentido que sí es más delicado el tema), pero sí te puedes encontrar con problemas que antes no tenías sobre todo recién liberada la nueva testing.
Comentario como el de Malkavian los he leído a montones pero también de usuario habituales de debian que no recomiendan testing precisamente por lo que yo menciono, si tienes suerte puede que no te falle nada pero tampoco sería nada inusual que el sistema te falle por algún lado. Como dije arriba no hay nada como probar las cosas uno mismo.
El problema que yo tuve fue con la paquetería, luego de varias actualizaciones synaptic y apper no me funcionaban bien, synaptic me daba errores hasta al refrescar la lista de paquetes y apper también tenía un comportamiento extraño. Gdebi la aplicación para instalar los .deb locales a golpe de clic me decía que no se encontraba el paquete cuando lo que estás instalando es un paquete local. Como vez, problemas para manejar la paquetería a través de interfaces gráficas y sólo podía instalar y actualizar a través de consola. Ni yo, ni con ayuda de los foreros di con la solución. Alguna petada del sistema con la actualización, al fin y al cabo es testing.
Tampoco soy usuario novato pero cuando un sistema peta pos eso, igual que lo han sufrido en sus carnes usuarios de Arch con conocimientos y al final han tenido que reinstalar. Además siempre he pesando y lo confirmo después de haberla usado que debian es para servidores y como mucho para desktop en empresas, pero la debian verdaderamente usable es la estable, lo demás es para pruebas/testeos.
Opensuse no es un sistema para novatos sino para cualquiera que quiera usarlo, como ubuntu, mint, fedora……. no por usar debian o arch se es necesariamente más experto que otro.
Me gustaMe gusta
En primer lugar, no he dicho que OpenSuse sea sólo para novatos y que Debian sea sólo para expertos. He dicho que recomiendo OpenSuse a los novatos porque me parece más fácil de usar para alguien que empieza en GNU/Linux. El hecho de que Yast te facilite la vida es un punto positivo para novatos y para expertos. A alguien experto le puede encantar OpenSuse perfectamente, ten en cuenta que he dicho que yo mismo la elijo para mí como segunda opción. No he querido menospreciarla ni menospreciarte en ningún momento y te pido disculpas si así lo ha parecido.
Yo jamás he oído recomendar Debian stable para escritorio, salvo que sea para trabajar y se quiera estabilidad a toda costa perdiendo la frescura de paquetes más nuevos. Es más, varias veces he oído decir que para Desktop unstable va muy bien y que no es tanto lío como podría parecer. Se que en unstable, a diferencia de testing, hay de vez en cuando dependencias que faltan durante un tiempo o paquetes muy poco probados. Luego ya, para desarrolladores está Debian experimental (que hace años no existía) y eso ya es un campo de minas…
La testing no se libera, lo que se libera es la estable. Al hacerlo la testing coge un nuevo nombre, pues el viejo pasa a ser el de la estable, pero hay un anuncio de nueva versión testing ni nada. De hecho lo que se dice es que ha sido liberada la estable con tal nombre, y la siguiente estable se llamará XXXX. No se habla del nombre de testing, sino del de la próxima estable, porque testing es una transición entre unstable y stable, y por ello un compromiso entre las novedades y la estabilidad.
Cuando sale una nueva Ubuntu, usa versiones de paquetes que están en Debian unstable y algunos en experimental, por eso el primer mes da muchos problemas hasta que luego se van solucionando. Ubuntu apenas recibe actualizaciones, salvo cosas de seguridad, digamos que está cuasi-congelada. Precisamente transcurrido 1 o 2 meses, los paquetes de testing comienzan a superar en novedad a los de Ubuntu, cosa que dura los siguientes 4 meses hasta la próxima Ubuntu. Esto lo comentó para que se pueda ver una comparativa en novedad y estabilidad entre Debian testing/unstable/experimental y Ubuntu, que es más conocida actualmente.
Me gustaMe gusta
Sí es cierto eso que comentas en cuanto a la novedad en testing con respecto a ubuntu por ejemplo, pero bueno, como no uso ubuntu pues eso me da igual.
Lo de la recomendación de estable para escritorio es precisamente porque testing cuando sale la nueva versión de la misma es como una bomba a punto de estallar, si tienes suerte puede que sigas sin problemas pero no es lo habitual, yo mismo lo sufrí cuando salió jessie y por eso simplemente la gente que suele usar debian recomiendan quedarse en estable al menos unos 4 o 5 meses después de que sale la nueva testing antes de cambiarse a ésta después.
Que problema veo con esto, que después de aguantar una congelación de testing durante 8 meses, tener que esperar otros 4 o 5 (por seguridad principalmente) para tener un kde más actualizado y con nuevas características, que en mi caso si las necesitaba, pues terminas simplemente aburriéndote de debian. Haz cálculo y te puedes pegar con el mismo kde más de un año y claro eso cansa y aburre.
Hay algunas actualizaciones que son muy recomendables porque adquieres aparte de posibles novedades que pueden resultarte útiles o no, sobre todo mejoras de rendimiento que eso sí que es apreciable, por ejemplo, en caso de kde con el escritorio semántico que está mucho más pulido en siguientes versiones, por eso principalmente estaba algo cansado de debian y por pasarme a testing en un mes después de salir jessie pues fallos que te pego, que igual a otro no le pasa pero bueno ahí queda.
Cuando se leen comentarios de usuarios de una distro que dicen que no la usan o recomiendan al menos hasta x meses porque es fácil encontrarte con problemas por algo será. Si te fijas lo mismo pasa con Arch, cuando hay usuarios que dicen que llevan 5 años o más sin ningún problema y otros que se quedan sin sistema de la noche a la mañana.
Al final cuando lees este tipo de comentarios sobre una distro o rama de la misma el resultado tarde o temprano termina siendo el mismo: problemas.
Aún así nadie duda de que debian es una de las distros más importante del ecosistema linux pero siempre la estable, por eso es difícil aconsejar debian para pc doméstico.
Saludos.
Me gustaMe gusta
Cuando se congela testing para sacar una nueva estable, lo que ocurre es que paquetes nuevos que estarían entrando en testing si no hubiera congelación, no entran pues la idea es depurar lo que hay y no añadir cosas si no es imprescindible para la estabilidad de la nueva estable. Las congelaciones no duran 8 meses, si no 2 ó 3 meses y durante ese tiempo, estar en testing es casi como estar en estable, obviamente. Cuando sale la nueva estable, ya no hay congelación y todas las novedades que tenían que haber entrado en testing, entran de golpe, de modo que de nuevo estás en testing normal y no debería haber problemas por recibir muchas actualizaciones de golpe.
Por ello, pasar a estable 4 o 5 meses al salir una nueva estable, me parece ridículo y jamás he oído recomendarlo (y conozco cientos (en plural) de personas que usan Debian). Si quieres usar testing, usas testing, no usas estable 4 ó 5 meses. Tendría mucha más lógica recomendar pasarse a unstable durante el período de congelación, aunque ello supondría tener cosas que no estarían en testing aún.
Me gustaMe gusta
hola de nuevo, creo y digo creo que estás equivocado en cuanto al tiempo de congelación de testing. La testing wheezy antes de pasar a estable estuvo congelada durante 8 meses yo la estuve usando, pero creo que esa versión fue un caso especial porque lo normal suelen ser sobre unos 6 creo.
De verdad piensas que testing puede pasar a considerarse la debian estable con tan solo 2 o 3 meses de congelación?? vamos como que no.
Recomendar debian unstable a alguien es de locos, eso es peor que Arch aunque nunca llegué a probar esa versión de debian, demasiado poco fiable para mí.
Si te comento que después de salir la nueva testing me recomendaron varios usarios de debian quedarme varios meses en estable es precisamente para que testing se asentara un poco, yo no les hice caso y al mes me pasé a testing cansado ya de la congelación de 8 meses y voilá por no hacerles caso empezaron los fallos.
Tal vez le tengas demasiada consideración a testing, es perfectamente usable pero no lo suficientemente sólida para trabajar al menos los primeros meses, después de eso es más difícil encontrarse con problemas.
Me gustaMe gusta
Añadir a lo anterior que igualmente ahí está testing disponible para todo el que quiera probarla/experimentarla en sus propias carnes, luego que cada uno saque sus propias conclusiones. ;
Me gustaMe gusta
Hola:
Solo quiero añadir a vuestro intercambio de opiniones que yo llevo unos doce años usando sid (inestable) diariamente en mi portátil y, aunque no llego al nivel de Malkavian de ir cambiando de disco duro no recuerdo grandes problemas (si recuerdo un problema con LVM y tuve que tirar del disco de instalación en modo rescate, y algún otro con los controladores de la red inalámbrica, bueno, ayude a resolver con mis pruebas un «bicho» de Debian). De hecho, he sufrido más problemas por ser usuario de PowerPC (un mac G4 al que duró OS X un mes, no, lo siento, tampoco es para mi) que por estar en inestable.
Aclaro que no soy ningún usuario super experto, me considero un usuario medio.
El error más serio que tuve con Sid es ponerla en un servidor, ¡ay, amigo! eso si fue un dolor.
Lo que no recomiendo es utilizar testing, a sabiendas del procedimiento que utiliza Debian, te puedes tirar meses con problemas de seguridad o de otra indole: los paquetes nuevos no entran en Testing hasta que no dan fallos en inestable.
Añado que también he tenido cosas instaladas de experimental, recuerdo que me pasé a una versión muy nueva de Xorg, y sin problemas.
Sin embargo, y en honor a la verdad, he de decir que este fin de semana, precisamente, he tenido que reinstalar Debian, algo se había corrompido en mi sistema que he sido incapaz de arreglar (por lo pronto el controlador Radeon me fallaba miserablemente). No me tiréis de la lengua pero os puedo decir que ha sido la instalación mas puñetera de mi vida, he pasado por todos los problemas habidos y por haber.
Para terminar, esa afirmación de que los paquetes de Testing/inestables son más modernos que los de Ubuntu… pues no será Kde porque yo todavía estoy con la 4.11 y solo ahora estoy viendo que están entrando algunos de la 4.12 en experimental.
Nada más, al final me ha quedado largo, lo siento.
Enhorabuena a Informático de Guardia por el blog, no lo sigo habitualmente pero ya he llegado más de una vez buscando alguna cosa.
Salud y Revolución.
Lobo.
Me gustaMe gusta
Gracias Lobo por tu «generosidad» en el comentario. Al final me he instalado la «puñetera» distro, me hubiese venido bien el comentario para no hacerlo ;P
Me gustaMe gusta
Ya te lo advertí yo antes, aunque siempre lo mejor es probar las cosas por uno mismo para salir de dudas, no siempre hay que fiarse de lo que dicen los demás pero si tenerlo en cuenta.
La razón que da RazLobo sobre los problemas de seguridad en testing es totalmente cierto, se me olvidó mencionar eso, es cierto que las correcciones de seguridad en testing no entran sobre la marcha, sino que antes esas correcciones tienen que pasar por sid. En debian estable lógicamente no hay problemas con eso.
Como también dice RazLobo ha estado 12 años con sid sin mayores problemas y recientemente ha tenido que reinstalar. Esto precisamente es lo que comentaba más arriba, que unos apenas en un año pueden sufrir problemas molestos y otros a lo mejor tiene la suerte de que aguantan mucho más pero al final algo les pasará, lo mismo que pasa con arch.
Por eso para mí, la única rama verdaderamente usable de debian es estable, el resto más bien para experimentar.
Me gustaMe gusta
Hace mucho que eso de la inseguridad de testing no es cierto. Hay repositorio de actualizaciones de seguridad para estable y para testing. Yo tengo esta línea en mi /etc/apt/sources.list
deb http://security.debian.org/ testing/updates main contrib non-free
Me gustaMe gusta
Sí, correcto que hay un repo para actualizaciones de seguridad en testing pero eso no quiere decir que entren inmediatamente porque todo lo que entra en testing primero tiene que pasar por sid.
Me gustaMe gusta
Las actualizaciones de seguridad, por su naturaleza y por el hecho de que este repositorio no existe para sid, no pasan por sid. De hecho anteun fallo grave una actualización entrata tanto en sid, como en testing y estable a la vez, si afecta a las 3.
Me gustaMe gusta
He llegado aquí desde G+ y no conocía tu blog, es un post muy interesante.
Y ya mismo te agrego a mi BlogRoll.. ;D
Me gustaMe gusta
Todo un placer que te hayas dejado «caer» por aquí Rene
Un saludo y bienvenido
Me gustaMe gusta