I was barfing at the use of 'gigawatts per hour' when the correct term is simply gigawatts, a unit of power. Running at full output, Hoover Dam will produce 2 gigawatt hours (2 million KWH) in one hour - which is now referring to units of energy. Remember power=(energy/time) and energy=(power*time), so saying Hoover Dam puts out 2GJ/s would also be correct (and 7.2TJ/hr).
'Gigawatts per hour' would be the correct term/phrase to use when describing how power production or demand changes with time and implies a time varying power. My guess is that Hoover Dam could go from no load to full load in about a minute, which means load increase rate of 120GW/hr.
Your calculation that the average power draw of servers compared to the peak output of Hoover Dam is correct. Another way of putting the demand from servers is that nearly ten 10,000 ton coal trains a day would be needed to feed the power plants generating electricity for the servers.
Or lets do it this way. Hoover Dam at peak output produces 2 Gigawatts of power per hour.
What you meant to say is "Hoover Dam at peak output produces 2 Gigawatts." What does make more sense is saying 48 million KWH per day or a bit over 17 billion KWH per year - assuming that there is enough water behind the dam to allow for continuous peak output, which is certainly not the case this year.
I was about to say interstate commerce - then saw ya beat me to it....
What congress is doing with this bill is no more unconstitutional than the bills prohibiting local taxation of information services. One difference is that instead of limiting what local governements can do, the bill gives more freedom to the local governments (it allows, but does not mandate, municipal ISP's).
The best of both worlds would be where the local goverment provides the last mile connectivity and the individual is allowed to pick their ISP.
The real downfall of the S100 systems was the memory... I can still remember paying $1600 for a 16KB (iirc, might have been 64K) static memory board.
I remember a price of $1200 for SCP's 64K static RAM boards in late 1981 - price had dropped to $1000 when I bought my SCP system in '82. Their original RAM was a 16K board.
The speed of the SCP (processor and 8" floppy) was impressive compared to the original IBM PC.
Apparently, despite Tim Patterson's denial, QDOS "ripped off" CP/M, specifically in the user interface, which in 1980 was the defining characteristic of software copyright law.
Ripped off the user interface - WTF are you talking about??
Copying an oldfile to newfile in CP/M: A> PIP newfile oldfile (may be missing some characters)
Copying an oldfile to newfile in 86-DOS: A: COPY oldfile newfile
The 86-DOS command for deleting a file was ERASE
86-DOS used BATch files, CP/M used SUBmit files
The API for QDOS/86-DOS was by design a close copy of CP/M's API, specifically to allow for translation of CP/M code to 86-DOS code. The concept of File Control Blocks were brought in for the same reason (most, but not all, data structures matched). 86-DOS also emulated using a jump instruction to use an OS call, which then executed a software interupt (21H).
There were some significant differences between 86-DOS and CP/M. One is the lack of an IOBYTE in 86-DOS. Another is that the file sizes were known to the byte and not to the block size. Disk reads and writes could be done in any size from 1 byte to 64KB. CON, AUX and PRN were treated like files.
Anyway, calling 86-DOS a rip-off of CP/M is pretty much like calling Linux a rip-off of Minix. And if you're talking about UI, CP/M is probably more of a rip-off of RSX-11 then 86-DOS was a rip-off of CP/M.
You're probably correct in that UFS could be patched to swap bytes when needed. OTOH, Sun seems to be committed to using ZFS as their file system of choice and they also seem committed to having ZFS ported to other OS's (e.g. MacOS and FreeBSD). In addition, ZFS seems to be more rigorously defined which suggests that different implementations will more likely be interoperable than currently is the case for UFS.
When Solaris installs a full C compiler as a default part of the installation, then I might consider it as a serious operating system. Otherwise, it's a toy OS, just like that Microsoft thing.
The hell with the full C compiler, when are they going to, by default, a full Cobol compiler??? Or a Pascal Compiler (especially one with MS-Pascal and Turbo-Pascal emulation???
If you're going to feed the trolls, you might as well go hog wild...
As Otterly mentioned, the primary problem with ZFS and Linux is that licensing issues prevent ZFS code from being part of the Linux kernel. I have heard of an user-space implementation of ZFS for Linux, which sidesteps the licensing problem, though there may be a performance penalty.
There was a Slashdot article a while ago, where one of the Linux kernel developers (Alan Cox?) was critical of the way ZFS changed layering in the file system code. ISTR the retort being that ZFS was still layered, but in a significantly different way than the Linux VFS code.
I wonder how hard it would be to port FreeBSD's port of ZFS to OpenBSD? If that isn't too difficult, ZFS would be the preferred solution (at least with MacOS 10.5).
Since I've been in R&D most of my working life, a numeric co-processor has been a necessity for almost all of the machines I've worked on. The first 486 bought by our company was purchased December 1990. I remember one application where we replaced a 12MHz 286 mobo (with 287) with a 33MHz mobo and were impressed with the speed improvement.
My original point was that it was cheaper to make the mobo for the 486 than for the 386 because you didn't need the co-processor socket and could get by without a cache on the mobo. By "cheaper", I mean the cost of the motherboard before the processor and main RAM is installed.
I seem to recall a price around five grand for a 10MB hard drive ca 1978. Whether my memory was correct or not, hard drives were not cheap - which is why a 4GB filesize limit looked like infinity back in early 1980.
Personally, I've got high hopes for UFS/FFS. Just about every operating system supports it in one form or another. Unfortunately, it seems nobody has bothered to get their implementations compatible with other implementations. So, while there is UFS/FFS support for Windows/OSX/Linux/*BSD/Solaris/AIX/etc. it's all in just a slightly different on-disk format, so it's not easy to get one to read another.
An example of compatibilty problems, UFS drives formatted on Solaris/Sparc are not readable by Solaris/x86 due to byte order in the data structures. Fortunately, Sun realized that mistake with ZFS - the byte order is determined by the machine that formatted the drive (zpool), but the ZFS driver will swap bytes if needed.
IBM didn't have exclusive rights to MS-DOS because that's not the agreement they made with MS. There were no legal hurdles that prevented them gaining exclusivity had they wanted it.
One hurdle was that SCP had already distributed 86-DOS to Lomas Data Products prior to the sale of rights to MS (see the LDP ad in the June 1981 issue of BYTE). In order for IBM to have exclusive rights to MS-DOS, they would have had to have MS negotiate with both SCP and LDP about using another OS for their machines and that would have ended up costing a lot more than the $50,000 that MS paid SCP for 86-DOS. As part of the sale of 86-DOS, SCP got royalty free access to MS-DOS and MS programming languages for CPU's sold by SCP.
Related point, work on 8086 support at MS started because of SCP - MS Disk Basic was running on SCP hardware in November 1979.
as we are talking about data here, often un-recoverable and damned important
Excellent point. Even for a home user, the data on the drive is far more valuable than the drive itself! Whoever mod'ed your post as flamebait obviously has problems with reading comprehension.
Of course fat32 still works just fine for this application, but it's getting a little long in the tooth as far as advanced features and modern storage needs go (c'mon what is up with those weak filesize limits)!?!?
When Tim Paterson first wrote QDOS, he thought that four bytes would be more than enough for file size (10MB hard drives cost several grand at the time) and that also happened to fit in with a 4 byte data element in CP/M's file control block. At least we weren't stuck with the bit-map from CP/M.
I was rather amused to read that one of the forensic applications understood Solaris UFS, so wouldn't be surprised if that same app has been updated to support ZFS. The investigator would have to be careful to ascertain if the ZFS disks were set up as a RAIDZ pool.
OTOH, you might have some fun with a CP/M formatted disk - say an 8" or 14" disk from the 1980's with some rare interface.
If you're going to bring up MS-DOS, you might as well mention Seattle Computer Products. The reason that MS-DOS was available for other machines was that it was originally written by SCP for their own hardware - and since IBM did not pay for the original development, they had no exclusive rights to MS-DOS. BTW, Compaq and a few other companies had their own forks of MS-DOS. Also BTW, DR-DOS was the result of DR reverse engineering a reverse engineered version of CP/M.
What made the business case for the IBM PC was Lotus 1-2-3, which was written specifically for the PC. What helped the clone market was that the IBM PC design was pretty generic, allowing for relatively easy cloning.
As for AMD's market share in 386 systems, it doesn't take much to force a change in Intel's pricing. FWIW, 486 motherboards were cheaper to build than 386 motherboards - the 486 had onchip cache and didn't need a numeric co-processor.
Did you ever see what Compaq was asking for their first 486 systems? Seem to recall prices on the order of 10 grand or so. OTOH, generic 486 boxes were a lot cheaper - which is exactly my point that Phoenix (and AMI) did a lot more for lowering the cost of the PeeCee than IBM, Intel or MickeySoft. Remember also that Windoze didn't start taking off until 1991 or '92 - also remember that the killer app for the IBM PC was Lotus 1-2-3.
Ca 1991, 386 boxes were a lot cheaper than 486 boxes in part due to AMD selling 386's.
If it weren't for the PeeCee clone market made possible by the Phoenix BIOS and the competition in the processor market keeping Intel on their toes, the low cost high performance Linux system as we know it wouldn't exist.
Remember, back around 1990, IBM and Compaq system prices were pretty close to what was being asked for low end HP/Apollo, Sun and MIPS boxes. Now if DEC had been more agressive with the pricing for Alpha and Ultrix...
There are a couple of areas where a USB serial port can not replace a "real" serial port. One is the 1PPS signal from a GPS receiver for timekeeping. Admittedly an esoteric example....
Sun still uses serial ports on their Sparc workstations (e.g. Ultra 25 & 45) as one is used as the console port when running headless.
One final note - serial ports are still useful for connecting to embedded devices as the protocol can be much simpler than USB. Or for that matter, USRobotics Courier modems (the T-1 connection for my worksite is administered remotely using a couple of Courier modems).
While I don't recollect the exact name of Gate's and Allen's first company, I do remember they were using an 8008 as part of a system to record traffic data (this would be ca 1973).
The nice thing about Circuit Cellar is that Steve Ciarcia chooses what to put into the magazine based on his passions and not the current fad. He has another advantage in that most of the advertizers are of interest to the readership.
Or how about Sol Libes rag, Microsystems?? That faded away a couple of years before Microcornucopia. A really old timer was Interface Age, which, IIRC, folded ~1980.
Slashdot Mirror
'Gigawatts per hour' would be the correct term/phrase to use when describing how power production or demand changes with time and implies a time varying power. My guess is that Hoover Dam could go from no load to full load in about a minute, which means load increase rate of 120GW/hr.
Your calculation that the average power draw of servers compared to the peak output of Hoover Dam is correct. Another way of putting the demand from servers is that nearly ten 10,000 ton coal trains a day would be needed to feed the power plants generating electricity for the servers.
What you meant to say is "Hoover Dam at peak output produces 2 Gigawatts." What does make more sense is saying 48 million KWH per day or a bit over 17 billion KWH per year - assuming that there is enough water behind the dam to allow for continuous peak output, which is certainly not the case this year.What congress is doing with this bill is no more unconstitutional than the bills prohibiting local taxation of information services. One difference is that instead of limiting what local governements can do, the bill gives more freedom to the local governments (it allows, but does not mandate, municipal ISP's).
The best of both worlds would be where the local goverment provides the last mile connectivity and the individual is allowed to pick their ISP.
I remember a price of $1200 for SCP's 64K static RAM boards in late 1981 - price had dropped to $1000 when I bought my SCP system in '82. Their original RAM was a 16K board.The speed of the SCP (processor and 8" floppy) was impressive compared to the original IBM PC.
Ripped off the user interface - WTF are you talking about??Copying an oldfile to newfile in CP/M: A> PIP newfile oldfile (may be missing some characters)
Copying an oldfile to newfile in 86-DOS: A: COPY oldfile newfile
The 86-DOS command for deleting a file was ERASE
86-DOS used BATch files, CP/M used SUBmit files
The API for QDOS/86-DOS was by design a close copy of CP/M's API, specifically to allow for translation of CP/M code to 86-DOS code. The concept of File Control Blocks were brought in for the same reason (most, but not all, data structures matched). 86-DOS also emulated using a jump instruction to use an OS call, which then executed a software interupt (21H).
There were some significant differences between 86-DOS and CP/M. One is the lack of an IOBYTE in 86-DOS. Another is that the file sizes were known to the byte and not to the block size. Disk reads and writes could be done in any size from 1 byte to 64KB. CON, AUX and PRN were treated like files.
Anyway, calling 86-DOS a rip-off of CP/M is pretty much like calling Linux a rip-off of Minix. And if you're talking about UI, CP/M is probably more of a rip-off of RSX-11 then 86-DOS was a rip-off of CP/M.
You're probably correct in that UFS could be patched to swap bytes when needed. OTOH, Sun seems to be committed to using ZFS as their file system of choice and they also seem committed to having ZFS ported to other OS's (e.g. MacOS and FreeBSD). In addition, ZFS seems to be more rigorously defined which suggests that different implementations will more likely be interoperable than currently is the case for UFS.
The hell with the full C compiler, when are they going to, by default, a full Cobol compiler??? Or a Pascal Compiler (especially one with MS-Pascal and Turbo-Pascal emulation???If you're going to feed the trolls, you might as well go hog wild...
There was a Slashdot article a while ago, where one of the Linux kernel developers (Alan Cox?) was critical of the way ZFS changed layering in the file system code. ISTR the retort being that ZFS was still layered, but in a significantly different way than the Linux VFS code.
I wonder how hard it would be to port FreeBSD's port of ZFS to OpenBSD? If that isn't too difficult, ZFS would be the preferred solution (at least with MacOS 10.5).
My original point was that it was cheaper to make the mobo for the 486 than for the 386 because you didn't need the co-processor socket and could get by without a cache on the mobo. By "cheaper", I mean the cost of the motherboard before the processor and main RAM is installed.
I seem to recall a price around five grand for a 10MB hard drive ca 1978. Whether my memory was correct or not, hard drives were not cheap - which is why a 4GB filesize limit looked like infinity back in early 1980.
An example of compatibilty problems, UFS drives formatted on Solaris/Sparc are not readable by Solaris/x86 due to byte order in the data structures. Fortunately, Sun realized that mistake with ZFS - the byte order is determined by the machine that formatted the drive (zpool), but the ZFS driver will swap bytes if needed.
One hurdle was that SCP had already distributed 86-DOS to Lomas Data Products prior to the sale of rights to MS (see the LDP ad in the June 1981 issue of BYTE). In order for IBM to have exclusive rights to MS-DOS, they would have had to have MS negotiate with both SCP and LDP about using another OS for their machines and that would have ended up costing a lot more than the $50,000 that MS paid SCP for 86-DOS. As part of the sale of 86-DOS, SCP got royalty free access to MS-DOS and MS programming languages for CPU's sold by SCP.Related point, work on 8086 support at MS started because of SCP - MS Disk Basic was running on SCP hardware in November 1979.
Excellent point. Even for a home user, the data on the drive is far more valuable than the drive itself! Whoever mod'ed your post as flamebait obviously has problems with reading comprehension.
When Tim Paterson first wrote QDOS, he thought that four bytes would be more than enough for file size (10MB hard drives cost several grand at the time) and that also happened to fit in with a 4 byte data element in CP/M's file control block. At least we weren't stuck with the bit-map from CP/M.IANAL, but I think he be in trouble only if the key was deleted after he found out that there was an investigation.
OTOH, you might have some fun with a CP/M formatted disk - say an 8" or 14" disk from the 1980's with some rare interface.
What made the business case for the IBM PC was Lotus 1-2-3, which was written specifically for the PC. What helped the clone market was that the IBM PC design was pretty generic, allowing for relatively easy cloning.
As for AMD's market share in 386 systems, it doesn't take much to force a change in Intel's pricing. FWIW, 486 motherboards were cheaper to build than 386 motherboards - the 486 had onchip cache and didn't need a numeric co-processor.
Ca 1991, 386 boxes were a lot cheaper than 486 boxes in part due to AMD selling 386's.
Remember, back around 1990, IBM and Compaq system prices were pretty close to what was being asked for low end HP/Apollo, Sun and MIPS boxes. Now if DEC had been more agressive with the pricing for Alpha and Ultrix...
Sun still uses serial ports on their Sparc workstations (e.g. Ultra 25 & 45) as one is used as the console port when running headless.
One final note - serial ports are still useful for connecting to embedded devices as the protocol can be much simpler than USB. Or for that matter, USRobotics Courier modems (the T-1 connection for my worksite is administered remotely using a couple of Courier modems).
While I don't recollect the exact name of Gate's and Allen's first company, I do remember they were using an 8008 as part of a system to record traffic data (this would be ca 1973).
BTW, wasn't Traf-O-Data the first foray of Gates and Allen into the biz world???
The nice thing about Circuit Cellar is that Steve Ciarcia chooses what to put into the magazine based on his passions and not the current fad. He has another advantage in that most of the advertizers are of interest to the readership.
Or how about Sol Libes rag, Microsystems?? That faded away a couple of years before Microcornucopia. A really old timer was Interface Age, which, IIRC, folded ~1980.