Andrew Lentvorski wrote:
DJA wrote:
Well, he's entertaining anyway. But to me he represents the average
lazy, and technically ignorant user who thinks his way should be the
only way. Especially if it means any mental work on his part. The rest
of us should just pound sand.
Maybe, but the whole problem with the "Power" button on Windows is that
it doesn't really work unless you power completely off.
But he's pointing out that Vista now offers more suitable options. His
opinion though, is that _you_ shouldn't have or need those options if he
doesn't understand them.
My Macbook almost *never* gets powered off. I shut the lid and I reopen
the lid. I go weeks without hard powering my system up or down. And
then, the restart is generally some idiotic Apple system upgrade (bad
Apple--no biscuit).
I have no experience with what Macs do. In any case the author was
criticizing Vista.
On Windows, even one shut lid-open lid cycle starts introducing strange
bugs. My rule of thumb is, 3 cycles or screwball bug, whichever comes
first, and hard reboot.
I sympathize, but then Windows doesn't need a lid cycle as an excuse to
call initiate_brain_fart either. Again, this author is railing against
options that he's (implicitly) given the benefit of the doubt in that
they work as designed. He's not complaining that they don't work, he's
complaining that they even exist.
And, he is correct about power management, the computer should be *far*
better at managing that than it is. When the computer is idle, it
should be ready to park everything immediately.
According to the ACPI spec it is. Getting implementors of the ACPI spec
to follow it properly is the problem. That applies to both BIOS writers
and OS designers. I've followed the ACPI4Linux mailing list for at least
a year, and my observation is that most of the problems are caused by
poor or misunderstood documentation regarding how the ACPI spec has been
implemented in both the hardware and the BIOS.
Fortunately, on the BIOS/hardware side it's usually possible, though
sometimes messy, to see what's supposed to happen by examining the DSDT
and associated tables. Linux developers try very hard to work around
DSDT and/or hardware bugs. However, M$ leaves no documentation behind as
to what they are doing, and when they make a mistake which has a certain
user-noticeable outcome, the user than assumes that is the proper
behaviour and thinks when using another hardware platform or OS, "Why
can't this work like Windows!). All the while never knowing that the
Windows behavior is actually broken.
The problem is that whole boatloads of applications sitting in the
background are too blasted chatty. "Hey, I cleaned the disk. Hey, we
redid the application caches. Hey, here's another inconsequential log
message." All of these applications demand persistency for no good reason.
True. But then ACPI accounts for this. The biggest offenders are not
applications, but buggy drivers (hard drive controller, video, lan,
sound, etc.) which don't properly account for power management behavior.
The worst offenders are the web browsers. "Let's cache everything on
disk! Yay!" in spite of the fact that we now have computers with 1GB+
of RAM and network connections that can reload almost instantly. If you
want to write my last links to disk as history, maybe, but I should be
able to shut that off. Keep my last browsing in RAM cache, or *throw it
out*. Writing cached images to disk is now useless.
-a
Keeping within the context of power management, RAM has to be refreshed.
And that uses power. Thus Suspend to Disk. If things work as intended, a
resume after this puts your system back to where it was before suspend.
I agree there is a lot of drive space wasted on stoopid stuff like your
examples above. Simply dumping the system to RAM is not very helpful, if
when you return to your laptop, you find that power management's only
solution was to notice there was only 5 minutes of battery left and so
turned the computer off.
--
Best Regards,
~DJA.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
