3 ms·

SW coming to HW saying "your ALU is broken because it's rounding incorrectly" or "we need feature X to speed up our real-time calculations" I get. SW coming to

by dewster 10y ago

SW coming to HW saying "your ALU is broken because it's rounding incorrectly" or "we need feature X to speed up our real-time calculations" I get. SW coming to HW saying "we need feature Y because our own SW process is so completely screwed up and out of control it takes an Einstein to do it right" I don't get.

nickpsecurity 10y ago
My background is high assurance. I know most of systems designed to be nearly flawless. Best minds, processes, and tooling still left occasional flaws. So how do you expect average, time-constrained, tool-constrained programmers to do better on inherently unsafe machines? And why do you promote unsafe machines in first place if safe alternatives have almist no overhead plus match language better? Not making much sense. Part of this process you talk about is selecting tools that make job easier. Applies to CPU's as well as anything else. My research is taking it all the way down to how gates or analog circuits are done to max availability or integrity. Burroughs plus NonStop with correct by construction synthesis basically.
- dewster 10y ago
  HW/SW co-design is supposed to go like this: Never do anything in HW if you can do it in SW. Because HW is expensive and dangerously set in stone. Because SW can be as complex as it needs to be and can be easily fixed / updated later. If you can't do it in a timely manner in SW, add the minimum safest HW to enable things. That's it. Except for cosmic rays flipping bits, well designed processors aren't inherently unsafe. People and the software they write are unsafe (guns don't kill people...). Why put any SW onus on HW where it will almost always be more expensive and less flexible?
  - nickpsecurity 10y ago
    You're still ignoring the other tradeoff of safety where you use any cost-effective technique at any layer to meet your goals. Intel's blown millions of gates on stuff tgey dont need plus bad ideas for safety. The stuff Im mentioning is in thousands. I imagine it's cheaper, faster, and easier to change than what vendors already add. Besides, empirical evidence is strongly against your statements about people's competence or bad analogies to guns. Empirical evidence, even for OpenBSD or Bernstein, show the best coders can't consistently make software work on tooling and architectures you seem to prefer. Whereas, average people using Rust and/or Java CPU's are producing software faster with few to no exploitable defects. And both can be targeted to under 10,000 gates (ARM is 30k+).

by dewster 10y ago

nickpsecurity 10y ago

My background is high assurance. I know most of systems designed to be nearly flawless. Best minds, processes, and tooling still left occasional flaws. So how do you expect average, time-constrained, tool-constrained programmers to do better on inherently unsafe machines? And why do you promote unsafe machines in first place if safe alternatives have almist no overhead plus match language better? Not making much sense. Part of this process you talk about is selecting tools that make job easier. Applies to CPU's as well as anything else. My research is taking it all the way down to how gates or analog circuits are done to max availability or integrity. Burroughs plus NonStop with correct by construction synthesis basically.

dewster 10y ago
HW/SW co-design is supposed to go like this: Never do anything in HW if you can do it in SW. Because HW is expensive and dangerously set in stone. Because SW can be as complex as it needs to be and can be easily fixed / updated later. If you can't do it in a timely manner in SW, add the minimum safest HW to enable things. That's it. Except for cosmic rays flipping bits, well designed processors aren't inherently unsafe. People and the software they write are unsafe (guns don't kill people...). Why put any SW onus on HW where it will almost always be more expensive and less flexible?
- nickpsecurity 10y ago
  You're still ignoring the other tradeoff of safety where you use any cost-effective technique at any layer to meet your goals. Intel's blown millions of gates on stuff tgey dont need plus bad ideas for safety. The stuff Im mentioning is in thousands. I imagine it's cheaper, faster, and easier to change than what vendors already add. Besides, empirical evidence is strongly against your statements about people's competence or bad analogies to guns. Empirical evidence, even for OpenBSD or Bernstein, show the best coders can't consistently make software work on tooling and architectures you seem to prefer. Whereas, average people using Rust and/or Java CPU's are producing software faster with few to no exploitable defects. And both can be targeted to under 10,000 gates (ARM is 30k+).