meneandro

#30 El copro hacía operaciones en coma flotante muy precisas, pero también de manera muy lenta (para los estándares actuales ya ni te cuento). No tanto las operaciones en si (si no hubieran sido rápidas, no tendría sentido) sino la comunicación con el procesador (el procesador se quedaba "bloqueado" a la espera, cedía el control de ejcución al coprocesador por así decirlo y luego lo recuperaba). Esto, como comprenderás, es un lastre muy grande para un juego que quiere mover muchísimas cosas por pantalla muchas veces por segundo.

"nother point not addressed in the existing answers relates to the latency associated with accessing an external coprocessor.

The first math coprocessors, while much faster than doing the same work on a CPU, still took many clock cycles to complete each operation. The overhead (bus cycles) associated with transferring data between the two chips was "lost in the noise". In other words, there was no penalty for putting those functions in a separate chip.

However, as coprocessors got faster, this overhead became a significant bottleneck on throughput, and this is what drove integrating them directly into the CPU chip."

meneandro

#2 Seguiría tratándose los síntomas y no la causa. Pero claro, las guerras de la región y los intereses de segundos y terceros países en las materias primas, etc. son cosas mucho más complejas y delicadas de abordar porque implicaría cuestionar nuestro modelo económico, social y en parte nuestro modo de vida... eso para cualquier político es un suicidio (ya les cuesta ponerle freno a las corporaciones, incluso cuando se demuestra fehacientemente que están violando leyes, acuerdos y regulaciones...)

manzitor

#4 Así es. Estos países no prosperan porque las multinacionales y los estados serviles a las mismas, no les dejan directa o indirectamente. Un país necesita una generación en paz como mínimo para comenzar a desarrollarse. Las migraciones son el trágico efecto secundario de nuestro bienestar.

meneandro

#174 Hay juegos de windows que no funcionan en windows y si en linux...

De todos modos, no es una bala mágica, muchos dependen de implementaciones específicas de ciertas cosas (o sea, se programaron con librerías que tenían bugs de forma que se aprovechaban de ellos o los ignoraban y seguían a sus cosas). Es imposible cubrir todos los posibles casos y hacer que todo funcione (en parte porque la solución sería parchear las aplicaciones que no funcionan bien, no poner mil excepciones en la emulación de esas librerías para cubrir todos los casos).


Fíjate la que se ha armado porque AMD en sus últimos drivers, para poder ampliar el número de juegos que soportan su FSR3 (que como los DLSS, necesita que sean incorporados dentro de los propios juegos, no son una simple "capa" de post procesado) se le ocurrió que los drivers podrían coger e inyectar ese código directamente en los juegos en tiempo de ejecución (así, sin necesidad de que los juegos soportaran FSR 3.0, podías tener FSR gratis). El problema es que ciertos medios y controles antipiratería validan que el ejecutable del juego sea íntegro y no haya sido modificado (para filtrar a los hackers que hacen trampas modificando el propio juego y demás) y esto ha cantado por todos lados y muchos han sido baneados... pero vamos, lo suyo sería eso, parchear el propio juego (algo así como lo que hace gog para que ciertos juegos antiguos puedan funcionar en equipos nuevos).

deabru

#187 eso implicaría trabajo por parte de las desarrolladoras, y visto como está la industria acaba siendo complicado.

Pero sí, sería lo mejor.

meneandro

#181 ¿Y qué tiene que ver el kernel con eso? justamente el kernel es la parte más conservadora de todo el sistema. Probablemente aún funcionarían cosas hechas incluso para kernels viejérrimos como los 2.4 o 2.6 en equipos actuales. ¿Qué pasa? las librerías... nadie programa a pelo sólo usando interfaces de kernel, todo el mundo echa mano de librerías, y estas mueren, cambian, se abandonan, mutan... es lo que hace que los programas dejen de funcionar en linux (o en windows... ¿o acaso cuando hay cambio de versión no hay cosas que dejan de funcionar?).

meneandro

#164 Entonces en lugar de ir a por wine/proton, tira de codeweavers. Es wine/proton, pero de pago y orientado al software en general. Y con el soporte, tienes la potestad de hacer que los desarrolladores se centren en el software en concreto que necesites que funcione (evidentemente si valve les paga para desarrollar proton y parchear los juegos más recientes, ellos van a soportar los juegos más recientes en proton; si tú les pagas para que funcione X, pues buscarán qué es lo que falta o no está haciendo su trabajo y lo añadirán o modificarán). No es tanto que no haya interés, sino que son pocos desarrolladores y no pueden abarcar todo (y si hay empresas o particulares que les pagan para ciertas cosas particulares, evidentemente se enfocarán más en ellas).


NTFS3g llevaba mucho tiempo en desarrollo, pero no estaba lo suficientemente maduro como para permitir que la gente lo usara para el día a día (y por lo tanto, las distribuciones no lo añadían como herramienta por defecto). No es que saliera de la noche a la mañana, es que cuando se consideró usable y estable y que no se iba a comer tus datos, fue cuando se empezó a usar más masivamente.

