Re: devuan
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
Reply to: