In a word, yes.

Longer version: Every important metric I've ever looked at, aside from input power requirements, are a lie in some way. Response times listed for LCD screens are outright fabrications, contrast ratio on ANYTHING uses abusive testing methods, Intel CPU power consumption figures are always "average usage", input latency issues with displays are always a lie of omission, hard drive sizes are stated in what I call "short mega/gigabytes", etc, etc, etc..

The very fact that these figures are largely unchallenged makes it necessary for a manufacture to survive as people are only reading the figures on the box.

Product X: 100W
Product Y: 250W

Which do you buy? Product X? that's it's idle consumption (reduced by 10% as well). Product Y is listing it's maximum usage which is only possible in laboratory conditions as feature A and B are normally exclusive. So Product Y doesn't move many units and the parent company goes out of business.

Even though it's idle consumption is only 55W and it's typical consumption is in the high 90s or low 100s of watts, topping out at 180W max in the field.

You should ignore those stickers and read reviews that actually measure usage under a wide variety of conditions. That's one thing I miss from the old Tom's Hardware monitor reviews; they did objective measurements of pixel refresh speed with an oscilloscope attached to an optical sensor (photodiode or resistor of some sort).

And also:

http://en.wikipedia.org/wiki/Castle_Wolfenstein ..which was an interesting game back in the day.

Most of Duracell's NiMH LSD chargers are individual channel too, although not nearly as nice as a BC-700, heh..

I would have thought that most NiMH (both LSD and non-LSD) would be one-channel-per-battery, as you can't just dump charge into them and expect them to be happy like old NiCDs were.

Note that there are other LSD batteries aside from Eneloop.

Duracell's "Precharged" batteries are actually NiMH LSDs as well. Energizer has a LSD model as well, called "Recharge", I think.

Most rechargeables with a "ready to go" labels will be NiMH LSDs like Eneloop. If they didn't have high retention, they'd have to be recharged before first use.

They aren't lithium ions, which biodegrade within 30 seconds of manufacture, regardless of usage, temperature, humidity, etc.

Do you have any trustworthy sources to suggest that NiMH LSD batteries would have such a small shelf life?

I packed up some batteries about six years ago during a move, still installed in devices. Some alkaline, some NiCD. The box was placed in storage instead of unpacked. All the devices with alkaline batteries had been destroyed by battery leakage. None of the NiCDs leaked at all, although some had died from being reverse charged. These were mostly name brand alkalines (Energizer, Duracell), with only one being a prepackaged no-name type.

My own NiMH LSDs are much newer than that, but I have a batch of older pre-LSD NiMH, and they haven't leaked either. Being similar to NiCDs, I expect them to be less.. leakily corrosive than alkies. Unless..you have better information on their long term survival.

If I'm right about their non-leaky nature though.. what's cheaper, a pair of Eneloops or Duracell Precharged, or a replacement remote control and two leaky alkalines?

Besides, with LSD NiMHs loaded in the remote, if you need batteries in an emergency, well, you can always quickly scavenge them out of the remote. They're way better than alkalines at any high draw application.

http://en.wikipedia.org/wiki/Power_factor

Cheapass power supplies with crappy PF are putting a higher load on the utility company for no purpose. The power factor is basically how far out of phase the return power is from the grid's phase.

Your actual drain is your current * voltage divided by the power factor.

180W (1.5A @120V) with a 0.67 power factor is 269W of loss at the plug.
180W (1.5A @120V) with a 0.98 power factor is 184W of loss at the plug.

Why would companies spend thousands just to correct the power factor if it had nothing to do with actual load?

The figures I used previously were for real life systems measured directly at the plug with a kill-a-watt meter.

There are other factors involved that aren't measured there (like the efficiency during transformation and rectification), but there's no way the Athlon XP 2500 is a higher power consumer than an i7 920. Also, the high end PSU is rated at over 80% efficient in those jobs too.

http://www3.ttc.ca/About_the_TTC/Projects_and_initiatives/New_Subway_Train/index.jsp

This train seats 404 (heh). The total would be 1,598. I bet in actual usage it exceeds 2,000-2,200 well-sardined people.

188 KJ per person, versus 1 MJ per person in a car (seeing as the average car around here carries 1.0000001 people), in rush hour.

That's a six car train. A ten-car would have almost 2700 people in it by 'spec'.

Ever measured the power drain on that? Don't forget to factor in power factor. My old Athlon XP system (which was stripped down of various high-drain performance parts when it became a server) has more draw than my i7 potato cooker thanks to it's no-name 350W supply's 0.67 power factor vs. the 0.98 or so power factor of the i7's high end PSU. Never mind that the voltage from the cheapy PSU varies quite a bit and is actually out of tolerance on the 5V side. I'd replace it, but that machine is due for retirement anyhow as it's now a backup to a backup server...

I do a bit of consulting on the side, and most system failures are caused by no name, came-with-the-cheap-case power supplies. It's like the good old C64 era all over again: most of those died due to the epoxy-filled craptastic power supply being wildly out of spec.

PSU test results:

AMD Athlon XP 2500+ - 110W @0.67 PF = 164W
Intel i7 920 - 130W @0.98 PF = 133W

This is fully powered up (no sleep states) but not doing any heavy workload. Heavy workload flips those around, of course, but the older PSU is still using an extra 50% power for nothing other than heating the mains wires.

I'd love to play with an 800XL. That's like the 8-bit ancestor to my Amiga lineup.

Nothing meaningful? How about full 3D?

But then again, Quake gave us that.

I call 'em "Quake clones".

