Many of them are. Others are just economies of scale. Consider disdk formatting. If you look at MB/S then today's drives are MUCH faster. If yuou look at "how long does it take to format this new drive", then the answer is about the same. In this case it is a pure hardware/physics issue... [3 drives formatted...2 to go...then the install]

David> Others are just economies of scale. Consider disdk David> formatting. If you look at MB/S then today's drives are MUCH David> faster. If yuou look at "how long does it take to format this David> new drive", then the answer is about the same. Why would you format a drive, in the sense of writing all the blocks? There is no longer any such thing as a "low level format". So unless you're desperate to get rid of the manufacturing test pattern, you might as well do a 30 second "quick format" to initialize the file system. paul

On Thu, 24 Mar 2005, Jim Leonard wrote: Very simply, Boyle's law (software expands to use all available resources) outpaces Moore's law (performance doubles every 18 months) -- Grumpy Ol' Fred cisin at xenosoft.com

In message <1111749690.3827.11.camel at weka.localdomain Jules Richardson <julesrichardsonuk at yahoo.co.uk> wrote: Mostly delays. The Award BIOS, for example, gives the hard drives 5 seconds EACH to initialise, plus another 5 seconds for the controller to initialise. If there's nothing on the IDE/ATA bus, it takes 25 seconds (or sometimes longer) for the BIOS to finally decide that there's nothing there. Then there's PnP initialisation and all the insane power checks. Some BIOSes take an average of the supply voltages over the course of 3-7 seconds... Um... Server for thin client? Ghost has this rotten tendency of falling over without erroring out, scrambling the destination drive in the process. You don't find out that the copy failed until you try and read from the destination drive. I've had much better luck with "dd if=/dev/hda1 of=/dev/hdb1 bs=32M". The partitions don't even have to be the same size - run resize.reiserfs (IIRC) and/or FAT Resizer after the clone and the inodes/FATs/superblocks are updated to match the new partition geometry. In my experience, the BIOS memory checks are worse than useless (false sense of security). The only surefire RAM check is MemTest86 left for a few hours in "burn in" mode. I guess you're using Linux or BSD then. [fx: checks headers]. Hmm. Ximian Evolution. That'll be Linux with GNOME then. [fx: Brrrr-Bip!] Acorn MOS Acorn 1770 DFS BASIC Gotta love the BBC Micro.. a boot time of less than a second, 1MHz Bus port, User port, onboard floppy controller, printer port, RS423, and a 6502 CPU. The height of expandable hardware (ignoring, perhaps, the Apple II, but I've never even seen one of those so I can't really comment). I would however like to get an Apple II for my collection (or what I laughably call a 'collection'), assuming my Microvitec Cub653 can sync to its video output. If it's standard PAL- or NTSC-resolution RGB, it should only be a case of bodging up an adapter cable. Later. -- Phil. | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB, philpem at philpem.me.uk | ViewFinder, 10BaseT Ethernet, 2-slice, http://www.philpem.me.uk/ | 48xCD, ARCINv6c IDE, SCSI ... File not found. Should I fake it? (Y/N)

It was thus said that the Great Jim Leonard once stated: I've found that compiling the Linux kernel to be an excellent test of a system. -spc (And if GCC failed compiling the kernel, it was almost always a sign of bad memory ... )

On Fri, Mar 25, 2005 at 05:47:56PM -0600, Jim Leonard wrote: Of course you can't. It only tests a limited set of patterns - those which are expected to be best for triggering faults - but it simply _cannot_ test all possible patterns. memtest86 is a positive only checking tool: it can only detect the presence of memory errors, but cannot prove their absence. Especially since there are some rather "interesting" failure modes for memory cells. Usually compiling a very large software package under Linux is a good memory stress test for finding faults. Traditionally, one used the full Linux kernel compile run for that, but nowadays I would also add a full compile of OpenOffice to that. If any SISEGVs are being thrown during compile, then the memory is highly suspect. Regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison

I would have to say it was the lab's PDP-8 back in the mid 70's. Boot was 1) Toggle in RIM Loader Bootstrap 2) Load RIM Loader Paper Tape 3) Load BIN Loader Paper Tape 4) Load FOCAL Paper Tape 5) Load Application Paper Tape All from a good ol' ASR-33....

The version I heard (from MVW himself, no less) was that you had to climb stairs between the room where you punched the tape and the room where EDSAC itself was (and therefore where you took the tape to read it in). After going up and down stairs a few times, he invented the idea of an interactive debugger. -tony

On Fri, 25 Mar 2005 12:33:51 +0100, Jules Richardson <julesrichardsonuk at yahoo.co.uk> wrote: Most old computers I used had power-on sequencing and testing of some kind, but it never amounted to a significant part of startup time. Typically less than half a minute, I'd say. The boot time was highly dependent on how much stuff they had to get loaded before the system was useable. Our HP-3000 would get drives ready, journals checked, MPE and databases loaded and terminals ready to use in about 20 minutes. The 260/50, on the other hand, would need some 45 minutes for a full IPL. That was until IMS and TSO/ISPF was available for us poor users. -- -bv