#37 Como bien dice en el vídeo, ahora que, gracias a la publicación de sus caras han podido identificarlos, ya han puesto la denuncia correspondiente en comisaría.
#25 Gracias por la explicación. Me olía que podía ser algo así, pero la verdad es que sorprende que a día de hoy pase algo así de manera "no puntual" en un teatro que se supone profesional.
#22 Ops... tienes razón, respondí a quien no era. De todas formas, el vídeo ya lo vi esta mañana y, simplemente, "no entran en detalles". Por eso preguntaba.
(lo del grupo nazi sí lo comentan, pero eso fue más bien la gota que colmó el vaso).
#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.
#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… » ver todo el comentario
#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.
#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 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.
#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").
#41 No acaba en la leche materna, sino que o lo absorben por la piel porque toca en la calva al padre (o las manos del padre, si no se las lavó bien después de aplicárselo), o lo traga por lamer al padre donde se lo aplicó.
#18 ¿Pero el INE no lo publica mes a mes? O sea, ahora mismo ha publicado el "IPC adelantado de noviembre" porque, obviamente, aún no ha terminado el mes, pero el de octubre sí debería ser definitivo ¿no? ¿O son datos "no oficiales"? (pregunta sincera; por lo que dices, parece que tienes más idea que yo).
#17 Hombre, lo de "abusiva" lo digo porque dependería de la publicidad. Por ejemplo, con el famoso "para siempre" de Movistar, esa cláusula sí sería abusiva... a eso me refería.
Por otro lado, ese es MI contrato, que es de O2. He buscado el de Vodafone y pone esto, que viene a ser lo mismo:
El Contrato podrá ser modificado por Vodafone, previa comunicación al Cliente con un (1) mes de antelación mediante MMS, SMS, correo electrónico, factura u otro medio de comunicación individualizada disponible cuando se produzca un cambio en el Servicio, en sus Condiciones, tarifas o en la normativa aplicable. Además de la comunicación, Vodafone procederá a la publicación del cambio en la Web. El Cliente podrá resolver anticipadamente el Contrato sin penalización alguna en caso de que no esté de acuerdo con la modificación. Si el Cliente sigue utilizando el Servicio una vez entrado en vigor el cambio, se entenderá que está de acuerdo con el mismo.
#6 Hombre... yo entiendo que si hay una cláusula específica que indica que te pueden subir cada año lo que suba el IPC, como dice #4, no hay modificación del contrato porque esa cláusula ya estaba ahí cuando la firmaste.
Dicho esto, a mí no me suena haber visto nunca esa cláusula... aunque a lo mejor me leí demasiado por encima el contrato. Ahora me ha picado la curiosidad...
Ok, he revisado mi contrato y dice dos cosas: por un lado, que tienen derecho a aumentar el precio en base a:
* Incremento de los costes del sector empresarial en el que esté presente O2 y que redunden en la cobertura, en la calidad de la red o en las características del Servicio prestado.
* Modificaciones normativas (incluyendo impuestos, tasas o resoluciones administrativas o judiciales) que afecten a las condiciones de prestación del Servicio.
* Incremento del índice de precios al consumo (IPC) o en su defecto del índice de precios Industriales (IPRI)
Pero justo después hay otra cláusula en la que dice que cualquier aumento de precio será comunicado con un mes de antelación, y que el cliente podrá resolver el contrato sin penalización alguna si no lo acepta.
La duda, por tanto, es si podrían subirlo sin posibilidad de rescisión si la segunda cláusula no existiese pero sí la primera... ¿sería una cláusula abusiva? ¿Algún abogado en la sala?
#9 Justo eso iba a decir: la pintura parecía más bien verde, y tras comprobar, veo que en zona verde de Cienpozuelos sólo pueden aparcar residentes, lo que significa que ni zona azul ni ticket ni leches. x.com/TirodeGraciah/status/1857105783156048115
#29 Claro, hombre, claro... ¿Y cuando tenía que habérselo quitado? ¿A la mañana, cuando aún no habían empezado las inundaciones? ¿A la tarde, cuando aún había tiempo para empezar? ¿A la noche, cuando el ejecutivo de Mazón por fin se puso las pilas y empezó a actuar?
No es tan sencillo como con el corona. Para empezar, lo que pasó era algo específico de la zona, no global como con el virus. Se supone que sabe mejor qué hay que hacer alguien de la zona que no alguien de Madrid. Además, propones hacer el cambio de un equipo a otro en mitad de la desgracia, lo que no tiene ningún sentido. Con el corona ya se estaba viendo qué iba a pasar, y el gobierno central se fue preparando, pero en este caso el que se tenía que haber preparado, pues eran sus competencias, era el gobierno de Valencia. Cambiar un equipo por otro no es como quitar una bombilla y poner otra en su lugar: el nuevo equipo necesita tiempo para entender la situación. A toro pasado es fácil decirlo, pero en aquel momento el gobierno no tenía motivos para suponer que el equipo de gobierno de Mazón era tan inútil.
El gobierno central hizo lo que tenía que hacer, que fue ofrecer una y otra vez sus recursos, hasta el punto de, literalmente, suplicar que les hiciesen caso. Los responsables son el equipo de Mazón, con él a la cabeza.
#9 Escucha bien, porque al principio hay una frase que se puede malinterpretar, que puede parecer que dice que es mentira que maten, pero a lo que se refiere es a que lo que dice Israel son mentiras para justificarse (seguramente falta un cacho de frase antes del vídeo). En realidad le da un repaso de los gordos.
#44 aspirador 