meneandro

#72 Si quieres de verdad comparar estas cosas, échale un ojo a los benchmarks que se cascan en phoronix.com

Por ejemplo... https://www.phoronix.com/review/windows-linux-mid22adl

Usa el mismo hardware y con sistemas linux "tal cual te lo descargas" y va actualizando cada cierto tiempo con comparativas de todo tipo.

Incluso si no te fías o tienes curiosidad por hacer pruebas tú mismo, puedes usar su sistema de benchmark y realizar las mismas pruebas en tu equipo (tiene perfiles para cada aplicación, normalmente aplicaciones libres y abiertas que pueden descargarse y ejecutarse sobre la marcha o juegos que tienen facilidades para obtener datos de rendimiento; no suelen ser lo último del mercado pero porque la gran mayoría no pueden lanzarse de manera automatizada o le dan los datos que necesita).

meneandro

#38 Yo diría más las steam machines y cuando microsoft amenazó con vallar su windows y hacer que todas las aplicaciones fueran por su tienda. Valve le vio las orejas al lobo y quiso dinamizar y consolizar el mercado para ampliarlo y no depender de windows; el proyecto fue fallido, pero permitió poner en primer plano las limitaciones existentes y darles un toque a los fabricantes (amd estaba en plena transición de drivers y negocio sobre soluciones de software libre, sus drivers daban bastante pena y las cosas potentes y novedosas que se habían sacado de la chistera no les funcionaron por falta de soporte de desarrolladores y de sus propios equipos internos, les pilló en muy mal momento) y replantearse cómo animar a los desarrolladores

Eso es lo que ha llevado a donde estamos ahora: plataforma semiabierta con muchas ventejas y la más completa del mercado sobre SO completamente abierto y un hardware lo más abierto posible, que permite a la gente trastear y desarrollar un ecosistema de aplicaciones propias y optimizarlas sin ningún impedimento o cortapisas. Y eso sin forzar a nadie a elegir desarrollos nativos, con una capa de compatibilidad con windows que asegura que sea fácil y barato que tus juegos funcionen y que si quieres apoyar más directamente el hardware, tengas todas las facilidades para hacerlo (librerías, código, especificaciones abiertas, etc).

deabru

#169 en lo de que lo que hizo a Valve moverse fue el interés de Microsoft por empujar el uso de su tienda, totalmente de acuerdo.

Lo que me gusta de esa capa de compatibilidad, es que puede ser adaptada para juegos de hace 20 años, de hace 10, y actuales. Es una forma de mantener una biblioteca de juegos durante toda tu vida.

meneandro

#174 Hay juegos de windows que no funcionan en windows y si en linux...

De todos modos, no es una bala mágica, muchos dependen de implementaciones específicas de ciertas cosas (o sea, se programaron con librerías que tenían bugs de forma que se aprovechaban de ellos o los ignoraban y seguían a sus cosas). Es imposible cubrir todos los posibles casos y hacer que todo funcione (en parte porque la solución sería parchear las aplicaciones que no funcionan bien, no poner mil excepciones en la emulación de esas librerías para cubrir todos los casos).


Fíjate la que se ha armado porque AMD en sus últimos drivers, para poder ampliar el número de juegos que soportan su FSR3 (que como los DLSS, necesita que sean incorporados dentro de los propios juegos, no son una simple "capa" de post procesado) se le ocurrió que los drivers podrían coger e inyectar ese código directamente en los juegos en tiempo de ejecución (así, sin necesidad de que los juegos soportaran FSR 3.0, podías tener FSR gratis). El problema es que ciertos medios y controles antipiratería validan que el ejecutable del juego sea íntegro y no haya sido modificado (para filtrar a los hackers que hacen trampas modificando el propio juego y demás) y esto ha cantado por todos lados y muchos han sido baneados... pero vamos, lo suyo sería eso, parchear el propio juego (algo así como lo que hace gog para que ciertos juegos antiguos puedan funcionar en equipos nuevos).

deabru

#187 eso implicaría trabajo por parte de las desarrolladoras, y visto como está la industria acaba siendo complicado.

Pero sí, sería lo mejor.

meneandro

#35 Es complicado hacer métricas porque hay muchas cosas que valorar. No sólo influye la cantidad de frames, sino la latencia, el cómo se gestionan los recursos, temperaturas, consumo, etc.

Habrá juegos que vayan mejor en uno y otros que vayan mejor en otro SO. Tampoco es malo que haya competencia y los usuarios tengan elección. Al fin y al cabo, sony usa BSD por debajo de su playstation desde hace algunas generaciones, microsoft sigue con su windows capado en sus consolas y nintendo... sigue a lo suyo, como siempre.

meneandro

