*BSD as a "main driver" for average users

This is cheating as you can rewind and replay it at your leisure to catch all of the things that are going on in the imagery. In the actual product, if you "miss something", it's gone -- enticing you to watch and wait to see if it appears, again.

I helped design marine radios for about 9 years. Product support was provided by whomever the switchboard directed the phone call. I made the mistake of passing out business cards at a boat show, and was soon cursed with a deluge of support call from out dealers. It wasn't fun, but having the engineers talk directly to the dealers, and sometimes the customers, was a good way of connecting the engineers directly to problems encountered in the field. My only complaint was the general lack of "service notes" documentation, which would have reduced the number of repeat calls. (Note: This was in the days of BBS's and well before the internet).

Anecdote: After the introduction of a new product, we typically received numerous calls from dealers over "repair" issues. However, one product had the service manual delivered about 3 months after the products were shipped. Initially, there were very few phone calls from dealers or customers. After the service manuals were shipped, we were buried in a deluge of phone calls from dealers and customers attempted to tune, repair or install their radios.

At the time, it was impossible to sell radios in the commercial marine radio sector without a lifetime warranty. We tried to make "evolved" replacement PCB's so that they were plug compatible with the older models. We had several such replacement PCB's where an IC and a few parts replaced a board full of discrete components. Fortunately, the rest of the industry realized that a lifetime warranty would eventually turn into a liability. So, we switched to a limited warranty and lived happily ever after.

I did hardware, not software. It was not beneath my dignity to reverse engineer the competition, improve the design, and use it for a new product. That's much the same as your "cut-and-paste" code example. I infringed on someone's patent only once in 9 years.

Ok, but that's hardly "cut-and-paste". It's more like "cut-paste-analyze-modify-etc".

It's ok to borrow code from anyone and anything as long as it's not your own code? Did I get that right?

Incidentally, I was once ordered to clone a radio that they were private labeling. There were several circuits which were marginal. I asked if I should fix these. The answer was a thundering no. They wanted an exact copy, bugs and all. I asked "why" and was ignored. I followed instructions, but wasn't very happy. Eventually, I couldn't stand it any more. I went to the president's office and ask him why I was copying a radio that didn't work. He said it was to prove to the manufacturer that we were able to copy the radio. If they wanted to continue the private labeling arrangement, they should lower their price or risk competing with one of their major customers. I thought about the situation for 2 days and submitted my resignation.

I'm thinking 1980s and some of the 1990s.

MVT never appeared in my world. I'll have to look into it. May be that it was trapped on expensive IBM in the era where UNIX was emerging.

Joe

MVS, iirc.

Cheers

Phil Hobbs

MVT was the predecessor of MVS. MVT dispatched the highest priority ready task (IBM speek for thread). All batch, single core/CPU, 24 bit address space. 29MB disk drives.

No interactive access, no timeslicing, just interrupts.

Later evolution added interactive access (TSO), multiple cores/CPUs, virtual storage. 31 bit address space, 64 bit address space.

And name changes: MVS, ..., now z/OS

Documenting a product (especially if you had no role in its design or development -- or, "aren't technical") is a delightfully challenging experience!

You've never *used* the product yet have to imagine how someone would use it and what sorts of questions they would ask. Then, sort out how to organize the documentation so THEY could find it. (creating an index is doubly challenging as you have to think of the various terms one might search for regardless of what *you* have chosen for the lexicon).

Then, you have to decide how much you WANT the user to know as that can encourage and discourage efforts in directions that you may or may not want to support. Tell him the pinout of a connector and now you're likely to field questions about folks wanting to (ab)use it for some unforeseen purpose -- and, angry when they can't do what they want with it because you neglected to _____.

You just have to be creative about defining "lifetime". I offered clients "free bugfixes" -- but, only while I kept the business open.

I started off doing mainly hardware (designing CPUs) but quickly found that you can design hardware in a few weeks that would take months or years to crate the software that would run on it.

And, the more clever/inexpensive the hardware design, the more you migrated into the software so a small (time) savings in the hardware design could end up dramatically increasing the "cost" of the software.

Now, I find I can write code to emulate things that I would have wanted in hardware as machines are fast enough that the "emulation overhead" is negligible (and saves having to go to a foundry to roll some custom silicon).

I always left an "out" in contracts indicating that I would never knowingly infringe on a patent -- but, the liability for any such infringement would lie entirely with the client. (you want me to make guarantees? then factor in my retaining a patent lawyer on your behalf but without your control!)

No. The "cutting and pasting" happens entirely in my head. "This is how I approached this problem. Is it -- or something similar -- appropriate for this NEW problem?"

So, I always had to recreate functionality from scratch.

But, *writing* code takes very little time. *Designing* it is where you spend your time and effort. And, once you've designed a particular functionality (model), you already have learned the important issues to address as you reimplement it (in a different language, API, target platform, etc.)

I don't use anyone's code in my products/projects. My copyrights are "clean". (I may use someone else's *product* in a design but then it is subject to THEIR copyright).

We had a japanese company tour our facility early in my career. Folks were excited when they decided to purchase (25?) radars. A year later, we bought one of THEIR radars to see that it was "inspired" (I don't want to say "copied") by ours. It was interesting to sese the changes they had made to the design and slap ourselves over how obvious some of the ideas were -- yet we had missed them!

For example, we had a multislotted encoder wheel to monitor the orientation ("azimuth") of the antenna. This was affixed to the antenna shaft. *They* had a cheap, crude "few slot" encoder on the upstream side of the gear reduction assembly exploiting the fact that the reduction effectively magnified the resolution of the encoder letting the cost and complexity of their encoder be peanuts.

"Gee, why didn't WE think of that?!"