Hace 1 mes | Por meneanteBlanco a genbeta.com
Publicado hace 1 mes por meneanteBlanco a genbeta.com

Proteger los sistemas tecnológicos críticos de posibles amenazas es una preocupación cada vez mayor para los gobiernos. Y un ejemplo de ello es el reciente llamamiento dirigido a la industria del desarrollo de software y realizado por la Casa Blanca a través de la Oficina de su Director Nacional de Ciberseguridad (ONCD) para que adopten lenguajes "seguros para la memoria"...

Comentarios

Powertrip

#54 los pelos como escarpias

Dramaba

#54 Espero que al menos lo cobres bien...

troll_hdlgp

#54 Tu comentario me ha recordado a este video

t

#54 Gathereando???????

A

#54 Que no se olvide:


 
 

diminuta

#54 hace poco participé en un proceso de selección que tenía buena pinta hasta que recibí un correo del que me iba a hacer la siguiente entrevista y estaba escrito en un consulto insoportable. Les dije que había cambiado de idea.

garnok

#54 mi mas sentido pésame par tus neuronas

Arcueid

#54 En las mismas, al fin y al cabo, seguramente como gran parte de Menéame.

Entiendo que terminemos hablando un lenguaje criollo en horas de trabajo con tanto anglicismo y acrónimos. Y creo que es sano limitarlo un poco; aunque creo que en mayor o menor medida todos nos dejamos llevar por la comodidad hasta cierto punto. Para mí el mayor problema viene de olvidarse o no saber que se pueden usar palabras ya existentes sin añadir longitud o complejidad especial; y que esto se retroalimente y refuerce entre compañeros. Y me parece incluso peor escrito que hablado.

Prefiero que alguien diga la palabra en inglés y separe idiomas, registros y entornos que no que se saque una mezcla como "contenerizar", "deployar" o "securizar". Y lo que es peor, que esto se escriba en documentos "serios".

javicho

#11 
De acuerdo con lo que dices, solo que secularizar si existe aunque no tiene mucho que vez con la seguridad informatica. Yo odio el "encriptar" cuando no se habla de criptas.
Se me ha ido la.olla y en vez de darte a responder te he dado negativo, te doy otro par de positivos luego

Arcueid

#89 Sí, sí; la palabra existe. Es sólo que en este contexto no tiene sentido.

A mí también me da grima que se use lo de "encriptar", quizá porque me enseñaron que no era el término correcto (para eso está "cifrar", al fin y al cabo). Pero me parece que cada vez lo aceptan más, incluso quienes trabajan directamente en la materia. Como decían en una película, el lenguaje también actúa como un virus y hay que tener cuidado con lo que se transmite.

No te preocupes por lo otro. Gracias por la explicación en todo caso.

Technics

#89 Encriptar no proviene de cripta sino de criptografía, Del griego Kriptos = ocultar, Graphos = escritura.
Encriptar es ocultar la información cifrándola mediante el uso de clave/s.
Si lo prefieres puedes usar el sinónimo cifrar, pero encriptar aparte de ampliamente utilizado esta admitido.

https://dle.rae.es/encriptar

pawer13

#21 o como desarrolladores de Cobol

M

#13 Te has olvidado de mencionar las mejoras de C++ desde C++11, C++14, C++17, C++20, etc...

Cuñado

#15 Y el uso del punto y coma Ninguna de esas mejoras incluye la automatización completa de la gestión de memoria (que sí incluye Rust) ni una seguridad en tiempo de compilación equiparable a la de Rust, que es de lo que estamos hablando.

JungSpinoza

#5 #10 #13 #15 JS for the win!

Cuñado

#19 JS... Te refieres a Jung/Spinoza? No me suena a ninguna otra cosa

tsiarardak

#19 reportado

Polarin

#19 #55 Cualquiera que programe en ...JS (ANATEMA!!!!) merece el castigo mas cruel posible: escribir ensamblador para al IBM 370!!!!!

Polarin

#19 JS es de esas cosas que aprendi a odiar en los 2000... que he visto ahora y me ha sorprendido gratamente, pero es como la tortilla de espinacas que te hizo comer tu madre con 8 anios, que aunque las espinacas esten cojonudas en un restaurante pijo, sigues acordandote de la puta tortilla de espinacas y como las odias con todo tu ser.

Azrapse

#13 Luego, te pones a implementar una lista doblemente enlazada en Rust y el compilador te dice
"Para qué quieres hace eso jaja saludos"

D

#60 Pero es que tiene razón. No he tenido que programar una de esas desde que salí de la carrera. Arrays de datos y arrays de índices FTW.

Cuñado

#60 use yo::ke::se;

Rust las incluye en la stdlib: std::collections::LinkedList. Pero teniendo en cuenta que el principal caso de uso de las listas doblemente enlazadas es implementarlas para resolver pruebas de programación, tienes dos opciones:

- Usar smart pointers: Rc permite varios owners y RefCell mutabilidad interna (con la penalización de las comprobaciones en tiempo de ejecución), o...
- Usar "unsafe" y hacer lo mismo que harías en un lenguaje como C++

Rust proporciona un montón de mecanismos de seguridad que en C++ ni están ni se les espera, pero también puedes prescindir de ellos.

Polarin

#60 A ver, es como eso de que JAVA es interpretado... y luego te sale la ostia esa de ClassDefNotFound, que es que un linker se ha pegado una ostia, pero te enteras en ejecucion. Ya se lo de el linkado dinamico enLinux, pero no deja de ser gracioso.

No hace tanto he visto ese error y me han dicho: "Que es el linker?", la madre que me pario del amor hermoso!!!!!!!!

a

#13 Díselo a los de OpenBSD usando S en /etc/malloc.conf, donde ahí es probable que detox casque como tien que ser.

Muchos de esos problemas con C se han arreglado con las mitigaciones de OpenBSD, opciones de malloc, y pledge y unveil en Firefox y Chromium.

babybus

#10 no necesitas C para crear estructuras de datos complejas. Puedes hacerlo con cualquier lenguaje de programación moderno. Lo mismo sucede con la POO.

#24 depende del tamaño de esa estructura... He visto sufrir mucho al garbaje colector de java en proyectos muy grandes... Y al equipo de desarrollo sufrir aun más intentando mejorar el rendimiento...

Nota: yo está como "sistemas" en las reuniones en las que daban caña al equipo de producto... No soy programador.

Polarin

#36 #57 Eso es una exageracion,... TID tenia una aplicacion que era en X-Windows que movieron a JAVA ... en un applet!!!!! Y vale... el bicho tardaba en cargar ... unos 5 minutos... pero luego funcionaba como un tiro. Y hablamos de aplicacion con calculos matematicos, comunicaciones, ... incluso tenia una herramienta que abstraia todos los ordenadores de una red y permitia mover ficheros en una especie de sistema de archivos distribuido a traves de maquinas locales, servidores en red, ... con un interfaz grafica que encapsulaba FTP y sistemas de ficheros locales de windows y Unix (Solaris), . Y estamos hablando del anio 2000. Y no tuve que pegarme para que aquello corriera, a veces las JVM se le iba la perola, pero ... corria medio bien.

LeDYoM

#24 Una vez hice un programa en Java y compilé. Aun estoy esperando a que la VM se encienda.

S

#57 ¿Estaba conectada?¿HIciste el sacrificio ritual de niños en el altar? Suena a que es problema tuyo.

babybus

#57 a mi de pequeño me gustaba el helado de pistacho.

Polarin

#24 Si, y quizas el problem ahi es de edad. Yo me trague las clases de Estructuras de Datos en C y C++, y siempre me ha costado hacerme las bibliotecas en JAVA. Python es raro de cojones y lo utilizo para otras cosas. Go y RUST, son para cuando termine mis clases de ML.

cosmonauta

