Menéame: comentarios [4005105]

#20 OpenStreetMap migra su infraestructura a Debian

soberao — Sun, 01 Dec 2024 06:30:21 +0000

#19 No digo que sea monolítico sino que abarca y fagocita programas y funciones que no corresponden al programa init.

"¿qué diversidad había cuando sólo existía sysvinit?"
Sysinit hace una cosa y la hace bien, no se encarga de acaparar programas bajo sus líneas de desarrollo haciendo su uso más dependiente y obligado.

» autor: soberao

#19 OpenStreetMap migra su infraestructura a Debian

aspirador — Sat, 30 Nov 2024 23:26:59 +0000

#18 Systemd NO es un programa monolítico. Por favor, a estas alturas ese bulo está más que desmentido. Systemd está formado por multitud de servicios independientes que utilizan DBus para ofrecer APIs. NO es un programa único. Originalmente era un sustituto de PID1, pero luego se convirtió en un "proyecto paraguas". Pero eso NO significa que todo lo que hace se haga en un solo "programa monolítico". Y además, buena parte de esos servicios eran proyectos que ya existían, y que simplemente se han añadido al "proyecto paraguas", pero siguen siendo servicios independientes que puedes instalar o desinstalar. Es como GNU: sus utilidades están todas bajo el proyecto paraguas GNU, pero son binarios independientes que siguen cada uno su ritmo de desarrollo.

Y lo del fork... ES NORMAL. ¿Por qué no intentas hacer un fork del kernel? ¿O de Libreoffice? ¿O de GTK? ¿Crees que no te pasará exactamente lo mismo? ¿Que en la siguiente versión te encontrarás con cambios y que tengas que hacer un trabajo extra para volver a mezclar tu código? Que se lo digan a nVidia, por ejemplo, que mira como al final ha preferido meter un pseudo-driver libre en el kernel para no tener que reescribir parte de su código en cada nueva versión, cuando le cambian la API interna. O mira como Canonical dejó de lado sus parches para GTK en cuanto pudo, al abandonar Unity y usar Gnome. Y son empresas con muchos recursos.

Y repito ¿qué diversidad había cuando sólo existía sysvinit?

Mira, lo siento, ya me he cansado de rebatir falacias. Buenas noches.

» autor: aspirador

#18 OpenStreetMap migra su infraestructura a Debian

soberao — Sat, 30 Nov 2024 22:59:33 +0000

#17 Todo eso es la teoría, la práctica es otra, no es un init sino que son también herramientas esenciales que ha fagocitado y unido todo en un programa monolítico gordo que va como el culo y cuando tienes un problema no sabes bien qué ha pasado.
Luego está imponiendo una forma de hacer las cosas porque si mount se hace desde systemd entonces es systemd quien decide lo que ese programa hace y que características tiene. Si haces un fork de ese programa que te interesa que funcione de otra forma vas contra el gigante de systemd y en la próxima versión puede añadir nuevos cambios.
Luego si te quitas de glibc para usar musl en servidores para minimizar y optimizar el uso de los recursos, no tiene sentido meter una bestia como systemd.
Luego también están haciendo el proyecto tan grande que no puedes hacer un fork si no te gusta porque necesitas una empresa gorda para llevar el desarrollo así que están decidiendo la dirección que una distro va a tener. Mucho poder se le esta dando a esta gente a un entorno donde antes había mucha diversidad y la dirección hacía donde iba dependía de muchos factores.

» autor: soberao

#17 OpenStreetMap migra su infraestructura a Debian

aspirador — Sat, 30 Nov 2024 22:09:43 +0000

#16 Se la diferencia e incompatibilidades entre GPL y BSD. Pero una vez más, systemd no existe en el espacio del kernel, sino en el de usuario, por lo que eso no les afecta. No hay código que mezclar.

Respecto a que los BSDs utilizan scripts de shell... sí, es exactamente lo mismo que sysvinit. La cuestión es que eso NO es nada eficiente. Por cada script tienes que lanzar un nuevo proceso, cargar el binario de BASH o la shell concreta que use y enlazarla dinámicamente, y que éste parsee todo el script y lo ejecute. Habitualmente, estos scripts hacen cosas relativamente sencillas en concepto, pero que en la práctica obligan a leer ficheros con cat, quedarse sólo con algunas líneas usando grep o awk... y cada uno de esos comandos implica crear un nuevo proceso, cargar un nuevo binario, enlazarlo con sus bibliotecas... Y eso cuando hay que hacer algo un poquito complejo, porque en muchos casos el script lo único que hace es lanzar el servicio que se quiere en segundo plano, con lo que, realmente, lanzar BASH u otra shell no es más que un paso innecesario. Systemd, en cambio, asigna un pequeño fichero a cada proceso que describe qué tiene que lanzar y un par de detalles más. Y este sistema no sólo es más eficiente, sino que es igual de flexible que sysvinit, porque si necesitas hacer algo un poco más complejo que lanzar un programa con una serie de parámetros, condicionado de manera opcional a un socket, sólo tienes que... ¡escribir un script, y usarlo como el programa a lanzar desde systemd! Exactamente igual que sysvinit, pero te ahorras el tener que ordenar "a mano" los scripts para asegurarte de que el servidor web no se lance antes que la base de datos.

Y es que la gran ventaja es la gestión de dependencias: a menudo, un servicio que depende de otro sólo necesita, durante el arranque, asegurarse de que el socket para comunicarse con él está presente, nada más. Pero incluso cuando necesita enviar o recibir datos de ese otro servicio, systemd es muchísimo mejor que sysvinit, porque systemd crea TODOS los sockets desde el principio, y sólo entonces lanza los servicios que tienen que estar sí o sí activos. Y si alguno de esos servicios necesita comunicarse con otro que no está lanzado, abrirá el socket que systemd creó, cosa que systemd detectará y entonces lanzará, bajo demanda, el servicio correspondiente. Mientras tanto, el servicio inicial simplemente espera en el socket, pues el propio kernel hace todo el trabajo de buffer. ESO es eficiente. ESO es simple. ESO es elegante. Puedes tener todos los servicios que quieras, que systemd sólo los lanzará cuando sean requeridos. Todo automáticamente.

Y seguro que la mecánica te suena, pues es justo lo que hacía el viejo inetd: lanzar servicios de red bajo demanda, aunque con la diferencia de que inetd sólo podía lanzar un proceso por cada conexión (además de estar limitado a servicios de red), lo que lo hacía ineficiente, mientras que en systemd un mismo servicio puede gestionar todas las conexiones que se necesiten. Por eso, la clave del reemplazo de PID1 en systemd no son cgroup, sino el lanzamiento de servicios bajo demanda, eliminando la gestión manual de dependencias, además de la gestión de servicios que se mueren. En sysvinit, cada script tiene que gestionar lo que ocurre si un servicio se muere; en systemd, en cambio, el fichero de descripción del servicio indica qué tiene que hacer systemd si el proceso se muere.

Como ves, no hay nada que no se pueda hacer también en BSD. Otra cosa es que no quieran tener que reescribir desde cero el código porque el de systemd es GPL. Pero realmente, un sistema compatible con systemd es perfectamente posible en BSD. Y una vez más, a (e)logind me remito.

» autor: aspirador

#16 OpenStreetMap migra su infraestructura a Debian

soberao — Sat, 30 Nov 2024 21:41:00 +0000

#15 "¿donde estaba la diversidad cuando sólo había sysvinit?"
Los BSDs suelen usar init rc.d (no estoy muy puesto en cuestiones técnicas), scripts de shell que te activan los servicios, hay distros que también los usan un inicio equivalente como Void Linux (runit). Esto también lo rompe systemd, que ahora es un programa en C y no scripts que puedes modificar al vuelo sin compilar.
El problema de la diversidad está en hacer un init para sistemas Linux del que dependen programas importantes y que no sea POSIX ni compatible para otros sistemas UNIX como BSD, estás dejando fuera a mucha gente y haciendo que su sistema vaya por detrás obligándoles a buscarse una solución, cuando los que van con systemd tienen solo que descargar la nueva versión y ponerse a compilar, no se rompe nada gordo.

