Portada
mis comunidades
otras secciones
#25:
#21 tu me estas hablando de un sistema operativo que usas tu ... yo te estoy hablando de los chips que regulan semáforos , lavadoras, coches , silos de agua , camiones , puentes , barcos , maquínas sencillas que llevan años , no creo que estés entiendo lo que digo ... estas pensando en un cojunto muy pequeño. Yo te hablo de todas las máquinas que tienen microcontroladores , no se de que otra forma decírtelo . Tu solo me hablas de BSD que se parchean en horas cuando aparecen bugs..
Yo te hablo del chip que controla el motor de un barco que tiene 40 años , y está encapsulado dentro de un motor y el jefe del barco no tiene un dongle para actualizarlo...
Te hablo del chip de un semáforo de un pueblo remoto , que lleva funcionando 20 años....
Te hablo de todo eso , ....
Insisto que internet hay varios experimentos cambiado la hora a varios sistemas operativos de 32 bits y cascan de lo lindo
Te hablo de los problemas que ya hemos tenido, mira youtube.
Te l,o he explicado de varias formas diferentes , no insito mas
https://www.youtube.com/watch?v=jrGWMaUOSvk
Ese es el reloj , lo lógico es que todo estuviera actualizado para entonces, pero ya lo veremos..
https://www.epochalypse.today/
The signed 32-bit integer that is historically used to keep unix epoch time has already exhausted 89.07% of all possible values.
0
1100100
00000010
10000011
10101100
Only 5435 days (14 years) until it's finally 20:45:52 UTC on 13 December 1901 again!
Only 5435 days (14 years) until it's finally 20:45:52 UTC on 13 December 1901 again!
Yo te hablo del chip que controla el motor de un barco que tiene 40 años , y está encapsulado dentro de un motor y el jefe del barco no tiene un dongle para actualizarlo...
Te hablo del chip de un semáforo de un pueblo remoto , que lleva funcionando 20 años....
Te hablo de todo eso , ....
Insisto que internet hay varios experimentos cambiado la hora a varios sistemas operativos de 32 bits y cascan de lo lindo
Te hablo de los problemas que ya hemos tenido, mira youtube.
Te l,o he explicado de varias formas diferentes , no insito mas
https://www.youtube.com/watch?v=jrGWMaUOSvk
Ese es el reloj , lo lógico es que todo estuviera actualizado para entonces, pero ya lo veremos..
https://www.epochalypse.today/
The signed 32-bit integer that is historically used to keep unix epoch time has already exhausted 89.07% of all possible values.
0
1100100
00000010
10000011
10101100
Only 5435 days (14 years) until it's finally 20:45:52 UTC on 13 December 1901 again!
Only 5435 days (14 years) until it's finally 20:45:52 UTC on 13 December 1901 again!
#61:
#25 ¡Hola!, que conversación tan interesante. He trabajado más de 20 años en programación de RTS y embebidos, os cuento mi visión por si a alguien le fuera de interés.
Para la sincronización y creación de temporizadores se emplea el reloj monotónico, que se reinicia junto al dispositivo, sobre todo en microcontroladores como los que comentas que ni siquiera suelen disponer de reloj de tiempo real (RTC). Además, estos dispositivos suelen sincronizarse con el entorno mediante E/S vía sensores y no mediante reloj.
La mayoría, por no decir la totalidad de los dispositivos que comentas no tienen ni siquiera conectividad a internet, donde es importante tener el RTC sincronizado exclusivamente por temas de cifrado de canal (SSL/TLS), que es donde interviene el reloj de tiempo real ya sea en HTTPS o túneles SSH. En TCP existe una cabecera timestamp que emplea el RTC, pero es opcional y la gran mayoría de sistemas hace caso omiso de esta, o la cumplimenta por dar compatibilidad pero no la revisa.
A mi sinceramente se me ocurren pocos sistemas críticos que dependan de un RTC y no puedan ser actualizados. Si algún sistema de 32 bits está haciendo de servidor NAS, SQL o HTTP, o incluso empleado como switch de red, tiene pinta de que va a ser un embebido cutre doméstico de mediados de 2010, con lo que en 2035 deberían estar más que muertos.
Desde 2020 cualquier linux tiene time_t de 64 bits, por lo tanto, el gran problema no parece que vaya a ser tan grande, más bien un problema de algunos gadgets a domésticos.
Para la sincronización y creación de temporizadores se emplea el reloj monotónico, que se reinicia junto al dispositivo, sobre todo en microcontroladores como los que comentas que ni siquiera suelen disponer de reloj de tiempo real (RTC). Además, estos dispositivos suelen sincronizarse con el entorno mediante E/S vía sensores y no mediante reloj.
La mayoría, por no decir la totalidad de los dispositivos que comentas no tienen ni siquiera conectividad a internet, donde es importante tener el RTC sincronizado exclusivamente por temas de cifrado de canal (SSL/TLS), que es donde interviene el reloj de tiempo real ya sea en HTTPS o túneles SSH. En TCP existe una cabecera timestamp que emplea el RTC, pero es opcional y la gran mayoría de sistemas hace caso omiso de esta, o la cumplimenta por dar compatibilidad pero no la revisa.
A mi sinceramente se me ocurren pocos sistemas críticos que dependan de un RTC y no puedan ser actualizados. Si algún sistema de 32 bits está haciendo de servidor NAS, SQL o HTTP, o incluso empleado como switch de red, tiene pinta de que va a ser un embebido cutre doméstico de mediados de 2010, con lo que en 2035 deberían estar más que muertos.
Desde 2020 cualquier linux tiene time_t de 64 bits, por lo tanto, el gran problema no parece que vaya a ser tan grande, más bien un problema de algunos gadgets a domésticos.
#50:
#29 menudos aires de grandeza te estás dando para las tonterías que estás diciendo.
"Haz pentesting y lo verás con tus ojos."
¿qué tiene que ver el pentesting con conocer el funcionamiento de una pila en arquitecturas intel?
"Me paso el día explicandoselo a compañeros , ingenieros , y no lo entienden."
igual ellos no lo entienden porque el que se lo está explicando tampoco. Un desbordamiento de pila es bastante fácil de entender si tienes unos conocimientos básicos de sistemas.
"Y la esctructura de un PE , portable ejecutable y como son los registros de una CPU . Te recomiendo empezar con un chip pequeño del tipo ESP32. "
Todo tu comentario es una clara falacia de autoridad, lo cual ya te desacredita por completo.
"Haz pentesting y lo verás con tus ojos."
¿qué tiene que ver el pentesting con conocer el funcionamiento de una pila en arquitecturas intel?
"Me paso el día explicandoselo a compañeros , ingenieros , y no lo entienden."
igual ellos no lo entienden porque el que se lo está explicando tampoco. Un desbordamiento de pila es bastante fácil de entender si tienes unos conocimientos básicos de sistemas.
"Y la esctructura de un PE , portable ejecutable y como son los registros de una CPU . Te recomiendo empezar con un chip pequeño del tipo ESP32. "
Todo tu comentario es una clara falacia de autoridad, lo cual ya te desacredita por completo.
#2:
#1 Cobol va a durar muchos años , pero es un lenguaje para un propósito diferente que C y C++ , preparo entornos de entrenamiento de Cobol para "estudiantes" , conozco la tecnología Mainframe y z/os , por desgracia por contrato de confidencialidad no puedo especificar mas. Cobol es un lenguaje vital , practicamente cualquier transacción económica implica COBOL . Es muy sencillo el 80% de las empresas del S&p 500 usan tecnología Mainframe y aunque en z/os tienes varios lenguajes , COBOL suele ser el mas usado . Cobol se sigue actualizando por ser vital para el funcionamiento del mundo . Así que viejo no eres .
Rust viene por un motivo diferente "overflow" de ahí vino el nombre de la página tan famosa Stack Overflow , desbordamiento de pila... de esos desbordamientos se aprovechaban antiguamente los virus y actualmente es un vector de ataque para un porcentaje muy alto de software. Rust no te deja compilar si hay desbordamientos de ese tipo , aunque tengas bien escrito todo , etc...
Rust viene por un motivo diferente "overflow" de ahí vino el nombre de la página tan famosa Stack Overflow , desbordamiento de pila... de esos desbordamientos se aprovechaban antiguamente los virus y actualmente es un vector de ataque para un porcentaje muy alto de software. Rust no te deja compilar si hay desbordamientos de ese tipo , aunque tengas bien escrito todo , etc...
#106:
#29
Rust no te deja compilar si hay desbordamientos
#24 procede a demostrar que ha compilado un código que provoca desbordamiento
…
No entiendes que es desbordamiento, los ingenieros tampoco lo comprenden, solo yo lo entiendo…
entre esto y el rollo espía de la KGB que traés con tu curro no se puede ser más patético jajajaj reconozco que me has alegrado la mañana ehhh
Rust no te deja compilar si hay desbordamientos
#24 procede a demostrar que ha compilado un código que provoca desbordamiento
…
No entiendes que es desbordamiento, los ingenieros tampoco lo comprenden, solo yo lo entiendo…
entre esto y el rollo espía de la KGB que traés con tu curro no se puede ser más patético jajajaj reconozco que me has alegrado la mañana ehhh
#24:
#22 A ver: El error me sale al ejecutar el programa compilado con Rust.
Es un coredump como cualquier otro. Y el error es diciendo que es un desbordamiento de pila me ha salido porque está compilado en modo debug, nada más.
Los desbordamientos de pila son inevitables si hay recursividad, es imposible que el compilador pueda saber de antemano el nivel de profundidad de las llamadas.
Es un coredump como cualquier otro. Y el error es diciendo que es un desbordamiento de pila me ha salido porque está compilado en modo debug, nada más.
Los desbordamientos de pila son inevitables si hay recursividad, es imposible que el compilador pueda saber de antemano el nivel de profundidad de las llamadas.
#26:
#23 tu me estas hablando de BSD y yo no te estoy hablando nada de BSD hablamos de cosas diferentes, es como si me pones de ejemplo mi windows .... obviamente yo tehablo de máquinas de 32 bits ... cualquier cosa que lleve un microcontrolador... incluso un coche con 15 años .... yo que sé como explicartelo ya !! disculpame , pero no hablamos de lo mismo.
#40:
#39 Los casos más triviales los detecta el compilador a tiempo:
fn main()
Al compilar te dice
error: this operation will panic at runtime
--> src/main.rs:4:5
|
4 | ar[1049] = 1;
| ^^^^^^^^ index out of bounds: the length is 1000 but the index is 1049
Si el índice es dinámico:
fn main()
}
✦ ❯ RUST_BACKTRACE=1 cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.00s
Running `target/debug/overflow`
thread 'main' panicked at 'index out of bounds: the len is 1000 but the index is 1000', src/main.rs:5:9
stack backtrace:
0: rust_begin_unwind
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:575:5
1: core::panicking::panic_fmt
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/panicking.rs:64:14
2: core::panicking::panic_bounds_check
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/panicking.rs:147:5
3: overflow::main
at ./src/main.rs:5:9
4: core::ops::function::FnOnce::call_once
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/ops/function.rs:507:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Las garantías estáticas de Rust no van de que tu programa nunca vaya a cascar - cualquiera puede hacer un programa que casque. Lo que no vas a poder hacer, al menos sin meter a propósito código que sea inseguro (y esté declarado como tal) es tener carreras (races) entre hilos, ni utilizar memoria una vez liberada, por ejemplo.
fn main()
Al compilar te dice
error: this operation will panic at runtime
--> src/main.rs:4:5
|
4 | ar[1049] = 1;
| ^^^^^^^^ index out of bounds: the length is 1000 but the index is 1049
Si el índice es dinámico:
fn main()
}
✦ ❯ RUST_BACKTRACE=1 cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.00s
Running `target/debug/overflow`
thread 'main' panicked at 'index out of bounds: the len is 1000 but the index is 1000', src/main.rs:5:9
stack backtrace:
0: rust_begin_unwind
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:575:5
1: core::panicking::panic_fmt
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/panicking.rs:64:14
2: core::panicking::panic_bounds_check
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/panicking.rs:147:5
3: overflow::main
at ./src/main.rs:5:9
4: core::ops::function::FnOnce::call_once
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/ops/function.rs:507:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Las garantías estáticas de Rust no van de que tu programa nunca vaya a cascar - cualquiera puede hacer un programa que casque. Lo que no vas a poder hacer, al menos sin meter a propósito código que sea inseguro (y esté declarado como tal) es tener carreras (races) entre hilos, ni utilizar memoria una vez liberada, por ejemplo.
#68:
#29 Rust evita el buffer over y underflow, no el stack overflow.
El caso que expone el compañero es una función recursiva sin caso base, cosa que Rust no es capaz de identificar.
Según las condiciones del sistema y problema puede producirse stack overflow incluso con la definición de un caso base, si como dice el compañero, la profundidad es grande ya que no se puede conocer de antemano. Por ejemplo en un gran grafo, o incluso en uno pequeño con un bucle (A-B-A-B...) si la función no ha sido pensada adecuadamente.
El caso que expone el compañero es una función recursiva sin caso base, cosa que Rust no es capaz de identificar.
Según las condiciones del sistema y problema puede producirse stack overflow incluso con la definición de un caso base, si como dice el compañero, la profundidad es grande ya que no se puede conocer de antemano. Por ejemplo en un gran grafo, o incluso en uno pequeño con un bucle (A-B-A-B...) si la función no ha sido pensada adecuadamente.
#41:
#32 y así, con un simple comentario, te acabas de marcar como objetivo ante cualquiera de la comunidad que pueda tener interés en "datos especialmente sensibles"... en una página poco segura (no es la primera vez que las bases de datos de mnm caen) y aumentado tus posibilidades de que te hagan un doxxing guapo para ver quien eres, a que te dedicas y si puedes ser un vector de acceso a lo que quiera que haces/tocas
#19:
#13 ojalá tuvieras razón. Solo te voy a poner un ejemplo , todas las raspberri pi con so de 32 bits... hay un experimento de alguien en internet qye le cambia la hora a una y casca por todas partes.
Nadie sabe que sucederá , se espera que esté todo a 64 para entonces... pero....
¿Tienes tu la censados todos los sistemas de 32 bits del planeta?
Chips, microcontroladores , .... quien sabe ...
En internet hay un reloj de cuenta atras.
Nadie sabe que sucederá , se espera que esté todo a 64 para entonces... pero....
¿Tienes tu la censados todos los sistemas de 32 bits del planeta?
Chips, microcontroladores , .... quien sabe ...
En internet hay un reloj de cuenta atras.
#3:
Que a qué? OpenBSD, OpenSSH, LibreSSL, NetBSD, FreeBSD, Linux, GNU C, GCC, Emacs...
Todos en C. A C le queda cuerda para rato.
De hecho Rust está bien para reemplazar a C++.
Sobre overflows, las mitigaciones de OpenBSD junto con pledge y unveil machacan el 99% de ataques.
Todos en C. A C le queda cuerda para rato.
De hecho Rust está bien para reemplazar a C++.
Sobre overflows, las mitigaciones de OpenBSD junto con pledge y unveil machacan el 99% de ataques.
Comentarios
#21 tu me estas hablando de un sistema operativo que usas tu ... yo te estoy hablando de los chips que regulan semáforos , lavadoras, coches , silos de agua , camiones , puentes , barcos , maquínas sencillas que llevan años , no creo que estés entiendo lo que digo ... estas pensando en un cojunto muy pequeño. Yo te hablo de todas las máquinas que tienen microcontroladores , no se de que otra forma decírtelo . Tu solo me hablas de BSD que se parchean en horas cuando aparecen bugs..
Yo te hablo del chip que controla el motor de un barco que tiene 40 años , y está encapsulado dentro de un motor y el jefe del barco no tiene un dongle para actualizarlo...
Te hablo del chip de un semáforo de un pueblo remoto , que lleva funcionando 20 años....
Te hablo de todo eso , ....
Insisto que internet hay varios experimentos cambiado la hora a varios sistemas operativos de 32 bits y cascan de lo lindo
Te hablo de los problemas que ya hemos tenido, mira youtube.
Te l,o he explicado de varias formas diferentes , no insito mas
Ese es el reloj , lo lógico es que todo estuviera actualizado para entonces, pero ya lo veremos..
https://www.epochalypse.today/
The signed 32-bit integer that is historically used to keep unix epoch time has already exhausted 89.07% of all possible values.
0
1100100
00000010
10000011
10101100
Only 5435 days (14 years) until it's finally 20:45:52 UTC on 13 December 1901 again!
Only 5435 days (14 years) until it's finally 20:45:52 UTC on 13 December 1901 again!
#25 Que lo entiendo de sobra. El firmware de muchas maquinas usa variantes de QNX y empotrados similares. Lo sé.
#25 ¡Hola!, que conversación tan interesante. He trabajado más de 20 años en programación de RTS y embebidos, os cuento mi visión por si a alguien le fuera de interés.
Para la sincronización y creación de temporizadores se emplea el reloj monotónico, que se reinicia junto al dispositivo, sobre todo en microcontroladores como los que comentas que ni siquiera suelen disponer de reloj de tiempo real (RTC). Además, estos dispositivos suelen sincronizarse con el entorno mediante E/S vía sensores y no mediante reloj.
La mayoría, por no decir la totalidad de los dispositivos que comentas no tienen ni siquiera conectividad a internet, donde es importante tener el RTC sincronizado exclusivamente por temas de cifrado de canal (SSL/TLS), que es donde interviene el reloj de tiempo real ya sea en HTTPS o túneles SSH. En TCP existe una cabecera timestamp que emplea el RTC, pero es opcional y la gran mayoría de sistemas hace caso omiso de esta, o la cumplimenta por dar compatibilidad pero no la revisa.
A mi sinceramente se me ocurren pocos sistemas críticos que dependan de un RTC y no puedan ser actualizados. Si algún sistema de 32 bits está haciendo de servidor NAS, SQL o HTTP, o incluso empleado como switch de red, tiene pinta de que va a ser un embebido cutre doméstico de mediados de 2010, con lo que en 2035 deberían estar más que muertos.
Desde 2020 cualquier linux tiene time_t de 64 bits, por lo tanto, el gran problema no parece que vaya a ser tan grande, más bien un problema de algunos gadgets a domésticos.
#86 Si crees que soy un tecnocuñado es que no has visto mis historial de comentarios.
Para todo lo demás, #61. Que un módulo RTC en hw usando hasta un GPS para ponerse en hora le cuesta calderilla a empresas. En Shenzhen los compras por toneladas.
Los habrá USB, serial o usando GPIO's, pero no te preocupes que eso para uno de ingeniería electrónica es un paseo.
#25 DIOS GRACIAS, estoy cansado de technocuñados que creen que programar es desarrollar páginas web
#4 Los coches de ahora y desde hace decadas, no llevan un chasis en si, sino que son monocasco. Lo mas parecido la chasis seria la plataforma, sobre la que se montan el techo, puertas, laterales.
Todoterrennos verdaderos eran los ultimos que llevaban chasis y carroceria separada, pero hasta el defender se ha pasado al monocasco.
#6 Creo que los F-35 tuvieron un problema de cambio de hora al sobrevolar la zona del pacifico donde se pasa de un dia a otro. Yo pienso que seria facil evitar esto usando UTC, para las cosas que necesitan una hora consistente y luego la represetancion la adaptas a la zona horaria.
#13 Yo entiendo que el problema es la implementacion en sofware y que el SO sea de 32bit deberia ser poco relevante. Es un problema previsible y añadir otro byte, no cuesta nada.
El hardware creaba el problema de que la bios no sabia representar al 2k. Pero por sofware, se puede suplir sabiendo que el punto de partida ya no es 1980, por ejemplo.
HAbia programas que lo hacian en el arranque, cuando no habia internet permanente ni NTP estaba extendido.
#25 OK, entiendo que aunque el problema puede ser facil de solucionar, hay muchos sistema que pueden haberse olvidado de un problema que dará la cara dentro de decadas.
#29 Creo que eres tú el que no entiende lo que es un overflow de pila Ni lo que hace Rust. Ya te he puesto un código trivial que te demuestra un programa en Rust que el compilador se traga sin problemas y que en ejecución casca con un stack overflow.
Aquí lo dejo que no vamos a llegar a nada.
#33 De lo que entiendo el resultado de un error de stack o overflow es un crash real de la máquina que acaba sin memoria donde escribir.
Ver un mensaje de stack overflow es una advertencia del compilador o del entorno de ejecución que no deja seguir el stack overflow.
En ese sentido se para el stack overflow, que sino resultaría en un crash irrecuperable, y no una ventanita que para el programa y te dice porque. Rust y C se pueden ejecutar en un OS que no tenga protección contra el stack overflow.
En Rust te ha salido una advertencia por lo menos :
warning: function cannot return without recursing
--> src/main.rs:1:1
|
1 | fn overflow() {
| ^^^^^^^^^^^^^ cannot return without recursing
2 | overflow();
| ---------- recursive call site
|
= help: a `loop` may express intention better if this is on purpose
= note: `#[warn(unconditional_recursion)]` on by default
warning: `playground` (bin "playground") generated 1 warning
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=ed4766b7217ec58a61eb7ca329e4ca95
#49 no, ningún desbordamiento de pila en espacio de usuario te cuelga un sistema. Un desbordamiento de pila en cualquier otro lenguaje hace exactamente lo mismo que hace RUST según ha puesto #10 en su comentario.
Es el manejador de memoria del sistema operativo el que en TODOS los casos detecta que el proceso está intentando escribir en direcciones de memoria (virtuales) que no le corresponde.
#49 Eso lo hacen TODOS los lenguajes, no solo rust.
#49 Ver un mensaje de stack overflow es una advertencia del compilador
¿Qué? No.
#33 SI lo que quieres es demostrar un stack overflow, no deberías dejarlo.
#76 ya está demostrado, no tengo nada más que añadir
#83 No lo has pillado.
#83 No has entendido la intención de #76. Bueno, supongo que la mayoría no lo entendió. Por eso pasó desapercibido.
#76 O podría hacer referencia a su propio comentario. Mejor demostración que esa, creo que no hay
#29 menudos aires de grandeza te estás dando para las tonterías que estás diciendo.
"Haz pentesting y lo verás con tus ojos."
¿qué tiene que ver el pentesting con conocer el funcionamiento de una pila en arquitecturas intel?
"Me paso el día explicandoselo a compañeros , ingenieros , y no lo entienden."
igual ellos no lo entienden porque el que se lo está explicando tampoco. Un desbordamiento de pila es bastante fácil de entender si tienes unos conocimientos básicos de sistemas.
"Y la esctructura de un PE , portable ejecutable y como son los registros de una CPU . Te recomiendo empezar con un chip pequeño del tipo ESP32. "
Todo tu comentario es una clara falacia de autoridad, lo cual ya te desacredita por completo.
#22 A ver: El error me sale al ejecutar el programa compilado con Rust.
Es un coredump como cualquier otro. Y el error es diciendo que es un desbordamiento de pila me ha salido porque está compilado en modo debug, nada más.
Los desbordamientos de pila son inevitables si hay recursividad, es imposible que el compilador pueda saber de antemano el nivel de profundidad de las llamadas.
#24 Entonces no entiendes como funciona el overflow
No estás entendido como hace Rust para evitar el overflow y no entiendes bien el overflow .
Haz pentesting y lo verás con tus ojos.
Me paso el día explicandoselo a compañeros , ingenieros , y no lo entienden.
Para entenderlo te recomiendo que veas un poquito de ensamblador y lo entenderás mejor.
Y la esctructura de un PE , portable ejecutable y como son los registros de una CPU . Te recomiendo empezar con un chip pequeño del tipo ESP32.
#29 Joder, no es tan complicado. Creas una variable local char[10] y escribes en ella 74 bytes....
Tachán!!
#7 #20 #109 Conoceis a mackuskey? es tambien un abuelo informatico que cuenta historias de informatica del año catapum.
https://eltamiz.com/elcedazo/author/macluskey/
Creo que tiene un libro de Historia de un Viejo informatico.
https://eltamiz.com/elcedazo/2009/03/31/historia-de-un-viejo-informatico-la-irresistible-irrupcion-del-pc-en-la-empresa-y-en-nuestras-vidas/
#68 #66 Eso entiendo yo que las gestion de memoria en C no tiene "topes" y si te sales, puede acabar en otra zona de memoria y si puede elegir donde, meterte en otras zonas y hacer cosas no previstas.
En pascal, creo que el BIt 0 tiene la longitud del array y en Rust, no se como evitar salirte de la memoria asignada.
#45 No responte tu pregunta. Pero Qmail tiene un diseño en dos partes. Una pequeña y sencilla y facil de vigilar conectada a internet y el resto de programa que se conecta a internet a traves de la anterior y solo le va a dejar acciones concretas. Ofrecen recompensa a quien encuentre un bug que les de acceso.
https://en.wikipedia.org/wiki/Qmail
Por otra parte yo seria partidario de limitar los permisos al minimo a los programas, no solo a todo el usuario.
Un word, necesita aceso a ficheros temporales y un sitema de guardar los archivos que se puede delegar en otro programa asegurado.
Un firefox parecido y se podria limitar lo que puede tocar en el disco duro y las acciones que pueda hacer por internet.
#29 Rust evita el buffer over y underflow, no el stack overflow.
El caso que expone el compañero es una función recursiva sin caso base, cosa que Rust no es capaz de identificar.
Según las condiciones del sistema y problema puede producirse stack overflow incluso con la definición de un caso base, si como dice el compañero, la profundidad es grande ya que no se puede conocer de antemano. Por ejemplo en un gran grafo, o incluso en uno pequeño con un bucle (A-B-A-B...) si la función no ha sido pensada adecuadamente.
#29
Rust no te deja compilar si hay desbordamientos
#24 procede a demostrar que ha compilado un código que provoca desbordamiento
…
No entiendes que es desbordamiento, los ingenieros tampoco lo comprenden, solo yo lo entiendo…
entre esto y el rollo espía de la KGB que traés con tu curro no se puede ser más patético jajajaj reconozco que me has alegrado la mañana ehhh
#23 tu me estas hablando de BSD y yo no te estoy hablando nada de BSD hablamos de cosas diferentes, es como si me pones de ejemplo mi windows .... obviamente yo tehablo de máquinas de 32 bits ... cualquier cosa que lleve un microcontrolador... incluso un coche con 15 años .... yo que sé como explicartelo ya !! disculpame , pero no hablamos de lo mismo.
#26 Dejale, su sistema operativo está parcheado
#26 El ha venido a hablar de su peli, tu déjale que siga.
En su cabeza todo suena genial.
#21 Los apóstoles de *BSD sois pesadísimos. Argumentar que los sistemas usan 64 bits desde hace eones porque lo usáis cuatro frikis en vuestros sistemas de chichinabo (ni siquiera es popular en servidores) es absurdo.
#85 Solo en Netflix, la PS4, en routers, OpenSSH en TODAS partes (adivina de dónde sale)....
Si tu supieras...
#85 Sin OpenBSD no tendrias LibreSSL, OpenSSH y cientos de mitigaciones.
Tendrías que usar un GNU LSH (que no usa ni dios) con más RCE's que un emulador de binarios.
De hecho en OpenBSD mandaron al cuerno linux_compat ya que podría ser un coladero. Total, hay versiones nativas de casi todo.
Que a qué? OpenBSD, OpenSSH, LibreSSL, NetBSD, FreeBSD, Linux, GNU C, GCC, Emacs...
Todos en C. A C le queda cuerda para rato.
De hecho Rust está bien para reemplazar a C++.
Sobre overflows, las mitigaciones de OpenBSD junto con pledge y unveil machacan el 99% de ataques.
#3 con Rust no tienes que mitigar mucho , ni si quiera tiene recolector de basura. OpenBsd de base es cojonudo , el problema es cuando se instala programas compilados en C y C++.
Ese 1% que dejas al aire es suficiente para que te ataquen y te roben todos los datos.
Un sistema es tan fuerte como su parte mas debíl.
#9 Todos los programas están compilados con opciones de seguridad y que hacen que sea bastante chungo por no decir imposible operar exploits. Todos.
#14 pues estas muy equivocado , te lo dice alguien aficionado al pentesting. Pregutales a los de lastpass . Por tu afirmación no debes saber nada de programacion. El 60% de los ataques a chrome es por overflow.... busca em google o estudia pentesting... a diario se rompen programas , claves , etc...hay demasiados agujeros...
#16 El que no conoce las mitigaciones de OpenBSD eres tu. Se aplican a cada port, es una CFLAG y CXXFLAG. Y por supuesto las LDFLAGS inseguras para usar un JIT como por ejemplo WXNEEDED en emuladores como PPSSPP han de establecerse explícitamente, si no el emulador al abrir un juego te va a cascar maravillosamente al intentar un W^X o ir horrorosamente lento.
#17 mitigaciones , tu lo dices . Tambien has dicho 99% ... es decir que un 1% queda expuesto , tu lo que lo conoces lo has dicho muy bien .
Ese 1% es suficiente para que se lie bien gorda.
Tampoco Rust lo va a solucionar todo , eso esta claro .
#30 No, no se lía. Pledge lo va a mandar a ATPC si intenta abrir una syscall. Pledge es implícito, no es explícito com Selinux en Linux. En OpenBSD si un programa compilado con pledge intenta acceder a una syscall el kernel le va a mandar un sigabrt bien guapo.
Con unveil no vas a ver desde el VFS nada que no se te haya indicado. Ni patrás. No es que que el exploit no intente un open o fopen, es que literalmente el proceso y subproceso los ficheros no existen para el, el kernel no los expone.
#34 OpenBSD es una pasada lo sé , pero también lo es es sistema de seguridad de un banco , pero si te abre la puerta el dueño del banco hasta el dinero ... .no se si me explico , OpenBSD es tremendamente seguro con el mayor porcentaje que te puedas esperar , pasa igual con los Mainframe de IBM que z/os que es unix .
Practicamente todo lo que es Unix es muy seguro , por suerte para todos nosotros , nuestros datos vitales descansan sobre BBDD que están en sistemas Unix. Imaginate que se descargan nuestros datos de la seguridad social , del banco o algo así directamente desde la BBDD , sería problema muy serio.
Por eso no se debe instalar cualquier mierda de programa , mira lo que les ha pasado a los de Lastpass , a un ingeniero de DEVOps le atacaron un programa de reproducion multimedia ... y a través de eso entraron en su nuve de amazón.... es decir les abrió la puerta hasta la cocina...
#16 Sobre CHrome, el Chromium de OpenBSD usa pledge y unveil por defecto, y no tiene WASM activado de serie. /etc/login.conf tiene limites de procesos y uso de memoria que o se aumentan o el software casca que da gusto.
Por lo general, en el 99% de los casos, si encima usas UBo, Chromium ni se va a enterar. En el resto antes de que pase algo Chromium casca pero de pleno al intentar usar alguna syscall que no este visibilizada desde pledge. Con unveil impides que se accedan a cosas como ~/.ssh y no salga de ~/Downloads y ~/.local/share/chromium (y otras rutas del sistema) para operar.
En Firefox para OpenBSD era mágico. En el cuadro de descargas y subidas de GTK+ no salía ni $HOME como ruta a entrar, no te dejaba. ~/Downloads como ruta absoluta y gracias. No, tampoco ibas a ".." . O directo a ~/Descargas, o no entrabas.
#31 Google lo sabe , busca en meneame y verás que han ordenado usar Rust... . Microsoft lo mismo ha ordenado usar rust , Github esta usando rust en su motor de búsqueda experimental .. Creo que también usan Go pero desconozco ese lenguaje .. ni idea como va. ...
#31 Una pregunta desde el desconocimiento vuestro:
Si usas OpenBSD y chromium y a este último le hacen un overflow, ¿no podrían acceder a los datos guardados en el propio chromium sin acceder al sistema?
¿Con esto te podrían robar cookies de sesión, o contraseñas guardadas (si no tienes habilitado algo que proteja esas contraseñas con otra contraseña) o incluso manipular tu navegador para que haga alguna acción desde tu navegador (crear una cuenta en alguna interfaz web, usar tu sesión para robar datos, por ejemplo del repositorio)?
Como os veo metidos en esto de la seguridad, a ver si me podéis ayudar con una duda estúpida:
El otro día hablaba con un amigo sobre si cifrar el .env de un proyecto de django y yo argumenté que si alguien te entra por la propia instancia de django, será capaz de leer la clave de descifrado almacenada en un archivo del propio proyecto (manage.py), con lo que el único motivo para cifrar eso es que alguien pueda desde tu sistema operativo leer ese archivo, pero de nuevo, si pueden leer ese archivo podrán leer manage.py y decifrar el .env.
Solo te sirve para poder subir el .env a un repositorio público, y para que sea eficaz tienes que poner el manage.py en el git ignore para que no suba la clave de decifrado. Con lo cual seria mejor poner el .env en el git ignore y dejar el manage.py ya que contiene una información más útil para el proyecto (como qué fuentes de datos usas, que pueden ser varias) y sin exponer ningún dato crítico (ip, puerto, usuario y contraseña).
Vamos, que no sirve de nada cifrar un archivo cuando quien pueda leer el archivo también va a poder leer el que lo decifra.
Perdonad el offtopic pero me he puesto a pensar, OpenBSD puede ser todo lo robusto que quiera, pero al final, solo hace falta permisos de ejecución de la propia aplicación para hackear los datos de esa aplicación, los permisos del sistema sería más para tema de ramsonware o virus.
Es que no entiendo como funciona el overflow, pensaba que era básicamente "colgar" un software para "prácticamente" permitirte lanzar código "no autorizado" en un sistema, aunque sean con permisos del mismo software.
#45 No tiene sentido cifrar el .env por los problemas que expones. Y tampoco subirlo al repo salvo que tenga valores de ejemplo.
La buena práctica es cargar la configuración a partir de variables de entorno. Los archivos no les gustan mucho a los sysadmins.
Aquí hablan, entre otras cosas, sobre cómo configurar un server.
https://12factor.net/
#45 > overflow
Primero que lo intenten, (ROP), y segundo que pledge no actue mandando el proceso a hacer gárgaras.
#31 No uso OpenBSD, pero se puede lograr lo mismo con SELinux y AppArmor. Y también tienes el típico limits.conf que tiene el tema de los límites (para memoria, ficheros abiertos, etc). O directamente los namespaces
#52 No, no es lo mismo. Los namespaces y SeLinux son explícitos. En el caso de pledge y unveil es implicito. Si el programa intenta algo fuera de lo admitido, segfault desde el kernel.
#16 a los de LastPass? Lo dices por el "incidente" de hace unos meses?
#9 OpenBsd de base es cojonudo , el problema es cuando se instala programas compilados en C y C++.
Jamás adivinarías en qué está desarrollado BSD...
#3 C es incluso peor que C++ en este aspecto
#15 Te estaba buscando un artículo de un programador de C y creo que dice lo contrario , pero como guardo tantos links favoritos , necesito un buscador para buscar entre mis links favoritos jejejejej
Luego si lo encuentro te lo paso .
Rompo un lanza en tu favor diciendo que yo pensaba igual que tu.
#3 Linux ya acepta Rust en nuevos desarrollos del kernel. No van a migrar lo que ya hay, obviamente, pero Linus ya dio el visto bueno a Rust y se están añadiendo cosillas.
#13 ojalá tuvieras razón. Solo te voy a poner un ejemplo , todas las raspberri pi con so de 32 bits... hay un experimento de alguien en internet qye le cambia la hora a una y casca por todas partes.
Nadie sabe que sucederá , se espera que esté todo a 64 para entonces... pero....
¿Tienes tu la censados todos los sistemas de 32 bits del planeta?
Chips, microcontroladores , .... quien sabe ...
En internet hay un reloj de cuenta atras.
#19 Repito, se usa un time_t de 64 desde hace bastante, al menos en los BSD. No hablo de 5 ni 10 años, ya en el 2007 creo que tuve OpenBSD y el límite estaba más que adaptado.
Ahora bien, si tienes una Debian Lenny o Squeeze de la época, pues allá tu.
#19 OpenBSD https://undeadly.org/cgi?action=article&sid=20130813072244
Si hablamos de parches no oficiales para el y2k38 s los hay hasta para BSD 4.3 bajo SIMH en una VAX
Como ejercicio es cojonudo, y el código en C no es precisamente difícil de retocar.
#19 las raspi nuevas (4) son de 64 bits, y la empresa Raspberry ya soporta raspbian_64
#12 Pero si ese error es en ejecución...
#18 ¿pero tienes el error no? Pues eso....
¿Para ejecutar usas el compilador dd Rust no?
Pregunto porque a lo mejor me pierdo algo.
En mi trabajo diario si me da un error de ejecución no puedo seguir y tengo que arreglarlo...
#22 Eso también da error en C.
No es ese el problema de la vulnerabilidad de desbordamiento de buffer.
Ahí lo único que ocurre es que llenas la pila. La vulnerabilidad consiste en desbordarla para sobreescribir datos guardados aprovechando variables creadas en la pila
#65 en realidad el desbordamiento de la pila sólo es el síntoma de que esa pieza de código es potencialmente explotable. Para explotarla no desbordas la pila sino el espacio reservado para alguna variable automática dentro de la misma pila y escribir en otra parte del marco de ese contexto de ejecución, normalmente la dirección de retorno.
#84 Eso es lo que acabo de decir.
#95 tienes razón, no me di cuenta de "desbordamiento de buffer" y no "desbordamiento de pila". Perdón.
#4 exacto . Te añado algo ahora viene el efecto 32bits , en 14 años los contadores de 32 bits se reinician y habrá problemas muchos mas gordos que con el efecto 2000. Todo lo que sea de 32 bits y use un calendario se tuene que actualizar . En el canal derivando de youtube puedes ver varios problemas. Mis respetos a un programador de COBOL. Un abrazo gracias!!!
#6
#6 Te equivocas. Los sistemas de 32 bits usan un time_t de 64 desde hace eones. Más de 10 años mínimo. Al menos OpenBSD y creo que NetBSD desde una década como digo.
#13 Nop. https://wiki.debian.org/ReleaseGoals/64bit-time
#39 Los casos más triviales los detecta el compilador a tiempo:
fn main()
Al compilar te dice
error: this operation will panic at runtime
--> src/main.rs:4:5
|
4 | ar[1049] = 1;
| ^^^^^^^^ index out of bounds: the length is 1000 but the index is 1049
Si el índice es dinámico:
fn main()
}
✦ ❯ RUST_BACKTRACE=1 cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.00s
Running `target/debug/overflow`
thread 'main' panicked at 'index out of bounds: the len is 1000 but the index is 1000', src/main.rs:5:9
stack backtrace:
0: rust_begin_unwind
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:575:5
1: core::panicking::panic_fmt
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/panicking.rs:64:14
2: core::panicking::panic_bounds_check
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/panicking.rs:147:5
3: overflow::main
at ./src/main.rs:5:9
4: core::ops::function::FnOnce::call_once
at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/ops/function.rs:507:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Las garantías estáticas de Rust no van de que tu programa nunca vaya a cascar - cualquiera puede hacer un programa que casque. Lo que no vas a poder hacer, al menos sin meter a propósito código que sea inseguro (y esté declarado como tal) es tener carreras (races) entre hilos, ni utilizar memoria una vez liberada, por ejemplo.
Quedan al menos un par de décadas para que todo lo que hoy se hace en C++ se haga en Rust. Y no tengo claro que vaya a pasar.
Rust está guapísimo, es un lenguaje cojonudo, pero el mundo entero está hecho en C y C++ y eso no se cambia de la noche a la mañana. Por otro lado, C++ está viviendo una segunda juventud: el lenguaje ha mejorado muchísimo con respecto a hace 15 años, no digamos ya 25. Sigue siendo el lenguaje premier para videojuegos, sistemas de IA, ML, etcétera.
Igual que Python destronó a Java para muchísimas aplicaciones, Rust quizá termine destronando a C++ que es su objetivo real. Pero seguramente muchos estemos ya jubilados cuando eso suceda.
(*) Y Python es más antiguo que Java
#5 python y java compilan en C y C++.
Ten en cuenta los niveles de los lenguajes.
Maquina
Ensamblador
C , C++ , Rust ...etc
Python , java etc
Lenguajes de muy alto nivel , yo uso uno que no puedo nombrar por confidencialidad.
Rust es un lenguaje de bajo nivel , entra en contacto con el hardware directamente.
Hoy en dia sl usar c y c++ hay que usar programas auxiliares para verificsr el código.
Por eso el tema es bastante gordo , pero se tardará décadas como tu dices.
#11 Prolog?
#27 no lo puedo decir , disculpame de verdad , un saludo . Me dan miles de ganas de decir lo que hago , pero por seguridad no puedo ser preciso , lo siento. Los datos que movemos son muy sensibles .
#32 y así, con un simple comentario, te acabas de marcar como objetivo ante cualquiera de la comunidad que pueda tener interés en "datos especialmente sensibles"... en una página poco segura (no es la primera vez que las bases de datos de mnm caen) y aumentado tus posibilidades de que te hagan un doxxing guapo para ver quien eres, a que te dedicas y si puedes ser un vector de acceso a lo que quiera que haces/tocas
#41 yo estoy flipando, llevo pensando lo mismo cada vez que leo un comentario suyo.
Hago cosas muy importantes, muy sensibles, vuestra vida depende de mi, se más que todos vosotros juntos pero eh, no puedo decir nada, acuerdo de confidencialidad.
O es un invento o es un inconsciente
#74 Le da vergüenza decir que usa Visual Basic.
#41 Suena a la típica vecina: "me han contado una cosa mu mala de la Puri la del 5° A, pero no me preguntes que no te lo puedo contar"
#32 Pues no lo iría explicando por ahí. Creo que el propio comentario ya da pistas
#27 Prolog está enfocado a su uso en inteligencia artificial.
#73 No le des muchas vueltas. Mi comentario sobre Prolog solo es un reflejo de un trauma laboral personal durante décadas.
#11 python y java compilan en C y C++
No es cierto. Tanto Python como Java suelen compilarse a bytecode. Java también se compila a código máquina en algunos entornos.
El que sí compila a C es Cython, un superset de Python.
#47 Tanto el intérprete de python como la máquina virtual de Java están hechos en C++. Otra cosa es que ambos sean JIT que convierten Java/Python a código máquina sobre la marcha.
#60 Eso no tiene nada que ver. El propio SO está hecho en C, y ahí compilas programas Rust.
Es posible que se pueda "compilar" a C Java, Python, Rust o lo que te dé la gana..... Si tienes un "compilador" que lo haga.
Java en Linux por ejemplo tiene un compilador a código máquina nativo (no a C)
#60 Nada de eso tiene que ver con que Java y Python compilen a C.
Tanto el intérprete de python como la máquina virtual de Java están hechos en C++.
La implementación oficial de Python, CPython, está escrita en C, no en C++, pero también existen implementaciones en otros lenguajes, como PyPy (escrita en RPython, un subset de Python). Por otra parte, existen compiladores y máquinas virtuales de Java escritos en diferentes lenguajes: C, C++, Java, Smalltalk...
Otra cosa es que ambos sean JIT que convierten Java/Python a código máquina sobre la marcha.
Nope. Lo que se convierte a código máquina sobre la marcha es el bytecode, no el código fuente. Y CPython no incluye JIT, otras implementaciones como PyPy o Jython sí.
#11 Joder debes trabajar en la CIA para no poder decir el lenguaje de muy alto nivel que usais en el curro...
#5 Ya está pasando Dentro de Microsoft, uno de los principales valedores de C++, hay muchos proyectos en curso de migración a Rust. Sobre todo en las áreas de Azure y Windows 11.
Hay que tener en cuenta el 70% de los parches de seguridad de Windows provienen de errores de memoria que se habrían evitado con Rust.
Y, en el otro extremo, el de los haters de C++, también hay movimientos importantes. Rust se va a convertir en el segundo lenguaje oficial para el kernel de Linux. Hasta ahora sólo C tenía ese privilegio.
Joder qué viejo soy, yo era de Cobol. 🗿
#1 Cobol va a durar muchos años , pero es un lenguaje para un propósito diferente que C y C++ , preparo entornos de entrenamiento de Cobol para "estudiantes" , conozco la tecnología Mainframe y z/os , por desgracia por contrato de confidencialidad no puedo especificar mas. Cobol es un lenguaje vital , practicamente cualquier transacción económica implica COBOL . Es muy sencillo el 80% de las empresas del S&p 500 usan tecnología Mainframe y aunque en z/os tienes varios lenguajes , COBOL suele ser el mas usado . Cobol se sigue actualizando por ser vital para el funcionamiento del mundo . Así que viejo no eres .
Rust viene por un motivo diferente "overflow" de ahí vino el nombre de la página tan famosa Stack Overflow , desbordamiento de pila... de esos desbordamientos se aprovechaban antiguamente los virus y actualmente es un vector de ataque para un porcentaje muy alto de software. Rust no te deja compilar si hay desbordamientos de ese tipo , aunque tengas bien escrito todo , etc...
#2 Gracias por echarme un cable frente a mi senecto-complejo. Entiendo esa pervivencia claro, Cobol es como los chasis, llegan nuevos motores, nuevas direcciones, nuevas funcionalidades... y ahí siguen tan simples, robustos y funcionales. Fíjate si hará tiempo que lo último que hice fue un sinfín de adaptaciones (y nuevos programas y procedimientos de comandos) para el "efecto 2000". Ahora mi nieto me da sopas con honda. Un saludo y suerte en lo tuyo.
#4 Cobol fue creado con la idea de que los oficinistas fueran capaces de escribir código, de ahí las instrucciones que parecen frases.
Ahora Microsoft vuelve a las andadas con Power FX, que será programar usando las fórmulas de Excel.
#71
#2 Yo trabajé para el mainframe de La Caixa, pero usabamos (y aun usan) PL/1. Hice poco de COBOL pero PL/1 me parecia mucho mejor.
#7 Yo igual, trabajé hace años para el de Deutsche Bank y también se usaba mucho PL/1 y COBOL, aunque no sé como estarán de actualizados hoy en día.
#20 Cuando trabajé para Banca Catalana era todo en PL1, más algo de assembler. El PL/1 es muy superior al COBOL. Puedes traducir un programa de COBOL línea a línea a PL/1, pero PL/1 puede hacer mucho mas. Por ejemplo les escribí un analizador sintáctico de PL/1 usando apuntadores a memoria para construir el árbol.
¿Deutsche? Crecieron mucho en sistemas medios, usando Java, C, y hasta COBOL, que sólo atacan al mainframe (Frankfurt) a base de CICS. El batch sigue siendo el de siempre, que lo van manteniendo a base de sustos y lloros.
Cuando aparecí por Deutsche había mucha gente que me conocía, algunos de Catalana, pero también otros de haber pasado por Caixa, y aún a algunos les sonaba de verme en la máquina de cerveza en el edificio de Sant Cugat. Este es un mundo pequeño.
#2 En Rust puedes tener desbordamientos de pila sin ningún problema.
fn overflow()
fn main()
thread 'main' has overflowed its stack
fatal runtime error: stack overflow
Aborted (core dumped)
#10 esa es la historia , el compilador no te deja seguir , fatal error...
#10 #12 Se comprueba en dos segundos, y Koji tiene razón.
#38 No había visto nunca ese warning sobre recursividad. El compilador de Rust es una pieza de software increíble.
#63 Creo que ese mensaje era para #59 Y estoy de acuerdo
Es un código muy simple y por eso sale el warning.
#38 Porque es un código trivial, supongo que a la que metes una variable ya se lo traga.
#63 Si te refieres a algo así, sigue detectándolo. Lo cual no es sorprendente, dado que el compilador lleva la cuenta de dónde se asignan los valores.
Es decepcionante que no sea un error "duro" en vez de un warning, pero detectarlo en tiempo de jubilación entra dentro del problema de parada.
#12 te lo está diciendo el propio error, "fatal runtime error: stack overflow". No conozco Rust pero el ejemplo que ha puesto #10 es exactamente igual que en C.
#12 Tío, ese error no es a nivel compilador, sino en runtime (es decir, el código debe haber entrado en el flujo correspondiente para que se den las condiciones), y está generando un coredump...
#10 me interesa, cuando en C hay un arreglo de 1000 posiciones por ejemplo y asignó en la posición 1050, puede que haya un error o puede que no y se caiga más adelante. En Java, el programa se detiene y me muestra en que línea hubo la mala asignación. ¿Rust es como Java?
#10 Esto en Excel te da #EXE. Hay que poner un límite en alguna parte.
#2 COBOL is a domain specific language 😉
#2 Rust no te deja compilar
Más que el lenguaje en sí, entiendo que la cualidad de Rust reside en cómo compila el código.
#2 sencillo?
Perdona, se que las comparaciones son odiosas - pero el Cobol es como jugar al Mario Bros en su conceptualización
https://www.archdaily.com.br/br/782588/papel-quadriculado-a-origem-de-super-mario-bros/56c5b229e58ece6a88000089-papel-quadriculado-a-origem-de-super-mario-bros-imagem
#62 genial ejemplo, me lo guardo para futuras ocasiones
#2 bien pero… confundes Stack Overflow (el que da nombre a la página) con Buffer Overflow (el problema de seguridad habitual en C).
#2 overflow y memoryleak
#2 mr programmer, los signos de puntuación solo llevan espacio despues, no antes. Te lo digo buenrrollerísimamente, que tu redacción es bastante impecable y sin duda tienes que corregir eso.
#2 En el año 9900 los programadores de cobol estarán angustiados porque se acerca el año 10000 y habrá trillones de líneas por revisar.
#1 Viejo no, desactualizado, yo desde que uso Rust ganó más dinero haciendo mucho menos.
Pasate a Rust, cada vez somos más.
#81
Tal vez en una próxima vida, en esta ya entregué mis 42 tacos de servicio y quedo desfondado.
#81 en qué sector (fintech, electrónica de consumo, crypto, browser engines) y qué tipo de trabajo, si se puede saber? (Remoto, presencial, híbrido)
Y en España o fuera (o desde España pero para cliente fuera)
Si prefieres mantener el anonimato y responder solo a una, que sea la primera, plis
#1 Aqui otro, que estuvo trabajando en AS-400 por el tema del efecto 2000.
Rust is C with a straight jacket.
Se le estropea el ascensor y crea un nuevo lenguaje tela... Lo barato q sería haber arreglado el ascensor
Disclaimer: Pregunta humilde desde la ignorancia más absoluta.
Tras leer de momento un trozo del artículo ya me surge una pregunta por el problema de la gestión y limpieza de la memoria: ¿Y no hay ningún software o incluso IA que sea capaz de corregir esos problemas al final de la fase de escritura del código fuente y una vez limpio este entonces compilar?
#88 hay herramientas de análisis estático (a partir el código fuente) y dinámico (usan el programa compilado). Son muy útiles y se podrían utilizar mucho más, la verdad.
#88 Ya se hace. El problema es que hay errores de programación que son indetectables hasta que se da la circunstancia exacta en la ejecución.
#88 En el caso general, no.
https://es.m.wikipedia.org/wiki/Problema_de_la_parada
En concreto, este párrafo:
_Lo que se afirma es que no existe una manera automática computable de saber si todos los programas posibles terminan. No se niega que exista la prueba para programas concretos. De hecho, la construcción de pruebas para programas concretos es un paso obligatorio para demostrar su correctitud._
Con lo que, o limitas los programas que se pueden escribir (en el caso de Rust mediante reglas sobre qué código es el propietario de qué regiones de memoria, y qué referencias pueden existir a esa memoria en un momento dado), o, post-facto, sólo podrás eliminar un porcentaje (mayor o menor) de los problemas.
¿En qué lenguaje está escrito Rust?
#89 En Rust
#89 no tengo ni idea, ni ganas de mirarlo ahora, pero básicamente todos los compiladores empiezan escribiéndose en otro lenguaje ya existente hasta que llegan a un punto de desarrollo en el que son capaces de compilarse a si mismos.
"El lenguaje que ha destronado a C". Chan Chan Chaaaaaan