On February 13, 2002 11:46 am, Bob Pawley wrote: > With a proprietary system the trouble-shooter knows the fundamental nature > of the program can not be changed so he is perfectly comfortable standing > on that knowledge. Not so with an open source system. > One of the posts indicated that Linux is structured and organized by the > distributor and the core programs are not touched unless absolutely > necessary. Who makes this decision, The guy on the site?, His supervisor? > The president of the company 5,000 miles away? How is this software > structured by the distributor and never touched, so much different from > proprietary software?

Since you based your comparison on Linux ("open source" is not synonymous with Linux), we'll discuss an example based on that. Linux is an operating system, not an application so we'll compare it to a proprietary operating system such as Windows. I'm not trying to suggest that there is anything wrong with WIndows, but it makes a good contrast.

Firstly, there is nothing to prevent someone from changing some very fundamental features of a system using Windows. Drivers and other such software can be changed for different ones whether they are proprietary or not. There are also lots of utilities which modify the behaviour of Windows, supposedly to make it more "crash-proof", or faster or other such (usually imaginary) benefits.

Secondly, Windows comes in different versions with different service packs. There is nothing to prevent someone from installing new service packs whose side effects (and new bugs) have not been tested in your application.

Thirdly, Windows' publisher (Microsoft) changes Windows all the time, and they won't ask your permission (or even tell you) before they do this. It is very unlikely that two supposedly "identical" installations conducted some time apart will in fact use the same software version.

A similar case can be made for most other types of software. Unless you are installing the software off a common set of CDs (which can be contrary to the software licensing), you are not going to have truly indentical systems.

Do you have anything with DOS in it? I believe there are open source versions of DOS around. People can hack away at that. People used to hack DOS even without source code. They used a debugger (included with DOS!) to patch the executable files directly in machine code. People used to publish these hacks in magazines and books, so you didn't even have to figure it out for yourself.

We've got proprietary equipment with special EPROMs containg firmware modified just for us. It's easy to get this when you are dealing with proprietary systems. You just give the OEM a spec and some money, and they'll do a new EPROM for you. When you order the hardware again, you just specify the EPROM version you want. This can be better (and cheaper) than a completely custom system if there is nothing on the market that does what you need. So there's no guarantees that the firmware is "standard", even if it is burned into EPROM.

Hacking isn't limited to software either. People used to (and probably still do) hot-rod 8032 based systems by installing chips which have a shorter execution cycle. This can upset various critical software timing loops. Do you pry the lid off all your hardware to see if anyone has been doing this?

Regardless of the talk you may hear of people "fixing" or modifying Linux, all except a very small number of people just stick the CD-ROM in their computer and run the software as is.

I have a very good idea of the reasons for keeping equipment to a common standard. But it can in fact be very difficult to do this with proprietary systems. If the manufacturer discontinues the current version (e.g. Windows), then you cannot (legally) continue copying the old one until you are ready to change.

I was involved in a meeting on Tuesday in which we were discussing a new machine (a standard design) we are considering buying. The machine included a "panel" type PC which ran software written by the machine OEM for MMI, parameter handling, and conducting certain critical process calculations. The operating system is Windows NT4. The machine OEM has spent several years developing this new product, and they are just beginning to make some significant sales.

One of our people mentioned that Windows NT4 is a discontinued product. Upon hearing this, the machine OEM representative looked shocked, and began cursing something to the effect of "you just get the lastest thing working, and you have to start all over again" (to put it mildly).

I can sympathise with him. They just want to get their new product into the field without having to worry about operating system compatability. They want to keep selling the same thing for years to come. If we buy a machine now, we want to be able to buy exactly the same machine again in the future. This part of the machine however, is out of their control.

The operating system is proprietary. However, it isn't proprietary to the machinery OEM - it belongs to someone else. What should this OEM do? They really don't want to get into the software business and start writing their own operating systems.

So how do they get something they can have some control over? I suppose they could use Linux. Nobody is going to cut off their supply of a particular version of that. They can keep using whatever version they like, completely unaffected by anyone's change in sales strategy, corporate merger, divestiture, bankruptcy, or anything else. That sounds pretty close to what the advantages of a proprietary system are supposed to be.:

 ************************
 Michael Griffin
 London, Ont. Canada
 ************************

Your house analogy is well taken and goes a long way to clear up some of the misunderstanding about "open" technology. But the problem I see is that home building is described in sets of established codes and automation isn't.

For instance, every lumber manufacturer knows 2X6 dimensional lumber is used in building, every electrical manufacturer knows if they build to UL specs they can sell their products, every plumbing manufacturer builds fixtures that connect to standardized pipe sizes, you start to get the picture.

Where are the codes and standards in automation that can allow this type of open technology to work? Isn't this where it all has to start?

Alan Brause