Cada día nuestros ordenadores forman una parte más importante de nuestra vida, si tiene algún tipo de problema nos afecta nuestro estado de ánimo, nuestro humor jeje. Claro, los usuarios de Windows son más propensos a ataques de pánico, que si los virus (viva linux!), que si desfragmentar el HDD, que si buscar e instalarse el Clean Master para PC (aunque aquí en Linux igual debemos limpiar el sistema, BleachBit es una de las alternativas preferidas). Recientemente los usuarios de Linux tenemos (algunos) cierto dolor de cabeza llamado: systemd
Bueno al grano, he leído un artículo interesante sobre systemd, que parece ser lo que está de moda desde hace no mucho.
SystemD, que a algunos le parece como (y haré uso de palabras de un amigo), one ring to rule them all … a otros simplemente ni les va ni le viene, mientras el ordenador funcione bien, no le importa si init hace X o Y cosa, o si se usa systemd. A este quien les escribe, bueno… digamos que prefiero init, lo encuentro más simple 🙂
Les dejo aquí el artículo:
Antes de comenzar debo decir que no me gusta nada la decisión de cambiar las cosas en Debian pero, en ningun momento planeo abandonar mi querida espiral. Solo intento que, si vamos a discutir un tema, por lo menos lo hagamos lo más preparados posible aún cuando yo mismo no me considero pro-systemd. Para lograr la desmitificación de systemd me apoyaré en un sitio web donde los desarrolladores dan su punto de vista el cual llegó a mis manos por un colega que si parece ser pro-systemd aunque no sea usuario de Debian. Dicho esto creo que puedo pasar a intentar desmitificar lo que se dice sobre systemd.
systemd es a base de binarios
Quizás este sea uno de los aspectos que más nos choquen, ¿si todo es a base de binario como monitorear las cosas que usualmente hacemos a través de logs?. No tengo ni idea de como nació este mito, pero no es absolutamente cierto.
systemd se configura casi exclusivamente a través de archivos de texto simple. Unos ajustes que también pueden alterar con la línea de comandos del kernel y a través de variables de entorno. No hay nada binario en su configuración (ni siquiera XML). Sólo un simple, sencillo y fácil de leer archivo de texto.
Esa cosa es monolítica y lo controla todo
Antes de llegar a la web mencionada anteriormente confieso que yo mismo pensaba de esta manera pero luego de leer lo que dicen sus desarrolladores mi opinión ha cambiado algo…
Si usted hace una build de systemd con todas las opciones de configuración habilitadas usted construirá 69 binarios individuales. Estos binarios sirven para diferentes tareas, y se separan cuidadosamente por un número de razones. Por ejemplo, se ha diseñado systemd pensando en la seguridad, por lo tanto, la mayoría de los demonios corren con privilegios mínimos (utilizando las capacidades del núcleo, por ejemplo) y son responsables de sólo tareas muy específicas, para reducir al mínimo su superficie la seguridad y el impacto. También, systemd paraleliza el arranque más que cualquier solución anterior. Esta “paralelización” se crea ejecutando varios procesos en paralelo. Por lo tanto queda visto que systemd está muy bien dividido en muchos binarios y por lo tanto los procesos. De hecho, muchos de estos binariosse separan tan bien, que son muy útiles fuera de systemd.
Un paquete que incluyó 69 binarios individuales difícilmente pudiera ser llamado monolítico. Lo que es diferente de las soluciones anteriores sin embargo, es que enviamos más componentes en un único tarball, y los mantenemos encadenados en un único repositorio con un ciclo de lanzamiento unificado.
Eso no se parece a Unix
Ciertamente hay algo de verdad en eso. Los archivos de las fuentes de systemd no contienen una sola línea de código procedente de las líneas originales de UNIX. Sin embargo, se deriva la inspiración de UNIX, y por lo tanto hay un montón de UNIX en systemd. Un ejemplo sería la idea de UNIX “todo es un archivo” el cual se encuentra reflejado en que en systemd todos los servicios se exponen en tiempo de ejecución en un sistema de archivos del kernel, los cgroupfs. Entonces, una de las características originales de UNIX fue el soporte multi-seat, basada en el apoyo integrado en el terminal. Con systemd trajimos el soporte multi-seat de forma nativa nuevamnte, pero esta vez con el soporte total para el hardware de hoy, que cubren gráficos, ratones, audio, cámaras web y más. De hecho el diseño de systemd como una suite de herramientas integradas que cada uno tiene sus propósitos individuales pero cuando se usan juntos son más que la suma de las partes, que más o menos en el centro de la filosofía UNIX. Entonces, la forma en que nuestro proyecto se maneja (es decir, el mantenimiento de la mayor parte del núcleo del sistema operativo en un único repositorio git) es mucho más cercano al modelo BSD (que es un verdadero UNIX, a diferencia de Linux) de hacer las cosas (donde la mayor parte del sistema operativo central es mantenerse en un único repositorio CVS / SVN) cosa que nunca fue asi en Linux.
En última instancia, la cuestión de si algo es UNIX o no importa muy poco. Siendo técnicamente excelente es apenas exclusivo de UNIX. Para nosotros, UNIX es una influencia importante (de hecho, el más grande), pero también tenemos otras influencias. De ahí que en algunas zonas systemd serán muy UNIX, y en otras un poco menos.
Es que eso es muy complejo…
Ciertamente hay algo de verdad en eso. Las computadoras modernas son bestias complejas y el sistema operativo que se ejecuta en ellas obviamente también lo será, por lo tanto tienen que ser complejo. Sin embargo, systemd ciertamente no es más complejo que las implementaciones anteriores de los mismos componentes. Es más sencillo, y tiene menos redundancia. Por otra parte, la construcción de un sistema operativo sencillo basado en systemd implicará mucho menos paquetes que los que usa un Linux tradicional. Menos paquetes hace que sea más fácil de construir su sistema, se deshace de las interdependencias y de gran parte del comportamiento diferente de todos los componentes involucrados.
Eso no me va a dejar usar scripts de Shell
Esto es totalmente falso. Simplemente no los usamos para el proceso de arranque, porque creemos que no son la mejor herramienta para ese propósito específico, pero eso no significa systemd era incompatible con ellos. Puede ejecutar fácilmente los scripts de shell como servicios systemd o demonios, puede ejecutar scripts escritos en cualquier idioma como servicios systemd ya que a systemd no le importa lo más mínimo lo que hay dentro de su ejecutable. Por otra parte, en gran medida utilizamos scripts de shell para nuestros propios fines, para la instalación, construcción, pruebas de systemd. Y usted puede pegar los scripts en el proceso de inicio temprano, se utilicen para los servicios normales, se pueden ejecutar en la última parada, prácticamente no hay límites.
Llegados a este punto supongo que algunas de las principales creencias pueden haber sido aclaradas, a pesar de no sentirme un defensor del cambio y tener mis recelos sobre eso de “un demonio para controlarlos a todos” creo que al final nadie se atreverá a decir que por lo menos no funciona, incluso conozco algunos usuarios que notan que con systemd “la PC camina mas rapido” pero ya esas serían otras cosas que pudieran discutirse. Por el momento solo me resta invitarlos a debatir aquí los puntos de vista que tengan sobre el gestor de inicio que muchas distribuciones han adoptado aunque ahora las mayores reacciones se estén viendo dentro de la comunidad de Debian el cual hasta le ha nacido un nuevo fork con todo esto. Si gustarle o no es una cuestion de cada uno, yo por mi parte solo quiero poner mi granito de arena en la desmitificación de systemd que al final va a estar presente en Jessie, la próxima versión estable de Debian.
El artículo lo ví en GUTL (que a su vez fue tomado de DesdeAbreus)
¿Actualidad de systemd?
Soy de los que no lee muchas noticias cuando algo genera tanta polémica, prefiero quedarme con detalles más técnicos. Es que…. a veces siento que determinados temas dejan de ser una discusión o debate meramente técnico, y pasan a ser como uno de esos chismes de farándula 🙁
Primero una bronca abierta de un usuario a systemd llamada systemd VS inteligencia, luego Linus Torvalds diciendo que systemd no es tan malo como lo pintan (y algo de razón si que tiene), un fork llamado uselessd … no comments … y para no alargar más, finalmente Devuan.
No diré si es tan malo como dicen, menos malo o peor. A mí el sistema me funciona sin problemas, no obstante por gusto personal preferiría init, pues su forma de organizar varias cosas (como logs por ejemplo) me gusta más, pero bueno, si systemd viene a ser llamado un caballo de carreras y debe sustituir a init (¿sería nuestro mulo de carga, que hace todo pero lento?) pues… hombre, mientras el cambio no sea extremadamente brusco, los usuarios se puedan adaptar sin mucho problema y el sistema funcione mejor (sí, mejor, igual no me vale!), pues bienvenido sea 😀
Muy buen articulo, llevo unos días con Linux Mint 17.1 Rebecca con systemd y lo siento mucho más fluido que en versiones anteriores, no se mucho acerca de esto debido a que soy un usuario común que esta aprendiendo sobre esto pero estare al pendiente, este es el primer articulo que leo que no habla pestes de systemD.
Por algo será el primero que lees que no habla pestes de el y por otro lado, cuentame, usas tu Mint como servidor?, o sea, no te molestaría si tiene un fallo de vez en cuando no?, es por eso que usas Mint, y es por eso que no te molesta, no te gusta pero tampoco te jode systemd. Cuando tengas fallos y a causa de eso tengas problemas serios en entornos serios, va a molestarte.
Amigo, alguan distro basada en Debian Stable que me recomeindes? Podria usar Debian, pero hay que configurale muchas cosas una vez isntalado, codecs, etc… Cual me recomiendas? gracias.
¿Y como lograste meter systemd en Linux Mint? Yo quería intentar meterlo pero no se si haya que hacer algo adicional (a lo que, en teoría, ya trae Ubuntu), si tienes alguna guía al respecto o algo que me puedas pasar te lo agradecería mucho
Muy buen artículo. A ver si los talibanes anti-SystemD lo leen (pero lo dudo)
En todo caso, de aquí a un año los veré usando SystemD y negarán lo que dijeron un año atrás. Así son. Resistentes al cambio? Seguro que sí.
Me consideras un talibán por no querer aceptar a Systemd, pues entonces yo te considero un talibán por no querer aceptar que yo no quiero aceptar Systemd. Estamos a mano 😉
No obstante según dice al final de tus artículos:
«elav: Blog Personal / Twitter / G+ / Usuario de ArchLinux. Informático, melómano, blogger y diseñador web. Administrador y Fundador de DesdeLinux.net. »
es decir, usas una de las primeras distribuciones que adopto SystemD.
Saludos
Ok niño.
Sin palabras!!!!, sigue jugando, que la vida es de color de rosa.
Por comentarios como el tuyo, estimado Giskard, es por lo que reniego de SystemD y de lo que representa.
Y si después de 20 años usando y trabajando con y para Linux, soy un Talibán; pues, así sea.
En un año hablamos. Y elav, yo no te mencioné. Te mataste tú solito como Chacumbele.
A ver, que la gente lee y NO lee. Hay o no hay talibanes en contra de SystemD? Los hay! Y los hay del otro lado, de los que lo defienden a capa y espada como si fuese una panacéa. Que son todos los que son? No! Para nada! Hay quienes SIMPATIZAN con uno u otro y ven lo bueno y malo tanto del propio como del ajeno. Con esos se puede hablar sin problema. Pero no me van a negar que HAY talibanes. Y de lado y lado. Y si alguien se picó por eso sin entender que podría muy bien NO ser un talibán, entonces descanso mi caso pues las pruebas los hacen culpables.
Si yo dialogo con alguien sobre SystemD y de entrada esa persona no lo llama por su nombre sino Systemshit o algo similar yo quisiera que me dijeran, sinceramente, si es posible tener una conversación con tal persona que de entrada descalifica al oponente. No se puede.
En fin, hay que leer . A ver, si yo vengo y digo «es que hay unos eschejfhduf (palabra inventada) que golpean niños al salir del colegio» y vienen unos cuantos a defender a los «eschejfhduf» no es para pensar que ellos mismos lo son?
Bueno, si alguien por ahí (no talibanes, por favor, y tampoco eschejfhduf) quiere conversar sobre los pro y contra de init y SystemD (que ambos tienen buenas y malas) con gusto estaré por acá.
Saludos.
Los talibanes anti systemd? y contame, ustedes que son? los talibanes pro-systemd?, por otro lado, porque asumis que no vamos a leer sino a comentar directamente?, quien es el taliban de mente cerrada que no admite discusion y habla como LP:: «es lo mejor, confia en mi, se lo que hago». ?.
Lei todo el articulo y te puedo decir:
Systemd es a base de binarios: Cierto
El demistificacion: Falsa
LP esta tergiversando lo que se dice, que es que el core de systemd son binarios, muchos, demasiados para colgar de PID1, entrelazados entre si fuertemente, tanto es que te invito a que mires en #devuan como cuesta limpiar por ejemplo, logind de systemd y el resto de los paquetes en Debian, dada lo ligado que esta al sistema el logueo que reemplaza a PAM.
La configuracion es escueta y no permite TODO lo que no desearia, como, desactivar journal, dado que no puedes ni matar el PID, ni pararlo ni nada, eso es modularidad?, con sysvinit al menos, podias matar todo hasta quedar solo con init, lo mismo upstart.
===========
«Esa cosa es monolítica y lo controla todo»
Lo es, mas alla de que sean 2 o 69 binarios, se entrelazan entre si con dbus y asi con el OS entero, no dejando des-relacionarlos a todos con facilidad, el caso mas claro es journald, que no puedes desactivarlo, ademas, el inicio de demonios o servicios se hace mediante «unidades» que son archivos de texto, pero nada mas que eso, parseados por systemd y listo, nada de modificaciones o hacks en servicios mas alla de lo establecido.
=======
«No se parece a UNIX»
Lo voy a responder brevemete. No cumple con la LSB, tampoco con POSIX y hoy mismo un fedora developer que ayuda en #devuan, dijo: «Es cierto no lo es, tampoco importa, lo que importa es que pueda corrar cosas que si sean POSIX, el resto, ciertamente no me interesa que OS o cosa sea, mientras funcione y tenga buenas features». Y porque deberia ser UNIX o UNIX-like: Haz una cosa y hazla bien, algo que systemd, no hace.
===========
«Sin embargo, systemd ciertamente no es más complejo que las implementaciones anteriores de los mismos componentes. Es más sencillo, y tiene menos redundancia»
Menos redundancia?, te piden que instales OTRO syslog para texto plano y lo pedian para logueo remoto antes de existir systemd-journald-remote, o sea, lo sacaron a produccion sin poder hacer un logueo remoto sin depender de rsyslog, algo basico como el logueo centralizado. Aun asi, no tiene la capacidad, un simple boolean de indicar si queremos la salida en binario o en texto plano y ademas, si iba a usar binario porque no algo conocido como berkeley DB para que pueda ser leido desde cualquier sistema UNIX o Linux?
Sencillo?, realmente? miren un poco lo sencillo que es: http://wiki.gentoo.org/wiki/Comparison_of_init_systems
Miren la cantidad de lineas de codigo y archivos.
=========================
«Eso no me va a dejar usar scripts de Shell»
Eso es falso, pero de nuevo tergiversa, no se le critica que no permita usar bash script, sino que no los use para el inicio de servicios, con lo cual no es modificable, hackeable y flexible como lo es upstart o sysvinit. Y por hackeable me refiero a harcodeado.
============================
Todavia pensas que:
1.- No tengo nada de razon
2.- No lei nada y soy un taliban?
yo me pregunto… ¿realmente hay que confiar en lo que dice Lennart?, si me lo dice alguien neutral puedo tomar ciertas cosas en consideración, pero esto me sabe igual a que Red Hat publique algo para defender Systemd
Vaya, hasta que alguien de por aqui dice algo razonable y no solamente miedo y desinformación.
El artículo es la traducción al español de lo escrito por Lennart..
Sin ánimos de ofender, pero la traducción parece hecha por Googlel Translator versión beta… 🙁 trabajo me costó entender algunos párrafos; de todos modos es de agradecer la información.
@Charlie-Brown, es por que Lennart no sabe muy bien expresarse en ingles. Asi de feo se entiende leyendo el original.
Válidas las razones expuestas, no obstante, pienso que a algunos le puedan generar más interrogantes. En cualquier caso, mi recomendación a los que tengan la oportunidad: acudan a la fuente original de la información http://0pointer.net/blog/projects/the-biggest-myths.html (desafortunadamente para algunos, está en inglés) que es mucho más completa y llega a fundamentar hasta 30 razones por las que se considera favorable el uso de SistemD.
Ese artículo que mencionas está escrito por el creador de Systemd. Como es lógico nadie mejor que él para defender su trabajo, no obstante, los invito a ver este video http://hackingthesystem4fun.blogspot.com/2014/12/systemd-journald-centos-7-totally.html y ya me dirán sus conclusiones al respecto. No digo más.
elav el tema de los log de journal que esten en un binario es uno de los puntos mas criticados, hasta el propio linus lo planteo, cuando en un reportaje donde admitio que systemd no estaba tan mal. Asimismo el propio linus explico que podes crearte un script para tomar los datos de journal y ponerlos en texto plano.
También systemd te permite configurar el tamaño del binario de journal disminuyendo los riesgos de un posible fallo.
realmente el art que citas es muy poco serio, ya que no tiene una pizca de objetividad, y hasta me hace preguntar si realmente es real el fallo que muestra es real o esta trucado (joder el software apropósito para que de el error).
todos los programas en algún momento tienen fallos, pero pareciera que siempre le van a buscar la quinta pata al gato para encontrarle algo malo a systemd.
Por ejemplo: en debian se decidió que systemd sera el init predeterminado, pero no impide usar sysvinit o openrc o upstart y me dirás bueno si pero no se puede sacar totalmente a systemd, y mi respuesta seria que es lo mismo que sucedía en debian wheezy donde vos podes correr openrc, systemd o upstart pero bajo sysvinit
PD: no me quiero imaginar que locos se van a poner con kdbus y su integración con systemd a nivel del kernel de linux http://kroah.com/log/blog/2014/01/15/kdbus-details/
Si puede ser. Es más, pienso retirarme oficialmente de los debates que tengan relación con Systemd. Que pase lo que tenga que pasar 🙂
@rolo el fallo está documentado, se le han presentado varios bugs reports, le presentan un video y ahora dicen que está trucado. Si quiere estar seguro siga los paso y vea lo que pasa. Ahora por aca hay más información del asunto, ¿Bugs inventados? No lo creo.
https://bugzilla.redhat.com/show_bug.cgi?id=958321
https://bugzilla.redhat.com/show_bug.cgi?id=1054929
https://bugzilla.redhat.com/show_bug.cgi?id=1055570
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=74280
https://bugs.archlinux.org/task/32191
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=64116 (Lennart y sus grandes explicaciones)
https://bugzilla.redhat.com/show_bug.cgi?id=974132
https://bugzilla.redhat.com/show_bug.cgi?id=1157350
Lo que menciona el vídeo es ciertamente curioso. Como desarrollador, siempre se nos dice que un detalle no debería afectar a todo el sistema/programa, por ejemplo, si falla una consulta de selección a la base de datos, ¿por qué habría que ver caer todo el programa? Es lo mismo con SystemD, si falla porque otros fallan, no sé que tan bien hecho esté. Obviamente, existen casos en los que un fallo son prácticamente el fallo del sistema, pero mientras más aisladas estén internamente las propiedades del programa, mejor producto se tendrá.
Ahora, atacar a un software por su lado débil no es nuevo, es más bien una práctica muy común y que de hecho se debería hacer con todo programa, así que ver caer a SystemD por el journald, es una prueba válida de que aún SystemD no es lo que se dice o se hizo creer.
Cuantas más cosas se vuelvan interdependencia con SystemD, peor será la cosa. Si antes mondar un dispositivo no hacía caer al sistema, puede que ahora las cosas no tengan tan buena pinta.
SystemD no es malo, no lo odio, pero no es lo que muchos quieren hacer creer. Ventajas tiene, pero nada que Upstart no tuviera o pudiera tener, claro, Canonical metida de por medio y ya nadie quiso poner atención.
Saludos.
pero en ese video en ningún momento se que que el sistema se caiga. el tipo lo que hace es modificar el binario de la info de journal para generar el fallo, pero el punto es que todas las veces entra a systemd.
por lo que entiendo, si limitas el tamaño del binario de journal, cuando llega al limite crea otro y así. disminuyendo la posibilidad de corromper todos los datos.
Es que seamos claros… ¿A quién se le ocurriría modificar el archivo del log, también? xD
@Jorgicio 4 diciembre, 2014 6:03 PM
Es que seamos claros… ¿A quién se le ocurriría modificar el archivo del log, también? xD
Si lo dijiste en modo irónico…todo bien, lo he entendido :)), pero si preguntaste realmente, doy mi punto de vista.
Para mi esta claro que no es un bug, es una característica!! la idea es que si hay escalamiento de privilegios en un acceso remoto, sería muy fácil para quien accede eliminar el log simplemente editándolo para corromperlo y que systemd lo elimine por corrupto y así librarse de ser detectado en ese acceso remoto.
Diganme paranoico, pero no me queda otra manera de pensar….no es un bug, es una característica y es por eso no aceptan reparar ese bug.
uff ahora todos los blogs de linux hacen 200 articulos sobre systemd al punto de que ya me conosco casi todos los argumentos en contra y a favor xD.
y de a poco me han ido convenciendo algunas de los argumentos anti sistemd y entre los que he visto(si hay algo equivocado por favor corriganme)
por ahi vi incluso un articulo sobre como hacer crashear todo el sistema cuando se edita un log binario y que este no da informacion alguna que el archivo esta corrupto.
la falta de claridad en los logs
un equipo de desarrollo que suele ignorar los reportes de bugs
por ser tan grande e incluir tantas cosas dentro de un init hace mucho mas inestable el sistema y si a eso le sumamos bugs como el anteriormente mencionado hace un sistema sin la estabilidad que tanto caracteriza linux.
se dice modular pero las partes del mismo no pueden funcionar sin otras partes del mismo systemd
un desarrollo que a la larga genera dependencias a la hora de programar haciendo que software como gnome dificilmente portables a sistemas sin systemd.
reemplaza partes(networkd,logind etc) que llevaban años funcionando y recibiendo mantenimiento y las cambia por unas nuevas sin necesidad alguna que suelen tener muchos mas bugs.
Del tiempo que llevo usando distros basadas en Arch (Manjaro, Bridge Linux, Antergos) que obviamente usan systemd, debo decir que no tengo quejas respecto a su uso y manejo. Iniciar servicios es fácil -más aún en Bridge, donde el bluetooth o modemmanager vienen desactivados por defecto-. Aparte de un bug relacionado con hwdb.bin (https://bbs.archlinux.org/viewtopic.php?id=189536) no he tenido muchos problemas. Obviamente no creo sea la opinión de todos, pero en lo personal no tengo quejas 🙂
No me gusta la idea de que una empresa (Red Hat) acusada de colaborar con la NSA (puertas traseras y control de EEUU) haga un sistema con el que se controla todo. Un anillo para controlarlos a todos, para atarlos en las tinieblas si es necesario..
Por otra parte tengo que reconocer que la intel IRIS PRO 5200 me va mejor y ya casi nunca, por no decir que ya no, se me rompe el sistema gráfico al iniciar openSUSE 13.1. Y si, todo va mejor, se inicia y se apaga mucho más rápido. Cómo un simple usuario me ha beneficiado.
resalto la parte importante
¿si alguien te acusa de que vendés droga automáticamente sos narcotraficante?
@juanfgs
narcotraficante no….cómplice si.
dios… te insultaría pero tus propias palabras lo hacen por vos.
Solo aclarar que se escribe systemd, y es asi como debe de hacerse.
Spelling
Yes, it is written systemd, not system D or System D, or even SystemD. And it isn’t system d either. Why? Because it’s a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d. And since systemd manages the system, it’s called systemd. It’s that simple. But then again, if all that appears too simple to you, call it (but never spell it!) System Five Hundred since D is the roman numeral for 500 (this also clarifies the relation to System V, right?). The only situation where we find it OK to use an uppercase letter in the name (but don’t like it either) is if you start a sentence with systemd. On high holidays you may also spell it sÿstëmd. But then again, Système D is not an acceptable spelling and something completely different (though kinda fitting).
http://freedesktop.org/wiki/Software/systemd/
Aquí también? Eso mismo lo pusiste en GUTL.. pero hombre, todos dicen Linux y no GNU/Linux, así que con SystemD lo mismo.
Te comento que no es necesario usar el sistemas de log ni el cron que provee systemD podes seguir syslog-ng y cronie para esto u otras alternativas
yo uso systemD en ArchLinux desde que estaba en aur y me parece mas simple de majar que la forma en debian y redhat derivadas, este tiene un montón de comandos de consola que que te ahorran editar los archivos de texto y simplifican el armado de scripts de configuración instalación(recuerden que en arch se instala todo por consola)
Y no menos importante el sistema inicia rápido, en arch se podía iniciar servicios en paralelo al iniciar el sistema pero erra arriesgado
lo que me parece mal del tema es que la mayoria toma bandos, o sos pro-systemd o anti-systemd, y creo que tiene sus cosas buenas y malas, yo soy un usuario y me puse a jugar un poco con systemd, la verdad que sus cosas buenas, el inicio es mas rapido y menos complejo que el resto de los init, aunque el tema de los journal a mi tambien me molesta mucho.
Entiendo que los que realmente pueden decir si es bueno o malo son los sysadmins o expertos en el tema pero me parece que el revuelo de systemd hace rato dejo de ser algo tecnico y paso a ser algo mas «farandulero», por mi parte estoy en un poco en contra pero no me considero anti o pro
@KZKG_Gaara
Veo que mucho que lo que comentas acá es lo mismo que Lennart ha publicado en su blog más precisamente en esta entrada: http://0pointer.de/blog/projects/the-biggest-myths.html.
Claro el post ha tenido ciertas «aclaratorias» y ha dejado de lado cierto contenido técnico, con el fin de ser una información fácil de digerir para quien la vaya a leer, pero vamos a ser serios y sinceros, por más que duela la verdad: systemd tiene muchas de las cosas que Lennart niega no tiene, eso y mucho más en realidad. Y en este sentido explico por parte.
1.- Lennart dice que no es bloated y que no tiene un alto sindrome de NIH (Sindrome de Not Invented Here). Si es así por favor que alguien me explique: ¿Por qué un init debe tener control de redes (systemd-networkd), dns (systemd-networkd), m-dns (systemd-networkd), logs (journald), coredumps (systemd-coredump), debugs (systemd-coredump y journald), acpi (logind), escalado de privilegios (logind), control de ntp (systemd-timesyncd), control sobre dev (systemd tomo toda la funcionalidad de udev), control de /dev/random (generador de numeros aleatorios) y el más reciente control sobre TTY (systemd-consoled)? ¿Acaso ya no habían MUCHAS herramientas creadas para tales fines como para que systemd ahora sume las suyas algunas con acceso exclusivo (caso journald)? ¿Qué explicación lógica y aceptable me da a que un init sea capaz de romper el debug y la cmdline del kernel? A eso sumenle el control sobre kdbus, el proximo IPC que será integrado al kernel. Seguramente me dirán aca: «Pero te puedes instalar otra herramienta para controlar todo eso». Y si es cierto, pero, muchas de esas herramientas solo reciben un stream de datos arrojado por systemd, como el caso de syslog y rsyslog, los cuales se conectan a un data/stream que journald provee para que otras herramientas puedan VER lo que journald maneja, al final, eso solo significa que tienes dos herramientas que hacen lo mismo, y una de ellas es una caja de pandora. (Por favor que no me digan que el código se puede auditar, porque invito a que alguien pueda «fumarse» el código de journald y su entramado con systemd y demás herramientas relacionadas)
2.- Lennart tambien nos dice que systemd ofrece soporte para SysV y LSB scripts. Esto es una «media verdad» una «mentira blanca» por asi decirlo, porque lo cierto es que systemd-214 no ofrece soporte para bash scripts ni SysV ni LSB y eso está relatado en su Release notes para esa versión.
3.- ¿Qué systemd no es portable? Es otro punto discutible. En BSD no funciona pues bueno, en BSD no existe Cgroups entre otras herramientas que systemd necesita para su ejecución. Pero es por una razón de diseño de systemd, no porque no sea portable. Hasta que el kernel BSD no cumpla con lo minimo para soportarlo, systemd no funcionará en esa plataforma y eso no es culpa de nadie, solo que BSD no tiene interes, ni Lennart tampoco. Asi de simple es. Ahora, el soporte a otras librerias C, es otra cosa, bien conocidos son los problemas de glibc (basta hacerse un kernel a mano para ver la cantidad de opciones y workarounds que se han hecho para evitar estos detalles sobre todo para glibc 2.3, 2.5 y 2.11, entre otras fallas que glibc ha arrastrado a lo largo de los años) pero la cosa no termina allí no termina la cosa, Lennart mismo ha dicho que ha preferido crearse su propia libreria libc, porque para su grupo eso es mucho más rapido hacerlo así, que andar leyendo codigo ya creado (y documentado por cierto), pero no se detiene allí, piensan sacar glibc, y usar su libc no solo para systemd, sino también para Fedora volviendolo estandar para la construcción de todos sus paquetes. NIH ¿Donde? Parece que el buen Lennart le gusta trollear y a lo grande.
4.- Que systemd no es monolitico porque está partido en 69 binarios. Si bueno, esto es discutible. systemd tiene 69 binarios, que hacen distintas tareas, pero esos binarios pasan la información de sus tareas a systemd, así que si uno falla, las probabilidades de romper el sistema, aumentan de forma bastante drastica. Esto está bien documentado, en los bugs reports abundan problemas como estos e incluso problemas más sencillos, estupidamente sencillos en realidad. systemd puede estar partido en cientos binarios, pero mientras su núcleo sea el que lleve el control, el riesgo de un break se mantiene y aumenta, y si no me creen, leanse los bugs reports y diviertanse.
Fijense que acá no he comentado nada de que systemd sea basura, solo he hecho comentarios meramente «técnicos» (obviamente hablar de tecnisimos la cosa se pone muy compleja) y válidos, respaldado por información facilmente accesible por internet. Ahora bien: ¿Qué Linux necesita un init estandar? Si ciertamente sería algo de gran valor para la comunidad. ¿Qué systemd es la solución? No, aunque está cerca, ciertamente tiene muchas cosas positivas, pero su expansión viral y la cantidad de cosas que hace aumentan el riesgo de lo que puede salir mal y terminar perjudicando a la comunidad.
PD: Les dejo material donde pueden corroborar lo que digo, leanlo les resultará bastante ilustrativo, y vean que no incluyo blogs ni nada por el estilo, pura critica personal y con base. Saludos.
http://lists.freedesktop.org/archives/systemd-devel/2014-June/019925.html
http://cgit.freedesktop.org/systemd/systemd/commit/?id=ce7b9f50c3fadbad22feeb28e4429ad9bee02bcc
http://lists.freedesktop.org/archives/systemd-devel/2013-November/014808.html
https://bugzilla.redhat.com/show_bug.cgi?id=1057883 (@elav tal vez te sientas identificado)
https://code.google.com/p/d-bus/source/browse/kdbus.txt
https://github.com/gregkh/kdbus
http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html
Amén hermano.. amén..
Sigo sin ver razones validas para no adoptar systemd. Simplemente interpretas lo que ves con miedo, resultando en exageraciones. Ni ventajas ni desventajas claras y bien definidas.
Ademas esa integracion permite la estandarizacion de la que incluso hablaste. No solo Red Hat trabaja en systemd, sino diferentes empresas y voluntarios de otras distribuciones.
Creo que el error es que no se estudia adecuadamente el funcionamiento de systemd.
Yo sí que veo razones válidas en el análisis de Yukiteru. Fíjate que en lugar de miedo yo veo rigor, precisión y claridad. Debe ser un tema de oculista.
No es miedo (no le tengo miedo a una pieza de código) y tampoco son exageraciones (todo lo que he dicho aca está documentado y he pasado bastante información que la corrobora, información que por cierto sale de las listas y de la mente/voz/puño/letra del propio Lennart, y no de los comentarios de un blogger), es LA REALIDAD.
systemd hace todo eso y mucho más, y eso es algo PREOCUPANTE (concepto distinto a tener miedo) porque ciertamente se toma atribuciones y hace cosas que en estos momentos se puede hacer por otros medios y que por cierto funcionan mejor y son más estables. systemd es muy Windows-like, y eso no se puede ocultar, solo basta conocer lo que userinit.exe, svchost.exe, smss.exe y demás dependencias hacen y compararlas con systemd, el parecido es tan grande que da mala espina. Ahora bien, ciertamente systemd puede tener una mejor calidad que su contraparte en Windows (o puede pasar lo contrario, nadie lo sabe en realidad, a no ser que programes para Microsoft) pero no me puedes acusar de EXAGERADO y MIEDOSO cuando lees al propio Lennart en una lista, hablando de crearse todo una nueva librería C, porque está harto de Glibc, y para ñapa, lanzar la pequeña e insignificante punta, de que esa libc pueda ser usada para contruir todos los paquetes de Fedora. Y si piensas que es una mentira y que soy exagerado te dejo el mensaje en este enlace: http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html (en ingles)
Ahora dime si es exagerado decir frente a todas estas cosas, que una vez que Linus decida que CONFIG_VT tal como está, tiene que salir del kernel (situación que lleva en la palestra bastante tiempo) y pasarlo a userspace, no suceda una cosa loca como que systemd-consoled sea dependencia fuerte para casi cualquier instalación de Linux (algo tiene que manejar las VT ¿No crees?), eso no pondría a distintas distros no-systemd en el punto de mira para forzarlar a cambiar. Si piensas que eso es exagerado, dejame decirte que no tienes ni idea de lo que Lennart es capaz de hacer y está haciendo, puesto que sus ultimos cambios afectan el desarrollo del fork de udev, eudev de Gentoo, y seguirá haciendolo con sus amenazas por debajo de la mesa (para despues quejarse como lo hizo en Google+)
@xiep no puedo estar más de acuerdo con tu comentario.
Che Yukiteru, tu extensa declaración omite el hecho que el mail que linkeaste sobre libc es una broma de april fools, mira el footnote y mira la fecha ( 31 de marzo, probablemente 1 de abril en el timezone de lennart)
Practicá tu english-fu porque hace aguas y pone en duda toda tu «investigación».
@juanfgs pareces el único que lee, al menos eso te lo aplaudo, pero te falto leer algo muy importante que está en mi comentario, no importa te lo pongo acá:
» NIH ¿Donde? Parece que el buen Lennart le gusta trollear y a lo grande.»
No creo que lo haya escrito por una razón inocente, conocía el hecho de que era otra broma del Lennart por April’s Fool Day (mal humor), al igual que su pasión por convertir /, /etc y todo lo demas en /Linux. 🙂
PD: Gracias pero no necesito practicar mi ingles, llevo con el idioma desde los 6 años
aaahh y todo lo demas es verdad, verificalo 🙂
Esto es sensacionalismo puro y duro, decis que te basas en hechos pero en realidad seguis tu corazonada de que el tipo es malo y quiere dominar el mundo y torcés los hechos para que reflejen tu discurso. Esto es lo que me molesta mucho de la gente anti-systemd, no tienen pelos en la lengua a la hora de torcer los hechos y contar medias verdades, cargadas de su opinión por supuesto.
Mi «rule of thumb» ante estos casos es simplemente el siguiente desglose lógico, partiendo de la premisa de que
– soy desarrollador web / apps de escritorio o cli
– no he escrito nunca un sistema de init.
– no soy mantenedor de una distro.
verificar si el interlocutor ha:
– creado un sistema de init
– es mantenedor activo del sistema de init de una distro
y la realidad es que la mayoría de los anti-systemd no pasan esta prueba, aún así son un puñado de gente que por algún motivo SABEN MÁS que la gente detrás : Debian, Fedora, Archlinux, el Kernel Linux, todo el proyecto GNOME, probablemente el proyecto KDE también ya que no se han quejado de systemd, SUSE, y un largo etc.
Aún así su discurso ponzoñoso y vitriólico lo unico que logra es generar desunión, problemas y demás. Tal es el punto de que no veo la hora de que finalmente se pasen a BSD como vienen amenazando desde Xorg, NetworkManager, PulseAudio y no se si por puro desconocimiento técnico o porque se quedarían sin que quejarse no lo hacen.
@juanfgs, le tomo la palabra específicamente en esto:
«y la realidad es que la mayoría de los anti-systemd no pasan esta prueba, aún así son un puñado de gente que por algún motivo SABEN MÁS que la gente detrás : Debian, Fedora, Archlinux, el Kernel Linux, todo el proyecto GNOME, probablemente el proyecto KDE también ya que no se han quejado de systemd, SUSE, y un largo etc.
Aún así su discurso ponzoñoso y vitriólico lo unico que logra es generar desunión, problemas y demás. Tal es el punto de que no veo la hora de que finalmente se pasen a BSD como vienen amenazando desde Xorg, NetworkManager, PulseAudio y no se si por puro desconocimiento técnico o porque se quedarían sin que quejarse no lo hacen.»
Entonces SEGÚN usted, todos los anti-systemd somos unos ponzoñosos y vitriólicos que lo único que logramos es desunión, problemas y demás. Déjeme decirle que esa es la barbaridad más grande que he podido leer por acá. Yo no sé porque se molestan los pro-systemd, cuando se le sacan a relucir los problemas estructurales de un sistema, que obviamente en algún momento les van a afectar, porque puede que no les haya pasado nada ahora, pero en algún momento, lo hará, y entonces algún anti-systemd les recordará las palabras que muchas veces dijeron y nadie les paro, y puede que algún otro anti-systemd les de una mano.
En lo personal, no me gusta systemd, pero eso no significa que no use el init, tengo que hacerlo, porque precisamente en mi trabajo si tengo que tocar alguna maquina con ese init, debo tener conocimiento de como manejarlo. Además en lo personal también lo he usado desde que llego a Archlinux e incluso en Debian y Gentoo, así que no me venga a decir que mi visión es sesgada por no hacer uso de systemd, yo le he usado, y se de que pata renquea, y si tengo que ayudar a alguien acá en el foro DesdeLinux o en IRC o la lista de Debian (que es la distro donde yo más tiempo he estado y aún uso en mi trabajo) lo haré con gusto, porque precisamente si algo me agrada de la comunidad Linux, es que pese a la diferencia siempre se ayuda.
Ahora de cambiarme a BSD, es posible, pero solo lo haré si systemd se vuelve algo tan virulento que no me permita hacer uso de alguna otra opción, mientras tanto me quedo en Linux, desactivando toda esa locura, incluyendo muchas de las cosas de Cgroups.
!=
Nuevamente torcés las palabras para que se acomoden a tu discurso. Sos muy buen material para político/periodista.
Aclaro, mi problema no es conque mencionen problemas técnicos de Systemd, el punto que es que muchas veces estan cargando su discurso con mentiras a saber de:
Que si systemd te va a obligar a usar un servidor microhttpd ( el cual es un modulo opcional NO instalado por defecto), que si systemd es un solo binario, que systemd va a ser cerrado porque a lennart le paga microsoft, que los logs binarios son obligatorios. Que nadie quiere a systemd y su adopción es por un lobby politico.
Eso es lo que choca, las mentiras. Si fuera una discusión razonable valdría la pena, pero es solo FUD del bueno.
Que no te guste me parece perfecto, a mi mucho software no me gusta, incluso lenguajes de programación, distros y demás, pero no invento cosas sobre eso ni soy obsecuente leyendo lo que quiero leer y cargando mis declaraciones con sentimientos personales para perjudicar la imagen de gente que lo desarrolla.
@juanfgs lo siento, pero yo no soy el que llama » ponzoñoso y vitriólico» a un determinado grupo de personas simplemente por no gustarles una pieza de software.
Nuevamente, torciendo frases para quedar como víctima.
@juanfgs nuevamente le digo, eso lo dijo usted, revise sus palabras, yo no ando tergiversando sus palabras, solo hice un copy/paste de sus palabras en el comentario 59.
Estoy citando mi comentario textual capo, el que tenés que leer de nuevo sos vos porque no querés comprender, o no sabés debatir. Vos sacas de contexto cosas y las interpretás como se te canta. Así que si querés elegir vivir en un mundo donde te sentis insultado porque rebaten tus argumentos, lennart, red hat y microsoft estan persiguiendote es porque vos elegís creer eso.
Corto acá porque me doy cuenta que no sos una persona razonable porque no querés entender, querés interpretar las cosas como a vos te parezca.
Si querés ofenderte ofendete, pero es tu problema no del resto del mundo.
@juanfgs no me molesto por tus comentarios, la verdad no veo razón, estamos discutiendo, la gente civilizada discute sin necesidad de molestarse por ello (eso es lo que pienso).
Ahora si a usted le gusta etiquetar, prejuzgar (o como quiera llamarlo) a la gente por sus discursos o acciones (tal vez deba leerse mi comentario el #64 y medir la amplitud del mismo), ese es su problema, limítese ha realizar esas acciones hacia usted mismo y deje a los demás fuera de ese saco.
Saludos.
«La mayoría de los anti-systemd», «casi todos», «todos», «alguna parte de los anti-systemd»… nos desviamos, Mariano, nos desviamos. En el caso que nos ocupa: Yo no veo por ningún lado que Yukiteru haya hecho un discurso sensacionalista y basado en corazonadas (referirse a su análisis de esta manera sí que tiene algo de retorcido), al contrario, ha desarrollado sólidos argumentos sobre los inconvenientes de systemd basándose en preguntas apropiadas y material extraído de listas de de correos y seguimientos de bugs (además de forma educada y civilizada). Posiblemente por ese motivo irrita a algunos y lo atacan al primer comentario, para desacreditarlo y descalificarlo (esta vez sí, de forma ponzoñosa).
Si tú ves que el discurso de la mayoría de los anti-systemd es ponzoñoso y vitriólico, yo lo que veo en el discurso de algunos pro-systemd (no sé si son mayoría o minoría) es histerismo y persecución de los que, precisamente, exponen sólidos argumentos entre tanto ruido. Eso en mi tierra lo llamamos hostigar la disidencia.
¿A usted le va bien systemd? Estupendo, me parece bárbaro, pero deje a los que no piensan lo mismo expresar sus reservas (tal vez no trabajen de la misma forma el sistema operativo).
Saludos
Ah por cierto ¿por que cualquier error de systemd es engrandecido hasta el punto de derrochar todo el componente, pero otros como GCC, glibc o incluso el kernel no han sido criticados hasta ese punto por muchos de sus errores?
Tu mismo lo has dicho, glibc arrastra problemas desde hace tiempo. Llvm con el tiempo ha demostrado tener ventajas respecto a GCC. Y aqui no veo la misma critica.
¿por que no hacer lo mismo con otros proyectos?
Simplemente es miedo colectivo e irracional para mi.
Glibc tiene sus fallos nadie puede ocultarlos, hay fallas enormes, de Glibc que afectan al kernel y a cientos de ejecutables. La diferencia entre Glibc y systemd, es que el primero es una base de la cual se pueden transforman MILES de proyectos de software en binarios, mientras que systemd es un init, cuyo fin es ser una pieza estable, probada y practicamente infalible. No solo eso, Glibc debe ajustarse a cientos de distintas arquitectura de hardware (CPU), a distintas flags de optimización y caracteristicas únicas del CPU, a distintas formas de optimización de software, un trabajo mucho más arduo y díficil que el de systemd, asi que no veo de verdad forma alguna de presentar a la misma escala una comparación entre ambos proyectos.
Lo mismo va para GCC, GCC es un compilador que por cierto soporta muchos lenguajes (13 en total contando los no oficiales), y tiene caracteristicas muy parecidas a Glibc, soportando muchas arquitecturas (70 arquitectruras para la version 4.9), flags de optimización binaria, flags de optimización por CPU, y muchas otras características. Ahora bien están al mismo nivel de dificultad, un compilador con un init. La respuesta es más que obvia, comenzando con que systemd está en C, y mucho del código de GCC está en assembler o tiene que usar assembler para que las cosas puedan funcionar en binario, algo un «poco dificl de hacer».
¿Qué tienen fallos GCC y Glibc? Claro. Hasta Linus les ha dado su ataque, pero en GCC y Glibc tienen algo positivo que en systemd se olvidan muchas veces, y es que, bug reportado, bug visto, bug arreglado.
– por favor que alguien me explique: ¿Por qué un init debe tener control de :
redes (systemd-networkd),
dns (systemd-networkd),
m-dns (systemd-networkd), l
ogs (journald),
coredumps (systemd-coredump),
debugs (systemd-coredump y journald),
acpi (logind), escalado de privilegios (logind),
ntp (systemd-timesyncd),
dev (systemd tomo toda la funcionalidad de udev),
de /dev/random (generador de numeros aleatorios)
TTY (systemd-consoled)?
Un tema 100000 repetido y repetido, lo que te falto decir es que systemd puede funcionar sin ellos, de hecho en debian no están ni la mitad de los que mencionas
igualmente solo es una característica de su amplio enfoque
lennart :Bueno, systemd divide lo que tiene que hacer en muchos componentes diferentes (90+ binarios estos días). Cada uno se corre con las menores privilegios posibles.
Me imagino que esto no es demasiada diferencia coreutils, que también tiene una gran cantidad de componentes en un solo paquete. Y coreutils probablemente es uno de los principales proyectos que hacen que Linux se siente como un sistema operativo similar a UNIX, ¿verdad?
Pero sí, systemd es más complejo que sysvinit, no hay duda. En los últimos 40 años de la computación muchas cosas cambiaron, y muchos de ellos en realidad requieren un cierto nivel de complejidad de tratar con ellos … Hay muy poca forma de evitar eso.
Porque no te pones así de intransigente con freebsd que hace exactamente lo mismo pero con sus herramientas y sin permitir que se usen otras, cosa que no es el caso de systemd.
– ¿Acaso ya no habían MUCHAS herramientas creadas para tales fines como para que systemd ahora sume las suyas algunas con acceso exclusivo (caso journald)?
No voy a negar que el tema de journal guarde la info en un binario es lo mas flojo de defender, pero no es el fin del mundo, se pueden guardar en texto plano
– ¿Qué explicación lógica y aceptable me da a que un init sea capaz de romper el debug y la cmdline del kernel?
Mmmmmmmmmmm…………………. romper el kernel……. 5000000 cosas pueden romper el kernel
– A eso sumenle el control sobre kdbus, el proximo IPC que será integrado al kernel.
Según lennart Esto tiene relación positiva para los desarrolladores y systemd va a traer herramientas para abrir dbus a los administradores, también les dará a journal y a networkd interfaces de bus
– Seguramente me dirán aca: “Pero te puedes instalar otra herramienta para controlar todo eso”. Y si es cierto, pero, muchas de esas herramientas solo reciben un stream de datos arrojado por systemd, como el caso de syslog y rsyslog, ….. eso solo significa que tienes dos herramientas que hacen lo mismo, y una de ellas es una caja de pandora. (Por favor que no me digan que el código se puede auditar, porque invito a que alguien pueda “fumarse” el código de journald y su entramado con systemd y demás herramientas relacionadas)
acá entramos en la teoría de la conspiración !!!!! es software libre flaco no se oculta nada
3.- ¿Qué systemd no es portable? Es otro punto discutible. En BSD no funciona pues bueno, en BSD no existe Cgroups entre otras herramientas que systemd necesita para su ejecución. Pero es por una razón de diseño de systemd, no porque no sea portable. Hasta que el kernel BSD no cumpla con lo minimo para soportarlo, systemd no funcionará en esa plataforma y eso no es culpa de nadie, solo que BSD no tiene interes, ni Lennart tampoco.
Bueno eso no es del todo correcto, los desarrolladores de bsd de hacer algo parecido a systemd cosa que el propio lennart destaco en su cuenta de g+
https://plus.google.com/115547683951727699051/posts/g78piqXsbKG
https://www.youtube.com/watch?v=Mri66Uz6-8Y
4.- Que systemd no es monolitico porque está partido en 69 binarios. Si bueno, esto es discutible. systemd tiene 69 binarios, que hacen distintas tareas, pero esos binarios pasan la información de sus tareas a systemd, así que si uno falla, las probabilidades de romper el sistema, aumentan de forma bastante drastica. Esto está bien documentado, en los bugs reports abundan problemas como estos e incluso problemas más sencillos, estupidamente sencillos en realidad. systemd puede estar partido en cientos binarios, pero mientras su núcleo sea el que lleve el control, el riesgo de un break se mantiene y aumenta, y si no me creen, leanse los bugs reports y diviertanse.
Si estas usando sysvinit y se te rompe TTY dev acpi ntp se te rompe el sistema también, no siembres el terror.
Monolítico es freebsd y no decís nada
@rolo
Ahora enumérame cuales son las distros que tomaron systemd y crearon esos 90 binarios en paquetes separados, serían 91 paquetes con systemd.
Y que al instalar systemd no me pida ninguno de esos 90 paquetes como dependencias.
En serio, y nuevamente insisto….por favor pásame las opciones del –configure-help que quiero hacerme 91 paquetes compilando a mano con make.
No hay peor ciego que el que no quiere ver…muchachos esto es el agua y el aceite, parece que aún hay gente testaruda que no ve la realidad de lo que persigue redhat.
@rolo yo quiero que te instales systemd y aparte le quites journald, systemd-udev y coredump, y uses opciones com eudev y syslog directamente, a ver si podes.
No me pudo dar mas risa este comentario en serio, estoy que me muero. 😀
Ya en serio, en verdad se toman la molestia de leer un poco, en lugar de seguir con la viga en el ojo.
Además que nadie se olvida que Kay Sievers, no solo rompio el cmdline del kernel, sino que quería callarlo, despues de todo «genérico es genérico».
O sea, que según tú, el hecho de que dos procesos se pasen información los hace tan acoplados que el hecho de que uno falle hace que el otro tenga altas probabilidades de fallar… ¿de qué teoría de desarrollo de software sacaste eso? Estoy de acuerdo con @pamp de que hablas desde el miedo irracional y sesgado.
Y tu otra gran interrogante, ¿por qué systemd tiene que controlar tantas cosas? Respuesta sencilla: porque con sysvinit y todos los demás init se están desaprovechando ventajas introducidas recientemente en el kernel Linux que mientras nadie las ponga en uso en espacio de usuario están ahí «mosqueadas» (como decimos en Cuba… vaya, desperdiciándose) sin que nadie las use y dan buenísimas ventajas en el uso eficiente de recursos de hardware (CPU, RAM, I/O, etc.) entre ellas cgroups. Lo que hace systemd es, precisamente, poner estas buenas funcionalidades el núcleo Linux al servicio del usuario, pero para eso necesita ser él quien inicie a esos demonios.
Creo que leiste y analizaste mal (analizar es importante) o simplemente ni siquiera te diste la oportunidad de hacer eso. Que dos procesos se pasen información no es razón para que quiebre un sistema, sin embargo, cuando tienes binarios con acción dinámica como control de red, logs o coredump, pasando informacion directamente al init, las cosas pueden ir mal e irán mal, porque si unos de los binarios se quiebra las probabilidades de quebrar al resto son mucho mayores, y eso es algo bastante realista, y ha pasado, el quiebre del cmdline del kernel recientemente, los problemas con acpi que los devs de Nvidia tuvieron gracias a systemd-212, todo eso es una muestra de lo que digo.
@Dariem
Si no se puede compilar cada uno de esos binarios en paquetes individuales, estás forzando a que por querer uno instalado, tienes que instalarte todos, al instalarlos a todos resulta que te pisa otros paquetes que no se podrán instalar porque estan las partes de systemd ocupando esos lugares.
Que sentido tiene partir un ejecutable grande en varios ejecutables mas pequeños si al final no tenes un paquete por cada uno que te permita instalarlos individualmente.
Vuelvo a hacer el pedido general a todo usuario avanzado de systemd, que me diga como compilar esos 90 modulos y crearme 90 paquetes que si se me dan las ganas los instalo y sino uso los programas que venia usando.
Muy mala leche todo esto….pareciera que al gente de systemd nos cree tontos a todos los usuarios de gnu/linux.
Que conste, uso gentoo testing y hace unos meses me habia cambiado a systemd y no pude con journald, eso me hizo regresar a openrc mas rápido que lo que demore en pasarme a systemd.
Para seguir viendo como va la cosa con systemd tengo archlinux en una notebook que pronto pasere a gentoo….estable seguramente.
@anonimo, yo solo quiero ver como va a evolucionar el tema de las TTY en Linux. Cuando el código de CONFIG_VT salga, a favor de dividir VT en dos partes bien diferenciadas (kernelspace y userspace) vamos a necesitar alguna herramienta para controlar las VT desde userspace y allí systemd-consoled puede jugar en ser una dependencia fuerte que hale al resto de las distros a la necesidad de tener que instalar los componentes de systemd, tan solo para hacer posible que el sistema pueda funcionar. Esto que digo no es una exageración, es una posibiidad muy, muy grande, y realmente preocupante. Hay otros proyectos, como KMSCon, pero si la mayoria de los escritorios y distros se van en favor de systemd, cosas como KMSCon pueden morir más rápido de lo que muchos piensan.
@Yukiteru 3 diciembre, 2014 8:49 PM
Yo no le tengo miedo a eso, don Linus no va a quitar las opciones por defecto de una versión para otra, pondrá el nuevo sistema como NEW y permitira elegir entre lo de siempre y lo nuevo.
Respecto a la parte del userspace, se podrá hacer un paquete que haga eso de forma independiente, si lo hace systemd, porque no lo podrían hacer otros 50 mas?, es mas, las distintas maneras de hacerlo va a hacer que las distintas terminales adopten diferentes maneras todas con USEs para activar y desactivar como ya estamos acostumbrados.
Lo mismo va para kdbus, que Linus lo admita en el 3.19 como se esta diciendo, no quiere decir que uno lo va a tener que tener activo si o si.
Soy muy feliz con openbox+compton, los escritorios por mi pueden ir desapareciendo que no me estan por afectar en lo mas mínimo.
@anonimo la cuestión es que quitar CONFIG_VT es algo que al final será total (por lo que he leido), es decir, en el kernel solo quedaran las primitivas, mientras que el resto de la herramientas estarán en userspace, esto no es malo, al contrario le quitara un monton de código viejo al kernel, lo hará más sencillo de mantener, y mucho más configurable (soporte completo KMS/DRM para consola). Ciertamente al principio, estarán los dos sistemas, pero en el largo plazo (15-20 lanzamientos) posiblemente salga del kernel, o incluso antes, muchas herramientas ya no soporten dicho código en favor de código más nuevo y con mejor soporte.
Ahora bien, tu dices que si lo hace systemd, porque no lo pueden hacer 50 más (imagino 50 aplicaciones más). Pues bien, si vemos las dependencias fuertes de KMSCon (el proyecto más viejo en este sentido) son libudev (código que será unido a systemd proximamente, no será soportado y tendrá conflicto con systemd si funciona por cuenta propia), libdrm, libxkbcommon, libtsm y el propio systemd para manejar multi-seat, entonces cuando ves esto, te das cuenta como la cosa va tomando forma en tomarse para si nada más, un montón de herramientas necesarias para que un SO GNU/Linux funcione sin problemas.
@Yukiteru 3 diciembre, 2014 9:46 PM
Aquí en gentoo libudev es un virtual apuntando a sys-fs/eudev, así que la gente de gentoo se encargará de modificar eudev para cumplir con la API que dicte el nuevo sistema en el núcleo.
Por eso creo que las distros que no sean systemd (hola devuan) usarán si o si eudev.
Va a pasar lo que paso con el udev original, systemd se lo engulló, pero aquí el núcleo es el que dicta la API para hacer de interface con las consolas usando DRM/KMS….ya quisera ver una urxvt usando esto…jeje
Lo que si te acepto es que el que este usando systemd, no va a tener opción a cambiar nada…imposición plena y dura y como dije antes…a llorar al cementerio.
@anonimo ciertamente lo que dices es la otra posibilidad, eudev tomará mayor fuerza en este sentido y mantendrá abiertas las opciones a elegir distintas herramientas.
PD: Como dices sería interesante ver como como las VT toman las ventajas de KMS/DRM junto con fbdev 😀
Has repetido exactamente el concepto que te critiqué, porque en ningún momento hablé de sistema, hablé de comunicación entre procesos, y vuelvo repetir, ¿de dónde sacas que porque dos procesos se comuniquen, la muerte de uno implica que el otro tiene amplias posibilidades de morir? Explícame cómo dos procesos, que residen en espacios de memoria separados, pueden incidir mutuamente uno en el comportamiento interno del otro. A ver si me explico, desde el punto de vista de uno de estos procesos, él solo está accediendo a un mecanismo IPC (el que sea que se definió para comunicar a los procesos de systemd). Si el programador fue tan malo para no incluir código que pueda lidiar con entrada y salida no esperada, eso es otra cosa, pero no tiene nada que ver con que un procesos influya en el funcionamiento interno de otro. Si systemd-networkd se cae, no tiene por qué tumbar ni a journald, ni a systemd, como mismo con el viejo sysvinit el hecho de que se caiga inetd no debería afectarlo, son procesos separados.
@dariem paso a explicar de forma sencilla a ver si coges la idea:
Eso que dices ciertamente es el comportamiento que siempre se espera de los programas y procesos modulares. La modularidad fue implementada con ese fin, el de separar dos procesos y que estos ocupen sus propios espacios de memoria, y que se comuniquen por algún medio (IPC, etc), para que en caso de que algo vaya mal, entonces nada malo pase y el sistema pueda seguir funcionando sin interrupción. Una teoría que ciertamente ha tenido gran apoyo debido a su potencialidad y al inmenso margen de confiabilidad que le ha dado a la computación actual. Ahora bien, esto no siempre se cumple (la vida no siempre es bella), y creo que seguramente has sido victima de estos sucesos en una u otra ocasión (esto seguramente va para todos sin importar el SO que use), y voy a dar un par de ejemplos.
El primero va con Xorg (que es un proceso modular tal cual systemd), que a veces le da la locura con algún driver y simplemente crashea y te deja sin gráficos, mientras que el resto del sistema sigue funcionando tal como se espera (Bendita modularidad 😀 ). Hasta aquí todo bien, nuestra teoria de que los procesos modulares no tiene que romper el sistema va bien. Pero (siempre hay algún pero) a veces a Xorg le da algo más que locura y por alguna razón extraña (que puede ir desde el control del ratón hasta el driver gráfico) no solamente se crashea Xorg, sino que tambien te da el más hermoso de los kernel panic (y una pintada en el monitor cual Picasso) que puedas imaginar, y entonces te das cuenta, que sin importar que tan modular sea, si un proceso se intercomunica e intercambia información/datos con otro, y algo sale mal en uno de ellos, y por alguna razón, no se puede manejar el error de forma correcta, las probabilidades de que los procesos en cuestión se vean afectados aumenta, por el simple hecho de que los datos son erroneos o simplemente son corruptos, y entonces viene la catastrofe.
Si piensa que esto no puede pasar, le dejo unos bugs reports (uno es mio en Debian y tiene par de fotografías) de un error viejo que está en Xorg, mesa, nouveau y el driver drm/kms del kernel, procesos que a pesar de ejecutarse **separados y ser modulares**, juntos no se llevan muy bien, al menos no bajo esas circunstancias.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742930
https://bugzilla.redhat.com/show_bug.cgi?id=901816
https://bugzilla.redhat.com/show_bug.cgi?id=679619
Ahora el otro ejemplo se lo voy a dar con systemd. Nuestro viejo Sysvinit tenía una peculariedad de que pese a ser viejo, era muy confiable, hasta el punto en que si tu /etc/fstab tenía una entrada de una partición (no importante para el sistema, entiendase un /mnt/Disco160GB) y está no podía montarse por alguna razón, simplemente el montaje se omitía, te daba un mensaje de advertencia, y seguía con el proceso de booteo. Ahora bien, systemd es otro cantar, pese a su modularidad, si tienes una entrada en /etc/fstab y systemd por alguna razón ve que es imposible montarla, no solo se queda esperando a que la partición este disponible (el comportamiento normal programado) para su montaje, sino que si el tiempo termina, tu sistema queda detenido y no puedes hacer nada más que entrar a modo recovery y sacar esa línea del /etc/fstab, algo bastante fail en realidad. Ese detallito no más durante el automontaje en el boot, y todo el proceso se detiene, en un principio (systemd-) el detallito era más feo, porque simplemente te aparecia el dump y tenias que reiniciar. Te lo dice alguien que paso por el detallito.
Otro ejemplo que puedo dar es coredumpd en systemd. coredumpd por defecto pasa toda su información a journald con el fin de que este ultimo escriba en disco la información captada, hasta aqui todo bien, estamos usando la modularidad de systemd a nuestro favor. Pero pasa en ocasiones, en que los coredumps son muy grandes, simplemente tan grandes, que pueden ocuparte varios GB, y en el proceso de pasar información desde coredump a journald y luego al disco, pasan cosas tan extrañas como que Xorg deje de funcionar e incluso kernel panics. Eso no solo pasa con systemd claro está, pero la forma en como está diseñado, aumenta el factor de fallo y crea otros detalles desagradables (entre ellos el aumento de consumo de memoria, corrupción de logs, dumps incompletos), quien haya tenido que trabajar con un coredump de KDE, seguramente ha pasado por varios episodios como estos, y habrá entendido la importancia de tener la opción sync en el /etc/fstab para su partición de vaciado, y seguramente odiará el hecho de que no pueda usar alguna otra opción para manejar los dumps, si tiene systemd instalado. Un ejemplo de lo que puede pasar con systemd-coredumpd.
https://bugs.archlinux.org/task/41728
Ahora bien, para culminar:
¿No se supone que son programas y procesos modulares?. Si, son modulares. El kernel es lo único monolítico de lo que he hablado acá, pero, este acepta modulos tambíen (LKM), por lo que vendría a ser, una especie de kernel híbrido aunque su forma de diseño base no está pensada en ese tipo de estructura, y eso lo hace un poco inestable bajo ciertas circunstancias.
¿Qué la modularidad no debería permitirme hacer que mis procesos y mi sistema no se rompan si algo sale mal? Es cierto, la modularidad es una medida pensada en conseguir un alto grado de estabilidad y confiabilidad, pero no es una medida 100% infalible, porque si algo puede salir mal, simplemente saldrá mal, por muy modular que sea, esa una realidad.
¿Qué systemd tiene que tener control de todo para hacer posible el uso de cgroups y demás opciones agregadas al kernel? Completamente falso. Eso no es necesario del todo, systemd se pudo haber quedado con una interfaz para controlar el arranque y asignación de cgroups a los procesos y demonios que estarán en el sistema, sin necesidad de adueñarse de la cantidad de servicios que ahora tiene, y el mejor ejemplo de eso es; que OpenRC también es capaz de usar cgroups y no por ello es tan invansivo para llevar a cabo esa tarea.
¿Qué soy sesgado y dado al miedo cuando hablo de systemd? No tengo ni idea de donde saca eso, porque como ve mi respuesta no tengo miedo de eso, solo hablo de aspectos que no me gustan de systemd y ya, sin basarme en las opiniones de terceros.
Por útimo, usted dice que: «Si el programador fue tan malo para no incluir código que pueda lidiar con entrada y salida no esperada, eso es otra cosa…»
Ciertamente decir que el programador por no incluir un código que maneje TODAS las formas posibles en que su programa pueda romperse por alguna entrada de datos erronea, es MALO, me parece una barbaridad. Por muy buen programador que sea, una persona es incapaz de diseñar un programa infalible y a prueba de fallos, SIEMPRE habrá un fallo, que de una u otra manera saldrá a la luz, y cuando lo haga, será gracias a un fallo aleatorio durante su uso, por algún hacker o cracker explotando alguna vulnerabilidad, por una revisión y auditoria de código o por algún otro medio con el que el programador pueda contar. Es mejor medir las palabras antes de decir, una cosa como esa.
Saludos.
El ejemplo que pones de Xorg es el menos apropiado pues todo el que haya sufrido la transición a KMS/DRM sabe que el problema viene dado por bugs en los módulos del kernel para controlar KMS que proveen los desarrolladores de los drivers de Xorg. Un bug en un módulo KMS es igual a un kernel panic, no tiene nada que ver con comunicación entre procesos, pues en ese caso es Xorg realizando una llamada al sistema (syscall) para que el kernel cambie de modo de pantalla, es decir, hay un solo proceso involucrado (Xorg) llamando al kernel, nada que ver con lo que estamos tratando aquí.
Lo del comportamiento actual de systemd al no encontrar el punto de montaje no viene al caso independientemente de que es una funcionalidad que a alguien puede no gustarle, eso se resuelve pidiendo que soporten el otro comportamiento, el de que ignore el montaje fallido. El coredump que ocurría antes pudo deberse a disímiles causas de las que solo se podría especular, pero el hecho de que la ejecución no continuara puedo deberse a un comportamiento deseado, ya que dices que había que reiniciar, no que hubo un kernel panic o un reinicio automático. Como no he pasado por eso no puedo dar una opinión.
Sobre el problema que me pones con systemd-coredumpd y el enlace al reporte de bug, todo apunta a que ese problema en Arch Linux fue debido a la compresión le habilitaron a systemd cuando lo compilaron para esa distribución. Más parece un problema del algoritmo de compresión que de systemd en sí. El sistema operativo no se crashea, sino que el algoritmo de compresión utilizado para almacenar los coredumps parece estar dejando al sistema sin recursos y eso es culpa de los desarrolladores de Arch Linux que compilaron systemd. De todas formas, systemd tiene configuraciones para limitar el consumo de recursos y habilitar/deshabilitar la captura de todos los coredumps que reportar el kernel. Quizás los mantenedores de systemd en Arch y los que usan KDE deberían echarles un vistazo.
Dices que OpenRC también usa cgroups sin ser invasivo. El problema está en lo siguiente: ¿cómo OpenRC reconoce el nombre de los ejecutables de los demonios para saber exactamente qué asignación de recursos es la más adecuada? En realidad no estoy seguro de si esta es una de las causas por la cual systemd se hace cargo de tantas cosas, asignando un nombre bien conocido a los ejecutables, pero sospecho que la cosa va por ahí. Además, elimina la carga que representa tener a dash por el medio para correr cada uno de esos servicios, al invocar directamente a los ejecutables.
No voy a negar de que systemd puede tener muchos bugs, pero de ahí a achacar todos ellos a la forma en que está concebido, no lo creo. En el caso de sysvinit, era superestable, una pieza de software madura, systemd apenas está empezando.
https://www.reddit.com/r/LinuxActionShow/comments/2nv4hp/ask_lennart_poettering_a_question/
Como revientan las pelotas con systemD, xD Si tanto lo odian creen su propia distro, que para eso es software Libre é_é
No se trata de odio, se trata de defender a tu comunidad.
Por cierto si existen distribuciones «underground» independientes:
http://gutl.jovenclub.cu/neonatox-un-linux-iconoclasta
Respetos
porque comparar todo con microsoft que eso se comporta como un windows.. si las cosas funcionan bien y es para el desarrollo y evolución de linux cual es el problema … todo proyecto en su inicio pueden tener cambios errores si los programas software etc fueran perfectos, somos humanos mas nada por eso tenemos errores..
que si falla systemd se peta el sistema.. y si falla el kernel, xorg, grub.. hay personas que actualizando el kernel en su pc o laptop se les queda el sistema… entonces porque la insistencia en la perfección de algo…..
como si algún sistema que halla salido no hubiese tenido errores bugs o x cosa en sus inicios o inclusive ya en su madures tener fallas
Systemd se impuso como estándar con juego sucio, es dependencia obligatoria para muchos paquetes debido a que muchos programas fueron absorbidos por systemd ya sea porque ellos mismos los mantenían o por que los eliminaron lentamente al ya no ser relevantes por que systemd ya proveía algo similar.
Esto limita la libertad de elección, es decir las distros no pueden optar por NO usar systemd, pueden tratar de resistirse como gentoo, pero eso es más bien una solución temporal a systemd, openrc es solo un service manager apoyado en sysv para init y en los initscripts de la distro, systemd provee más funcionalidades que openrc y cada día tiene una nueva funcionalidad. El software nuevo se apoya systemd y exige implementar algo similar lo que termina volviendo más complejos a los otros inits y mas parecido a systemd que es lo que no se quiere.
Systemd hace muchas cosas comparado con el antiguo init que simplemente leía un par de líneas de /etc/inittab para luego ir cargando según el runlevel cada uno de los initscripts y sus configuraciones. El enfoque antiguo era mucho más sencillo e independiente. Estamos una etapa de transición hacia una nueva era de homogeneidad, no hay solución, la forma de imponerse que tiene es imparable.
En unos años no va a haber practicamente diferencia entre usar debian , usar arch o fedora, se perdera la identidad de cada distro si seguimos asi y systemd se volvera cada dia mas intrusivo que hasta pasara a formar parte del nombre del sistema (systemd/gnu/linux)
LOL
A llorar a la iglesia >:D
Qué dice Don KZKG, le dejo esto: https://blog.desdelinux.net/systemd-vs-inteligencia/#comment-127648
El problema es que sos argentino(yo tambien) pero es realmente preocupante la forma de expresarse que tienen la mayoria de los linuxeros argentinos que leo, aunque tambien se dice que el mundo del software libre atrae a cierta gente. Lo que rescato es que no presumis de ser argentino, pero se nota a leguas por desgracia.
uyyuyy.. ese muchacho cayó con artilleria pesada..
contundente el comentario!!
Juju.. ..pochoclos.. xD
Del tal artículo se desprende que lo único que hacen es «imponer» un sistema. No entro a valorar si es mejor (que no lo es), ni peor. Lo que digo, repito, recalco y remarco, es que no me da la real gana de que me impongan nada.
Frases como: «Simplemente no los usamos para el proceso de arranque, porque creemos que no son la mejor herramienta para ese propósito específico».
Y quién eeres Tú para decirme si quiero usar tal o cual herramienta?.
Allá cada cual. Yo simplemente, no lo uso y punto, y mientras pueda no hacerlo, no lo haré.
Fdo. Un Talibán.
(Es que me ha hecho gracia la payasada)
menudo dolor de cabeza con ese tema!!!! X_X
Estaba administrando servers con Centos 6 y pasar al 7 con systemd no me costó nada, no lloren, la vida sigue.
Con perdón, pero estoy leyendo mucha cosas que me recuerdan a la discursión clásica de «servidor windows – Hombre certificado VS servidor linux – Hombre openSource».
1º – Veréis, si fuerzas un error es normal que falle. Todos y cada uno de los vídeos que he visto son forzados de errores.Es como si hago un programa que alimente de palabras clave el log de syslog y a la vez trato de ejecutar un script a base de grep para sacar información de log… claro que va a fallar, yo lo he provocado.
Es como echar azucar a un motor diesel y decir «Mirad… es mejor el de gasolina!!!» o como hacen los de windows, escribir mal un fichero de configuración y quejarse de que no arranca el demonio diciendo «con windows esto no pasa».
2º – Que systemd incorpora muchas cosas que a lo mejor no vas a usar? Bien cual es el problema? Es que es el mismo argumento vacío que usan los de windows contra los de linux… «Para que quiero yo un texto plano donde poner mil y una opciones cuando no las vas a usar».
Todavia escucho a los de IBM con sus programas moniliticos ladrar hace años sobre mysql cuando leo algunas cosas. Yo agradezco y aplaudo la diversidad de GNU/Linux y de su comunidad. Si me das 50 formas de hacer algo, elegiré en cada momento la que mejor me funcione o se adapte a lo que necesito. ¿En serio que veis un problema en esto?
3º – Por el nivel de las conversaciones, deduzco que tenéis nivel suficiente para trabajar con cualquier distribución o montaros la vuestra propia y mantenerla vosotros mismos. ¿Para que queréis poner systemd y quitarle cosas? ¿No es mas facil seguir con vuestra init o openRC?
A la gente que me ha pedido que les enseñe las bases de linux les digo siempre lo mismo… GNU/LINUX no es WINDOWS, no intentes hacer las mismas cosas ni penseis como si lo fuese. ¿Por que asimilais que sistemd es igual a initd o que funciona igual? ¿No es mas sencillo asimilar el funcionamiento de systemd y usar su potencial, que intentar que funciones como init o OpenRC ? Es que es normal que no os guste.
4º – ¿Que hay de malo en la complejidad? Seguro que os acordáis todavía cuando dabais programación lineal y que seguramente en algún momento dijisteis… «¿Y para que quiero aprender a trabajar en objetos si ahora puedo hacer de todo y a demás ya me dejan usar el go to?» … (el facepalm un par de meses despues es grande si xD)
Seamos claros. Los init actuales (E incluyo systemd) tienen muchas carencias que solo se pueden suplir añadiendo complejidad. No hay otra, ya que para que un sistema interconexo crezca, ha de crecer en complejidad a riesgo de tener alguna parte debil, pero es mejor que quedarse estanco.
Hace falta recorrer mucho camino y si… sistemd no es la solución a todo. Pero tampoco lo es quedarse con SysVinit.
PD: Notese la ironia de que he usado el pc de mi compañero «aferrimo defensor de windows-server» para que de paso lo lea. xD
Solo una cosa, a los defensores de otros INIT que dan datos tecnicos y enlaces… CHAPO!!! Me encanta ver argumentos y datos así. Solo un apunte, los datos anteriores a octubre del 2014 son meramente historicos.
Muchas cosas que se comentan ya han sido arregladas y muchos bancos de pruebas publicados en el 2013 ya han sido revisados.
@rolo
Si es cierto, si viste el video, cosa que NO hiciste, se ve que el log es de 8MB, nada mas y asi y todo se corrompe, por cierto, podes enviar la salida de journald a syslog en texto plano? si, pero aun asi si tocas los log creados por journald, pasa eso, se cuelga el sistema y, es entendible, a ver, journal cuelga de PID1 junto con cosas tan complejas como systemd, falla, se ve que no tiene alguna parte de codigo que no permita la edicion por algo que no sea el mismo PID de journald asi como tampoco tiene la capacidad de seguir escribiendo mas alla de que sea corrompido el log, lo que demuestra que ademas de que piensa en modo windows, LP es mal programador.
No me digas que sera solo en centos, la version mas estable de las distro que usan systemd, clon de RHEL7, y no ni reporte ni pienso reportar el error.
La verdad es que cuanto mas leo los comentarios pro systemd, me doy cuenta de que realmente son como una religion, o estas a favor o sos el enemigo, pero, de esas religiones tipo ISIL, los del estado islamico, totalmente extremistas, de hecho, lo se por experiencia, los systemd lovers, piensan asi, o estas con ellos o sos el enemigo. Eso es lo que promueve Lennart con su soberbia y por favor, no me jodan con que Linus lo apoya, systemd no era esto, NO LO ERA, yo usé systemd apenas salio en Fedora 15 y era solo un init mas rapido, no reemplazaba la modularidad de GNU/Linux.
Si yo mato rsyslog, corrompo sus log o reemplazo el mismo por un dibujo, nada mas, solo que me quedo sin log, nada se cuelga, el sistema no se ve afectado.
@Rafael Mardojai
Eso hace Devuan, eso hizo Void Linux y otras que se mantienen lejos de systemd.
@Yukiteru
Seguro nadie te lee, como me dicen taliban, a vos no te leen porque usas windows o comentaste desde el y porque creo que pocos de los systemd lovers, entienden la parte tecnica de lo que decis y ahi radica el problema.
======
La verdad, sigo pensando en que una persona conocida alla por el 2006 tenia razon en algo:
«No quiero que la gente use linux ni que lo conozca, estos de Ubuntu me tienen las balls llenas»
yo- «Por?»
«Cuando algo se hace conocido y para las masas, se caga, se jode, y hay muestras a montones de ello»
yo- «como cuales?»
«mira lo que le paso a Debian, ahora tiene un hijo tonto llamado Ubuntu y acordate en algunos años vamos a tener «hackers» y «geeks» que mamaron Ubuntu y no van a saber distinguir Ext3 de NTFS»
Algo de razon tenia…. systemd triunfa entre los que saben, como dice Allan McRae, porque no le importa como inicia su maquina, para el es, boton, magia y tengo prompt. Entre los que no les interesa mas que «funcione» con lindas features, total, para servidor usan LFS o Gentoo o BSD realmente y luego los que lo aman porque enciende mas rapido su PC con luces de colores, sonidos hermosos y juegos de azar, pero no saben que es una syscall.
@SynFlag si no leen es por decision de ellos mismos, en cuanto al SO que uso, si estoy en mi trabajo y comento desde una PC con Windows, es porque es lo unico que tengo a la mano, salvo el servidor que esta en Debian Wheezy y obviamente desde el servidor no puedo comentar aca.
Incluso en mi casa me he visto obligado a usar el PC de mi hermana porque mi PC ha muerto (la MB y la fuente de poder conspiraron contra mi), y aun asi cuando tengo tiempo, me monto un LiveCD y uso Sabayon (con OpenRC) para comentar aca, como estoy haciendo justo mientras escribo estas palabras.
Ahora bien, si me dicen o piensan que soy un taliban anti-systemd eso me da igual. Como ya dije, he usado systemd y se de que pata renquea, no solo eso, suelo leer mucho la lista de systemd para enterarme de las cosas que vienen en nuevas versiones, y tambien para estar al tanto de los cambios que se realizan y de las discusiones que alli se llevan. Ahora si algun amante de systemd entiende el aspecto tecnico de lo que hablo y pongo en mis enlaces (los enlaces al repo git de systemd mayormente), y aun asi es incapaz de ver la realidad, eso solo me permite pensar que la venda en sus ojos y el extremismo en su forma de ver/pensar/sentir/amar/glorificar/enaltecer/adorar systemd es tan grande que no importa si incluso el mismo Linus le da una patada por el **** a systemd, ellos seguiran atrincherados en sus ideas de que estan en lo correcto.
Hola! no soy muy experto, y me gustaria saber para que sirve este «systemd» y porque se esta hablando tanto de el, cual es el problema y que alternativa hay? gracias
Cojonudo el comentario SynFlag! Estoy de «geeks», «frikis» y «linuxeros de pro» hasta las mismisimas.
Y ese es el futuro que nos espera; Ubuntu hasta en la sopa; portátiles con Linux para sólo acceder a Steam y jugar al último jueguito de moda. Y legiones de frikis enteradillos que no saben de que va la vaina.
Postdata: el concepto de fondo de systemd es una mierda.
los botones del adk y del foro no se ven en la pagina principal
Así que según @SynFlag ahora todo el que no es anti-systemd es un n00b, fanático religioso extremista, y la peste que corrompe GNU/Linux. Con una opinión tan estrecha como esta no sé si vale la pena debatir sobre este tema. Mejor dejar que el agua corra y a la larga pasará lo que tenga que pasar.
es verdad, llega un punto que no se puede discutir mas. solo el tiempo nos dirá si sytemd va a ser algo positivo para el mundo del software libre o no.
igualmente me da la idea que si esta distribución basada en debian que no va a usar systemd llega a concretarse, va a colaborar en apaciguar los ánimos de aquellos que no quieren saber nada con systemd.
como cuando apareció gnome 3 y se armo una resistencia tremenda, hasta que aparecieron los «fork» cinnamon y unity permitiendo seguir usando las aplicaciones de gnome en un escritorio con mas configuraciones y un diseño mas pensado para el pc y no tanto para lo táctil
Tal vez ese, Rolo (la aparición de Devuan), puede ser un punto de consenso. Creo que todos lo necesitamos para contener un ambiente de discusión polarizado y belicoso. Devuan será un espacio para la creación y la continuidad de una manera de hacer y eso ayudará a calmar los ánimos. El proceso que hemos vivido en Debian ha sido doloroso, sin embargo debemos asumir la situación, no hay más remedio que aceptar la separación. Esto acaba siendo un poco como los divorcios. Éste fork puede ser un trasunto de tratado de paz y un punto y a parte. Existían alternativas, claro está, Slackware, Gentoo, Funtoo, Crux, PCLinux OS, ahora Manjaro (por enumerar algunas)… pero la escena «deb» requería de una alternativa sin systemd. Parece claro que nadie va a convencer a nadie, los argumentos están sobre la mesa y no hay consenso (a pesar de que systemd tienen buenas ideas y de que los peligros que este software conlleva son evidentes). Es tiempo de forks y de que se obtenga libertad para el usuario (porque esto se trata de Software Libre, ¿no?).
Un factor que ha influido en el proceso ha sido la sensación de «decepción» por parte de algunos de los que depositamos la confianza en Debian. Por eso Devuan se plantea como un fork y no una derivada. Hay tensión porque a nadie le gusta qué ha ocurrido; ni a los pro-systemd (de ahí ciertos ataques furibundos intentando difamar) ni a los anti-systemd (que han apostado por el fork). En el ambiente está el «¿cuánto talento podemos estar perdiendo?», tanto por una parte como por la otra.
Todos los usuarios de Debian contemplamos la distro de «una» cierta manera (esto puede aplicarse a las otras distribuciones también). Hay quién admira su calidad técnica, otros sus contrato social, su influencia en el mundo Linux, el respeto que ha cosechado con los años, su estabilidad en los entornos productivos críticos… En algunos usuarios esta percepción se ha alterado, apareciendo la decepción. La desilusión, el desencanto, llámenlo como quieran. De ahí a la separación sólo hay un pasito.
El divorcio de Debian se parece a lo acontecido con NetBSD y OpenBSD. Aunque el tiempo lo dirá. Veo muchas expectativas en el fork y eso me hace pensar que no será una distribución fugaz y estéril . Hoy mismo había un miembro del equipo de gnome comentando en la lista de distribución de Devuan (a pesar de que lo ha hecho con cierta torpeza), esto, a mi entender, sugiere que Devuan genera interés y se quiere, de alguna manera, dialogar.
En fin, buen fin de semana.
@rolo
Decir que el video puede estar trucado o el sofware, es una falacia total e insulto, en mi PU** vida truque algo para crear un mito, jamas, me jacto de haber visto ese fallo por mis medios no por mis truchos. Se van todos a la **** que los ***** y no me pienso meter mas en debates de systemd porque es totalmente al pedo, nadie quiere entender nada y es todo como una relegion, las cuales, detesto, porque todo es por dogma de fe. Sean felices con systemd.
@SynFlag violencia es mentir
Lo que si demuestra ese video es la falsedad de la afirmación de que si uno de los módulos de systemd si se arruina, hace de que systemd se caiga, ya que evidentemente, por lo que muestra tu video eso no sucedió, xddddd y por cierto journal se ejecuta como root, por lo tanto,si un tercero entra y maliciosamente jode el binario de los log de journal, yo no me preocuparía de systemd sino mas bien de la seguridad de tu ordenador. xdddddd. Por ultimo sobre el tema del video, replique lo que se muestra editando con nano el archivo /var/log/journal/24f02f5b2b16758b820ea6a751ed6efb/system.journal y al reiniciar te encontras que hay un nuevo system.journal y un system@@24f02f5b2b16758b820QQea6a751ed@.journal que es el binario dañado.
Es decir journal se da cuenta que el archivo esta corrupto, asi que no renombra y vuelve a crear uno nuevo, no veo cual es el problema en eso??, lo mismo que si se elimina el archivo system.journal, journal lo vuelve a crear.
me pregunto que pasaría si a un archivo log de texto plano, lo arruinaría con un editor hexadecimal , seguramente hasta que uno no se de cuenta que el archivo estaba dañado se peperina todos los datos O.o
hablemos un poco de journal que es una de las criticas mas comunes a systemd.
journal es un componente muy importante de systemd , que capta los mensajes Syslog, los mensajes de registro del kernel, RAM y los mensajes de arranque iniciales, así como mensajes escritos en STDOUT/TDERR y hace que toda esa información este disponible para el usuario.
Pero lo mas importante, es que journal puede ser utilizado en paralelo, o en reemplazo de un demonio syslog tradicional, como rsyslog o syslog-ng, por lo tanto un sysadmin precavido podría tener rsyslog o syslog-ng como una segunda herramienta de consulta, al margen de transformar en texto plano los registros de journal por si el binario se corrompe
Otro dato importante sobre journal es que si no esta creada la carpeta /var/log/journal Solo se guarda información en forma temporal, la cual se pierde con cada reinicio.
por ejemplo, cuando entro systemd en debian la persistencia de los log no estaba activa asi que habia que crear manualmente la carpeta journal
http://0pointer.net/blog/projects/journalctl.html
Quienes sepan inglés, no se pueden perder las charlas que estan llevando a cabo entre los desarrolladores de devuan, jaromil dimkr max2344 entre otros en el canal IRC de freenode #devuan.
Muy divertido leer las investigaciones del código de systemd como lo han desparramado al propósito con fin de infectar (crear dependecias innecesarias).
Me molesta systemd….así de frente…es difícil. Poca documentación ni el puto slim corre solo KDM o gdm y en u sistema ligero quiero slim lxdm no lo soporta ni compilándolo….. Enserio que hasta antes de….estaba feliz con debían. La verdad empecé a usar openrc como dicen en gentoo y ayudo…. Mucho
@rolo
Sos un insolente y malformador de noticias al decir eso. Es el peor insulto que me digas que miento o falseo datos, realmente me repugna como en pro de defender algo atacas a gente que hace PoC serios como yo. El log se corrompe, el sistema crashea, reiniciar el servicio no funciona asi que no queda otra que reiniciar la maquina lo cual no es lo mejor en un servidor hackeado, me vas a decir que si la seguridad fue comprometida lo mejor es reiniciar o reinstalar y es de lo unico que me debo de preocupar como dicen los de systemd excusandose y no hacer un analisis en caliente de QUE PASO? para llegar a ese punto?. Evidentemente sos un producto mas de los new sysadmin si es que llegas a eso que se crio usando ubuntu y tiene la seguridad de un DOS 5.0 en su pc, asi que lo que digas lo tomo como de quien viene, me jode mucho que dudes ademas el que falsea sos vos, replicaste acado el mismo OS con las updates de ESE día?, seguramente no, asi que tratá de mentiroso a otro. Que falta de capacidad tenes, anda a laburar de taxista xq para mas que eso dudo que te de, deja de jugar con linux y segui mirando pr0n
A ver pichón (synflag), papa te va a mostrar como se haca para lograr que journal continué funcionando luego de que por alguna razón nuestro archivo log binario de journal queda corrupto, sin tener que reiniciar el ordenador.
en este ejemplo partimos de una instalación base de debian 8 jessie.
por defecto systemd-journal.service biene con la función «storage=auto» por lo tanto para lograr tener un registro persistente de los log es necesario crear el archivo en /var/log/journal/ previamente.
# mkdir -p /var/log/journal/
para que journal empiece a escribir los log NO hay que reiniciar el ordenador, vasta con hacer:
# systemctl reload systemd-journal.service
o
# systemctl force-reload systemd-journal.service
### ahora vamos a simular que se corrompe el log binario de journal ###
# cd /var/log/journal
# ls
24f02f5b2b19808b820ea0a980ed6efb
# cd 24f02f5b2b19808b820ea0a980ed6efb
# nano system.journal
### ahora modificamos alguna linea del archivo para simular que se corrompe
# journalctl
### como era de esperar no pasa nada
####¿hay que reiniciar el ordenador para que journal cree un nuevo binario? NO
# systemctl force-reload systemd-journal.service
# ls
system@24f02f5b2b19808b820ea0a980ed6efb-0000000000000001-0005069a53abf581.journal
system.journal
# journalctl
### como podremos ver journal crea un nuevo archivo binario de log y ya podemos vovler a acceder a la información sin tener que haber reiniciado en ningún momento el ordenador
https://www.youtube.com/watch?v=hEagyMdkN4A&feature=youtu.be
conclusión: synflag o sos un ignorante, o sos un fabulador
que te garúe finito
por error de tipeo y abuso del copy and paste escribí systemd-journal.service cuando en realidad el servicio se llama systemd-journald.service
Pichon?, … que equivocado estas flaco, en serio va.. Eso ya lo sabia, reporte el bug en red hat a ver que decian, te pego la respuesta, a ver si captas:
If you remove the output file, or overwrite parts of the file, the daemon cannot really do anything about that: if an attacker has permissions to modify the output file, she has already won. The daemon could check some of those things, but that would be rather inefficient, and not really useful for anything. If you want, you can set up a periodic cryptographic signature with ‘journalctl –setup-keys’. See the journalctl man page.
Journalctl depende de rsyslog, no se auto reinicia en caso de error en el log, cosa que rsyslog no necesita, total, tenes que usar el fordward para que envie a rsyslog y de esa forma se escriba pese a todo y se regenere el journal log, es una falla de diseño de journald, si no queres verlo, blow me.
@rolo
En el vídeo (no se si lo has hecho tu) veo que en el minuto 2:11 se usa ls y no ls -l que permitiría ver el tamaño que tenia originalmente el archivo system.journal, luego lo editan con nano y le agregan renglones vacíos, reinician el servicio a mano y en el minuto 3:15 vuelven a hacer ls y no ls -l, luego en el minuto 3:20 ven el log con journalctl, esto le muestra el log actual lo cual esta bien.
Ahora vienen mis preguntas:
1 – porque se usa ls y no ls -l, para poder ver el tamaño original que tenia el log antes de ser editado
2 – que paso con el log viejo? en donde lo metio systemd al log binario corrupto?
3 – con que comando systemd puede reparar su log binario corrupto…que se supone que no ha borrado
Saludos
@anonimo
Ahora vienen mis preguntas:
1 – porque se usa ls y no ls -l, para poder ver el tamaño original que tenia el log antes de ser editado
2 – que paso con el log viejo? en donde lo metio systemd al log binario corrupto?
3 – con que comando systemd puede reparar su log binario corrupto…que se supone que no ha borrado
1 la verdad que ni lo pensé, solo utilice ls para ver que archivos estaban en el directorio, pero si te interesa lo podes replicar, el procedimiento esta detallado, y lo realice en virtualbox (instalar un debian base es una papita)
2 el log viejo queda en el mismo directorio, solo solo que systemd lo renombra con un montón de números y letras (se muestra en el video)
3 en todo caso podrías tratar de recurrir a aplicaciones de terceros (algún editor hexadecimal supongo) ya que si systemd pudiera reparar el archivo corrupto no lo renombraria ni crearía uno nuevo. En todo caso, y como ya he mencionado en otras ocasiones ene este post, un sysadmin precavido podría tener rsyslog o syslog-ng como una segunda herramienta de consulta, al margen de transformar en texto plano los registros de journal por si el binario se corrompe.
digo, no es la idea de convencer a nadie de usar systemd (hasta me encantaría que en el instalador de debian exista la posibilidad de elegir el int ). pero no me voy a quedar callado cuando leo a ignorantes o fabuladores que se la pasan repitiendo mentiras sobre systemd, en cuanto blog existe, cuando uno ve que esos dichos no coinciden con la realidad. y como decía aristóteles la única verdad es la realidad 😉
@rolo
He mirado el vídeo de nuevo y si, ahi salia listado, solo que era tan largo el nombre numérico que lo veía, pense que ese era el directorio….soberano nombre.
Respecto a reparar el binario, si, es lógico lo que dices…si pudiera repararlo no crearia uno nuevo.
Finalmente me quedo con que no deberia de ser un binario para que no pase eso y para poder verse sin herramientas especiales con journalctl…..aún no comprendo que lo llevó a usar un formato binario.
Saludos y gracias por responder
Rolo, dedicate a otra cosa:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393
Yo lo supe sin saber eso…. como se nota la diferencia entre uno que anda probando cosas y otro que solo hace videitos pedorros
Vengo a cerrar el ocote de Rolo, el error que se ve en mi PoC habia sido reportado, asi que, cerra el ocote pichon:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393
A ver fabulador:
1 Afirmaste que para que journal solucionara el problema era necesario reiniciar el pc como en windows TOTALMENTE FALSO
Te demostré que eso era una mentira y en el video ese que hiciste en ningún momento usas el comando systemctl force-reload systemd-journald.service porque si lo hubieras usado tu argumento se caía (o desconocías el comando, lo cual demostraría que sos un ignorante, o intencionalmente no lo utilizaste, lo cual demostraría que sos un fabulador)
2 Decís que existan reportes del bug, por un lado es totalmente irrelevante ya que por lo general la gente reporta muchas tonteras como bug (para que lo entiendas no todo reporte de bug es un verdadero bug) hasta me da la idea que lo reportaste vos mismo. Y por el otro todos los programas tienen bug (cuantos bug reportados tiene sysvinit (un programa que tiene como 20 años)) y lo bueno del reporte es que ayuda a los desarrolladores a descubrir y solucionar problemas (algunos mas rápido otros mas lento)
3 Decís que con el fallo que generas en journal, al reiniciar systemd se casca ya que en el video se ve que tenes que reiniciar forzadamente el virtualbox. TOTALMENTE FALSO
La verdad es que systemd no se casca ya que el sistema se inicia perfectamente (si no arrancara systemd te daría un kernel panic y tendrías que entrar en modo recuperación)
Lo que te sucede es que el sistema se tilda cuando tratas de editar un binario con un editor de texto y los factores pueden ser muchos, como la memoria asignada, el estado del sistema operativo (en el video el sistema tarda mucho en arrancar y en apagar lo que da a pensar que no es una instalación limpia de 0 (cosa recomendada para este tipo de casos)), etc. Solo te puedo decir que el binario ese lo edite unas 10 o 20 veces y nunca se tildo. Esto también pone en evidencia que o sos un ignorante o un fabulador
4 Ahora decís que journal depende de rsyslog TOTALMENTE FALSO, el hecho es que cualquiera lo puede comprobar instalando o desinstalando rsyslog y viendo que journal funciona perfectamente
Te agradecería encarecidamente que dejes esa obsesión malsana hacia mi persona, no es mi culpa que seas un ignorante o fabulador
Conclusión:
No querés usar systemd, me parece genial, ahora no tenes ninguna necesidad de sembrar el terror con mentiras para lograr adherentes a tu cruzada anti-systemd. vivi y deja vivir, que hay lugar para todos en el mundo del software libre 😉
una aclaración sobre el punto 3, alguien me diría que como systemd esta en pid1 un cuelgue de la maquina implicaría que systemd casco. Dos cosas, primero aca lo que se afirmaba es que systemd cascaba por el fallo de journal, pero en realidad se produce un tilde por entrar a un binario ( que esta siendo usado en tiempo real ) con un editor de texto, igualmente aclaro que en todas las pruebas que realice nunca se tildo la maquina virtual. En segundo lugar nadie en su sano juicio puede afirmar que linux no se tilda xddd,
Fabulador?, flaco, contenete un poco, fabuladora tu vieja que dice que me tiro la goma cuando no la toco ni con un palo, volviedo al respeto:
1.- Tenes que reiniciar o forzar el reinicio del servicio, lo cual tampoco es lo ideal y en CentOS 7 cuando lo probe el reinicio del servicio no hacia nada, no olvides que es la version 208 no la 217 nueva o 216 de Fedora.
2.- Irrelevante y los que reportan bugs?… sos un idiota, ni te respondo
3.- INFELIZ, la version que probe ese dia del video, que se ve, se crasheaba el OS entero, para que te pensas que mentiria infeliz del orto?, no soy un simio mentiroso, anda a tomar cindor pajero.
4.- Depende para auto regenerarse solo, no lo hace por si mismo de hecho lo sugeri a los dev de systemd como feature, que se auto regenere sin dejar de loggear a menos que se reinicie el servicio, me lo tomaron como que lo van a añadir, asi que chupame la verga y decime gracias papi por colaborar mientras yo miro porno.
Chau flaco, me canse de hablar con monitos para eso prefiero ir al zoo, cuando estes al nivel de mi ano charlamos.
@SynFlag te pido mil disculpas, no sabía que estabas enfermo, realmente creía que eras un fabulador e ignorante, pero con lo que acabas de escribir me doy cuenta que en realidad sos un delirante.
bueno nada, espero que gradúes mejor tu medicación y logres volver a la realidad, fuerza !!! vos podes!!!
Leo y leo y releo pero no entiendo nada, solo se que desde que salio Xubuntu 14.04.1 hasta la fecha, no he tendio ningun problema con mi notebook, ni con mi impresora laser hp 1102, no se nada de nada, soy usuario y no se si systemd es peor o no conviene de init, pero repito no tengo problemas con xubuntu. 🙂
Leo, leo y releo y solo se que estoy reviviendo un tema viejo. XD