#75 Eso es una aplicación, es (hasta cierto punto) independiente del sistema operativo. Y al final usa un protocolo llamado LDAP (que tiene una versión abierta llamada openldap y muchas derivadas) que puede usarse en linux también. Y también usa un protocolo llamado samba (que también puede usarse en linux). Al final, las funcionalidades del directorio activo pueden usarse en linux (y sospecho que el zenyal este no es más que un software que empaqueta e integra estas y otras cosas por debajo).

Linux tiene muchas facilidades para interconectarse y usar otros "directorios de usuarios y recursos" en su sistema de manera transparente...

meneandro

#3 Si hubiese una distro enfocada y optimizada para juegos te daría la razón (lo más cercano sería el SO de la deck, pero aún así puedes salir del modo big picture y tienes el escritorio ahí, preparado y dispuesto para enchufarle un docker con pantalla, teclado y ratón y ya tienes un ordenador completo). Pero las distros más típicas y que usa la mayor parte de la gente son como windows: son sistemas de uso general, con un montón de servicios que quizá no necesites corriendo...

meneandro

#11 Y nunca lo harán. No sé si te has fijado que siguen saliendo versiones de windows y siguen incorporando APIs nuevas...

anv

#163 Si... pero me conformaría con poder ejecutar el software que dice ser compatible con windows 7 por ejemplo.

A mi me parece que con esto pasa lo mismo que con NTFS. Estuvieron durante muchos años con soporte de sólo lectura de NTFS. Cada vez que estaban cerca de sacar algo funcional Microsoft sacaba un windows nuevo con un NTFS modificado. Parecía que nunca iban a alcanzarlos. Algunos sospechábamos que Microsoft sobornaba a gente de ese proyecto para que no avanzaran.

Y un día apareció "de la nada" NTFS3G. Yo no había escuchado hablar de ese proyecto nunca y resulta que de golpe aparecieron con algo perfectamente funcional y que todavía hoy seguimos usando.

A veces he llegado a pensar que con wine pasa algo parecido. Que realmentente no hay interés en implementar lo que falta.

meneandro

#164 Entonces en lugar de ir a por wine/proton, tira de codeweavers. Es wine/proton, pero de pago y orientado al software en general. Y con el soporte, tienes la potestad de hacer que los desarrolladores se centren en el software en concreto que necesites que funcione (evidentemente si valve les paga para desarrollar proton y parchear los juegos más recientes, ellos van a soportar los juegos más recientes en proton; si tú les pagas para que funcione X, pues buscarán qué es lo que falta o no está haciendo su trabajo y lo añadirán o modificarán). No es tanto que no haya interés, sino que son pocos desarrolladores y no pueden abarcar todo (y si hay empresas o particulares que les pagan para ciertas cosas particulares, evidentemente se enfocarán más en ellas).


NTFS3g llevaba mucho tiempo en desarrollo, pero no estaba lo suficientemente maduro como para permitir que la gente lo usara para el día a día (y por lo tanto, las distribuciones no lo añadían como herramienta por defecto). No es que saliera de la noche a la mañana, es que cuando se consideró usable y estable y que no se iba a comer tus datos, fue cuando se empezó a usar más masivamente.

meneandro

#2 Si usa proton, hay capa de compatibilidad. De hecho, como se ponen más recursos y optimización en las versiones de windows de los juegos, no es inusual que incluso habiendo versiones nativas para linux, las versiones windows emuladas vía pronto/wine suelan ser más rápidas...

meneandro

#119 ¿Cómo tienes configurados los logs? a mi me da que estás metiendo más mierda de la que necesitas para lo que sea que necesites...

Por otro lado, mejor que rsyslog usa journalctl, que entre otras ventajas, autoregula el espacio que ocupan los logs y evita tus problemas...

meneandro

#53 ¿Y eso es problema de linux o de los fabricantes que no dan un soporte adecuado a su hardware? igual que mucho se criticaba el windows vista cuando la gran mayoría de problemas que tuvo fueron debidos al pésimo soporte de los fabricantes a los cambios disruptivos que se introdujeron con el SO (mira lo bien que iba todo luego con el W7, que básicamente era un vista más maduro y con un soporte de drivers ya fogueado tras la experiencia con vista, con el que comparte casi todo).

Te falta comentar que Proton es un retoque a un software que ya existía llamado Wine. Que con una capa de emulación de las APIs de windows, en linux las cosas vayan más rápido también dice unas cuantas cosas...

D

#159 Es problema de Linux, porque si en Linux iba hasta cierto kernel y llegado cierto kernel deja de funcionar, es que se han cargado la funcionalidad.

Otra cosa sería que no hubiese funcionado nunca.

meneandro

#181 ¿Y qué tiene que ver el kernel con eso? justamente el kernel es la parte más conservadora de todo el sistema. Probablemente aún funcionarían cosas hechas incluso para kernels viejérrimos como los 2.4 o 2.6 en equipos actuales. ¿Qué pasa? las librerías... nadie programa a pelo sólo usando interfaces de kernel, todo el mundo echa mano de librerías, y estas mueren, cambian, se abandonan, mutan... es lo que hace que los programas dejen de funcionar en linux (o en windows... ¿o acaso cuando hay cambio de versión no hay cosas que dejan de funcionar?).

