9 ms·

> Not completing the operation at all, is not really any better than getting the wrong answer, it's only more debuggable. Wouldn't be that sure about that. Get

by tcfhgj 4y ago

> Not completing the operation at all, is not really any better than getting the wrong answer, it's only more debuggable. Wouldn't be that sure about that. Getting the wrong answer can be a serious security problem. Not completing the operation... well, it is not good, but that's it.

2OEH8eoCRo0 4y ago
True- which is why he says to throw a warning first.
atoav 4y ago
I mean if it is a cosmetic thing sure. If it has substantial meaning I would rather have that 5 ton robotic welding arm not move than have it move through my skill. It is sometimes acceptable to get wrong output. But is nearly always better to know it is wrong.
- deleted 4y ago
  [deleted]
- analognoise 4y ago
  This sounds like the difference between "fault tolerant" and "fail safe". Fault tolerant - you get a fault, you keep moving. Fail safe - you fail, and thus all operations are stopped.
  - gmueckl 4y ago
    Failing may require triggering some actions actively. Going inert is not the right way in many cases. Some system absolutely require best efforts in the face of failure. A fire alarm in an otherwise secure and locked down facility may have to trigger the opening of door locks, for example.
  - atoav 4y ago
    I mean the Rust appeal is actually that it foeces you to handle Errors. Whether you then fail or not is your decision. What Rust usually does not do is just fail. This is good for when the things you are using could error, e.g. when you use an arbitrary unicode string as a filename you might get an error because depending on the OS there might be characters that you cannot use as filenames that are valid unicode (or the other way around, possible filenames that are not valid unicode). In most programming languages this is something you need to know to catch it. In Rust this is an Error that you can or cannot handle. But you can't forget to deal with it.
- fritolaid 4y ago
  Unless it was holding a welding gun and stopped on one spot with the welding flame turned on instead of gracefully turning off the flame and backing away. Never used Rust before but is there a way to supply some default code to run in such a situation instead of just not carrying out the bad operation?
  - shepherdjerred 4y ago
    Yes, you can define your own panic handler in Rust. https://doc.rust-lang.org/nomicon/panic-handler.html https://doc.rust-lang.org/nomicon/panic-handler.html
atty 4y ago
The kernel can’t fail to complete its operations, because then the entire system crashes and no logs are created. Instead, you can finish the operation and check the result.
- charcircuit 4y ago
  panic doesn't instantly crash the program. It prints out debug information first. You could have kernel panics work the same way.
  - wtallis 4y ago
    Printing debug information to the kernel log then immediately triggering a kernel panic is not as useful as it sounds, because that approach will quite often result in that debugging information never reaching a display or any kind of persistent storage.
  - Someone1234 4y ago
    And when Linux is running on your fridge, in your car, or on a headless VM then who is there to read out this "printed output." The great thing about "log and continue" is you can automate collection and fix the underlying bug (or know that the hardware is failing). Keep in mind that in a kernel panic no hardware is assumed to work, so assumptions like "just write to storage!" isn't an assumption you can make, you're in a panic the IO could have been literally pulled out.
    - charcircuit 4y ago
      >Keep in mind that in a kernel panic no hardware is assumed to work So just change that assumption since for these edge cases that is an incorrect assumption.
  - secondcoming 4y ago
    Prints it out how? If the kernel has crashed how do you guarantee anything gets printed, either to the screen, tty, log file?
remram 4y ago
Not completing the operation is also a security issue, commonly called denial of service (DoS).
alerighi 4y ago
> Not completing the operation... well, it is not good, but that's it. Depends on what the operation is. If the operation is flying an airplane or controlling a nuclear reaction, you are sure that not completing the operation and just aborting the program is the worst outcome possible. Beside the error can crash the plane or melt down the nuclear reactor, but may also not have any effect at all, e.g. a buffer overflow overwrites a memory area that is not used for anything important. Of course these are extreme example (for which Linux is of course out of discussion since it doesn't offer the level of safety guaranteed required), but we can make other examples. One example could be your own PC. If you use Linux, take a look at the dmesg output and count the number of errors: there are probably a lot of them, for multiple reason. You surely want your system to continue running, and not panic on each of them!