#10 Tienes que mirar Rust. Te va s sorprender. Yo go tampoco está nada mal en cuanto a protección de acceso a memoria ilegitima.

frg

#45 No soy programador, pero confío plenamente en el criterio de cierto amigo mío que sueña en código, donde me mencionó, hace ya algunos años, que Go era una PM a la altura de PHP, y que si quería hacer algo serio usara Rust.
Ya se que confiar en este comentario sin más pruebas es una estupidez pero confío plenamente en su criterio.

l

#80 Go es esa PM de lenguaje en el cual está desarrollado ni más ni menos que Kubernetes. Y PHP el sustento de gran parte de la web vía Wordpress. Cada lenguaje tiene su uso y ventajas. Catalogar a Python de PM es extremadamente sencillo, y no por ello es un lenguaje con una grandísima utilidad y el más adecuado en muchos escenarios. Por lo que simplemente es un talibán más o un iluminado de la pureza de los lenguajes funcionales.

frg

#99 Si es un Talibán es mi talibán de cabecera

kverko

#80 es difícil encontrar un lenguaje de programación que da tantas facilidades para manejar cadenas y expresiones regulares como PHP. Por eso es una herramienta muy útil para web.

PacoJones

#80 PHP ha mejorado muchísimo con las últimas versiones, y no, PHP no es una mierda, siempre lo suele decir la gente que nunca lo ha tocado o que se quedó en PHP 4 de hace 20 años.

cosmonauta

#80 No te fíes de tu amigo para decisiones importantes.

Nitros

#_80 #45 Tu amigo tiene opiniones muy raras.

Si necesitas hacer algo crítico en lo que no te fies del GC, por supuesto que Rust es un candidato ideal.

Para montar una API decentilla, o crear un CLI, o cualquier cosa medianamente compleja que tampoco sea súper crítica, Go es una maravilla. Ya vale la pena solo por la cantidad de herramientas que te da la librería estándar sin tener que bajarte paquetes de otros.

Polarin

#93 Ya, pero tambien pasa que hay cosas que no son API o CLI. Ejemplo: SACTA, o los sistemas de control de redes telefonicas.

Polarin

#45 Ya, es que me ha dado desde hace algunos anios por Ciencia de Datos y ... a ver, que C/C++ fueron mis amores de juventud, pero me toco escribir JAVA durante muchos anios, y ahora estoy lejos del codigo por mandato profesional.

En cuanto tenga tiempo quiero mirar Rust. Lo he empezado, pero en cuanto tengo tiempo me meto con matematicas para ML y esas cosas.

elprofemates

#10

Otra cosa es la mala gestion de memoria, que viene del modelo de usar la memoria para tener datos y codigo, y el heap y la stack. De hecho, lo logico, que no ha hecho nadie hasta ahora, seria cambiar el paradigma de los compiladores y de la gestion de la memoria.


El propio creador de C++ decía algo parecido. Él sugiere el uso de analizadores de código estático. Supongo que habría que meterle a estos analizadores algo más. Por ejemplo, la notación:

https://github.com/selairi/memory_notation.h

Por cierto, si tenéis algún segment fault o memory leak, recomiendo leer:

https://github.com/selairi/memory_notation.h/blob/main/PROBLEMS.md

Para los memory leaks lo mejor es Valgrind:

https://cartaslinux.wordpress.com/2020/04/05/valgrind-buscando-errores-de-memoria-en-c-y-c/

Zade

#87 por como habla se nota bastante

Polarin

#87 #90 #124 #138

Es que a los mayores de 40 no nos han prohibido todavia volver a la universidad.

Y ademas ahora existe Internet y puedes sacarte una carrera en universidades en otro continente.

En mi caso estoy intentando una segunda carrera en Ciencia de Datos y estoy pegandome con las asignaturas de matematicas porque hace mas 25 anios que me hice las de la carrera.