meneandro

#2 Simplemente está en el gobierno y tienen un problema gordo y tienen que quedar como los buenos y los otros presidentes del pp les están dejando en un feo, así que tiene que salir a cubrirse la espalda y de paso darles un toque de atención a los suyos para que se replanteen su estrategia (que ya ha derivado a cargar contra el gobierno central); hace no tanto hubieran deseado "algo" de inmigración para tener la excusa de pedir pasta al gobierno central (cosa que han hecho en todos los frentes, incluso han renunciado a su tan cacareada bajada de impuestos, lo que les hizo subir al poder), pero es que lo que les ha caído desborda a cualquiera. No hace tanto criticaban mucho al gobierno anterior (y aún lo hacen, ya sabes, la herencia recibida)...

Como ejemplo: https://www.pplanzarote.es/manuel-dominguez-critica-en-sede-parlamentaria-el-fracaso-de-torres-al-no-conseguir-la-implicacion-de-sanchez-en-la-gestion-de-la-inmigracion-irregular/



O sea, los del pp como siempre bloqueando cualquier medida de solidaridad con los demás, pero ahora como les toca sufrirla están en plan "que soy compañero, coño".

meneandro

#168 "¿Sabes acaso cómo se procesan esos archivos de configuración? ¿Podrías cambiarlo para que lo haga diferente?"
¿Y tú sabes cómo procesa bash sus scripts? en ambos casos tienes los fuentes... ¿no es eso lo importante?