by tcfhgj 4y ago

2OEH8eoCRo0 4y ago

True- which is why he says to throw a warning first.

atoav 4y ago

I mean if it is a cosmetic thing sure. If it has substantial meaning I would rather have that 5 ton robotic welding arm not move than have it move through my skill. It is sometimes acceptable to get wrong output. But is nearly always better to know it is wrong.

deleted 4y ago
[deleted]
analognoise 4y ago
This sounds like the difference between "fault tolerant" and "fail safe". Fault tolerant - you get a fault, you keep moving. Fail safe - you fail, and thus all operations are stopped.
- gmueckl 4y ago
  Failing may require triggering some actions actively. Going inert is not the right way in many cases. Some system absolutely require best efforts in the face of failure. A fire alarm in an otherwise secure and locked down facility may have to trigger the opening of door locks, for example.
- atoav 4y ago
  I mean the Rust appeal is actually that it foeces you to handle Errors. Whether you then fail or not is your decision. What Rust usually does not do is just fail. This is good for when the things you are using could error, e.g. when you use an arbitrary unicode string as a filename you might get an error because depending on the OS there might be characters that you cannot use as filenames that are valid unicode (or the other way around, possible filenames that are not valid unicode). In most programming languages this is something you need to know to catch it. In Rust this is an Error that you can or cannot handle. But you can't forget to deal with it.
fritolaid 4y ago
Unless it was holding a welding gun and stopped on one spot with the welding flame turned on instead of gracefully turning off the flame and backing away. Never used Rust before but is there a way to supply some default code to run in such a situation instead of just not carrying out the bad operation?
- shepherdjerred 4y ago
  Yes, you can define your own panic handler in Rust. https://doc.rust-lang.org/nomicon/panic-handler.html https://doc.rust-lang.org/nomicon/panic-handler.html

atty 4y ago

The kernel can’t fail to complete its operations, because then the entire system crashes and no logs are created. Instead, you can finish the operation and check the result.

charcircuit 4y ago
panic doesn't instantly crash the program. It prints out debug information first. You could have kernel panics work the same way.
- wtallis 4y ago
  Printing debug information to the kernel log then immediately triggering a kernel panic is not as useful as it sounds, because that approach will quite often result in that debugging information never reaching a display or any kind of persistent storage.
- Someone1234 4y ago
  And when Linux is running on your fridge, in your car, or on a headless VM then who is there to read out this "printed output." The great thing about "log and continue" is you can automate collection and fix the underlying bug (or know that the hardware is failing). Keep in mind that in a kernel panic no hardware is assumed to work, so assumptions like "just write to storage!" isn't an assumption you can make, you're in a panic the IO could have been literally pulled out.
  - charcircuit 4y ago
    >Keep in mind that in a kernel panic no hardware is assumed to work So just change that assumption since for these edge cases that is an incorrect assumption.
- secondcoming 4y ago
  Prints it out how? If the kernel has crashed how do you guarantee anything gets printed, either to the screen, tty, log file?

remram 4y ago

Not completing the operation is also a security issue, commonly called denial of service (DoS).

alerighi 4y ago

> Not completing the operation... well, it is not good, but that's it. Depends on what the operation is. If the operation is flying an airplane or controlling a nuclear reaction, you are sure that not completing the operation and just aborting the program is the worst outcome possible. Beside the error can crash the plane or melt down the nuclear reactor, but may also not have any effect at all, e.g. a buffer overflow overwrites a memory area that is not used for anything important. Of course these are extreme example (for which Linux is of course out of discussion since it doesn't offer the level of safety guaranteed required), but we can make other examples. One example could be your own PC. If you use Linux, take a look at the dmesg output and count the number of errors: there are probably a lot of them, for multiple reason. You surely want your system to continue running, and not panic on each of them!