OpenRC en isos de Manjaro para los que odian Systemd

Hoy leyendo mis RSS me enteré de una interesante noticia que nos ofrecía el Blog La Mirada del Replicante, y es que en la Comunidad de Manjaro se han lanzado varios ISOs con la peculiaridad de que no usan Systemd como init, sino OpenRC, el sistema de inicio usado por Gentoo.

OpenRC

No sé a ustedes, pero ya a mi el tema de Systemd me está tocando bastante las pelotas, y mientras mas leo, más me percato que aunque para el usuario final (o para muchos) no represente nada súper relevante, por lo menos a mi, no me gusta el camino que esto está tomando. Creo que se avecina una temporada negra en el mundo de GNU/Linux, donde los forks y el descontento brotará hasta en desiertos áridos.

Pero vamos al lío. En el foro de Manjaro han publicado, como dije anteriormente, algunos isos que hace uso de OpenRC. Y para los que temen instalar estas versiones, les dejo el vídeo de como hacerlo.

Descargar ISOs con OpenRC

El primer ISO que veremos es la versión NetInstall. Este ISO tiene como característica lo siguiente:

  • Basado en el perfil de Manjaro-Net profile (no tiene ningún Entorno de Escritorio pre-instalado)
  • Basado en la rama Testing.
  • Solo drivers libres
  • Usa la serie 3.14 del Kernel de Linux
  • No usa Plymouth
  • Fue probada en Virtualbox

El lenguaje lo podemos seleccionar al inicio presionando la tecla F2. Una vez que termine el proceso de arranque nos encontraremos con el prompt, donde usaremos para acceder:

  • Usuario: root
  • Contraseña: manjaro

Para iniciar la instalación como se muestra en el video anterior, escribirmos:

setup

Enlaces para descargar los ISOs

manjaro-net-0.8.11-openrc-i686.iso (32 bit)
(md5sum: 80be54ecfb0360b2a8e544344f72113c)

manjaro-net-0.8.11-openrc-x86_64.iso (64 bit)
(md5sum: ef205f70f3b3428545fdf1420db10b74)

Instrucciones para la Post-Instalación

En el foro de Manjaro nos ofrecen unos datos para la Post-Instalación:

Añadimos el repositorio de openrc-eudev siguiendo estas instrucciones.

1) Añadimos lo siguiente al final de /etc/pacman.conf

[openrc-eudev]
SigLevel = Optional TrustAll
Server = http://downloads.sourceforge.net/project/mefiles/Manjaro/$repo/$arch

Añadimos e importamos las llaves:

sudo pacman-key -r 518B147D
sudo pacman-key --lsign-key 518B147D

2) Actualizamos el sistema

sudo pacman -Syu

3) Instalamos nuestro entorno de escritorio preferido, en el ejemplo se usa lxde

sudo pacman -S lxde

La información acerca de la instalación de los Entornos de Escritorios se puede encontrar en la wiki.

4) Instalamos un Gestor de Sesión:

sudo pacman -S lxdm-consolekit
El Gestor de Sesión también se debe establecer en el fichero /etc/conf.d/xdm y hay más información aquí y aquí

5) Instalamos algunos paquetes como el applet para networkmanager

sudo pacman -S network-manager-applet

6) Reiniciamos el sistema

sudo reboot

Creo que sobra decir que para esto necesitamos estar conectados a Internet mediante un cable. Si usamos WiFi, pueden ver como hacerlo en este enlace.

ISOs de Manajaro con OpenRC y OpenBox

En el caso del ISO de Openbox hay que tener en cuenta algunas cosas:

  • El objetivo principal es hacer que el proceso de instalación sea más fácil y permitir configurar de forma gráfica la red (usando wicd) y el particionado usando GParted de forma opcional.
  • La configuración incluye Openbox WM, LXTerminal, PCMan y NetSurf Web Browser (para buscar información en la wiki o google), etc.
  • Utiliza el instalador por consola.

Enlaces para descargar los ISOs con OpenRC:

manjaro-openbox-openrc-2014-11-13-i686.iso (32 bit)
(md5sum: 9be7e75c75ab296f955a3396386c4764)

manjaro-openbox-openrc-2014-11-13-x86_64.iso (64 bit)
(md5sum: 07fd57df022118dfc9e2794a0ca3d26e)

ISO de Manjaro XFCE con OpenRC

Solo de forma experimental y para 64 bits, se encuentra también un ISO con XFCE:

manjaro-xfce-openrc-2014-11-14-x86_64.iso (64 bit)
(md5sum: e132f294f2ffd99c6cbc371d1e7a6d72)


68 comentarios, deja el tuyo