Pero ya que estamos, el formato es muy similar a los .ini de windows, es un formato muy simple incluso para hacer un parser propio (de hecho, hay muchísimos parsers ya hechos, como este: https://github.com/jochasinga/systemd-parser y si quieres verlo en detalle, puedes ver que es muy simple: https://github.com/jochasinga/systemd-parser/blob/master/src/parser.rs). Y tampoco se inspiró directamente en .ini, sino en https://specifications.freedesktop.org/desktop-entry-spec/latest/

Aunque entiendo que tú lo que propones son cambios no en el parseo de los scripts como tal, sino en qué hace cada sección. Si, eso ya es más complejo y hay que meterse en harina, pero ya se cubren todos los casos de uso que se te puedan ocurrir (vamos, hay units para todo tipo de servicios creadas, se han modificado y creado muchos elementos nuevos por el camino; si aún así se echa algo en falta a estas alturas... basta abrir una petición, y como cualquier otro proyecto, si tiene sentido y no está cubierto por alguna funcionalidad ya existente, se pondrán manos a la obra). Igualmente, tú tampoco ibas a ponerte a modificar bash por adaptar cualquier cosa que no te guste o a modificar init para que soporte cosas nuevas o...

Por otro lado, tienes toda una serie de capacidades ya hechas que son difíciles o muy complejas de hacer (y de hacer bien) con sysV init. Que con systemd puedes controlar de manera sencilla los grupos de procesos y restricciones de uso de recursos a grupos o procesos concretos, la activación de units asociada a sockets, montajes, eventos, etc. control preciso de timers (¿has probado a hacer a mano una entrada de crontab que se ejecute cada minuto? se puede hacer, pero de una manera muy fea y con una primera ejecución con delay). ¿Se puede hacer con scripts en bash? por supuesto, pero...

"systemd rompe con un modelo que ha demostrado ser lo más exitoso de la historia: programas pequeños que hacen una sola cosa pero la hacen
bien. "

Pues qué quieres que te diga, en mi ordenador parecen programas pequeños que hacen una sola cosa y la hacen bien...

systemctl, hostnamectl, teamctl, timedatectl, journalctl, systemd-udevd, systemd-logind, systemd-localed, systemd-machined, systemd-ac-power, systemd-cgtop, systemd-detect-virt, systemd-hwdb, systemd-notify, systemd-socket-activate, systemd-tty-ask-password-agent, systemd-analyze, systemd-confext, systemd-dissect, systemd-id128, systemd-nspawn, systemd-stdio-bridge, systemd-umount, systemd-ask-password, systemd-creds, systemd-escape, systemd-inhibit, systemd-path, systemd-sysext, systemd-cat, systemd-cryptenroll, systemd-firstboot, systemd-machine-id-setup, systemd-repart, systemd-sysusers, systemd-cgls, systemd-delta, systemd-gnome-ask-password-agent , systemd-mount, systemd-run, systemd-tmpfiles... (y dependiendo de cómo y qué compiles o qué distro uses, habrá más aún, cada uno haciendo su cosa concreta, como systemd-resolved, systemd-networkd, systemd-boot, etc).

Lo que pasa es que los fuentes de todo esto están todos juntos porque la idea es compartir todo el código posible entre ellos (muchos están relacionados, y las dependencias que pudiera haber tienen que ver más con esto que conque quiera forzarse al usuario a usar herramientas de systemd sí o sí), no hacer lo mismo varias veces de varias maneras distintas, pero luego se generan ejecutables para cada cosa que vayas a utilizar (o no se generan si no quieres perder el tiempo compilando lo que no vas a usar) ¿qué más cercano a la filosofía unix que esto?

anv

#169 ¿Y tú sabes cómo procesa bash sus scripts? en ambos casos tienes los fuentes... ¿no es eso lo importante?

Claro. Son scripts. Se procesan igual que todos los demás.

meneandro

#166 " Mira... llevo usando Linux desde que estábamos en kernel 0.92. Usaba Slackware en aquel tiempo y me llegaba en diskettes porque ni siquiera teníamos internet. Lo uso continuamente como escritorio desde hace más de 20 años y he administrado cientos de servidores a lo largo de décadas."

¿Y? ¿qué tiene que ver el cuánto tiempo lleves usando algo para conocer y valorar con sentido cierta tecnología? a lo que voy es que repites las mismas críticas que tanto se oyen por ahí y que no son ciertas o sólo son ciertas si retuerces mucho las cosas, así que si, hablas de oídas. Los yoamimeparece denotan falta de conocimiento teórico y práctico sobre las alternativas.


" A ver. Tal vez a ti te parezca "sencillo" un archivo de configuración que tiene un montón de líneas que más o menos se entienden. Y claro, cuando te lo dan hecho está bien. Si no te lo dan puedes buscar en google y copiar. "

Te lo dice alguien que ha hecho desde cero servicios para systemd, simplemente mirando un poco la documentación y sin experiencia previa. Así que sí, me parece más sencillo que pelearme con bash, donde si te dejas un espacio donde no debes ya la cosa revienta y no sabes muy bien por qué. Aparte de que toda esa plantilla te la ahorras. Systemd funciona y funciona muy bien en parte porque evita repetir código, cosa que con SysVInit se produce con demasiada frecuencia, y los scripts de arranque son el menor de sus males (y por si no lo sabías, systemd aún sigue siendo compatible y soportando los scripts de SysVInit, así que ni siquiera esto es una ventaja de SysVInit sobre systemd, ni para ti ni para nadie).

anv

#167 ¿Y? ¿qué tiene que ver el cuánto tiempo lleves usando algo para conocer y valorar con sentido cierta tecnología?

Sólo te estoy explicando que tengo muchos años de experiencia. No soy ningún principiante.

Te lo dice alguien que ha hecho desde cero servicios para systemd, simplemente mirando un poco la documentación y sin experiencia previa


Te creo. Yo estoy seguro de que también podría hacerlo. Si hoy en día buscando en google se puede hacer de todo en un ratito. Pero eso no cambia el hecho de que systemd es mucho más opaco. ¿Sabes acaso cómo se procesan esos archivos de configuración? ¿Podrías cambiarlo para que lo haga diferente?

Así que sí, me parece más sencillo que pelearme con bash, donde si te dejas un espacio donde no debes ya la cosa revienta y no sabes muy bien por qué

Te entiendo. Lo que pasa es que yo empecé cuando "pelearse con bash" era la única alternativa, y una vez que aprendes te da un control completo desde el nivel más bajo. Por eso es que lo prefiero antes de que un programa que sólo lee archivos de configuración.

Y repito: systemd rompe con un modelo que ha demostrado ser lo más exitoso de la historia: programas pequeños que hacen una sola cosa pero la hacen bien.

meneandro

#168 "¿Sabes acaso cómo se procesan esos archivos de configuración? ¿Podrías cambiarlo para que lo haga diferente?"
¿Y tú sabes cómo procesa bash sus scripts? en ambos casos tienes los fuentes... ¿no es eso lo importante?

Pero ya que estamos, el formato es muy similar a los .ini de windows, es un formato muy simple incluso para hacer un parser propio (de hecho, hay muchísimos parsers ya hechos, como este: https://github.com/jochasinga/systemd-parser y si quieres verlo en detalle, puedes ver que es muy simple: https://github.com/jochasinga/systemd-parser/blob/master/src/parser.rs). Y tampoco se inspiró directamente en .ini, sino en https://specifications.freedesktop.org/desktop-entry-spec/latest/

Aunque entiendo que tú lo que propones son cambios no en el parseo de los scripts como tal, sino en qué hace cada sección. Si, eso ya es más complejo y hay que meterse en harina, pero ya se cubren todos los casos de uso que se te puedan ocurrir (vamos, hay units para todo tipo de servicios creadas, se han modificado y creado muchos elementos nuevos por el camino; si aún así se echa algo en falta a estas alturas... basta abrir una petición, y como cualquier otro proyecto, si tiene sentido y no está cubierto por alguna funcionalidad ya existente, se pondrán manos a la obra). Igualmente, tú tampoco ibas a ponerte a modificar bash por adaptar cualquier cosa que no te guste o a modificar init para que soporte cosas nuevas o...

Por otro lado, tienes toda una serie de capacidades ya hechas que son difíciles o muy complejas de hacer (y de hacer bien) con sysV init. Que con systemd puedes controlar de manera sencilla los grupos de procesos y restricciones de uso de recursos a grupos o procesos concretos, la activación de units asociada a sockets, montajes, eventos, etc. control preciso de timers (¿has probado a hacer a mano una entrada de crontab que se ejecute cada minuto? se puede hacer, pero de una manera muy fea y con una primera ejecución con delay). ¿Se puede hacer con scripts en bash? por supuesto, pero...

"systemd rompe con un modelo que ha demostrado ser lo más exitoso de la historia: programas pequeños que hacen una sola cosa pero la hacen
bien. "

Pues qué quieres que te diga, en mi ordenador parecen programas pequeños que hacen una sola cosa y la hacen bien...

systemctl, hostnamectl, teamctl, timedatectl, journalctl, systemd-udevd, systemd-logind, systemd-localed, systemd-machined, systemd-ac-power, systemd-cgtop, systemd-detect-virt, systemd-hwdb, systemd-notify, systemd-socket-activate, systemd-tty-ask-password-agent, systemd-analyze, systemd-confext, systemd-dissect, systemd-id128, systemd-nspawn, systemd-stdio-bridge, systemd-umount, systemd-ask-password, systemd-creds, systemd-escape, systemd-inhibit, systemd-path, systemd-sysext, systemd-cat, systemd-cryptenroll, systemd-firstboot, systemd-machine-id-setup, systemd-repart, systemd-sysusers, systemd-cgls, systemd-delta, systemd-gnome-ask-password-agent , systemd-mount, systemd-run, systemd-tmpfiles... (y dependiendo de cómo y qué compiles o qué distro uses, habrá más aún, cada uno haciendo su cosa concreta, como systemd-resolved, systemd-networkd, systemd-boot, etc).

Lo que pasa es que los fuentes de todo esto están todos juntos porque la idea es compartir todo el código posible entre ellos (muchos están relacionados, y las dependencias que pudiera haber tienen que ver más con esto que conque quiera forzarse al usuario a usar herramientas de systemd sí o sí), no hacer lo mismo varias veces de varias maneras distintas, pero luego se generan ejecutables para cada cosa que vayas a utilizar (o no se generan si no quieres perder el tiempo compilando lo que no vas a usar) ¿qué más cercano a la filosofía unix que esto?

anv

#169 ¿Y tú sabes cómo procesa bash sus scripts? en ambos casos tienes los fuentes... ¿no es eso lo importante?

Claro. Son scripts. Se procesan igual que todos los demás.

meneandro

#16 Si ahí te doy la razón, ya desde que se pilló a las petroleras con el carrito del helado se debería haber actuado. Pero la dependencia era tan alta y las alternativas tan pocas...

Y no, ahora no da igual, aún se puede hacer algo. Basta con empezar votando a partidos concienciados y que sepamos que realmente van a hacer cosas. No de los que dicen que van a hacer y no hacen, y desde luego, no a los negacionistas. Cuando pensemos que "no va a servir de nada", recordar que si todos los abstencionistas que no votan "porque no me representan" fundaran un partido y se votaran a si mismos, ganarían las elecciones con mayoría. Alternativas hay, aunque parezcan minoritarias y aunque parezca que se está tirando el voto. No votar si que es tirarlo.

meneandro

#139 ¿En qué lo hace más opaco?
Los scripts de inicio no sólo son abiertos, sino más legibles y entendibles que los de InitV.

No es un ente opaco y oscuro que lo gestiona todo, son una miriada de apliaciones que hacen cosas concretas y que se pueden sustituír por cosas equivalentes (ahí están las interfaces definidas; por poner un ejemplo, desde el comienzo se ha podido sustituír logind por alternativas como elogind para soportar ciertos softwares en sistemas sin systemd).
Los fuentes son abiertos y disponibles bajo GPL2+

"Que quieres que algo arranque en el inicio? Pues tienes que crear un archivo de configuración en tal lugar, después en lazarlo en tal otro."
Estás describiendo cómo crear un servicio de arranque de Init de sysV, donde tienes que crear un script a manoplas que soporte al menos dos funciones (start y stop), copiarlo en un sitio y luego crear enlaces simbólicos en varios sitios más... no vengas con cuentos con systemd porque definir un servicico es incluso más sencillo (crear un archivo unit y refrescar el demonio de systemd para que lo tenga en cuenta).

"Yo preferiría SISV init donde si quieres arrancar algo metes un script y listo."
Que es complicado de debuguear, entender y modificar, sobre todo si llegas a un sistema y los scripts no son tuyos. Dime a ver si no sólo tú, sino casi cualquiera, puede entender y seguir qué hace esto:
[Unit]
Description=exim Mail Transport Agent
Documentation=man:exim(8)
Documentation=https://exim.org/docs.html
Conflicts=sendmail.service postfix.service
After=network-online.target nss-lookup.target
Wants=network-online.target

[Service]
PrivateTmp=true
RestrictRealtime=true
PIDFile=/run/exim4/exim.pid
Environment="EXIMSERVICE=-bdf -q30m" "UPEX4OPTS="
EnvironmentFile=-/etc/default/exim4
ExecStartPre=/usr/sbin/update-exim4.conf $UPEX4OPTS
ExecStart=/usr/sbin/exim4 $EXIMSERVICE
ExecReload=kill -HUP $MAINPID
Type=exec

[Install]
WantedBy=multi-user.target


Que por cierto, también es mucho más sencillo hacer un frontend para systemd si nos ponemos.

"Hay que rebuscar documentación y no se encuentra fácilmente."
Pues no sé de qué hablas... https://www.freedesktop.org/wiki/Software/systemd/
Si vas a toquetear las tripas: https://systemd.io/
Si quieres entender cómo funciona: https://0pointer.de/blog/projects/systemd.html
Si quieres saber cómo crear un servicio: https://www.freedesktop.org/software/systemd/man/systemd.unit.html

Y los cientos de tutoriales que hay por la red si quieres empezar por algo más básico.

Lo siento, pero se ve que hablas de oídas, de lo que otros han dicho por ahí, y que nunca te has puesto en serio a usar systemd como administrador. Si lo hubieras hecho, si hubieras padecido lo que cuesta hacer las mismas cosas con SysVinit, mirarías systemd con otros ojos.

anv

#162 Lo siento, pero se ve que hablas de oídas, de lo que otros han dicho por ahí, y que nunca te has puesto en serio a usar systemd como administrador.

Mira... llevo usando Linux desde que estábamos en kernel 0.92. Usaba Slackware en aquel tiempo y me llegaba en diskettes porque ni siquiera teníamos internet. Lo uso continuamente como escritorio desde hace más de 20 años y he administrado cientos de servidores a lo largo de décadas.

A ver. Tal vez a ti te parezca "sencillo" un archivo de configuración que tiene un montón de líneas que más o menos se entienden. Y claro, cuando te lo dan hecho está bien. Si no te lo dan puedes buscar en google y copiar.

A mi me sigue pareciendo más sencillo y entendible algo así:


case "$1" in
start)
programa
;;
stop)
killall programa
;;
status)
ps afx grep programa
;;
restart)

