#163 Si... pero me conformaría con poder ejecutar el software que dice ser compatible con windows 7 por ejemplo.

A mi me parece que con esto pasa lo mismo que con NTFS. Estuvieron durante muchos años con soporte de sólo lectura de NTFS. Cada vez que estaban cerca de sacar algo funcional Microsoft sacaba un windows nuevo con un NTFS modificado. Parecía que nunca iban a alcanzarlos. Algunos sospechábamos que Microsoft sobornaba a gente de ese proyecto para que no avanzaran.

Y un día apareció "de la nada" NTFS3G. Yo no había escuchado hablar de ese proyecto nunca y resulta que de golpe aparecieron con algo perfectamente funcional y que todavía hoy seguimos usando.

A veces he llegado a pensar que con wine pasa algo parecido. Que realmentente no hay interés en implementar lo que falta.

#164 Entonces en lugar de ir a por wine/proton, tira de codeweavers. Es wine/proton, pero de pago y orientado al software en general. Y con el soporte, tienes la potestad de hacer que los desarrolladores se centren en el software en concreto que necesites que funcione (evidentemente si valve les paga para desarrollar proton y parchear los juegos más recientes, ellos van a soportar los juegos más recientes en proton; si tú les pagas para que funcione X, pues buscarán qué es lo que falta o no está haciendo su trabajo y lo añadirán o modificarán). No es tanto que no haya interés, sino que son pocos desarrolladores y no pueden abarcar todo (y si hay empresas o particulares que les pagan para ciertas cosas particulares, evidentemente se enfocarán más en ellas).


NTFS3g llevaba mucho tiempo en desarrollo, pero no estaba lo suficientemente maduro como para permitir que la gente lo usara para el día a día (y por lo tanto, las distribuciones no lo añadían como herramienta por defecto). No es que saliera de la noche a la mañana, es que cuando se consideró usable y estable y que no se iba a comer tus datos, fue cuando se empezó a usar más masivamente.

#181 ¿Y qué tiene que ver el kernel con eso? justamente el kernel es la parte más conservadora de todo el sistema. Probablemente aún funcionarían cosas hechas incluso para kernels viejérrimos como los 2.4 o 2.6 en equipos actuales. ¿Qué pasa? las librerías... nadie programa a pelo sólo usando interfaces de kernel, todo el mundo echa mano de librerías, y estas mueren, cambian, se abandonan, mutan... es lo que hace que los programas dejen de funcionar en linux (o en windows... ¿o acaso cuando hay cambio de versión no hay cosas que dejan de funcionar?).

#169 ¿Y tú sabes cómo procesa bash sus scripts? en ambos casos tienes los fuentes... ¿no es eso lo importante?

Claro. Son scripts. Se procesan igual que todos los demás.

#167 ¿Y? ¿qué tiene que ver el cuánto tiempo lleves usando algo para conocer y valorar con sentido cierta tecnología?

Sólo te estoy explicando que tengo muchos años de experiencia. No soy ningún principiante.

Te lo dice alguien que ha hecho desde cero servicios para systemd, simplemente mirando un poco la documentación y sin experiencia previa

Te creo. Yo estoy seguro de que también podría hacerlo. Si hoy en día buscando en google se puede hacer de todo en un ratito. Pero eso no cambia el hecho de que systemd es mucho más opaco. ¿Sabes acaso cómo se procesan esos archivos de configuración? ¿Podrías cambiarlo para que lo haga diferente?

Así que sí, me parece más sencillo que pelearme con bash, donde si te dejas un espacio donde no debes ya la cosa revienta y no sabes muy bien por qué

Te entiendo. Lo que pasa es que yo empecé cuando "pelearse con bash" era la única alternativa, y una vez que aprendes te da un control completo desde el nivel más bajo. Por eso es que lo prefiero antes de que un programa que sólo lee archivos de configuración.

Y repito: systemd rompe con un modelo que ha demostrado ser lo más exitoso de la historia: programas pequeños que hacen una sola cosa pero la hacen bien.

#168 "¿Sabes acaso cómo se procesan esos archivos de configuración? ¿Podrías cambiarlo para que lo haga diferente?"
¿Y tú sabes cómo procesa bash sus scripts? en ambos casos tienes los fuentes... ¿no es eso lo importante?