Puedes convertir una licencia BSD a GPL sin problemas, pero al revés no, una GPL no puede ser BSD o MIT porque esas licencias no te obligan a publicar cambios si haces modificaciones y la GPL sí. news.ycombinator.com/item?id=29268636
Si usas GPL en un sistema con BSD estás obligando a usar una licencia dual. En el caso de systemd no habría problemas porque toda la licencia sería GPL, pero en el caso de los drivers en el kernel de BSD obliga a que sean BSD, no se pueden copiar de Linux para no tener un kernel con dos licencias. Los de OpenBSD en su día se negaron a usar firmwares para el driver wifi atheros y desarrollaron el suyo propio, y este driver iba con dos licencias BSD y GPL para que se pudiera usar en el kernel de Linux. www.linuxpromagazine.com/Online/News/Atheros-Driver-License-Problems-R

» autor: soberao

#15 OpenStreetMap migra su infraestructura a Debian

aspirador — Sat, 30 Nov 2024 20:54:48 +0000

#14 Hombre, a ver... Eso no es que "se use en windows". Systemd se utiliza en el sistema Linux que corre dentro del Windows Subsystem for Linux... que no es más que una máquina virtual. Decir que systemd funciona en Windows en base a eso es como decir que funciona en windows porque si instalo un Linux en un VirtualBox corriendo en un Windows, systemd está corriendo ahí.

Por otro lado, yo te diría que le echases un vistazo al The Unix Haters Handbook, donde verás muchos de los problemas de los sistemas heterogéneos, por mucho que todos ellos se llamen "UNIX". Por cierto: ¿donde estaba la diversidad cuando sólo había sysvinit?

Respecto a que sin cgroup, systemd no tiene sentido, creo que la cuestión es más bien por qué no se añade soporte a systemd para el equivalente a cgroup en otros sistemas, como BSD (por lo que estuve viendo, al menos FreeBSD tiene un equivalente), y aquí sospecho que el motivo SI es político, pero por parte de BSD: systemd es GPL. Podría contarte verdaderas pesadillas de discusiones entre los desarrolladores de BSD que consideran libre al código GPL y los que no. Y una vez más, el PID0 es sólo una parte de systemd, y el corazón son las interfaces DBus, por lo que reimplementar los demonios manteniendo las interfaces es perfectamente posible.

EDITO: en el Unix Haters Handbook hay un delicioso "anti-foreword" por el propio Dennis Ritchie, donde les da un repaso magistral a algunos de los argumentos del libro. El problema es que el libro, en muchos casos, no ataca a UNIX en sí, sino a la situación caótica que había en los 80 y 90 con tantos derivados de UNIX.

» autor: aspirador

#14 OpenStreetMap migra su infraestructura a Debian

soberao — Sat, 30 Nov 2024 20:35:37 +0000

#13 Systemd está pensado para Linux, no hay cgroups fuera de Linux y sin esto systemd no tiene sentido.
No uso systemd porque va en contra de la diversidad de sistemas operativos, lo mismo hace Microsoft, que está en contra de la diversidad y la libre competencia. Systemd se puede usar en Windows 11 pero no se puede usar en UNIX tradicionales que siguen respetando los estándares como POSIX, más motivos para no usar este software en entornos UNIX-like: learn.microsoft.com/en-us/windows/wsl/systemd
Las distros con systemd son distros generalistas, no son las que está innovando estos días, las distros que van sin systemd como Gentoo, Alpine Linux, Void, Devuan y otras, son mucho más interesantes para saber cómo funciona un sistema operativo y como funciona por dentro.

» autor: soberao

#13 OpenStreetMap migra su infraestructura a Debian

aspirador — Sat, 30 Nov 2024 19:26:17 +0000

#12 También discrepo: una vez más, el sustituto de init sí es específico al usar llamadas a sistema específicas de Linux, pero todo lo demás trabaja mediante interfaces DBus, y se pueden escribir alternativas que ofrezcan la misma interfaz pero que funcionen en BSD. La prueba está, por ejemplo, en logind: tanto Gnome como KDE lo usan para gestionar la sesión, y al principio se decía que eso los hacía dependientes de systemd y que impediría que se pudiesen usar en BSD. Sin embargo, la gente de BSD "sólo" (sí, vale, no es algo que se haga en una tarde, por eso lo puse entre comillas) tuvo que hacer que su gestor de sesiones expusiese la misma interfaz DBus que logind, y el problema estuvo resuelto.

