Hmm, it seems like you need to make sure the computer is on before calling this function, or else you run the risk of getting back undefined data. Seems like we also need a function that can be used to tell if the computer is on...
Nah. Just bump that responsibility to the caller, and power supply manufacturer. Have the caller call power_on_computer() first always. This will ensure you always get defined state!
...What do you mean not every power supply manufacturer implements the power_on_computer() function as a NOOP if the computer is already on?!
Some implement it that way, some it returns and error message or throws an NMI; then ya got the cheap clones that use it to frob a toggle without regard to the state it was in (which there's no way to read)... Then ya got the weird ones (HP) where it only works right if you call it twice with a 40ms delay between while streaming a sample from "Swan Lake" over their NDA'd 1wire thingy.
Seems like a reasonable compiler would inline the most likely implementation as 1. So, while technically undefined, it's safe to assume that it will 'return' 1 regardless of the actual on/off state of the computer.
{return 1;} is clearly a faulty implementation, it's entirely possible that the computer is already turned off by the time the function is executed using power stored in the decoupling capacitors of the CPU.
I would be unreasonable. The power state appears to me as highly asynchronous to program execution. I see no explicit guarantees on how the state is retrieved or synchronized, without synchronization the state wont be properly updated. We know that the computer was of at some point, so it starts of as undefined. Given undefined as starting state and the lack of update guarantee we can assume that it will always return an undefined value. This opens up a lot more optimization possibilities than assuming a 1.
When I first read the headline, I assumed this was some kind of query to the Intel Management Engine. But in this context, it's some good programming humor.
I like how it also has support for the ENIAC platform. I kicked my family out of the house so I had room to install the ENIAC. Happy to hear there's an OS I can run on it to get real work done, like posting unfunny jokes for strangers on Hacker News.
It upsets me that this function's interface allows it to describe silly things like "an ENIAC running on a 68000" or "an Apple II running on SPARC". Wouldn't be an issue if C++ supported GADTs.
I can find various results where that number is negative (Faltings height of LMFDB elliptic curve 1688.c1; north east longitude of el Baix Segura) but not where the number is positive. It's part of a DOI string though, but that's not really a number.
I know it's not as common anymore but if the computer is in a "hold and catch fire" incident it won't report temperature sensor readings. What happens? Is it considered off?
This assert doesn't work like you think it does. If the computer is off is_computer_on is undefined, so if this is called when the computer is already off it could return a nonzero value, thus resolving to true even though the computer is already off.
GP said for the 'non-true state', not the 'computer off state'. I.e. verify that the computer is off, given that the fn returns false (which is valid only as part of its undefined computer-off response).
It's obviously `IO Bool`, so it's equivalent to directly evaluating in an imperative language and you gain nothing from the monadic interface.
I'm sure some impurity "pragmatist" will try to argue you can make a perfectly good version of it as `Bool`. That kind of pragmatism is better ignored because it interferes with compiler optimization and standardization. As an example, you can look at the recent discussion around `==` and `/=`.
(And I just noticed some people may seriously argue that, so here comes the /s.)
There's an elegant FP solution that involves searching an infinite data structure using only a finite amount of computation -- actually, with precisely zero computation, because the machine isn't on.
Hum... Both P and NP are within the set of algorithms you can run when the computer is on. When it's off it's a different set, so it proves that OP=NOP (where O is for "off").
Please, can we make it `MonadIO m => m Bool` so that this can work with any IO-like monad and/or monad transformer stacks based off IO? It will also make unit testing much easier.
write a function whose sig is like "boolean isOn()". call it. if it returns true, the computer is on. if it returns false, the computer is also on. done. ship it!
add a // TODO in v2: handle case if it never returns, or the process crashes, or caller times out waiting
"On metal" would refer to running the OS without any additional layers like virtualization, in this context.
But it could also refer to the material "metal" (or the collection name for bunch of materials really), whereas computers are commonly known for being made with a lot of silicon instead of metal.
Hopefully I didn't dissect too much of the frog to kill it.
Asynchronous is definitely the way to go. I once tried synchronous code. Had to move it to a service worker so as to not bog down the UI, and you don't even want
to know what service workers do when the computer is off. Let's just say it's undocumented.
XP's behaviour is interesting in this case. It's one of the few things I actually like about Vista (sue me, I like things about Vista): Vista will abort the shutdown, but XP will hang for an unspecified length of time, when you have an event handler that makes a blocking call like `alert`.
// power cycle computer
bool was_on = set_computer_on(true); // returns prior value
if (was_on) {
set_computer_on(false);
set_computer_on(true);
} else {
// was previously off, is now on: nothing to do!
}
While it is clearly a joke, it has a legitimate use as a syscall that does nothing so can be used to test the syscall process itself [1]. (Its cousin `is_computer_on_fire` is not a syscall.)
Of course, one important trick here is that no matter how fast your system call is, not making a system call is just faster. io_uring is an example, as are futexes. So it's worth spending more effort on figuring out tricks to avoid doing the system call than exploiting tricks to shave a cycle or two off the time taken to execute one.
Completely depends on your use case. If you're checking if sys calls work, you'd only need to run one first and see if it succeeds. Then you can be reasonably sure you have access to the rest.
And different programs have different speed requirements.
Since the not-on result is 'undefined', a devilish implementer could return 1 for the off case, just to screw with people.
(How could this work in theory? Maybe the computer has a separate watchdog controller board which allows the computer to be turned on and off remotely, and that controller acts as a proxy for the API request.)
Only if the watchdog also has a CPU that can run programs when the "real" CPU is off. But then we'd need a is_watchdog_on() to know if that one is powered on, in the case where the wall plug has been pulled.
Maybe we can forbid the function from returning 1 in the off case. The existence of such a function means that "is this machine running?" is semidecidable - but it's surely not decidable by the machine itself.
196 comments
[ 3898 ms ] story [ 3725 ms ] threadShouldn't it just block until the computer turns back on? Probably interferes with pthreads.
...What do you mean not every power supply manufacturer implements the power_on_computer() function as a NOOP if the computer is already on?!
Edit: I see the downvotes, yet i still don't know if it's a joke. I was genuinely asking the question.
(And please stop calling me lazy.)
The question is worth asking (all are) but then soliciting "quantum computing" as an answer makes it a doubly worthy set up line, so thanks twice.
Interesting it seems to come from BeOS:
https://github.com/haiku/haiku/commit/bcf475ec65f1060c0a8abf...
where the same function had a hn thread about it already a couple years ago :D
https://news.ycombinator.com/item?id=8780606
Probably I'm being nerd sniped. https://xkcd.com/356/
I suppose it would.
So perhaps a biocomputer of sorts could be offline and return undefined behavior by spec. Guess we'll keep looking for that perfect OS code.
turn_computer_off();
Assert(!is_computer_on(), "Computer should have been off but it's on.");
The opposite is a bit tricky, though.
I'm sure some impurity "pragmatist" will try to argue you can make a perfectly good version of it as `Bool`. That kind of pragmatism is better ignored because it interferes with compiler optimization and standardization. As an example, you can look at the recent discussion around `==` and `/=`.
(And I just noticed some people may seriously argue that, so here comes the /s.)
It's like lazy evaluation, only more lazy.
So our security systems are (useless | perfect)!
I think there might even be other implications...
I think the following always holds: isUserAGoat==!isComputerOn, in other words the user is a goat if and only if the computer is off.
Given a lump of silicon, how does one programmatically tell if it is a computer?
add a // TODO in v2: handle case if it never returns, or the process crashes, or caller times out waiting
But it could also refer to the material "metal" (or the collection name for bunch of materials really), whereas computers are commonly known for being made with a lot of silicon instead of metal.
Hopefully I didn't dissect too much of the frog to kill it.
[1] https://github.com/haiku/haiku/commit/ccaac177f64038c160de6f...
Of course, one important trick here is that no matter how fast your system call is, not making a system call is just faster. io_uring is an example, as are futexes. So it's worth spending more effort on figuring out tricks to avoid doing the system call than exploiting tricks to shave a cycle or two off the time taken to execute one.
And different programs have different speed requirements.
Imagine putting a few of these in as a joke and then you take it out and your parallelized code doesn't work anymore.
Not sure how all that's handled on Haiku specifically.
(How could this work in theory? Maybe the computer has a separate watchdog controller board which allows the computer to be turned on and off remotely, and that controller acts as a proxy for the API request.)