#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.
#4 Como os gusta a las izquierdas dinamitar obras de arte
Luego sois muy respetuosos con el medio ambiente
Por eso Alemania lleva 30 años limpiando el vertedero tóxico que le dejo la RDA en Alemania del este
#3 Rusia bloqueó Telegram por no mostrar datos al gobierno, y la desbloqueó dos años después sin ninguna explicación. Abunda la información al respecto que puedes consultar con una simple búsqueda, no soy un Pavel Rubtsov.
#78 Estoy básicamente de acuerdo con lo que dices. yo también pienso que es más importante y efectivo que la policía haga su trabajo. Solo digo que esta medida no se le hubiera ocurrido a nadie si la gente fuera educada y respetuosa, y también si la policía hiciera su trabajo por supuesto.
#71 Lo único que dice es que no quiero que un maleducado egoísta desgracie la vida de un anciano porque le partan la cadera o algo peor, y que encima el culpable no pague las consecuencias. Las normas que dices no se hacen cumplir, y gran parte de la gente no tiene educación y respeto, así que repito, tienen lo que se merecen, aunque paguen justos por pecadores. Y el que va cumpliendo las normas, poco tiene que temer, como dicen por ahí, incluso te incluyen la bici o el patinete en el seguro de hogar.
#3 A eso venía yo, no estamos hablando de violar a bebés de 1 año #4 la tenencia... que no distribución, es delito? Lo digo porque la curiosidad más morbosa (que no te ponga, pero sí quieras verlo) de ver gore en sus distintas formas, está ahí, entre los que me incluyo
#12 ya veo que la posesión es delito.
Pregunto, es delito tener material de asesinatos y otros delitos que no sean sexuales?
#4 Mira, Torbe me parece un puto asqueroso. No por un punto de vista postmoderno, o puritano. No. Es que me da un puto asco que lo flipas. El ha contado que fué contenido que le encontraron en su carpeta del el emule. Que era una época de emule a saco. Y creo que no era infrencuente bajarte cosas que eran otra cosa diferente, incluyendo pornografía infantil. Aqui mismo he leido gente que lo ha contado. Asi que aunque repito, me parece un tipo repugnante, me creo que era mierda que tenía en la carpeta "incoming" sin control. Pese a todo nunca me ha parecido un tipo turbio en ese aspecto.
#4 te voy a ser sincero, esa parte no la leí y no lo había escuchado nunca hasta hoy, recuerdo o creo recordar leer noticias en su día y de lo que se hablaba era de un video que grabó, creo que en latinoamérica con una chica de 17 años.
#11 No es el mismo caso que eldiario entonces, aquí no da más opción que pagar o aceptarlas (opción usar gratuitamente), pero si en siguiente paso las rechazas o luego de aceptarlas vas a configuración para volver a bloquearlas te vuelve a salir la ventana para pagar si quieres seguir usando la web.
#23 Ya lo sé, está claro que comparan las funcionalidades. Pero es que en este tipo de aplicaciones lo interesante es el volumen de usuarios que las utilizan, más allá de si funcionalmente es una mejor que otra.
La inteligencia de los usuarios no creo que esté relacionada con que usen WhatsApp o Telegram, no entiendo tu comentario
#46 Aquí lo único que ha funcionado es tu sectarismo, ya que criticas pero no aportas pruebas de nada y cuando te dan pruebas de que te equivocas haces un adhominem.
#9 Pero qué fondos se malgastan si dicen que NO VAN A COBRAR NADA. ¿Qué malgastas? Igual hay que exigir que la tan cacareada sanidad pública esté mejor. Incluso se podría crear un organismo para que la gestione de manera eficiente y reparta recursos como convenga, que podríamos llamar MINISTERIO DE SANIDAD
#9 "¿Qué empresas son exactamente "La sanidad privada"? No veo nombres"
Sin leer la noticia es dificil ver nombres....
"Así lo ha indicado el Instituto para el Desarrollo e Integración de la Sanidad (IDIS)....
El ofrecimiento del IDIS coincide con lo expuesto por el presidente de la Alianza de la Sanidad Privada Española (ASPE) que ha contado Invertia. Su presidente, Carlos Rus..."
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.