Siempre me he preguntado, si hay tantas críticas que hacerle a Systemd, no así a Runit u OpenRC, ¿por qué se convirtió tan rápidamente en un estándar para la mayoría de las distribuciones grandes?

Porque fueron los que empezaron esto de dejar a SysV atrás (estoy ignorando a Upstart a propósito), convencieron a los que mantienen las mayores distros de obligar a sus usuarios a usar systemd en lugar de darles la posibilidad de elegir fácilmente, y también absorbieron varios otros proyectos grandes que hacen que estés casi obligado a cambiarte a systemd (por ejemplo con GNOME). Junto a esto, el autor de systemd ha dicho en numerosas ocasiones que systemd no va a ser portátil, y que va a rechazar parches de quienes quieran hacerlo funcionar. Esto efectivamente obliga a la gente a quedarse en Linux si necesitan software que requiere de systemd, aunque el software no necesite funciones específicas a Linux. También, el autor de systemd ha dicho públicamente que las interfaces entre componentes de systemd van a mantener inestable y sin documentar en el futuro cercano. Esto complica la creación de alternativas a componentes de systemd, ya que los devs tienen que estudiar primero el tremendo código que tiene systemd para en primer lugar entender cómo funciona y cómo empezar siquiera, además de asegurarse que sus alternativas van a ser compatibles con cada versión de systemd si esperan que la gente los use.

Todo esto asegura que va a ser muy costoso y tomaría mucho tiempo a los devs implementar alternativas que no impliquen simplemente escribir systemd desde cero. Cualquier trabajo que hacen para arreglar estos problemas con systemd pueden fácilmente ser socavados o desautorizados por el autor de systemd (a quien no le interesa la creación de alternativas). Lo que es especialmente desmoralizador sobre esta situación es que no hay una razón técnica de por qué systemd tiene que ser diseñado de esta manera; el software podría haberse creado portátil (o la comunidad podría hacerlo portátil si el autor aceptara su trabajo) y sus componentes podrían haber sido diseñados para tener interfaces internas estables, a modo de que reemplazar partes de systemd fuera posible.

Lo único "positivo" de todo esto es que el autor de systemd hace que hacerle más complicada la vida a cualquier potencial competencia, llevando a mucha frustración y controversia.

Pero eso no hace sino acrecentar la misma pregunta. Según recuerdo, cuando aún se estaba discutiendo si elegir Systemd u OpenRC como init oficial (discusión que tengo entendido, se llevó a cabo primero en la comunidad de Debian), se optó por Systemd netamente por un par de ventajas técnicas:

https://wiki.debian.org/Debate/initsystem/systemd

Si durante esta discusión se tenían claras todas las desventajas y limitantes que conllevaría Systemd, ¿por qué no se optó por OpenRC?

Lo primero que veo al entrar a ese enlace es
>Systemd makes the boot process much simpler
jjjjjjjaaaaa es el booteo más lento que hay

>Systemd can handle the boot process from head to toe
En otras palabras, tiene sus tentáculos metidos en todo
Deberían llamarlo systemd/Linux en vez de GNU/Linux, o systemd+GNU+Linux estos días

>¿por qué se convirtió tan rápidamente en un estándar para la mayoría de las distribuciones grandes?
Simple, porque Poettering trabaja para la NSA y a Torvalds el FBI lo tiene amenazado de muerte

Odio hacer de abogado del diablo por un sistema que no apoyo ni utilizo, pero nunca he percibido diferencias prácticas entre el booteo de Systemd y el de OpenRC. Hoy en día es muy fácil hacer la prueba: se pueden preparar varios equipos para bootear la instalación de Arch Linux (que incluye Systemd) y Artix Linux (que incluye OpenRC), y comparar. Cuando he instalado y usado estos dos sistemas nunca percibí tiempos distintos de booteo (o bueno, pueden haber diferencias de segundos, pero nada más allá de 10 segundos). De hecho, me fijé especialmente en eso cuando instalé y usé Artix por unas semanas, porque ya había escuchado lo del tiempo de booteo.

Deberías probar runit, es la zorra. Te recomiendo Void Linux de paso.

>bueno, pueden haber diferencias de segundos, pero nada más allá de 10 segundos
¿...No te molesta una diferencia de 10 segundos cada vez que enciendes el computador? O eres de esos que tienen uptimes de varios días ww

Los tiempos de booteo es algo insignificante en comparación a la importancia de la forma en qie cada sistema gestiona los procesos.

Personalmente, encuentro que diez segundos es una diferencia insignificante como para constituir el argumento de "este init es el más lento". Ese es el uptime del init en todo caso, yo valoro más el uptime total desde que inicia la BIOS hasta que el sistema operativo está completamente utilizable. En ese sentido, pienso que el sistema operativo, más allá del init, tiene mucha más relevancia en el uptime.