$0 stop
$0 start
;;
esac

Lamentablemente no puedo poner indentaciones.

Eso sin contar con lo más grave: que systemd rompe con la filosofía unix de hacer una sola cosa por programa.

meneandro

#166 " Mira... llevo usando Linux desde que estábamos en kernel 0.92. Usaba Slackware en aquel tiempo y me llegaba en diskettes porque ni siquiera teníamos internet. Lo uso continuamente como escritorio desde hace más de 20 años y he administrado cientos de servidores a lo largo de décadas."

¿Y? ¿qué tiene que ver el cuánto tiempo lleves usando algo para conocer y valorar con sentido cierta tecnología? a lo que voy es que repites las mismas críticas que tanto se oyen por ahí y que no son ciertas o sólo son ciertas si retuerces mucho las cosas, así que si, hablas de oídas. Los yoamimeparece denotan falta de conocimiento teórico y práctico sobre las alternativas.


" A ver. Tal vez a ti te parezca "sencillo" un archivo de configuración que tiene un montón de líneas que más o menos se entienden. Y claro, cuando te lo dan hecho está bien. Si no te lo dan puedes buscar en google y copiar. "

Te lo dice alguien que ha hecho desde cero servicios para systemd, simplemente mirando un poco la documentación y sin experiencia previa. Así que sí, me parece más sencillo que pelearme con bash, donde si te dejas un espacio donde no debes ya la cosa revienta y no sabes muy bien por qué. Aparte de que toda esa plantilla te la ahorras. Systemd funciona y funciona muy bien en parte porque evita repetir código, cosa que con SysVInit se produce con demasiada frecuencia, y los scripts de arranque son el menor de sus males (y por si no lo sabías, systemd aún sigue siendo compatible y soportando los scripts de SysVInit, así que ni siquiera esto es una ventaja de SysVInit sobre systemd, ni para ti ni para nadie).

