From owner-freebsd-hackers Wed Apr 3 14:22:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA27549 for hackers-outgoing; Wed, 3 Apr 1996 14:22:10 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA27518 Wed, 3 Apr 1996 14:21:50 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA20146; Wed, 3 Apr 1996 15:15:40 -0700 From: Terry Lambert Message-Id: <199604032215.PAA20146@phaeton.artisoft.com> Subject: Re: It isn't easy being "green"... To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Wed, 3 Apr 1996 15:15:40 -0700 (MST) Cc: terry@lambert.org, jkh@freebsd.org, bde@zeta.org.au, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org In-Reply-To: <9603038285.AA828564378@ccgate.infoworld.com> from "Brett Glass" at Apr 3, 96 01:40:51 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > And since the usefulness of disabling the mode is limited to people > > with a burning need to run down the batteries in their laptops as > > quickly as possible, > > > or people with "green desktop machines" that they really didn't want to > > be green. > > There are a lot in the latter category! 8-). It's *illegal* in the US to tamper with this if you are getting the tax break for the green-ness hardware (it's called "tax evasion"). I'd much prefer FreeBSD be a "green-OK" OS, and leave the disable as an option instead of something mandatory for an install. > The machine on which I am installing is *not* a laptop. It's a perfectly > ordinary Zeos Pantera 486DX/100 desktop. More than a hundred thousand of > this make and model alone were sold. Right after the EPA announced its > "Energy Star" program, MANY vendors incorporated these drives into desktop > machines. And did not provide any way of turning off the "green" features > -- on purpose, so that employees of corporations that purchased the > machines couldn't do it on their own. Exactly. The OS's you run on these things are supposed to be "green-OK" or they are supposed to fail to operate. FreeBSD fails to operate, which is bad. > By the way, "Nate and the Nomads" is a cool name. What is the status on > their APM code? I think Nate answered this one already (privately? I was CC'ed). [ ... ] > > and ability to disable features that you have to go out of your way to > > find in a computer (so presumably you wanted them to work instead of > > being disabled) ought to be a controllable option. > > Again, for about a year, you almost couldn't avoid getting these > "features," especially if you bought from certain big mail-order houses. Well, it was either support the "bullet item of the day" or actually make better machines... guess which was cheaper to do? 8-). I think we both agree that FreeBSD should "just work" on these boxes. > > I think the primary use is for employees of companies trying to get > > the EPA tax incentive for energy conservation by putting unreasonably > > performant green machines on their employees desks. 8-). > > Yep. Hope you aren't audited -- does the EPA read this list? 8-). > > As a workaround to making the drivers robust (which is something I > > strongly think should *not* be worked around to incent a real fix), > > you might be able to convince Jordan to call the utility as part of > > the install. This should be sufficient to kludge around the bad > > driver code, which is the problem that originally bit you in the > > first place, without making it "standard practice". > > This would require three things. First, the ioctl to issue arbitrary ATA > commands would need to be added to the disk driver. (This is not hard.) > Second, the "disable spindown" utility would need to be called > for each IDE drive during the install (it would gracefully exit if it > did not recognize the hard drive). Finally, if a drive WAS found that the > code worked on (the installation could determine this via an exit code), > the command would need to go into rc.local during install. I agree with everything but the "finally". I think, like the TTCP extensions, by default there should be an incentive to fix the broken code, and there should be support requests from the people trying to use it to harrass the coders into doing the fix ASAP. If you fix it this way, there won't be any complaints (and there should be). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.