Uptime se refiere al tiempo en que el computador pasa encendido y no tiene mucho que ver con la discusión, estaba haciendo un chiste porque hay gente que nunca apaga el computador y a ellos principalmente les daría lo mismo el tiempo de booteo, que es, bueno, "desde que inicia la BIOS hasta que el sistema operativo está completamente utilizable" como tú mismo dijiste pero con el nombre equivocado.

Tienes razón, el término estaba equivocado.

No sé ustedes cabros pero a mí por lo menos diez segundos me parece CALETA de tiempo. Cuando instalé un SO con runit por primera vez y me apareció el prompt casi inmediatamente después de encender el computador quedé maravillado, y eso que no estoy usando un SSD.

lo único que critico de systemd es la funcionalidad, el hecho de que se encargue de tantas cosas que podría ser complicado de debugear como dice >>1. aparte de eso, temas de arquitectura creo que ameritaba tener un init system que no dependiera tanto de scripts en bash o sintaxis no declarativa, es un avance. además, el hecho de poder utilizar otros init scripts antiguos para manejar servicios es bastante conveniente.

Ocho años después, creo que es interesante volver a ver esta charla que les recomiendo mucho ver...

27c3 - Desktop on the Linux... (and BSD, of course) - Wolfgang Draxinger (+ Lennart Poettering) (55:44)
stecklars

Al final, Poettering básicamente termina recurriendo a la falacia más básica para descartar las críticas a PulseAudio, Systemd, D-Bus y GDM: "no estás pagando por el software, por lo tanto no tienes derecho a reclamar por él, el código es abierto y gratuito y si no te gusta, puedes modificarlo, nadie te obliga a usarlo".

Es interesante notar cómo hoy en día es casi imposible escapar de las garras de PulseAudio, Systemd, D-Bus y GDM, no sólo porque muchas distribuciones incluyen este software por defecto, sino porque hoy en día la cantidad de software que depende de PulseAudio o Systemd es desconcertante. Systemd está imbuido profundamente en algunas distribuciones, pasando a formar parte de su esqueleto.

Lo que está consiguiendo esta tendencia de desarrollo (featuritis) no es sólo pasar completamente por alto el principio de simplicidad UNIX (como dice datenwolf en la charla, parchando errores tirando más código encima en vez de hacerse cargo del error simplemente), sino descartar de paso otra característica de los sistemas GNU/Linux, que es la posibilidad de elegir y armar tu sistema justo como tú lo quieres.

Gracias a lo anterior, muchas distribuciones tienden hoy en día a lo que es Windows o Mac: paquetes completamente prearmados que apuntan a usuarios analfabetas tecnológicos.

>Gracias a lo anterior, muchas distribuciones tienden hoy en día a lo que es Windows o Mac: paquetes completamente prearmados que apuntan a usuarios analfabetas tecnológicos.
Y eso es malo porque...

>>15
Es realmente una paja lo que está sucediendo y cómo Linux se está pareciendo cada vez más a Windows, pero al menos siguen algunos devs intentando mantener la filosofía UNIX como los de Void Linux o XFCE.

Hora de cambiarse a BSD cabros.

BAI Init System cuando?

BienveINIT a Internet

>>15,16
...

Entiende que con esa actitud aweoná de "debátanme, a ver" nadie te va a inflar, déjate de molestar. Aprende a discutir de buena manera o explica por qué estás en desacuerdo y entonces te van a responder.

Relájese, amigo, y de pasadita deje los prejuicios de lado. Tan solo estoy pidiendo que elaboren un argumento.

el tema con Systemd es que me anda bien y rápido al principio y dos meses más tarde a menudo me encuentro 5 minutos pegado en el poweroff porque algún daemon no se quiere apagar, me ha pasado en varias distros
es bloatware en el sentido más literal posible de la palabra bloat, es software que se va inflando con el tiempo

>5

https://mashable.com/2013/09/19/linus-torvalds-backdoor-linux/?europe=true

¿En serio creías que el puto FBI va a amenazar de MUERTE a Linus, y encima se va a saber púbicamente sin que nadie haga algo al respecto?

A Torvalds lo mató la dictadura LGBTI de lo políticamente correcto

>"Oh, Christ. It was obviously a joke, no government agency has ever asked me for a backdoor in Linux," Torvalds told Mashable via email. "Really. Cross my heart and hope to die, really."
No sé por qué pero no le creo ww.

Mientras tanto, en el oscuro mundo de BSD......

>27

Entonces no lo hubiera dicho en un principio. Te amenazan de muertes y haces bromas sobre ello arriesgándote a que de verdad te maten. Sí, seguro.

Más allá de eso, cuando pasó lo de Simon y Speck, por ejemplo, Linus se desentendió por completo del tema, busquen una sola declaración suya sobre el tema en línea: nada. El autista que cuando ve UNA línea de código mal en un commit arma una casa de putas... sí, claro, ¿qué onda con eso? ¿dejamos la cagada porque a un dev le faltó una coma, pero no decimos absolutamente nada cuando un dev de forma completamente vertical añade un módulo completo que a todas luces es un backdoor? Es obvio que a Linus lo tenían fichado hace rato para que abriera el culo y no dijera nada. A Linus y a todos los mantenedores principales del kernel.