Pero ya que estamos, el formato es muy similar a los .ini de windows, es un formato muy simple incluso para hacer un parser propio (de hecho, hay muchísimos parsers ya hechos, como este: https://github.com/jochasinga/systemd-parser y si quieres verlo en detalle, puedes ver que es muy simple: https://github.com/jochasinga/systemd-parser/blob/master/src/parser.rs). Y tampoco se inspiró directamente en .ini, sino en https://specifications.freedesktop.org/desktop-entry-spec/latest/

Aunque entiendo que tú lo que propones son cambios no en el parseo de los scripts como tal, sino en qué hace cada sección. Si, eso ya es más complejo y hay que meterse en harina, pero ya se cubren todos los casos de uso que se te puedan ocurrir (vamos, hay units para todo tipo de servicios creadas, se han modificado y creado muchos elementos nuevos por el camino; si aún así se echa algo en falta a estas alturas... basta abrir una petición, y como cualquier otro proyecto, si tiene sentido y no está cubierto por alguna funcionalidad ya existente, se pondrán manos a la obra). Igualmente, tú tampoco ibas a ponerte a modificar bash por adaptar cualquier cosa que no te guste o a modificar init para que soporte cosas nuevas o...

Por otro lado, tienes toda una serie de capacidades ya hechas que son difíciles o muy complejas de hacer (y de hacer bien) con sysV init. Que con systemd puedes controlar de manera sencilla los grupos de procesos y restricciones de uso de recursos a grupos o procesos concretos, la activación de units asociada a sockets, montajes, eventos, etc. control preciso de timers (¿has probado a hacer a mano una entrada de crontab que se ejecute cada minuto? se puede hacer, pero de una manera muy fea y con una primera ejecución con delay). ¿Se puede hacer con scripts en bash? por supuesto, pero...

"systemd rompe con un modelo que ha demostrado ser lo más exitoso de la historia: programas pequeños que hacen una sola cosa pero la hacen
bien. "

Pues qué quieres que te diga, en mi ordenador parecen programas pequeños que hacen una sola cosa y la hacen bien...

systemctl, hostnamectl, teamctl, timedatectl, journalctl, systemd-udevd, systemd-logind, systemd-localed, systemd-machined, systemd-ac-power, systemd-cgtop, systemd-detect-virt, systemd-hwdb, systemd-notify, systemd-socket-activate, systemd-tty-ask-password-agent, systemd-analyze, systemd-confext, systemd-dissect, systemd-id128, systemd-nspawn, systemd-stdio-bridge, systemd-umount, systemd-ask-password, systemd-creds, systemd-escape, systemd-inhibit, systemd-path, systemd-sysext, systemd-cat, systemd-cryptenroll, systemd-firstboot, systemd-machine-id-setup, systemd-repart, systemd-sysusers, systemd-cgls, systemd-delta, systemd-gnome-ask-password-agent , systemd-mount, systemd-run, systemd-tmpfiles... (y dependiendo de cómo y qué compiles o qué distro uses, habrá más aún, cada uno haciendo su cosa concreta, como systemd-resolved, systemd-networkd, systemd-boot, etc).

Lo que pasa es que los fuentes de todo esto están todos juntos porque la idea es compartir todo el código posible entre ellos (muchos están relacionados, y las dependencias que pudiera haber tienen que ver más con esto que conque quiera forzarse al usuario a usar herramientas de systemd sí o sí), no hacer lo mismo varias veces de varias maneras distintas, pero luego se generan ejecutables para cada cosa que vayas a utilizar (o no se generan si no quieres perder el tiempo compilando lo que no vas a usar) ¿qué más cercano a la filosofía unix que esto?

#169 ¿Y tú sabes cómo procesa bash sus scripts? en ambos casos tienes los fuentes... ¿no es eso lo importante?

Claro. Son scripts. Se procesan igual que todos los demás.

#162 Lo siento, pero se ve que hablas de oídas, de lo que otros han dicho por ahí, y que nunca te has puesto en serio a usar systemd como administrador.

Mira... llevo usando Linux desde que estábamos en kernel 0.92. Usaba Slackware en aquel tiempo y me llegaba en diskettes porque ni siquiera teníamos internet. Lo uso continuamente como escritorio desde hace más de 20 años y he administrado cientos de servidores a lo largo de décadas.

A ver. Tal vez a ti te parezca "sencillo" un archivo de configuración que tiene un montón de líneas que más o menos se entienden. Y claro, cuando te lo dan hecho está bien. Si no te lo dan puedes buscar en google y copiar.

A mi me sigue pareciendo más sencillo y entendible algo así:


case "$1" in
start)
programa
;;
stop)
killall programa
;;
status)
ps afx grep programa
;;
restart)

