I bought a used 2000 Insight (5 spd) and I've had it for about 7 months now.
In my experience, I've consistently gotten around 60 miles to the gallon . In the winter it dropped to ~59 (Missouri weather), but on my current tank of gas I have gotten 64.8 MPG over the last 240+ miles. I drive about 5 miles to work one way in city roads, with an max speed of around 40 mph and several stop lights. On weekends I drive it on the highways and my mpg figure usually rises even on a 5-10 mile trip on the highway, which I figure means that I've gotten significantly better mileage. My worst mileage was when i drove to Indiana last thanksgiving and I did 80 mph most of the way. I got 55 MPG then.
In my opinion, the hybrids need to be driven a certain way. You can't really drive them the way you drive a regular car (accelerate too fast / brake fast). Dont get me wrong, I still accelerate normally, but being able to anticipate stops better and using the regenerative braking and getting the engine into auto-stop faster when the batteries are charged works like a charm for me. Insight Central has some driving tips that helped me a lot.
I'd chalk this guys problems up to him not adjusting his driving style to fit the car. Thats my 2cents.
Is it just me or does this article seem to have a Pro-Sco slant towards it?
SCO has admitted that its action is designed to shore up sagging sales by wringing revenue out of its rights to Unix, an older operating system from which Linux was derived.
Derived is used rather loosely here. To a casual looker, it might sound like SCO is in the right.
IBM scored a surprise legal victory in that court case when a judge ruled on Friday in favour of IBM in SCO's trade-secret violation lawsuit against the computing giant.
Whoa!:-) (emphasis on surprise)
SCO had been pressuring the courts to force IBM to reveal its Unix and Linux source code so SCO could prove that IBM was using stolen code. But the judge ruled that SCO would have to present its own Unix source code first and identify which software code had been stolen.
That does'nt make sense considering just about anyone can look at Linux source.
FreeBSD Release Engineering Team's Bruce Mah provides the latest status of what's holding up the official release of FreeBSD 4.8. Our take: we fully support FreeBSD RE's approach to fixing necessary problems before officially releasing the product. Thanks mezz, our forums moderator for the newstip.
[Read full announcement]
Date: Wed, 2 Apr 2003 16:23:25 -0800 From: "Bruce A. Mah" To: freebsd-stable@freebsd.org Subject: 4.8-RELEASE status
Hi--
A number of you have been (rightfully) wondering what's up with the i386 4.8-RELEASE. Here's the current state:
The files that are as of this moment tagged as RELENG_4_8_0_RELEASE can't be used to build a release because the MFSROOT kernel (that goes on the kern.flp) overflows a the size of a 1440K floppy disk.
This bug was masked by another problem that happened to be present on the machines used by the RE team to build releases...namely, that they didn't have the cvsroot-all collection in their local repositories. To make a long story short, the $FreeBSD$ tags didn't get expanded in the source files, thus (I am not making this up) causing the MFSROOT kernel to be just a *little* bit smaller so that it could fit on a floppy. I think this was the world's April Fool's joke to the RE team.
We're currently trying to fix this by finding some other driver we can move to a module on the mfsroot.flp image (or maybe just eliminate). After we finish some tests, we'll need to commit whatever change is required, re-tag the affected files, and then rebuild the base system.
I'm not in a position to comment on a timeline for these happenings.
Thanks for your continued patience!
Bruce.
PS. This may sound rude, for which I apologize in advance: The less time that the RE team has to spend replying to various emails (particularly those that are not relevant to the immediate goal of shipping 4.8-RELEASE), the faster the release is probably going to be finished.
Slashdot Mirror
I bought a used 2000 Insight (5 spd) and I've had it for about 7 months now.
In my experience, I've consistently gotten around 60 miles to the gallon . In the winter it dropped to ~59 (Missouri weather), but on my current tank of gas I have gotten 64.8 MPG over the last 240+ miles. I drive about 5 miles to work one way in city roads, with an max speed of around 40 mph and several stop lights. On weekends I drive it on the highways and my mpg figure usually rises even on a 5-10 mile trip on the highway, which I figure means that I've gotten significantly better mileage. My worst mileage was when i drove to Indiana last thanksgiving and I did 80 mph most of the way. I got 55 MPG then.
In my opinion, the hybrids need to be driven a certain way. You can't really drive them the way you drive a regular car (accelerate too fast / brake fast). Dont get me wrong, I still accelerate normally, but being able to anticipate stops better and using the regenerative braking and getting the engine into auto-stop faster when the batteries are charged works like a charm for me. Insight Central has some driving tips that helped me a lot.
I'd chalk this guys problems up to him not adjusting his driving style to fit the car. Thats my 2cents.
Is it just me or does this article seem to have a Pro-Sco slant towards it?
:-) (emphasis on surprise)
SCO has admitted that its action is designed to shore up sagging sales by wringing revenue out of its rights to Unix, an older operating system from which Linux was derived.
Derived is used rather loosely here. To a casual looker, it might sound like SCO is in the right.
IBM scored a surprise legal victory in that court case when a judge ruled on Friday in favour of IBM in SCO's trade-secret violation lawsuit against the computing giant.
Whoa!
SCO had been pressuring the courts to force IBM to reveal its Unix and Linux source code so SCO could prove that IBM was using stolen code. But the judge ruled that SCO would have to present its own Unix source code first and identify which software code had been stolen.
That does'nt make sense considering just about anyone can look at Linux source.
There's nothing like a good slashdotting to mark their 10 year anniversary :-)
FreeBSD Release Engineering Team's Bruce Mah provides the latest status of what's holding up the official release of FreeBSD 4.8. Our take: we fully support FreeBSD RE's approach to fixing necessary problems before officially releasing the product. Thanks mezz, our forums moderator for the newstip.
[Read full announcement]
Date: Wed, 2 Apr 2003 16:23:25 -0800
From: "Bruce A. Mah"
To: freebsd-stable@freebsd.org
Subject: 4.8-RELEASE status
Hi--
A number of you have been (rightfully) wondering what's up with
the i386 4.8-RELEASE. Here's the current state:
The files that are as of this moment tagged as RELENG_4_8_0_RELEASE
can't be used to build a release because the MFSROOT kernel (that goes
on the kern.flp) overflows a the size of a 1440K floppy disk.
This bug was masked by another problem that happened to be present on
the machines used by the RE team to build releases...namely, that they
didn't have the cvsroot-all collection in their local repositories.
To make a long story short, the $FreeBSD$ tags didn't get expanded in
the source files, thus (I am not making this up) causing the MFSROOT
kernel to be just a *little* bit smaller so that it could fit on a
floppy. I think this was the world's April Fool's joke to the RE
team.
We're currently trying to fix this by finding some other driver we can
move to a module on the mfsroot.flp image (or maybe just eliminate).
After we finish some tests, we'll need to commit whatever change is
required, re-tag the affected files, and then rebuild the base system.
I'm not in a position to comment on a timeline for these happenings.
Thanks for your continued patience!
Bruce.
PS. This may sound rude, for which I apologize in advance: The less
time that the RE team has to spend replying to various emails
(particularly those that are not relevant to the immediate goal of
shipping 4.8-RELEASE), the faster the release is probably going to be
finished.