Re: devuan
El Wed, 17 Dec 2014 19:33:30 +0100, Manolo Díaz escribió: El miércoles, 17 dic 2014, a las 18:15 horas (UTC+1), Camaleón escribió: (...) 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. (...) Si de verdad crees lo que estás diciendo es que no has entendido nada de lo que pasa o como ya te he dicho antes, no quieres entenderlo. Eres muy libre de pretender ignorar el problema aunque negando que exista ni lo evitas ni lo solucionas (que es la peor de las posturas), pero bueno, allá cada cual ¿no? ;-) Saludos, -- Camaleón -- 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/pan.2014.12.18.14.47...@gmail.com
Re: devuan
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. Saludos, -- Camaleón -- 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/pan.2014.12.17.14.22...@gmail.com
Re: devuan
El Tue, 16 Dec 2014 20:32:57 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 19:09 horas (UTC+1), Eduardo Rios escribió: No entiendo mucho del tema, pero parece ser que desde Jessie en adelante, para que todos los servicios funcionen correctamente, se depende de systemd. No. Si un servicio solo va a funcionar correctamente con systemd, te va a obligar a instalarlo. Eso no es lo que ha preguntado ;-) A partir de Jessie, systemd va a ser el gestor de servicios predeterminado y se va a potenciar su uso, no hay más vuelta de hoja. Todos los scripts de inicio se van a hacer pensando en systemd y probado en/por/para systemd. El kernel, las aplicaciones, los entornos de escritorio pro-systemd (gnome) y el resto de servicios todos sin excepción dirigen sus pasos hacia systemd. Upstart y sysvinit quedan en el banquillo, relegados a un segundo puesto. Vale, no es necesario, pero si eliges cualquier otro, te arriesgas a que ciertos servicios no vayan o no lo hagan como esperas... No. Y en caso contrario solo hay que abrir un informe de fallo serio por carecer de una dependencia. Un paquete no puede alcanzar la distribución estable si cuenta con un solo fallo de este tipo sin corregir. https://www.debian.org/Bugs/Developer#severities Y si haces eso ya verás lo que tardan en degradar el informe de fallo a normal, que las prioridades las gestionan los mantenedores no los informantes. Y dependerá del mantenedor si corregir el problema o cuándo hacerlo. Entonces, entiendo que los desarrolladores se vuelquen con systemd y abandonen cualquier otro sistema de inicio. En Jessie no. En adelante cualquiera sabe. (...) Desde Jessie... sí. Ya me dirás, lo han puesto como predeterminado y han modificado los scripts de inicio de las aplicaciones y servicios para adaptarlos a systemd a todo correr... Saludos, -- Camaleón -- 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/pan.2014.12.17.15.02...@gmail.com
Re: devuan
El miércoles, 17 dic 2014, a las 16:02 horas (UTC+1), Camaleón escribió: El Tue, 16 Dec 2014 20:32:57 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 19:09 horas (UTC+1), Eduardo Rios escribió: No entiendo mucho del tema, pero parece ser que desde Jessie en adelante, para que todos los servicios funcionen correctamente, se depende de systemd. No. Si un servicio solo va a funcionar correctamente con systemd, te va a obligar a instalarlo. Eso no es lo que ha preguntado ;-) A partir de Jessie, systemd va a ser el gestor de servicios predeterminado y se va a potenciar su uso, no hay más vuelta de hoja. Todos los scripts de inicio se van a hacer pensando en systemd y probado en/por/para systemd. El kernel, las aplicaciones, los entornos de escritorio pro-systemd (gnome) y el resto de servicios todos sin excepción dirigen sus pasos hacia systemd. Eso es adivinación. Upstart y sysvinit quedan en el banquillo, relegados a un segundo puesto. Eso, en cambio, es algo que ocurre ahora, con Jessie. Vale, no es necesario, pero si eliges cualquier otro, te arriesgas a que ciertos servicios no vayan o no lo hagan como esperas... No. Y en caso contrario solo hay que abrir un informe de fallo serio por carecer de una dependencia. Un paquete no puede alcanzar la distribución estable si cuenta con un solo fallo de este tipo sin corregir. https://www.debian.org/Bugs/Developer#severities Y si haces eso ya verás lo que tardan en degradar el informe de fallo a normal, que las prioridades las gestionan los mantenedores no los informantes. Y dependerá del mantenedor si corregir el problema o cuándo hacerlo. Vuelves a adivinar. Pero no, no me imagino a los mantenedores degradando informes de fallos mientras cientos o miles de usuarios ven como sus servicios o su ordenador no se inician. Si quieren terminar para siempre el proyecto Debian imagino que los desarrolladores lo harán de forma más elegante. Personalmente me inclino por una de estas dos perspectivas. - Los fallos son resueltos con regularidad, como hasta ahora (Sí, incluida Jessie). - Los mantenedores/desarrolladores deciden que el exceso de trabajo no merece la pena y expulsan a sysvinit (o upstart) de Debian. Entonces, entiendo que los desarrolladores se vuelquen con systemd y abandonen cualquier otro sistema de inicio. En Jessie no. En adelante cualquiera sabe. (...) Desde Jessie... sí. Ya me dirás, lo han puesto como predeterminado y han modificado los scripts de inicio de las aplicaciones y servicios para adaptarlos a systemd a todo correr... Uso varios tipos de servicios: correo de sistema (postfix), servidor HTTP para el sistema de documentación de Debian (lighttpd), DNS caché (pdnsd), etc. Y todos sin excepción me funcionan perfectamente con sysvinit en Jessie. Esa situación de perfecto funcionamiento es del todo incompatible con la afirmación de abandono. 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/20141217174934.76b00...@gmail.com
Re: devuan
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. 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. 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. 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. [1] http://www.eglibc.org/home 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/20141217175238.104ea...@gmail.com
Re: devuan
El 17/12/14 a las 12:02, Camaleón escibió: El Tue, 16 Dec 2014 20:32:57 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 19:09 horas (UTC+1), Eduardo Rios escribió: No entiendo mucho del tema, pero parece ser que desde Jessie en adelante, para que todos los servicios funcionen correctamente, se depende de systemd. No. Si un servicio solo va a funcionar correctamente con systemd, te va a obligar a instalarlo. Eso no es lo que ha preguntado ;-) A partir de Jessie, systemd va a ser el gestor de servicios predeterminado y se va a potenciar su uso, no hay más vuelta de hoja. Todos los scripts de inicio se van a hacer pensando en systemd y probado en/por/para systemd. El kernel, las aplicaciones, los entornos de escritorio pro-systemd (gnome) y el resto de servicios todos sin excepción dirigen sus pasos hacia systemd. Upstart y sysvinit quedan en el banquillo, relegados a un segundo puesto. Vale, no es necesario, pero si eliges cualquier otro, te arriesgas a que ciertos servicios no vayan o no lo hagan como esperas... No. Y en caso contrario solo hay que abrir un informe de fallo serio por carecer de una dependencia. Un paquete no puede alcanzar la distribución estable si cuenta con un solo fallo de este tipo sin corregir. https://www.debian.org/Bugs/Developer#severities Y si haces eso ya verás lo que tardan en degradar el informe de fallo a normal, que las prioridades las gestionan los mantenedores no los informantes. Y dependerá del mantenedor si corregir el problema o cuándo hacerlo. Entonces, entiendo que los desarrolladores se vuelquen con systemd y abandonen cualquier otro sistema de inicio. En Jessie no. En adelante cualquiera sabe. (...) Desde Jessie... sí. Ya me dirás, lo han puesto como predeterminado y han modificado los scripts de inicio de las aplicaciones y servicios para adaptarlos a systemd a todo correr... Saludos, Entonces los usuarios comunes, finales, de escritorio como yo ¿En qué nos beneficia Systemd como gestor de inicio? ¿Qué deberemos ver o qué disfrutar? Porque se discute si es beneficioso o perjudicial. Ahora bien, sin saber lo que ustedes a nivel técnico infiero que si el gestor de inicio tendrá tantas dependencias, además de controlar los servicios del sistema es de pensar que si falla algo todo el sistema caerá al mejor estilo Windows. ¡Tamaño equipo de desarrollo debe tener systemd para soportar los fallos que irán apareciendo! ¿no? -- Sergio Bessopeanetto Buenos Aires - Argentina -- 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/5491b361.5020...@inbox.im
Re: devuan
El Wed, 17 Dec 2014 17:49:34 +0100, Manolo Díaz escribió: El miércoles, 17 dic 2014, a las 16:02 horas (UTC+1), Camaleón escribió: El Tue, 16 Dec 2014 20:32:57 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 19:09 horas (UTC+1), Eduardo Rios escribió: No entiendo mucho del tema, pero parece ser que desde Jessie en adelante, para que todos los servicios funcionen correctamente, se depende de systemd. No. Si un servicio solo va a funcionar correctamente con systemd, te va a obligar a instalarlo. Eso no es lo que ha preguntado ;-) A partir de Jessie, systemd va a ser el gestor de servicios predeterminado y se va a potenciar su uso, no hay más vuelta de hoja. Todos los scripts de inicio se van a hacer pensando en systemd y probado en/por/para systemd. El kernel, las aplicaciones, los entornos de escritorio pro-systemd (gnome) y el resto de servicios todos sin excepción dirigen sus pasos hacia systemd. Eso es adivinación. Para nada, es una realidad. Cosa aparte es que haya quien no quiera verlo o tenga miedo (¿?) de las consecuencias de afirmar que es así. Upstart y sysvinit quedan en el banquillo, relegados a un segundo puesto. Eso, en cambio, es algo que ocurre ahora, con Jessie. Pues eso es lo que estoy diciendo. Y repito que no hay nada de malo en esa decisión, todo proyecto debe autodefinirse y apostar por unas opciones u otras sólo que hay formas distintas de adoptarlas y en eso (en la forma de implementar systemd) creo que en Debian se han equivocado de pleno. Vale, no es necesario, pero si eliges cualquier otro, te arriesgas a que ciertos servicios no vayan o no lo hagan como esperas... No. Y en caso contrario solo hay que abrir un informe de fallo serio por carecer de una dependencia. Un paquete no puede alcanzar la distribución estable si cuenta con un solo fallo de este tipo sin corregir. https://www.debian.org/Bugs/Developer#severities Y si haces eso ya verás lo que tardan en degradar el informe de fallo a normal, que las prioridades las gestionan los mantenedores no los informantes. Y dependerá del mantenedor si corregir el problema o cuándo hacerlo. Vuelves a adivinar. Pocos informes de fallo habrás leído o seguido más allá de los que hayas puesto. De hecho, ajustar la prioridad de un informe de fallo es el procedimiento habitual. Pero no, no me imagino a los mantenedores degradando informes de fallos mientras cientos o miles de usuarios ven como sus servicios o su ordenador no se inician. Yo me lo imagino perfectamente. Es más (y ahora sí estoy adivinando) visualizo la respuesta: Verás, es que ahora el gestor de servicios es systemd y todos los paquetes se prueban contra systemd, ¿podrías instalarlo para ver si te funciona? El pobre informador incauto lo instala, le funciona y el bug queda cerrado a cal y canto. Al fin y al cabo, los empaquetadores saben (aunque no lo quieran decir en voz alta) que sysvinit no va a durar mucho. Si quieren terminar para siempre el proyecto Debian imagino que los desarrolladores lo harán de forma más elegante. Personalmente me inclino por una de estas dos perspectivas. - Los fallos son resueltos con regularidad, como hasta ahora (Sí, incluida Jessie). - Los mantenedores/desarrolladores deciden que el exceso de trabajo no merece la pena y expulsan a sysvinit (o upstart) de Debian. Supongo que ya sabrás cuál es la respuesta ¿no? :-) Entonces, entiendo que los desarrolladores se vuelquen con systemd y abandonen cualquier otro sistema de inicio. En Jessie no. En adelante cualquiera sabe. (...) Desde Jessie... sí. Ya me dirás, lo han puesto como predeterminado y han modificado los scripts de inicio de las aplicaciones y servicios para adaptarlos a systemd a todo correr... Uso varios tipos de servicios: correo de sistema (postfix), servidor HTTP para el sistema de documentación de Debian (lighttpd), DNS caché (pdnsd), etc. Y todos sin excepción me funcionan perfectamente con sysvinit en Jessie. Esa situación de perfecto funcionamiento es del todo incompatible con la afirmación de abandono. Cuando deje de funcionarte algo, hablamos. Cuando tengas que instalar una aplicación de terceros que no trabaje con systemd y tengas problemas con la compatibilidad de systemd y los scripts escritos para sysvinit, hablamos. Sigues sin entenderlo: no se trata de que tú o yo tengamos un problema o no lo tengamos, se trata de que a partir de jessie sysvinit va a ir desapareciendo del mapa y no sólo en Debian. Así lo han decidido, así está pasando y así va a ser. Saludos, -- Camaleón -- 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/pan.2014.12.17.17.04...@gmail.com
Re: devuan
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? :-? Independientemente de la fuente de la que se nutra la biblioteca, el estado del paquete no ha variado: mismas dependencias, misma compatibilidad, misma libertad... 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. 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... 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. Saludos, -- Camaleón -- 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/pan.2014.12.17.17.15...@gmail.com
Re: devuan
El Wed, 17 Dec 2014 13:46:25 -0300, Sergio Bessopeanetto escribió: El 17/12/14 a las 12:02, Camaleón escibió: El Tue, 16 Dec 2014 20:32:57 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 19:09 horas (UTC+1), Eduardo Rios escribió: (...) Entonces, entiendo que los desarrolladores se vuelquen con systemd y abandonen cualquier otro sistema de inicio. En Jessie no. En adelante cualquiera sabe. (...) Desde Jessie... sí. Ya me dirás, lo han puesto como predeterminado y han modificado los scripts de inicio de las aplicaciones y servicios para adaptarlos a systemd a todo correr... Entonces los usuarios comunes, finales, de escritorio como yo ¿En qué nos beneficia Systemd como gestor de inicio? ¿Qué deberemos ver o qué disfrutar? Porque se discute si es beneficioso o perjudicial. Ahora bien, sin saber lo que ustedes a nivel técnico infiero que si el gestor de inicio tendrá tantas dependencias, además de controlar los servicios del sistema es de pensar que si falla algo todo el sistema caerá al mejor estilo Windows. ¡Tamaño equipo de desarrollo debe tener systemd para soportar los fallos que irán apareciendo! ¿no? Para ser sinceros, en este momento ya no importan las ventajas o inconvenientes, systemd es lo que hay en linux y si quieres evitar su uso el laberinto en el que te vas a meter no te va a compensar. Yo nunca me paré a pensar en las ventajas o problemas de sysvinit: funcionaba, era compatible con la mayor parte de los entornos linux/bsd/ unix, hacía lo que se le pedía (una función), era modular y sencillo de depurar. Saludos, -- Camaleón -- 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/pan.2014.12.17.17.29...@gmail.com
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 -- 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
Re: devuan
El miércoles, 17 dic 2014, a las 18:04 horas (UTC+1), Camaleón escribió: El Wed, 17 Dec 2014 17:49:34 +0100, Manolo Díaz escribió: El miércoles, 17 dic 2014, a las 16:02 horas (UTC+1), Camaleón escribió: El Tue, 16 Dec 2014 20:32:57 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 19:09 horas (UTC+1), Eduardo Rios escribió: No entiendo mucho del tema, pero parece ser que desde Jessie en adelante, para que todos los servicios funcionen correctamente, se depende de systemd. No. Si un servicio solo va a funcionar correctamente con systemd, te va a obligar a instalarlo. Eso no es lo que ha preguntado ;-) A partir de Jessie, systemd va a ser el gestor de servicios predeterminado y se va a potenciar su uso, no hay más vuelta de hoja. Todos los scripts de inicio se van a hacer pensando en systemd y probado en/por/para systemd. El kernel, las aplicaciones, los entornos de escritorio pro-systemd (gnome) y el resto de servicios todos sin excepción dirigen sus pasos hacia systemd. Eso es adivinación. Para nada, es una realidad. Cosa aparte es que haya quien no quiera verlo o tenga miedo (¿?) de las consecuencias de afirmar que es así. Upstart y sysvinit quedan en el banquillo, relegados a un segundo puesto. Eso, en cambio, es algo que ocurre ahora, con Jessie. Pues eso es lo que estoy diciendo. Y repito que no hay nada de malo en esa decisión, todo proyecto debe autodefinirse y apostar por unas opciones u otras sólo que hay formas distintas de adoptarlas y en eso (en la forma de implementar systemd) creo que en Debian se han equivocado de pleno. Vale, no es necesario, pero si eliges cualquier otro, te arriesgas a que ciertos servicios no vayan o no lo hagan como esperas... No. Y en caso contrario solo hay que abrir un informe de fallo serio por carecer de una dependencia. Un paquete no puede alcanzar la distribución estable si cuenta con un solo fallo de este tipo sin corregir. https://www.debian.org/Bugs/Developer#severities Y si haces eso ya verás lo que tardan en degradar el informe de fallo a normal, que las prioridades las gestionan los mantenedores no los informantes. Y dependerá del mantenedor si corregir el problema o cuándo hacerlo. Vuelves a adivinar. Pocos informes de fallo habrás leído o seguido más allá de los que hayas puesto. De hecho, ajustar la prioridad de un informe de fallo es el procedimiento habitual. Sí, he visto reajustes en los dos sentidos, para aumentar o para disminuir la severidad. La desavenencia sobre la severidad real del fallo se da con cierta frecuencia. Lo que no he visto es conspiración. Pero no, no me imagino a los mantenedores degradando informes de fallos mientras cientos o miles de usuarios ven como sus servicios o su ordenador no se inician. Yo me lo imagino perfectamente. Es más (y ahora sí estoy adivinando) visualizo la respuesta: Verás, es que ahora el gestor de servicios es systemd y todos los paquetes se prueban contra systemd, ¿podrías instalarlo para ver si te funciona? El pobre informador incauto lo instala, le funciona y el bug queda cerrado a cal y canto. Al fin y al cabo, los empaquetadores saben (aunque no lo quieran decir en voz alta) que sysvinit no va a durar mucho. No tengo amistad con ninguno, así que no me han hecho ninguna confidencia al respecto pasada ya la quinta ronda de cervezas. Por cierto, ¿cómo lo sabes tú? Si quieren terminar para siempre el proyecto Debian imagino que los desarrolladores lo harán de forma más elegante. Personalmente me inclino por una de estas dos perspectivas. - Los fallos son resueltos con regularidad, como hasta ahora (Sí, incluida Jessie). - Los mantenedores/desarrolladores deciden que el exceso de trabajo no merece la pena y expulsan a sysvinit (o upstart) de Debian. Supongo que ya sabrás cuál es la respuesta ¿no? :-) No, pero lo sabré en un par de años. Entonces, entiendo que los desarrolladores se vuelquen con systemd y abandonen cualquier otro sistema de inicio. En Jessie no. En adelante cualquiera sabe. (...) Desde Jessie... sí. Ya me dirás, lo han puesto como predeterminado y han modificado los scripts de inicio de las aplicaciones y servicios para adaptarlos a systemd a todo correr... Uso varios tipos de servicios: correo de sistema (postfix), servidor HTTP para el sistema de documentación de Debian (lighttpd), DNS caché (pdnsd), etc. Y todos sin excepción me funcionan perfectamente con sysvinit en Jessie. Esa situación de perfecto funcionamiento es del todo incompatible con la afirmación de abandono. Cuando deje de funcionarte algo, hablamos. Cuando tengas que instalar una aplicación de terceros que no trabaje con systemd y tengas problemas con la compatibilidad de systemd y los scripts escritos para sysvinit, hablamos. Ese sería un argumento a favor de mantener a sysvinit. Sigues sin entenderlo: no se trata de que tú o yo tengamos un problema o no lo tengamos, se trata de que a partir de jessie sysvinit
Re: devuan
El martes, 16 dic 2014, a las 16:09 horas (UTC+1), Camaleón escribió: Es decir, que los problemas derivados de usar sysvinit se podrían rechazar/cerrar sin más en los informes de fallo dejando a los usuarios sin plena cobertura. Solo he visto que se dé ese caso cuando un paquete es expulsado del repositorio y ya no es mantenido, lo cuál tiene toda la lógica del mundo. Y ni siquiera en ese caso lo cierran sin más: los informadores son debidamente notificados sobre por qué se cierran. 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/20141216171630.11fe6...@gmail.com
Re: devuan
El Tue, 16 Dec 2014 17:16:30 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 16:09 horas (UTC+1), Camaleón escribió: Es decir, que los problemas derivados de usar sysvinit se podrían rechazar/cerrar sin más en los informes de fallo dejando a los usuarios sin plena cobertura. Solo he visto que se dé ese caso cuando un paquete es expulsado del repositorio y ya no es mantenido, lo cuál tiene toda la lógica del mundo. El problema es que depende completamente del empaquetador/mantenedor, y los hay que son un poco toca-narices (no sólo en Debian, ojo). No es la primera vez que un bug termina a debate en el CTTE porque el mantenedor de turno se enroca en una postura absurda y no hay quien lo saque de ahí. Para empeorar las cosas, con la excusa de que systemd es el sistema predeterminado en Jessie y de la reciente votación de no es necesario incidir en este punto pues deja todo en el aire, sin ningún tipo de garantía de cara al administrador que vaya a instalar Debian Jessie y que no quiera usar systemd. Y ni siquiera en ese caso lo cierran sin más: los informadores son debidamente notificados sobre por qué se cierran. Pues qué bien ¿y de qué sirve que te digan que lo cierran porque quieren? Pues de nada, es más, te deja peor el cuerpo. Saludos, -- Camaleón -- 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/pan.2014.12.16.16.40...@gmail.com
Re: devuan
El martes, 16 dic 2014, a las 17:40 horas (UTC+1), Camaleón escribió: El Tue, 16 Dec 2014 17:16:30 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 16:09 horas (UTC+1), Camaleón escribió: Es decir, que los problemas derivados de usar sysvinit se podrían rechazar/cerrar sin más en los informes de fallo dejando a los usuarios sin plena cobertura. Solo he visto que se dé ese caso cuando un paquete es expulsado del repositorio y ya no es mantenido, lo cuál tiene toda la lógica del mundo. El problema es que depende completamente del empaquetador/mantenedor, y los hay que son un poco toca-narices (no sólo en Debian, ojo). No es la primera vez que un bug termina a debate en el CTTE porque el mantenedor de turno se enroca en una postura absurda y no hay quien lo saque de ahí. Pero eso es general y válido para los más de 40.000 paquetes existentes. Aunque sería interesante saber cómo proceder en casos así... Para empeorar las cosas, con la excusa de que systemd es el sistema predeterminado en Jessie y de la reciente votación de no es necesario incidir en este punto pues deja todo en el aire, sin ningún tipo de garantía de cara al administrador que vaya a instalar Debian Jessie y que no quiera usar systemd. Y ni siquiera en ese caso lo cierran sin más: los informadores son debidamente notificados sobre por qué se cierran. Pues qué bien ¿y de qué sirve que te digan que lo cierran porque quieren? Pues de nada, es más, te deja peor el cuerpo. No, no es que lo cierren porque quieren. Lo cierran porque es absurdo tener abierto informes de fallos sobre un paquete que ya no existe (salvo en snapshot). En ese caso, además, recibes una notificación automática explicando el porqué. Y por lo que sé, únicamente se ha abandonado un paquete cuando es obsoleto e inservible, o cuando casi nadie lo usa y no hay mantenedor dispuesto a hacerse cargo. Saludos, 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/20141216185350.43a9f...@gmail.com
Re: devuan
El 16/12/14 a las 18:53, Manolo Díaz escribió: El martes, 16 dic 2014, a las 17:40 horas (UTC+1), Camaleón escribió: El Tue, 16 Dec 2014 17:16:30 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 16:09 horas (UTC+1), Camaleón escribió: Es decir, que los problemas derivados de usar sysvinit se podrían rechazar/cerrar sin más en los informes de fallo dejando a los usuarios sin plena cobertura. Solo he visto que se dé ese caso cuando un paquete es expulsado del repositorio y ya no es mantenido, lo cuál tiene toda la lógica del mundo. El problema es que depende completamente del empaquetador/mantenedor, y los hay que son un poco toca-narices (no sólo en Debian, ojo). No es la primera vez que un bug termina a debate en el CTTE porque el mantenedor de turno se enroca en una postura absurda y no hay quien lo saque de ahí. Pero eso es general y válido para los más de 40.000 paquetes existentes. Aunque sería interesante saber cómo proceder en casos así... Para empeorar las cosas, con la excusa de que systemd es el sistema predeterminado en Jessie y de la reciente votación de no es necesario incidir en este punto pues deja todo en el aire, sin ningún tipo de garantía de cara al administrador que vaya a instalar Debian Jessie y que no quiera usar systemd. Y ni siquiera en ese caso lo cierran sin más: los informadores son debidamente notificados sobre por qué se cierran. Pues qué bien ¿y de qué sirve que te digan que lo cierran porque quieren? Pues de nada, es más, te deja peor el cuerpo. No, no es que lo cierren porque quieren. Lo cierran porque es absurdo tener abierto informes de fallos sobre un paquete que ya no existe (salvo en snapshot). En ese caso, además, recibes una notificación automática explicando el porqué. Y por lo que sé, únicamente se ha abandonado un paquete cuando es obsoleto e inservible, o cuando casi nadie lo usa y no hay mantenedor dispuesto a hacerse cargo. Saludos, Saludos. No entiendo mucho del tema, pero parece ser que desde Jessie en adelante, para que todos los servicios funcionen correctamente, se depende de systemd. Vale, no es necesario, pero si eliges cualquier otro, te arriesgas a que ciertos servicios no vayan o no lo hagan como esperas... Entonces, entiendo que los desarrolladores se vuelquen con systemd y abandonen cualquier otro sistema de inicio. Y si es así, tiene razón Camaleon al decir que los usuarios que no usen systemd van a estar vendidos. ¿Es así, no? -- www.LinuxCounter.net Registered user #558467 has 2 linux machines -- 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/m6psgd$4b2$1...@ger.gmane.org
Re: devuan
El Tue, 16 Dec 2014 18:53:50 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 17:40 horas (UTC+1), Camaleón escribió: El Tue, 16 Dec 2014 17:16:30 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 16:09 horas (UTC+1), Camaleón escribió: Es decir, que los problemas derivados de usar sysvinit se podrían rechazar/cerrar sin más en los informes de fallo dejando a los usuarios sin plena cobertura. Solo he visto que se dé ese caso cuando un paquete es expulsado del repositorio y ya no es mantenido, lo cuál tiene toda la lógica del mundo. El problema es que depende completamente del empaquetador/mantenedor, y los hay que son un poco toca-narices (no sólo en Debian, ojo). No es la primera vez que un bug termina a debate en el CTTE porque el mantenedor de turno se enroca en una postura absurda y no hay quien lo saque de ahí. Pero eso es general y válido para los más de 40.000 paquetes existentes. Aunque sería interesante saber cómo proceder en casos así... 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. Para empeorar las cosas, con la excusa de que systemd es el sistema predeterminado en Jessie y de la reciente votación de no es necesario incidir en este punto pues deja todo en el aire, sin ningún tipo de garantía de cara al administrador que vaya a instalar Debian Jessie y que no quiera usar systemd. Y ni siquiera en ese caso lo cierran sin más: los informadores son debidamente notificados sobre por qué se cierran. Pues qué bien ¿y de qué sirve que te digan que lo cierran porque quieren? Pues de nada, es más, te deja peor el cuerpo. No, no es que lo cierren porque quieren. Lo cierran porque es absurdo tener abierto informes de fallos sobre un paquete que ya no existe (salvo en snapshot). En ese caso, además, recibes una notificación automática explicando el porqué. Estamos hablando de un hipotético bug que exista en los paquetes que sustituyen o reemplazan a systemd (upstart, sysvinit), es decir, paquetes que sí existen y no están obsoletos ni abandonados. Y por lo que sé, únicamente se ha abandonado un paquete cuando es obsoleto e inservible, o cuando casi nadie lo usa y no hay mantenedor dispuesto a hacerse cargo. No estamos hablando de esa situación. Saludos, -- Camaleón -- 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/pan.2014.12.16.18.16...@gmail.com
Re: devuan
El Tue, 16 Dec 2014 19:09:18 +0100, Eduardo Rios escribió: El 16/12/14 a las 18:53, Manolo Díaz escribió: El martes, 16 dic 2014, a las 17:40 horas (UTC+1), Camaleón escribió: (...) Pues qué bien ¿y de qué sirve que te digan que lo cierran porque quieren? Pues de nada, es más, te deja peor el cuerpo. No, no es que lo cierren porque quieren. Lo cierran porque es absurdo tener abierto informes de fallos sobre un paquete que ya no existe (salvo en snapshot). En ese caso, además, recibes una notificación automática explicando el porqué. Y por lo que sé, únicamente se ha abandonado un paquete cuando es obsoleto e inservible, o cuando casi nadie lo usa y no hay mantenedor dispuesto a hacerse cargo. No entiendo mucho del tema, pero parece ser que desde Jessie en adelante, para que todos los servicios funcionen correctamente, se depende de systemd. Vale, no es necesario, pero si eliges cualquier otro, te arriesgas a que ciertos servicios no vayan o no lo hagan como esperas... Entonces, entiendo que los desarrolladores se vuelquen con systemd y abandonen cualquier otro sistema de inicio. Y si es así, tiene razón Camaleon al decir que los usuarios que no usen systemd van a estar vendidos. ¿Es así, no? Sí, así lo veo yo y no encuentro nada malo en esa decisión (cada uno tomará las contramedidas que estime oportunas), lo que me molesta es que pretendan vendernos otra cosa cuando todos sabemos que no va a ser así. Un proyecto como Debian tiene que tomar sus propias decisiones pero lo que no se espera es la falta de transparencia. Saludos, -- Camaleón -- 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/pan.2014.12.16.18.37...@gmail.com
Re: devuan
El martes, 16 dic 2014, a las 19:16 horas (UTC+1), Camaleón escribió: El Tue, 16 Dec 2014 18:53:50 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 17:40 horas (UTC+1), Camaleón escribió: El Tue, 16 Dec 2014 17:16:30 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 16:09 horas (UTC+1), Camaleón escribió: Es decir, que los problemas derivados de usar sysvinit se podrían rechazar/cerrar sin más en los informes de fallo dejando a los usuarios sin plena cobertura. Solo he visto que se dé ese caso cuando un paquete es expulsado del repositorio y ya no es mantenido, lo cuál tiene toda la lógica del mundo. El problema es que depende completamente del empaquetador/mantenedor, y los hay que son un poco toca-narices (no sólo en Debian, ojo). No es la primera vez que un bug termina a debate en el CTTE porque el mantenedor de turno se enroca en una postura absurda y no hay quien lo saque de ahí. Pero eso es general y válido para los más de 40.000 paquetes existentes. Aunque sería interesante saber cómo proceder en casos así... 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. Para empeorar las cosas, con la excusa de que systemd es el sistema predeterminado en Jessie y de la reciente votación de no es necesario incidir en este punto pues deja todo en el aire, sin ningún tipo de garantía de cara al administrador que vaya a instalar Debian Jessie y que no quiera usar systemd. Y ni siquiera en ese caso lo cierran sin más: los informadores son debidamente notificados sobre por qué se cierran. Pues qué bien ¿y de qué sirve que te digan que lo cierran porque quieren? Pues de nada, es más, te deja peor el cuerpo. No, no es que lo cierren porque quieren. Lo cierran porque es absurdo tener abierto informes de fallos sobre un paquete que ya no existe (salvo en snapshot). En ese caso, además, recibes una notificación automática explicando el porqué. Estamos hablando de un hipotético bug que exista en los paquetes que sustituyen o reemplazan a systemd (upstart, sysvinit), es decir, paquetes que sí existen y no están obsoletos ni abandonados. Pues lo habitual es justo lo contrario a tus temores, que los paquetes cruciales consigan más atención, no menos, que el resto. De hecho, en esos casos suelen considerar fallos de nivel importante como si fuesen RC. 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/20141216195516.7d07a...@gmail.com
Re: devuan
El martes, 16 dic 2014, a las 19:09 horas (UTC+1), Eduardo Rios escribió: No entiendo mucho del tema, pero parece ser que desde Jessie en adelante, para que todos los servicios funcionen correctamente, se depende de systemd. No. Si un servicio solo va a funcionar correctamente con systemd, te va a obligar a instalarlo. Vale, no es necesario, pero si eliges cualquier otro, te arriesgas a que ciertos servicios no vayan o no lo hagan como esperas... No. Y en caso contrario solo hay que abrir un informe de fallo serio por carecer de una dependencia. Un paquete no puede alcanzar la distribución estable si cuenta con un solo fallo de este tipo sin corregir. https://www.debian.org/Bugs/Developer#severities Entonces, entiendo que los desarrolladores se vuelquen con systemd y abandonen cualquier otro sistema de inicio. En Jessie no. En adelante cualquiera sabe. Y si es así, tiene razón Camaleon al decir que los usuarios que no usen systemd van a estar vendidos. ¿Es así, no? Si vendido significa un futuro sin otro sistema de inicio en Debian, pudiera ser. Si significa que van a haber otros sistemas de inicio pero que van a estar plagados de fallos... bueno, en el mejor de los casos eso es hablar por hablar. 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/20141216203257.631ca...@gmail.com
Re: devuan
2014-12-16 13:55 GMT-05:00 Manolo Díaz diaz.man...@gmail.com: ... 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. La idea es minimizar el número de puntos únicos de fallo[0]. Añadir uno más es añadir más eslabones a la cadena, lo que significa aumentar la probabilidad de que un eslabón pueda fallar y ya conoces el dicho: una cadena es tan fuerte como el eslabon más debil. [0] https://es.wikipedia.org/wiki/Single_point_of_failure -- 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/caabycjpnbo2b2oweycur9ze-yma1krm6vs-2pyag4yvvtmy...@mail.gmail.com
Re: devuan
El martes, 16 dic 2014, a las 23:25 horas (UTC+1), Carlos Zuniga escribió: 2014-12-16 13:55 GMT-05:00 Manolo Díaz diaz.man...@gmail.com: ... 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. La idea es minimizar el número de puntos únicos de fallo[0]. Añadir uno más es añadir más eslabones a la cadena, lo que significa aumentar la probabilidad de que un eslabón pueda fallar y ya conoces el dicho: una cadena es tan fuerte como el eslabon más debil. [0] https://es.wikipedia.org/wiki/Single_point_of_failure Muy bien, pero cambiar un sistema de inicio por otro no es añadir. El número de puntos únicos de fallo sigue siendo el mismo. -- 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/20141216233622.06800...@gmail.com
Re: devuan
El Tue, 09 Dec 2014 11:44:49 -0430, Edward Villarroel (EDD) escribió: buenas tardes comunidad el siguiente hilo es nada mas para saber y discutir quienes han considerado devuan? La iniciativa es loable y confirma la falta de tacto con la que han actuado desde Debian a este respecto (me refiero a la problemática con systemd), pero en mi caso desgraciadamente devuan no me solucionada nada (al menos en principio) salvo que recompilen/rediseñen todos los paquetes para que no tengan dependencias fuertes de libpam-systemd. Aún tengo un año (oficial) y pico (gracias al repo LTS) por delante para tomar una decisión... y en eso estoy. Saludos, -- Camaleón -- 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/pan.2014.12.10.15.00...@gmail.com
Re: devuan
Pues la verdad no entiendo mucho con respecto a lo acontecido en debian por systemd, sin embargo me parece mal el hecho se que no se tenga en cuenta al usuario final, creo que me pasaría a debían u otra distro que me permita realmente instalar lo que quiero, esperar a ver que sucede. El dic 10, 2014 10:00 a.m., Camaleón noela...@gmail.com escribió: El Tue, 09 Dec 2014 11:44:49 -0430, Edward Villarroel (EDD) escribió: buenas tardes comunidad el siguiente hilo es nada mas para saber y discutir quienes han considerado devuan? La iniciativa es loable y confirma la falta de tacto con la que han actuado desde Debian a este respecto (me refiero a la problemática con systemd), pero en mi caso desgraciadamente devuan no me solucionada nada (al menos en principio) salvo que recompilen/rediseñen todos los paquetes para que no tengan dependencias fuertes de libpam-systemd. Aún tengo un año (oficial) y pico (gracias al repo LTS) por delante para tomar una decisión... y en eso estoy. Saludos, -- Camaleón -- 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/pan.2014.12.10.15.00...@gmail.com
Re: devuan
yo actualmente ya estoy testiando freebsd! y me a gustado mucho! e tenido inconveniente con acpi y la configuración de teclado!!! y sus paquetes son muy actualizado lo único q extra;o realmente el el paper-flash de chrome pero de resto es fácil de configurar... y el otro punto negativo es la documentación es mas escasa comparada con la de linux debian.
Re: devuan
Son muchas las distribuciones con SystemD, no entiendo muy bien el porque este problema parece que solo se da con Debian, ArchLinux o Fedora por poner ejemplos usan este sistema de arranque desde hace tiempo. A mi me parece bien la existencia de este fork ya que viene a sumar una alternativa pero si Debian decide de forma interna hacer un cambio de este calibre es normal que haya gente a favor y en contra, yo por mi parte como usuario de 'escritorio' no me va a afectar tanto como si fuera un usuario de 'servidor' (espero que entendais a lo que me refiero) Personalmente una de las cosas que menos me gustan de SystemD es que es intrinseco al núcleo Linux, y esto no beneficia para nada ni a Debian/hurd que posiblemente a este paso puede que alguno de los nietos de nuestros nietos lo vea estable ni al port de Freebsd el cual por desgracia y por otras circunstancias deja de ser un port oficial ( personalmente no logre que funcionara de forma estable virtualmente y lo intente varias veces) El 10 de diciembre de 2014, 17:10, Edward Villarroel (EDD) edward.villarr...@gmail.com escribió: yo actualmente ya estoy testiando freebsd! y me a gustado mucho! e tenido inconveniente con acpi y la configuración de teclado!!! y sus paquetes son muy actualizado lo único q extra;o realmente el el paper-flash de chrome pero de resto es fácil de configurar... y el otro punto negativo es la documentación es mas escasa comparada con la de linux debian. -- carlos.nico...@gmail.com
Re: devuan
El día 10 de diciembre de 2014, 12:20, Carlos Nicolas carlos.nico...@gmail.com escribió: Son muchas las distribuciones con SystemD, no entiendo muy bien el porque este problema parece que solo se da con Debian, ArchLinux o Fedora por poner ejemplos usan este sistema de arranque desde hace tiempo. A mi me parece bien la existencia de este fork ya que viene a sumar una alternativa pero si Debian decide de forma interna hacer un cambio de este calibre es normal que haya gente a favor y en contra, yo por mi parte como usuario de 'escritorio' no me va a afectar tanto como si fuera un usuario de 'servidor' (espero que entendais a lo que me refiero) Lo que pasa es que para muchos por aquí el asunto en cuestión es valórico, y nuestra opción por debian en su momento se dió casi por una opción filosófica. Y actitudes, resoluciones y demases cada vez me parece que alejan el proyecto de su ideario original. Personalmente una de las cosas que menos me gustan de SystemD es que es intrinseco al núcleo Linux, y esto no beneficia para nada ni a Debian/hurd que posiblemente a este paso puede que alguno de los nietos de nuestros nietos lo vea estable ni al port de Freebsd el cual por desgracia y por otras circunstancias deja de ser un port oficial ( personalmente no logre que funcionara de forma estable virtualmente y lo intente varias veces) Yo tampoco lo logré. El 10 de diciembre de 2014, 17:10, Edward Villarroel (EDD) edward.villarr...@gmail.com escribió: yo actualmente ya estoy testiando freebsd! y me a gustado mucho! e tenido inconveniente con acpi y la configuración de teclado!!! y sus paquetes son muy actualizado lo único q extra;o realmente el el paper-flash de chrome pero de resto es fácil de configurar... Prueba PcBSD y el otro punto negativo es la documentación es mas escasa comparada con la de linux debian. La documentación es abundante, lo que no hay mucho es material del tipo tutoriales y guías paso a paso. Eso te obliga a estudiar. -- carlos.nico...@gmail.com -- usuario linux #274354 normas de la lista: http://wiki.debian.org/es/NormasLista como hacer preguntas inteligentes: http://www.sindominio.net/ayuda/preguntas-inteligentes.html -- 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/CAAiZAx5K3PKiWVp-9Y7TRHr1b=-rffka7wakbezeahvmnyz...@mail.gmail.com
Re: devuan
El 09/12/2014 13:15, Edward Villarroel (EDD) edward.villarr...@gmail.com escribió: buenas tardes comunidad el siguiente hilo es nada mas para saber y discutir quienes han considerado devuan? Edward Villarroel: @Agentedd Yo estoy pendiente de los avances, al menos probar en un virtual cuando cobre vida, luego veré.
RE: Devuan y un poco mas de luz
Date: Thu, 4 Dec 2014 00:13:53 -0300 From: unciegobaila...@mail.com To: debian-user-spanish@lists.debian.org Subject: Re: Devuan y un poco mas de luz El 03/12/14 a las 13:48, Camaleón escibió: El Tue, 02 Dec 2014 15:03:26 -0300, unciegobailando escribió: aprovecho que estoy curioseando y les pregunto algo tecnico sobre systemd que no me ha gusta (no se si estoy bien orientado..) No resulta -asquerosamente- intrusivo que systemd se meta entre los pedidos de una aplicacion y d-bus? Systemd, como cualquier gestor de servicios, tiene que ser intrusivo (sin tener que llegar a serlo asquerosamente) porque esa es su función: controlar y gestionar los servicios que ha iniciado. O sea que si falla systemd se me cuelga todo el escritorio gnome por ejemplo (y quizas parcialmente cualquier otro entorno)? Si falla systemd es una afirmación demasiado abstracta e indefinida como para ser válida y que equivale a decir si me falla sysvinit. Que systemd e init puedan fallar es algo que todos damos por hecho que pueda suceder pero dado el caso lo importante no es *si falla* sino *cómo* lo hace (no es lo mismo que se lleve por delante todo el sistema a que deje un servicio sin iniciar) y *qué* herramientas dispone de depuración para que el usuario pueda resolver el problema in situ. Saludos, Muchas gracias por la info y orientacion camaleon... Argumentaria sobre algunas cosas... pero es hacerla muy larga y no tiene ningun sentido aqui. Saludos desde el sur. Recordando los estadíos del software:alfa, alfa 2, beta, beta2, final (estable) Recordando que Red Hat su final es pago y que usa gratuitamente a los usuarios de Fedora como beta testers (por eso abandone la distribución de Linux Fedora y me encolumné para aprender Debian ya hace algunos años).Creo que seguir la línea que impone Red Hat es pasar a ser beta testers de ellos y no solo aliviarle el trabajo a ellos (que lo cobran) sino comenzar a desaparecer como distribución. Devuan puede llegar a ser la verdadera continuación de esa idea que identificó en su momento como software estable a Debian (según mi criterio).No uso Ubuntu por que se comprometieron a sacar release muy seguidos y nunca terminan de dar un software estable como Debian (hasta ahora) que diferencia muy bien entre old estable, estable, inestable.No uso Win2 por que en vez de pagarme para ser beta tester, les debo pagar yo para ser beta tester de Macrochot (parecido a Red Hat y Fedora).Ahora estoy espectante y me gustaría conocer mas detalles de systemd vs. sysvinit para saber si se justifica pasar a ser beta tester de Red Hat o irme mudando de Distribución(justo ahora que comienzo a adquirir más conocimientos de Debian y podria ser mas activo en estas listas).Agradezco a quien sea capaz de darme datos para hacer alguna comparación que eche luz en este punto. Saludos
Re: Devuan y un poco mas de luz
El Tue, 02 Dec 2014 15:03:26 -0300, unciegobailando escribió: aprovecho que estoy curioseando y les pregunto algo tecnico sobre systemd que no me ha gusta (no se si estoy bien orientado..) No resulta -asquerosamente- intrusivo que systemd se meta entre los pedidos de una aplicacion y d-bus? Systemd, como cualquier gestor de servicios, tiene que ser intrusivo (sin tener que llegar a serlo asquerosamente) porque esa es su función: controlar y gestionar los servicios que ha iniciado. O sea que si falla systemd se me cuelga todo el escritorio gnome por ejemplo (y quizas parcialmente cualquier otro entorno)? Si falla systemd es una afirmación demasiado abstracta e indefinida como para ser válida y que equivale a decir si me falla sysvinit. Que systemd e init puedan fallar es algo que todos damos por hecho que pueda suceder pero dado el caso lo importante no es *si falla* sino *cómo* lo hace (no es lo mismo que se lleve por delante todo el sistema a que deje un servicio sin iniciar) y *qué* herramientas dispone de depuración para que el usuario pueda resolver el problema in situ. Saludos, -- Camaleón -- 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/pan.2014.12.03.16.48...@gmail.com
Re: Devuan y un poco mas de luz
El 03/12/14 a las 13:48, Camaleón escibió: El Tue, 02 Dec 2014 15:03:26 -0300, unciegobailando escribió: aprovecho que estoy curioseando y les pregunto algo tecnico sobre systemd que no me ha gusta (no se si estoy bien orientado..) No resulta -asquerosamente- intrusivo que systemd se meta entre los pedidos de una aplicacion y d-bus? Systemd, como cualquier gestor de servicios, tiene que ser intrusivo (sin tener que llegar a serlo asquerosamente) porque esa es su función: controlar y gestionar los servicios que ha iniciado. O sea que si falla systemd se me cuelga todo el escritorio gnome por ejemplo (y quizas parcialmente cualquier otro entorno)? Si falla systemd es una afirmación demasiado abstracta e indefinida como para ser válida y que equivale a decir si me falla sysvinit. Que systemd e init puedan fallar es algo que todos damos por hecho que pueda suceder pero dado el caso lo importante no es *si falla* sino *cómo* lo hace (no es lo mismo que se lleve por delante todo el sistema a que deje un servicio sin iniciar) y *qué* herramientas dispone de depuración para que el usuario pueda resolver el problema in situ. Saludos, Muchas gracias por la info y orientacion camaleon... Argumentaria sobre algunas cosas... pero es hacerla muy larga y no tiene ningun sentido aqui. Saludos desde el sur. -- 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/547fd171.10...@mail.com
Re: Devuan y un poco mas de luz
El Tue, 02 Dec 2014 09:52:18 -0300, unciegobailando escribió: Fuentes: http://forum.debianizzati.org/viewtopic.php?f=15t=49133start=225 Extraccion y traduccion desde: http://lamiradadelreplicante.com/2014/12/01/devuan-uno-de-los-creadores-del-fork-de-debian-da-su-vision-del-proyecto/ Aqui copio y pego las declaraciones de uno de los administradores de Devuan: (...) Entonces que cosas se cambian con respecto a Debian? Muchísimas. Se ha dicho que systemd se pueden evitar en Debian, pero esto no es cierto.Usted puede retirarla del PID1 pero los “tentáculos” están en todas las partes del sistema, y no es posible evitarlo por completo. (...) ahora casi todo el sistema básico depende de libsystemd0, y sus ramificaciones y dependencias son cada vez más y más profundas en debian como pasa en otros sistemas que lo han adoptado. En estas condiciones no es posible conseguir lo que queremos, es decir, la libertad de utilizar o no systemd… (...) Completa y desgraciadamente cierto :-/ Saludos, -- Camaleón -- 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/pan.2014.12.02.15.42...@gmail.com
Re: Devuan y un poco mas de luz
El 02/12/14 a las 12:42, Camaleón escibió: El Tue, 02 Dec 2014 09:52:18 -0300, unciegobailando escribió: Fuentes: http://forum.debianizzati.org/viewtopic.php?f=15t=49133start=225 Extraccion y traduccion desde: http://lamiradadelreplicante.com/2014/12/01/devuan-uno-de-los-creadores-del-fork-de-debian-da-su-vision-del-proyecto/ Aqui copio y pego las declaraciones de uno de los administradores de Devuan: (...) Entonces que cosas se cambian con respecto a Debian? Muchísimas. Se ha dicho que systemd se pueden evitar en Debian, pero esto no es cierto.Usted puede retirarla del PID1 pero los “tentáculos” están en todas las partes del sistema, y no es posible evitarlo por completo. (...) ahora casi todo el sistema básico depende de libsystemd0, y sus ramificaciones y dependencias son cada vez más y más profundas en debian como pasa en otros sistemas que lo han adoptado. En estas condiciones no es posible conseguir lo que queremos, es decir, la libertad de utilizar o no systemd… (...) Completa y desgraciadamente cierto :-/ Saludos, Justamente me acorde de tus comentarios en el tema systemd cuando leia sobre las ramificaciones y depedencias cada vez mas profundas encontre algo a favor de systemd, que aunque traducido por google se lee muy bien... lo dejo por aqui tambien: **A favor de systemd** https://translate.googleusercontent.com/translate_c?depth=1hl=esrurl=translate.google.comsl=autotl=esu=http://0pointer.de/blog/projects/the-biggest-myths.htmlusg=ALkJrhj-DDRCKLHprv5kL_4mQF3zHqxJzw Al final la adopcion de systed por parte de los DD para fundada en una gran razon: trabajar menos -si mal no entiendo las cosas-. Hasta luego... -- 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/547de76c.3090...@mail.com
Re: Devuan y un poco mas de luz
El Tue, 02 Dec 2014 13:23:08 -0300, unciegobailando escribió: El 02/12/14 a las 12:42, Camaleón escibió: (...) Aqui copio y pego las declaraciones de uno de los administradores de Devuan: (...) Entonces que cosas se cambian con respecto a Debian? Muchísimas. Se ha dicho que systemd se pueden evitar en Debian, pero esto no es cierto.Usted puede retirarla del PID1 pero los “tentáculos” están en todas las partes del sistema, y no es posible evitarlo por completo. (...) ahora casi todo el sistema básico depende de libsystemd0, y sus ramificaciones y dependencias son cada vez más y más profundas en debian como pasa en otros sistemas que lo han adoptado. En estas condiciones no es posible conseguir lo que queremos, es decir, la libertad de utilizar o no systemd… (...) Completa y desgraciadamente cierto :-/ Justamente me acorde de tus comentarios en el tema systemd cuando leia sobre las ramificaciones y depedencias cada vez mas profundas encontre algo a favor de systemd, que aunque traducido por google se lee muy bien... lo dejo por aqui tambien: (...) Esa página que apuntas¹ es más antigua que el Balrog de Moria. De hecho es del desarrollador principal de systemd y efectivamente, ninguno de sus mitos desmitifica lo que están diciendo los devuanenses, es decir, que tienen más razón que un santo ;-) ¹http://0pointer.de/blog/projects/the-biggest-myths.html Saludos, -- Camaleón -- 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/pan.2014.12.02.16.30...@gmail.com
Re: Devuan y un poco mas de luz
El 02/12/14 a las 13:30, Camaleón escibió: El Tue, 02 Dec 2014 13:23:08 -0300, unciegobailando escribió: El 02/12/14 a las 12:42, Camaleón escibió: (...) Aqui copio y pego las declaraciones de uno de los administradores de Devuan: (...) Entonces que cosas se cambian con respecto a Debian? Muchísimas. Se ha dicho que systemd se pueden evitar en Debian, pero esto no es cierto.Usted puede retirarla del PID1 pero los “tentáculos” están en todas las partes del sistema, y no es posible evitarlo por completo. (...) ahora casi todo el sistema básico depende de libsystemd0, y sus ramificaciones y dependencias son cada vez más y más profundas en debian como pasa en otros sistemas que lo han adoptado. En estas condiciones no es posible conseguir lo que queremos, es decir, la libertad de utilizar o no systemd… (...) Completa y desgraciadamente cierto :-/ Justamente me acorde de tus comentarios en el tema systemd cuando leia sobre las ramificaciones y depedencias cada vez mas profundas encontre algo a favor de systemd, que aunque traducido por google se lee muy bien... lo dejo por aqui tambien: (...) Esa página que apuntas¹ es más antigua que el Balrog de Moria. De hecho es del desarrollador principal de systemd y efectivamente, ninguno de sus mitos desmitifica lo que están diciendo los devuanenses, es decir, que tienen más razón que un santo ;-) ¹http://0pointer.de/blog/projects/the-biggest-myths.html Eso mismo pude notar aun en mi oscura ignorancia, que no desmitifica los problemas de los que se encuentra acusado aun hoy. Aunque personalmente me sirvio para entender mejor sus fortalezas. La falta de scrips redundantes y la administracion centralizada con una pequeña curva de aprendizaje... (es lo que mas me quedo en el marote). Ellos mismos -o el- aclara que la velocidad no fue lo buscado sino un resultado consecuente del nuevo diseño. Realmente parecen dos posiciones 'ireconciliables'. pfff... -- 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/547decfa.8080...@mail.com
Re: Devuan y un poco mas de luz
El día 2 de diciembre de 2014, 13:46, unciegobailando unciegobaila...@mail.com escribió: El 02/12/14 a las 13:30, Camaleón escibió: El Tue, 02 Dec 2014 13:23:08 -0300, unciegobailando escribió: El 02/12/14 a las 12:42, Camaleón escibió: (...) Aqui copio y pego las declaraciones de uno de los administradores de Devuan: (...) Entonces que cosas se cambian con respecto a Debian? Muchísimas. Se ha dicho que systemd se pueden evitar en Debian, pero esto no es cierto.Usted puede retirarla del PID1 pero los “tentáculos” están en todas las partes del sistema, y no es posible evitarlo por completo. (...) ahora casi todo el sistema básico depende de libsystemd0, y sus ramificaciones y dependencias son cada vez más y más profundas en debian como pasa en otros sistemas que lo han adoptado. En estas condiciones no es posible conseguir lo que queremos, es decir, la libertad de utilizar o no systemd… (...) Completa y desgraciadamente cierto :-/ Justamente me acorde de tus comentarios en el tema systemd cuando leia sobre las ramificaciones y depedencias cada vez mas profundas encontre algo a favor de systemd, que aunque traducido por google se lee muy bien... lo dejo por aqui tambien: (...) Esa página que apuntas¹ es más antigua que el Balrog de Moria. De hecho es del desarrollador principal de systemd y efectivamente, ninguno de sus mitos desmitifica lo que están diciendo los devuanenses, es decir, que tienen más razón que un santo ;-) ¹http://0pointer.de/blog/projects/the-biggest-myths.html Eso mismo pude notar aun en mi oscura ignorancia, que no desmitifica los problemas de los que se encuentra acusado aun hoy. Aunque personalmente me sirvio para entender mejor sus fortalezas. La falta de scrips redundantes y la administracion centralizada con una pequeña curva de aprendizaje... (es lo que mas me quedo en el marote). Ellos mismos -o el- aclara que la velocidad no fue lo buscado sino un resultado consecuente del nuevo diseño. Realmente parecen dos posiciones 'ireconciliables'. pfff... He estado siguiendo lo que se dice sobre los dos sistemas de arranque; hoy han estallado todos los foros y blogs con el tema de DEVUAN. Mi opinión: lo mejor que pudo pasar. ¿Por qué? Porque no me cabe dudas que va a terminar en algo mucho mejor que no es ni sysvinit ni systemd. ¿De dónde lo saco? De la experiencia de la tríada dialéctica. Después de 20, es la primera vez que se le mueve el piso a Debian. Y todo organismo sólo evoluciona cuando se ve sometido a presión. Creo que va a ser una forma de quebrar paradigmas de las nuevas generaciones, de romper con lo anterior, no porque sea malo, si no por el simple hecho de intentar otra vía. Ambos sistemas tienen los suyo, tanto de bueno como de malo. Lo único que realmente me molesta de systemd, son los logs binarios. JAP -- 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/CAG0od5cYY5JJo+VKFyowB6=py7efenzugeyj+rbve-1tzgf...@mail.gmail.com
Re: Devuan y un poco mas de luz
El 02/12/14 a las 14:21, Javier ArgentinaBBAR escibió: El día 2 de diciembre de 2014, 13:46, unciegobailando unciegobaila...@mail.com escribió: El 02/12/14 a las 13:30, Camaleón escibió: El Tue, 02 Dec 2014 13:23:08 -0300, unciegobailando escribió: El 02/12/14 a las 12:42, Camaleón escibió: (...) Aqui copio y pego las declaraciones de uno de los administradores de Devuan: (...) Entonces que cosas se cambian con respecto a Debian? Muchísimas. Se ha dicho que systemd se pueden evitar en Debian, pero esto no es cierto.Usted puede retirarla del PID1 pero los “tentáculos” están en todas las partes del sistema, y no es posible evitarlo por completo. (...) ahora casi todo el sistema básico depende de libsystemd0, y sus ramificaciones y dependencias son cada vez más y más profundas en debian como pasa en otros sistemas que lo han adoptado. En estas condiciones no es posible conseguir lo que queremos, es decir, la libertad de utilizar o no systemd… (...) Completa y desgraciadamente cierto :-/ Justamente me acorde de tus comentarios en el tema systemd cuando leia sobre las ramificaciones y depedencias cada vez mas profundas encontre algo a favor de systemd, que aunque traducido por google se lee muy bien... lo dejo por aqui tambien: (...) Esa página que apuntas¹ es más antigua que el Balrog de Moria. De hecho es del desarrollador principal de systemd y efectivamente, ninguno de sus mitos desmitifica lo que están diciendo los devuanenses, es decir, que tienen más razón que un santo ;-) ¹http://0pointer.de/blog/projects/the-biggest-myths.html Eso mismo pude notar aun en mi oscura ignorancia, que no desmitifica los problemas de los que se encuentra acusado aun hoy. Aunque personalmente me sirvio para entender mejor sus fortalezas. La falta de scrips redundantes y la administracion centralizada con una pequeña curva de aprendizaje... (es lo que mas me quedo en el marote). Ellos mismos -o el- aclara que la velocidad no fue lo buscado sino un resultado consecuente del nuevo diseño. Realmente parecen dos posiciones 'ireconciliables'. pfff... He estado siguiendo lo que se dice sobre los dos sistemas de arranque; hoy han estallado todos los foros y blogs con el tema de DEVUAN. Mi opinión: lo mejor que pudo pasar. ¿Por qué? Porque no me cabe dudas que va a terminar en algo mucho mejor que no es ni sysvinit ni systemd. ¿De dónde lo saco? De la experiencia de la tríada dialéctica. Después de 20, es la primera vez que se le mueve el piso a Debian. Y todo organismo sólo evoluciona cuando se ve sometido a presión. Creo que va a ser una forma de quebrar paradigmas de las nuevas generaciones, de romper con lo anterior, no porque sea malo, si no por el simple hecho de intentar otra vía. Ambos sistemas tienen los suyo, tanto de bueno como de malo. Lo único que realmente me molesta de systemd, son los logs binarios. JAP aprovecho que estoy curioseando y les pregunto algo tecnico sobre systemd que no me ha gusta (no se si estoy bien orientado..) No resulta -asquerosamente- intrusivo que systemd se meta entre los pedidos de una aplicacion y d-bus? O sea que si falla systemd se me cuelga todo el escritorio gnome por ejemplo (y quizas parcialmente cualquier otro entorno)? -- 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/547dfeee.6080...@mail.com
Re: Devuan y un poco mas de luz
On Tue, Dec 02, 2014 at 03:03:26PM -0300, unciegobailando wrote: No resulta -asquerosamente- intrusivo que systemd se meta entre los pedidos de una aplicacion y d-bus? O sea que si falla systemd se me cuelga todo el escritorio gnome por ejemplo (y quizas parcialmente cualquier otro entorno)? Pues más o menos lo mismo que si falla el núcleo o el servidor X, se puede colgar todo el escritorio igualmente. Que un determinado software pueda tener bugs ya lo sabíamos, no hay nada nuevo en ello. -- 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/20141202221319.ga2...@cantor.unex.es
Re: Devuan y un poco mas de luz
El 02/12/14 a las 19:13, Santiago Vila escibió: On Tue, Dec 02, 2014 at 03:03:26PM -0300, unciegobailando wrote: No resulta -asquerosamente- intrusivo que systemd se meta entre los pedidos de una aplicacion y d-bus? O sea que si falla systemd se me cuelga todo el escritorio gnome por ejemplo (y quizas parcialmente cualquier otro entorno)? Pues más o menos lo mismo que si falla el núcleo o el servidor X, se puede colgar todo el escritorio igualmente. Que un determinado software pueda tener bugs ya lo sabíamos, no hay nada nuevo en ello. Ok Santiago.. pero a mi el nucleo no me falla hace mucho y el servidor x tampoco (mis graficas son intel). El asunto aqui es que sistemaD es un nuevo intermediario en un aplicacoin y d-bus, mientra segun pude entender, antes no se necesitaba de esto. en fin.. gracias che igualmente. Biene bien para des-asnarse. jiji. -- 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/547e9fe4.2060...@mail.com