$0 stop
$0 start
;;
esac

Lamentablemente no puedo poner indentaciones.

Eso sin contar con lo más grave: que systemd rompe con la filosofía unix de hacer una sola cosa por programa.

#166 " Mira... llevo usando Linux desde que estábamos en kernel 0.92. Usaba Slackware en aquel tiempo y me llegaba en diskettes porque ni siquiera teníamos internet. Lo uso continuamente como escritorio desde hace más de 20 años y he administrado cientos de servidores a lo largo de décadas."

¿Y? ¿qué tiene que ver el cuánto tiempo lleves usando algo para conocer y valorar con sentido cierta tecnología? a lo que voy es que repites las mismas críticas que tanto se oyen por ahí y que no son ciertas o sólo son ciertas si retuerces mucho las cosas, así que si, hablas de oídas. Los yoamimeparece denotan falta de conocimiento teórico y práctico sobre las alternativas.


" A ver. Tal vez a ti te parezca "sencillo" un archivo de configuración que tiene un montón de líneas que más o menos se entienden. Y claro, cuando te lo dan hecho está bien. Si no te lo dan puedes buscar en google y copiar. "

Te lo dice alguien que ha hecho desde cero servicios para systemd, simplemente mirando un poco la documentación y sin experiencia previa. Así que sí, me parece más sencillo que pelearme con bash, donde si te dejas un espacio donde no debes ya la cosa revienta y no sabes muy bien por qué. Aparte de que toda esa plantilla te la ahorras. Systemd funciona y funciona muy bien en parte porque evita repetir código, cosa que con SysVInit se produce con demasiada frecuencia, y los scripts de arranque son el menor de sus males (y por si no lo sabías, systemd aún sigue siendo compatible y soportando los scripts de SysVInit, así que ni siquiera esto es una ventaja de SysVInit sobre systemd, ni para ti ni para nadie).

#167 ¿Y? ¿qué tiene que ver el cuánto tiempo lleves usando algo para conocer y valorar con sentido cierta tecnología?

Sólo te estoy explicando que tengo muchos años de experiencia. No soy ningún principiante.

Te lo dice alguien que ha hecho desde cero servicios para systemd, simplemente mirando un poco la documentación y sin experiencia previa

Te creo. Yo estoy seguro de que también podría hacerlo. Si hoy en día buscando en google se puede hacer de todo en un ratito. Pero eso no cambia el hecho de que systemd es mucho más opaco. ¿Sabes acaso cómo se procesan esos archivos de configuración? ¿Podrías cambiarlo para que lo haga diferente?

Así que sí, me parece más sencillo que pelearme con bash, donde si te dejas un espacio donde no debes ya la cosa revienta y no sabes muy bien por qué

Te entiendo. Lo que pasa es que yo empecé cuando "pelearse con bash" era la única alternativa, y una vez que aprendes te da un control completo desde el nivel más bajo. Por eso es que lo prefiero antes de que un programa que sólo lee archivos de configuración.

Y repito: systemd rompe con un modelo que ha demostrado ser lo más exitoso de la historia: programas pequeños que hacen una sola cosa pero la hacen bien.

#168 "¿Sabes acaso cómo se procesan esos archivos de configuración? ¿Podrías cambiarlo para que lo haga diferente?"
¿Y tú sabes cómo procesa bash sus scripts? en ambos casos tienes los fuentes... ¿no es eso lo importante?

