Recién me entero que la bronca de muchos usuarios ha llevado a la creación de uselessd, un nuevo demonio init basado en systemd que intenta despojarlo de la «innecesaria cantidad de funcionalidades que éste incorpora». Es interesante la elección del nombre que, en inglés, puede leerse como «el inservible systemd» o «usemos menos systemd».
En sus primeras etapas de desarrollo, Uselessd no es más que un fork de systemd reducido a su mínima expresión. En palabras de sus desarrolladores, es «un demonio init (initd) básico, un supervisor de procesos y un sistema de dependencias transaccional, que minimiza la intrusión y el aislacionismo». Entre las funcionalidades que fueron eliminadas se encuentran: journald, libudev, udevd y ciertos tipos de unidades consideradas superfluas, a saber, dispositivos, temporizadores, swaps, mounts y automounts.
Como si esto fuera poco, ya han añadido soporte para compilarlo bajo MUSL y uClibc, como alternativas al uso de glibc. Uselessd también está en las primeras etapas de ser portado a FreeBSD, mientras que systemd sólo tiene compatibilidad para Linux.
En fin, no está claro cómo van a terminar las «guerras de init» y si uselessd terminará generando un reemplazo realmente funcional, pero aquellos que deseen aprender más sobre este proyecto pueden visitar su sitio web oficial.
Sabía que había alguien que no sólo se quedaría en echarle pestes a SystemD.
Ahora, a apoyarlo, nomás.
Que diferencia hay entre systemd….CLI…..GUI ?.
systemd maneja el arranque del sistema y las aplicaciones.
Cli viene de interfaz de línea de comandos, osea los comandos que usas para manejar los programas
Y GUI es lo referente a la interfaz gráfica.
Podías buscarlo en internet te comento
Suban un tuto para noobs
No entiendo, como simpre user, esta campaña anti-systemd
A mi me ha sido fácil, como simple user, adaptarme a su uso a la hora de activar o desactivar servicios, ya me lo se de memoria cosa que con lo que había antes no me había pasado.
No tengo nada en contra de syetmd y veo absurdo su menosprecio. Hablando como end user.
Hacer un fork para quitarle funciones me parece una tontería de las tontas. La gente se aburre.
Yo comprendo a la gente que recién llega a GNU/Linux y no logra ver las diferencias fundamentales entre lo que siempre fue y lo que intentan colarnos con systemd.
Linux es un clon de Unix y Unix fue creado con una cosa en mente, hacer una cosa a la vez y hacerla bien, esto no fue un capricho, fue debido al fracaso rotundo de Multics que intento hacer muchas cosas y las hacía mal o no podía controlarlas como debió ser.
Entonces no solo contradijeron el nombre de Multics usando Unix (algo como muchos contra pocos o únicos) sino que crearon el concepto de tuberías y de concatenación de procesos que da una flexibilidad imposible de lograr por otros medios…eso fue lo que dio el éxito rotundo de Unix.
Ahora con systemd nos quieren venir con el cuento de Multics de nuevo….no gente, rechazar la base de Unix en Linux es volver a Multics donde sabemos (la historia lo ha demostrado ya varias veces) que tenemos el fracaso asegurado.
Si recién han llegado a GNU/Linux por favor lean un poco de historia y aprendan porque las cosas se las hacen así en Unix y GNU/Linux.
Bien dicho , y a los que dicen que en el mundo actual las cosas ya no funcionan asi , les pongo un ejemplo ,un navegador , una de las piezas de software mas complejas que existen , sin embargo , estan construidos por herramientas que , cada una , hace una tarea especifica y pueden funcionar fuera del conjunto . Un motor javascript , uno HTML , el SSL , el http …
Que no haya funcioando en el pasado no significa que no vaya a funcionar ahora. Ya pasaron como 20 años de eso, tal vez sea hora de cambiar, ¿no?
Ya quisiera ser yo un recién llegado a Linux, llevo en esto desde el 2004 y si, se lo que es Linux y systemd, y aún así veo a systemd más cómodo.
Este comentario que dejaré a continuación es de un compañero, no es mío, pero es un comentario que también suscribo.
[…]El rechazo a systemd lo achaco a «neofobia», miedo a lo nuevo. Desactivar un script de SysVinit implicaba conocer bien el sistema de runlevels y las dependencias que pudiera haber en /etc/init.d… y en cada distribución lo hacían de una forma diferente. Con systemd basta un systemctl disable y ya.
Los que se quejan de que systemd viola la filosofía UNIX es que no se han enterado de lo que es la filosofía UNIX ni de cómo funciona systemd. Por esa misma regla de tres, el núcleo Linux sería lo menos UNIX del mundo. Lo que pasa es que systemd le cambia la función a PID 1, como en su momento expliqué en una entrada: es un demonio de sistema, no simplemente una cosa que va ejecutando scripts.
En lo único que reconozco que systemd no sigue la filosofía UNIX es en lo de usar logs binarios, pero está justificado para acelerar la consulta mediante indización.[…]
@Yoyo: Lo que pasa es que como eres de lento aprendizaje cualquiera diría que eres un n00b, jajajajaja.
@yoyo:
Muy buena cita. Además, el chiste radica en que SystemD tiene una falencia en los bugs, aunque tiene su propia forma de visualizar dichos «logs» blobbeados.
Lo que me interesa de dicho fork es cómo van a adaptar la velocidad de SystemD a otros entornos UNIX como BSD.
GNU’s Not Unix, como dijo ricardito hombrecaseta
El comentario as coherente de los últimos tiempos sobre porque systemd es basura. Multics, windows…. Les suena la falla total por un componente?.
Eso le pasaría a systemd el cual es atravesado enteramente por dbus, si algunos de sus demonios falla seria necesario reiniciar el sistema o todo se podría colgar. Ya me ha pasado en centos 7 que un demonio o unidad queda como dead y no se reinicia por mas restart que le hagas. Me rompe mucho la etc que end users opinen un saber y defiendan algo que ni saben porque se ataca. Como decía mi abuelita, si no sabes no opines, mejor callate y pregunta sin cuestionar, cuando sepas, ahí cuestioná.
Mucho ubunuser opinando, el gran apoyo a systemd en gran medida lo trajo, paradojicamente una de las empresas que lo crítica, canónical, inundando el mundo linux de usuarios que no ven mas alla de su ls -l.
Este muchacho de uselessd es una sola persona la misma que posee el dominio del boicot así que a menos que otros dev lo apoyen le veo poco futuro. Espero que dev de distros mas geek le ayuden como los de arch, gentoo o Slackware.
.. no me considero «usuario avanzado» no me gustan los titulos de nobleza, tampoco soy sysadmin, pero he pasado por todas esas distros que mencionan (Slack (muy poquito), Arch un par de años, y Gentoo si varios años (tambien su fork Funtoo)) entiendo su punto de vista como sysadmins, per pregunto, y si el kernel falla?, se va todo al garete, entonces digo, porque no se quejan del kernel?, porque no usan Minix, o algun tipo de SO con «reincarnation server» ?, a veces me parece que la bronca viene mas por la actitud de Lennart (que no me parece apropiada), pero permitanme una generalizacion, ustedes los sysadmins (y obvio que lo van a hacer) defienden su trabajo, y nos dejan «tirados» a los usuarios del desktop, solo les importa que su server ande «bien», por mas que el sysv use un «paradigma de inicio» bastante arcaico (el tema del target y wanted de systemd esta muy bien…), digo yo su sever andará perfecto con sysv, pero mientras tanto los usuarios del desktop usamos un dbus en espacio de usuario…… que gran idea………
repecto a éste fork, como ya dijeron en otros lados, hasta ahora solo veo un nombre «bonito» y un systemd capado, que por cierto, BIENVENIDOS a Systemd, Systemd haters… veo muchos que se quejan de systemd, pero lo quieren… porque?, acaso OpenRC no hace las cosas bien?, o Upstart?, o lo que sea? …. Dios mio… hasta ahora vi 2 tipos de haters, los sysadmins con fundamentos, y los que describo en éste párrafo que más bien parecen «posers» ….
Volviendo al tema de los sysadmins, ustedes ni siquiera necesitan interfaz gráfica, no se porque se quejan de systemd (tranquilamente podrian argumentar que Gnome Shell requeire Systemd (cosa que no es del todo cierto porque Funtoo lo tiene funcionando con OpenRC)) pero NO NECESITAN GUI entonces se deberían quejar con sus respectivas distros, Centos y Debian. En particular Centos, si tantos problemas trae Systemd no debería haber migrado (aunque era obvio que iba a migrar estando bajo la mano de RedHat) y Debian, lamento decirles, jodanse, eso lo decidio el equipo de Debian, en su afán de ser «la distro universal»… pero repito usen FreeBSD o una «Distro para Servidores» que entienda lo «malo» que es Systemd y use sysvinit y punto..
Quizás x11tete11x el problema no es que falle el Kernel, sino que falle y uno pueda saber que ocasionó el fallo. Es lo que por lo menos a mi me jode de SystemD..
@elav tienes razón en eso, con systemd mucho de los errores del sistema quedan entre los tonos de gris y negro, y todo porque journald parece una «caja mágica» que te convierte los logs en un archivo binario poco fiable, y cuando hablo de fiabilidad me refiero a la locura comprobada (ya hay un bugreport) de que si un log de journald se daña (cosa que puede ocurrir por muchas razones) este simplemente se descarta y se comienza uno nuevo, quedando ese log prácticamente ilegible en muchas ocasiones, un bug relatado en freedesktop y del cual el mismo Poettering ni bolas le ha parado. Ni hablar del temita del debug, pero bueno ya eso es conocido (si no saben de que hablo, les recuerdo que la opción debug de la línea del kernel y su «subsecuente arreglo» fue la razón por la que sacaron a Kay de tener permisos para commits en el kernel ).
@x11tete11x no comparemos el desarrollo del kernel con el desarrollo de systemd. systemd es una pieza de software que aún está en pañales, si lo comparamos con el kernel, además yo no veo a Linus aprobando parches experimentales a diestra y siniestra, mientras cambia a su vez, las ABIs y APIs del kernel.
@joakoej Multics fracaso por muchas razones, entre ellas: tener una mayor complejidad en cuanto a código, ser lento en muchas tareas comunes con respecto a otros sistemas ya desarrollados y resultar excesivamente caro para lo que normalmente se manejaba en proyectos de igual envergadura.
Es un fork para que no tenga todas las funciones, un sistema de init no puede actuar asi , mira sysvinit . sysvinit , aunque anticuado , solo tenia una tarea basica , y era iniciar el OS , de lo demas que se encarguen otros (syslog y no journald , openrc y no systemctl , consolekit y no logind … ) dado que sysvinit esta anticuado y que cada vez mas muchos proyectos dependen en parted de systemd , esta iniciativa me parece genial . Yo prefiero syslog a journald , pero logind (ademas de ser un requisito para gnome) gana por goleada a consolekit . Ademas , este fork deberia ser mas seguro , portable , y con un poco de suerte ,compatible con ulibc .
Compa, yo tampoco tenía nada en contra de Systemd hasta ayer. Por algún motivo mi Laptop está demorando mucho en apagar, y lo único que me sale es (interminablemente):
[ 9064.808526] systemd-journald[150]: Failed to write entry (13 items, 351 bytes), ignoring: Bad addressEs como un puto error en Windows, que no te enteras de nada.
Y sin logs es bastante complicado poder rastrear la base de los problemas. A mi también me está molestando systemd por ese tipo de cosas. Quizás sea que no conozca muy bien el software pero lo mínimo que pido es claridad en los logs.
Y una vez mas los [Inserte su estereotipo favorito aquí] tenían razón. 🙂
Pero ojo, no mencionemos a windows, quizás seamos unos enfermos de esos que se contagiaron de la nueva patología que ya propuso el Sr. Linus para ser agregada al CIE, odioawindowsitis, creo que se llama. 🙂
@Staff y cual es la equivocación de Elav? Desde windows 8 en adelante se ocultaron muchas cosas (chkdsk al arranque, información técnica de BSOD, msconfig «decorativo»). Al parecer, todo va en esa dirección. Espero que no lleguemos, a las «mac triste» y su correlativo de windows, y ninguna información al usuario.
@Mario
Nunca dije que elav este equivocado.
Notece el emoticon al final de mis dos párrafos.
Ay!! @Staff que no pones una… hago referencia a Windows por su típico cartel al estilo:
Windows ha detectado un problema. El código del problema es 0x1123df2982, contacte con el Centro de Soporte para más información…
en fin, para el /dev/null
Elav, imaginate un error así en un servidor en producción. No es admisible. Sólo un sysadmin entiende por qué es tan malo systemd. No es por menospreciar a nadie, pero hace falta entender cómo funciona un procesador, un sistema operativo, un kernel, un proceso, etc. para comprender los problemas a bajo nivel que acarrea systemd. Va más allá de la filosofía UNIX, estamos discutiendo la estabilidad de un sistema.
Los sysadmins están cómodos con sus Debian 6/7 y CentOS 5/6 libres de systemd, pero cuando se termine el soporte de Debian 7 y CentOS 6, recién ahi va a comenzar el verdadero revuelo (si es que no surge una alternativa viable como la que se describe en este artículo).
Incluso imagínense para un sysadmin, ponerse a traducir y testear scripts que funcionaron toda la vida con el comando «service» a systemd.
Y el error que mostrás descubre otra de las aristas de systemd, vos lo dijiste muy claro, ese nivel de ocultamiento de información es «muy Windows».
Saludos.
Mirá no estoy seguro de esto, pero creo que exageras un poco, yo he tenido varios errores en Gnu/Linux que no se explicaban por sí sólos y dudo que todos se debieran a systemd. ¿Acaso me equivoco?
@Emiliano Puede que tengás razón. De todas maneras, si bien no soy un experto, me parece que es un poco sensacionalista todo esto. Me parece a mi que es cuestión de costumbre más que nada y si el administrador del sistema quiere, de seguro aprende como funciona systemd, incluso hasta le parezca más fácil, digo si lo que hace es centralizar todo, de seguro en algunos o varios aspectos las cosas sean más rápidas.
Por lo que vi tiene varias ventajas en ese aspecto, como el tiempo de arranque, no requiere que algunos programas se inicien antes que otros para arrancar correctamente, no hay que modificar un archivo rc.conf ni nada parecido, ya que se maneja todo de manera más automática, puede ejecutar aplicaciones incluso si algunas dependencias no están cumplidas, etc. Estas cosas son algunas de las ventajas que vi en internet, corregime si me equivoco
Ahora, de seguro agunas desventajas va a tener, como todo, pero estaría bueno, si sabés como funciona y tenés tiempo, que lo aclarés, te lo pido como un favor para saber en que se basa tu opinión. Por lo que vi, puede que una desventaja sea que va a haber que parchear varios programas para que funcionen correctamente con systemd, pero no sé si eso afecta de alguna forma a otros init systems.
@Emiliano Ah me equivoque el archivo no era rc.conf, eran /etc/inittab y /etc/init.d/rc
Parece que hay una versión de ese archivo para systemd, pero centralizada en un único archivo /etc/systemd, el cual se maneja con el programa sytemctl.
Creo que entiendo porque decís que un administrador de sistemas podría no gustarle, ya que parece que con init tenía más control y hacía la cosas sólo cuando él lo indicaba.
En cambio, systemd puede que sea un poco más intrusivo, pero me parece también, y reitero, que es cuestión de aprender como funciona y de seguro que alguien con la capacidad de ser administrador puede conseguirlo.
Pues bien, intenté apagar Debian Jessie con los comandos de SysVinit de toda la vida, pero había ignorado que usaba SystemD, por lo que tuve que valerme de la guía de Arch para saber manejar un poco mejor el SystemD y el systemctl.
En mi caso, el SystemD me apaga bastante rápido mi PC de escriorio cuando uso de forma intensiva el Chromium/Chrome/Opera Blink.
@eliotime3000 aca tenes una buena wiki de systemd para debian con bastante info http://www.esdebian.org/wiki/systemd claro que la wiki de arch es muy buena pero systemd en debian no esta implementado de la misma forma que en arch así que hay muchos comandos, soluciones, etc que no te van a funcionar. cada distro tiene sus cositas 😉
LOL
La carita feliz no fue suficiente, quizás deba usar comillas, con eso de que ahora las comillas lo aclaran tooodo 🙂 //Sarcasmo (a ver si con esa etiqueta ya se entiende).
Se nota que tampoco leíste mi respuesta a mario.
Mis dos párrafos eran sarcásticos.
El primero, tratando de hacer notar la ironía de que cuando la gente nos avisa de las deficiencias de un proyecto, los tachamos de locos y mil otras cosas si es que no somos simpatizantes de su ideología, pero cuando ya experimentamos los problemas en carne propia no nos queda mas que tragarnos las palabras.
Y el segundo, que EN EFECTO ES COMO WINDOWS, pero que muchos no lo aceptan y dicen que es por que se odia a Windows y se usa indiscriminadamente para atacar a todo lo que no huela a la FSF.
Pero en fin, el criterio es algo difícil de encontrarse en este mundillo.
@Staff, hombre para usar sarcasmo en una forma de comunicación tan fría como esta, hay que currárselo un poco más 😛
@elav:
Vengo aquí, dejo este link a mi comentario, y me voy corriendo. :v
He notado lo mismo pero al iniciar…. desde hace un par de días el computador se demora una eternidad para arrancar y primera en la linea dice algo relacionado con Systemd. Que es lo que está pasando?
Así es elav, as como windows mismo. ESE error lo he tenido, borra todo el file del journal y listo. Dentro de poco tendremos que reinstalar jajaja.
Jajaja, pero si instalé Antergos no hace ni un mes jajaja
Imaginense cómo me siento con un puto Arch que tarda cerca de 30 o hasta 40 segundos en arrancar más que en Windows, si, instalo mucha mierda en el yaourt, pero no pongo nada de inicio (es lo que más procuro) lo más descabellado que tengo es el servicio de CUPS y creo que ssh para terminales remotas. Desgraciadamente ya después de un año sin formatear creo que voy a reconsiderar la idea de hacerlo de nuevo 🙁
Desgraciadamente he notado que en los últimos 2 años nos acercamos más a las distros-estilo-Windows que intentan ocultar información, automatizar envíos de informes de error, automatizar operaciones en las que el usuario debería de intervenir y hasta tener el control.
Como extraño las distros de hace 3 o 4 años con el SysVinit, era divertido farolear con un «init 0» en la escuela XD. Además aunque no estaba tan homologado todo, el control fue extremadamente del usuario y no del sistema. Si, hay muchas comodidades, pero a costa de que…
Ya se veía venir. Yo no tengo nada contra systemd, como un usuario común y corriente me facilita mucho las cosas y las ordenes para activar o desactivar servicios son bastante simples. Habrá que ver en que acaba esta guerra de init.
SystemD es como una anillo para controlarlos a todos. Puede ser un caballo de troya de la NSA. SystemD puede comprometer nuestra privacidad-seguridad, ya que se mete en muchos servicios. Y peor aun, si mi distro menejaba muy bien la energía, que va a pasar ahora? No podré cambiarme a otro lado.
Tanto como un troyano no, si controla muchas cosas, pero sigue siendo Software Libre, puedes ver que es lo que hace el código con tu información.
Entonces, si SystemD tiene problemas (Y si que los tiene) hay que solucionarlos y no solo tirar todo a la basura, ya que también tiene muchas cosas buenas y necesarias.
Una cosa es cierta, sólo sé que no sé nada. Soy un novato, pero después de leer muchas opiniones de gente que sabe infinitamente más que yo, contrapuestas, o neutrales, la conclusión a la que puedo llegar es a sospechar y nada me hace que no deje de hacerlo. Nada me hace confiar, por ahora.
Uso openSUSE porque me encanta y pordrían estar colandomela… De echo podrían estar colandonosla a todos por todos lados… Y es hay donde aparece Stallman, el vela por nuestra privacidad por mucho que le pese a muchos.
No había metido sus zarpas la NSA en RedHat????
Que exagerado, ¿por qué iba a comprometer tu privacidad?
Para violar la seguridad y que nadie se entere, se necesita empeorar los logs del sistema, complicarlo, hacerlo binario, no hacer caso a los que reportan mal funcionamientos, no permitir que coexistan syslog-ng y journald al mismo tiempo.
Si a esto le sumamos manejo de red automático por dhcp, tenemos el terreno sembrado para las intromisiones sin dejar rastro «al menor bug no descubierto aún», realmente el que no ve esto es porque es ciego sordo y mudo….hace mas de 2000 años uno dijo….por sus frutos los conocereis, y pues bien yo ya veo los frutos y están al caer de maduros.
Lo que se le achaca a systemd es no hacer solo la tarea que le corresponde, se ha entrometido en todo para pervertir la seguridad y hacer obsoletas herramientas que hacen bien sus tareas no permitiendo la coexistencia de ambas a la vez.
Como dije antes, que exagerado.
Te creería siempre y cuando SystemD fuera programado por Microsoft, Apple y/u otra compañía que no haya compartido el código fuente. Por fortuna, no es así, y agradece que al menos hay alguien que no se ha quedado en sólo las pataletas.
Por otro lado, cuando le preguntaron a Linus Trovals acerca del sistema de algoritmo de SELinux, respondió con una solución bastante sencilla (y eso sin mencionar que el padre de Linus haya confesado que la NSA intentó meter su mano en el desarrollo del kernel, aunque sólo quedó con lanzar con todo y código fuente el dichoso componente).
Date cuenta que muchas veces es la ignorancia es la principal lacra del ser humano.
Que bien , acabo de ganar 10 euros en una apuesta 😛 . Tan predecible como siempre … Me parece bien , no me gusta mucho systemd por su filosofia de proyecto y su carencia total de comentarios en el codigo (a lo OpenSSL) . Pero reconozco que es tecnicamente superior . Me pregunto si podra ser un remplazo de sysvinit para Openrc . En cuyo caso migrare .
Ademas , en el software libre , por alguna razón , es necesario que haya dos implementaciones de lo mismo , el porque , competencia (Libreoffice , Openoffice ) y seguridad (OpenSSL).
hay una cosa que no entiendo, si el diseño de systemd se basa en cgroups el cual es una característica exclusiva de linux.
Para portar el uso del fork de systemd a FreeBSD Hurd, etc, o garegan en dichos kernels los cgroups o elimian del diseño de dicho fork a cgroups.
pero si le quitan cgroups al fork de systemd, es difícil pensar que Uselessd sea una verdadera alternativa de systemd.
igualmente considero muy positiva esta iniciativa porque la competencia siempre es buena ya que los obliga a esforzarse para ser mejores y el resultado nos beneficia a los usuarios.
* garegan = agregan
pues simplemente no usarían cgroups o harian de cgroups algo opcional. en teoria noe s tan dificil. loq ue tienes que hacer es simplemente diseñar y escribir la manera de soportar otros metodos de control de procesos que los hay en todos los SO actuales. en la practica esto es tedioso y costoso porque significa que si por ejemplo tienes 8 horas para trabajar en el programa, en lgar de usar las 8 horas para mejorar y pulir lo que una sola opción te da, debes de dividir ese tiempo en 6 (mantener los 3 sistemas + 3 maneras de intercambiarse entre ellos). de ese modo el mantenimiento y desarrollo se hace mucho mas pesado y lento. osea, o soportas varios regular o soportas uno bien.
Y sin contar que BSD tiene muy poca demanda por parte de los sysadmins, e incluso, el mismo UNIX se lo ve con los mismos ojos que con Windows XP.
el tema es que cgroups: «se utilizan para realizar un seguimiento de los procesos de servicio, en lugar de PIDs. Esto significa que los demonios no pueden “escapar” de systemd aunque estén doblemente-bifurcados. » http://es.wikipedia.org/wiki/Systemd
si bien este es uno de los puntos que le critican a systemd porque dicen que se inicia en pid 0 y que esto es un riesgo porque si se rompe systemd se rompe el sistema, lo cual como dijo linus es una tontería ya que si se rompe el kernel u otros procesos también se rompe el sistema. lo cierto es que si el fork no usa cgroups usa pids y no va a tener un control total de los demonios. ya con eso nunca va a ser mejor que systemd en linux
Hay varios forks relacionados, pero este es el primero a systemd en si mísmo. En Gentoo para udev (que se fusionó con el mencionado), existe libgudev y libeudev. Sino queda extraño andar con OpenRC, y ver en los procesos «systemd/udev» como pasa en ciertas instalaciones actuales. En lo personal, no me agrada esa idea de incorporar un cliente DHCP (espero que no lo hayan hecho aún). Creo que hay software probado y de excelencia en esa tarea, no hay necesidad de reinventar la rueda.
corrijo, gudev también es systemd, en las últimas versiones.
Te respondo al comentario sobre el DHCP en systemd.
systemd no solo tiene un DHCP built-in (integrado como parte de networkd), sino que también tiene un DNS resolver y cache DNS, además de funcionalidades heredadas de Avahi (otro monstruo creado por Poettering).
Hoy cené patatas y filete, no me ha gustado, crearé un fork. Y así para todo.
Is uselessd actually an elaborate false flag operation by Red Hat to discredit their opponents and install a New World Order?
…Fuck.
Bien cubierto de espaldas este proyecto
TRADUCCIÓN:
me estan diciendo que
1) están creando un systemd amputado sin ninguna de sus herramientas y con ninguna de las ventajas que la estandarizan trae consigo a la par que no resuelve ninguno de los problemas que systemd esta resolviendo ni resuelve los viejos problemas tradicionales. si claro. denme 3
2) me están diciendo que es un systemd sin el «bloat» pero resulta que systemd es modular y puedes usar systemd sin ninguno de sus demonios secundarios. por lo tanto eso de quitarle el bloat es igual nada en la practica (salvoq ue no vana conservar muchas de las mejores herramientas de systemd como jounals)? ok. perfecto. denme 20 ahorita mismo.
3) me están diciendo que este fork que no resuelve ningún problema, que no solventa el problema de la fragemtnación en el bajo nivel, que no ofrece ventajas técnicas de ningún tipo sino que antes nos hace retroceder 5 años en el manejo de servicios en linux. compita con la unica esperanza de estandarización? . ok. lo amo. denme 2161816814168 distros con esto. plis. ahora!!
para quien no entendió. es sarcasmo 🙂
y por esto es que linux nunca triunfará en el escritorio, cuando por fin se empiezan a dar los pazos para crear una infraestructura para hacer posible un escritorio funcional para todo publico. salen los mamertos con sus mamadas. ok que hagan lo que quieran, tienen el derecho, pero la verdad, que no esperen que los tomen muy en cerio.
http://hackingthesystem4fun.blogspot.mx/2014/09/linux-no-triunfa-en-el-escritorio.html
http://linuxito.com/gnu-linux/nivel-alto/431-por-que-systemd-es-una-mierda
A decir verdad, el chiste es que SystemD me sirve de mucho, incluso hace que el apagado de la PC sea rapidísimo cuando tienes bastante tiempo usando Chrome en particiones Ext4. En el caso que pruebe Debian Jessie con XFS y SystemD -y encima, me de resultados mejores que con SysVinit- me arrodillaré ante ella.
Lo más gracioso es que intentan hacer un SystemD con la facultad de añadirle las características de SysVinit, aunque dicha labor sea completamente un reto (como el fork de Theo de Raadt de OpenSSL).
Este fork resuelve el problema de quitarle las riendas a Lennart y su papá RedHat para intentar dárselo a desarrolladores independientes para
que eliminen la maldad de systemd de entrometerse con cosas que no son ni deben ser nunca parte del sistema de inicio. ¿te quedo claro?
Ahora, si para algunos eso les parece poco motivo…eso no lo puede resolver nadie, son solo opiniones y puntos de vistas personales.
pero es que systemd no es un mero sistema de inicio, systemd son mas de 70 binarios distintos de los cuales solo 1 es pid 1 y este solo se encarga de 1 cosa, iniciar y detener otros demonios. todo el «bloat» de systemd es de hecho opcional salvo por journald. así que la verdad no veo que cosa hace el sistema de inicio que se supone no debería hacer si esteolo hace una cosa. como dije, el resto de los prcesoso y servicios son manejados por separado por otros demonios, la mayoría puede usarse por separado inclusive. la única diferencia es que estos demonios opcionales son escritos por el mismo equipo, bajo el mismo calendario y en el mismo git (como hace de manera similar bsd)
maldad de lennart y red han? delirios de persecución y poco mas.
@Mirage pero es que systemd no es un mero sistema de inicio….
Es que ese es el problema, empezaron como un mero sistema de inicio y lograron convencer a muchas distros para luego dejar de ser un mero sistema de inicio y pasar a expandirse como un cáncer.
Te lo pinto mejor, yo quiero systemd, pero no quiero ningún otro módulo de systemd…pero cuando digo no quiero, es que no quiero que este instalado en mi disco rígido….no me alcanza con que este deshabilitado…es que no confío en las cosas automáticas que se pueden habilitar solas, por ejemplo cuando esta activo el protector de pantalla.
Entonces dime que distro me da una versión de systemd que no tenga esos módulos en su instalador.
actualmente uso linux mint 17 y no usa systemd (creo que solo algunas de sus dependencias) aunque en las distros que lo use me funciono perfecto, uso linux hace casi 2 años y le doy un uso básico (navegar en Internet, editar documentos de manera sencilla, etc) y cuando use systemd no me fallo ademas que a nivel técnico se nota una mejoría, y gran parte del odio me parece injustificado, muchos dicen que es por algo ético mas que técnico pero me parece demasiado aunque igualmente me gustaría ver una alternativa que este a su nivel aunque no le tengo fe a este (por ahora es básicamente un systemd mas «desnutrido» y ya el nombre me parece muy ridículo como para que sea algo serio)
¿Y porqué no seguir usando los script’s BSD? ¿O openRC del equipo Gentoo? ¿O olvidarse de todo lo anterior incluído SystemD y usar Upstart de Ubuntu?
Porque SystemD acelera el proceso de encendido y apagado del sistema GNU/Linux.
Además, lo que se quiere rescatar es eso, la velocidad de arranque de SystemD sin tener que usar los módulos de SystemD, y usar los de OpenRC, SysVinit e incluso los scripts de BSD, evitando así el blobbing de los logs.
Pues yo estoy contento con systemd.
Incluso le veo más ventajas que otra cosa.
He leído muchos comentarios y al parecer systemd….no va con la filosofía del 90% de usuarios del sistema Linux que esta en su contra,…me pregunto….porque tanto el intereses de systemd en querer controlar todo….osea tipo windows?,…no sera que detrás hay planes siniestro por controlar a todos y el gobierno mundial?. En la actualidad el sistema Linux Mint funciona de maravilla casi todo automático y no requiere de systemd. Si logra a apoderarse del sistema Linux…..no queda mas remedio que emigrar a BSD UNIX y sus derivados.
¿Qué otras distribuciones funcionan como Linux Mint, lleven o no Systemd?
Mirá en Windows no existe nada como systemd hasta donde tengo entendido.
Lo hacen ver como algo malo que esté centralizado, cuando a los únicos que les importa son a los que trabajan con el sistema, que suelen ser expertos, a nosotros los usuarios comunes nos viene mucho mejor systemd, incluso algunos sysadmins lo alaban, así que fijate que es todo relativo al gusto.
Systemd es muy bueno, pero de lo que mucha gente se queja es hay varios programas que van a necesitar dependencias nuevas para poder funcionar, ya que systemd es más intrusivo y va un poco más allá de lo que sería un sistema de arranque. También se quejan de que hace algunas tareas de forma automática, pero estoy seguro de que si aprendés a usarlo lo podés configurar a tu gusto.
Por eso digo: SystemD es bastante sencillo de gestionar, aunque cada vez me estoy despegando de lo que hacía en SysVinit (no es por desmerecer a SystemD, pero SysVinit me evitaba la molestia de tener que hacer dmesg para fijarme si hay algo en el cual metía la pata).
El propósito de hacer las gestiones de arranque a lo Windows es ahorrarte la molestia de tener que editar scripts. En otras palabras, eso significaría mucho ahorro de tiempo para los que no sean tan sysadmins.
Para los perfeccionistas y/o sysadmins seniors, es preferible el viejo SysVinit y el OpenRC de Gentoo (en mi caso, me gustaría que SysVinit tuviera la velocidad de arranque de SystemD, por lo que UselessD sirva como complemento adicional para que SysVinit o el OpenRC tengan las facultades que el mismísimo SystemD).
Supongo que has probado con rc_parallel=»YES» en /etc/rc.conf.
Sigue siendo un poco mas lento que systemd pero apenas unos segundos y siendo que el uptime diario en mi caso nunca es menor a 14 horas….8 segundos de diferencia no me están afectando.
Creo que con este fork se va a lograr cambiar el rumbo y espero que se unan desarrolladores independientes para lograr unir lo bueno de los inits con systemd
y desde luego que se siga la lógica de una sola tarea y hacerla bien.
@eliotime3000 hay cosas mucho más importantes que el tiempo de arranque, además ese factor tampoco es que es la gran cosa, al menos en mi caso, los tiempos de arranques entre systemd y OpenRC (usando Gentoo), no son muy distinto, ganando systemd por menos de 4 segundos, y sin usar rc_parallel=yes en OpenRC.
NOTA: A partir de acá, el que lea, por favor, hágalo con detenimiento y perdóneme algunas expresiones, además que quede claro que es mi opinión personal.
A mi lo que no me gusta de systemd, es el hecho de querer hacer cosas que ya están hechas, porque eso de reinventar la rueda me parece por más estúpido e innecesario.
¿Qué mierda hace un init con demonios luks, lvm, dns, dhcp, funcionalidades de avahi, logs, coredump, devfs, entre otras cosas? Acaso ya no existen demonios con todas esas funcionalidades.
¿Por qué demonios se necesita acceso root para manejar los logs y el coredump? (Esto lo he podido comprobar personalmente en Debian y Gentoo).
¿Por qué demonios tengo que reiniciar mi PC si hay algún cambio en systemd, es que acaso no puede reinicializarse a si mismo en caliente? El vejestorio de SysVinit puede hacerlo, y lo más importante, lo hace bien. Dicen que systemd puede hacerlo, pero hagan la prueba y verán que falla y no queda otra que reiniciar.
La cosa no termina allí, sino que se le conocen fallos a systemd y simplemente no se arreglan, y todo porque el equipo (Poettering llevando la batuta) simplemente prefiere ignorarlos y marcarlos como WONTFIX o simplemente ignorarlos. Incluso algunos de esos bugs ya son unos clásicos, el de journald, el de automontaje, y vamos señores que son del año 2011 y 2012 y aún no tienen arreglo, y no porque no se conozcan (tiene reporte y todo) o no sean fácilmente reproducibles, sino porque simplemente NO QUIEREN ARREGLARLOS. Ese comportamiento no viene con systemd, Poettering SIEMPRE ha sido así, Avahi (una de sus creaciones) también tenía problema parecidos, especialmente con leaks de memoria y consumo excesivo de CPU, muchos de los cuales aún siguen. ¿Quieren más pruebas? Pulseaudio es otra locura de este tipo, que si bien era algo que muchos esperaban con ansia, trajo más problemas que soluciones y no fue sino hasta hace poco, que muchos de sus problemas se solucionaron, eso si, lejos de la manos de Poettering.
Yukiteru +100
Es evidente, tal vez un simple usuario novato no se de cuenta, pero RedHat es una empresa y que yo sepa, lo que único que interesa a toda empresa es hacer dinero, si a esto le sumamos que pueden haber ciertas ofertas por agentes del gobierno para que «de a poco ir modificando», yo creo que todo es posible…el señor DIOS dinero todo lo puede.
El afán de poder de todos los gobiernos y grandes empresas no tienen límite, lo leemos a diario, resulta que el sistema operativo que se resiste es gnu/linux, sus usuarios suelen estar mejor informados sobre seguridad y privacidad.
Con systemd empezaron de a poco, de primero era todo lindo y lograron conquistar a las distros principales para que se cambien, luego de a poco fueron agregándole módulos para reemplazar lo que ya existía y siempre funcionó, pueden decir que si no te interesa no instalas esos módulos….pero hoo sorpresa, todas las distros te lo instalan completo y los usuarios de a pie no saben como compilar a mano y quitarlos.
El módulo mas perverso es journald el cual he leído en un mensaje que uno decía que ese no era opcional, que era obligatorio y que no se podía quitar.
Es obvio que no se va a poder quitar, la intención es no funcionar bien y no dejar que funcione bien syslog-ng, tampoco atender los reclamos de los usuarios que reportan esos bugs.
La técnica es encubrir para que no se pueda ver, luego manejar la red de forma automática para en un futuro no muy lejano perder total control manual de lo que pasa con la red y con los logs de lo que paso con la red.
De nada va a servir leer el código de systemd, todo hace lo que debe hacer y lo hace muy bien «para ellos», lo que esta mal es la funcionalidad combinada que representa un riesgo total ante un «bug no declarado».
Por eso, systemd no esta mal, lo que esta mal son sus creadores que deben ser cambiados.
que exagerado. te recurrió que es software libre y que si hay cosas raras se dan cuenta? y más en un proyecto tan controvertido como este crees que no hay cientos de geeks buscándole la quita pata al gato? pff el sensacionalismo siempre vende mas
Porque Systemd en realidad es la Skynet… jajajaja
y este fork supongo que es encabezado por canonical?
@emiliano
Que tal linuxito, por desgracia tenés razón y con mas desgracia que son pocos los sysadmin, menos de 1/4 de los usuarios….. Así que a esperar que sigan pasando cosas raras como.esta:
systemd-journald[150]: Failed to write entry (13 items, 351 bytes), ignoring: Bad address
Para demostrar que no estamos locos, ni es por puristas sino por temas técnicos.
Pueden ver el error en este cgit usando ctrl+f pero claro como lennart no suele comentar, otra mala practica que tiene no van a saber que es ese error:
http://cgit.freedesktop.org/systemd/systemd/tree/src/journal/journald-server.c
No sos el unico elav:
https://bbs.archlinux.org/viewtopic.php?id=150704
Hay muchos post con eso pero no veo ninguno que diga realmente que es, me suena a bug y se parece a los de PulseAudio con su pollin que lo despertó y los eventos suprimidos
Terrible!!
Y aunque no lo creas hay muchos mas que reportan ese error, parece que viene de otro error y ese es un sintoma pero tambien que es un error propio, en fin, systemd esta plagado de bug, al menos sysv no tenia errores, hacia tanto que estaba probado que estaba super pulido. Hoy intenté deshabilitar journald en una VM, no me dejo, es imposible, lo unico que se puede es poner syslog y hacer que journald le envie las cosas asi el las escribe, pero, y si journald falla?… Desde cuando no puede deshabilitarse un demonio de logueo en Linux?… cosa de Windows esto, despues dicen que es modular, si ya veo
Ni el dmesg los salva. Al ojo noto que es el JournalD que está bugeado.
Espero que OpenBSD o la Fundación Apache muestre su apoyo a dicha bifurcación.
@elav
Tenés compañía, sumate al bug report a ver si lennart trabaja un poco:
https://bugzilla.redhat.com/show_bug.cgi?id=1069828
Es un bug.
Añado, es un Bug generado por otra cosa solo que es » otro » síntoma según los de fedora pero con el mismo origen:
https://bugzilla.redhat.com/show_bug.cgi?id=1043212
¡VIVA EL DMESG!
Ya, en serio, gracias al epic fail del JournalD mostraré mi apoyo hacia dicho fork de SystemD, ya que con JournalD no me enntiendo mucho (con DMESG se ve bastante los errores de arranque del kernel, e incluso, de los demonios hasta de SystemD).
Mucha gente rechaza systemd porque no cumple con la filosofía de Unix. Señores, Unix está moribundo y en peligro de extinción, hay momentos en que hay que dejar un poco las ataduras del pasado y tratar de hacer algo mejor aunque rompa con la vieja filosofía. Dejen el conservadurismo y si systemd les da algún problema, pues reporten el bug y ayuden a probar los parches que lo solucionen. En mi opinión el uselessd no va a llegar a ningún lado, así que su nombre le viene muy bien, useless, inútil, una total pérdida de tiempo y esfuerzo que se podría dedicar a hacer algo mejor.
Hombre, ¿pero no viste los enlaces en este mismo post al Bugtracker de RedHat? El creador de Systemd no responde ni comenta en ninguno de ellos. ¿De que sirve hacer reportes de bugs si el tipo se los pasa por el forro?
En este momento, SystemD tiene reportado 240 sólo en el bugzilla de RedHat (habiendo reportes también en otras paginas):
https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&component=systemd&product=Fedora
Con un máximo de 3 o 4 personas trabajando, según Wikipedia:
https://en.wikipedia.org/wiki/Systemd
Teniendo que trabajar con bugs que pueden llevar desde algunos días hasta varios meses en arreglar. Y a eso también hay que agregar que tienen que agregar nuevas características y eliminar código antiguo.
¿A vos te parece que tienen tiempo para responder a cada uno de los reportes?
Acá más de uno se cree con derecho a opinar sobre el trabajo de los programadores de sistemas, cuando lo máximo que han hecho es escribir un script en Bash o Python y meterle un tema a WordPress, pero se cagan en las patas si tienen que mantener un programa de gran calibre.
La gran mayoría los que se quejan de SystemD no tienen ni la más mínima idea de lo que hablan. Son sólo un montón de pollos cacareando.
Primero que todo hipersayan_x, si yo fuese a lanzar una aplicación como SystemD lo primero que haría antes que todo, sería documentar lo mejor posible cuales son sus especificaciones, sus posibles problemas, el significado de sus logs, etc.. con esto, evitaría molestias como la mía, donde todavía no conozco que carajo significa el dichoso error (o mensaje):
systemd-journald[150]: Failed to write entry (13 items, 351 bytes), ignoring: Bad addressAdemás, considero que si te vas a dedicar a crear una aplicación, debes al menos emplear 1 hora de tu tiempo en dar respuesta a los bugs que presentan las personas que la usan. Si no puedes con eso, deja un mensaje al menos o que se yo, pero no responder nos deja en la incertidumbre.
A cada cual según su trabajo.. y cada cual es responsable de lo que hace. No entiendo que significa esta parte del comentario, por el simple hecho de que un diseñador de temas para WordPress (o un usuario que simplemente instala un tema), o una persona que programe un script de Bash o Python, no necesariamente está obligado a mantener un programa de «gran calibre» ni mucho menos. Como diría el tío Ben: «Un gran poder conlleva una gran responsabilidad», que llevándolo al tema que nos ocupa: «Un gran programa, conlleva una gran responsabilidad«, y por responsabilidad entiendo todo lo que sea: Soporte, Desarrollo, etc..
Si eres tan amable de explicar detalladamente y con datos técnicos como funciona Systemd para que los que cacareamos dejemos de hacerlo o simplemente entendamos mejor, te lo voy a agradecer infinitamente.
Saludos
Está perfectamente documentado:
http://www.freedesktop.org/wiki/Software/systemd/
Secciones: Manuals and Documentation for Users and Administrators y Documentation for Developers
¿Te parece poco?
Acá aparece la linea de ese mensaje:
http://cgit.freedesktop.org/systemd/systemd/tree/src/journal/journald-server.c#n513
Y el código relevante aparece en L448, así que todo depende de que mensaje te haya dado antes.
Así funcionan todos los foros de internet, te pueden responder o no, si no te responden puede ser porque: no tienen respuesta, no les interesa tu mensaje, tienen otras prioridades, o están trabajando en otras cosas y no tienen tiempo para vos. Aceptá que no sos el centro del universo, además de que ellos no reciben nada de tu parte por arreglar un bug que te afecta particularmente.
manual hay. es cuestion de leerlo, quiza el problema es que mucha gente no lo lee, no estoy en debian. pero no me limito solo al man que se empaquete http://www.freedesktop.org/software/systemd/man/systemd.html,
yo leo el blog de http://en.wikipedia.org/wiki/Lennart_Poettering hay un ciclo muy bueno de (tutoriales) http://0pointer.de/blog/projects/systemd-for-admins-1.html
@hipersayan_x ¿En serio amigo? Te invito (una vez) más a que me traduzcas que significa la línea 513 de ese enlace que me pusiste, porque no veo como eso explica cual es el problema que arroja ese mensaje.
No se trata de mi, se trata de un montón de gente.. Mira el link en el comentario #66. 😉
@elav, vuelvo a repetir, según lo que se puede leer en el CF, antes de ese mensaje tiene que aparecer otro mensaje indicando el porqué no fue posible escribir en el log, y por lo tanto ese sería el problema real.
esta bueno que se hagan forks de las cosas, es una forma de medir la eficacia, me causa risa, que desabiliten caracteristicas que las uso a diario y aceleran la experiencia del usuario, o de otra forma, sirven para automatizar el sistema, lo considero como una apreciacion de un usuario novel en la capacidad de uso de sistema. Es una cuestion de crecer (madurar) en cuanto a apreciaciones del uso de sistema, quiza porque me guste mas verlos como conjuntos de ordenes dentro de un script, en ves de espejitos de colores. quiza sea mas util leer el manual mas seguido y hacerce planteos de como hacer un sistema mas automatico, pero dentro de un marco logico, definido por el usuario (que no siempre esta frente al terminal).
Saludos
@ASPERO
Hacer que las cosas sean automáticas, quita flexibilidad y genera imposición, no puedes poner a todos en la misma bolsa, al definir algo automático estás buscando que se generen forks, porque habrá mas gente disconforme que no se va a quedar sentada mirando como crean un nuevo windows.
Unos comentarios mas arriba, pregunté si sabían de alguna distribución que tenga el paquete de systemd sin los «módulos opcionales», pero se ve que no hay…nadie me respondió.
En mi caso no tengo necesidad, vivo feliz con gentoo hace mas de 5 años con eudev y openrc, pero tengo una notebook que uso poco, que aún tiene archlinux, la sigo actualizando para ir viendo como va el asunto y no opinar de oído de lo que dicen otros.
A tocarse los cojo!@#$% me acabo de desayunar que en ArchLinux no hay crontab, el cron se maneja con Systemd.. Grrrr
https://wiki.archlinux.org/index.php/Systemd/cron_functionality
@elav
Hay que promocionar las distribuciones que no usen systemd, no queda otra.
Lo se, no serán las más fáciles de instalar, pero visto el rumbo de todo esto
creo que empezarán a aparecer mas distros nacidas de LFSs, como crux que
fue madre de archlinux y que tengo entendido que aun siguen usando init.
También pueden aparecer distros al estilo sabayon que no son otra cosa que shots
de gentoo en binarios i686.
Systemd es como el tema de AC/DC «Got You By The Balls»
https://www.youtube.com/watch?v=2ICWCMaRypI