Es como el troleo perfecto a sus detractores, pero probablemente systemd siga desarrollándose. Este muchacho tiene mucho talento e ideas.

Y poca integridad

Bueno no podía irse a un lugar más apto para alguien como él.

>>2
Muchas ideas horribles.

>>5 cuáles y por qué?

systemd es un sistema init, el primer proceso iniciado por el kernel (Linux) después de que se cargue en la memoria y del que descienden todos los demás procesos en el árbol de procesos. El sistema init incluye más funciones que el programa "init". Es responsable de arrancar el sistema operativo, incluyendo los diversos daemons(servicios) y todo el resto de cosas.

Fue desarrollado por Red Hat, una empresa que vende soporte técnico para una distro, que más tarde fue comprada por IBM (!), y es ampliamente aceptado que systemd es uno de los varios intentos de RedHat para hacerse con el ecosistema linux insertando un componente, cuyo desarrollo controlan estrechamente, y luego imponiendo "vendor lock-in" después de que las diversas distros hayan crecido dependientes de él para promover el uso de otros proyectos de RedHat y poner lentamente más del ecosistema en el control de RedHat.

systemd fue particularmente dudoso porque a pesar de ser un lío roto (lo que es ridículo para un sistema init), incompatible con todo y en general contrario a los principios de los sistemas tipo unix... bueno, inmediatamente fue adoptado por casi todas las distribuciones de Linux y con la misma rapidez se convirtió en la opción exclusiva, en detrimento de ellos, meses, si no años de ruptura severa y pérdida de funcionalidad, mientras que el resto del ecosistema se reconstruye en torno a este nuevo componente. No se puede exagerar lo grande que fue la mentira obvia de que systemd sería un reemplazo directo.

El principal gancho comercial no era la funcionalidad, de la que carecía, ni la compatibilidad, que cualquiera sabía que no lo era. O la estabilidad, el elefante en la habitación. Era la velocidad. Hacía que tu ordenador arrancara más rápido. Ahora bien, incluso si eso fuera cierto y en algún momento en el futuro lejano sería una alternativa utilizable a la tecnología actual, es difícil no notar que este punto fue promocionado masivamente a los normalitos de Ubuntu y similares como la nueva cosa fresca. El equivalente al "redditor de linux", el usuario de Ubuntuforums, estaba convencido de que sólo los "boomers" y los "luditas" rechazaban systemd porque eran viejos y temerosos del cambio y simplemente patéticos, a diferencia de ellos, que estaban a la moda y eran geniales y ejecutaban ciegamente comandos copiados de búsquedas en Google.

Lo cual es inmensamente irónico porque optimizar la velocidad de arranque básicamente sólo beneficia a aquellos que serían sysadmins y demás, no a los usuarios promedio de Windows que han estado hibernando la misma sesión durante seis meses.

Cuando algunas grandes distros protestaron (como Gentoo) y denunciaron la invasión, RedHat aprovechó su control sobre Udev , un daemon de gestión de hardware crucial utilizado por la mayoría de las distribuciones, para chantajearlos para que cumplieran, haciendo que sólo funcionara con systemd y rompiendo la compatibilidad cuando se desarrollaron soluciones.

Además, systemd, cuyos desarrolladores juran hasta el día de hoy que nunca tuvieron más que la más altruista de las intenciones, ha utilizado desde entonces este apalancamiento como componente central y exclusivo de las distros para expandirse, de ahí los memes. Aunque esto ya era evidente desde el principio, los "módulos" exclusivos de systemd que, o bien son incompatibles con todo, o bien impulsan "extensiones" sólo para su sistema, han llegado a sustituir gran parte de lo que tradicionalmente eran componentes del SO cuya función podía ser satisfecha por una serie de proyectos de la competencia, cuyo principal defecto es no estar bajo el control de RedHat.

Los desarrolladores de systemd también siguen presionando a los equipos de desarrollo de los entornos de escritorio y otros grandes proyectos, incluidos los grupos de estándares, para que inserten dependencias en la funcionalidad exclusiva de systemd.

Si esto te suena un poco a "Adoptar, extender y extinguir", entonces sí...
https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish

oh no qué tragedia

bueno, como iba diciendo...

Como ibas diciendo que? No tienes nada que decir. Preguntaste y te respondieron y quedaste como saco wea.

No hablemos de PulseAudio ya que al menos llegó PipeWire a salvar esa mierda.

sigo creyendo que las peleas de init están más motivadas por ideología que por código. a un usuario normal no debería importarle qué init está usando.

Bueno, es que no son precisamente los usuarios "normales" los que llevan esta discusión, sino los "power users". Yo creo que hay buenos argumentos en ambas partes, por una parte hay mejores inits disponibles, como runit, pero por otra parte cuando hizo falta reemplazar sysvinit, systemd era la mejor opción disponible en ese momento, y para bien o para mal se convirtió en la norma.