Soy mas bien calvo, que cuando empece usabamos el Turbo Pascal y el Turbo C, y OWL era un adelanto de la polla en vez de programar windows con la API en C a pelo,... y teniendo que cargar las entradas de las dll mirando los segmentos de memoria porque era win32 y en mi memoria de persono mayor me acuerdo de que habia un pollo bien montado con los puntos de entrada de las dll si tenias win32 en vez de 16 bits... pero hace mucho de eso.

Polarin

#90 Lo mismo que para el otro, me toco la codena de escribir ensamblador para la 370. Pero paso hace mucho.

Dramaba

#87 Podría ser su tercera carrera y tal...

h

#87 Aprender es una maravilla y se puede hacer toda la vida, pero el sistema actual nos hace asociar "aprender" con "debilidad", es todo lo contrario.

Polarin

#87 El mejor leguaje es Fortran77, y a mi no me gusta el quiche.

Polarin

#87 Espera, que se me habia olvidado... tambien he escrito codigo en COBOL y profesionalemente en ensamblador de la 370. Pero por lo menos mi codena fue corta, de solo un anio.

M

#5 Ups, veo que te quedastes en la prehistoria del lenguaje... hoy en dia en C++ con Smart Pointers (std::unique, std::shared) no tienes que gestionar mucho... pero siempre es mejor hablar de oidas

babybus

#14 conozco bien los smart pointers, igual que seguro que los conoce la casa blanca roll

Pero eso solo alivia algunos de los problemas, no resuelve el problema. Por qué el problema es el modelo de gestión de memoria y la forma en la que el programador se relaciona con el.

De hecho, por eso existe rust. Si fuese como tú dices, no haría falta rust para nada.

Fariseo

#25 #14 Sin acritud, desde al menos C++ 11, puedes prescindir de news, deletes, mallocs, allocs, frees y shared pointers si quieres.Yo llevo años haciéndolo, ya solo uso punteros cuando me toca cambiar codigo legacy roll

cosmonauta

#32 Puedes prescindir de news, pero también puedes usarlos. Y ese es el riesgo.

Especialmente en desarrollo de drivers y código que necesita alto rendimiento, el programador está muy tentado a saltarse todas las buenas prácticas. En Rust o Go, el riesgo está mucho más acotado y con un rendimiento similar.

Fariseo

#49 Solo quería puntualizar que no es obligatorio, veo mucho desarrollador asustado por la gestión de memoria dinámica. Simplemente apunto que si no te gusta o no estás seguro de saber lo que haces puedes evitarlo y usar los recursos que tienes desde C++11
Que prefieres Rust? Pues genial
Saltarse "las prácticas" pasa con todas las tecnologías y todas las áreas de la vida misma

cosmonauta

#64 Claro. Pero la noticia cita un marco normativo para proyectos USA. Y a los gobiernos les gustan las normas y no tener que confiar en las buenas prácticas de los miles de programadores que contribuyen.

Habiendo lenguajes equivalentes, empezar un proyecto nuevo en C/C++ tiene poco sentido en la inmensa mayoría de casos. Y te lo dice un ex programador de C.

Fariseo

#71 Desde el respeto, eso es tu opinión
Respetable, por supuesto, pero no es necesariamente verdad

D

#64 El tema aquí no es que haya programadores asustados de la complejidad de C/C++. Los asustados son los pagadores de proyectos que se hartan de exploits en sus sistemas críticos.

Fariseo

#73 Entiendo que sin C/C++ se acaban los exploits.
No lo sé, pero me suena raro

D

#77 Con Rust es mucho más fácil no cometer errores de acceso a memoria, y se hace muchísimo más difícil cometerlos, por lo que es mucho más difícil (de hecho imposible si lo que programas no está marcado como unsafe) producir aplicaciones con exploits.
A ver si me explico: con Rust no tiene sentido usar Valgrind, porque nunca vas a leer o escribir fuera de rango (que es lo que hacen la mayoría de exploits para ganar acceso a un sistema, aprovechar un fallo de esos para escribir donde les interesa fuera del espacio de usuario).
Y encima, Rust consigue eso sin utlilizar un recolector de basura, por lo que es igual de eficiente que C (o más, porque permite mejores optimizaciones en tiempo de compilación, aunque eso aún no se nota, el compilador está verde aún).

