▲ 310 ▼ Report: White House delaying release of voting machine security study (www.reuters.com) submitted 1 month ago* (last edited 1 month ago) by sanitation@lemmy.today to c/technology@lemmy.world 46 comments fedilink hide all child comments
[–] SkaveRat@discuss.tchncs.de 60 points 1 month ago (1 child) as xkcd put it: permalink fedilink source parent hideshow 2 child comments replies: [–] 4am@lemmy.zip 27 points 1 month ago (2 children) I actually don’t like this XKCD, this is a bad answer to why electronic voting is bad. Mostly because it is a largely obtuse process that most people can’t see or understand. “Trust the magic rock is counting fairly and that bad people who would want to manipulate it in order to obtain power and conquer you haven’t had a chance to do so.” You cannot code your way out of that. Everyone understands marks on paper. No one understands buffer overrun RCE, resistive touchscreen calibration, or database triggers and log sharding. permalink fedilink source parent hideshow 4 child comments replies: [–] thebestaquaman@lemmy.world 25 points 1 month ago (1 child) While I see what you're getting at, I still like this XKCD. I work as a developer, and have also worked in more "handy" fields. The thing with planes, elevators, and basically all other physical things is that they're limited by physics. A steel beam can't suddenly decide to spontaneously fail or disappear. With code, that can feel pretty different. With experience, I've basically learned to assume that there is always some edge-case I haven't considered, that could trigger a bug. In a building, you can have redundant bolts, and over-dimensioned supports. A small mistake somewhere, a single missing bolt, won't cause a catastrophic failure. With code, it's different: A tiny, hard to notice mistake, can bring the whole think crashing down. Imagine if a plane could crash because the paint had a slightly non-uniform thickness... permalink fedilink source parent hideshow 2 child comments replies: [–] Venator@lemmy.nz 7 points 1 month ago* (1 child) A good example of software failing where traditional systems were more reliable is when Boeing tried to rely on it with MCAS on the 737 max permalink fedilink source parent hideshow 2 child comments replies: [–] thebestaquaman@lemmy.world 3 points 1 month ago* This is exactly the kind of thing I'm talking about. You can confirm the structural integrity of the wings with a rather simple visual inspection. Same goes for the windows and landing gear. Try confirming the integrity of (tens- or hundreds of) thousands of lines of code with a similar kind of inspection... permalink fedilink source parent [–] stringere@sh.itjust.works 3 points 1 month ago log sharding I understand log sharting! permalink fedilink source parent
[–] 4am@lemmy.zip 27 points 1 month ago (2 children) I actually don’t like this XKCD, this is a bad answer to why electronic voting is bad. Mostly because it is a largely obtuse process that most people can’t see or understand. “Trust the magic rock is counting fairly and that bad people who would want to manipulate it in order to obtain power and conquer you haven’t had a chance to do so.” You cannot code your way out of that. Everyone understands marks on paper. No one understands buffer overrun RCE, resistive touchscreen calibration, or database triggers and log sharding. permalink fedilink source parent hideshow 4 child comments replies: [–] thebestaquaman@lemmy.world 25 points 1 month ago (1 child) While I see what you're getting at, I still like this XKCD. I work as a developer, and have also worked in more "handy" fields. The thing with planes, elevators, and basically all other physical things is that they're limited by physics. A steel beam can't suddenly decide to spontaneously fail or disappear. With code, that can feel pretty different. With experience, I've basically learned to assume that there is always some edge-case I haven't considered, that could trigger a bug. In a building, you can have redundant bolts, and over-dimensioned supports. A small mistake somewhere, a single missing bolt, won't cause a catastrophic failure. With code, it's different: A tiny, hard to notice mistake, can bring the whole think crashing down. Imagine if a plane could crash because the paint had a slightly non-uniform thickness... permalink fedilink source parent hideshow 2 child comments replies: [–] Venator@lemmy.nz 7 points 1 month ago* (1 child) A good example of software failing where traditional systems were more reliable is when Boeing tried to rely on it with MCAS on the 737 max permalink fedilink source parent hideshow 2 child comments replies: [–] thebestaquaman@lemmy.world 3 points 1 month ago* This is exactly the kind of thing I'm talking about. You can confirm the structural integrity of the wings with a rather simple visual inspection. Same goes for the windows and landing gear. Try confirming the integrity of (tens- or hundreds of) thousands of lines of code with a similar kind of inspection... permalink fedilink source parent [–] stringere@sh.itjust.works 3 points 1 month ago log sharding I understand log sharting! permalink fedilink source parent
[–] thebestaquaman@lemmy.world 25 points 1 month ago (1 child) While I see what you're getting at, I still like this XKCD. I work as a developer, and have also worked in more "handy" fields. The thing with planes, elevators, and basically all other physical things is that they're limited by physics. A steel beam can't suddenly decide to spontaneously fail or disappear. With code, that can feel pretty different. With experience, I've basically learned to assume that there is always some edge-case I haven't considered, that could trigger a bug. In a building, you can have redundant bolts, and over-dimensioned supports. A small mistake somewhere, a single missing bolt, won't cause a catastrophic failure. With code, it's different: A tiny, hard to notice mistake, can bring the whole think crashing down. Imagine if a plane could crash because the paint had a slightly non-uniform thickness... permalink fedilink source parent hideshow 2 child comments replies: [–] Venator@lemmy.nz 7 points 1 month ago* (1 child) A good example of software failing where traditional systems were more reliable is when Boeing tried to rely on it with MCAS on the 737 max permalink fedilink source parent hideshow 2 child comments replies: [–] thebestaquaman@lemmy.world 3 points 1 month ago* This is exactly the kind of thing I'm talking about. You can confirm the structural integrity of the wings with a rather simple visual inspection. Same goes for the windows and landing gear. Try confirming the integrity of (tens- or hundreds of) thousands of lines of code with a similar kind of inspection... permalink fedilink source parent
[–] Venator@lemmy.nz 7 points 1 month ago* (1 child) A good example of software failing where traditional systems were more reliable is when Boeing tried to rely on it with MCAS on the 737 max permalink fedilink source parent hideshow 2 child comments replies: [–] thebestaquaman@lemmy.world 3 points 1 month ago* This is exactly the kind of thing I'm talking about. You can confirm the structural integrity of the wings with a rather simple visual inspection. Same goes for the windows and landing gear. Try confirming the integrity of (tens- or hundreds of) thousands of lines of code with a similar kind of inspection... permalink fedilink source parent
[–] thebestaquaman@lemmy.world 3 points 1 month ago* This is exactly the kind of thing I'm talking about. You can confirm the structural integrity of the wings with a rather simple visual inspection. Same goes for the windows and landing gear. Try confirming the integrity of (tens- or hundreds of) thousands of lines of code with a similar kind of inspection... permalink fedilink source parent
[–] stringere@sh.itjust.works 3 points 1 month ago log sharding I understand log sharting! permalink fedilink source parent