Pero ya que estamos, el formato es muy similar a los .ini de windows, es un formato muy simple incluso para hacer un parser propio (de hecho, hay muchísimos parsers ya hechos, como este: https://github.com/jochasinga/systemd-parser y si quieres verlo en detalle, puedes ver que es muy simple: https://github.com/jochasinga/systemd-parser/blob/master/src/parser.rs). Y tampoco se inspiró directamente en .ini, sino en https://specifications.freedesktop.org/desktop-entry-spec/latest/

Aunque entiendo que tú lo que propones son cambios no en el parseo de los scripts como tal, sino en qué hace cada sección. Si, eso ya es más complejo y hay que meterse en harina, pero ya se cubren todos los casos de uso que se te puedan ocurrir (vamos, hay units para todo tipo de servicios creadas, se han modificado y creado muchos elementos nuevos por el camino; si aún así se echa algo en falta a estas alturas... basta abrir una petición, y como cualquier otro proyecto, si tiene sentido y no está cubierto por alguna funcionalidad ya existente, se pondrán manos a la obra). Igualmente, tú tampoco ibas a ponerte a modificar bash por adaptar cualquier cosa que no te guste o a modificar init para que soporte cosas nuevas o...

Por otro lado, tienes toda una serie de capacidades ya hechas que son difíciles o muy complejas de hacer (y de hacer bien) con sysV init. Que con systemd puedes controlar de manera sencilla los grupos de procesos y restricciones de uso de recursos a grupos o procesos concretos, la activación de units asociada a sockets, montajes, eventos, etc. control preciso de timers (¿has probado a hacer a mano una entrada de crontab que se ejecute cada minuto? se puede hacer, pero de una manera muy fea y con una primera ejecución con delay). ¿Se puede hacer con scripts en bash? por supuesto, pero...

"systemd rompe con un modelo que ha demostrado ser lo más exitoso de la historia: programas pequeños que hacen una sola cosa pero la hacen
bien. "

Pues qué quieres que te diga, en mi ordenador parecen programas pequeños que hacen una sola cosa y la hacen bien...

systemctl, hostnamectl, teamctl, timedatectl, journalctl, systemd-udevd, systemd-logind, systemd-localed, systemd-machined, systemd-ac-power, systemd-cgtop, systemd-detect-virt, systemd-hwdb, systemd-notify, systemd-socket-activate, systemd-tty-ask-password-agent, systemd-analyze, systemd-confext, systemd-dissect, systemd-id128, systemd-nspawn, systemd-stdio-bridge, systemd-umount, systemd-ask-password, systemd-creds, systemd-escape, systemd-inhibit, systemd-path, systemd-sysext, systemd-cat, systemd-cryptenroll, systemd-firstboot, systemd-machine-id-setup, systemd-repart, systemd-sysusers, systemd-cgls, systemd-delta, systemd-gnome-ask-password-agent , systemd-mount, systemd-run, systemd-tmpfiles... (y dependiendo de cómo y qué compiles o qué distro uses, habrá más aún, cada uno haciendo su cosa concreta, como systemd-resolved, systemd-networkd, systemd-boot, etc).

Lo que pasa es que los fuentes de todo esto están todos juntos porque la idea es compartir todo el código posible entre ellos (muchos están relacionados, y las dependencias que pudiera haber tienen que ver más con esto que conque quiera forzarse al usuario a usar herramientas de systemd sí o sí), no hacer lo mismo varias veces de varias maneras distintas, pero luego se generan ejecutables para cada cosa que vayas a utilizar (o no se generan si no quieres perder el tiempo compilando lo que no vas a usar) ¿qué más cercano a la filosofía unix que esto?

#169 ¿Y tú sabes cómo procesa bash sus scripts? en ambos casos tienes los fuentes... ¿no es eso lo importante?

Claro. Son scripts. Se procesan igual que todos los demás.

#137 si lo han incorporado es porque mejora y facilita muchísimo la administración de sistemas en linux

Eso es cierto, pero por otro lado lo hace más opaco. Hace demasiadas cosas juntas y demasiado escondidas. ¿Que quieres que algo arranque en el inicio? Pues tienes que crear un archivo de configuración en tal lugar, después en lazarlo en tal otro. Y ese archivo tiene que tener varias secciones. Cada una con determinados campos. Y anda tu a saber qué campo es el que controla por ejemplo el tiempo de apagado. Hay que rebuscar documentación y no se encuentra fácilmente.
Yo preferiría SISV init donde si quieres arrancar algo metes un script y listo. Dentro del script haces lo que quieras y como quieras. Y si es complicado agregar frontends para quien lo necesite.

Pero bueno. Tampoco es para iniciar una guerra. Vengo usando systemd desde hace años y como rara vez tengo que tocar algo a mano, rara vez me quejo de que sea complicado.

#139 ¿En qué lo hace más opaco?
Los scripts de inicio no sólo son abiertos, sino más legibles y entendibles que los de InitV.

No es un ente opaco y oscuro que lo gestiona todo, son una miriada de apliaciones que hacen cosas concretas y que se pueden sustituír por cosas equivalentes (ahí están las interfaces definidas; por poner un ejemplo, desde el comienzo se ha podido sustituír logind por alternativas como elogind para soportar ciertos softwares en sistemas sin systemd).
Los fuentes son abiertos y disponibles bajo GPL2+

"Que quieres que algo arranque en el inicio? Pues tienes que crear un archivo de configuración en tal lugar, después en lazarlo en tal otro."
Estás describiendo cómo crear un servicio de arranque de Init de sysV, donde tienes que crear un script a manoplas que soporte al menos dos funciones (start y stop), copiarlo en un sitio y luego crear enlaces simbólicos en varios sitios más... no vengas con cuentos con systemd porque definir un servicico es incluso más sencillo (crear un archivo unit y refrescar el demonio de systemd para que lo tenga en cuenta).

"Yo preferiría SISV init donde si quieres arrancar algo metes un script y listo."
Que es complicado de debuguear, entender y modificar, sobre todo si llegas a un sistema y los scripts no son tuyos. Dime a ver si no sólo tú, sino casi cualquiera, puede entender y seguir qué hace esto:
[Unit]
Description=exim Mail Transport Agent
Documentation=man:exim(8)
Documentation=https://exim.org/docs.html
Conflicts=sendmail.service postfix.service
After=network-online.target nss-lookup.target
Wants=network-online.target

[Service]
PrivateTmp=true
RestrictRealtime=true
PIDFile=/run/exim4/exim.pid
Environment="EXIMSERVICE=-bdf -q30m" "UPEX4OPTS="
EnvironmentFile=-/etc/default/exim4
ExecStartPre=/usr/sbin/update-exim4.conf $UPEX4OPTS
ExecStart=/usr/sbin/exim4 $EXIMSERVICE
ExecReload=kill -HUP $MAINPID
Type=exec

[Install]
WantedBy=multi-user.target


Que por cierto, también es mucho más sencillo hacer un frontend para systemd si nos ponemos.

"Hay que rebuscar documentación y no se encuentra fácilmente."
Pues no sé de qué hablas... https://www.freedesktop.org/wiki/Software/systemd/
Si vas a toquetear las tripas: https://systemd.io/
Si quieres entender cómo funciona: https://0pointer.de/blog/projects/systemd.html
Si quieres saber cómo crear un servicio: https://www.freedesktop.org/software/systemd/man/systemd.unit.html

Y los cientos de tutoriales que hay por la red si quieres empezar por algo más básico.

Lo siento, pero se ve que hablas de oídas, de lo que otros han dicho por ahí, y que nunca te has puesto en serio a usar systemd como administrador. Si lo hubieras hecho, si hubieras padecido lo que cuesta hacer las mismas cosas con SysVinit, mirarías systemd con otros ojos.

#162 Lo siento, pero se ve que hablas de oídas, de lo que otros han dicho por ahí, y que nunca te has puesto en serio a usar systemd como administrador.

Mira... llevo usando Linux desde que estábamos en kernel 0.92. Usaba Slackware en aquel tiempo y me llegaba en diskettes porque ni siquiera teníamos internet. Lo uso continuamente como escritorio desde hace más de 20 años y he administrado cientos de servidores a lo largo de décadas.

A ver. Tal vez a ti te parezca "sencillo" un archivo de configuración que tiene un montón de líneas que más o menos se entienden. Y claro, cuando te lo dan hecho está bien. Si no te lo dan puedes buscar en google y copiar.

A mi me sigue pareciendo más sencillo y entendible algo así:


case "$1" in
start)
programa
;;
stop)
killall programa
;;
status)
ps afx grep programa
;;
restart)

