Hay que recordar que la de Redmond reveló en 2019 que el 70% de sus parches en los 12 años anteriores eran correcciones de errores de seguridad de memoria, debido en gran medida a que Windows está escrito principalmente en C y C++. El equipo de Chrome de Google pesó con sus propios hallazgos en 2020, revelando que el 70% de todos los errores de seguridad graves en la base de código de Chrome eran errores de gestión de memoria y seguridad, que está escrito principalmente en C++.
Comentarios
Si lo dice Microsoft, habrá que olvidar el Rust y volver al C
#1 Ostia, venia a decir lo mismo
"el 70% de todos los errores de seguridad graves en la base de código de Chrome eran errores de gestión de memoria y seguridad".
¿Quien co*o ha redactado esto? Es como poner
"La mayoría de los inmigrantes de EE.UU. son centroamericanos e inmigrantes."
#2 Microsoft es esa gran empresa que bien entrados los años 90 seguía sin verle las ventajas al protocolo TCP/IP y nos daba la turra con lo bueno que era el NetBIOS. Están para dar muchas lecciones.
#1 Estos de Microsoft culpando al lenguaje de sus chapuzas. No se podía esperar más de ellos.
#4 Sin mencionar las maravillas del .NET...
#6 El .NET como lenguaje no es tan malo. Es un competidor de Java y es muy portable, así que tiene sus ventajas. Dicho esto, donde esté el código nativo. . .
Cuanto dice que paga por programar con Rust?
#8 Mucho, a mi me llegan ofertas cada semana por encima de 150.000$/año. El problema: el 80% de ellas están relacionadas con Blockchain.
#5 No sé si te dedicarás a esto, pero me huelo que no. Esto no lo dice sólo Microsoft, de hecho son de los últimos en apuntarse al carro. Que C y C++ son un nido infecto de agujeros de seguridad llevamos sabiéndolo desde hace 20 años, o más.
#7 .NET no es un lenguaje, es un runtime + "ecosistema". Pero dejando eso de lado (asumiré que simplificabas), tiene muchos otros problemas, como que su "fundación" no es realmente independiente de Microsoft, y cada dos por tres traicionan a sus desarrolladores, tomando decisiones que los fuerzan a usar las herramientas de Microsoft, en detrimento de otras opciones abiertas y compatibles.
https://isdotnetopen.com/
#9 que problema moral... Con mucho que no me echarán en dos meses serían unos 24k menos impuestos
#11 Me refería al argumento técnico. Comparado con otros sistemas del estilo, no está tan mal. Yo por lo menos lo prefiero por encima de Java.
#1 Microsoft es probablemente la empresa con más experiencia en software de sistema, así que sabe de lo que habla.
#14 Pues si. La han cagado tantas veces que tienen un montón de experiencia.
Mucha c-nilidad (léase con acento americano) veo aquí. Mucho me temo que este es el futuro: a partir de ahora, el software de sistema tenderá a escribirse cada vez más en lenguajes con seguridad de memoria.
Venir en pleno 2022 con que el problema son los malos programadores es no tener ni puta idea de cómo andan las cosas en el mundo en materia de seguridad. Antes estaba la excusa de que no había elección que arriesgarse si querías usar un lenguaje sin recolector de memoria. Pero tras la aparición de Rust eso cambia, y la tendencia va a ser arrolladora: o el lenguaje garantiza la seguridad de memoria, o se irá quedando al margen de los desarrollos más modernos.
#12 Te parecerá una postura de privilegiado, pero sí, es un problema moral de los gordos. Una tras otra, casi todas las empresas metidas en el ajo acaban cerrando, o metidas en follones legales por multitud de causas: lavado de dinero, evasión de impuestos, insider trading, robo, estafa, vulneración de protección de datos, etc.
Y eso sin contar con que han desestabilizado por completo el mercado de producción de chips, procesadores y tarjetas gráficas; o que han aumentado los niveles de contaminación de forma alarmante.
Yo mismo estuve en una hace años, cuando era algo más inocente, y a la que el negocio empezó a ir mal, el jefe ya estaba maquinando... ninguna de sus ideas era legal ni ética, pero no le importaba lo más mínimo (dimitimos todos en bloque al ver el percal).
#15 La han cagado como empresa, pero eso no significa que todos sus desarrolladores destacados sean culpables de ello.
#18 Las decisiones en una empresa de estas las toman habitualmente los directivos, como el aquí mentado. Nadie ha responsabilizado a los desarrolladores.
#17 chico, que solo es un puesto de programador. Tecleas, cobras y te tomas unas copas. Dudo que el minero que se dedica a sacar uranio piense que se usan para hacer bombas. Tiene otros usos
#1 #2 Recordemos que en unas pocas semanas se acabará de integrar la primera pieza de código escrito en Rust dentro del kernel Linux (para la versión 6.1, o la 6.2 si hubiera algún problema de última hora).
Esto no viene de Microsoft, de hecho ellos van a remolque. El lenguaje nació en Mozilla, y ya se está usando en muchas otras grandes empresas: Amazon, Facebook, Google, Discord, obviamente Microsoft, RedHat...
#21 Tengo la sana costumbre de desconfiar de Microsoft, llámame loco
#19 Pero justo dices:
> La han cagado tantas veces que tienen un montón de experiencia.
refiriendote a su experiencia en "software de sistema" (del comentario anterior), no soy yo quien omite el contexto.
#23 La "experiencia" son las decisiones directivas acumuladas. El apostar por cosas que luego no han funcionado. Los desarrolladores harán lo que les manden, no son los que deciden el rumbo.
#20 La diferencia entre un minero de uranio, que lo hace para sobrevivir (y que no tiene otras opciones), y alguien que gana 150k/año reside precisamente en que el segundo no necesita ese puesto de trabajo para vivir bien (no cobro 150k, pero sigo cobrando de puta madre); podría estar haciendo muchas otras cosas... y sin embargo decide participar en una actividad dañina a todas luces por una ganancia personal marginal.
No, no es solo un puesto de programador.
#22 Hombre, de otras cosas tiene todo el sentido del mundo, tampoco les tengo cariño; pero decir que "Rust caca" porque MS lo promueve es como decir que ahora hay que contaminar porque los de Iberdrola hacen anuncios de molinos de viento.
#25 eres camarero o algo así?
#1 No es que lo diga Microsoft. Empiezo a leer y dice "Mark Russinovich...". Este tio no es un cualquiera.
https://learn.microsoft.com/en-us/sysinternals/
Aprovecho el hilo. ¿Hay algun libro bien actualizado sobre Rust?
#10 Lo que no sé por qué los ponen juntos, supongo que será porque son los mas usados en sistemas operativos, porque C y C++ son dos mundos diferentes con distinta gente detrás.
#3 Genbeta forma parte de una agrupación de blogs.
Probablemente estén obligados a escribir un numero de artículos diarios.
La calidad de los artículos no es una prioridad, solo la cantidad.
Es una peste que afecta a cada vez más blogs y webs de noticias.
#29 este tutorial de youtube es buenísimo
#29 +1, interesa. No sé hasta qué punto rust está evolucionando muy rápido ahora mismo como para que un libro se quede desfasado rápido, pero es que prefiero el papel, la verdad.
#28 venía a decir esto, es el CTO y como desarrollador fue el que descubrió el rootkit de Sony que fue todo un escándalo en su momento. En ese momento tenía su propia empresa donde había creado multitud de herramientas para facilitar el mantenimiento de Windows y es considerado un programador talentoso... en C y C++.
Su empresa fue adquirida por MS y él ha escalado hasta ser CTO de MS.
#3 errores en la gestión de seguridad! =errores de seguridad
Para nuevos proyectos se puede usar C++11 en adelante, que ya tiene punteros inteligentes y no hay que andar alocando y liberando memoria cada 2x3.
El palillero de Mocosoft no se entera de nada, como si los errores de "seguridad" fueran un problema del lenguaje; será del pardillo que lo ha hecho, que no tendrá ni idea de nada.
#25 Enhorabuena. Y gracias.
#10 ¡ Y los cuchillos cortan !
#11 hoy en día se puede desarrollar en .NET en Linux o Mac sin problemas. Te lo digo yo que lo hago.
#25 Como dijo un famoso filántropo, dedicate a lo que más rentable te salga para ganar dinero, luego ya limpiarás tu conciencia donando una parte.
#30 porque son los más usados ahora mismo
#7 si competidor significa copia con mil añadidos que lo hacen peor
#10 perdona si discrepo de tu opinión. C++ y en mayor medida C son lenguajes altamente utilizados y expuesto a la comunidad, lo que los hace altamente testado. Es al utilizarlos mal es cuando empiezan los problemas. O cuando se descubre una vulnerabilidad asociado a una libreria de hace más de 20 años... ¿volvemos al problema del efecto 2000?
Pero puesto a echar mierda, empecemos por Java - y a continuación ponga su lista preferida.
#24 estás bastante equivocado. Microsoft tiene bastantes desarrolladores "cracks" (para eso les pagan pastizales) con poder suficiente para tomar decisiones de este tipo.
Por ejemplo, vscode está hecho en TS/nodejs porque les salió del nardo.
Con el C++ empece yo a programar en serio, decían que algunos bucles podían llegar a quemar el procesador... Leyenda urbana, de ser cierto yo hubiera quemado varias maquinas
#39 En ningún momento he negado eso.
¿Y no sería mejor corregir los fallos de C o habilitarlo para poder programar de forma segura, en vez de inventar lenguajes nuevos?
#25 danina a todas luces?
Muchos la consideramos beneficiosa para la humanidad, aunque con aspectos negativos, como todo.
Sí, tu trabajo también tiene aspectos negativos.
#10 sera un nido infecto el código realizado en esos lenguajes. Que son los más usados desde hace 50 años y por eso obviamente se decubren más agujeros de seguridad en C que en ADA que no lo usa ni Perry. Además programar en C o C++ requiere una disciplina mayor que en otros lenguajes, donde se facilitan algunas cosas.
#36 el palillero dice...
Ese muchacho te da mil vueltas en todo. Mira su currículum.
Por otro lado, lo de los punteros inteligentes está muy buen, pero yo quiero un lenguaje donde se lean procesos de negocio al mirar el código, no que tipo de puntero se usa en cada línea.
¿cual es el mejor libro para aprender rust?
#40 Lo del "effective altruism" es una forma muy, muy burda de utilitarismo (que no tiene en cuenta aspectos básicos como el típico "factor de descuento" que hay que aplicar a retornos futuros). No me voy a poner a desmontarlo aquí porque es mucho trabajo para mi, que no me dedico a la filosofía; pero no es difícil encontrar muy buenas explicaciones al respecto.
#46 podrías ser más concreto con esto, entonces?
tomando decisiones que los fuerzan a usar las herramientas de Microsoft,
#30 Son muy distintos, pero tienen conexiones históricas, y los dos se usan para hacer software de "alto rendimiento". Además de que muchas herramientas están diseñadas para trabajar con los dos a la vez.
#4 tienes un ejemplo de este milenio?
#52 No te molestes en desmontar nada, la gracia de "famoso filántropo" es porque uno de sus mayores impulsores (y captadores de ese tipo de donaciones) es Bill Gates.
#43 muy bien explicado.
#15 Pues hora lo estan petando en el cloud no?
#30 Porque ambos comparten el mismo problema. La gestión de la memoria. Que justamente es de lo que se queja MS, los de Chrome y todo el mundo
#36 ¿no te parece útil que sea el compilador el que te garantice que el código está libre de bugs de las clases más peligrosas?
#54 y ya que estás, tienes enamorado a medio meneame por tu sueldo y trabajo, deberías hacer un preguntame o algo similar cuando tengas tiempo para cotillear como has llegado ahí y contarnos que problemas éticos y morales te has encontrado por el camino.
#4 si profundizas un poco más, Microsoft sabe bien lo que se hace. Creo que han aprendido de los errores del pasado. Ahora, no sé si es algo bueno o malo...
#51 rust book, que es gratis.
La documentación de rust es excelente.
#49 No hablo (ni yo ni el resto de proponentes de Rust, o críticos de C/C++) de cantidades absolutas, sino de proporciones. Proporcionalmente, el código en C y C++ contiene muchos más errores graves que el código escrito en Ada, o Haskell, o Rust (y lo mismo pasa si comparamos JavaScript con TypeScript, precisamente porque TS aplica reglas más estrictas).
No se trata sólo de tener "mal código" o "malos programadores". Es demasiado fácil cometer errores sutiles (pero graves) en C y C++. Esto no es tampoco una opinión de 4 academicistas, ni de puristas. Se ha demostrado por activa y por pasiva que había que encontrar mejores soluciones que lo que C y C++ nos ofrecían.
Y son los más usados por motivos históricos, no porque fueran especialmente mejores que otras opciones, el concepto de "accidente histórico" existe por algo. En el caso de las tecnologías también tenemos el concepto de evolución dependiente del camino "path dependent" (es decir, que ciertas decisiones no se tomaron por ser las "mejores", sino por los pasos dados previamente).
#43 Perdona si desconfío de tus conocimientos en programación de sistemas a bajo nivel, o de seguridad en sistemas críticos.
#55 Windows Vista. Windows 8. Zune. Toda la cosa de móviles. Cortana. Algunos ya citan el Win11 (en esto no estoy de acuerdo. . . porque es que es lo mismo que 10).
#58 Su nube va mayormente con Linux. Obvio. Hasta tienen su propia distro para usar en Azure.
#c-53" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3726785/order/53">#53 He enlazado una página bastante interesante, más arriba en el hilo, donde se exponen casos bastante salvajes de actos deshonestos por parte de la .Net Foundation. Esa página no es ni mucho menos exhaustiva.
Admito que no toco C# más allá de 4 chorradas cuando cacharreo con Godot para mis experimentos personales, pero uno de mis motivaciones para evitarlo ha sido su historia llena de baches a la hora de soportar sistemas como Linux (primero con Mono, que siempre iba por detrás y luego fue absorbido), o las dificultades para acceder a buenas herramientas de debugging que fueran libres (de hecho uno de los casos que más me escandalizó estaba relacionado precisamente con esto último).
#16 No entiendo nada pero te voto positivo porque me da la sensación de que tienes razón.
#66 ¿esos son ejemplos de qué, cosas que no funcionaron? Todas las empresas tienen montones. No sé a donde quieres llegar.
#58 En cloud y en un montón de cosas. Desde que se fue Ballmer la empresa va como un tiro.
#67 ya, bueno, estoy de acuerdo, el . NET antiguo no lo hubiera tocado ni con un palo.
Pero llevan muchos años ya dando pasos de gigante en dirección al openness (como se diría esto en castellano?) y, sinceramente, no veo eso de que te fuercen a usar herramientas de Microsoft.
Es todo lo contrario, ahora puedes usar hasta docker fácilmente.
C prevalecerá. Como siempre.
#47 Pues si, esto parece ya la Torre de Babel.
#36 Alocando dice el palillero.
#73: Es que es siempre lo mismo:
"Eh, mirad, he inventado aún otro lenguaje nuevo que soluciona los problemas que yo notaba en otros, pero que deja otros problemas pendientes de arreglar para que otros puedan inventar un lenguaje más"
Al final se atomiza todo y es peor. Si el problema de C es que puedes salirte del vector, implementa una función de comprobación y úsala SIEMPRE, incluso podría haber una biblioteca estándar para eso. Si el problema es la conversión de tipos, que implementen una función en el compilador que obligue a usarla siempre y si no coinciden, que de error, aunque la conversión sea
tribaltrivial.#61 Supongo que podría responder preguntas, pero sin ser famosillo ni haber expuesto qué hago en realidad, no sé si la gente tiene material suficiente como para poder hacer demasiadas preguntas.
Ojo, se gana bien, pero no es el paraíso, o no para todos.
Disclaimer: lo que sigue es una simplificación MUY burda, no se me juzgue por ella; que esto no es un artículo académico.
Es un oficio algo extraño, igual que pasa con el futbol o algunos deportes, tenemos una cierta "élite" (3 grupos: "académicos", "industria", "influencers"), y "clase media", y luego toneladas de gente que pringa más de lo debido. En ese esquema, yo he sido un pringuis durante mucho tiempo, y ahora estoy en esa "clase media acomodada".
Lo he estado viendo y está muy interesante...
#66 No soy precisamente pro-microsoft, pero ya que hablas de cosas malas, tienen cosas buenas, como VSCode, por ejemplo, typescript creo que también está diseñado por Microsoft. El WSL funciona bastante decente, aunque sea peor que un Linux nativo, obviamente.
Hacen cosas mal, como todos, pero ponerlos como que no saben de tecnología...
El año de Rust en el escritorio. Oh, wait!
#47 Posiblemente habría que cambiarlo tanto que sería como hacer un lenguaje nuevo.
#48 La verdad es que sin conocer lo que sabes o desconoces, no sé por dónde empezar, pero te aseguro que no hay absolutamente nada positivo en ese sector, más allá de las buenas intenciones de algún pobre inocente.
Te lo digo habiendo trabajado en ello, habiendo pensado mucho tiempo en ello, tanto en los aspectos tecnológicos, como en los económicos y sociales; y habiendo estado en contacto directo con la industria, conociendo a quienes la integran, y sus intenciones.
Joder, es que da para escribir un libro de los gordos. Estilo "No Logo", pero aun más salvaje.
#80: Depende de lo que se quiera hacer, si son tantos cambios como para hacerlo un lenguaje tan lento como Python... quizás sea mejor usar ese lenguaje o alguno similar para ciertas funciones y dejar C para otras.
#65 no , a ver.. si te entiendo, hablar de ax o mov es un coñazo. Por no hablar de hacerlo en lenguaje máquina... Sobre los sistemas críticos, pues depende si hablamos de sistemas de vigilancia o de sistemas de gestión para el control de la señalización.. ahí me pillas algo frio.
#64 Gran parte de los errores que se cometen en C son debidos a que es un lenguaje más antiguo que otros no a que sea un mal lenguaje.
Descargar la tarea de gestión de memoria en el programador ahora es un riesgo pero el peor rendimiento de lenguajes más modernos al respecto como Java no era posible con los procesadores de hace 30 años.
Y lo digo con conocimiento de causa que empecé a programar en Java en 1998.
#4 antes era MS quien estaba outdated... Ahora MS está en la ola, y en cambio vosotros estáis outdated... Qué irónica es la vida.
#28 Si es que él mismo lo dice en el propio artículo, que se inclina por Rust pero que aun queda mucha vida a C y C++. Aquí muchos asesinando lenguajes y empresas, extremando posturas, y esto no es una cuestión de elegir y defenestrar nada, sino de complementar y evolucionar.
Un par de días después de esta declaración, Russinovich volvió a sacar el tema en su Twitter. Recordó que "hay una enorme cantidad de C/C++ que se mantendrá y evolucionará durante décadas (o más). Anoche codifiqué una función para Handle, que se suma a las aproximadamente 85.000 líneas de código C/C++ de Sysinternals que he escrito". Pero tambiñen añadió que "me inclinaré por Rust para las nuevas herramientas".
Como recuerda #34, Sysinternals era un pozo de sabiduría y herramientas para sistemas Microsoft.
Y así, para evitar errores, en vez de contratar programadores listos, mejor usar un lenguaje para programadores junior. Sale mas económico y el resultado ya tal...
#47 "habilitarlo para poder programar de forma segura" Eso limitaría su potencia, que es la gracia de esos lenguajes. Lo que hay que hacer es contratar gente que sepa lo que hace.
#84 Ya en la época de C había lenguajes con mejores propiedades (como mejores sistemas de tipos, sin irnos a rollos academicistas como Haskell), y que ofrecían rendimientos similares. Lo que lo hizo ganar terreno sobre todos los demás fueron 3 factores:
- que se usó en UNIX
- que se usó para crear las "libc" que a día de hoy aglutinan toneladas de funcionalidades básicas para interactuar con los sistemas operativos.
- era fácil de implementar compiladores de C, se podían hacer compiladores "de una sola pasada", que son más simples que los compiladores de múltiples pasadas.
C no es malo sólo por la gestión manual de memoria, lo es también por su sistema débil de tipos, por sus macros horrendas, por sus ficheros de cabecera, por su ecosistema de herramientas, por las decisiones incomprensibles tomadas por el comité ISO...
Ejemplo: Tenemos Zig, que también necesita que el programador gestione la memoria, y sin embargo es mucho más limpio como lenguaje.
#50 Y para eso teneis visual basic.
#79: Si es de metal, derramas el café y no lo limpias...
#16 Y luego la competencia te saca un producto en C++ que va 3 veces mas rápido requiriendo 10 veces menos de RAM.
#4 A ver, en este caso, y viendo que muchos proyectos libres están refactorizando en Rust, y que el propio kernel de linux que desde su nacimiento no ha admitido más lenguajes de programación en la próxima release se espera compatibilidad con Rust, igual no van desencaminados. Aunque sea Microsoft.
Hasta un reloj parado da la hora correcta dos veces al día.
Y hay que tener en cuenta que el lenguaje lo creó Mozilla, y ahora está en manos de su propia fundación (Rust Foundation).
#16 estoy de acuerdo, pero veo 2 handicaps aquí.
La base de código en C que tenemos a día de hoy no va a desaparecer de la noche a la mañana y reescribir cosas como el kernel de Linux o ffmpeg no es trivial en absoluto.
Y segundo y más importante, la curva de aprendizaje de Rust es realmente dura para recién iniciados y bastante dura para programadores con experiencia. Eso provoca que, si vas a iniciar un nuevo proyecto, elijas C, que es extremadamente simple en comparación.
Todavía nos quedan al menos 20 o 30 años más de ver C por todas partes.
#87 ¿Insinúas que es lo que hicieron cuando contrataron programadores en C para no tener que hacerlo en ensamblador?
#32 #33
https://doc.rust-lang.org/book/
Los autores publican el libro en tapa blanda.
#67 desde hace dos años, con el lanzamiento de .net 5 la cosa ha cambiado.
Ahora está .net 6 y en nov sale .net 7, desde el .net 5 alucinas con lo fácil que es lanzar una web corriendo sobre un docker con alpine linux (con menos de 150mb tienes el docker de SO + .net6 corriendo asp.net)
#11 "foundation" significa base, no fundación
#71 así es, además ahora están lanzando MAUI para correr apps de escritorio en Windows, android y Mac. Eso sí, para Linux no lo han sacado pero la comunidad ya está dándole para que lo he hecho con Maui corra en Linux
Visual basic 4. Chupito!!! (Y comentario 100 POLEEEEE)