Fariseo

#95 No conozco Rust para debatir/rebatir lo demás.
"Rust consigue eso sin utlilizar un recolector de basura, por lo que es igual de eficiente que C"
Hace más trabajo y más comprobaciones consumiendo menos cpu/recursos? qué es lo siguiente? La máquina de movimiento perpetuo?
En serio, creo que toda tecnología tiene su aplicación pero está obsesión de algunos, no lo tomes personal por favor, de demonizar C++ por los "riesgos" que podría tener la flexibilidad que te daba el C ...me suena a trauma infantil

d

#98 Rust añade el código para gestionar la memoria en tiempo de compilación.

alephespoco

#98 El sistema de asignación de memoria es muy simple (muy parecido a RAII), y soluciona el problema de la gestión de memoria de un modo elegante.
Aparte el compilador es muy moderno y está muy muy optimizado y da errores con sentido (no como los que hemos sufrido durante décadas en C++).
En el tema de performance, hay algunos benchmarks en los que Rust funciona mejor que C (por ejemplo en pidigits aquí https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gpp.html ), pero es porque el compilador es mucho mejor y optimiza mejor que g++, nada de movimiento perpetuo, el tooling de Rust es mucho mejor que el de C++ de lejos, sin hablar de la gestión de librerías moderna que viene integrados.

De todas maneras, permíteme que exprese mi opinión sobre el tema del performance: una diferencia de performance del 1 al 5% en prácticamente todos los sistemas modernos es irrelevante, igual tiene un pase en los sitemas embebidos, pero para el resto es ridículo que se use el argumento del performance, cuando la ganancia en seguridad es muchísimo mayor:
* Preferirías que tu aplicación fuera un poquito más lenta (un 5% por ejemplo) o que por diseño no pudiera tener memory leaks ni punteros inválidos?

GalgoIbicenco

#49 "el programador está muy tentado a saltarse todas las buenas prácticas"
...linters, y static code analysis en la pipeline son tus amigos

S

#49 Al final se trata de eso, si en un edificio tienes un cuarto con cables de alta tensión, puedes poner un cartel de "peligro" y quedarte a gusto, o puedes poner un candado. De hecho muchos aspectos de diseño orientados a seguridad (reales o de software) básicamente tratan de que las situaciones de riesgo sean imposibles, o desincentivarlas lo máximo posible.

spacos

#32 La idea de todo esto, es que las personas cometen errores. La gestion de punteros, mas o menos de forma automatica es el problema, porque el programador la puede cagar sin darse cuenta. Eliminando eso, aka Rust, eliminas el problema.

Fariseo

#58 Es que no necesitas gestionar punteros desde C++11 !!!
He visto memory leaks y cuelgues usando lenguajes "sin punteros"
Los errores se cometen sin punteros también

alephespoco

#14 #32 Siempre se ha podido usar RAII, desde antes incluso de C++11. El memory safety no es algo que C++11 ni ninguno de las actualizaciones posteriores haya solucionado.
C / C++ son leguajes potentísimos que mal usados te vuela el pie, una buena analogía puede ser un bazooka.
Es un lenguaje que de potente que es, te puedes llevar un buen disgusto. Sobre todo perfiles que no tengan un buen y largo bagaje de programación.
Y claro, el legacy de C++ es como el legacy estándar solo que con nuevos superpoderes: memory leaks, punteros inválidos ... para mí tiene que estar muy muy justificado programar algo en C/C++ hoy en día.

ed25519

#14 Con los ultimos cambios en c++ con los smart pointers hay poco que gestionar de memoria

ur_quan_master

#5 es que esas cosas muy muy concretas son la base de todo el castillo que se monta por encima.
Aparte que desde c11 y posteriores la cosa ha ido mejorando.