No podemos olvidar que el UNIX original se escribió para una máquina de 16 bits, con un máximo de 256KBytes de RAM y sin memoria virtual. Ni que la gente venía de trabajar con sistemas de gestión por lotes y muchos era la primera vez que trabajaban con un sistema de tiempo compartido. Muchas de las reglas y las formas de trabajar no son adecuadas hoy en día.

Y ya lo de Poettering... lo siento, opino que tu odio hacia Microsoft (que comparto en muchos aspectos) te ciega. Systemd se lanzó en marzo de 2010 ( 0pointer.de/blog/projects/systemd.html ); Debian y Ubuntu, que fueron de las últimas distros en cambiar de sysvinit a systemd, lo hicieron a principios de 2014 (lignux.com/ubuntu-sigue-los-pasos-de-debian-y-cambiara-a-systemd/ ) . IBM compró RedHat en 2019 (www.redhat.com/en/about/press-releases/ibm-closes-landmark-acquisition ). Y por último, Poettering se fue a Microsoft en 2022 (www.muylinux.com/2022/07/07/lennart-poettering-microsoft/).

Y no, systemd no tiene absolutamente nada que ver con "administración con programas gráficos", ni con no necesitar saber cómo funciona el sistema por dentro.

» autor: aspirador

#12 OpenStreetMap migra su infraestructura a Debian

soberao — Sat, 30 Nov 2024 16:54:31 +0000

#10 Yo el problema que tengo con Systemd es que deja fuera a los BSDs y que deja obsoletos libros sobre UNIX que han estado contando lo mismo hasta que llegó Systemd y reinventa la rueda. No solo es el inicio sino que un montón de herramientas las fagocita y ahora funcionan a su manera, no es un simple cambio sino que es mucho más complejo.
Por ejemplo, en arm64 me bajo una imagen Debian y la paso a Devuan quitando systemd, etc y no solo cambia el inicio, sino que también deja de funcionar la red, no es quitar uno por el otro sino que es un cambio mucho más profundo. Luego también toca como se monta las particiones, el tema de chroot, el tema de los permisos, de los procesos en segundo plano. Un montón de movidas que para un escritorio no te afecta, pero para el tema de servidores que se administran con ssh te lo rompe todo y lo deja como un sistema experimental.

Y luego que Poettering trabaje para Microsoft no es una tontería sino que es la prueba que este cambio no es un cambio técnico sino político y va en la misma línea de los cambios que ha ido potenciando Microsoft, de quitar importancia a la terminal y la administración sin gráficos y potenciar todo lo que sea administración con programas gráficos, donde el usuario no tenga que tocar nada él mismo, ni tenga que saber nada de como funcionan las cosas por dentro y se limite a tocar cuatro historias básicas que te hace la abstracción del programa gráfico que te administra el servidor. Es un cambio político donde el hacker deja de tener importancia para pasar a ser el servicio tecnico que te ofrece la empresa la que te resuelve la papeleta, eso sí, sin depender de tus técnicos y dependiendo del servicio técnico propio que te vende Microsoft y otras multinacionales del software.

» autor: soberao

#11 OpenStreetMap migra su infraestructura a Debian

soberao — Sat, 30 Nov 2024 16:43:23 +0000

#10 "que sí es muy interesante de cara a arranques rápidos,"
En servidores que con systemd te reinicie en 7 segundos y con sysvinit te reinicie con 10 tampoco marca ninguna diferencia y más cuando un servidor reiniciarlo es cuando cambias de kernel, lo ideal es reiniciarlo lo menos posible y que se mantenga funcionando sin problemas la mayor parte del tiempo.

"Respecto a la "incompatibilidad con otros sistemas Unix"... tal vez deberíamos recordar que el propio Stallman, a finales de los 80, ya dejó bien claro que no se buscaba "ser Unix". O sea... "GNU's not Unix"... "
Stallman no rompió la compatibilidad con las herramientas de Unix, GNU is not UNIX pero las herramientas de GNU funcionan en distintos UNIXs sin problemas, en cambio systemd no puede funcionar en los BSDs porque no es portable ni es compatible con UNIX funciona solo en linux y nada más. Hasta ahora un cambio de herramienta servía también en otros Unix-like hasta que llegó systemd que dejó fuera a todo lo que no fuera Linux. Y esto no es "filosofía" sino que es compatibilidad y portabilidad, no se puede portar a otros sistemas, es como portarlo a Windows.