$0 stop
$0 start
;;
esac

Lamentablemente no puedo poner indentaciones.

Eso sin contar con lo más grave: que systemd rompe con la filosofía unix de hacer una sola cosa por programa.

#166 " Mira... llevo usando Linux desde que estábamos en kernel 0.92. Usaba Slackware en aquel tiempo y me llegaba en diskettes porque ni siquiera teníamos internet. Lo uso continuamente como escritorio desde hace más de 20 años y he administrado cientos de servidores a lo largo de décadas."

¿Y? ¿qué tiene que ver el cuánto tiempo lleves usando algo para conocer y valorar con sentido cierta tecnología? a lo que voy es que repites las mismas críticas que tanto se oyen por ahí y que no son ciertas o sólo son ciertas si retuerces mucho las cosas, así que si, hablas de oídas. Los yoamimeparece denotan falta de conocimiento teórico y práctico sobre las alternativas.


" A ver. Tal vez a ti te parezca "sencillo" un archivo de configuración que tiene un montón de líneas que más o menos se entienden. Y claro, cuando te lo dan hecho está bien. Si no te lo dan puedes buscar en google y copiar. "

Te lo dice alguien que ha hecho desde cero servicios para systemd, simplemente mirando un poco la documentación y sin experiencia previa. Así que sí, me parece más sencillo que pelearme con bash, donde si te dejas un espacio donde no debes ya la cosa revienta y no sabes muy bien por qué. Aparte de que toda esa plantilla te la ahorras. Systemd funciona y funciona muy bien en parte porque evita repetir código, cosa que con SysVInit se produce con demasiada frecuencia, y los scripts de arranque son el menor de sus males (y por si no lo sabías, systemd aún sigue siendo compatible y soportando los scripts de SysVInit, así que ni siquiera esto es una ventaja de SysVInit sobre systemd, ni para ti ni para nadie).

