How to programmatically find out if computer is on | Hacker News Reader

How to programmatically find out if computer is on

haiku-os.org

405 pointsmarcodiego187 comments

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".

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'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".

Is... this not how your WoL works? Hitting the NIC is equivalent to pressing the on button, boots the OS, etc.

I've been using this for years to wake hosts at home when I'm abroad. It's invaluable.

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.

Intel vPro?

That's AMT, provided by Intel ME.

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.

Can it enter the password required to decrypt my LUKS partition?

Lately this has been my biggest barrier to leaving a computer fully remote.

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.

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

Yes, this works. I have it set up for some servers that have encrypted hard drives.

Store the LUKS crypto key in the TPM, and make sure secure boot is used so the TPM will only reveal the key if the systems boot chain is verified.

Nope. That's dangerous, TPM keys can be sniffed on the bus: https://trmm.net/tpm-sniffing/

Is a LUKS key being sent remotely to Intel ME _not_ vulnerable to being sniffed on the LAN?

You don't need to involve ME into remote decrypting. Embed the LUKS binaries and dropbear into your initramfs, and off you go.

look into tang and clevis.

I have followed this guide: https://blog.buettner.xyz/luks-verschlusseltes-ubuntu-20-04-...

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.

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.

I am not sure how this would meaningfully differ from the current state of affairs, where the NIC runs in a low power mode while the PC is off.

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.

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.

In PCI Express slot there is indeed a standby power (+3.3 V) pin and WAKE# signal pin, but it works differently than the power button.

https://en.wikipedia.org/wiki/PCI_Express#Pinout

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.

There is a pin that provides access to the 3.3v standby bus, and a wake pin that can be used to wake the CPU.

Could you apply the same reasoning to 'double is_computer_on_fire()'?

Sure. Every Dell server's iDRAC and every Oracle's ILOM has this functionality.

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.

An Apple II style of computer built around a SPARC would be a fascinating hobbyist platform.

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.)

[1] https://github.com/haiku/haiku/commit/ccaac177f64038c160de6f...

Sure.

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.

I suppose not checking whether syscalls work would indeed be faster than checking whether they work...

I was thinking the same thing, although in reverse:

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.

https://xkcd.com/1172/

is_computer_on_fire goes all the way back to the early days of BeOS IIRC. I'm sure full backwards compatibility has been _very_ carefully considered.

Why isn’t is_computer_on_fire a syscall? That’s fascinating that two joke functions differ so dramatically.

> If the computer isn't on, the value returned by this function is undefined.

Shouldn't it just block until the computer turns back on? Probably interferes with pthreads.

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.

I know that at least Solaris implemented SIGPWR signal to inform programs of a power failure: https://community.bmc.com/s/article/Inquira-KA334556

TIL: linux also implements SIGPWR. Using "kill -PWR `pidof dd`" killed it with "power failure".

There's a syscall to check whether the computer is on so just call that before this and you'll be fine

That introduces a time-of-check to time-of-use bug (https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use).

Ah, good ole TOCTOU

Aha. If only the API was "Execute a user-provided function in a context where the computer is guaranteed to be on".

You need to halt this thinking at once

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 agree on the implementation, but I'm pretty sure if the computer is off you aren't getting 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.

Since the behavior is undefined when the computer is off this implementation seems correct in your hypothetical as well.

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.

> is_computer_on()

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).

https://en.wikipedia.org/wiki/Halt_and_Catch_Fire_(computing...

Wouldn't a CPU halt state mean no code is running?

a computer has multiple CPUs. One may be halted while another still running.

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.

which implies that the power state of the whole core cluster is on, so the syscall is defined to return 1

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.

A CPU can halt as a power saving measure, and still respond to interrupts.

> 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.

Works as advertised. ;-)

I’ve wondered what Go APIs involving channels should do when the computer is put to sleep and later on wakes up.

Maybe I haven't done enough Go to know why that's something to wonder about? They wouldn't just carry on when resumed like anything else?

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.)

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) :)

SRM it is. Thanks!

(Alpha) System Reference Manual:

https://en.wikipedia.org/wiki/System_Reference_Manual

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.

I'm curious if there's any significance in number 0.63739 in this implementation

    double
    is_computer_on_fire(void)
    {
        return 0.63739;
    }

https://github.com/haiku/haiku/blob/8f16317a5b6db5c672f33181...

Doesn’t seem to be a date or notable postal code

My first thought is that it looked close to 1-e^-1, but that doesn't seem to be it.

Closest I came was sqrt(3)/e = 0.637185

I want to build a computer than can run in supercooled conditions, to prove that implementation has a bug.

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.

Dunno. Referencing a US telephone keypad, it spells NERDY.