» autor: soberao

#10 OpenStreetMap migra su infraestructura a Debian

aspirador — Sat, 30 Nov 2024 15:53:11 +0000

#9 Hombre, a ver... una cosa es "Systemd, el proyecto paraguas", que tiene muchas cosas que pueden no ser necesarias en un servidor, y otra diferente es "el sustituto del PID1 de Systemd".

Estoy de acuerdo en que hay muchas cosas que no necesitas de "Systemd-proyecto" en un servidor, pero yo hablo fundamentalmente del sustituto del PID1, que fue el origen de Systemd. De hecho, muchas de esas partes extra de Systemd están en paquetes separados, por lo que no necesitas instalarlos si sólo quieres usar el nuevo init, que sí es muy interesante de cara a arranques rápidos, cosa que en un servidor no está de más para reducir al mínimo los tiempos en que el servidor no está disponible por mantenimiento; además, el hecho de que las dependencias se manejen de manera implícita simplifica muchísimo el mantenimiento.

Respecto a la "incompatibilidad con otros sistemas Unix"... tal vez deberíamos recordar que el propio Stallman, a finales de los 80, ya dejó bien claro que no se buscaba "ser Unix". O sea... "GNU's not Unix"... Y, de hecho, él mismo recomendaba a los programadores del proyecto hacer las utilidades GNU mucho más complejas y versátiles que sus equivalentes originales (si no ¿por qué 'ls' permite filtrar por nombre de fichero, u ordenar la salida, cuando todo eso, según la "filosofía UNIX", se debería hacer con pipes, grep y sort, por ejemplo?). Y en Linux, pues más de lo mismo: hay un montón de Syscalls que no son POSIX. Según ese argumento, no deberían permitirse tampoco porque cualquier biblioteca o programa que las use no será compatible con otros Unixes.

Y respecto a que Poettering trabaje para Microsoft... para empezar, Systemd lo empezó cuando trabajaba en Red Hat, y toda la parte del reemplazo de PID1 la hizo ahí, y ya entonces se criticaba a Systemd; además de que es un argumento Ad Hominem. Por otro lado, $DEITY me libre de defender a Microsoft, pero tienes que reconocer que la Microsoft actual ya no es la misma que en los 90, cuando Gates y Ballmer la controlaban. De hecho, le interesa muchísimo que Linux funcione bien en Azure si quiere que de dinero, porque prácticamente nadie utiliza Windows en servidores (motivo por el que está metiendo tanta pasta en Linux).

Honestamente, creo que el verdadero problema con Systemd no es tecnológico, sino simplemente que la gente no soporta a Poettering (y esto último lo puedo entender después de algunas de sus "sobradas históricas").

» autor: aspirador

#9 OpenStreetMap migra su infraestructura a Debian

soberao — Sat, 30 Nov 2024 15:24:23 +0000

#8 Systemd es un programa estable pero en desarrollo y que abarca demasiadas cosas críticas y que cada día amplía servicios y los problemas asociados a tomar nuevas funciones que no estaban antes.
En un servidor quieres tener lo mínimo y si hay algún problema tener claro qué ha fallado y no perder mucho tiempo con los cambios y bugs que introduce el desarrollo de systemd. Aparte del volumen que ocupa, que para el tema de contenedores y virtualización es importante y la incompatibilidad con otros sistemas Unix fuera del ámbito de las distros Linux.
Luego ya metiéndote en política, el desarrollador principal trabaja para Microsoft, es decir, en la competencia.

» autor: soberao

#8 OpenStreetMap migra su infraestructura a Debian

aspirador — Sat, 30 Nov 2024 14:35:17 +0000

#3 ¿Y exactamente por qué está bien prescindir de systemd en servidores?

» autor: aspirador

#7 OpenStreetMap migra su infraestructura a Debian

soberao — Sat, 30 Nov 2024 12:40:46 +0000

#4 Luego también Devuan en la instalación te da la opción de elegir entre distintos inits cosa que Debian no hace, te instala systemd de fábrica y si quieres otro init te complicas tu solo. No es un uso mínimo cuando cambiar de init te deja el sistema roto y no es cosa que un usuario normal pueda hacer, sino que hace falta luego darle muchas vueltas para dejarlo de nuevo operativo. Por eso es mejor instalar directamente Devuan pero en sistemas como Arm64 no siempre es posible instalar desde Devuan sino que tienes que empezar con una imagen de Debian y luego poner a intentar que todo funcione más o menos tras quitar la instalación de Systemd y sus dependencias.