#167 ¿Y? ¿qué tiene que ver el cuánto tiempo lleves usando algo para conocer y valorar con sentido cierta tecnología?

Sólo te estoy explicando que tengo muchos años de experiencia. No soy ningún principiante.

Te lo dice alguien que ha hecho desde cero servicios para systemd, simplemente mirando un poco la documentación y sin experiencia previa

Te creo. Yo estoy seguro de que también podría hacerlo. Si hoy en día buscando en google se puede hacer de todo en un ratito. Pero eso no cambia el hecho de que systemd es mucho más opaco. ¿Sabes acaso cómo se procesan esos archivos de configuración? ¿Podrías cambiarlo para que lo haga diferente?

Así que sí, me parece más sencillo que pelearme con bash, donde si te dejas un espacio donde no debes ya la cosa revienta y no sabes muy bien por qué

Te entiendo. Lo que pasa es que yo empecé cuando "pelearse con bash" era la única alternativa, y una vez que aprendes te da un control completo desde el nivel más bajo. Por eso es que lo prefiero antes de que un programa que sólo lee archivos de configuración.

Y repito: systemd rompe con un modelo que ha demostrado ser lo más exitoso de la historia: programas pequeños que hacen una sola cosa pero la hacen bien.

#168 "¿Sabes acaso cómo se procesan esos archivos de configuración? ¿Podrías cambiarlo para que lo haga diferente?"
¿Y tú sabes cómo procesa bash sus scripts? en ambos casos tienes los fuentes... ¿no es eso lo importante?

