#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?
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… » ver todo el comentario
#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).
#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.
#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
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.
#5 WSL es una forma de probar y testear programas para linux sin salir de windows. Lo que MS quiere es mantener el ecosistema de desarrolladores anclados a windows, y cuando su negocio se basa cada vez más en la nube y servicios que van en linux, es la única manera de hacerlo.
Por otro lado, WSL y WSL2 empezaron sin usar systemd y si lo han incorporado es porque mejora y facilita muchísimo la administración de sistemas en linux y la gestión de procesos y contenedores, y hay muchas alternativas viables a systemd en linux (que nadie te obliga a usar).
#6 Es que simplemente hay que pensar que para producir hidrógeno primero hay que quemar petroleo o gastar electricidad. ¿En qué cabeza cabe que poner un intermediario vaya a ser mejor que hacer algo directamente?. Si se hubiera invertido en almacenamiento energético lo que se ha invertido en hidrógeno, cuya única ventaja es que no se pierde durante el transporte (comparado con la electricidad, que lo suyo es que se produzca directamente en destino y las redes de distribución queden como elementos de redundancia y seguridad, con lo cual tampoco el hidrógeno tendría esa ventaja), otro gallo nos cantaría. Y Cosas como baterías intercambiables podrían solucionar sin problemas el único punto débil de la electricidad para motorización: los tiempos de recarga.
"Según los cálculos de T&E, en el simple hecho de generar el hidrógeno (siempre de fuentes renovables) ya hay un pérdida notable de energía que sitúa el hidrógeno para un vehículo fuel cell en un 61 % de eficiencia. Y eso que aún no ha llegado al depósito del coche, frente a un 95 % de la electricidad. Añadiendo luego el transporte y la distribución hasta el consumo final por parte del vehículo, llegaríamos a un 30 % de eficiencia energética para el hidrógeno y un 77 % para el coche eléctrico (y un 13 % para un coche de gasolina o diésel)."
Más eficiente que un gasolina, ¿pero a qué precio, sobre todo habiendo tecnologías mejores?
#11 La eficiencia debería subir a un ritmo muchísimo mayor no sólo para evitar el decrecimiento, sino simplemente para afrontar una "estabilización".
Dicho esto, la electrificación y las baterías no serán la solución para evitar el decrecimiento (hay que decrecer o decrecer), pero si (por física) suponen un aumento de eficiencia lo suficientemente grande como para que sean sustitutas de las tecnologías basadas en combustión y combustibles fósiles. Y vamos con mucho retraso.
#41 Un desgraciado es un don nadie que se come los marrones de otro, este llegó a jefazo y mandaba y hacía y deshacía a su antojo (de ahí todo lo que ha pasado luego), no parece el típico perfíl del desgraciado.
Como bien dices, ha hecho cosas peores y no le han empurado. ¿Qué problema hay con que lo empuren por esto? al menos que pague por algo... si verlo esto como un beso no te parece grave, míralo como un acto de soberbia, prepotencia, manipulación, acoso y chantaje... ¿sigue pareciéndote poco grave? ¿te vale esto para que lo empuren?
#16 ¿Y cuánto dinero se ganará, tanto en fútbol masculino como femenino, si las mujeres se unen a eso de gusatarle masivamente el fútbol? ¿por qué hay tanto miedo a que se incorporen? ¿te van a desplazar? el futuro es el que es, querer apartar, perjudicar o menospreciar el fútbol femenino (y a todo lo femenino en última instancia) es lo que está llevando a esta revolución social. Y está pasando precisamente porque de ser algo minoritario empieza a tener un seguimiento muy importante. Si esto hubiera ocurrido en la selección femenina española de curling ¿crees que hubiera tenido alguna repercusión? ¿por qué te crees que ha tenido impacto, sino porque una gran cantidad de población ha visto lo que ha pasado en directo y no puedes cambiarle lo que ha pasado blanqueando y mintiendo así como así, como se ha hecho siempre, incluso con montajes y declaraciones oficiales falseadas?
#1 Windows le sirve a MS como punta de lanza para añadir tecnologías perjudiciales para los usuarios y que lleguen rápidamente a las casas de la gente de a pie. Por lo demás, hoy en día MS gana más pasta con linux que con windows... al final las empresas defienden aquello que les da pasta...
#11 Y todos los ataques que ha habido contra la GPL y la filosofía del software libre en general, sobre todo del software libertino, que se cree que dar "más libertad" garantiza los derechos de los usuarios finales, que son siempre los grandes perjudicados, cuando es al revés, sólo beneficia a las grandes corporaciones, esas que siempre toman y nunca aportan a los demás, las de los jardines vallados y del que no seas dueño de lo que compras (o más bien alquilas).
El cuerpo del mensaje puede ser html y css, lo del spoiler, encuestas, emojis, etc. está más que superado...
El problema de jabber nunca fue el protocolo en si, sino todos los que cogieron ese protocolo y se montaron su propio chiringuito independiente, no por querer innovar, sino por un trozo del pastel de la mensajería instantanea, por tener su propio patio vallado.
Está claro que hay dos cosas que van a marcar el punto de inflexión en el mercado de los coches: el coste y la autonomía.
Actualmente el coste de la energía eléctrica puede empezar a ser menor que el de los combustibles fósiles. Pero cuando una carga de batería dure más que un depósito de gasolina (que además será más barata), ahí si que empezarán a cambiar las cosas.
Y aún quedaría el tema del peso y espacio, pero es probable que se nivele un tanto con el tiempo o pase a ser completamente despreciable.
#121 Depende de la licencia del protocolo. Si es una licencia libre tipo GPL, tienen que publicar los cambios y todo el mundo sale beneficiado. Si es una licencia libertaria de esas que te dejan hacer lo que quieras (a costa del usuario, para las empresas estupendo), pueden hacer cambios o usar extensiones propias y cerradas del protocolo para según qué funcionalidades, que mientras lleguen a los demás llos mensajes y puedan justificar que hay interoperabilidad mientras te guardas cosas guays para ti solo, la ley es ineficaz.
Por otro lado, lo que están haciendo muchos es usar activitypub, que abre la interoperabilidad de tus publicaciones a todo tipo de aplicaciones de terceros. Esta es la via, protocolo abierto, datos abiertos, nada de jardines cerrados.
#77 ¿Qué innovación vas a frenar? puedes hacer lo que quieras con él. De hecho, es lo que se hace. Lo que pasa es que no quieres compartir la innovación con todos los demás (pero bien que te aprovechas de todo el trabajo comunal hecho), así que cierras tus cambios al protocolo y a los demás y a tomar por culo todos.
#2 Quizá la alegoría de las dos españas es lo que nos han intentado vender toda la vida... ¿qué sería de algunos colectivos sin un enemigo a quien señalar?. Mientras unos hacen por españa, los otros hacen por medrar... (y aquí no tiro de bandos o lados, tiro más de personas que usan esos bandos o lados para medrar a costa de todos los demás).
#21 no se hace porque tener dos controladoras de memoria y sincronizar todo eso dentro y fuera y con las cachés por medio... será un infierno si lo hacen y habrá más problemas de protección y acceso a memoria (vulnerabilidades y más complicadas de remediar) dudo que se metan en esos berenjenales. No sé cómo lo arreglarán, pero casi que pienso que nos podemos olvidar de ampliar memoria en estos casos.
¿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: github.com/jochasinga/systemd-parser y si quieres verlo en detalle, puedes ver que es muy simple: github.com/jochasinga/systemd-parser/blob/master/src/parser.rs). Y tampoco se inspiró directamente en .ini, sino en 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… » ver todo el comentario