Deja tu comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.

  1.   unodetantos dijo

    No te falta razón, el asunto de systemd empieza a desprender cierto tufillo ya que OpenRC es el sucesor natural del actual init. Ya veremos en que acaba esta historia.

  2.   Wilhelm dijo

    «aunque para el usuario final (o para muchos) no represente nada súper relevante»

    Opino lo mismo, no es relevante porque como usuarios no nos a afectado en el funcionamiento del SO en si.

    De hecho el unico grande (debian), ha dado noticias de «escandalo» sobre el tema, y aunque dicen que son otros los motivos todos los relacionaron systemd ( y no deberian).

    Las otras distros grandes, no se han hecho problema ( o almenos manifestado con picas y antorchas), Fedora, Ubuntu y OpenSUSE.

    A mi me da la impresion de que es una pelea entre programadores, ya que por ejemplo opensuse 13.2 tiene una buena aceptacion/critica y nadie en los reviews se manifiesta de systemd (auque sea para instaurar debate),

    Ahora para que tanto jaleo de de pasar a systemd a OpenRC, si alfinal no les afecta.

    1.    dero dijo

      En lo personal lo de systemd, me da inquietud he inseguridad, buen post.

    2.    Yukiteru dijo

      En Fedora se dio cierto debate sobre systemd cuando se decidio ponerlo como init, habían algunos detractores al sistema, más que todo porque no estaban de acuerdo de usarlo como init por defecto debido a que estaba muy fresco y tenía muchas fallas, sin embargo, la mayoria de los devs de peso están en el equipo de desarrollo del core y estaban relacionados con systemd, asi que la sustitución de Upstart por systemd fue una muestra de cierta imposición, además del tema de que Upstart era un desarrollo de Ubuntu y tiene una CLA bastante mal vista, que al final ayudo a que todos aceptaran sin chistar a systemd. OpenRC estaba fuera de discusión en ese entonces, ya que carecia de muchas de las características que tiene ahora, entre ellas paralelización y el soporte de cgroups.

  3.   anonimo dijo

    Excelente noticia! una distro binaria que va a dar a conocer openrc….es como un regalo del cielo.
    Es el camino que tendría que haber tomado archlinux desde un principio, recuerdo cuando tuve que avandonar archlinux por irse a systemd. Ahora tengo la posibilidad de volver a probar una distro binaria con openrc+eudev que es justamente lo que uso aqui en gentoo.
    Mil gracias gente de Manjaro!!!

    # eix -Ic openrc
    [I] sys-apps/openrc (0.13.6@24/11/14): OpenRC manages the services, startup and shutdown of a host
    # eix -Ic eudev
    [I] sys-fs/eudev (2.1.1@31/10/14): Linux dynamic and persistent device naming support (aka userspace devfs)

  4.   Xiep dijo

    Gracias por la info, elav!

    Comparto tu opinión respecto a systemd y también me preocupa la deriva que ha tomado Linux desde la aparición de este nuevo init. Si Wheezy se queda muy viejo antes de la llegada del fork de Debian, me pensaré darle una oportunidad a Manjaro OpenRC, ya que no tengo el tiempo libre necesario para prepararme un sistema Gentoo (he valorado hacerlo pero, definitivamente, el tiempo de compilación de Gentoo es demasiado extensa para mi situación personal).

    Saludos!

  5.   Cristian dijo

    Elav puedes describir en menos de 10 palabras para un usuario que no entiende demasiado la «polémica», hace rato hay varios artículos en el blog que están siendo muy técnicos, y no terminan de explicar el contexto para los «no iniciados»… alguna vez me dijeron que independiente de lo técnico, una explicación debe ser entendida hasta por tu abuelita para que sea buena.

    En realidad en fedora, hace rato, el problema se está volviendo insufrible, tanto es así que varios usuarios de escritorio estaban pensando en pasarse a centos, para bypasear el problema

    1.    Luis dijo

      Me apunto a esa petición.

      A mi me va bien con Systemd ¿Cual es el problema que causa tanta movida?

      Digamos que no me entero.

    2.    daryo dijo

      systemd es el programa encargado del inicio del sistema pero los desarrolladores de este decidieron extenderlo y ahora no solo maneja el inicio sino tambien cosas como el cron (programa para ejecutar programas de forma automatica), la red , los logs del sistema que por cierto son binarios.entre otras cosas

      muchos no ven con buenos ojos un cambio tan brusco sobretodo porque es un software nuevo por tanto con muchos mas bugs que los programas que habian funcionado toda la vida , ademas de generar dependencias a la hora de programar y por ejemplo gnome esta cada vez mas ligado a este sistema. Haciendolo menos portables a otras plataformas unix.

      no se si mi otro comentario no paso la moderacion pero decia que me gustaba systemd pero no deberian dejar que monopolize todos las distribuciones y dejar alternativas como siempre se ha hecho en linux para quienes tienen diferentes necesidades.

    3.    daryo dijo

      me falto decir que antes el programa encargado de iniciar el sistema en el boot era system v que llevaba desde hace muchisimo tiempo hasta que fue reemplazado en la mayoría de distribuciones por systemd xD.

    4.    elav dijo

      A lo que dice @daryo le añado lo siguiente (que es mi opinión además):

      Siempre me ha gustado la filosofía de Unix donde un programa hace solo una cosa, pero la hace bien. Al querer Systemd controlar todo lo que te comentó @daryo, me surge una pequeña duda ¿y que pasaría si Systemd de alguna forma se ve comprometido? Pues arrastraría consigo posiblemente todo lo que controla.

      A eso le sumo (y quizás esto es más por costumbre), que siempre me ha gustado que los logs de mi sistema sean puros archivos de texto, pero con Systemd todo es binario, y no sirven comandos como:

      cat log.txt

      o

      tailf log.txt

      Donde podíamos usar otras opciones como GREP para filtrar determinado contenido, sino que Systemd usa un comando nombrado journalctl.

      Además de lo antes mencionado, debo decir que siendo RedHat el principal exponente detrás de Systemd, se me enciende una alerta que no logro apagar. A lo mejor me equivoque, pero esto no pinta bien.. Y me sigo preguntando ¿qué necesidad hay de controlar el arranque, el cron, la red y cuanto servicio exista? ¿Qué pretenden con eso?

      1.    Alexander dijo

        Gracias a tu comentario y lo que vengo investigando puedo confirmar tus sospechas, esa alerta esta en lo correcto Broder.
        Veras vengo leyendo sobre TCP Stealth, es una tesis alemana donde acusan a Red Hat, de facilitar el espionaje industrial a los sistemas de escucha de los 5 ojos:
        Ya escribi sobre esto, si tienes el talento necesario, se que lo tienes, podras llegar a tus propias conclusiones:
        https://gnunet.org/sites/default/files/ma_kirsch_2014_0.pdf
        http://heise.de/ct/artikel/GCHQ-NSA-El-programa-HACIENDA-2293098.html#TCP Stealth

      2.    Yukiteru dijo

        Solo para complementar tu buen comentario @elav, systemd tiene un nivel de NIH tan grande, que ahora pretende controlar lo siguiente:

        1.- Gestión de conexiones de internet con IPv4 e IPv6, usando systemd-networkd y systemd-nspawn.
        2.- Gestión de DNS a través de una cache DNS interno, systemd-resolved.
        3.- Gestión de Multicast DNS en redes internas, usando systemd-networkd.
        4.- Gestión de terminales TTY en Linux, usando systemd-consoled. (¿Adios KMScon?)
        5.- Gestión de sesiones y privilegios por medio de logind.
        6.- Control de coredump, usando archivos en binario, y saltandose las directivas del kernel.
        7.- Control de logs, usando archivos en binario, y saltandose las directivas del kernel.
        8.- Control de eventos ACPI usando logind. (Systemd-212 agrego varios quebraderos de cabeza a los devs de Nvidia con varios bugs que dejaban inutil el sistema)
        9.- Soporte PPPoE para networkd, un trabajo que aún está en progreso.
        10.- Soporte para DHCP en cliente y servidor. (¿Qué hacen con eso? Ni idea)
        11.- Soporte para sistemas con factory reset, que por cierto está muy ligado a BTRFS (No se sorprendan si luego BTRFS se convierte en dependencia de systemd, al buen Lennart le encanta)
        12..- Soporte para containers virtualizados (Xen y KVM principalmente)
        13.- Soporte para manejo e inicialización de dispositivos (lo que hace udev)
        14.- Manejo de sistemas de encriptación de discos.
        15.- Carga de firmware y modulos del kernel.
        16.- Manejo de hostname (te crea hasta un identificador único de tu PC), locales, horario, sincronización NTP, sysctl (variables de control del kernel), y del generador de numeros aleatorios incluso (Muy WTF esto, y levanta mucha suspicacia)
        17.- Manejo de sistemas de archivos temporales.

        En fin lista larga, son las cosas que conozco que systemd hace, si alguien conoce alguna más que la diga :).

        PD: systemd ya no ofrece soporte para scripts LSB ni SysV desde systemd-214, asi que no se cuan cierto sea ahora su soporte «legacy» ni que tan respetuosos de los estandares sean. Digo ¿LSB sigue siendo el estandar en Linux, o me equivoco?

        1.    Allan Herrera dijo

          Gracias por avisarme, pensaba pasarme a BTRFS pero sabiendo que le gusta a Lennart, puedes saber que debe ser horroroso y espia de la NSA-IBM

    5.    anonimo dijo

      Es poco espacio para resumir y explicar tanto…se trata de una caballo de troya gigante, que ni si quiera intentan disumular. Que hace un sistema de inicio metiéndo servicios de red , dhcp dns y hasta creo que avahi…dentro de systemd ?. Se pierde poder de desición al no poder manejar los servicios
      que no se desean y que no me vengan que se pueden desactivar, yo no los quiero en el paquete systemd!
      En OpenRC, es uno el que descide que cosas se inician en cada runlevel, algunos servicios tienen dependencias de otros servicios pero son muy pocos y salen listados…en tanto en systemd cualquier cosa hace lo que se le da la gana en el momento que se le da la gana …para ganar unos 5 segundos en el booteo y ser rápido en el apagado.
      Systemd es tan complejo, que es imposible saber que hace, te tienes que resignar a pensar que es tu amo y no te hace nada malo.
      Systemd rompe el concepto de que las cosas deben ser fáciles y entendibles en cuando a los demonios o servicios y runlevels, nadie de los que usa systemd sabe cabalmente que sucede en sus servicios en cada momento.
      Systemd no permite usar syslog-ng de forma nativa, han puesto a journald que lo pisa y no lo deja funcionar, o sea, o usas journald o naninga!. El log del sistema es algo fundamental para la seguridad y auditoría de lo que paso y esta pasando con las conexiones locales y remotas, pero journald usa un formato binario que solo jornalctl puedo verlo….muy a menudo a journald se le corrompe «misteriosamente» su archivo binario y como lo ve corrupto lo borra de una y empieza con uno nuevo, olvidandose de todo los logs que ya habian.
      Puedo seguir por horas, pero el peor problema es que Lennart no le da bola a los que reportan esos errores y tampoco hasta donde lei, acepta parches de cualquiera.
      Pense que al meterse debian en systemd, ellos irían a reportar bugs y parches, que los de systemd tendrian que aceptar….pero sinceramente creo que Lennart y RedHat tienen otro plan para el resto de las distros…..como dije antes, CABALLO DE TROYA de RedHat.
      Sinceramente para mi systemd no es arreglable, la idea detrás de su diseño es perversamente mala, es mejor empezar un sistema de inicio desde cero que tratar de arreglar ese frankestein.

      1.    elav dijo

        AMEN!! @anonimo..

      2.    kunagi dijo

        Llevo como un par de años usando systemd (Fedora) y he llegado a esto:
        El asunto huele a raro, conforme más cosas añaden más desactivo/redirijo.
        El journald lo tengo dirigido a rsyslog directamente. Algún log binario suyo se ha roto ya.
        De dns uso a bind, si lo integran en systemd lo seguiré usando igual, aunque me toque modificarlo todo.
        Uso XFCE así que me ahorro buena parte de lo que gnome quiere integrar.
        Es como un elefante en una cacharrería.

      3.    Tito dijo

        Cierto; ni siquiera ellos saben como denominarlo. Salimos a actualización diaria, corrigiendo bugs y demás mierdas. Es un tema que me enfada bastante; pero no ya sólo por el hecho de que SystemD sea una soberana cagada; si no el cómo lo han hecho.
        Está claro que en el mundo Linux, hay varias empresas que intentan controlarlo todo; véase Canonical, RedHat y Gnome, (hasta el propio Miguel de Icaza se ha largado de Gnome).
        Si uso Linux es por uqe lo controlo y esa es la base y filosofía de lmismo; para no saber que está haciendo, monto máquinas con W Server y a correr.
        Lo que me da lástima es que Debian, haya sucumbido. De hecho se está planteando la posibilidad de crear un fork paralelo sin SystemD.
        Esperemos que la cosa no vaya a más; o me veo migrando todas mis máquinas a BSD.

      4.    Yukiteru dijo

        @anonimo, pedazo de comentario man, no puedes tener más razón.

        systemd es una cosa loca que no tiene explicación en muchas cosas, la verdad causa mucha suspicacia todo lo que hace y no deja hacer a otras herramientas, la verdad no se como se dejan meter esto los de Debian, pero en fin ya tomaron esa decisión, y por primera vez en muchos años he dejado de usar Debian como SO principal, y seguira así hasta que systemd salga de Debian por una opción más transparente.

    6.    Tito dijo

      En resumidas cuentas. SystemD es una auténtica mierda.
      Almacena logs en formato binario, se ejecuta como proceso padre de todos los demás, (Pid 1), con lo que si algúno rompe, el sistema se hace irrecuperable; va en contra de todo lo que significa Linux, ésto es, archivos de texto plano, (que coño es eso de archivos binarios??, archivos de texto plano! como toda la vida de dios.)
      Vamos, que es una porquería. No me gusta nada de nada.
      Pero gracias a compañias como Canonical, Gnome y Red Hat; nos lo vamos a comer con patatas.
      Eso si, mientras existan otras opciones; yo no lo usaré, ni en los servidores que administro, ni en mis máquinas personales.
      Ésto ya se está convirtiendo en una sucursal de la empresa de Redmond.

      1.    sephiroth dijo

        no pretendo defender a nadie, pero bien recuerdo que canonical estaba totalmente en contra de systemd en favor de upstart. cuando debian se rindió ante systemd termino arrastrando a ubuntu.

  6.   daryo dijo

    ademas esos bugs pueden comprometer la seguridad del sistema y la estabilidad de por ejem un servidor por eso es que los que mas se quejan de estas cosas son los sys admin .

  7.   Alexander dijo

    Y que me dicen de Mageia, es increible que un KDE pueda correr sobre 512 MB de ram, impecable.
    http://mirror.cedia.org.ec/mageia/iso/cauldron/

  8.   Sergio E. Durán dijo

    unas cuantas preguntas; ¿Que tan facil es gestionar los servicios en OpenRC? y ¿que tan facil es instalarlo usarlo por defecto en una instalación de Manjaro con systemd? lo que me gusta de systemd es que con el simple comando systemctl enable (servicio).service o un systemctl disable (servicio).service puedo gestionar mis servicios facilmente, SI me interesa saber sobre OpenRC y sobre todo pues si me huele un poco raro todo esto de systemd, por cierto; soy usuario novell

    1.    Sergio E. Durán dijo

      Por cierto; dice que estoy en Windows porque estoy usando user agent overrider

    2.    anonimo dijo

      OpenRC se maneja muy fácil, te doy un ejemplo con el servicio cupsd de impresión.

      Para iniciarlo.
      # rc-service cupsd start
      * Starting cupsd ..[ ok ]

      Para detenerlo.
      # rc-service cupsd stop
      * Stopping cupsd …[ ok ]

      Para reiniciarlo.
      # rc-service cupsd restart
      * Stopping cupsd …[ ok ]
      * Starting cupsd ..[ ok ]

      Para ponerlo que se inicie en el runlevel default.
      # rc-update add cupsd default
      * service cupsd added to runlevel default [ ok ]

      Para quitarlo del runlevel default.
      # rc-update del cupsd default
      * service cupsd removed from runlevel default [ ok ]

      Para ver el estado de todos los servicios en todos los runlevels.
      # rc-status -a

      Para ver el estado de un runlevel, en este ejemplo default.
      # rc-status default

      Aquí en gentoo, OpenRC es el sistema de inicio por defecto y lo seguirá siendo por siempre, tenemos systemd en portage para los suicidas, que por suerte son pocos….
      Para reemplazo de journald, usamos syslog-ng y logrotate, aquí en gentoo el log del sistema sale por la consola virtual vt12 o sea control+alt+F12, o puedes verlo de continuo en cuaquier terminal gráfica como usuario root con:

      # tailf /var/log/messages

      1.    Sergio E. Durán dijo

        ¿y para instalarlo en mi Manjaro?

      2.    Sergio E. Durán dijo

        Digo; no voy a perer todos is archivos y mi hermoso XFCE nomás por cambiarme a OpenRC 🙂

      3.    Sergio E. Durán dijo

        Listo; lo instalé al usar sudo pacman -S manjaro-openrc bluez-openrc (este ultimo pues tengo bluetooth)

      4.    Sergio E. Durán dijo

        Ahora mi problema es que XFCE4 power manager no funciona con upower-pm-utils 🙁 y no tengo las opciones tipicas de suspend e Hibernate

    3.    Yukiteru dijo

      OpenRC es muy sencillo, gestionar servicios es pan comido, solo por poner un ejemplo:

      Habilitar un servicio: rc-update add cronie default

      Iniciar un servicio: /etc/init.d/cronie start o rc-config start cronie

      Detener un servicio: /etc/init.d/cronie stop o rc-config stop cronie

      Sencillo y nada complejo en realidad.

  9.   Yukiteru dijo

    @elav lo que se avecina es para largo, y va desde tormentas de arena, lluvia de trolls, forks a granel, divisiones de los grupos dev, y muchos preguntandose si migrar a BSD es mejor opción que calarse a systemd, porque si.

    En lo personal, aplaudo esta iniciativa de Manjaro, es una opción para quienes no quieran quedarse con systemd, algo que a mi me agrada, en este momento ando en Gentoo y me agrada, me siento comodo con la libertad que me da, pero ya se me ha pasado varias veces por la mente hacerme el cambio a FreeBSD, y puede que en este mes de el salto, todo depende de mi tiempo y de ordenar ciertas cosas para llevar con exito la migración.

    1.    Yukiteru dijo

      Nada de eso refuta la realidad de systemd, Lennart es muy bueno esquivando las cosas y responsabilidades, le recomiendo que en ves de limitarse a leer artículos, se lea el código de systemd o al menos se lea la lista devel de systemd, se enterará de cosas que refutan lo que dicen esos tres artículos que ha pasado, y apoyan mas a los detractores de systemd.

      1.    pamp dijo

        Su argumento consiste en establecer que existe un conocimiento que refuta lo que mostré, pero jamas presenta las pruebas, de forma que no puedo confiar en su existencia.
        https://lists.debian.org/debian-ctte/2013/12/msg00234.html

      2.    Yukiteru dijo

        @pamp mi argumento está un poco más respaldo por lo expuse más arriba en el comentario 25 de esta misma entrada, y lo he expuesto en muchas otras entradas referentes a systemd, además de exponerlo en el irc de Debian y la lista de esta distribución, además mi invitación, es a que usted se cree sus propias opiniones y para ello tan solo tiene que leer un poco la lista devel de systemd. Además solo para levantar su curiosidad le doy este enlace en el que claramente hablan de que systemd-214 ya no ofrece soporte para los scripts SysV y LSB, con la excusa de «limpieza del código».

        http://lists.freedesktop.org/archives/systemd-devel/2014-June/019925.html

        Ahora digame: ¿Donde está el soporte al estandar LSB que se supone fue creado con el fin de crear una base común para todas las distros? Porque dejeme decirle algo, nada más en su primer enlace Lennart se regordea, se jacta y se llena la boca de decir que systemd soporta el uso de scripts SysV y LSB, cuando la verdad es que ese soporte está dropeado y sustituido por un generador de init-files, que dicho sea de paso, tiene varios bugs y al final no queda otra que hacerse un init-file por completo.

        Saludos.

    2.    Tito dijo

      Lo de las opiniones, es como el culo, todos tenemos uno.
      Lo que diga éste señor, puede irle muy bien a él, pero no es mi caso. Y la opinión de un señor que escribe en un portal web, no es que sea palabra de Dios. Es su opionón y punto.
      Así que de «refutadas» , nada.
      Lo bueno que nos queda, es que podemos usar lo que nos de la real gana; sin intentar ser «talibanes» e imponer nuestro criterio a los demás.
      Para mi SystemD es una auténtica cagada. Y hay gente a la que le encanta. Pues bienvenidos sean!
      Ni mi opinión es la buena ni la de los que no opinan como yo es una mierda; simplemente son distintas.
      Ésto es lo que nos distingue de otros sistemas operativos; podemos escoger.
      No caigamos en peleas inútiles que no llevan a ningún sitio.

      1.    anonimo dijo

        @Tito
        Mejor no lo podrías haber dicho…amén.
        Hay que ser ciego para no darse cuenta de la pervesidad que impulsa systemd en abarcarlo todo, pisando, tapando y desplazando proyectos que andan perfectamente, reemplazándolos por versiones que nunca llegan ni llegarán a ser estables, incluso no hay compatibilidad entre núcleos y mas de dos versiones para atrás de systemd.
        A los de debian parece que les llegó el terremoto y se lograron despertar, solo espero que se inclinen por eudev y openrc, así se unificaría el desarrollo de gentoo debian manjaro y algunas otras que usan openrc, lo que lo mejoraría muchisimo en poco tiempo, ganando toda la comunidad.

      2.    Dah65 dijo

        Secundo tus palabras.

        Hay gente que cita a otra gente (las opiniones que le interesan, generalmente), y las esgrime como prueba.

        Por mi parte, no tengo una opinión respecto a systemd. No sé si técnicamente es mejor que upstart o que openrc, pero lo que sí parece claro es que la posibilidad de sysvinit está descartada por TODAS las distros, siendo Debian la única que aún la conservaba en Wheezy debido a su política. Pero la próxima Debian estable, Jessie, iba a ser una Debian sin sysvinit.

        Lo que sí esta claro es que éticamente es software libre 100%; en cuanto a su parte técnica, ni he estudiado el código ni lo he comparado con sus alternativas, así que no tengo una opinión fundada. Pero incluso las Ubuntu actuales usan partes de systemd aunque aún conserven upstart, y dudo que lo hayan hecho porque Canonical está «comprada» por Red Hat.

        Systemd no es «perversidad», por favor, que no estamos luchando contra Skynet (Terminator), ni contra HAL9000 («2001 odisea del espacio»), ni es el lado oscuro de la Fuerza que pretende dominar a los Jedi. Ni tampoco es que al instalarse en un equipo se apodere de todo y haga desaparecer hasta los víveres de la despensa.

        Y eso de que «desplaza proyectos que andan perfectamente» (comentario 52), yo he tenido problemas con una red NFS doméstica en los equipos que acceden al servidor porque el proceso de apagado del equipo cliente desconecta la red antes de desmontar el sistema NFS, y el apagado se congelaba, siendo la única solución apretar el botón de on/off para apagarlo a pura fuerza (bug reportado por diversos usuarios) ; tuve que crear un script que desmonta los archivos NFS para ejecutarlo antes de apagar el equipo cliente. Por otra parte, el equipo servidor NFS se conecta por wifi, y de vez en cuando la conexión se pierde: no sé si el problema es el network-manager o está en dhcpd, o dónde.

        No estoy diciendo que esos problemas desaparezcan con systemd; lo ignoro, porque no lo he usado. Es sólo una muestra de que decir que los proyectos que sustituye systemd andan perfectamente es exagerado.

      3.    Yukiteru dijo

        Una cosa es una opinión y otra cosa es un argumento, ciertamente lo primero es muy variado como dices @Tito, pero lo segundo es algo más conciso y centrado, no es algo que pueda ser tan facilmente manipulado, al menos, no en el caso del software libre, donde tenemos el código al alcance para revisarlo.

        @pamp nos dice que los argumentos mostrados están refutados desde hace mucho tiempo, y como primera prueba nos pone al tanto de las opiniones (que no argumentos) de Lennart . Pero una cosa es lo que este tipo dice en sus comentarios (los números 4 y 8 son simplemente para morirse de risas), y otra la que hace en el código de systemd. Una actitud que he visto en repetidas ocaciones en Lennart desde que empezo a desarrollar cosas como Avahi y Pulseaudio, y que simplemente puede corroborarse leyendo las listas devel y los bugs reports de ambas piezas de software.

      4.    Yukiteru dijo

        @Dah65 ciertamente mucha gente esgrime pruebas usando las opiniones de terceros, una mala costumbre de aquellos que no pueden investigar por si mismo en los temas para tener una opinión propia y personal, e incluso, crear argumentos válidos con los cuales participar en una discusión constructiva.

        En mi caso, yo me mantengo al tanto de los cambios en systemd gracias a la lista devel, aunque no me gusta la herramienta, me desagrada totalmente, pero no por ello dejo de leer sobre ella a nivel de usuario y técnico, y la razón para esto es muy sencilla, si tengo que atender a un cliente que use dicho init, ya se que debo hacer y como atender cualquier situación.

        Ahora sobre lo que los servicios andan sin problemas, eso es una falacia, hay muchos scripts SysV con problemas, y lo mismo pasa en systemd, pero al menos cuando reportas un error en un SysV se arreglan o puedes hacerlo de forma sencilla como has comentado, en systemd, tras hacer un reporte de bugs te puedes encontrar con un WONTFIX o CLOSED, gracias a Lennart o Kay, según sea el caso y no exagero al decir esto, una muestra aca:

        https://bugzilla.redhat.com/show_bug.cgi?id=753882

        Leanse el comentario 48, no tiene perdida. El 53 de Clement es otro que no tiene perdida, especialmente por su solución arcaica pero funcional ante el problema que Lennart no quiere solucionar y que dicho sea de paso fue reportado en 2011.

    3.    mario dijo

      Esos «mitos» quien los estableció? Algunos los saca de la galera como «systemd is not portable for no reason.» Es completamente verdadero que no es portable (y él lo admite diciendo que está muy personalizado para Linux)
      Asume falacias, como el supuesto de que BSD no está interesado (los muchachos de BSD dicen lo contrario: «Jordan Hubbard – FreeBSD: The Next 10 Years (MeetBSD 2014)» ), aunque fuera portable no lo adoptarían y cosas por el estilo (mito 13,14,15).

      Si la intencion de Poettering es que nos pongamos a reescribir scripts, exclusivos para su sistema (http://0pointer.de/blog/projects/systemd-for-admins-3.html) vamos a andar mal. En principio un clásico init script no le importa donde está andando. Se le hace mínimas modificaciones para funcionar en en GNU, UNIX o BSD. Bueno, eso era hasta ahora (a menos que se use OpenRC). En fin, creo que cosas como esta produciran un cisma entre Linux para escritorio y servidores. Los usuarios de ubuntu y derivadas recien a fines del año que viene verán los cambios.

      1.    anonimo dijo

        @Dah65

        Bueno, ya que dices que systemd no es la perversidad personificada, dime entonces porque no ponen en el Makefile opciones para deshabilitar en tiempo de compilación todos sus modulos, de manera que a los que no nos gusta tener esos «módulos opcionales» que pisan a otros paquetes, los podamos asi compilar y crearnos nuestras propias versiones de systemd capadas!
        Sabes porque no lo hacen? porque su forma de desarrollo se llama imposición a la fuerza y como el 95% de los usuarios no tienen NPI se aprovechan del por defecto lo descidimos nosotros por todos ustedes.
        Así no funciona el software libre o opensource o como quieran llamarle, ahora me da risa, porque con el nuevo fork a debian muchos salen a opinar que es un desperdicio de fuerzas y yo me sigo preguntando ¿tan dificil era ponerle opciones de compilación adicionales al Makefile?
        El tema no da para mas, esto es como querer mezclar agua con aceite, es por eso que aprecerán interminables forks en cada desarrollo en donde haya imposición de unos pocos para todo el resto.

      2.    Yukiteru dijo

        @mario es exactamente lo que dices. Jordan Hubbard también ha entrado en razón en que el init de BSD necesita actualizarse no solo para adaptarse a las nuevas tecnologias sino también para soportar nuevas caracteristicas que ahora son posibles, pero é pasa de largo el concepto que ahora tiene systemd de como se deben hacer las cosas, y lo simplifican a la filosofia que siempre ha imperado en UNIX, «Hacer un programa que haga una cosa y lo haga bien», y eso en un init es de suma importancia, puesto que no hablamos de un demonio más, estamos hablando del init de un sistema operativo, además de que es una medida de seguridad, frente a lo que muchos especialistas ya comienzan a vociferar sobre systemd, y es demostrable, systemd se parece mucho a svchosts.exe de Windows, haciendo desde el init de servicios hasta el control de redes entre muchas otras cosas más.

  10.   Luis dijo

    Tios, la verdad es que da miedo.

    ¿Es muy complicado de eliminar de ArchLinux????

    Voy a buscar información pero no me atrevo a tocar ese tipo de cosas no sea que meta la pata y me quede sin sistema.

  11.   manu dijo

    Por los muchos comentarios que leído, SYSTEMD es un autentico CABALLO DE TROYA….
    Esto quiere decir salvence quien pueda?, hay poca información en español -sobre la configuración de escritorio en FreeBSD y dejar a punto el sistema para ser utilizado.

  12.   Rafael Mardojai dijo

    Pobre systemd, déjenlo ser. xD

  13.   waco dijo

    esto del odio a systemd no sera viral???? a mi me ha ido de maravilla con arch.. si es verdad que esta abarcando mas, no se si es bueno o malo! pero acaso ya hay vulnerabilidades de tomar el control o algún virus que destruya el sistema debido a este… si es estable y seguro no veo el problema… de todas maneras voy a ver si tengo un tiempo y estudio el tema y hago unos test con openrc

    1.    daryo dijo

      no es tan estable . y es mucho mas inseguro que system v. para un usuario de escritorio como muchos de nosotros(yo) tampoco representa un problema hace un boot mas rapido funciona bien y no se suelo leer los logs asi que no importa la claridad de estos ni que sea en formato binario .

      tengo una teoria linux crecera en los escritorios(y gobiernos) y perdera terreno en servidores (lugar que tomaran SO como freebsd)

  14.   Oscar dijo

    En la Wiki de esdebian publican como instalar SysVinit en Debian Jessie. http://www.esdebian.org/wiki/sysvinit

  15.   anonimo dijo

    Leyendo sobre seguridad, me entero de que por el lado de intel, hay placas madres con chipsets, generalmente en el northbridge, implementan algo llamao AMR Intel Active Management Technology….interesante, por suerte no tengo intel, pero empezaré a buscar si por el lado de AMD no hay algo parecido.
    Se imaginan una combinación de intel+AMR+systemd, que Dios no lo permita.
    https://en.wikipedia.org/wiki/Intel_AMT_versions
    Con razón que el paranoico de Stallman pide a gritos por bios libres.

  16.   Dah65 dijo

    En primer lugar, no uso systemd porque aún no está incorporado a Kubuntu (estoy con Netrunner 14, derivada de Kubuntu 14.04).

    Aclarado esto, hay que puntualizar varias cosas:

    1- systemd está siendo adoptado por desarrolladores/empaquetadores de muchas distros diferentes (Debian, openSUSE, Arch, Fedora…), pero ahora resulta que los lectores de este blog sabemos más que ellos sobre las ventajas e inconvenientes de systemd.

    2- systemd es software libre, cuyo código puede ser leído (y comprendido), por quienes tienen tiempo y conocimientos (esos desarrolladores/empaquetadores de los que hablaba antes). Si esconde puertas traseras, se descubrirían. ¿Cuántos de los lectores usa un firmware o driver propietario, cuyo código no ha leído ni puede leer? Creo más sensato tenerle miedo a eso que no a systemd.

    3- Todos trabajamos con paquetes binarios, pues cuando yo me bajo un .deb de los repositorios para instalarlo, no me estoy bajando un archivo de texto plano. Así pues, ese argumento es bastante paradójico.

    4- En GNU/Linux ya hay programas que hacen muchas cosas: el mismo kernel, que cada vez integra más drivers, e incluso firmware propietario (mejor poner una puerta trasera en el firmware cerrado que en un programa cuyo código está publicado). También está Xorg, que no sólo maneja el servidor gráfico sino también el teclado, el ratón, y otras cosas más; nadie dice que Xorg «traicione» la filosofía UNIX por eso, se le quiere jubilar porque ya ha sido superado por otros proyectos.

    5- «Linux is choice», claro, pero es la libertad de elegir si quiero leer el código, alterarlo, distribuirlo, etc. No es que las distros estén obligadas a dar todas las elecciones (todas las arquitecturas de procesador, todos los entornos de escritorio, todos los formatos de paquetes, etc)

    6- Para los que están pensando en pasarse a un BSD, recuerdo haber leído noticias de que en algunos sistemas BSD la NSA estadounidense ya había puesto sus zarpas. Si dicha noticia era acertada, lo desconozco porque no he seguido el tema. Pero es irónico que huya de algo «porque está Red Hat detrás y quizá…» para meterme en algo que «quizá la NSA esté detrás….»

    Además de usar GNU/Linux, BSD, Windows, o lo que quiera que usemos, podemos usar también nuestra lógica y capacidad de razonar

    1.    elav dijo

      En primer lugar, no uso systemd porque aún no está incorporado a Kubuntu (estoy con Netrunner 14, derivada de Kubuntu 14.04).

      Aclarado esto, hay que puntualizar varias cosas:

      1- systemd está siendo adoptado por desarrolladores/empaquetadores de muchas distros diferentes (Debian, openSUSE, Arch, Fedora…), pero ahora resulta que los lectores de este blog sabemos más que ellos sobre las ventajas e inconvenientes de systemd.

      O sea, que los lectores de este blog, por ser solo lectores, no tienen la capacidad de percatarse si algo es bueno o no, porque debemos guiarnos por el buen juicio, conocimiento y experiencia de empaquetadores y desarrolladores.. ¿Es eso?

      2- systemd es software libre, cuyo código puede ser leído (y comprendido), por quienes tienen tiempo y conocimientos (esos desarrolladores/empaquetadores de los que hablaba antes). Si esconde puertas traseras, se descubrirían. ¿Cuántos de los lectores usa un firmware o driver propietario, cuyo código no ha leído ni puede leer? Creo más sensato tenerle miedo a eso que no a systemd.

      Es cierto, es Software Libre, y si apareciera algo raro las super personas de las que hablabas antes y de las que debemos fiarnos se podrán percatar y anunciarlo, o quizás no, porque a lo mejor como son personas se sienten tentados a callarse a cambio de algo.

      3- Todos trabajamos con paquetes binarios, pues cuando yo me bajo un .deb de los repositorios para instalarlo, no me estoy bajando un archivo de texto plano. Así pues, ese argumento es bastante paradójico.

      Cuando tu te bajas un .deb lo único que estás haciendo es bajar un fichero comprimido, el cual puedes descomprimir y por ende, ver lo que tiene adentro y es posible, que en su interior es donde si está el binario. 😉

      6- Para los que están pensando en pasarse a un BSD, recuerdo haber leído noticias de que en algunos sistemas BSD la NSA estadounidense ya había puesto sus zarpas. Si dicha noticia era acertada, lo desconozco porque no he seguido el tema. Pero es irónico que huya de algo “porque está Red Hat detrás y quizá…” para meterme en algo que “quizá la NSA esté detrás….”

      No sé cuales son los usuarios que van a huir de Linux para irse a BSD, pero yo por ejemplo en dado caso no tendría que salir de Linux, solo tendría que salirme de una distribución que te meta Systemd por atrás si o si.

      Además de usar GNU/Linux, BSD, Windows, o lo que quiera que usemos, podemos usar también nuestra lógica y capacidad de razonar

      O sea en resumen, los que comentamos, leemos y usamos GNU/Linux en este blog no razonamos. ¿Eso es lo que quieres decir? De todos modos te lo diré desde mi experiencia personal, y mi razonamiento (sea lógico o no):

      Systemd es una mierda pinchada en un palo. He leído que hay otros Init que inician mucho más rápido y no por ello tiene que controlar DNS, RED, CRON y todo lo que Systemd quiere controlar. A lo mejor para un usuario final, que solo le importa encender la computadora, abrir un navegador y enviar correos electrónicos, le da lo mismo si usa Systemd o Systemx, pero para los que administramos servidores es un grano en el culo. Y te hago la misma pregunta que siempre hago ¿qué sucederá si Systemd se ve comprometido y se va a la mierda? ¿Nos quedamos sin RED, sin CRON, si DNS, sin Init y todo lo demás que hace? Ahí te lo dejo.

      Y ojo, todo esto te lo digo sin acritud. Dicho esto, bienvenido por estos lares.

      1.    Dah65 dijo

        Gracias por la bienvenida.

        Respondiendo sin acritud, aclaro que ni desarrollo systemd ni me pagan por promocionarlo. Y que no me afecta para nada el que otras personas lo usen o no, es su decisión.

        Pero lo que veo con este asunto parece, a veces, una histeria, y leo opiniones de personas que sin haber estudiado el código ni haberlo usado lo tachan como de basura, imposición, traición, y no sé cuántas cosas más. Me recuerda una situación que viví hace unos días, cuando una persona que reconoció que nunca había instalado Windows ni sabía particionar un disco duro empezó a decir que Linux era muy difícil… sin haberlo probado siquiera, y además teniendo Android en su smartphone.

        ¿Has comparado systemd con sysvinit, con upstart y con openrc? Estupendo, puedes tomar una decisión fundamentada en tu propia experiencia. Es lo mejor, porque además sabes que la distro que funciona en un equipo puede ir de pena en otro diferente, y por eso quienes tenemos algo de experiencia en GNU/Linux decimos que la mejor distro es aquella con la que el usuario se siente a gusto.

        1- «O sea, que los lectores de este blog, por ser solo lectores, no tienen la capacidad de percatarse si algo es bueno o no, porque debemos guiarnos por el buen juicio, conocimiento y experiencia de empaquetadores y desarrolladores»

        Soy lector de este blog desde hace bastante tiempo (verás comentarios míos en noticias antiguas), así que estoy incluido en el pack. Y la respuesta es que no: ser lector de este o cualquier blog no me capacita (al menos a mí), para juzgar lo bueno o malo de un software que no conozco. Puedo leer lo que dicen otros, y en este caso hay posturas tanto a favor como en contra de systemd; de hecho, cada vez que se toca el tema en Phoronix hay mucho debate, pero incluso allí los comentarios argumentados son escasos. Me refiero a argumentos como «cuando systemd llama al proceso X se produce un bucle infinito que deja el sistema inusable».

        Y la verdad es que al usar una distro u otra diferente, te estás dejando guiar por el juicio, conocimiento y experiencia de empaquetadores y desarrolladores. El uso de cualquier SO o programa implica en parte confiar en el juicio y experiencia de otras personas; por ejemplo, con Linux aceptas la decisión de usar un kernel monolítico en vez de usar un microkernel como Hurd. Esa decisión fue de Linus Torvalds, y tú la aceptas al usar su núcleo.

        2- «Es cierto, es Software Libre, y si apareciera algo raro las super personas de las que hablabas antes y de las que debemos fiarnos se podrán percatar y anunciarlo, o quizás no, porque a lo mejor como son personas se sienten tentados a callarse a cambio de algo.»

        Bien, puestos a sospechar, ¿por qué fiarse de Linus Torvalds y de Richard Stallman y el proyecto GNU? No he mirado el código de sus programas, así que a lo mejor me están engañando.

        3 – «Y te hago la misma pregunta que siempre hago ¿qué sucederá si Systemd se ve comprometido y se va a la mierda? ¿Nos quedamos sin RED, sin CRON, si DNS, sin Init y todo lo demás que hace? Ahí te lo dejo.»

        ¿Qué pasa si OpenRC se ve comprometido de alguna forma? ¿O Upstart? ¿O el kernel? A mí me ha pasado, tras una actualización «normal» en Debian Testing, quedarme sin grub, no podía entrar ni a Debian ni a Windows, y en aquella época mi desconocimiento hizo que sólo me quedara la alternativa de reinstalar.

        4- «O sea en resumen, los que comentamos, leemos y usamos GNU/Linux en este blog no razonamos. ¿Eso es lo que quieres decir?»

        No, no quiero decir eso; no pretendo generalizar desde una situación particular, concreta, hasta la totalidad del comportamiento de una, o mil, personas. Pero sí creo que en el caso de systemd se habla muchas veces sin hacer un análisis objetivo y sereno; también pasó con Wayland – Mir, haciéndose muchas afirmaciones infundadas, tanto contra Wayland como contra Canonical.

        Además, te repito que leo y comento en este blog (como en otros), y que uso GNU/Linux.

        Y también repito lo que dije antes: usemos el cerebro, analicemos lo que oímos y leemos, tomar diferentes perspectivas para intentar rebatir tanto A como no-A, y si nos es posible, obtengamos nuestra propia experiencia para basar nuestras conclusiones en hechos. Y después, usemos lo que nos parezca adecuado.

      2.    waco dijo

        umm.. bueno eso de ser comprometido es una hipótesis es como todo.. mi pregunta ya ha pasado?.. acaso no se consiguen bugs en todos los software y se corrigen si sale x bugs en systemd lo corrigen y ya como cualquier programa puede tener sus bugs.. el problema no es que pueda fallar es si quieres que haga o controle lo que esta haciendo mas no por hipotesis de que pueda fallar cualquier cosa puede fallar en un momento… no soy fan de systemd para nada solo es mi opinión.

        1.    elav dijo

          Un bug puede ocurrir en un ordenador de un usuario y puede que no pase nada, pero en un servidor la cosa es muy, muy diferente.

      3.    Yukiteru dijo

        @waco ciertamente si se consiguen bugs en un software el deber corregirlos. El problema es que systemd tiene muchos errores viejos (algunos datan de 2010 y son graves) y todavía hoy no tienen arreglo, o simplemente se le ha restado importancia, o simplemente Lennart los marca como CLOSED o WONTFIX.

    2.    waco dijo

      muy acertado tu comentario! no podemos todos caerle a systemd porque esta de moda y se ha creado como una campaña de desprestigio a este.. todo cambio tiene un rechazo.

    3.    Yukiteru dijo

      Respondo a tus argumentos:

      1.- Los usuarios serios e indagadores, y los desarrolladores saben por igual las ventajas y desventajas de adoptar systemd en cualquier entorno de desarrollo y trabajo, las debilidades y fortalezas de systemd no cambian por tener una u otra perspectiva.

      2.- Ciertamente systemd es software libre y puede ser auditado. El problema no es que tenga escondido puertas traseras, el problema es que hace cosas que un init no debería hacer (control de red, dns, consolas TTY, etc), que tiene un monton de servicios que se suporponen a otros, que hace cosas de forma completamente distinta a como se espera que se realicen, que rompe reglas del propio kernel de Linux (coredump), que a muchos de sus desarrolladores les importa muy poco solucionar problemas estructurales que systemd tiene (coredump y debug son de los mas graves aún no solucionados).

      3.- Una cosa es bajarse un binario que resulta ser un programa cuya CONFIGURACION y LOGS aun está en texto plano, y otra cosa es bajarse un binario cuya CONFIGURACION y demas información se almacena en binario y solo es accesible por medio de herramientas especificas, aqui es donde cambia la cosa. Un log binario no ofrece seguridad (si quieren realmente seguridad cifren la partición con AES-256), es solo una caja negra de la que no sabes nada de lo que está pasando y se presta a muchas cosas, por ejemplo: Imagina que tienes un troyano que explota alguna vulnerabilidad de systemd y por medio de ella obtiene acceso total al sistema incluyendo al servicio de logs y escalado de privilegios. ¿No es eso un problema grave? ¿Acaso los logs binarios manejados directamente por systemd no se volverían en tu contra al ser inauditables sin entrar en el punto de que ya hayan sido modificados sin saberlo? Allí está el punto y la diferencia entre un programa y un archivo de configuración/logs/dumps en binario.

      4.- El kernel es una pieza de software pensada en ese sentido, está pensada desde un principio a controlar todo lo que hay en tu PC, un init no. Un init se dedica solo a hacer que tu sistema levante el kernel y sea usable, porque es lo primero que se inicia y lo ultimo que se termina. Por eso se llama init (initialization) porque solo inicia el sistema y no hace nada más, y la razón para que sea así es muy sencilla, el init debe ser la pieza de software más estable y perfecta posible, para evitar que por algún motivo esta termine quebrando todo el sistema, se trata de estabilidad y seguridad. Xorg, es otra voz, hace muchas cosas es verdad, pero nada tan arriesgado como para dejarte con un sistema completamente inutilizable, y además su configuración aún se hace en archivo de texto plano sencillos.

      5.- Ciertamente las distros no están obligadas a ofrecer la libertad en un amplio sentido, y debido a ello es que se presenta la diatriba actual. Pero, somos usuarios y comunidad, y muchos simplemente no estamos de acuerdo con la implementación de este sistema, es por ello que hacemos llegar nuestra voz, si la escuchan o no, es cuestión de quienes desarrollan la distro, y su decisión tendrá impacto en quienes decidan usar o no su distro, y eso, claramente puede llevar al quiebre a varias distros dependiendo de como se den las cosas y un ejemplo ahora es Debian y su fork Devuan.

      6.- La noticia de BSD es por lo que paso en OpenSSH y en la pila IP de OpenBSD, una puerta trasera que por cierto afectaba no solo a BSD sino tambien a Linux (en el caso de OpenSSH), y que fue reparada. La situación se le achaca a BSD, porque es BSD (Theo de Raadt en OpenBSD) quienes se encargan del desarrollo de esta herramienta (OpenSSH) y la situación se presento porque ciertos desarrolladores que ya no están activos en el proyecto plantaron la puerta trasera. La situación se solvento y se declararon las medidas pertinenetes a tomar en caso de que esta situación pudiese estar afectando a quienes hicieran uso del software. Ahora bien: ¿Está situación se puede presentar en systemd? La respuesta es sencilla, y el resultado catastrofico, puesto que systemd maneja escalado de priveligios entre muchas otras cosas, una puerta trasera en systemd significa acceso total al sistema, cosa que no ocurria con las backdoors mencionadas en BSD.

  17.   Oscar dijo

    Devuan el fork de Debian sin systemd ya tiene página web. Parece que el proyecto si va y muy enserio . https://devuan.org/

  18.   Aaditya Bagga dijo

    ISOs actualizados y algunas nuevas subidas.
    https://forum.manjaro.org/index.php?board=50.0

  19.   keos dijo

    El instalador no es muy claro, no puedo seguir sus pasos, sobre todo en la parte de las particiones, no se porque insisten en estas cosas tan confusas.

  20.   Manuel R dijo

    Hay algo que me llama la atención de las netinstall con Openrc, en alguna parte de la instalación sigo viendo el mensaje de que está configurando systemd, ¿en serio estarán libres de systemd o de su uso?

    1.    keos dijo

      Hola Manuel, tambien yo observe lo mismo durante la instalacion debe ser cosa del instalador pues lo que no cabe dudas es que systemd no esta instalado, confirmas en la terminal asi: pacman -Qs openrc

      Saludos

      1.    Manuel R dijo

        Hola keos, primero que nada me disculpo por no haber contestado antes. Te agradezco tu respuesta, me alegra saber que Manjaro ofrezca esta opción; en cuanto finalice el soporte de Ubuntu Precise (o quizá antes) la instalaré. Saludos.

  21.   Anonimo dijo

    Buen Post

    Voy a esperar en Manjaro con Systemd mientras la versión con OpenRC madura un poco mas, quiero salir de systemd… (Me la suda)