@GromBeestje @nixCraft It's critically important to run this in a separate process to HCF()!
@GromBeestje @nixCraft This should also cover the temperature inside a supernova, so we are safe on that side ;)
🆁
🅷🅽 ツ @GromBeestje @nixCraft "some other value" what is freezing ?
@Brahn @GromBeestje @nixCraft This calls for a get_calamity_type() method.
@GromBeestje @nixCraft wish I’d had access to this before I had to read a whole book to find out https://mitpress.mit.edu/9780262539739/your-computer-is-on-fire/
(D.Burch) 
@catsalad@infosec.exchange @GromBeestje@mastodon.social @nixCraft@mastodon.social damn that CPU's touching grass... unlike me
@GromBeestje @nixCraft reminds me of the old "lp0 on fire" error in some older Unixes
@peter, it's still there in (at least) current Linux.
On a status check, “lp0 on fire” (for appropriate values of 0) may be logged; on opening the device file, “lp0 printer error” will be logged instead given the same error condition. It's specific to an error condition reported via the 8255 status port.
This is a true masterwork of wrongness.
Okay, I just googled it and it's real. I don't know whether to be delighted or horrified.
Also (and sorry for the monologuing), I once witnessed a demo of the original dual-processor BeBox where the presenter showed how to turn off one or the other of the cores from the settings interface. He then turned off both of the cores, and it did exactly what you'd expect. While the computer rebooted, he segued on to how robust the filesystem was.
So, on reflection, this seems pretty on-brand for them.
@suetanvil @GromBeestje @nixCraft I was kind of sad when I was told that they later on removed that feature from BeOS
@suetanvil @nixCraft I recall reading these function were there to test the performance of userland-kernel calls.
That makes sense. My idle speculation was that they were there as the entry points to the hardware or kernel equivalents of debugging printfs, FWIW.