c

#5 C/C++ son lenguajes muy artesanales
¿Lenguajes "artesanales" ?

donde el programador se encarga de gestionar la memoria a mano.
He programado en C durante años y jamás he "gestionado la memoria a mano". He cogido memoria cuando la he necesitado y la he liberado cuando ya no me hacía falta.
No es tan difícil.

Los problemas de seguridad se derivan de una mala programación. Y mientras haya esas malas praxis habrá problemas. Uses Javascript, PHP, Rust o lo que quieras.

Hoy en día los problemas de buffer-overflows que es lo más típico debido a la falta de control en el almacenamiento en memoria en C no son los peores problemas de seguridad ni de lejos.

D

#41 Los accidentes de tráfico se derivan de una mala conducción. Y mientras haya esas malas praxis habrá problemas. Uses cinturón, airbags o lo que quieras.
 

h

#59 Me parece una muy dudosa analogía. Según dices, Rust es la solución a los "accidentes" de programación, ¿Cual es la solución a los accidentes de tráfico?

c

#59 Exacto. Por lo cual debemos pedirle a la gente que deje de conducir.

b

#41 Si la cojes como quien tiene un saco de algarrobas pues no hay problema, claro.

Yo no he programado extensamente en C pero, precisamente, C te PERMITE hacer optimizaciones del uso de la memoria que no estan al alcance de lenguajes de más alto nivel. Como por ejemplo alinearte con los tamaños de pagina para reducir las llamadas del S.O.

Si, C *puede* usarse de forma artesanal y conseguir cotas de rendimiento y reduccion de huella de memoria muy interesantes.
Pero hacer eso y NO CAGARLA no esta al alcance de cuaquiera ... y por ahi ha de venir el problema.

Es un tema que era importante especialmente en dispositivos embebidos, no se como andará la cosa ahora.

f

#5 Tu no has tocado c++ desde hace 23 años, así como poco.

Trabajé 5 los en proyectos en C++ y teníamos prohibido gestionar la memoria, y no tuvimos ni una fuga de memoria en esos años.

babybus

#61 claro, pero para no tener que "tenerlo prohibido", es mejor no tenerlo

Yo toco c++ cada día, como parte de mi trabajo, ya está bien de ataques personales que no aportan nada

Veelicus

#5 Hace muuuuchos años habia que gestionar la memoria RAM porque habia muy poca, que hoy todos los sistemas tengan memoria de sobra hace que dicha gestion sea "menos" importante, pero en su momento cada kilobyte, incluso cada byte, contaba.

M

#46 Qué va, entonces dan un salto mágico de dos metros.

swapdisk

#46 matemáticas al rescate jejeje

j

#46 el de casco oscuro sí puede

Una cosa que no queda clara es si la estela que deja el sable de luz también repele. ¿Hay algún tipo de atracción entre el sable y los láseres?

Luego si hay alguien que usa pólvora pues se le tira el sable de luz haciendo el molinillo a la cara y ya está

#33 A mí me confundía la forma en que usaban los sables de luz en las nuevas películas. Sale el llorón cortando árboles de un tajo, pero luego a los buenos les roza un poquito haciéndoles una quemadura de primer grado, que parece sanarse en cuestión de segundos y se mueven con total normalidad. Cuando mata a Han Solo, lo empala atravesándole el vientre en una escena que ya de por sí no tiene ningún sentido. En el grupo de frikiamigos todos pensamos que lo coherente con lo mostrado hasta el momento es que el cuerpo se hubiera partido en dos, cayendo por su propio peso. Nadie se queda completamente quieto cuando siente algún dolor en la zona abdominal y a poco que se mueva con un sable láser dentro...

En las tres primeras el movimiento del sable al estilo kendo tiene más sentido porque la prioridad en cualquier estilo de combate es no hacerte daño a ti mismo. Precisamente el entrenamiento de Luke es en su mayor parte defensivo. En las demás películas, cuando están todo el rato haciendo el molinillo como una majorette resulta ridículo.