Asynchronous JavaScript browser DOM callback API:

    <html
      onon="alert('Computer turned on!')"
      onoff="alert('Computer turned off!')"
    >

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`.

Paraphrasing Descartes. "I think, therefore I am on".

Humans think even if they are off, for some definition of a human being off ;)

Sometimes I sit and think; sometimes I just sit.

Although many people are laughing, I believe the function works ok. The only complicated part is to find a way to call it when the computer is not on.

If you take the memory unit, and attach it to another computer, does >interpreting< the code count as running the software on the new computer?

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.

Easy peasy, just call it from a different computer.

In Soviet Russia the computer checks you to see if you are on.

   // 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!
   }

Have you tried turning it off and on again?

This reminds me of http://www.hasthelargehadroncolliderdestroyedtheworldyet.com...

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.

Really it is a matter of opinion -- you and the TV just disagreed about the definition of "on" I guess.

"Returns 1 if the computer is on. If the computer isn't on, the value returned by this function is undefined."

Better description would be:

Returns 1 if the computer is on. If the computer isn't on, the value returned by this function is not computable.

Functional programming with monads is the right way to implement this.

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.

It's like lazy evaluation, only more lazy.

Wait. When the machine isn't on, P=NP!

So our security systems are (useless | perfect)!

I think there might even be other implications...

Nice job - having shown that P is the same as NP factorial will allow us to solve a lot of really hard problems!

Golf clap.

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").

A sideeffect free api to turn on the computer in haskell would be brilliant.

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.

Descartes for the digital age:

"I compute, therefore I am on"

See also isUserAMonkey and isUserAGoat.

I think the following always holds: isUserAGoat==!isComputerOn, in other words the user is a goat if and only if the computer is off.

For some it is a joke, for others it just reminds them of what the codebase looks like after the juniors have been peer reviewing each other...

Reminds me of 'onstat' in Brendan Gregg's special tools: https://www.brendangregg.com/specials.html

Where does the code run when the computer is off?

Edit: I see the downvotes, yet i still don't know if it's a joke. I was genuinely asking the question.

thatsthejoke.jpg

that's the joke

must be serverless

It looks like you haven't heard of quantum computing

The computer is only on or off when you measure it.

I propose to optimize it so that it's off all the time. And switches on and does something only when measured.

(And please stop calling me lazy.)

In the cloud

Embedded controller, management engine, low-power core.

Genuine answer: the code cant run when the computer is off, thus the joke.

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.

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.

Both thanks and not thanks you mean

Javascript equivalent function is kind of wonky so they had to make is_the_computer_really_on() to do what you want here.

there's a convenient npm package to handle that for you

Yeah but you never know whose computer the result applies to

And a separate package by the same prolific author for not_on that depends on the first package.

You really should use onoff.js, which is a wrapper that is more actively maintained and has a typescript support

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.

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."

I tried inverting the clock and running a one way hash and my CPU vanished...

Thanks for sharing, OP. I thought I was going to have to do a Haiku rewrite in Rust to do something like this.

I’d like to see the unit tests for the non-true return state.

I think that would have to be an integration test

It's actually pretty straightforward:

turn_computer_off();

Assert(!is_computer_on(), "Computer should have been off but it's on.");

The opposite is a bit tricky, though.

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.

Result is undefined if computer isn't on, so any value is OK, no tests necessary.

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).

I think the is_computer_on_fire function is far more useful

I posit a much more interesting question.

Given a lump of silicon, how does one programmatically tell if it is a computer?

`rock.exists()`? see also the last line of most "weather rock" forecasting stations.

Impl code here[1]:

  int32
  is_computer_on(void)
  {
      return _kern_is_computer_on();
  }


  double
  is_computer_on_fire(void)
  {
      return 0.63739;
  }

[1] https://github.com/haiku/haiku/blob/master/src/system/libroo...

Was used by the Haiku doc, namely "System calls"[2], as an example.

[2] https://www.haiku-os.org/documents/dev/system_calls/

Leh, 0.63739 means "on fire"? Any conversions?

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.

integrate power consumption seems like an easy answer.

I was expecting this to be about using IPMI on a BMC to see if the motherboard is powered on.

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.

https://github.com/haiku/haiku/blob/8f16317a5b6db5c672f33181...

woah! i had no idea beos lived on in an oss project!

It works great on my Thinkpad. I run it on the metal.

Interesting, but I think parent was asking how to run it on silicon.

now i'm confused.

"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.

Similar situation: a process queries the operating system (CPU scheduler) to find out if the process is currently being executed on the CPU.

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.

Maybe it’s a probability function. Something like “hey there’s a .7 percent chance your computer is engulfed in flames”

Constant probability function. (Please be precise!)

Wonder if this is a throwback to the HCF command.

https://en.wikipedia.org/wiki/Halt_and_Catch_Fire_(computing...

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)

My new favorite review comment on while(true) : prefer system.isOn() which is more reliable to detect computer off.

Lots of weed hand grown by Jean Loius-Gasse was smoked in the offices of Be back in the day...

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?

"Returns 1 if the computer is on. If the computer isn't on, the value returned by this function is undefined."

is_computer_on_fire() seems more usable...

weird how it's returning a constant https://github.com/haiku/haiku/blob/8f16317a5b6db5c672f33181...

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

Not 451. I'm disappointed at the missed opportunity.

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.

Probably I'm being nerd sniped. https://xkcd.com/356/

Doc doesn't specify the unit of measure used. Also would be nice to know if fire was caused by computer itself or from an external cause.

I like to call this at the end of an intialization sequence, with a throw to is_computer_even_plugged_in() .

Defensive programming at its best

http://www.ismycomputeron.com

Is that talking about my computer or his computer?

Your computer. It hacks your computer to find out the state.

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?

Presumably there's a non-joke version of this at some level in the hardware / firmware stack?

https://docs.microsoft.com/en-us/windows/win32/power/system-...

I read "Soft Off" as "sort of" and though, well, that's probably the best answer one can get in certain situations.

Yes, the ‘ipmitool power status’ command lets you query a server over the network to see if it is on

How do you know you are on (exist)? This is the equivalent for computers trying to become sentient.

Where is the function is_halting() ?

Right? Especially since the implementation is so simple, and even runs in O(1) time:) https://xkcd.com/1266/

Nobody mentions the decades old BeOS blog www.iscomputeron.com ?

> 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 :)

Even if it were, how could it actually know, really?

Odd they have a TI 99/4a platform but no TMS990 CPU.

"How to find out computer is on fire"

Keeps timing out.

boolean did_customer_cause_fire();

Returns TRUE.

Reply on news.ycombinator.com