[somewheres]

I'd rather see a hard crash and know for sure that the battery is too empty to perform work.

Stupid battery warning meters are a lie, and a waste of valuable power.

If you have enough power to show me that you don't have power, I know your battery meter is full of shit. It means the board can still operate, and is probably performing a small subset of tasks without my awareness, in a low power mode.

Maybe the accelerometer is still capturing events, maybe lots of things are happening, below the threshold of activating the monitor and expensive motors.

The greatest sin of all, though. The hands-down WORST crime committed, is when the hardware IS PLUGGED INTO A POWER SOURCE, BUT REFUSES TO POWER ON BECAUSE "THE BATTERY NEEDS TO CHARGE FIRST."

WHAT???

[matthewmacleod]

Stupid battery warning meters are a lie, and a waste of valuable power.

No, they're not. Knowing the charge of a battery accurately is essential to managing the performance of a lithium battery; they're pretty sensitive to this stuff.

If you have enough power to show me that you don't have power, I know your battery meter is full of shit. It means the board can still operate, and is probably performing a small subset of tasks without my awareness, in a low power mode.

See above. Power management systems never let a battery completely discharge; this would destroy a lithium battery. There will always be a small amount of reserve power available for managing battery life.

The greatest sin of all, though. The hands-down WORST crime committed, is when the hardware IS PLUGGED INTO A POWER SOURCE, BUT REFUSES TO POWER ON BECAUSE "THE BATTERY NEEDS TO CHARGE FIRST."

Again, this is down to the sensitivity of lithium batteries. If the charge of the battery falls below the minimum safe level, the device will charge it before allowing you to take power. There are a couple of reasons – it's important to make sure the battery doesn't fall into deep discharge, and to ensure that device power isn't immediately cut off (=hard crash) if the user subsequently disconnects the power before the device charges to acceptable levels.

[somewheres]

  Again, this is down to the sensitivity of lithium 
  batteries. If the charge of the battery falls below 
  the minimum safe level, the device will charge it 
  before allowing you to take power. There are a couple 
  of reasons – it's important to make sure the battery 
  doesn't fall into deep discharge, and to ensure that 
  device power isn't immediately cut off (=hard crash) 
  if the user subsequently disconnects the power before 
  the device charges to acceptable levels.

No. It comes down to mediocre design, and unfortunate misconceptions, and tunnel vision about what's worth designing for and what isn't.

1. If the main board is receiving power, it can use some of that power.

2. The user can pull the plug, and and cut power to the main board, and guess what, the main board can simply stop working without trying to consume power from a battery without enough power to operate safely.

3. The operating system can employ an architecture that tolerates hard faults, in the middle of code execution, and address them upon the next successful reboot. Yeah, that's expensive to develop, and yeah, Apple computers are expensive.

4. With each of these preceding points in place Deep Discharge of lithium batteries is irrelevant, because the main board is in control of whether or not the battery is even called into action at all. With AC power, no power needs to be sourced from the battery. Anxieties about a bricked device are circumvented with a durably designed OS. The end.

[matthewmacleod]

It's more complex than you claim – I've worked with a few of these systems.

There are a lot of edge cases; consider that in some cases devices being used a full-blast power can draw more current when operating then a charging device can supply, meaning they can still discharge batteries even when AC power is available. (Apple example – smaller power adapter than supplied. Still technically works to charge, but not supply power. Or any arbitrary 500mA USB charger.)

Yeah, I don't doubt that you could probably engineer something that works. But would the complexity be worth it? Probably not. The fact that every modern device (Apple and otherwise) behave this way should suggest that it's not that easy – if it were, it wouldn't be implemented that way.

[JasonSage]

> The greatest sin of all, though. The hands-down WORST crime committed, is when the hardware IS PLUGGED INTO A POWER SOURCE, BUT REFUSES TO POWER ON BECAUSE "THE BATTERY NEEDS TO CHARGE FIRST."

I don't know this for sure, but I'm guessing that the device waits until it has enough charge to boot properly. Otherwise, if you disconnect the power source the computer does not have enough power to finish booting and will hard crash somewhere in the boot process. I don't know if it's enough to brick your machine but it's easier to just let the thing charge for a minute before you hit the button.

[somewheres]

If it's plugged in, it can boot. Anything else is a malignant abomination masquerading as design.

No exceptions.

[dkonofalski]

That seems an awful lot like an opinion rather than an objective assessment. Yes, if it's plugged in, it can boot. If it gets unplugged, though, as laptops are wont to do, it can't. Ensuring that a laptop is, at a minimum, usable without power before allowing a boot seems like an excellent design.

[morcheeba]

Requiring a battery can be a design decision. Let's say a computer uses 10W on average with a 40W peak for short bursts. If you've got a 20W power supply, it won't be able to supply those bursts. But add in a good battery and it will be able to. Of course, you could just make the power supply twice as powerful, but it will weigh more, be physically bigger, and become less efficient.

[somewheres]

Let's be honest, those 40W spikes are due to video playback and/or other GPU bound tasks. Sorry, wait for the battery on those. But booting the OS should be unconditionally permissible on AC power.

So design the OS bootstrap to never spike consumption past the load capacity of the power supply. Once booted, deny access to processes that will slam power consumption, until you have a sufficiently energized battery.

Hey, presto, a weightless solution solved in software without any additional added mass!