#6#7 para ser justos la formula es ligeramente distinta:
En el caso de Valencia, si recuerdo bien, el organizador en teoría era una empresa privada (Valmor) a la que la Generalitat avalaba. Valmor quiebra y es el avalista (público) quien paga.
En este caso directamente es una empresa pública la organizadora, la cual se supone que revenderá/cederá la organización del GP a empresas privadas que sabrán sacarle el rédito económico (en teoría: de momento es el ente público IFEMA quien ha puesto la pasta y, que yo sepa a día de hoy, no hay capital privado a la vista).
Es un mero detalle y aunque la formula sea parecida no es del todo igual.
En el caso de Madrid sospecho además que, pufos y pelotazos a parte (que también), es una operación con el cual desde la CAM quieran hacerse con el control de IFEMA por la puerta de atrás (ya que según sus estatutos no pueden estar 2 años consecutivos en perdidas y de ser así entraría una gestora nombrada por la CAM para sustituir la cúpula directiva ordinaria al 33% entre comunidad, ayuntamiento y ¿camara de comercio?)
#7 Si no se almacena cuando hay una producción en exceso, primero pierden las eléctricas y después el usuario, porque el sistema necesitara unas tarifas más elevadas, no será tan competitiva la electricidad en España y eso al final afecta tanto al mercado regulado como al libre.
#23 El DNS seguro no sirve si el bloqueo es a nivel IP en el core (como hace Telefónica), si cortan la IP 104.21.96.1 la única forma de acceder es mediante VPN
#4#5#6#13 La cosa va más por lo que dice #11 y #14. Linus está a favor de Rust en el kernel (de hecho, ha manifestado más de una vez que le encantaría usar los nuevos macs con linux, si acaso no los está usando ya). Otros mantenedores no, cada uno con sus argumentos, más o menos aceptables o debatibles.
Aquí el problema real que hay es que todo esto es muy delicado. Décadas de estabilidad y compatibilidad hacia atrás podrían perderse si se hacen las cosas mal y eso es lo que los mantenedores de C y por extensión Linus no quieren. Pero si es necesario abrir la puerta a rust, no sólo como lenguaje es mejor para el desarrollo de sistemas (al menos a ciertos niveles, interfaces, drivers, parsers, paralelismo... ahí rust brilla) sino porque como suele pasar en estos casos, el integrarlo ha descubierto bugs y puesto de relieve problemas de diseño. A cambio, también ha sido fuente de la introducción de nuevos bugs y problemas, como cualquier reestructuración de código que se precie.
Por lo demás, Rust en el kernel funciona y va bien (ahí está Asahi linux para demostrarlo), el problema es adaptar las viejas interfaces del kernel para que pueda usarse Rust para desarrollar cosas sin romper nada, y eso tiene su miga y no puede ser tomado a la ligera y de ahí los constantes roces entre los desarrolladores de rust, que para poder avanzar y trabajar y desarrollar drivers necesitan que más y más porciones de kernel puedan ser interoperables y accesibles desde rust y los mantenedores que ven que más y más partes de código tienen que cambiar y hacerse más complejas de modificar y mantener porque además de soportar las funcionalidades necesarias para C tienen que soportar las de rust y cualquier cambio puede romper cosas en un lado o en el otro.
Y luego está el tema de los tiempos de desarrollo y aceptación de cambios. Los mantenedores tienen mucho trabajo y los desarrolladores quieren las cosas para ya o hacen modificaciones fuera de los plazos o intentan meter código que no sigue los estándares requeridos... ya el driver de tarjetas gráficas unificado de amd tuvo que ser reescrito y estuvo muchos meses fuera del código del kernel de linux antes de ser aceptada su inclusión por estas cosas y también generó fricciones, pero al final los programadores se plegaron a las exigencias y se integró correctamente y todos salieron ganando. También ha habido problemas con filesystems (reiserfs, más recientemente bcachefs) por querer modificar o añadir código en ciclos donde no se debería, todo por acortar los tiempos de incorporación a costa de provocar roturas, incompatibilidades o problemas en otras partes del kernel no gestionadas por ellos.
El problema aquí es desarrollar sin pensar en que tu trabajo afecta al trabajo de otros, en menospreciar su trabajo, no entenderlo, no respetar sus tiempos y necesidades.
#13 Sigo a Marcan desde hace tiempo, le he visto en conferencias del Chaos Computer Club en Berlín y programando el Asahi en directo y es un verdadero genio. A mí que me dedico a esto desde hace cof años me cuesta mucho seguirle. No sólo es sobrehumano programando y haciendo ingeniería inversa, también tiene una visión de alto nivel del futuro y desarrollo del Linux. Hasta el momento no le he visto soltar ninguna afirmación o incluso opinión, por polémica que sea, que no fuera acertada. Le han hecho caso en el kernel innumerables veces. No creo que sea una batalla de egos como tal, sino un asunto de resistencia al cambio y actitud becerril de grupo. Y eso que a mí el Rust me parece un error, pero si lo defiende con tanto interés, es que es el futuro.
#20 El problema está en que hay un juez del Supremo que quiere cargarse Lawrence v Texas, y hay supermayoría conservadora en el tribunal, así que mejor retirar ese artículo de los libros, no vaya a ser que vuelva a estar en vigor dentro de poco.
Acestream es p2p, solo tienen que abrir un partido de futbol en acestream para ver todas las ips involucradas.