>están más motivadas por ideología que por código
¿Y cuál es la diferencia?

>>7
mi linux sigue sin poder correr jueguitos, mirá si me voy a estar fijando por un sistema init

>>13
para empezar, ¿quien se motiva por código?

Pero si en Linux tienes el mejor juego de todos los tiempos, Tux Racer...

No mentira, Xonotic obviamente.

>>9 no soy >>8, hice la pregunta en >>6, y no estoy conforme que se trate de vendor lock-in ni una estrategia a lo Microsoft de adoptar, extender y extinguir. Lo que más he leído por parte de los detractores va más por un modelo de funcionamiento más filosófico, en particular la filosofía UNIX de una función, un programa. Esto se sabe que no siempre es escalable, de hecho el núcleo del sistema operativo con su arquitectura monolítica y no de micronúcleo no ha tenido mayores quejas y las alternativas no han fraguado como en el modelo usado por Linux.

Otro asunto que se critica de systemd es que está inflado, pero ese inflado no es tanto por systemd. De hecho, hay aspectos del núcleo Linux, que es donde está la parte bien inflada de características que no se aprovechan y que no están en otros sistemas estilo UNIX y que para aprovecharlas era terreno inexplorado donde podría convenir un diseño particular más que otro al ir más allá de normas POSIX y sacar más provecho a lo que permite el núcleo.

Además systemd es relativamente modular: si no quieres usar journal, no lo uses, puedes usar rsyslogd o similar. Incluso es posible utilizar rsyslogd como entrada o salida (imjournal/omjournal) y que trabajen juntos. La ventaja agregada del journal es que se trata de información estructurada y almacenada de manera más eficiente, que también lo es para consultarla. Si tienes gran cantidad de logs es más rápido consultar por proceso, fecha y tipo de evento, resultando más conveniente que desde rsyslogd.

Es importante señalar que cuando apareció rsyslogd también había crítica sobre sus características y que apareciera en distros, muy inflada para casos de uso de máquinas modestas que no necesitaban combinar logs remotos de máquinas remotas o las opciones de cifrado para proteger la integridad y confidencialidad de la información, pero esto es de uso muy común, recordando que estos sistemas se usan incluso más en servidores que en computadoras personales. Hay montones de cosas que no necesitas en un sistema UNIX que lo hacen pesado y lento al arrancar, al igual que en Windows hoy en día. Irónicamente, journald es como el sistema de eventos de Windows y nadie va a dejar de usar Windows por ese hecho.

No se puede extinguir algo que es software libre. Los BSD siguen y seguirán existiendo, del mismo modo que macOS no extinguió los BSD por extenderlos aun con mucho código cerrado que las licencias no recíprocas de BSD permiten explícitamente apropiarse del código sin compartir el modificado. systemd tiene en la medida de lo posible una capa de compatibilidad POSIX, al igual que macOS, para mantener la interoperabilidad. Ha hecho más daño zsh y bash en mi opinión en romper características y vicios en los scripts de shell y nadie se ha llevado las manos a la cabeza con los "bashismos" por adoptar y extender, ya que extinguir a sh, csh y dash no parece haber logrado. Fragmentan más las distros con su sistema de paquetería sin querer ponerse de acuerdo con Linux Standard Base y gracias a ello ahora tenemos engendros cono snap o flatpak para no tener que empaquetar tarballs de slackware, (r)pm, deb, ebuild, pkginfo, nix, entre otros. (básicamente la problemática que menciona >>14).

Aquí existe libertad de elección. Si prefieres usar una distro que no aprovecha las características del kernel y que no tiene mucha alternativa, puedes. Pero no parece que sea tendencia o que tenga un rendimiento conjunto aceptable por otros factores, por ejemplo la comunicación entre procesos es menos eficiente para ciertos casos de uso que funcionan mejor con un sistema que orqueste mejor los servicios del núcleo en espacio de usuario que un montón de UDS (.sock) dispersos por el sistema o algo monstruoso basado en kdbus o aún peor, d-bus tradicional.

systemd lo utilizo para no tener que utilizar demonios cron y configurarlos de forma mucho más granular y aleatoria, no tener que pelearme en decisiones con los rc, mayores facilidades y muchas más prestaciones en el manejo de jaulas gracias a características del núcleo, aislamiento de procesos y configuración de los mismos de forma declarativa con el sistema de unidades, que permiten limitar muchísimos aspectos gracias a los grupos de control versión 2, incluyendo características propias de cortafuegos y sin usar reglas de cortafuegos, límite de consumo de recursos, etc. y de forma más eficiente y sencilla que con una maraña de scripts lentos que tendrían que ir consultando datos de /sys y /proc y con gran propensión a equivocarse en el código no declarativo.

