If it really is isolated (what the heck are you making that doesn't talk to anything else?) then the VM you talked about is a starting point. Next comes the challenge of tracking it: You have to keep enough copies that you don't lose it, but you also have to keep track of which copy is authoritative so that the bug fix in year 12 starts from the bug fix in year 7, not the bug fix in year 3.

Anyway, you need to keep a living memory of the project. If it goes into dead storage there probably won't be enough findable documentation to resurrect it. This means that at all times there must be someone employed by the company which has touched it before.

So, set aside a staff day every single year, paid up-front by the customer, to literally boot the VM, run a re-compile and send a report to the customer certifying that it was done. Any further apart and you'll lose the living memory of the project.

Hardware is your other foe. I don't know how you move the software compiled software image to the embedded hardware, but if it's a small-run product it won't be around in 5 years, let alone 25. RS232 serial has been remarkably resilient but few of the other popular communications hardware interfaces have survived 25 years. Scsi? Gone. IDE? Gone. Ethernet? The form that existed 25 years ago is gone, hard even to find on the second-hand market.

I'm morbidly fascinated with this concept of systemd subsuming the kernel too.

Statistically, System A. System B is still an infant. Huge infant mortality rate for systems. Those that survive tend to live to a far too ripe old age.

A Masters of Business Administration is -the- generic degree for folks who want to be middle-managers. You generally add it to a technical bachelors degree in whatever field you'd prefer to be a manager and the add things like PMP certificates depending on the kind of management you want to work.

Unfortunately, if you really wanted to be in the technical side of the work, an MBA is a bit of a hobble since it also screams of a dilettante's interest in the technology.

Howdy,

If you want useful advice, you have to tell us more about what the embedded system you're targeting is intended to do, how (if) it interacts with other computers, how the software is installed on it once built, and so forth. Replicating the the original build system may or may not be a successful strategy depending on such details.

Put another way: my advice is that you haven't yet asked the right questions.

Unless the software is for a purely standalone system you have several more problems to figure out:

1. Every dependent library you use has one or more security flaws which will be uncovered in the next 25 years. The fixes won't be backported to your current environment.

2. IPv6 will have replaced IPv4 within the next decade, but it probably won't work the same as IPv6 available now does. 25 years ago IPv4 was "classful" and DHCP did not exist. You will need to be able to link against the network stacks available 5, 10 and 15 years from now.

Like the other guy said... pick a language that hasn't deprecated anything of consequence for at least a decade yet is still strong and widely used. C is a good choice. Python code weathering 25 years? Don't make me laugh.

If it were just the support issue there might be things you could try, but the only thing you can do about vendor incompetence is find another vendor.

Were I the sysadmin, I'd have told you to either provide your own complete python environment as a part of your request (python is good about this) or rebuild you software to match the available system python environment. Asking for changes to the system python environment is begging for trouble when the next user with a python program comes along.

Your expectations were out of line, and God alone knows what damage sysadmin #2 did trying to accommodate them.

Directly answering your question: I don't think you know nearly enough to assess whether sysadmin #1 was incompetent.

It was written in Java. The program caught the exception and moved on.

If your receiver beeps, interrupting the caller, then somebody did a lousy job setting up your Cisco phone system. They don't normally do that.

Not in any modern business phone system. Line 2 lights up, the caller id appears and the phone rings. There is no beep beep beep in-line on the call. Beep beep beep happens with residential and obsolete phone systems.

It isn't; it's applied by an Israeli company against a U.S. company, github. It doesn't matter where github's customer is located, the take down notice is applied against the hosting company.

The put-back notice, should the gentleman in India choose to issue one, is also applied against the hosting company, in the U.S.

You can't merely ignore a takedown notice but there are a number of things you can do instead of complying if you believe it to be in error. The only thing that happens with refusal is that -IF- the material is later judged by a court to be infringing, you -might- be subject to damages for your refusal. That seems rather unlikely in this case.

I have no idea what you mean by "pay the money to appeal against it." How do you think DMCA takedowns work anyway? It's just a formulaic letter, not necessarily even from a lawyer.

As long as half the CS grads insisting on trying to become game developers, the game industry will have no trouble continuing to abuse them. If your computer science dream is to write cool games... give up early and get a job where your peers and bosses pay you well and, in many cases, respect you too.

I periodically hear that claim. One variant is that when someone posts spam on the list a lot of folks supposedly mark it as spam, causing the list itself to lose reputation instead of the spammer.

I've not seen data to either support or refute the claim, though I have to concede it's possible. On the other hand, I'm a bit jaded about it since I most heard the claim in connection with a particular single-opt-in political list that I knew to have bogus addresses due to the lack of confirmation.