El miércoles, 17 dic 2014, a las 18:15 horas (UTC+1), Camaleón escribió:
>El Wed, 17 Dec 2014 17:52:38 +0100, Manolo Díaz escribió: > >> El miércoles, 17 dic 2014, a las 15:22 horas (UTC+1), >> Camaleón escribió: >> >>>El Tue, 16 Dec 2014 19:55:16 +0100, Manolo Díaz escribió: >>> >>>> El martes, 16 dic 2014, a las 19:16 horas (UTC+1), >>>> Camaleón escribió: >>> >>>(...) >>> >>>>>El resto de paquetes no ha tenido un CTTE de por medio, pero este sí. >>>>>Es decir, no, no es lo mismo. Y no hay que olvidar del tipo de paquete >>>>>del que estamos hablando: un bug en el gestor de servicios (o en un >>>>>servicio que no se inicia con sysvinit) no tiene el mismo impacto que >>>>>un bug en una aplicación cualquiera. En el primer caso te puedes >>>>>quedar sin iniciar el sistema mientras que en el segundo a lo sumo te >>>>>quedas sin poner iniciar una aplicación. >>>> >>>> Claro que no tiene la misma implicación. Pero siguiendo tu línea >>>> argumental: ¿y si el paquete libc6 tiene un fallo? _Todo_ el sistema >>>> deja de funcionar. Hasta sysvinit-core depende de él y no hay >>>> alternativas. Lo mismo es válido para el núcleo. >>> >>>(...) >>> >>>Creo que o no entiendes o no quieres entender la problemática. >>> >>>Que yo sepa, libc6 sigue teniendo el mismo estatus que tenía hace un año >>>no así sysvinit que poco a poco va a quedar fuera de juego. >> >> Pues precisamente has puesto un mal ejemplo. > >El paquete (libc6) lo has elegido tú, no yo ;-) > >> Aunque el nombre del paquete no cambió, Wheezy usaba eglibc[1], >> mientras que Jessie vuelve a usar los fuentes de GNU. No hubo cruzada >> cuando se abandonó la biblioteca de GNU ni ahora, cuando se ha >> abandonado eglibc, aunque sí una lógica preocupación ante un cambio de >> tal magnitud. > >¿Y qué tiene que ver eso con lo que estamos hablando? :-? Todo. Se ha cambiado un paquete por otro distinto para el mismo fin (caso paralelo a sysvinit/systemd) sin que haya tanto jaleo. Donde se rompe el paralelismo es que con el sistema de inicio sí hay elección. >Independientemente de la fuente de la que se nutra la biblioteca, el >estado del paquete no ha variado: mismas dependencias, misma >compatibilidad, misma libertad... Es decir, ninguna. >todo igual. > >Ya me gustaría a mí que el cambio de sysvinit a systemd hubiera sido como >el de esta biblioteca. Mira, el ejemplo es perfecto: demuestra que las >cosas se pueden hacer bien, cuando se quiere. Pues fue un cambio mucho más brusco: no había posibilidad de gradación. Con systemd pude dar marcha atrás y volver a sysvinit porque coexistían en el repositorio. Con esa biblioteca no hubiese podido hacer nada excepto esperar a que resolviesen cualquier posible fallo. >> Sí que entiendo el problema: sysvinit está relegado a segundo plano >> actualmente y puede desaparecer de Debian en el futuro. Problema según >> quién, claro. > >Huy, según nadie... claro, claro, como nadie se ha quejado, no han >aparecido proyectos paralelos para evitar su uso, no hay un fork de la >base de Debian, etc... Teniendo en cuenta que muchas otras personas no han hecho nada parecido... pues eso, según quién. >> Pero lo que no comparto es atribuirle en exclusiva debilidades que >> están en todos los sistemas de inicio (punto único de fallo) o >> presentar un imaginado y siniestro futuro como realidad presente. > >En este caso, piensa mal y acertarás. Podrían haber hecho las cosas de >forma distinta, aún implementando systemd y dándole prioridad, podrían >haberlo hecho sin levantar tanta polvareda y sin enfadar a sus usuarios, >dándoles otra opción real... pero no. > >En fin, sólo espero que no se arrepientan. Si se arrepienten dan marcha atrás o eligen otro sistema de inicio. Esto no es el fin del mundo. Saludos. -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141217193330.05524...@gmail.com