Portada
mis comunidades
otras secciones
#8:
#4 Es decir, utilizabas Linux cuando iba como el culo y tenías que considerar hasta que teclado comprabas para ser compatible, y lo dejás de utilizar cuando está en su punto más alto de funcionalidad y compatibilidad porque:
- Las distribuciones más importantes deján de utilizar un sistema que estaba ideado para ser totalmente secuencial y se pasan a uno ideado para sacar partido de los recursos de la máquina. Por cierto, Linus no tiene nada que ver con esto, está fuera del kernel.
- Linus decide, de forma un tanto aleatoria ciertamente, cambiar el versionado. Lo cual no tiene ningún efecto y no es motivo ni de pena ni de gloria.
Pues nada, que te vaya bien con FreeBSD, supongo que cuando FreeBSD sea un pooco más mainstream (es decir, nunca) te pasarás a GNU Hurd.
- Las distribuciones más importantes deján de utilizar un sistema que estaba ideado para ser totalmente secuencial y se pasan a uno ideado para sacar partido de los recursos de la máquina. Por cierto, Linus no tiene nada que ver con esto, está fuera del kernel.
- Linus decide, de forma un tanto aleatoria ciertamente, cambiar el versionado. Lo cual no tiene ningún efecto y no es motivo ni de pena ni de gloria.
Pues nada, que te vaya bien con FreeBSD, supongo que cuando FreeBSD sea un pooco más mainstream (es decir, nunca) te pasarás a GNU Hurd.
#3:
Traducción de la parte que habla de la numeración (algo informal):
.. veamos cuanto (si algo) se rompe por el número de versión. Probablemente menos que durante el tiempo de 3.0, pero puedo imaginarme a alguien utilizando las versiones como si tuvieran significado.
La gente ha hablado, y aunque la mayoría no tenía sentido, los números no mienten. La gente ha preferido 4.0 y 4.0 debe ser. Salvo que alguien venga con un buen argumento en contra.
Hasta ahora los argumentos en contra han sido "el número grande debe ir con una nueva característica grande o incompatibilidad", que sólo muestra lo poco que sabe la gente. Nosotros no rompemos compatibilidad y no hemos hecho lanzamientos en base a características desde básicamente nunca.
Por otro lado, el argumento más fuerte de algunas personas a favor de 4.0 parece ser ver 4.1.5 - porque "esa es la versión de Linux skynet utilizó para el terminator T-800".
Para resumir, yo no daría mucho significado al número.
.. veamos cuanto (si algo) se rompe por el número de versión. Probablemente menos que durante el tiempo de 3.0, pero puedo imaginarme a alguien utilizando las versiones como si tuvieran significado.
La gente ha hablado, y aunque la mayoría no tenía sentido, los números no mienten. La gente ha preferido 4.0 y 4.0 debe ser. Salvo que alguien venga con un buen argumento en contra.
Hasta ahora los argumentos en contra han sido "el número grande debe ir con una nueva característica grande o incompatibilidad", que sólo muestra lo poco que sabe la gente. Nosotros no rompemos compatibilidad y no hemos hecho lanzamientos en base a características desde básicamente nunca.
Por otro lado, el argumento más fuerte de algunas personas a favor de 4.0 parece ser ver 4.1.5 - porque "esa es la versión de Linux skynet utilizó para el terminator T-800".
Para resumir, yo no daría mucho significado al número.
#21:
#18 Por partes:
- Logs binarios: te permiten cosas impensables anteriormente como ordenar y filtrar resultados por fechas, servicios, palabras clave, etc. Y además puedes hacer que la salida se derive a logs de texto tradicionales, con lo que sigues teniendo tus logs en texto plano si te place.
- Beneficios de arranque y apagado: La rapidez es secundaria (no tanto si tienes un servidor de máquinas virtuales -guardar y apagar todas las máquinas virtuales, el servidor, arrancarlo, arrancar todas las máquinas virtuales que tenga dentro, cargar las imágenes guardadas-, ahí la rapidez si es muy estimada: todo el tiempo que no tengas las máquinas arriba estás perdiendo dinero), lo que da es robustez (controla dependencias entre procesos, controla recursos asignados a cada proceso tanto a la hora de darlos -fijar un límite de consumo de cpu para el proceso tal, límite de consumo de memoria para el proceso cual- como a la hora de recuperarlos -que no se queden procesos abiertos o zombies, liberar toda memoria, etc.-).
- Intentar abarcarlo todo: Systemd pese a lo que te cuenten es MODULAR, hay pequeños ejecutables que se encargan de cosas concretas, puedes montarte un systemd a medida, está hecho para escalar desde dispositivos empotrados hasta grandes clusters de servidores a base de activar los elementos que necesites en el arranque. Que haya componentes/binarios de systemd para hacer de todo no solo no engorda el sistema ni lo hace lento ni nada de eso, sino que lo hace aún más deseable porque te da más flexibilidad y más elementos. Pasa lo mismo con el kernel y su "monoliticidad", que en el fondo como todo son módulos no es tan gordo como la gente piensa. La ventaja que tiene es que dichos módulos comparten mucho código (no se escribe lo mismo dos veces para dos cosas distintas, con la posibilidad de añadir bugs que eso conlleva y además son más fáciles de mantener). Y lo mejor de todo, al ser modular se pueden sustituír los módulos por otros mejores llegado el momento (salvo unos cuantos que son parte integral de systemd).
Aquí tienes una table de las distintas interfaces de los módulos base (hay muchísimos más), su portabilidad, quienes los usan y sus distintas implementaciones:
http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
- Logs binarios: te permiten cosas impensables anteriormente como ordenar y filtrar resultados por fechas, servicios, palabras clave, etc. Y además puedes hacer que la salida se derive a logs de texto tradicionales, con lo que sigues teniendo tus logs en texto plano si te place.
- Beneficios de arranque y apagado: La rapidez es secundaria (no tanto si tienes un servidor de máquinas virtuales -guardar y apagar todas las máquinas virtuales, el servidor, arrancarlo, arrancar todas las máquinas virtuales que tenga dentro, cargar las imágenes guardadas-, ahí la rapidez si es muy estimada: todo el tiempo que no tengas las máquinas arriba estás perdiendo dinero), lo que da es robustez (controla dependencias entre procesos, controla recursos asignados a cada proceso tanto a la hora de darlos -fijar un límite de consumo de cpu para el proceso tal, límite de consumo de memoria para el proceso cual- como a la hora de recuperarlos -que no se queden procesos abiertos o zombies, liberar toda memoria, etc.-).
- Intentar abarcarlo todo: Systemd pese a lo que te cuenten es MODULAR, hay pequeños ejecutables que se encargan de cosas concretas, puedes montarte un systemd a medida, está hecho para escalar desde dispositivos empotrados hasta grandes clusters de servidores a base de activar los elementos que necesites en el arranque. Que haya componentes/binarios de systemd para hacer de todo no solo no engorda el sistema ni lo hace lento ni nada de eso, sino que lo hace aún más deseable porque te da más flexibilidad y más elementos. Pasa lo mismo con el kernel y su "monoliticidad", que en el fondo como todo son módulos no es tan gordo como la gente piensa. La ventaja que tiene es que dichos módulos comparten mucho código (no se escribe lo mismo dos veces para dos cosas distintas, con la posibilidad de añadir bugs que eso conlleva y además son más fáciles de mantener). Y lo mejor de todo, al ser modular se pueden sustituír los módulos por otros mejores llegado el momento (salvo unos cuantos que son parte integral de systemd).
Aquí tienes una table de las distintas interfaces de los módulos base (hay muchísimos más), su portabilidad, quienes los usan y sus distintas implementaciones:
http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
#16:
#15 ¿Qué servicio? ¿qué servicios dependen de ese servicio? ¿cómo lo reseteas? ¿qué distro usas? ¿qué versión de systemd? ¿estás seguro que antes el servicio se cerraba bien antes de volver a abrirse o quizá se forzaba el cierre a lo bestia? ¿te liberaba todos los recursos?
Systemd no fue creado para mejorar la velocidad de arranque, es un efecto secundario de hacer las cosas bien.
Systemd no fue creado para mejorar la velocidad de arranque, es un efecto secundario de hacer las cosas bien.
#18:
#8 No iba como el culo entonces, de hecho me fiaba más de los servers con linux que de los NTs que tenia entonces. Y lo sigo usando ahora (en la raspberry, en VMs, en mi entorno de desarrollo, etc)
Pero para instalaciones nuevas de servidores estoy empezando a usar FreeBSD en vez de Debian o CentOS.
Lo del mainstream parece un ataque personal, no lo hago por hipsterismo. Prefiero un entorno base más simple y fiable.
#6 No solo por los números, es uno de varios motivos.
Mi critica a systemd, y esto va para #6, #7 y #8 es por varios motivos, entre ellos:
- Logs binarios
- Beneficios de arranque imperceptibles: los servidores solo los reinicio cuando actualizo el kernel.
- Intenta abarcarlo todo: si solo fuera un sustituto de init, podria pasar, pero va mucho más alla, sustituyendo a servicios o sistemas que no tienen nada que ver con el arranque.
Pero para instalaciones nuevas de servidores estoy empezando a usar FreeBSD en vez de Debian o CentOS.
Lo del mainstream parece un ataque personal, no lo hago por hipsterismo. Prefiero un entorno base más simple y fiable.
#6 No solo por los números, es uno de varios motivos.
Mi critica a systemd, y esto va para #6, #7 y #8 es por varios motivos, entre ellos:
- Logs binarios
- Beneficios de arranque imperceptibles: los servidores solo los reinicio cuando actualizo el kernel.
- Intenta abarcarlo todo: si solo fuera un sustituto de init, podria pasar, pero va mucho más alla, sustituyendo a servicios o sistemas que no tienen nada que ver con el arranque.
#1:
Gran noticia, yo utilizo ahora lubuntu y va cañón, pero todo lo que sea mejorar, bienvenido sea.
Comentarios
Traducción de la parte que habla de la numeración (algo informal):
.. veamos cuanto (si algo) se rompe por el número de versión. Probablemente menos que durante el tiempo de 3.0, pero puedo imaginarme a alguien utilizando las versiones como si tuvieran significado.
La gente ha hablado, y aunque la mayoría no tenía sentido, los números no mienten. La gente ha preferido 4.0 y 4.0 debe ser. Salvo que alguien venga con un buen argumento en contra.
Hasta ahora los argumentos en contra han sido "el número grande debe ir con una nueva característica grande o incompatibilidad", que sólo muestra lo poco que sabe la gente. Nosotros no rompemos compatibilidad y no hemos hecho lanzamientos en base a características desde básicamente nunca.
Por otro lado, el argumento más fuerte de algunas personas a favor de 4.0 parece ser ver 4.1.5 - porque "esa es la versión de Linux skynet utilizó para el terminator T-800".
Para resumir, yo no daría mucho significado al número.
#3 Todo el mundo sabe que el T800 funcionaba con el código de un Apple II+
#28 Me pregunto por que una maquina pondría comentarios en su propio código. Y ademas ensambla just in time o depura sobre la marcha, porque eso tendría que ser código maquina. Seguramente por eso falló su misión, no corria en release.
Todo indica que skynet contrató a un par de becarios de alguna carnica para programar sus T-800.
http://www.pagetable.com/docs/terminator/00-37-23.jpg
#15 ¿Qué servicio? ¿qué servicios dependen de ese servicio? ¿cómo lo reseteas? ¿qué distro usas? ¿qué versión de systemd? ¿estás seguro que antes el servicio se cerraba bien antes de volver a abrirse o quizá se forzaba el cierre a lo bestia? ¿te liberaba todos los recursos?
Systemd no fue creado para mejorar la velocidad de arranque, es un efecto secundario de hacer las cosas bien.
#16 Me refiero por ejemplo a restartear el Apache. Con Centos 7 completamente actualizada. Antes de systemd, un "service httpd restart" era inmediato. Ahora tarda una eternidad porque en lugar de matar los hijos se pone a esperar que terminen por sí mismos. Alguna vez he tenido que ponerme a hacer kill de los procesos porque necesitaba que terminara de una vez y no podía esperar 5 o 10 minutos.
#48 http://serverfault.com/questions/501694/systemd-httpd-stop-very-slow-under-arch-linux
#49 Interesante, pero también he tenido ese problema con mysql (mariadb) por ejemplo
#54 Bueno, la primera pregunta sería si realmente necesitas reiniciar todo el servicio completamente o si solo necesitas "releer" la configuración para que el servicio opere usando las nuevas opciones.
systemctl restart x --> para completamente y luego arranca el servicio
systemctl reload x --> hace un "gracefully restart", o sea, recarga la configuración del servicio
He puesto gracefully restart porque es el equivalente que hay en apache para lo mismo (Stops the Web server by advising all forked Apache processes to first finish their requests before shutting down. As each process dies, it is replaced by a newly started one, resulting in a complete "restart" of Apache). O sea, un reinicio gradual donde no se pierde el servicio en ningún momento y que además va cogiendo la nueva configuración, todo eso sin parar el proceso del todo en ningún momento. A nivel de gestores de bases de datos seguramente funcione de manera parecida.
Visto de manera "técnica" en restart recarga el fichero de configuración de systemd para ese proceso (unit), mientras que reload lo que hace es cargar los ficheros de configuración propios del proceso. El primero reinicia a nivel de gestor de servicios (systemd), el segundo lo hace a nivel de servicio (apache).
Según como lo tuvieras configurado anteriormente en el /etc/init.d/, quizá se te estuviera comportando como en el primer caso o quizá como en el segundo.
#55 Mi situación es que a veces a "alguien" le da por tirar alguna consulta pesadísima sobre la base de datos. Por motivos de velocidad, utilizo myisam en lugar de innodb. He hecho pruebas y realmente innodb es inusable con la cantidad de datos que tengo (varios millones de registros) mientras que myisam se comporta muy bien. Pero resulta que myisam bloquea las tablas completas durante las consultas. Una consulta pesada termina por bloquear alguna tabla de uso frecuente y las demás consultas quedan en espera. La solución más razonable (aparte de no hacer esas consultas) es matar el proceso de la consulta, pero a veces hay tantas conexiones esperando respuesta que no me permite conectarme para mirar la "processlist" y deshacerme del responsable. Por lo tanto me quedan dos alternativas: o mato el proceso de php (apache) que tiró la consulta, o restarteo todo el mysql para que termine de una vez con eso. Como no puedo saber cuál es el proceso de Apache responsable, lo único que me queda es matar todos (restartear el Apache) o restartear el mysql.
Eso antes de systemd me tomaba segundos y ahora con systemd me toma minutos.
#57 Uff, es que myisam no realiza transacciones a nivel de celdas o filas, por eso tiene que bloquear las tablas completas (y claro, hace las cosas una a una en lugar de muchas a la vez que satura mucho más la base de datos, lo cual permite que esas grandes transacciones vayan, pero a costa de todas las demás). Aún así habría que mirar si no está bloqueando "de más" esa tabla que dices (si interrumpes el proceso y no hay pérdida de datos supondré que si), quizá habría que revisar las consultas que hacen y si se dejan sin soltar algún bloqueo en algún momento. Otra cosa que puedes mirar es la configuración del propio gestor de bases de datos, aumentar la memoria disponible para realizar ciertas operaciones y así acelerarlas, el control de bloqueos para que una tabla se desbloquee si no se realizan operaciones sobre la misma durante x tiempo, etc. Un seguimiento usando una herramienta tipo mytop puede ayudar a averiguar qué coño pasa (aparte de lo obvio), como poner la opción de slow_queries_log (o algo así, no recuerdo cómo se llama, el caso es que te guarde qué consultas se están pasando de la raya, para que tu les tires de las orejas a los que las han hecho y optimicen en caso de que sea posible).
Por otro lado, una base de datos sin transacciones me parece un "riesgo". ¿Has probado algún otro motor para mariadb que no consuma tantos recursos como innoDB y que sea rápido como myisam?
#58 No hay pérdida de datos porque son consultas, no grabaciones. Y sí, hay formas de hacer las consultas de otra forma, y si, llevo tiempo intentando que dejen de usar las antiguas... No es que las consultas dejen bloqueos porque no hacen bloqueos explícitos, simplemente son selects con joins complicados que a veces no se pueden resolver con índices así que se recorren millones de registros varias veces.
Por la manera en que se graban las cosas, es muy poco probable que queden datos inconsistentes. He probado el motor de almacenamiento aria con varias opciones pero en todos los casos, incluso sin transacciones y sin ningún tipo de control que supuestamente queda al mismo nivel que myisam, resulta que es notablemente más lento. Suficientemente lento como para que los usuarios empiecen a llamar a quejarse de que el sistema no responde o para que algunas aplicaciones den timeouts. No es peor que innoDB pero igual es suficientemente lento como para que no pueda cambiarlo.
#59 ¿Y si les creas vistas a esas joins para que no tengan que estarte reventando la BBDD todo el rato sino solo una vez (cuando la creas)? que trabajen sobre las vistas, que ya tienen media consulta "hecha" y aceleran la otra media...
Cuanto más fino es el control más recursos consume, es lógico.
#60 No he intentado crear vistas porque son consultas que no se hacen muy seguido, tal vez una vez al mes, y son diferentes cada vez así que crear una vista podría penalizar el funcionamiento general. En realidad lo que he estado haciendo es tratar de que dejen de usar esas consultas y usen programas específicos que van directamente a buscar lo que necesitan y responden instantáneamente. A eso he agregado un esclavo de replicación sobre el que largo las demás consultas. Pero voy a pensar el tema de las vistas a ver si podrían ayudar en algo.
#61 Por lo menos tener las joins hechas, ya solo con eso te evitas la mayor parte (aunque las consultas sobre esas joins varíen).
#18 Por partes:
- Logs binarios: te permiten cosas impensables anteriormente como ordenar y filtrar resultados por fechas, servicios, palabras clave, etc. Y además puedes hacer que la salida se derive a logs de texto tradicionales, con lo que sigues teniendo tus logs en texto plano si te place.
- Beneficios de arranque y apagado: La rapidez es secundaria (no tanto si tienes un servidor de máquinas virtuales -guardar y apagar todas las máquinas virtuales, el servidor, arrancarlo, arrancar todas las máquinas virtuales que tenga dentro, cargar las imágenes guardadas-, ahí la rapidez si es muy estimada: todo el tiempo que no tengas las máquinas arriba estás perdiendo dinero), lo que da es robustez (controla dependencias entre procesos, controla recursos asignados a cada proceso tanto a la hora de darlos -fijar un límite de consumo de cpu para el proceso tal, límite de consumo de memoria para el proceso cual- como a la hora de recuperarlos -que no se queden procesos abiertos o zombies, liberar toda memoria, etc.-).
- Intentar abarcarlo todo: Systemd pese a lo que te cuenten es MODULAR, hay pequeños ejecutables que se encargan de cosas concretas, puedes montarte un systemd a medida, está hecho para escalar desde dispositivos empotrados hasta grandes clusters de servidores a base de activar los elementos que necesites en el arranque. Que haya componentes/binarios de systemd para hacer de todo no solo no engorda el sistema ni lo hace lento ni nada de eso, sino que lo hace aún más deseable porque te da más flexibilidad y más elementos. Pasa lo mismo con el kernel y su "monoliticidad", que en el fondo como todo son módulos no es tan gordo como la gente piensa. La ventaja que tiene es que dichos módulos comparten mucho código (no se escribe lo mismo dos veces para dos cosas distintas, con la posibilidad de añadir bugs que eso conlleva y además son más fáciles de mantener). Y lo mejor de todo, al ser modular se pueden sustituír los módulos por otros mejores llegado el momento (salvo unos cuantos que son parte integral de systemd).
Aquí tienes una table de las distintas interfaces de los módulos base (hay muchísimos más), su portabilidad, quienes los usan y sus distintas implementaciones:
http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
#21
- Si, los logs binarios permiten hacer muchas cosas, pero esas cosas no las hago en los servidores que producen los logs, sino en los servidores auxiliares que "recogen" los logs de otros servidores.
- La diferencia de velocidad, al menos en mi experiencia, no es tan grande como para que suponga un ahorro de dinero, a no ser que estemos hablando de cientos de servidores. Las dependencias ya las tenía resueltas con el tema del orden en que arrancan. Estamos hablando de servers, y ahi se muy bien que está rodando y porqué. El control de recursos de los servicios (cpu, mem) no entiendo porque tiene que ser responsabilidad del gestor de arranque.
- No he dicho que sea monolitico, tampoco hablo de oidas. Que sea modular no cambia que pretenda abarcarlo todo.
Gracias por el enlace, pero ya lo conocía.
No se porque la gente me ha saltado al cuello acusandome de hablar sin saber, o por comentarios de terceros. Lo he probado, y las ventajas no me compensan los inconvenientes.
#23
- Logs: puedes derivarlos y tratarlos a tu antojo, como si quieres enviarlos como entrada a libcaca y hacerte un video con ellos (aunque dudo que libcaca funcione así). Que los logs se almacenen en el ordenador que los produce en binario para hacer todo más fácil y eficiente no tiene nada que ver con los procesos posteriores y el uso que les des a posteriori. O sea, cuando lo hacía en modo de texto también tenías que manipularlos para conseguir ciertas cosas. Si quieres moverlos a otras máquinas, transormarlos, hacer data minning sobre ellos y demás debes saber que hay muchas formas y seguramente en binario sea más fácil que usando texto. No por nada siempre que hay que analizar textos se les transforma en algún tipo de representación intermedia bien estructurada.
-El control de recursos: Quiero que mi mysql no se pase consumiendo ram, necesito que me deje un margen para poder meterme en el servidor y ver qué pasa si alguna consulta se pasa de madre. Quiero que mi tomcat no se coma toda la cpu cuando se mi máquina virtual java se meriende la memoria y haya que hacer recolección de basura. Quiero que mi apache no se coma todo el ancho de banda de la red porque quiero reservar un poco para los backups. Está bien que tu manualmente puedas controlar los recursos del programa que ejecutas cuando lo lanzas, y lo haces al lanzarlo. Cuando es un servicio, que se arranca en inicio, también es deseable poder fijar parámetros de control y gestión de los recursos durante ese inicio, y eso es lo que hace systemd de forma sencilla. Antes tenías tus scripts que tenías que editar a mano y tenías que crearte soluciones a mano. Ahora tienes units, bien estructuradas y con la mayoría de cosas que necesitas para gestionar tus procesos ya hechas. De hecho, puedes hasta restringir qué procesos pueden acceder a qué recursos (que un apache solo vea una interfaz de salida y que un postgresql solo vea la otra interfaz, por cuestiones de seguridad).
Ahora, una cosas es un "sistema de inicialización de servicios y gestión de recursos" y otra un gestor de arranque, el arranque dura hasta que hay en memoria un sistema que se puede encargar de si mismo y de todos los procesos necesarios que forman parte de un sistema operativo y todos aquellos que dan funcionalidades y ofrecen servicios.
Sobre saltar al cuello, es que hay mucho FUD al respecto, mucho que habla sin saber repitiendo eslóganes que ha leído mil vecse por internet sin conocer cómo funcionan de verdad las cosas.
#26 No conocía libcaca, gracias Me recuerda a la viejuna aa-lib.
#29 es aalib pero en color
lo cual es una cagada de mi parte, porque poco color tendría derivar los logs a libcaca
#21 Hoy en el bar estaban dos jubilados hablando de eso y erre que erre con lo mismo.
#46 Menos mal que hay jóvenes que están levantando el país y cambiando el mundo.
#18 No es que intente abarcarlo todo, es una capa del sistema, por tanto todo debe y debería ir pasar por systemd. Init.d hasta ahora solo trataba de funcionar como una capa, a base de hooks hardcoded para cada cada nuevo servicio que se instalase, una chapuza.
Ahora, por definición, existen llamadas a systemd, y es, sencillamente el encargado de poner de acuerdo al kernel con los servicios, sean dispositivos de entrada, daemons o lo que quiera el admin que sea. De forma uniforme y coherente. Además implica una nueva capa de seguridad, por fin el sandboxing tiene un estandar en Linux.
En serio, es realmente el avance más importante en el desarrollo de los sistemas GNU/Linux en casi una década, llevamos años pidiendo uniformidad e interoperabilidad entre distribuciones, y cuando por fin nos ponemos todos de acuerdo en algo, nos ponemos mojigatos porque ahora la mía me parece más larga. Buena suerte a los que se pasen a Devuan, y que disfruten de su rollo "mormónix", yo estoy que doy palmas con las orejas con el nuevo systemd.
Gran noticia, yo utilizo ahora lubuntu y va cañón, pero todo lo que sea mejorar, bienvenido sea.
Qué relevante.
Uso Linux desde el 98, y Debian desde que salió potato (~2000) y por cosas como esta y la mamamandurria del systemd, estoy migrando a FreeBSD.
#4 ¿Te cambias a bsd por meros números y por un sistema de inicio que soluciona muchos problemas?
#6 La verdad a mi systemd sólo me ha dado problemas. Por ejemplo antes podía restartear un servicio en segundos y ahora tarda una eternidad. Y la verdad no he notado mucha mejora en la velocidad del arranque.
#15 Tiene muy poco sentido eso de que no puedas reiniciar un servicio, en 14 años ha dado tiempo a cambiarlos.
#20 sí puedo reiniciar un servicio. Pero es muchiiiiisimo más lento. Lo que hace es esperar a que el servicio deje de estar ocupado. Por ejemplo supongamos que tengo una consulta pesadísima que me está matando el servidor mysql (mariadb en realidad). Muchas veces me ha pasado que está tan ocupado que no acepta nuevas conexiones, por lo tanto no puedo entrar por línea de comandos y matar la consulta. La única alternativa es hacer un service mariadb restart. Pero resulta que le da por esperar a que todas las consultas terminen.
A veces para no darle a la base de datos prefiero restartear el Apache (que generó la consulta). Pero en este caso tarda más todavía. Intenta esperar a que todas las conexiones de Apache hayan terminado y tarda varios minutos.
#8 No iba como el culo entonces, de hecho me fiaba más de los servers con linux que de los NTs que tenia entonces. Y lo sigo usando ahora (en la raspberry, en VMs, en mi entorno de desarrollo, etc)
Pero para instalaciones nuevas de servidores estoy empezando a usar FreeBSD en vez de Debian o CentOS.
Lo del mainstream parece un ataque personal, no lo hago por hipsterismo. Prefiero un entorno base más simple y fiable.
#6 No solo por los números, es uno de varios motivos.
Mi critica a systemd, y esto va para #6, #7 y #8 es por varios motivos, entre ellos:
- Logs binarios
- Beneficios de arranque imperceptibles: los servidores solo los reinicio cuando actualizo el kernel.
- Intenta abarcarlo todo: si solo fuera un sustituto de init, podria pasar, pero va mucho más alla, sustituyendo a servicios o sistemas que no tienen nada que ver con el arranque.
#18 Si necesitas logs en texto plano, creo que se los puedes pasar a syslog y los tendrás en ambas opciones (https://wiki.archlinux.org/index.php/systemd#Journald_in_conjunction_with_syslog). El único mótivo para utilizar logs binarios es que son más rápidos de procesar.
Con systemd redirigiendo todo el stdout y stderr de servicios a journald, te ahorras el tener que configurar todos esos servicios.
El beneficio de arranque es un efecto secundario, para máquinas que no son servidores se agradece.
Yo por otro lado, solo le veo ventajas a que systemd sea más ambicioso que un simple script.
Yo no voy a decir que systemd soluciona problemas existentes porque no sabría decirte que problema soluciona. Pero te puedo asegurar que si me enseñan init y systemd (sin tener en cuenta la historia detrás de cada uno de ellos) y tengo que quedarme con uno de ellos, me quedo con systemd.
#18 Respecto a lo de los log binarios, creo que no te has detenido a leer concienzudamente lo que supone, y supongo que no te ha tocado sufrir una semana de lectura de logs para darte cuenta de sus ventajas:
- Una única entrada a logs. Adiós bucear cientos de ficheros tipo 23436621341234_1.gz.
- Metadatos, y búsqueda por metadatos.
- Pares clave y valor. los logs son firmados y no falseables.
- Seguro. Una aplicación no puede escribir en los log de otra.(ahora sí pueden)
- Seguro. Los usuarios tienen acceso sólo a su log, o a los que esté habilitado.
- Menor tamaño de logs.
- Paralelizados. Se puede acceder a los datos de forma NO lineal.
#18 Hay otra cosa que me he dejado en el tintero, y creo que tiene una importancia vital. Desde hace un par de años, ha habido varios intentos en fragmentar la comunidad linux en varios sectores, la más dolorosa y sangrante es Ubuntu, que intenta imponer su criterio sobre el de los demás desde posiciones absolutamente egoistas. Tambien desde Android, y desde otras comunidades se ha intentado poner unas barreras que hubieran sido infranqueables de haberse consumado el "cup de stat".
Systemd ha sido un acuerdo inextremis entre las comunidades RedHat, SuSE y Debian, cediendo unos y otros de su parte. Debian sopesó muchísimo la decisión, con no pocas tensiones en su interior (prueba de ello es Devuan).
No ha sido hasta el momento del órdago, cuando Ubuntu ha anunciado que muy a su pesar, adopta igualmente Systemd frente a Upstart, lo cual viene a significar "Debian, reconozco que sin tí, no soy nada".
Systemd ha venido a ser un standar para gobernarlos a todos y tenerlos en el redil. ¿Un dictador? Puede, pero hay que cerrar filas en torno a algo mayor, que es mantener a la familia unida y sin fragmentaciones. Todos Ganan.
#6 Un sistema de inicio que soluciona muchos problemas que yo no tenía. Y que a cambio causa muchos problemas que yo no tenía tampoco.
#34 Dime que problemas te ha causado. A parte de dolor de cabeza y urticaria.
#41 Cuando cierro la tapa del portátil, con systemd se me suspende (eso lo pude arreglar, pero funcionaba bien antes). Linuxlogo no funciona (cada vez que actualiza systemd pierdo la configuración porque tengo que meterla a mano en /lib). Elasticsearch no arranca en systemd (en ese momento me cansé y volví a init.d).
En resumen, systemd me provoca problemas. Yo no quiero andar depurando el sistema, tratando de buscar qué demonios ha dejado de funcionar con systemd. Y una cosa es pelear con la máquina para que algo ande la primera vez y otra pelear para hacer andar algo que ayer funcionaba perfectamente.
#42 No creo que sea systemd, sino el cómo lo haya configurado la distro que uses. Seguramente sea la configuración de las units que se encargan de arrancar las X es lo que evita que linuxlogo funcione correctamente. Sobre lo de elasticsearch me extaña, porque si que hay soporte para systemd (al final del todo: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/setup-service.html).
En principio no es algo que tengas que hacer tu ni es fallo de systemd en si mismo, es algo que deberían de hacer los mantenedores de paquetes de las distros (salvo que sea algún programa o servicio que no esté en la distribución) que no han afinado la configuración lo suficiente y seguramente habrán fallos porque las distros están en plena transición a systemd. Rellena un bug, quizá eso sirva de algo más productivo que quejarte de systemd. También pasó durante la migración a upstart con algunos programas y servicios, y antes de eso también habían bugs ocasionales (más de los que crees y/o recuerdas) con servicios de inicio.
#51 Linuxlogo pierde la configuración porque la única forma de configurar las consolas es editando unos ficheros que se sobreescriben al actualizar systemd. De todos modos, con independencia de quien es el culpable, el hecho es que lo que antes funcionaba dejó de funcionar. Y ya hice algo más productivo que quejarme, lo desinstalé
#52 Desinstalar = solución que solo funciona para ti y/o evitar buscar una solución.
Hacer algo productivo = buscar solución que funcione para todos y/o facilitar que otros en tu misma situación obtengan una alternativa.
Está claro que linuxlogo no está hecho pensando en systemd; quizá systemd aporte formas de realizar lo mismo que linuxlogo sin necesidad de recurrir a tocar dichos archivos de configuración (eso no lo sé). Lo que está claro es que rechazar un sistema de inicio solo porque no te deja poner una imagen al inicio de X me parece un poco frívolo (ya sé que hay otras cosas que a ti te fallan y que esto no es nada "vital" pero que si te es molesto).
Curiosamente, me he molestado en buscar un poquito y mira, si que hay solución para esto:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750781
Y parece ser que la última versión de linuxlogo soluciona el problema (con lo cual parece que no es cosa de systemd después de todo).
#53 El problema no era de linuxlogo. El asunto es que linuxlogo genera un fichero que se muestra en el login, y la forma de indicarle a getty que use ese fichero es editando inittab. Para systemd hay que editar otro fichero. Ese fichero puede estar en dos ubicaciones: /lib y /usr. En /usr la ignoraba, y en /lib la sobreescribía al actualizar. Quizá ya no ignora /usr, no sé.
No rechazo un sistema de inicio porque no me deja poner una imagen. Lo rechazo porque a mi personalmente no me beneficia en absoluto, y sin embargo me causa problemas. Claro que podría investigar una solución, pero no quiero. Menos aún para un cambio en mi sistema que me parece innecesario. No estamos hablando de mejorar un driver del kernel. Estamos hablando de arreglar los bugs de un sistema de inicio que nunca pedí, y que no necesito.
#63 El caso es que aunque a ti no te afecten las carencias de un producto, lo deseable es que estén arregladas o usar un producto sin esas limitaciones. Como todo cambio en esta vida va a dar algún dolor de cabeza que otro, pero a la larga todo será para mejor (si fuera a peor no se haría, miles de voluntarios que escriben código gratis en su tiempo libre y muchos contratados por grandes empresas que trabajan en ello no pueden estar tan equivocados). Y de todos modos, hay alternativas, así que tampoco hay mayor problema.
#6 systemd no soluciona ningún problema en el segmento de servidores (que es el mas extendido) y crea muchos (logs binarios, cambios en los scripts de arranque, etc).. y lo peor de todo la dependencia que esta creando y cada día es mas difícil prescindir de el. y por no mencionar la fractura que esta formando en la comunidad de software libre que hasta esta planteando hacer forks de distribuciones enteras para poder librarse de la mierda de systemd..
#35 Otro más que no ha usado systemd ni se ha molestado en aprender cómo funciona siquiera:
-Logs binarios: solucionan un huevo de problemas y sobre todo en servidores. El único problema que dan es que el software que se usaba para "espiar" los logs ya no vale. Pero mira que bien, estructuran el texto para que puedas consultar los logs mucho más fácil (ordenar, buscar y filtrar por servicio, fecha, palabras clave, etc. cosa que antes tenías que hacer a mano) y para que programar aplicaciones de seguimiento y control de procesos vía log sea mucho más sencillo (¡hay una api, no hay que matarse a base de expresiones regulares y demás magias oscuras para conseguir lo que quieres conseguir y no otras cosas!). Pero es que incluso si necesitas logs en modo texto siempre puedes redirigir los logs como salida en el formato que quieras a otros sistemas de logs, así que no pierdes nada, ni genera problemas.
-Cambios de scripts de arranque: NINGUNO. Systemd es 100% compatible con sysV init. Pero ¿quién quiere seguir usando scripts en bash cuando las units de systemd te dan todo lo que necesitas y además son un sistema más robusto, compacto y fácil de poner a punto?
-etc? ¿ya no sabes qué más poner para atacar gratuítamente a systemd?
-Dependencias que crea: Las que tu quieras crearle. Systemd no crea dependencias, cada módulo de systemd (porque son muchos ejecutables separados, lo sabías ¿no? al estilo del kernel, que todo el mundo piensa que es muy monolítico y a la hora de la verdad casi todo son módulos que se cargan según se necesite) aporta una serie de apis para que las aplicaciones puedan pedir ciertos recursos de manera estándar. Luego tu puedes sustituír esos módulos por tus propias implementaciones mientras respetes la api. O sea, systemd es muy flexible, si un módulo de systemd se va quedando obsoleto se puede sustituír sin problemas. Las dependencias que se creen no te van a atar a un ente gigantesco, simplemente hablan con un módulo específico. Gnome no está atado a logind (ni a ningún otro módulo de systemd, lo que hace es aprovechar las funcionalidades del sistema si las detecta), simplemente hace uso de logind para facilitarse la vida. Y hay una implementación de logind hecha por canonical ¿qué te parece?. ¿Y te había dicho que hay una implementación de logind-hostnamed para bsd en marcha? https://www.google-melange.com/gsoc/project/details/google/gsoc2014/kremlin/5639274879778816
-Cada día es más difícil depender de él: ¿te refieres en servidor? ¿eso que no necesita ningún entorno gráfico que pueda usar servicios de systemd? hay muchas distros sin systemd, hay muchos gestores de escritorio sin systemd, hay mundo sin systemd y lo seguirá habiendo. Que muchas distros elijan systemd debe dar alguna pista sobre si lo consideran útil y bueno o no. Créeme si te digo que un programador no añade dependencias a sus programas porque si, si lo hace es porque le solucionan la vida en algún punto.
Sobre la gente que está haciendo forks, allá ellos. Mucho trabajo, pocos resultados. Muchos no han llegado a entender realmente qué es systemd, solo se aferran a lo que les es conocido, sin aportar verdaderas razones de índole técnica que les den la razón.
#4 Estoy casi seguro de que no has probado systemd. Si lo hubieras probado, te darías cuenta de lo errado de tu argumento.
Es estable, limpio, y sobre todo TREMENDAMENTE rápido. Es lo que debe ser y por ahora, lo hace rematadamente bien.
#4 Es decir, utilizabas Linux cuando iba como el culo y tenías que considerar hasta que teclado comprabas para ser compatible, y lo dejás de utilizar cuando está en su punto más alto de funcionalidad y compatibilidad porque:
- Las distribuciones más importantes deján de utilizar un sistema que estaba ideado para ser totalmente secuencial y se pasan a uno ideado para sacar partido de los recursos de la máquina. Por cierto, Linus no tiene nada que ver con esto, está fuera del kernel.
- Linus decide, de forma un tanto aleatoria ciertamente, cambiar el versionado. Lo cual no tiene ningún efecto y no es motivo ni de pena ni de gloria.
Pues nada, que te vaya bien con FreeBSD, supongo que cuando FreeBSD sea un pooco más mainstream (es decir, nunca) te pasarás a GNU Hurd.
#8 La ventaja de FreeBSD es que solo hay un FreeBSD y no tienes que hacer como con GNU/Linux con 20000 distros para tener el último Firefox o VLC.
#4 Prefiero OpenBSD, es más simple de configurar.
#4 FreeBSD también cambia de versión de vez en cuando y no sólo eso si no que están pensando en cambiar el sistema de inicio por algo parecido a systemd, a ver a que migras ahora ...
#17 Si, cambia de versión, pero sigue usando el esquema tradicional de MAJOR.MINOR.RELEASE, donde cada uno de esos tiene un significado, y no se apunta a la moda de Chrome, Firefox y compañia de usar los números de versión como una especie de estrategia de marketing.
Si FreeBSD cambia init por openRC o algo similar no le veo problema. Si cambia por algun monstruo como systemd puede. No es que sea un fan del init tradicional, pero las ventajas de systemd respecto a sus inconvenientes no me compensan.
#19 ¿Y cuales son los inconvenientes de systemd?
Si fuera por modas, Linux tendría una numeración muy alta y FreeBSD baja, pero FreeBSD va por la 10 y Linux va a pasar ahora a la 4. Los cambios de versión de Linux siempre han sido así, así fue el paso de la 1 a la 2, de la 2 a la 3 y así lo es de la 3 a la 4 pero ahora resulta que es una moda ...
#22 No voy a repetir otra vez los inconvenientes, para mi, de systemd. Ya lo he hecho en otras respuestas.
La numeración alta o baja no tiene nada que ver.
En linux, de la 1 a la 2 habia grandes diferencias. Recuerdo perfectamente el cambio de 2.2 a 2.4 y el motivo.
El cambio de numeración al 3, vale, aceptamos barco.
Pero el cambio al 4, pues no lo entiendo. No hay cambios de ABI, no hay grandes novedades ni merges brutales. El post enlazado tampoco justifica el porque: "a la gente le mola", "chorrada skynet", "si no te gusta es porque no tienes ni puta idea"...
#25 2.4 , básicamente nos dió:
IpTables.
IRDA.
USB.
BTTV/V4L.
AGP.
Soporte de DRI en X.
ISCSI.
ISDN.
RAID.
MTD.
I20.
Una lista bestial, como pasar de Windows 95 a Windows 98SE o Windows XP si me apuras en soporte de drivers. El 4.0 no aporta nada.
#19 FreeBSD tiene compat.x , donde X son las veriiones anteriores a la RELEASE, como 9, 8, 7... antes de la 10 . Ergo, puedes ejecutar todo lo anterior sacado para FreeBSD sin problema.
Por ejemplo, juegos de Unreal. Eso con GNU/Linux es más chungo.
Ni te digo en el caso de Ubuntu, el ejecutar cosas de la 10.04 en la 14. Sí, debootstrap + chroot, pero es bastante más complejo... y no quedan repositorios. En ese caso Debian con sus DVD's es más factible.
No debería usarse la 4.0 hasta que los robots humanoides asesinos sean medianamente autónomos.
Le lo contrario estoy viendo que le ponemos la 4.1.15 a la versión mejorada de Spot Boston Dynamics presenta a Spot, la versión ligera y eléctrica del robot Big Dog
Boston Dynamics presenta a Spot, la versión ligera...
es.gizmodo.comrel: Linus Torvalds te pregunta: ¿seguimos con la versión 3.xx o pasamos a la 4.0? [ENG]
Linus Torvalds te pregunta: ¿seguimos con la versi...
plus.google.comVamos, que se sepa no es un cambio importante, los cambios de numeración en las versiones han sido pervertidos por la moda de Google de ponerle a cada cambio menor de Chrome un nuevo número de versión.
Este es el año de Linux en el escritorio.
#24 me lo has quitado. Estaba llegando al final y nadie lo había puesto.
Versionitis, Linus. Llámala linux 6.022x1023 y lo bordas.
No se porque me ha recordado a una pagina del siglo pasado, que aun existe
http://www.mslinux.org/
Relacionada: La próxima versión del kernel, ¿será Linux 3.20 o Linux 4.0?
La próxima versión del kernel, ¿será Linux 3.20 o ...
muylinux.comYa estamos con la versionitis... recuerdo cuando Mozilla decidió subirse al carro de cambiar el número de la versión cada mes, a lo google chrome...
Al final es todo marketing. Me dan ganas de quedarme en la 2.6
Respecto a la discusión que hay con Systemd yo me cague en sus muertos cuando me tope justo con la transición en archlinux. Ahora mismo me parece de las mejores cosas que han cambiado en gnu/linux desde hace tiempo.
#43 " Al final es todo marketing. Me dan ganas de quedarme en la 2.6"
¿2.6?
Tío, que ahora tenemos KMS, Mesa 10.6 con DXD9 integrado, drivers libres decentes (Nouveau está avanzando bastante con el reclocking, radeon supera a Catalyst en muchas cosas, Intel sigue siendo cada vez mejor).
#45 jajaja claro claro, si yo soy el primero que se pone a mirar los changelogs ilusionado. Sólo pretendía ser un poco irónico, si se puede usar esa palabra en este caso.
Ha tirado los dados y ha salido lo que él quería.
¿Entonces la 3.20 será ahora la 4.0 o es la 3.21?
La 3.20 tiene live patching y eso si que es un cambio importante