» autor: soberao

#6 OpenStreetMap migra su infraestructura a Debian

Malinke — Sat, 30 Nov 2024 10:10:34 +0000

Yo uso este.

» autor: Malinke

#5 OpenStreetMap migra su infraestructura a Debian

soberao — Sat, 30 Nov 2024 09:44:10 +0000

#4 Devuan no es ninguna complicación. La instalación es la misma y no tienes que hacer nada más. El único problema es que los manuales, tutoriales y wikis se van centrando solo en Systemd, pero Debian nunca se ha caracterizado por tener buena documentación, incluso muchas veces para encontrar algo es mejor poner la palabra Ubuntu en el buscador que Debian.

» autor: soberao

#4 OpenStreetMap migra su infraestructura a Debian

abnog — Sat, 30 Nov 2024 08:59:34 +0000

#3 Debian hace un uso tan mínimo de systemd que ni merece la pena la complicación de usar devuan. Sólo mete por defecto un sistema init (que por sorprendente que parezca está muy bien), uno de network fácilmente desactivable, udev, y de logs corriendo en paralelo al tradicional. Y eso es todo (si recuerdo bien).

» autor: abnog

#3 OpenStreetMap migra su infraestructura a Debian

soberao — Sat, 30 Nov 2024 08:04:03 +0000

Para el tema de servidores está bien prescindir de Systemd como hace Alpine Linux y otras distros orientadas a entornos virtuales y servidores. Systemd solo es para entornos gráficos de escritorio y tampoco queda clara sus ventajas.
Por ejemplo, tienes la distro Devuan que es Debian sin Systemd, modifican sólo los paquetes necesarios para quitar las dependencias con Systemd y el resto son los mismos paquetes.
www.devuan.org

» autor: soberao

#2 OpenStreetMap migra su infraestructura a Debian

neo1999 — Sat, 30 Nov 2024 07:55:11 +0000

Pego aquí uno de los comentarios del envío que habla sobre la debilidad de Ubuntu Server.

He usado Ubuntu Server desde la 14.04, de hecho hoy día uno de mis ex-clientes aún tiene el sistema que implementé por allá en el 2015 funcionando, obvio dentro de una red VPN que le implementó otro proveedor, funcionando en VirtualBox en un ThinkCentre (PC Workstation) con Windows 7 por allá tirado en el rack de servidores, sin siquiera pasarle un trapito para limpiarlo, y funciona perfectamente, en una VM. Tristemente en esta 24.04 sufrí muchos problemas hace poco por quien sabe que actualización que hacía que todas las conexiones SSH cerraran abruptamente, y que el tráfico de entrada y salida se cortara también inesperadamente, al principio pensé que era problemas de firewall de la compañía, las reglas y nada, reinstalando paquetes y nada, tocó montar una nueva instancia de Ubuntu 24.04 y volvió a presentar lo mismo, estaba loco, no sabía entonces qué carajos era, y decidí como Usuario de Debian que soy, poner Debian en lugar de Ubuntu Server porque necesitaba una distro que me diera confianza, la misma que le tenía a Ubuntu Server, pero que en ese momento no podía brindarme, y que todo hasta el día de hoy funciona perfecto en Debian 12.

Tengo que decir que con Ubuntu 20.04 y 22.04 no tuve el problema, pero ahora estoy usando Debian hasta para los servidores, no sé qué habrá sucedido, pero fue caótico, fueron literalmente momentos de mi3rda que no le deseo a nadie.

No hay duda que Ubuntu en especial Ubuntu Server con snap me hicieron la vida más fácil en estos aspectos, pero hoy día he decidido que todos los servidores que me toque implementar siempre como primera opción será Debian.

Creo que los de OpenStreetMap también pasaron por algo parecido para haber tomado esa decisión.

» autor: neo1999

#1 OpenStreetMap migra su infraestructura a Debian

Torrezzno — Sat, 30 Nov 2024 07:20:45 +0000

Interesante. Ya la tendencia es irse a arm64 que es más barato.

» autor: Torrezzno