Not really. In big systems problems arise which are simply not present in small systems. For instance: a HDD has an average life cycle of (say) 5 years. If you build a system with one harddisk, you could expect (ov average) it to run these five years before breaking. You do not need a certain procedure for changing disks in this case. You simply take the risk of having one unplanned outage every five years.

Now suppose you have a system with several TBs diskspace and hence (again, say) 300 disks attached to it. Since all of them have a life expectency of 5 years a disk failure will happen on average every 5yrs/300, which is about once every week. In this case you need a procedure on how to change disks while the system is running or risk one unplanned outage every week.

This is why a Mac with a G5 processor costs only half as much as an Intellistation from IBM with the same processor - the difference is not only IBMs surplus factor (that too, but not only that), but also many features to make operating a data center with some thousand Intellistations *possible* (as opposed to "a complete nightmare"), unlike a datacenter with some thousand consumer-grade MacFrags with a nice design and nothing more.

This principle can be extended to software as well, but there is even another point: software is expensive to develop and cheap to sell. That means writing a program costs some effort while selling a copy of it costs nearly nothing. Hence, when you build software for some outlandish platform where you don't expect to sell many copies the price will be relatively high (very high in some cases), because it is the same effort to write the OS and sell it 100 times as it is to write it and sell it 100.000 times. Maybe the UNIX you say was some realtime OS (most Unixes aren't real-time at all) or for some extremely rare hardware (massively-parallel for instance?) or something such.

bakunin