Systemd fue un movimiento de RedHat para tomar el control del espacio de usuario de Linux mediante la forzada adopción de systemd el cual no es más que código inútil que duplica funcionalidades implementadas y probadas históricamente, que incluye nuevos bugs y amplia la superficie de ataque expuesta del sistema (curiosamente los mismos males que sufre pulseaudio). Y para llevar a cabo esto, los cabrones han operado para establecer en puestos clave a desarrolladores bajo nónima (como el puto Poettering).
Con la FSF en vías de desaparición, Stallman fuera de juego RedHat tiene virtualmente el poder para establecer nuevos, borrar viejos y dirigir los elementos comunes (lo standard) de las distros de Linux. Los de RedHat son unos hijosdeputa y nadie se está dando cuenta de la jugada maestra. Y mejor ni hablamos de las implicaciones de actores estatales en el contexto de la ciberguerra ...
Systemd fue un movimiento de RedHat para tomar el control del espacio de usuario de Linux mediante la forzada adopción de systemd el cual no es más que código inútil que duplica funcionalidades implementadas y probadas históricamente, que incluye nuevos bugs y amplia la superficie de ataque expuesta del sistema (curiosamente los mismos males que sufre pulseaudio). Y para llevar a cabo esto, los cabrones han operado para establecer en puestos clave a desarrolladores bajo nónima (como el puto Poettering).
Con la FSF en vías de desaparición, Stallman fuera de juego RedHat tiene virtualmente el poder para establecer nuevos, borrar viejos y dirigir los elementos comunes (lo standard) de las distros de Linux. Los de RedHat son unos hijosdeputa y nadie se está dando cuenta de la jugada maestra. Y mejor ni hablamos de las implicaciones de actores estatales en el contexto de la ciberguerra ...
#5 Hay distros como hypérbola que están adoptando cosas de OpenBSD, como sndio (una especie pulseaudio pero BIEN hecho), Xenocara (fork de X.org) y algunas cosas más. Como arranque usa OpenRC, pero para mí tanto el sistema de inicio de Slackware como OpenBSD son imbatibles: simples, scripts más que probados por verdaderos expertos de Unix (BSD) incluso antes de ponerse torvalds con Linux y configuración pa tontos.
Sobre RedHat, os recuerdo que RPM antiguamente era un formato propietario, no sé si ahora usará CPIO pero antes no habia forma de convertir o extraer nada.
Sobre distros en general, aún os quedará Slackware y váis a tener calidad para rato, aunque saquen releases a ritmo glacial.
Creo que tienes un punto de vista PC centrista.
Te puedo preguntar si administras sistemas grandes, o proyectas estructuras de red? Porque es justo ahí donde initd era un dolor de muelas.
Systemd está pensando con el SA en mente, que es al fin y al cabo el cliente de systemd. El usuario medio de linux es el visitante de una web o el usuario de un móvil.
Para un usuario PC de Linux, que no necesita preocuparse de la arquitectura, hay más tiempo para pensar en filosofía, política y conspiraciones. A más que me pese ese ha sido el gran fallo de la FSF (junto con personalizar la asociación en la persona menos empática del mundo, pero ese es otro debate).
Un administrador de sistemas HOY DÍA debe tener bajo control un sistema que no se parece en nada a un entorno Linux de hace 10 años.
Ya no es un sistema físico, y si lo es, está en un centro de datos al que ya no se tiene acceso físico. Tiene un Hipervisor, los paquetes vienen en contenedores.
Ahí, initd sencillamente no encaja. Systemd Tiene integradas las tareas necesarias para administrar cómodamente un sistema de hoy en día, sin pasarte horas escribiendo o desescribiendo scripts. Hasta puedes instalar módulos de systemd junto con la pila de contenedores.
Este uso, y no otro, es el del usuario medio de Linux.
#11 Systemd funciona bien en cualquier sistema, sea server o escritorio. Yo personalmente nunca he tenido problemas con él y desde el punto de vista de usuario no tiene grandes diferencias con el viejo init más allá de aprender nuevos comandos pra arrancar servicios. Mucha gente se asusta porque dentro del proyecto de systemd hay muchas cosas aparte del init, pero la inmensa mayoría de las cosas no tienen porque usarse para nada y se puede quedar uno con las ventajas de systemd, como tener una forma estandard para hacer init scripts, mejor monitorización de servicios, el journalctl cuando aprendes a usarlo es más cómodo que el típico syslog y varias cosas más.
#c-11" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3214808/order/11">#11 Sigues siendo un engañao, pero no te lo tomes a mal
Si, soy un super-user hardcore. Cuando no tengo na que hacer me dedico a revisar logs a manubrio y a analizar cores con el gdb de los SEGFAULT que me voy encontrando por la vida.
root@srv03:/root # uname -a
FreeBSD srv03.xxxx.yyyy 11.2-RELEASE-p9 FreeBSD 11.2-RELEASE-p9 #0: Tue Feb 5 15:30:36 UTC 2019 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
No tienes ni puta idea del dolor de guebos que es que los /var/log/* estén en formato binario (no me vengas con que puedo redirigir desde el journald.conf) y de que los scripts de inicio ya no sean scripts. También de que hayan quitado el doble fork() que siempre ha sido el proceso init (por eso las jails() de BSD son tan limpias y faciles de implementar, forkean otro init y a volar) , que hayan añadido código vulnerable (he perdido cuenta de los CVEs), etc, etc.
#15 Aplaudo tu entusiasmo. Solo decirte que hace 20 años, yo tenía exactamente las mismas quejas de init. Solo que las quejas eran precisamente el obscurantismo mistico detrás de los scripts que tienían todos los ingredientes para funcionar, y sin embargo no funcionaban por los 175.000 scripts de antes y después de ese en particular que querías que destacara.
... Y si, journalctl es el mejor invento desde el ácido lisérgico. Deal with it.
#18 Yo nunca he dejado BSD, pero lo tengo solo para mi NAS. Es un bonito juguete
Ahora, te invito a que cojas una OpenBSD, te vayas a un VPS le metas kubernetes, condas, servicios, stacks y cientos de lineas de codigo de mierda. Cuando parezca terrible, mete a 2000 usuarios completamente inútiles a utilizarlo, y cuando parezca absolutamente inviable, mete a un comercial vendiendo características imposibles de implementar que deben salir en producción pasado mañana...
Systemd será la última de tus preocupaciones. Y si te ves caminando por verdes prados, relájate, porque habrás muerto, y estarás en el Eliseo.
#2 Es perfectamente comprensible. Cuando se presentó systemd, se presentó como la primera versión de una nueva arquitectura dentro del sistema operativo. Era un cambio grande que debía evolucionar necesariamente tras ser implantado.
#1 Realmente es una muy buena idea. Entiendo el motivo de las quejas, pero a día de hoy, creo que fue una muy buena decisión, no hay más que ver que las quejas se han esfumado.
#22 tiene los timers, que básicamente son lo mismo que Cron/Anacron, y tiene incluso implementada su propia versión de AutoFS. Me parece una locura. Si se descuidan hacen una suite ofimática.
#24 Tanto los mount como los automount los veo lógicos ya que puedes ponerlos como dependencias, por ejemplo si un servicio depende de un share NFS no lo arranque si no está.
O que si se mete un pendrive arranques automáticamente un servicio, o incluso un user service. Ambos me parecen casos de uso lógicos.
Lo de los timers si que me parece que sobra, y además es del core, pero tampoco es algo que a mi me moleste que esté ahí porque systemd sigue siendo muy ligero no conozco ninguna distribución que no meta crontab.
#6 Yo solo he usado DesktopBSD. Me pareció muy eficiente. Quiero preguntarte una cosa, si quieres meterte de lleno en edición de vídeo (Cinelerra, etc) y diseño gráfico gimp, krita. ¿Las distros BSD son aconsejables?. Repito, tuve una buena impresión, con DesktopBSD, pero he leido que la instalación FreeBSD es un poco compleja. No sé si habrán cambiado las cosas.
A buenas horas.... A día de hoy systemd, como gestor de servicios, funciona bien. Hace años cuando iba como el culo es otra cosa, pero los bugs del core de systemd hoy en dia son raros.
Otra cosa son los despropósitos de extensiones que tiene como resolvd y journald, pero systemd, lo que es el core, nspawn y la gestión de cgroups a día de hoy funcionan
#4 Yo soy usuario de Debian desde hace 9 años, aunque yo enfoco el uso de este sistema operativo a offimática, edición de video, diseño gráfico y 3D. No soy experto en seguridad informática ni desarrollador.
Sé que existe Devuan, un fork de Debian que evita el uso de systemd https://devuan.org/ pero nunca lo he probado.
Yo hace poco compré una torre pc bastante potente en comparación mi laptop Toshiba que ya tiene casi 10 años y que se le fastidió los filtros de vídeo de la tarjeta gráfica, y Debian ahora arranca tan rápido como los Windows, será porque uso SSD o por la potencia de mi equipo, pero antes, Debian era muy lento en su arranque, a mí no me importaba, pero un linuxero me dijo que era un problema que había qe solucionar.
#4 Que duplicidad de funciones exactamente? Si estás hablando de cosas como hostnamectl, resolvd, networkd y mierdas de esas, son las extensiones opcionales que mencionaba antes.
#6 No se que uso le darás exactamente, pero nosotros le damos un uso bastante exhaustivo a mi me parece bastante estable hoy en día. Y cuando digo que systemd me parece bastante estable quiero decir exactamente systemd y no componentes opcionales del proyecto como journald.
Recuerdo que haciendo llamadas a libsystemd tuvimos problemas porque systemd gestiona la memoria de forma bastante especial y en lugar de usar el malloc de glibc que es thread safe tiene un gestor de memoria integrado que no es thread safe, y al usar libsystemd como librería liberabamos la memoria que no era. Dicho comportamiento no estaba documentado y la tuvo un compañero con el subnormal de Poettering.
Recuerdo otra hace poco donde si había una sysctl determinada y poca memoria se ponía a reservar memoria a lo bestia.
Pero en lo que es administrar servicios no he visto nada demasiado grave, la verdad. Otra cosa es que me digas journald que eso si que es cancer de sida, no hay por donde coger esa mierda.
#2 Sigue yendo como el culo. En distros supuestamente sólidas como Solus traga bastante.
Y eso que para mí es la mejor distribución para escritorio de lejos, lo digo como usuario de OpenBSD donde si tengo que elegir por usabilidad para recomendar a un neófito, elijo esa, pero los bugazos que da consumiendo no son normales.
Yo no sé de las virtudes de systemd, pero usando sysvinit en mx linux (debian stable) 0 problemas, hoygan. Cualquier proceso con el sudo service y arreando, que supongo que habrá otros métodos, pero vamos, que eso, 0 problemas.
#12 No creo que nadie haya cuestionado la estabilidad de sysvinit, lo que se critica es que a parte de ser lento es un cristo en cuanto a la gestión de errores, saber lo que se está ejecutando, tienes un huevo de scripts no estándar, si alguien modifica un script después de arrancar un servicio tampoco se te notifica, era bastante más lento, etc.
Se alaba mucho la simplicidad de sysvinit, pero a mi me parece que los scripts eran bastante más complejos.
Comentarios
#3 Eres un engañao.
Systemd fue un movimiento de RedHat para tomar el control del espacio de usuario de Linux mediante la forzada adopción de systemd el cual no es más que código inútil que duplica funcionalidades implementadas y probadas históricamente, que incluye nuevos bugs y amplia la superficie de ataque expuesta del sistema (curiosamente los mismos males que sufre pulseaudio). Y para llevar a cabo esto, los cabrones han operado para establecer en puestos clave a desarrolladores bajo nónima (como el puto Poettering).
Con la FSF en vías de desaparición, Stallman fuera de juego RedHat tiene virtualmente el poder para establecer nuevos, borrar viejos y dirigir los elementos comunes (lo standard) de las distros de Linux. Los de RedHat son unos hijosdeputa y nadie se está dando cuenta de la jugada maestra. Y mejor ni hablamos de las implicaciones de actores estatales en el contexto de la ciberguerra ...
#5 Hay distros como hypérbola que están adoptando cosas de OpenBSD, como sndio (una especie pulseaudio pero BIEN hecho), Xenocara (fork de X.org) y algunas cosas más. Como arranque usa OpenRC, pero para mí tanto el sistema de inicio de Slackware como OpenBSD son imbatibles: simples, scripts más que probados por verdaderos expertos de Unix (BSD) incluso antes de ponerse torvalds con Linux y configuración pa tontos.
Sobre RedHat, os recuerdo que RPM antiguamente era un formato propietario, no sé si ahora usará CPIO pero antes no habia forma de convertir o extraer nada.
Sobre distros en general, aún os quedará Slackware y váis a tener calidad para rato, aunque saquen releases a ritmo glacial.
#5 engañado no, me gano el pan con esto.
Creo que tienes un punto de vista PC centrista.
Te puedo preguntar si administras sistemas grandes, o proyectas estructuras de red? Porque es justo ahí donde initd era un dolor de muelas.
Systemd está pensando con el SA en mente, que es al fin y al cabo el cliente de systemd. El usuario medio de linux es el visitante de una web o el usuario de un móvil.
Para un usuario PC de Linux, que no necesita preocuparse de la arquitectura, hay más tiempo para pensar en filosofía, política y conspiraciones. A más que me pese ese ha sido el gran fallo de la FSF (junto con personalizar la asociación en la persona menos empática del mundo, pero ese es otro debate).
Un administrador de sistemas HOY DÍA debe tener bajo control un sistema que no se parece en nada a un entorno Linux de hace 10 años.
Ya no es un sistema físico, y si lo es, está en un centro de datos al que ya no se tiene acceso físico. Tiene un Hipervisor, los paquetes vienen en contenedores.
Ahí, initd sencillamente no encaja. Systemd Tiene integradas las tareas necesarias para administrar cómodamente un sistema de hoy en día, sin pasarte horas escribiendo o desescribiendo scripts. Hasta puedes instalar módulos de systemd junto con la pila de contenedores.
Este uso, y no otro, es el del usuario medio de Linux.
#11 Systemd funciona bien en cualquier sistema, sea server o escritorio. Yo personalmente nunca he tenido problemas con él y desde el punto de vista de usuario no tiene grandes diferencias con el viejo init más allá de aprender nuevos comandos pra arrancar servicios. Mucha gente se asusta porque dentro del proyecto de systemd hay muchas cosas aparte del init, pero la inmensa mayoría de las cosas no tienen porque usarse para nada y se puede quedar uno con las ventajas de systemd, como tener una forma estandard para hacer init scripts, mejor monitorización de servicios, el journalctl cuando aprendes a usarlo es más cómodo que el típico syslog y varias cosas más.
#c-11" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3214808/order/11">#11 Sigues siendo un engañao, pero no te lo tomes a mal
Si, soy un super-user hardcore. Cuando no tengo na que hacer me dedico a revisar logs a manubrio y a analizar cores con el gdb de los SEGFAULT que me voy encontrando por la vida.
root@srv03:/root # uname -a
FreeBSD srv03.xxxx.yyyy 11.2-RELEASE-p9 FreeBSD 11.2-RELEASE-p9 #0: Tue Feb 5 15:30:36 UTC 2019 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
root@srv03:/root # uptime
2:03PM up 178 days, 9:09, 1 user, load averages: 0.20, 0.20, 0.16
No tienes ni puta idea del dolor de guebos que es que los /var/log/* estén en formato binario (no me vengas con que puedo redirigir desde el journald.conf) y de que los scripts de inicio ya no sean scripts. También de que hayan quitado el doble fork() que siempre ha sido el proceso init (por eso las jails() de BSD son tan limpias y faciles de implementar, forkean otro init y a volar) , que hayan añadido código vulnerable (he perdido cuenta de los CVEs), etc, etc.
ME CAGON EN EL PUTO SYSTEMD Y EN REDHAT!
cc #13
#15 la verdad es que me da lo mismo porque yo dedico mi tiempo libre a no usar el ordenador, gracias al tiempo que me ahorra systemd
#15 Aplaudo tu entusiasmo. Solo decirte que hace 20 años, yo tenía exactamente las mismas quejas de init. Solo que las quejas eran precisamente el obscurantismo mistico detrás de los scripts que tienían todos los ingredientes para funcionar, y sin embargo no funcionaban por los 175.000 scripts de antes y después de ese en particular que querías que destacara.
... Y si, journalctl es el mejor invento desde el ácido lisérgico. Deal with it.
#17 Ya lo he "gestionado": hace años que me pasé a *BSD. Sois vosotros los que tenéis que "deal with it" ;-D
#18 Yo nunca he dejado BSD, pero lo tengo solo para mi NAS. Es un bonito juguete
Ahora, te invito a que cojas una OpenBSD, te vayas a un VPS le metas kubernetes, condas, servicios, stacks y cientos de lineas de codigo de mierda. Cuando parezca terrible, mete a 2000 usuarios completamente inútiles a utilizarlo, y cuando parezca absolutamente inviable, mete a un comercial vendiendo características imposibles de implementar que deben salir en producción pasado mañana...
Systemd será la última de tus preocupaciones. Y si te ves caminando por verdes prados, relájate, porque habrás muerto, y estarás en el Eliseo.
#19 Hay multitud de empresas funcionando con BSD, sin ir más lejos CDMON en España.
#5 Suena conspiranoico, pero al menos el primer párrafo largo (Systemd fue...) me parece extremadamente real.
Systemd es un framework que engloba múltiples funcionalidades en una, innecesariamente... con lo que en el punto de fallo es enorme.
Lo que siempre me pareció curioso es que el creador, luego de la cagada de Pulseaudio, desarrollara éste sistema... y tuviera tanto éxito!
Pero lo que explicas de RH, tiene sentido...
#5 Además, básicamente, por el camino han dejado escapar un buen grupo de buenos desarrolladores.
puto systemd
Ahora, en 2020, después de la purga que hubo de desarrolladores cuando se instauró por narices ..
#2 Es perfectamente comprensible. Cuando se presentó systemd, se presentó como la primera versión de una nueva arquitectura dentro del sistema operativo. Era un cambio grande que debía evolucionar necesariamente tras ser implantado.
#1 Realmente es una muy buena idea. Entiendo el motivo de las quejas, pero a día de hoy, creo que fue una muy buena decisión, no hay más que ver que las quejas se han esfumado.
#22 tiene los timers, que básicamente son lo mismo que Cron/Anacron, y tiene incluso implementada su propia versión de AutoFS. Me parece una locura. Si se descuidan hacen una suite ofimática.
#24 Tanto los mount como los automount los veo lógicos ya que puedes ponerlos como dependencias, por ejemplo si un servicio depende de un share NFS no lo arranque si no está.
O que si se mete un pendrive arranques automáticamente un servicio, o incluso un user service. Ambos me parecen casos de uso lógicos.
Lo de los timers si que me parece que sobra, y además es del core, pero tampoco es algo que a mi me moleste que esté ahí porque systemd sigue siendo muy ligero no conozco ninguna distribución que no meta crontab.
#6 Yo solo he usado DesktopBSD. Me pareció muy eficiente. Quiero preguntarte una cosa, si quieres meterte de lleno en edición de vídeo (Cinelerra, etc) y diseño gráfico gimp, krita. ¿Las distros BSD son aconsejables?. Repito, tuve una buena impresión, con DesktopBSD, pero he leido que la instalación FreeBSD es un poco compleja. No sé si habrán cambiado las cosas.
A buenas horas.... A día de hoy systemd, como gestor de servicios, funciona bien. Hace años cuando iba como el culo es otra cosa, pero los bugs del core de systemd hoy en dia son raros.
Otra cosa son los despropósitos de extensiones que tiene como resolvd y journald, pero systemd, lo que es el core, nspawn y la gestión de cgroups a día de hoy funcionan
#2 lo malo de Systemd es la duplicidad de funciones que provoca.
Desde que existe Systemd es más difícil administrar sistemas y dicha administración es más caótica. Keep it simple, stupid.
#4 Yo soy usuario de Debian desde hace 9 años, aunque yo enfoco el uso de este sistema operativo a offimática, edición de video, diseño gráfico y 3D. No soy experto en seguridad informática ni desarrollador.
Sé que existe Devuan, un fork de Debian que evita el uso de systemd https://devuan.org/ pero nunca lo he probado.
Yo hace poco compré una torre pc bastante potente en comparación mi laptop Toshiba que ya tiene casi 10 años y que se le fastidió los filtros de vídeo de la tarjeta gráfica, y Debian ahora arranca tan rápido como los Windows, será porque uso SSD o por la potencia de mi equipo, pero antes, Debian era muy lento en su arranque, a mí no me importaba, pero un linuxero me dijo que era un problema que había qe solucionar.
#4 Que duplicidad de funciones exactamente? Si estás hablando de cosas como hostnamectl, resolvd, networkd y mierdas de esas, son las extensiones opcionales que mencionaba antes.
#6 No se que uso le darás exactamente, pero nosotros le damos un uso bastante exhaustivo a mi me parece bastante estable hoy en día. Y cuando digo que systemd me parece bastante estable quiero decir exactamente systemd y no componentes opcionales del proyecto como journald.
Recuerdo que haciendo llamadas a libsystemd tuvimos problemas porque systemd gestiona la memoria de forma bastante especial y en lugar de usar el malloc de glibc que es thread safe tiene un gestor de memoria integrado que no es thread safe, y al usar libsystemd como librería liberabamos la memoria que no era. Dicho comportamiento no estaba documentado y la tuvo un compañero con el subnormal de Poettering.
Recuerdo otra hace poco donde si había una sysctl determinada y poca memoria se ponía a reservar memoria a lo bestia.
Pero en lo que es administrar servicios no he visto nada demasiado grave, la verdad. Otra cosa es que me digas journald que eso si que es cancer de sida, no hay por donde coger esa mierda.
#2 Sigue yendo como el culo. En distros supuestamente sólidas como Solus traga bastante.
Y eso que para mí es la mejor distribución para escritorio de lejos, lo digo como usuario de OpenBSD donde si tengo que elegir por usabilidad para recomendar a un neófito, elijo esa, pero los bugazos que da consumiendo no son normales.
Yo no sé de las virtudes de systemd, pero usando sysvinit en mx linux (debian stable) 0 problemas, hoygan. Cualquier proceso con el sudo service y arreando, que supongo que habrá otros métodos, pero vamos, que eso, 0 problemas.
#12 No creo que nadie haya cuestionado la estabilidad de sysvinit, lo que se critica es que a parte de ser lento es un cristo en cuanto a la gestión de errores, saber lo que se está ejecutando, tienes un huevo de scripts no estándar, si alguien modifica un script después de arrancar un servicio tampoco se te notifica, era bastante más lento, etc.
Se alaba mucho la simplicidad de sysvinit, pero a mi me parece que los scripts eran bastante más complejos.