Pero ya que estamos, el formato es muy similar a los .ini de windows, es un formato muy simple incluso para hacer un parser propio (de hecho, hay muchísimos parsers ya hechos, como este: https://github.com/jochasinga/systemd-parser y si quieres verlo en detalle, puedes ver que es muy simple: https://github.com/jochasinga/systemd-parser/blob/master/src/parser.rs). Y tampoco se inspiró directamente en .ini, sino en https://specifications.freedesktop.org/desktop-entry-spec/latest/

Aunque entiendo que tú lo que propones son cambios no en el parseo de los scripts como tal, sino en qué hace cada sección. Si, eso ya es más complejo y hay que meterse en harina, pero ya se cubren todos los casos de uso que se te puedan ocurrir (vamos, hay units para todo tipo de servicios creadas, se han modificado y creado muchos elementos nuevos por el camino; si aún así se echa algo en falta a estas alturas... basta abrir una petición, y como cualquier otro proyecto, si tiene sentido y no está cubierto por alguna funcionalidad ya existente, se pondrán manos a la obra). Igualmente, tú tampoco ibas a ponerte a modificar bash por adaptar cualquier cosa que no te guste o a modificar init para que soporte cosas nuevas o...

Por otro lado, tienes toda una serie de capacidades ya hechas que son difíciles o muy complejas de hacer (y de hacer bien) con sysV init. Que con systemd puedes controlar de manera sencilla los grupos de procesos y restricciones de uso de recursos a grupos o procesos concretos, la activación de units asociada a sockets, montajes, eventos, etc. control preciso de timers (¿has probado a hacer a mano una entrada de crontab que se ejecute cada minuto? se puede hacer, pero de una manera muy fea y con una primera ejecución con delay). ¿Se puede hacer con scripts en bash? por supuesto, pero...

"systemd rompe con un modelo que ha demostrado ser lo más exitoso de la historia: programas pequeños que hacen una sola cosa pero la hacen
bien. "

Pues qué quieres que te diga, en mi ordenador parecen programas pequeños que hacen una sola cosa y la hacen bien...

systemctl, hostnamectl, teamctl, timedatectl, journalctl, systemd-udevd, systemd-logind, systemd-localed, systemd-machined, systemd-ac-power, systemd-cgtop, systemd-detect-virt, systemd-hwdb, systemd-notify, systemd-socket-activate, systemd-tty-ask-password-agent, systemd-analyze, systemd-confext, systemd-dissect, systemd-id128, systemd-nspawn, systemd-stdio-bridge, systemd-umount, systemd-ask-password, systemd-creds, systemd-escape, systemd-inhibit, systemd-path, systemd-sysext, systemd-cat, systemd-cryptenroll, systemd-firstboot, systemd-machine-id-setup, systemd-repart, systemd-sysusers, systemd-cgls, systemd-delta, systemd-gnome-ask-password-agent , systemd-mount, systemd-run, systemd-tmpfiles... (y dependiendo de cómo y qué compiles o qué distro uses, habrá más aún, cada uno haciendo su cosa concreta, como systemd-resolved, systemd-networkd, systemd-boot, etc).

Lo que pasa es que los fuentes de todo esto están todos juntos porque la idea es compartir todo el código posible entre ellos (muchos están relacionados, y las dependencias que pudiera haber tienen que ver más con esto que conque quiera forzarse al usuario a usar herramientas de systemd sí o sí), no hacer lo mismo varias veces de varias maneras distintas, pero luego se generan ejecutables para cada cosa que vayas a utilizar (o no se generan si no quieres perder el tiempo compilando lo que no vas a usar) ¿qué más cercano a la filosofía unix que esto?

#13 "Si se hubiera invertido en almacenamiento energético lo que se ha invertido en hidrógeno, cuya única ventaja es que no se pierde durante el transporte (comparado con la electricidad, que lo suyo es que se produzca directamente en destino y las redes de distribución queden como elementos de redundancia y seguridad, con lo cual tampoco el hidrógeno tendría esa ventaja), otro gallo nos cantaría."

Si se hubiera invertido en una alternativa al sistema, organizando el decrecimiento y reorganizando todo... mira que hemos tenido tiempo. Más o menos desde "The Limits of Growth", es decir, 50 años...

Solo hemos tenido 5 décadas para adaptarnos y pivotar el declive aminorando la marcha del cambio climático por el camino.

Realmente, si te paras a pensarlo, da para inmolarse de la rabia que genera saber que todo esto se podía evitar tan solo pensando un poco. Pero no, nos han tomado el pelo y nos hemos dejado engañar voluntariamente, a sabiendas de que en el fondo las cosas no cuadraban.

Ahora ya da igual. Ni vamos a salir bien parados del declive energético ni podemos paliar los efectos del CC.

#16 Si ahí te doy la razón, ya desde que se pilló a las petroleras con el carrito del helado se debería haber actuado. Pero la dependencia era tan alta y las alternativas tan pocas...

Y no, ahora no da igual, aún se puede hacer algo. Basta con empezar votando a partidos concienciados y que sepamos que realmente van a hacer cosas. No de los que dicen que van a hacer y no hacen, y desde luego, no a los negacionistas. Cuando pensemos que "no va a servir de nada", recordar que si todos los abstencionistas que no votan "porque no me representan" fundaran un partido y se votaran a si mismos, ganarían las elecciones con mayoría. Alternativas hay, aunque parezcan minoritarias y aunque parezca que se está tirando el voto. No votar si que es tirarlo.