While this is a joke, there are some contexts in which it does make sense to ask whether the computer is on. For instance, most laptops have an embedded controller which runs all the time, even when the laptop is powered off, and manages things like battery charging and the power state. Within that embedded controller, an is_computer_on() function could legitimately return "false".
I've often wondered why WOL is so poorly designed. WOL should be a function of the NIC, completely independent of the OS and capable of returning status codes even if the computer is "off".
I think the parent means that you should be able to talk to the NIC about the computer, without the NIC needing to get the CPU powered on so that the CPU can tell the NIC what to do. Like a very-minimally-functional BMC.
As far as I'm concerned ME-equipped NICs should unconditionally be behind VPNs, but the AMT functionality itself is really cool. Even the 10+ year old machines that don't support VNC let you remotely hit CTRL+ALT+DEL, issue an ACPI shutdown, perform a hard reset (equivalent to hitting the reset button on 486-era boxen), etc. So basically you can do either soft or hard shutdowns or reboots. Quite granular.
I actually used the hard-reset functionality while playing around with Linux early boot on a laptop a few years ago. Rebuild initramfs (loaded via PXE), use `curl` to hit AMT reset endpoint. Very cool.
You can embed a minimal ssh server (like dropbear or tinyssh) in your initramfs to remotely enter the passphrase. There are some guides for that online
If you can fiddle around and get the VNC functionality working, then as long as you have it behind a bastion host you basically have insta-BMC.
I kneejerk-recommend a bastion host because a) Intel ME, and b) there was that all-0 password bypass a while back and uhhh yeah who knows what other "sneeze correctly and the leaf falls over" knock sequences there are.
SSH port forwarding, VPN, RPi running the remote-access AMT web UI thingy (runs on Linux, forget what it's called) behind nginx with authentication... you get the idea.
You could use a Mainboard with an IPMI module and KVM-over-LAN functionality. This way your are able to do everything remote, including mounting isos to install a new system and ofc you could use it to enter your password for the encrypted partition.
Now I'm almost curious if every PCI slot has a pin equivalent to the power button pin on the mainboard and also feed some basic background power to the cards even when turnt off. I doubt it actually is this simple though, the industry rarely chooses KISS.
The main difference is that WAKE# signal only restores power to the system but it does not change the system's power state, after using it the card needs to send an interrupt to the motherboard to properly wake it up. Power button does both things.
there is a WAKE# pin on the PCIe slot so any card should be able to wake the system from sleep (S3).
however, an ATX PSU supplies only 5V (5Vsb) when the system is off (S5) which is not available on the PCIe connector which only has 12V and 3.3V. so when the system is off (S5), the PCIe cards are unpowered and thus cannot turn the system on.
but if you mean off in the Microsoft "Modern Standby" (S0i) then yes, the PCIe cards are powered and the WAKE# pin can "turn on" the system.
For the sake of the argument, I think it's more of a shared capability of the motherboard _and_ the NIC, rather than the sole responsibility of the NIC.
I wonder if that could be implemented solely by the motherboard. After all, it could supply a small amount of power to the NIC while shutdown and embed a minimal NIC driver to monitor incoming packets without the need for the NIC to do the monitoring itself.
Because currently you need support of WoL from both your NIC (to enter low power WoL monitoring mode) and your motherboard (to listen for WoL events from the NIC and trigger power on).
If the motherboard would embed a simplistic NIC/WoL driver then you could have WoL on any NIC, with the motherboard acting like any client. I suppose that would mean using the PCI lane and stuff to communicate with the NIC though which may defeat the purpose of a dedicated low power interface.
Yeah, would make sense in that case. Probably would name the function differently though, to indicate the difference. "is_computer_on" makes me think it's checking the state of the computer this code is running on, not the state of another computer than "myself".
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.
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.
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.
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.
{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.
How does this relate to computer being in Halt state, which is quite valid state for servers (there could be even a dedicated Halt button)? Technically computer hardware is ON. I remember that in such state it shows a "carrot" prompt (>>>) from the SRE console.
By the way, there is also HCF instruction (Halt and Catch Fire).
> By the way, there is also HCF instruction (Halt and Catch Fire).
I was somewhat recently scarred for life by this instruction, having just discovered that if you execute HCF on the MIPS-based integrated circuits in Stationeers, the simulated IC... explodes in your face.
I admire for how you nerdsniped several other comments without anyone noticing the platform, or how "halt" would drop you into console monitor on said platform. My standing ovation to you :D
(The platform is Alpha, right? Given the prompt and name for the console, though it was SRM, not SRE) :)
Funny thing, for some historic reason, the system terminal attached to cabinet with those memorable Alpha Servers was of the monochrome lineage, but the phosphors color was orange. So the >>> prompt was unmistakably a carrot one! However it would rarely be seen, as bulk of the time the console would busily beep and boop with operator messages, as any respectful Alphas would be on 24/7/365 duty.
The only forced interruption I witnessed was when the attached storage controller froze. Literally. Someone left a window open in the server room, with -20C outdoors. So with all that circulation there was ICE accumulation on one side of storage controler cabinet. Apparently that put it beyond service temp range. Well, thawed it out - back to bizznizz, so to speak.
It that case, should've been is_system_iced() system call, it could've saved us the trip on such a freezing night. We would've just called HCF... briefly :)
Orange, or more specifically Amber, was one of the popular options for monochromatic terminals from Digital and not only. Personally I had an amber VT510 attached to my AS255/233, and that one was essentially a budget model (effectively a slightly upgraded VT220 with PS/2 keyboard) and was apparently common choice for system console with Alphas. Unfortunately from what I heard default text mode on colour displays when using them instead of serial console was apparently white-on-blue (familiar from winnt BSOD among other things).
Interestingly enough, there are few systems in Alpha lineage that have what's known as "external console", meaning that instead of running SRM on the normal CPUs, they had separate frontend processor and main cpus only had shims to communicate with it. Marvel was one of those, but apparently there were older ones as well.
Also, if you had partition-capable Alpha, the carrot prompt would be made into Pxx> where xx referred to currently selected cpu. With VMS, you could then boot into "VMS Galaxy" mode where you had multiple VMS systems running without hypervisor, just with all of them carefully avoiding stepping on each others' resources.
If the function call doesn't allow you to specify a CPU core, then it seems like it would be testing either the logical or'ing of all core's powered-on state, or the state of the current core.
In order for the code to execute anywhere, at least one core must be powered on and not halted. Also, I would consider a halted CPU to still be powered on.
Otherwise, the function's name has no relation to it's behavior and it's a buggy function on top of being a useless but amusing thought experiment.
That was one of the interesting things about BeOS - that you could turn off CPUs while it was running via the desktop. Just make sure to leave one running.
Yeah, but what should happen to the values that would’ve been sent while the computer was asleep, but couldn’t be. Should they be resent as soon as possible after computer wakes up, or dropped? (It probably depends on the exact API and its needs.)
When you convert float->hex->int->unix time, you get Sun Jul 27 2003 01:33:50 GMT+0000, which kind or corresponds to when the function might gave been implemented in Haiku. But if it matches BeOS R5, then the number may have another significance.
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!
}
This is actually a good example to explain the concept of undecidability in computation theory. If you get a True you know for sure that the computer is on. If you don't get anything immediately, it may be that the computer is on but really slow to answer or it may be off and never going to answer. But you'll never be sure, thus its state is undecidable in this case.
This reminds me of the time when I had a TV attached to my computer through HDMI and I wanted to write a program that checked whether it was on or off. It turned out to be impossible, because even when it was turned off, it still appeared as connected on Windows because it was technically on stand by.
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.
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.
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.)
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.
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.
I was working on an embedded system. I told the hardware guy that the CPU clock input wasn't running. He said, "Any reasonably intelligent software should have detected that condition and handled it." I replied, "Seems to me the software acted appropriately for the conditions."
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).
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.
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
I have recently wondered if there is a way to guarantee that a processor is idling. By this I mean, is there a way to ensure another computer has been idle for a time when it promises that it has been. Kind of the opposite of a crypto mining problem.
What's so amusing today is that "off" tends to be an illusion today. It's more like "sleeping". There's still some stuff running. Listening for the On button, Wake on LAN, timers, the system management engine...
I was hoping this would be implemented by actually reading a memory location that was set to 0, when the system is hibernating/sleeping. But it always returns 1. If it was reading a flag from memory it would be useful when examining memory dumps.
"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.
Why would is_computer_on_fire() return a double and not true/false? Even for a joke function, this seems like bad practice. If the function is named is_state(), I expect a boolean return.
> Returns the temperature of the motherboard if the computer is currently on fire. Smoldering doesn't count. If the computer isn't on fire, the function returns some other value.
These functions are useless since there's no way to know if the function "fails." If the computer is on it returns 1, but if it's off it can also return 1. So if it returns a 1 you don't actually know if it's on (unless you happen to know from somewhere else that the computer is on which at that point why bother calling this function)
Really have to object to manuals of this kind - the B_INFINITE_TIMEOUT() function - see the miscellaneous functions link at the top of the page - seems to have been adopted by too many automated call centres.
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?
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.
Ah yes, the annoying Windows message "Do not turn off your computer" when it is running updates. Why is it telling me what to do with another computer? And I can turn it off since it isn't mine?
> but also something related to our beloved OS, and with a little humour to top it off, so after a brainstorming session we came up with Is Computer On, or ICO (cute uh?) for short. The developers out there (and many others) will most certainly recognize the is_computer_on() function, a very important one in our day to day computer usage :)