Otro apunte con la que mucha gente quizás no ha tenido que lidiar: scripts de init personalizados que se rompen a migrar entre distros o versiones de la misma por los intérpretes utilizados, dificultad extrema para diagnosticar fallos y propagación fallida en las dependencias. systemd tiene herramientas sumamente útiles para ver qué y cómo falló un servicio y por tanto las que no se dispararon, ver la duración o qué proceso está causando cuello de botella en el arranque, etc. ¿Y si sencillamente no quieres usar scripts de shell para iniciar por estas y otras razones como es en mi caso? Recordemos que esto implica otro tipo de dependencias como un intérprete de sh y en sistemas empotrados tal vez quieras eliminarlo del todo por razones especializadas.

Systemd también tiene problemas de seguridad y bugs, aunque es cierto que la comunidad tiende a exagerar al respecto. Para el usuario promedio estos problemas no son relevantes. También tiene varias ventajas como las que lista 17 (al ser bloatware tiene que tener más de alguna ww). A fin de cuentas es bueno que existan alternativas y distintos sabores para cada pieza del sistema. Ese es el punto de Linux.

Otro punto no mencionado es el cambio radical que supone con respecto a lo establecido (init). Y como buenos amantes de la revolución y el cambio en otros aspectos de la vida, sabemos que eso causa rechazo. Dicho y hecho, los detractores gastan tiempo y energía en tratar de que no cambie y tengan que apuntarse a la tendencia del momento, para bien o para mal. De ahí que se exagere y se busquen enemigos, que linux se acaba, etc. Lo que sí está claro es que ya no es lo que era. Y los nostálgicos que intenten ahora a probar un linux de inicios de los 90 no creo que quiera volver a eso. Si no, muchos estarían usando gnu/hurd, 4.4BSD o algún otro sistema incompatible con todo, como lo eran muchos UNIX entre sí antes de existir POSIX.

Bueno, hay varias distros que no usan Systemd, así que no sé qué tan cierto sea eso con respecto a Systemd en específico.

>>17 basado

>>20
Decir que la gente que critica a systemd es por el cambio es una falacia tremenda y la mas extendida de mala fe por Lennart y su fanclub. Muy pocos boomers son los que quieren SysV, creo que casi todo el mundo estaba de acuerdo en que era un desastre. Pero la gente que critica systemd ofrece otras alternativas que funcionan perfect como runit o s6 y a estos argumentos nunca los responden porque de seguro nunca los han probado.

Tampoco es por ser fan de Lennart. Si bien PulseAudio resolvía un problema complejo, la latencia era penosa, lo que no demuestra mucha maestría en temas de audio. Wim Taymans demostró que es posible lograr integración pro audio y escritorio a pesar del escepticismo inicial de la gente de JACK y que tras hacer algunos cambios en la arquitectura está logrando resolver este problema de una vez por todas. Y también contratado por Red Hat, demonizada por aquí también. Igual que se demoniza todavía la actual Microsoft por contratar al "dictador benevolente" de Python, que de entrada la 3.11 va a ser mucho más rápida que la 3.10 para que deje de ser un lenguaje interpretado de categoría inferior por sus problemas históricos de rendimiento y fragmentación de intérpretes alternativos incompletos que tampoco terminaban de resolver el problema sin romper la compatibilidad.

No es por pelear ni nada, solo tengo algunas dudas que me saltan.

>Si bien PulseAudio resolvía un problema complejo
Cuál?

>Y también contratado por Red Hat, demonizada por aquí también.
Yo al menos no demonizo a Red Hat, los comentarios van mayormente en contra de Lennart. Hay mucha gente de Red Hat que ha aportado de buena manera a Linux.

>Igual que se demoniza todavía la actual Microsoft
Por qué habría que no demonizarlo luego del terrible historial que tienen? Lo mismo se puede decir de Google, o Apple.

>de entrada la 3.11 va a ser mucho más rápida
Creo que no hay problemas con Python aquí la verdad, o sea, BaI está hecho en Python.

> >Si bien PulseAudio resolvía un problema complejo
>Cuál?

A pesar de los hacks en asound.conf con dmix, alsa no era especialmente buena para reproducir sonido de múltiples fuentes y quedaba bloqueado fácilmente entre aplicaciones. Manejar el volumen individual entre aplicaciones era también un desafío notable. Y si a eso le agregas el monstruoso Bluetooth®, ni te imaginas. PulseAudio comenzó complicado pero luego se consolidó y hoy en día no es el especial motivo de quejas de antaño, salvo para las limitaciones obvias del audio profesional, que requiere baja latencia; por eso y por la mezcla de video nació PipeWire, que es compatible con PulseAudio y JACK a la vez. Todavía hoy con apps si no se usa pipewire mediante APIs de cámaras en lugar de v4l2 directo todavía se bloquea la videocámara si la compartes con dos aplicaciones, solo teniendo acceso una, ni permitiendo agregar efectos.

>>1
No importa, justine tunney y Stallman siguen vivos. El mundo tiene perdón aún.

Bien traído y no se golpean entre ellos.