anv

#167 ¿Y? ¿qué tiene que ver el cuánto tiempo lleves usando algo para conocer y valorar con sentido cierta tecnología?

Sólo te estoy explicando que tengo muchos años de experiencia. No soy ningún principiante.

Te lo dice alguien que ha hecho desde cero servicios para systemd, simplemente mirando un poco la documentación y sin experiencia previa


Te creo. Yo estoy seguro de que también podría hacerlo. Si hoy en día buscando en google se puede hacer de todo en un ratito. Pero eso no cambia el hecho de que systemd es mucho más opaco. ¿Sabes acaso cómo se procesan esos archivos de configuración? ¿Podrías cambiarlo para que lo haga diferente?

Así que sí, me parece más sencillo que pelearme con bash, donde si te dejas un espacio donde no debes ya la cosa revienta y no sabes muy bien por qué

Te entiendo. Lo que pasa es que yo empecé cuando "pelearse con bash" era la única alternativa, y una vez que aprendes te da un control completo desde el nivel más bajo. Por eso es que lo prefiero antes de que un programa que sólo lee archivos de configuración.

Y repito: systemd rompe con un modelo que ha demostrado ser lo más exitoso de la historia: programas pequeños que hacen una sola cosa pero la hacen bien.

meneandro

#168 "¿Sabes acaso cómo se procesan esos archivos de configuración? ¿Podrías cambiarlo para que lo haga diferente?"
¿Y tú sabes cómo procesa bash sus scripts? en ambos casos tienes los fuentes... ¿no es eso lo importante?