La NSA tiene backdoors en Windows desde los 90, en Mac desde el 2001 (OS X). Hay que pecar de ingenuo para pensar que no van a intentar meter un backdoor en Linux sólo porque respetan la privacidad de los usuarios.

¿A todas luces un backdoor? ¿Bajo que evidencias?

Yo creo que es pasarse de conspiranoico. Para estar fichado, no sé, la forma en la que hace bromas. No tiene demasiado sentido.

>>32 la NSA previó que pensarían eso. por ese motivo hace que su marioneta, linus, siga el guión que le dieron :'v

>>32
No, obvio que no para matarlo, eso es medio bobo, aparte que la NSA no opera así.

A ver, lo que pasa es que a Linus siempre lo pintan como a este tipo cínico, sin pelos en la lengua, muy llevado a sus ideas y que defiende su proyecto muy quisquillosamente, etc, pero, ¿se han puesto a pensar en la cantidad masiva, billonariamente masiva de computadores personales, laptops, equipos empresariales, servidores, teléfonos TCP/IP y teléfonos smarthphones, dispositivos IoT... a los que la NSA tendría acceso ilimitado para espiar si lograran intervenir de alguna manera el kernel con un backdoor? ¿Y me van a decir que piensan que no lo han hecho ya sólo porque Linus es un tipo muy defensor del kernel y porque no nos escondería algo así? Eso sería un acto de ingenuidad pero... histórico, sobre todo considerando que la NSA tiene las manos metidas en Windows y Mac hace años. Es obvio que la NSA tarde o temprano iba a desarrollar interés por intervenir el kernel Linux. Simon y Speck fue eso, lean por favor el comunicado de Tomer Ashur y consideren el historial de la NSA. No confíen en nadie porque sí, ni siquiera en Linus.

>aparte que la NSA no opera así
como es que la NSA persuade a la gente?
no estoy lobomarineando ????

La NSA ha demostrado en el pasado dos formas de operar a la hora de dedicarse al espionaje masivo:

· Cuando el objetivo son las grandes marcas (Skype, Facebook, Microsoft, etc), han ejercido coerción legal, valiéndose de distintas leyes que los favorecen como agencia de seguridad nacional, o derechamente por sobornos monetarios; en PRISM ocurrió así. Glenn Greenwald detalla estos casos en el libro "No Place to Hide", que les recomiendo mucho leer (disponible en la Biblioteca de Santiago a todo esto).

· Cuando el objetivo han sido proyectos criptográficos, ya sea proyectos desarrollados por ellos, o en donde ellos intervinieron, el mecanismo utilizado es el del saboteaje deliberado de estos sistemas criptográficos, haciéndolos vulnerables en una manera tal que sólo ellos puedan vulnerar los equipos encriptados con el sistema, para luego poder intervenirlos de distintas maneras (incluido pero no restringido a un backdoor). Esto es lo que Ashur describe cuando escribió su comunicado criticando a Simon y Speck.

Esto ha ocurrido en muchas ocasiones y no sólo con Simon y Speck (cuando intentaron corromper Linux), y lo que mencionaba arriba de los sobornos también: el escándalo de la NSA y la NIST por ejemplo fue un intento deliberado de sabotaje, lo mismo con el escándalo de la NSA e IPSec, por otro lado, está el escándalo de la NSA y la RSA, cuando la NSA le pagó 10 millones de dólares a estos últimos para corromper un estándar de encriptación.

entonces podrían estar sobornando a Linus? es difícil de creer, pero supongo que es lo mismo que cuando dicen que Piñera ya tiene plata y tal... jeje

En mí caso, entre Runit y Systemd, Runit me tarda no más de 10 segundos. En systemd, puede sobrepasar el minuto. Una pasada.

Ohh wn, me convenzo de quedarme en Lubuntu y aparece esto. Mierda, me sacaste ganas de nuevo :1

Usa la distro que te sea más cómoda baisano. En la práctica, para un usuario común que no va a interactuar mucho con el init, no hay mucha diferencia entre Systemd y otros init.

systemd no es más cómodo porque a cada rato hay problemas debido a que tiene sus tentáculos en cada parte del entorno Linux y arreglarlos es un webeo :^)

Vean esto: https://www.youtube.com/watch?v=o_AIw9bGogo

Y de pasada lean esto: http://blog.aurynn.com/2015/12/16-contempt-culture

que es?

>en la práctica, para un usuario común que no va a interactuar mucho con el init, no hay mucha diferencia entre Systemd y otros init.
a la hora de instalar software que opera con servicios sí

>>44
Hay que ser menos tóxicos :/

no entendia que tanto problema con systemd, hasta que inenté hacer chroot en debian desde gentoo, y resulta que no puedo ejecutar los programas que quiero porque para iniciar sus servicios, se necesitan otros servicios que a su vez requieren otros y al final se requiere iniciar systemd entero y como proceso 1.
o algo así :c