OpenStreetMap migra su infraestructura a Debian

OpenStreetMap es uno de esos proyectos de fuente abierta muy importantes, pero que pasa muy desapercibido para el común de los mortales porque aunque es ampliamente utilizado por mil y una aplicaciones, el usuario medio suele tirar, sobre todo, de Google Maps. Y lo digo con cargo de conciencia, porque medios como este tendríamos que prestarle más atención.

[#3 soberao]

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

[#4 abnog]

#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).

[#5 soberao]

#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.

[#7 soberao]

#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.

[#8 aspirador]

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

[#9 soberao]

#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.

[#10 aspirador]

#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…   

[#11 soberao]

#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

…   

[#12 soberao]

#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…   

[#13 aspirador]

#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…   

[#14 soberao]

#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:…   

[#15 aspirador]

#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…   

[#16 soberao]

#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…   

[#17 aspirador]

#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…   

[#18 soberao]

#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…   

[#19 aspirador]

#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…   

[#20 soberao]

#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.

[#2 neo1999]

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

…   

[#6 Malinke]

Yo uso este.

[#1 Torrezzno]

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