swapdisk

#84 ya el Maestro Yoda en plan frijol saltarín puesto hasta arriba de redbull con el sable en moto ventilador ni te cuento...

Es que Disney "olvidó" el funcionamiento de los sables láser de forma muy conveniente para intentar suavizar el impacto "gore". En algunos juegos nuevos de la franquicia parece que estés pegando guantazos con una porra fluorescente. En cambio en el antiguo Jedi Knight (qué tiempos...) caían trozos si golpeabas una extremidad.

a

#46 Un Jedi simplemente parará las balas.

Cehona

Luego algunos pierden maletas con datos en USB sin secularizar.

Maximilian

#2 un palabro muy raro ese de secularizar.

D

#3 Es que la iglesia todavía tiene mucho poder. 

j

#2 segurizar, mejor que securizar

a

#2 Siendo Estados Unidos me creo que alli no permitan USB secularizados, ser pagano no esta muy bien visto por alli

sieteymedio

#2 ¿Eran datos religiosos?

c

#2 Es que el USB una vez bendecido, bendecido queda.

Ya no se puede secularizar.

geburah

#2 secuque?

Rudolf_Rocker

#2 y que los tenían, en seculmander todavía?

m

¿No se vende suficiente RAM y tienen que animar las ventas?

ccguy

#1 rust no necesita más RAM

sieteymedio

#18 ¿Qué te hace pensar que es la primera vez que lo suelta?

redscare

#18 Un buen ingeniero es experto en el uso del , lo habrá usado mil veces ya lol

Y

#86 Es lo que se conoce por codigo reutilizable? o programacion por objetos?

R

#17 Tu gracia se ha fugado.

kotomuss

#17 Segmentation fault

vvjacobo

#17 unhandled bad joke exception

frg

#44 Recuerda, siempre acabas cometiendo un fallo, por lo menos }

Peazo_galgo

#81 bien traído, vive (ms)DOS

m

#63: ¿Qué es conio.h?
Me lo acaba de preguntar GCC.exe, que no sabe lo que es.

a

#63 Normal, estás anticuada.

m

#92: ¿La has preguntado si la gusta la música .pop() ?

poyeur

#17 What the fork()!

M

#17 Adelante, siéntete free().

frg

#1 De hecho muvhat veces consume menos RAM, al hacerlo mejor.

H

No sé las repercusiones que tendrá esto a largo plazo (sobre todo teniendo en cuenta la inercia brutal que tienen las inmensas cantidades de legacy code en esos lenguajes, de manera crucial en SO-s, y que existen ya desde hace décadas iniciativas y experiencia acumulada para hacer un uso más seguro de ellos como MISRA, herramientas de linting, QA y similar...), pero meneo.

Para quién le intentese, mandé el otro día el comunicado de la Casa Blanca citado en el envio:
- Comunidado de Prensa de la Casa Blanca: El software del futuro debería ser seguro para la memoria [ENG]

l

Si recomiendan Javascript han demostrado que a lo que digan no hay que hacerle mucho caso

m

#48 ¿porqué?

avalancha971

"Este llamamiento es una consecuencia de la creciente preocupación con la ciberseguridad provocada por incidentes como la grave vulnerabilidad Log4j"

Por favor, que alguien me explique esto. No entiendo como la vulnerabilidad de una librería de Java puede tener como consecuencia un llamamiento a dejar de utilizar C/C++ y ofrecer Java como una de las alternativas.

LeDYoM

#52 Han visto que por ahí es más fácil meter back doors

avalancha971

#62 ¿Te refieres a que es más fácil que ellos pongan backdoors en la máquina virtual de los lenguajes interpretados y por ello quieren que se usen?

Me da la sensación de que nos están tomando por gilipollas, pero de una manera tan burda que me cuesta creerlo y pienso que soy yo que no lo estoy entendiendo.