AmigaDOS (released mid 1985) uses 30-character names, including spaces etc, for drive names, volume names (the disk inserted in the drive, even hard drives had this, came in handy in the zip disk era), directory names and filenames. forward slash (/) for the separator, full-colon (:) for the root of the drive in question, and a null string for the current working directory ("").

Commodore 15xx series disk drives for the C64/128 (released at various times, starting in 1982) had 15 character filenames but no subdirectories. Volume names existed but I don't think they did anything. The actual C64/128 etc machines didn't really have a filesystem, the drive had almost as much processing capability of any of those 8-bit machines (6502 CPU and upwards of 8k of memory for some models) and handled all the 'filesystem' details.

MS-DOS really did take us way back. To be fair to CP/M, though, it was more of a 70s OS anyways and should have been laid to rest long before IBM went shopping around to strangle, er, monopolize, er, leverage another new computing industry.

To give an idea of what this has done to the industry, this is how I mount my 'projects' share from various machines:
Linux/BSDs: /net/proj/
AmigaOS 3.x: projects: (with an alias of 'proj:')
Windows/DOS: P:\
Commodore 128(keyboard style model): I don't have a smb or nfs driver for it. Or a network card. I could get the latter, and *possibly* the former if I cared though.

Your program isn't reflecting the reality of the situation.

Under Windows, merely opening a file for writing always locks it exclusively, unless you use one of the funky shared-write modes.

CreateFile("winblows.txt",GENERIC_WRITE,blah,blah,blah,blah,blah); -- winblows.dat has an exclusive lock on it. You cannot manipulate or delete it until that handle is released.

Under Unix variants, if you simply open a file in write mode, you can still manipulate and delete it. That's why Debian can do updates of running services whereas even the mighty windows 7 (er sorry, windows NT 6.1?) requires a reboot every month to patch in those updates.

The downside of the Unix method is that if you delete a file that's open for writing from another process, the space won't be released until that other process closes the file (or is terminated, which also closes the file). This, however, lets you use the files in a /tmp fashion without having to actually place them in /tmp, with a faster release to boot.

I'm not familiar with OSX ; I would have assumed it's the same as Linux/*BSD/etc, but some of the other posts and tests submitted suggest otherwise.

Debian 5.0:

rene@tessa:~/test$ cat > ABCD
^Z
[1]+ Stopped cat > ABCD
rene@tessa:~/test$ lsof | grep ABCD
cat 3263 rene 1w REG 3,1 0 429757 /home/rene/test/ABCD
rene@tessa:~/test$ mv ABCD EFGH
rene@tessa:~/test$ ls
EFGH
rene@tessa:~/test$ fg
cat > ABCD
abcd's contents
rene@tessa:~/test$ ls
EFGH
rene@tessa:~/test$ cat EFGH
abcd's contents

Writing into a file simultaneously from multiple handles is possible but not advised.

I wrote a DirectX 3* game many years ago as a test platform.

Most of the accelerator features available on PC platform at the time were either useless or not reliably available from system to system, so it generally just requested a surface and drew things manually (aside from background blits).

I still fire it up for fun every once in a while (yes, it still runs under Windows 7/64, despite being written for Windows 95, unlike 99% of the so-called "AAA" titles which crash and burn with each and every minor unrelated Microsoft update ever released, let alone moving from say Win2K->XP), and it runs fine..except one time my frame rate dropped off to something like 30fps for no reason. Normally it's running at 60fps, using less than 10% of the available render time. (I have vsync on; the game spends most of it's time waiting on a surface flip)

It turned out that my PCIe card dropped from 16x to 1x mode. It refused to return to 16x mode until I turned the machine entirely off. Once I did that though, it came back as 16x and my FPS was restored.

Those graphs are obviously for games/applications that aren't doing any direct rendering and aren't replacing textures very much. There ARE times when bus DOES matter.

Also, average times aren't going to tell the whole picture; do you really want to play an FPS that suddenly lags out while uploading textures for a new enemy that just appeared?

Granted if we're talking about PCIe 2.0 x4, it won't be quite so bad as say having to deal with 1x PCIe or old original low-end PCI, etc, but there will be times when the difference is very pronounced.

* - technically it's DirectX 5, but the only DX5 call it uses is the one that explicitly requests a frequency along with a resolution when setting the display mode. Plus, that was added later. It was originally purely DX3.

Random Ren Aside: I paid attention to the developer documentation. They told me stride(I think they called it 'pitch') isn't ~always~ equal to row length. They were right. They told me to use the QueryPerformanceCounter rather than snagging the TSC directly. They were right. Why can't AAA developers read these same documents?

You can get a USB->Amiga 1200 clockport bridge too.

The clock port is a little 22 pin header on Amiga 1200s (low end Amiga 'keyboard computer') that allow a realtime clock to be installed inexpensively.

Third party manufacturers have made USB controllers for it... amongst other things. You definitely can bridge transports with enough will! Even ones with 4 address lines and 8 data lines hooked up to D16 through D23 of a 32-bit data bus.

You know, I've been meaning to get a CF-to-IDE adapter and plug that into my old Amiga 1200.

You see, it didn't spontaneously write to the OS disk. EVER.

The only times writes occurred there is if you saved prefs, copied files there, or specified it as a location for a file that you're saving.

I think later third party extensions caused writes to be a bit more frequent, and I don't know about the successor OSes (>3.1), but 3.1 and earlier and earlier had this .. read purity thing going on. I'd love to run it on an old one gig CF card, as that would be tons of space for 3.1. Turns out, many years later, that this behavior has some very serious benefits -- it's the perfect OS to run on a flash card.

Hell, the original machine only had 120 -megabytes- of space anyways when it was a primary machine, with like a 20 meg OS partition.

So, for some OSes, it would be the perfect media.