Wandering Thoughts archives

Why I dislike ATX power supplies

Courtesy of a nice little thunderstorm, I lost power for a bit, which reminded me of why ATX power supplies are not my favorite thing. The problem is that they are too smart yet not smart enough.

In the old days of simple power supplies, when you turned a machine off it would stay off and if you turned a machine on it stayed on, and power failures didn't change this; after the power came back, the off machine stayed off and the on machine powered back up. In effect, the machines remembered their current power state and returned to it after a power failure.

For all its smarts, ATX is often too stupid to do this. Instead I usually get a choice between the machine always powering up after 'power failures' or never powering up after them. Neither choice is ideal, although the former is acceptable for a server style machine, and the whole thing seems a bit much to give up to get a poweroff command, however nifty it is.

In theory you can mostly duplicate the old way by setting 'always power on after power failures' and then always flipping the manual power switch or yanking the cord if you want the machine to be off. The problem is that this invites errors, because it's hard to notice that a machine is powered down but not turned all the way off this way and so will spring back to life after a power failure.

(The other problem with ATX is that your computer is always drawing some power even when nominally turned off.)

Sidebar: so who is really to blame for the problem?

I got curious enough to skim through the ATX power supply and motherboard standards, and as far as I can tell the actual power supply doesn't implement any of the power control stuff. Presumably it is all done by a motherboard circuit that is powered by the +5 VSB standby power line, and different motherboard makers opt for more or less sophisticated versions. This would neatly explain why some motherboards have the 'restore previous power state' option in their BIOS and others don't.

So apparently I should really be blaming lazy (or cheap) motherboard implementors instead of ATX power supplies themselves; all the ATX power standard did is let the motherboard people be lazy.

(For the curious, the Wikipedia ATX page has a good set of links. The standards are actually pretty short and easy to find things in.)

Why syndication feed readers ignore an entry's 'last updated' time

The simplistic reason is that only Atom feeds have a distinction between the date an entry was published and the date it was most recently updated. But as far as I know, even fairly deeply Atom aware syndication feed readers don't try to do anything much with the field; instead they look for changes in the entry's text.

One reason to not use it for much is that the Atom specification is fuzzy about when it gets updated. The specification says that it is only the time of the last significant update, where the publisher gets to decide what is significant.

Another reason is that I believe 'last updated' is inconsistently and erratically implemented in feed generators. Some never update it; some update it at the drop of a hat (somewhat to my regret DWiki is one of the latter, because it has to use the inode ctime as its best proxy for 'has this entry changed?', and inode ctimes can get updated for all sorts of reasons). It's hard to put much weight on something that is so inconsistent in both theory and practice.

But I think that there's a deep reason that feed readers ignore it in favour of looking at the text. The last updated field is something that the server tells them and they would have to take on trust, but updated text is something that they can check themselves. Checking the text is thus much more direct and reliable, and is easier to explain simply to the user: 'this flag on a message means that the text has changed since you last read it'.