Portada
mis comunidades
otras secciones
#9:
#6
-Uhh Mike está teniendo problemas con el chequeo de sintaxis y puede que su codigo no llegue a compilar
-Si Tim, ha intentado primar la velocidad de desarrollo sin ir haciendo comprobaciones poco a poco y ahora se encuentra con un montón de codigo espagutti plagado de errores, no se como lo va a solucionar.
-Además parece que su madre se ha olvidado de traerle el inhalador por lo que es posible que se encuentre con problemas debido a las gramineas.
-Uhh Mike está teniendo problemas con el chequeo de sintaxis y puede que su codigo no llegue a compilar
-Si Tim, ha intentado primar la velocidad de desarrollo sin ir haciendo comprobaciones poco a poco y ahora se encuentra con un montón de codigo espagutti plagado de errores, no se como lo va a solucionar.
-Además parece que su madre se ha olvidado de traerle el inhalador por lo que es posible que se encuentre con problemas debido a las gramineas.
#2:
Hay un punto a partir del cual, tienes que confiar en alguna caja negra, es lo que hay, no puedo forjar mi propio silicio
#8:
#5 Para eso tienes los certificados de auditoria, yo monto algo sobre dos sistemas que tienen el sello de X, que a su vez se basan en dos sitemas que tienen el sello de X que a su vez se basan en tres sistemas que tienen el sello de X
Y ese puto sello tiene que ir a misa porque si no el castillo de naipes se cae, mira por ejemplo el engendro que estoy montando ahora interconecta 6 sistemas de su padre y de su madre que van desde contabilidad a ventas, tio pues yo en base a los interfaces y la especificacion aprobada que me dan me tengo que fiar que hacen lo que me dicen y como me lo dicen, no puedo auditar todo.
Luego si hay fallos pues si ya rastreo quien ha sido el cabron que me ha mentido
Y ese puto sello tiene que ir a misa porque si no el castillo de naipes se cae, mira por ejemplo el engendro que estoy montando ahora interconecta 6 sistemas de su padre y de su madre que van desde contabilidad a ventas, tio pues yo en base a los interfaces y la especificacion aprobada que me dan me tengo que fiar que hacen lo que me dicen y como me lo dicen, no puedo auditar todo.
Luego si hay fallos pues si ya rastreo quien ha sido el cabron que me ha mentido
#21:
#16 Aquí hablan de software y el compilador, no de sensores y motores del mundo fisico, y aún así te diré pese a que lleve años sin tocar ese mundo yo técnicamente soy ingeniero industrial en robótica, y si, tu cuando montas un sistema en el mundo físico, el concepto es exactamente el mismo, me tengo que fiar del fabricante y sus especificaciones.
Si después hay errores pues se rastrea quien miente, pero tu no puedes reinventar la rueda, te tienes que basar en alguna caja negra (la cual ha sido auditada previamente, las especificaciones en segun que sistemas tienen categoría de documento legal)
Si después hay errores pues se rastrea quien miente, pero tu no puedes reinventar la rueda, te tienes que basar en alguna caja negra (la cual ha sido auditada previamente, las especificaciones en segun que sistemas tienen categoría de documento legal)
#66:
#17 cuando trabajo bien, hago a mi empresa fuerte y competitiva, la competencia se resiente, y en algunos casos los manda a la bancarrota, familias enteras afectadas negativamente, depresión, suicidios, algunos caen en el lado oscuro criminal, hay homicidios, trata de blancas, narcotráfico, mafia, delincuencia organizada..... Y todo por hacer mi trabajo bien
#12:
Llevo 20 años trabajando en el desarrollo de software y una de las pocas cosas -o la única- que siempre he tenido clara es la decisión de no trabajar en aplicaciones donde haya vidas en juego: hospitales, transportes, etc. Quiero poder dormir tranquilo sabiendo que mi peor error puede provocar una pérdida económica o de productividad. O que a una mala me podrían incluso despedir. Pero que la cosa nunca tendrá consecuencias más graves.
Comentarios
#6
-Uhh Mike está teniendo problemas con el chequeo de sintaxis y puede que su codigo no llegue a compilar
-Si Tim, ha intentado primar la velocidad de desarrollo sin ir haciendo comprobaciones poco a poco y ahora se encuentra con un montón de codigo espagutti plagado de errores, no se como lo va a solucionar.
-Además parece que su madre se ha olvidado de traerle el inhalador por lo que es posible que se encuentre con problemas debido a las gramineas.
#9 - Atención, aparece la primera sentencia GOTO
* Tim, te lo confieso; nunca pensé que vería un código así
Hay un punto a partir del cual, tienes que confiar en alguna caja negra, es lo que hay, no puedo forjar mi propio silicio
#2 Si que es cierto que cuanto más partes del proceso total tengas auditadas, más reduces la probabilidad de fallo.
#5 Para eso tienes los certificados de auditoria, yo monto algo sobre dos sistemas que tienen el sello de X, que a su vez se basan en dos sitemas que tienen el sello de X que a su vez se basan en tres sistemas que tienen el sello de X
Y ese puto sello tiene que ir a misa porque si no el castillo de naipes se cae, mira por ejemplo el engendro que estoy montando ahora interconecta 6 sistemas de su padre y de su madre que van desde contabilidad a ventas, tio pues yo en base a los interfaces y la especificacion aprobada que me dan me tengo que fiar que hacen lo que me dicen y como me lo dicen, no puedo auditar todo.
Luego si hay fallos pues si ya rastreo quien ha sido el cabron que me ha mentido
#8 Creo que evitar que un chip active una puta bolsa que te reventa en la cara y al mismo tiempo se asegure que detectores y detonadores estén en orden de funcionamiento esta varias ordenes sobre tu concepto de auditoria del soft encima que te entre en unos pocos K.XD
Creo que tenemos aquí un usuario se dedica a eso y podía aportar un poco mas yo solo me dedico reparar ultimamente esas mierdas.
#16 No, es exactamente lo mismo.
#16 Aquí hablan de software y el compilador, no de sensores y motores del mundo fisico, y aún así te diré pese a que lleve años sin tocar ese mundo yo técnicamente soy ingeniero industrial en robótica, y si, tu cuando montas un sistema en el mundo físico, el concepto es exactamente el mismo, me tengo que fiar del fabricante y sus especificaciones.
Si después hay errores pues se rastrea quien miente, pero tu no puedes reinventar la rueda, te tienes que basar en alguna caja negra (la cual ha sido auditada previamente, las especificaciones en segun que sistemas tienen categoría de documento legal)
#5 o no, igual te pasas de frenada y complicas innecesariamente todo.
#2 Eso da para programa de Mega: "Forjando mi silicio".
Sería delicioso ver a cuatro nerds, granudos y gafudos, dándole con un martillo de dos kilos a su oblea de silicio "de aquí me sale un transistor npn cojonudo..."
Luego Doug Marcaida diría: "este microprocesador... ¡mata!"
#6 Maldito, ese programa es droga de la buena
#23 C y forjado a fuego, la mejor noticia de menéame ever
#23 #6 pensaba que era el único que se pasaba horas viendo dar martillazos.
This knife, would KEEL
#94 Es porque mola ver que hay gente más friki que nosotros.
#6 https://www.microsiervos.com/archivo/hackers/semiconductores-artesanales.html
Y apunto que hay que ser muy pro.
#6 oye que tambien hay nerds que cuidamos nuestro aspecto físico. A ver si te piensas que somos todos como los de las pelis, algunos tenemos vida social y hacemos deporte.
#26 entonces eres un nerd renegao...
#37
#37 Será "renerdgao" !
#55 la puerta -->
#37 Creo q es un geek.
#26 Incluso tenemos pareja y escasez de granos, lo del deporte ya tal...
#40 porque tienes pareja.... Yo hago deporte además de por salud porque si no estás en forma lo tienes bastante más difícil para pillar cacho (o tienes que bajar el nivel)
#45 Está claro, no eres un "Nerd", solo te haces pasar por uno
#45 Como decían en el genial corto "La fiesta": si hay que bajar el listón, se baja. Si hay que tirarlo, se tira!
#45 "(o tienes que bajar el nivel)"
Esto dice mucho de ti
#80 ahhh claro que en las relaciones esporádicas sin compromiso lo que importa es la personalidad y no el físico, claaaaro.
#81 Por como hablas debes tener pocas, así que es como si yo te hablara de la cría del avestruz. Suerte con el ejercicio
#82 solo tengo que abrir el grindr
#6 eso, sigamos con el estereotipo de los nerds gafudos y granudos. Porque los funcionarios no trabajan, los taxistas son unos ladrones, los obreros unos paletos, los curas unos pederastas y los políticos unos puteros. Así nos va.
#2 El truco está en dejarlo bien planito con una espatula cuando se enfría.
#38 ¿Espátula? no me fio, yo uso un hueso de torax de muflón aplanado que labro yo mismo con dos piezas de sílex tras cazarlo a pedradas
#2 exacto! además en el caso de C la caja negra Está a tan bajo nivel que puedes incrustar blobs en ensamblador.
#2 ...todavía no. Pronto.
Llevo 20 años trabajando en el desarrollo de software y una de las pocas cosas -o la única- que siempre he tenido clara es la decisión de no trabajar en aplicaciones donde haya vidas en juego: hospitales, transportes, etc. Quiero poder dormir tranquilo sabiendo que mi peor error puede provocar una pérdida económica o de productividad. O que a una mala me podrían incluso despedir. Pero que la cosa nunca tendrá consecuencias más graves.
#12 Amen. Yo solo llevo 8 años, pero tal y como está el tema de cárnicas y demás paso de trabajar con aplicaciones críticas.
Cuando Indra, Everis, Accenture... fallen lo mismo que un compilador entonces igual si.
#12 Una pérdida económica conlleva despidos, vidas destrozadas en el alcohol y la drogradicción. Ale, ya puedes dar vueltas en la cama
#17 cuando trabajo bien, hago a mi empresa fuerte y competitiva, la competencia se resiente, y en algunos casos los manda a la bancarrota, familias enteras afectadas negativamente, depresión, suicidios, algunos caen en el lado oscuro criminal, hay homicidios, trata de blancas, narcotráfico, mafia, delincuencia organizada..... Y todo por hacer mi trabajo bien
#12 Pues sí, al final esos sistemas pasan cientos de pruebas, certificaciones y demás pero la probabilidad de un error que derive en un accidente mortal por muy baja que sea siempre existe y nunca va a ser 0.
#12 Pues yo prefiero que esté al cargo una persona como tú, a la que le quita el sueño ese tema e irá con cuidado, a que esos programas los haga alguien a quien le importe tres cojones el tema.
#12 Lo que se hace en esos casos es utilizar software matemáticamente verificado, hoy en día existen SMT solvers (Satisfability Modulo Theories) estáticos que en función de una especificación en la forma de precondiciones y postcondicones se demuestra y comprueba matemáticamente que el software va a comportarse exactamente así, por ejemplo el lenguaje Dafny.
Un ejemplo de lo que le paso al cohete Ariane - 5 , por utilizar software del anterior cohete que no estaba matemáticamente verificado, al parecer un número se salió de su representación...
Así es un bloque de código en dafny que calcula un factorial.
function fact (n:int):int
requires n >= 0
decreases n
method factorial (n:int) returns (f:int)
requires n >= 0
ensures f == fact(n)
{
var x := n;
f := 1;
while x > 0
invariant 0
Mejor una interfaz en visual basic para detectar la ip del hacker...
Me temo que el mensaje se perderá en el marasmo, pero por si alguien le interesa el tema, en la industria del automovil desarrollamos basándonos en la ISO 26262 (https://es.wikipedia.org/wiki/ISO_26262) y para ello están los niveles ASIL (https://en.wikipedia.org/wiki/Automotive_Safety_Integrity_Level)
Cualquier software que requiera algún nivel de ASIL en su ejecución ha de ser generado con herramientas cualificadas para ese nivel y correr sobre microcontroladores certificados para ello también. Y no sólo eso, se definen estrategias de verificación formal, de testeo, de review... todo conforme a la especificación. Yo siempre digo que ISO 26262 es la manera que las empresas tienen de salvarse legalmente en caso de accidente, pero lo cierto es que gracias a ello se desarrollan sistemas que son infinitamente más robustos, verificados y confiables. Casos como el de Toyota con el acelerador a día de hoy no son posibles si sigues la especificación. https://josemuelas.org/2017/07/09/por-que-la-justicia-necesita-software-libre-el-caso-toyota-camry/
Llevo dos anyos trabajando en ello gestionando el desarrollo de software FuSa (Functional Safety), si alguien quiere preguntar algo que pregunte.
#0 Te falta un punto y coma
Si tan crítico es que dependen de él vidas humanas el compilador no va a ser lo único que te preocupe, también influirá mucho el sistema operativo en donde se ejecute el programa, y eso ya puede hacer que el programa tenga que ser completamente diferente. Y además también afectará a cómo escribes el programa.
#7 El fallo siempre estará en un humano, el tema es averiguar cual, si el del procesador, el del so, el del compilador, el del programa o el que lo usa.
#15 Bueno Bueno.
https://en.wikipedia.org/wiki/Pentium_FDIV_bug
https://en.wikipedia.org/wiki/MOS_Technology_6502#Bugs_and_quirks
https://en.wikipedia.org/wiki/Pentium_F00F_bug
Y hay mas
#44 Claro, y esos procesadores los fabricó un Terminator, ¿no?
#44
#7 Está hablando de IoT, Arduinos y mandangas así. Ahí no hay sistema operativo, eres tú contra la máquina.
#7 Si es tan crítico, puede que uses ADA, o algún compilador de C ultrarestictivo.
Esto es como todo, ¿Confías en la calibración del robot que empaqueta los medicamentos?,¿la pureza de los mismos?.
Hay una cosa que me parece muy curiosa, y es cuando te ponen una vía, el plastiquillo ese para regular la velocidad de la administración intravenosa, es un plástico sencillo pero hay que confiar en él.
(En medicamentos donde la dosis es más precisa, se usa un aparato electronico, pero ... ¿puede fallar, no? como todo.
Si confio en los autobuses con alas de Ryanair porque no iba a confiar en un simple compilador?
Si tengo código crítico del que dependen vidas y no hay ninguna restricción que me impida no escribirlo en C, no voy a escribirlo en ese lenguaje.
Si tienes que hacerlo en C porque lo estás haciendo en algún microcontrolador que solo soporta C pues... toca santiguarse, porque meter bugs en cualquier código medianamente complejo en C es fácil de cojones.
There are also restrictions on how you can code a switch statement.
Switch statement = dejo de leer y le doy a decline en el code review
#36 Es fácil cometer errores en cualquier lenguaje y en C más aún, pero no se habla de eso sino de los fallos provocados por el propio compilador. Son errores que se dan bajo condiciones de programación poco habituales y que no se corrigen hasta una versión siguiente en la cual pueden aparecer errores diferentes.
Tenemos que pensar que hay fases de optimización en la generación de código que no son nada triviales.
Es evidente que los fallos provocados por un S.O. son incluso más numeroso. La cantidad de código que interviene es mucho mayor.
Yo imagino que para hacer un compilador seguro lo que buscaran es algo muy simple (menos potente y flexible) para que sea mucho más fácil validarlo.
#36 ¿Podrías desarrollar más ese último párrafo? Siento curiosidad.
#79 Aquí lo explican mejor de lo que podría hacerlo yo:
https://www.c-sharpcorner.com/article/switch-statement-a-code-smell/
En general, los switch statements están ahí casi siempre para cubrir malas prácticas.
Pero vamos, en C tienen como costumbre pasar errores con números negativos asociados a constantes. Cuando tienes que hacer guarradas de ese calibre, quedas lo suficientemente insensibilizado como para hacer un switch y no preocuparte.
#36 Nada más rápido y legible que un switch.
El hardware tiene microprogramacion y como tal tiene fallos.
LA BIOS/UEFI esta programada y tiene fallos.
El SO y drivers estan programados y tambien tienen fallos.
El compilador es un programa y como tal tiene fallos.
las librerias y framework que usuas estan programadas y tienen fallos.
Los sistemas o componentes externos que usas estan programados y tiene fallos.
Nosotros tenemos fallos.
Los usuarios tiene fallos.
las comunicacones tiene fallos.
Todo tiene fallos, todo! Lo que se intenta es minimizarlos en los usos mas comunes a un coste razonable segun el uso.
Aquí uno que trabaja justamente en eso. Pero para ello tenemos el ISO26262, testeo a diferentes niveles, software redundante, protección de memoria y ejecución en los sistemas operativos... Hoy en día el software es bastante seguro en ese sentido y tenemos mecanismos para garantizar que el coche no te mata.
#33 Otro que también ha trabajado en sistemas críticos. Es curioso como cambia la perspectiva del desarrollador cuando estás programando a nivel Kernel y se detecta un fallo en el hardware... Que por supuesto hay que tapar con software.
ante la incertidumbre, redundancia
#10 La idea es que no haya incertidumbre.
#49 no hay sistema 100% seguro ni fiable.
#57 El artículo se refiere a software crítico y se puede escribir software 100% fiable, otra cosa es la fiabilidad del hardware.
#60 pues habla con los del tuv. Y luego me cuentas.
#58 Haha, mucho más amor da el Brainfuck
¿En el compilador mas probado? que remedio.
Les compilador si. Del optimizador de código no. Osea gcc -O0
Según recuerdo el c no está permitido en sw crítico como centrales nucleares o torres de control aereo pq te permite hacer ciertas cosas
Realmente el auge de la computación cuántica se debe principalmente a que los particulares ya pueden hacer sus propios compiladores, chips, e incluso semiconductores, aunque todavía está al alcance de pocos. Para mantener el mercado, hace falta hardware más complejo, la "nube" está fallando, y la computación cuántica es la última esperanza de los fabricantes de hardware, aunque ¿por cuánto tiempo?
Relacionadas:
http://www.bimos.com/B/es-es/noticias/2741/como-planifico-una-sala-blanca-de-forma-eficiente
https://www.microsiervos.com/archivo/hackers/semiconductores-artesanales.html
#11 y los gamusinos como elemento central... imprescindibles para comprender la proliferación de la recurrencia especulativa en los procesos computacionales contemporaneos, y su consolidado mercado, evidentemente.
#18 si quieres usar gamusinos o hámsters para que giren las ruedas, tú mismo, yo te lo digo como profesional con seis años de experiencia en la computación de altas prestaciones. Cuando IBM ofrece computación cuántica a sus clientes, no es por una necesidad de los clientes de ese tipo de potencia de cómputo, sino una necesidad de IBM de ofrecer algo nuevo y diferente a sus clientes.
La calidad del software no esta definida x el compilador ni por los programadores. Esta definida x el testing que se haga. Si supera el test es confiable. O si no es que esta mal definido el test.
#31 O el antiguo pascal... Se dice que quien sabe pascal al 100% domina el UnixVerso (vale ya me voy)
#51 O Ada
El lenguaje que amo más de todos 
#56 Ni la mitad de amor que al Ook!
Qué recuerdos más bonitos.
Uno, Qt con Visual studio 2003, si hacia un if con j dentro de otro if con I, en una clase en específico, j siempre valía 0. Por muchos j++ que le metieras.
Dos, as2 bajo Flash nosequé versión, si le metía muchos "intros" el código de después de los saltos de línea no se ejecutaba, ignoraba esa línea.
Kotlin te quiere. Kotlin nunca te haría eso. Kotlin es tu amigo. Benditos checos.
Confiarías en tu procesador? Confiarías en tu memoria? En tu compilador? En tu recolector de basura?
Con lo feliz que era yo con mi ensamblador....
¿Y qué pasa si el verificador que verifica no está verificado?
C#minor - Cminor?
Qué clase de intercambio modal es ése?
C#m7b5
Yo lo que haría sería utilizar Ada o Rust (especialmente el segundo) junto con una batería de tests exhaustiva.
Rust es un lenguaje de sistemas (tipo C o C++) que es capaz de garantizar en tiempo de compilación que no vas a cometer un montón de bugs muy fáciles de cometer en otros lenguajes, incluyendo race conditions en multihilo, desreferenciar punteros nulos, buffer overflows y cosas por el estilo.
Utilizar C para software crítico es como confiar que un profesional del tiro con arco acierte el 100% de las veces en la diana. Y C++ ya ni digamos.
#84 Claro, porque nos conocemos de toda la vida.
Para empezar, lo que yo no haría sería elegir C
#43 Qué elegirías, por curiosidad?
#72 Seguro que dice Java...
#72 Creo que es más razonable usar Ada o C++.
Confío en mis tests
Yo de lo que no me fiaría es de alguien que ha escrito su propio compilador porque no se fía de los compiladores que llevan años y años en desarrollo y en los que han añadido su grano de arena los mayores expertos con diferencia.
Respuesta corta; no hay que reinventar la rueda.
#61 Vamos, que estás diciendo que el compilador bueno es gcc
https://en.wikipedia.org/wiki/Formal_verification#Software
No me fío de mi padre, que se jodió a mi madre, me voy a fiar de las porquerías que codifico.
Afortunadamente el que vale, vale y el que no a Banca, y en ese mundo no tengo que preocuparme por las mierdas que programo (ojo, para Banca pero no en Kobold, yo el Host ni lo huelo, pero si mierdecillas accesorias - aplicaciones web pestosas - que solicitan, y para las cuales los bancos no son nada exigentes).
Con tests automatizados y un equipo de testers/QA semi decente estaría más que tranquilo.
El lenguaje ideal para eso sería Java
Hay que decir que no se compila y ¡ale, a producción!
Incluso en las cárnicas se hacen pruebas.
Yo del Rivera no me fío ni un pelo
#1 Los que te votan negativo seguro que programan en COBOL
https://es.wikipedia.org/wiki/Kobold
#28 Por los dioses de Kobol!
#28
Yo de lo que no me fío, no es del compilador, sino de los programadores!...
Y no te metas con la Working-Storage Section, que no respondo!!!
Donde este el Cobol que se quiten las ñoñeces esas del C++, Java, etc... El Cobol es el lenguaje de los VERDADEROS hombres!!! Esos de peluche en sobaco y camachos hasta la cintura!