Re: Basic linux network questions (long)
> ACPI is very complex, there is some sort of programming language needed for
> communication with the BIOS, and to make things even more challenging many
> laptops get it wrong in subtle ways because there wasn't much OS support to
> test it with at the time they were designed!
Well, they failed the basic principle, which is
* declare what you're gonna do
* hardware and software both implement the same thing
Mswin is therefore ahead of us in that space, since they have more money to
twist developer arms with :(
> ACPI is still quite experimental, and I recommend not using it unless you
> want to help in testing or development. So if you want to just use a laptop
> to get things done (as the original question was about) then APM is really
> the only option.
The choice of experimenting with crappy APM (because the Beast From Redmond
implements ACPI so much better than they implement APM, hardware manufacturers
no longer properly regression test it; I have first hand experience with that
issue) ...
or with crappy ACPI because software-wise "it's not complete" and in fact
never will be if people do not use it and report all the big hairy bugs...
... has to be left to the fellow who asked the question.
Reminds me of the quote, "if you left deciding when the project was finished
to its lead programmer, no software would ever be shrink wrapped." Not
necessarily a feature if shrink wrapping (apt-get install Foo, anyone?) is
the only way most folks pick up software.
> > So you have a tradeoff, excellent software in the APM space but a
> > brain-dmgd suspend-APM signal will (and often does) result in spurious
> > crashes on suspend/resume.
>
> Also many other funny things happen. Sometimes on Thinkpads after a resume
> from APM sleep they do funny things such as beeping repeatedly until you do a
> hardware reset. I'm not sure whether other laptops have similar problems,
> but suspect that they do.
APM and ACPI both have some machines completely freak out the sound system on
suspend/resume if the sound is not fully released and its module set unloaded.
Yep, it can be a problem... but it's not news, and it's not ACPI specific.
> ACPI is powerful enough that hopefully when it's implemented fully and
> debugged it will allow enough control over the hardware to resolve such
> problems.
y/n. It will allow *compliant hardware* to have more granular control; it
may allow CMOS values to be useful to end users again; but "enough control"
has to be well tuned drivers, and that's a "mere matter of coding". In other
words developers who write crappy code need to be poked in the ribs with bug
reports :)
The more detailed the better, and the more QA one is willing to do to prove
it's fixed up, better yet :) :) :)
> It's been a while since I tried ACPI (last time it failed totally but there's
> been a lot of progress since).
>
> > As opposed to excellent hardware but minimal
> > software in the ACPI space, means some devices may not get on the clue
> > wagon, and not be quite right after resumes. aaaagh ;P
>
> Yes, hope and pray that your hard drive is not one of those devices that is
> not quite right...
standard IDE is one of the early things to do right, or why bother? But at
that point I'm just babbling and no longer offering more than an opinion.
Returning to more useful second-hand data, there have been some claims of
people actually using ACPI to do suspend-resume and live day to day. I'm
not such a user, but may be soon as one of the laptops I have access to is
in the "crappy APM hardware" category and is likely to become my guinea pig.
I'd recommend making the machine fairly quiescent before suspending that way,
much the same way that I recommend not running apps you really don't use;
why waste battery?
I'm also not a user running a journaling filesystem for day-to-day use, but
otoh, if one *knows* they will crash a lot, maybe ext3 is a good idea...
(set up runlevel 7 to run fairly few things at all, rather like runlevel 1
but with the acpid/apmd still running; syslog, most of gettys, mail daemon,
that dev webserver you play with can all be turned off. Then wire up
"kbdsignal" aka alt-uparrow to telinit 7)
> > In the 2.4 kernel series Linus has a competing tree of pcmcia support,
> > and trying to use both may have... odd effects. Me, I'm grumpy because
> > that stuff doesn't support some odd bits around my lab, so I stick with
>
> I'm grumpy that Linus merged broken PCMCIA code into the kernel at a time
> when Dave's tree of PCMCIA code was working very well, and that then this
> mistake was not fixed for a long time (has it been fixed yet?).
dunno, as I said, I use the real goods. I'm sure the notes are in the
changelogs somewhere but what I've been watching for is USB and whether the
vm and other loose parts are really stable yet. Worth noting that I still
live on 2.2.x.
> > > Look at resolv.conf. That's where your DNS servers should go.
> > > (man resolve.conf)
> >
> > ^^
> >
> > There was an "e" eating monster roaming around during the early days of
> > UNIX. It nailed the creat() system call too.
>
> I've read that one of the Unix creators once declared that his only regret in
> life was not calling it create() instead of creat().
I've heard this stated baldly, from the man himself. At the time 12 UNIX(tm)
systems were using the call heavily throughout their software and it was
considered too onerous to make everybody change it. They were, after all,
scattered cross-country, and there was a considerable amount of latency in
software updates as they were limited by the speed of someone else's blue
station wagon. (bandwidth was pretty good, lots of room for tapes in the
broad back seat, but still... throughput sucked.)
Waaaaaay too late now.
> > No wait, the SAGE
> > (sysadmin's guild) claims responsibility for that last one :)
>
> Shouldn't it be "SAG" then? ;)
would be, but it stole and uses the "e" from the creat() system call. Any
claims about complaints from 'ollywood are completely unfounded. One might
suspect the silent "e" has therefore served very well as an extra.
(ba dum, ching!)
* Heather Stern * star@ many places...
Reply to: