A lot of the machines in my shop do little but shovel stuff between a hard disk and an ethernet port perhaps by way of a web and/or sql server. Keyboard, mouse, vga, usb, parallel are all distractions to the main task.
My ideal motherboard would have a single ethernet connector and be POE powered. The official POE standard supports only 13.5 watts and I want to be able to spin one of the larger hard disks available so I am prepared to accept a second 12v. power connector which implies an internal inverter.
The BIOS would support only PXE boots although the image of a functional machine is on the hard disk. The normal boot sequence would load a boot image off the hard drive while a "special" image could be loaded to test the hard drive and reload a fresh image. This would be accomplished from a workstation on the network.
Physical configuration would be like slices with vents on the long edge and resting on an external fan. Each slice would have two connectors on the front, power and RJ45 jack.
I suggest such a system would be a vast improvement over all the blade designs in existence.
Although Edsger is remembered for the article on the goto, his development of the stack model was an evolutionary leap in the development of computers.
Every computer made today embodies his model. Interrupt handling, recursion, reentrant programming, multi-programming, multi-processing, virtual memory all come out of Edsger's model.
I had the great fortune to work on a Burroughs B5500 and later the first B6500 that made it out of manufacturing. This entire series of computers was based on Edsger's model and his Algol 60 compiler.
Tony Hoare may have put it best when he quipped "Algol is an improvement over all its successors".
Certainly Edsger was an improvement over most of his successors.
The number of heads and track density has a profound affect on seek accuracy. Over time the positioning of the heads will diverge relative to each other and thermal recalibrates only make things worse.
3 platter IBM drives are as reliable as any other; 4 and 5 platter drives at high track densities pushes the envelope.
What amazes me is the neglect of SMART. Hard drives don't last forever and it is very helpful to spot the ones that need attention first.
The hard drive story was too superficial to guide others properly.
I had a lot of fun with Dynamicube from www.datadynamics.com. I applied it to 6 million record files with up to 10 dimensions. Wish I could find the same for Linux.
There are several datacube efforts, some in actual practice which are not labeled as such. One is analog which builds a datacube from httpd access logs.
Once one has well defined categories, all it takes is to add one dimension for the sum, form the cartesian product of the categories and sum all the combinations of the zeroth member in each category. The process is reversible so that records can be added and deleted.
It can also be generalized to more than sums and there are some parallels to n-dimensional correlation matrices.
The problem gets a bit nattier when the data is sparse. I suppose an index of keys would ameliorate the problem
I would be willing to help in such an effort and can help lay out specs.
Slashdot Mirror
My ideal motherboard would have a single ethernet connector and be POE powered. The official POE standard supports only 13.5 watts and I want to be able to spin one of the larger hard disks available so I am prepared to accept a second 12v. power connector which implies an internal inverter.
The BIOS would support only PXE boots although the image of a functional machine is on the hard disk. The normal boot sequence would load a boot image off the hard drive while a "special" image could be loaded to test the hard drive and reload a fresh image. This would be accomplished from a workstation on the network.
Physical configuration would be like slices with vents on the long edge and resting on an external fan. Each slice would have two connectors on the front, power and RJ45 jack.
I suggest such a system would be a vast improvement over all the blade designs in existence.
Although Edsger is remembered for the article on the
goto, his development of the stack model was an
evolutionary leap in the development of computers.
Every computer made today embodies his model.
Interrupt handling, recursion, reentrant
programming, multi-programming, multi-processing,
virtual memory all come out of Edsger's model.
I had the great fortune to work on a Burroughs B5500
and later the first B6500 that made it out of
manufacturing. This entire series of computers
was based on Edsger's model and his Algol 60 compiler.
Tony Hoare may have put it best when he quipped
"Algol is an improvement over all its successors".
Certainly Edsger was an improvement over most of
his successors.
Jim Tarvid
I love SlashDot but...
The number of heads and track density has a profound affect on seek accuracy. Over time the positioning of the heads will diverge relative to each other and thermal recalibrates only make things worse.
3 platter IBM drives are as reliable as any other; 4 and 5 platter drives at high track densities pushes the envelope.
What amazes me is the neglect of SMART. Hard drives don't last forever and it is very helpful to spot the ones that need attention first.
The hard drive story was too superficial to guide others properly.
I had a lot of fun with Dynamicube from www.datadynamics.com. I applied it to 6 million record files with up to 10 dimensions. Wish I could find the same for Linux.
There are several datacube efforts, some in actual practice which are not labeled as such. One is analog which builds a datacube from httpd access logs.
Once one has well defined categories, all it takes is to add one dimension for the sum, form the cartesian product of the categories and sum all the combinations of the zeroth member in each category. The process is reversible so that records can be added and deleted.
It can also be generalized to more than sums and there are some parallels to n-dimensional correlation matrices.
The problem gets a bit nattier when the data is sparse. I suppose an index of keys would ameliorate the problem
I would be willing to help in such an effort and can help lay out specs.