Pero ya que estamos, el formato es muy similar a los .ini de windows, es un formato muy simple incluso para hacer un parser propio (de hecho, hay muchísimos parsers ya hechos, como este: https://github.com/jochasinga/systemd-parser y si quieres verlo en detalle, puedes ver que es muy simple: https://github.com/jochasinga/systemd-parser/blob/master/src/parser.rs). Y tampoco se inspiró directamente en .ini, sino en https://specifications.freedesktop.org/desktop-entry-spec/latest/

Aunque entiendo que tú lo que propones son cambios no en el parseo de los scripts como tal, sino en qué hace cada sección. Si, eso ya es más complejo y hay que meterse en harina, pero ya se cubren todos los casos de uso que se te puedan ocurrir (vamos, hay units para todo tipo de servicios creadas, se han modificado y creado muchos elementos nuevos por el camino; si aún así se echa algo en falta a estas alturas... basta abrir una petición, y como cualquier otro proyecto, si tiene sentido y no está cubierto por alguna funcionalidad ya existente, se pondrán manos a la obra). Igualmente, tú tampoco ibas a ponerte a modificar bash por adaptar cualquier cosa que no te guste o a modificar init para que soporte cosas nuevas o...

Por otro lado, tienes toda una serie de capacidades ya hechas que son difíciles o muy complejas de hacer (y de hacer bien) con sysV init. Que con systemd puedes controlar de manera sencilla los grupos de procesos y restricciones de uso de recursos a grupos o procesos concretos, la activación de units asociada a sockets, montajes, eventos, etc. control preciso de timers (¿has probado a hacer a mano una entrada de crontab que se ejecute cada minuto? se puede hacer, pero de una manera muy fea y con una primera ejecución con delay). ¿Se puede hacer con scripts en bash? por supuesto, pero...

"systemd rompe con un modelo que ha demostrado ser lo más exitoso de la historia: programas pequeños que hacen una sola cosa pero la hacen
bien. "

Pues qué quieres que te diga, en mi ordenador parecen programas pequeños que hacen una sola cosa y la hacen bien...

systemctl, hostnamectl, teamctl, timedatectl, journalctl, systemd-udevd, systemd-logind, systemd-localed, systemd-machined, systemd-ac-power, systemd-cgtop, systemd-detect-virt, systemd-hwdb, systemd-notify, systemd-socket-activate, systemd-tty-ask-password-agent, systemd-analyze, systemd-confext, systemd-dissect, systemd-id128, systemd-nspawn, systemd-stdio-bridge, systemd-umount, systemd-ask-password, systemd-creds, systemd-escape, systemd-inhibit, systemd-path, systemd-sysext, systemd-cat, systemd-cryptenroll, systemd-firstboot, systemd-machine-id-setup, systemd-repart, systemd-sysusers, systemd-cgls, systemd-delta, systemd-gnome-ask-password-agent , systemd-mount, systemd-run, systemd-tmpfiles... (y dependiendo de cómo y qué compiles o qué distro uses, habrá más aún, cada uno haciendo su cosa concreta, como systemd-resolved, systemd-networkd, systemd-boot, etc).

Lo que pasa es que los fuentes de todo esto están todos juntos porque la idea es compartir todo el código posible entre ellos (muchos están relacionados, y las dependencias que pudiera haber tienen que ver más con esto que conque quiera forzarse al usuario a usar herramientas de systemd sí o sí), no hacer lo mismo varias veces de varias maneras distintas, pero luego se generan ejecutables para cada cosa que vayas a utilizar (o no se generan si no quieres perder el tiempo compilando lo que no vas a usar) ¿qué más cercano a la filosofía unix que esto?

anv

#169 ¿Y tú sabes cómo procesa bash sus scripts? en ambos casos tienes los fuentes... ¿no es eso lo importante?

Claro. Son scripts. Se procesan igual que todos los demás.