It depends on the way the "stabilizer" works. Most just blank out some lines while some might actually replace the whole sync signal which is what you want.

Macrovision is record only.
Professional VHS and/or S-VHS recorders actually had a switch where you could turn of the Macrovision AGC so those never were a problem.
Such professional VTRs are now available fairly cheap, even the ones with little use. I'd gravitate towards an S-VHS one since they are able to play VHS, and they provide the S-Video output for no cross colour.

Well but iOS for the iPhone x is a different image than iOS for the iPhone y. The same goes for Android. That's why the manufacturer decides which devices get updates and which don't.

Yes and so is USB, the question is, will the controllers for it be the same?
There is some pressure for such standards from the ARM-hosting crowd, since ARM based servers would fill a very interesting niche in the market.

Something that already exists on the PC. You can trivially boot up any operating system you want on any PC and the basic things like the display and the input devices will just work.
This is because the PC platform not only has certain basic hardware components standardised, but also because there are interfaces to enumerate the hardware you have. Once you have your kernel in memory and running, it can simply look for the hardware and access the hardware accordingly.

On ARM there is no such thing as a PCI bus. Therefore your kernel needs to be compiled for the very device you want to use it for. You cannot just compile in the most common ethernet controllers into your kernel and expect it to choose the right one. This may work, but very likely your first driver will try to probe blindly for its device, crashing your system, before the second one even has a chance to run.

This is why there are movements to create a common hardware interface, one where you just have a single operating system image running on a huge variation of hardware just like on the PC. Unfortunately the business model of ARM doesn't help here. ARM licenses its cores to many SoC manufacturers. Each one of them hopes to lock in its customers making it deliberately hard to switch to any of their competitors. A common interface would sweep away the borders. You could switch from manufacturer A to manufacturer B just like you can switch from a Dell PC to an HP one.

When people believed you could use a computer without being able to program. That's how mandatory programming courses got shut down and the incompetence "trickled down".

Actually the Nokia 770 was a phenomenal success, despite not being advertised. It spawned 5 successors and the line was only cancelled when Nokia was Elopped. Even then the single remaining product was outselling all of their Windows products despite being only offered in selected markets.

It was the first, and unfortunately the last, mobile device that was actually useful. It was the closest thing to a portable computer you could get.

Actually scratch that, the protocol feature is not suitable for adding noise since it's like a ping. You send some data and it comes back verbatim... that's trivial to filter out as an attacker.

In his paper he admits that no data is necessary.

But wouldn't it make a lot more sense to do this on the application side? There you can easily just add "noise" in any way you want.

I mean keep alive is already done by TCP, a keep alive doesn't need data. Why did this even get into the standard?

It seems like the only purpose for this code was for Robin S. to erect a monument for himself. Again why did this get into the standard?

I mean paper doesn't have to be inefficient, in fact it rarely is since paper based workflows are often optimized. Everybody working with paper understands the process and can therefore come up with ways to optimize it.
I once worked at a hospital which had paper files. It makes sense since the documents in there can be in a lot of different types. The process of dealing with it was rather efficient on the paper side, you had some numbers and got the file with that number from a cabinet. The actual bottleneck was the computer based indexing system. We had something similar to E-Mail called "Outlook/Exchange". We ended up printing out those pseudo E-Mails, looking up each number individually in the indexing system, and writing the number of the file next to it. There was no way of sorting the entries to be able to reach them efficiently, nor was the system well designed. (it had SQL injection bugs!)
This is just one example of how badly designed computer based workflows can be.

Then there is the other point of governments being supposedly less efficient than companies. I have no idea where that idea comes from. I have 2 retirement funds, one run by a private company, the other one run by the government. While the government one manages to pay out millions of pensions every month and flawlessly adapts to any changes in my life, the private one can't even get a simple address change right, twice in a row!

Why should companies change? Companies mainly act to self-preserve. Any change is not just constructive, but also destructive. For a company to change it would need to have a vital reason, without that reason it cannot change.
Some people claim that there is the magic hand of the market which will somehow fix the problem though something called "competition". Those people go on citing exotic areas where their dogma actually worked and there was competition. However look around you. Go to an electronics store with a list of brands that come from the same manufacturer and then look at how many different prices exactly the same product gets sold. If there was competition, everyone would buy the cheapest of the otherwise identical products. There is no competition on many markets.

Such systems are not insecure because they are digital or involve computers or anything. (seriously I doubt the guy even understands what digital and analog means) Such systems are insecure because they are unnecessarily complex.

Let's take the Stuxnet example. That system designed to control and monitor the speed at which centrifuges spin. That's not really a complex task. That's something you should be able to solve in much less than a thousand lines of code. However the system they built had a lot of unnecessary features. For example if you inserted an USB stick (why did it have USB support) it displayed icons for some of the files. And those icons can be in DLLs where the stub code gets executed when you load them. So you insert an USB stick and the system will execute code from it... just like it's advertised in the manual. Other features include remote printing to file, so you can print to a file on a remote computer, or storing configuration files in an SQL database, obviously with a hard coded password.

Those systems are unfortunately done by people who don't understand what they are doing. They use complex systems, but have no idea how they work. And instead of making their systems simpler, they actually make them more and more complex. Just google for "SCADA in the Cloud" and read all the justifications for it.

Yes it did. It was transmitted via USB stick.

Only like the criminals the news likes to call hackers.

I've recently tried both Visual Studio and Eclipse for C. I have to say they are both where Pascal IDEs used to be in the 1990s, though Eclipse is a few years ahead.

However all that is just a part of the environment you develop in. It's more than the editor and compiler. It's also the operating system (in a wider sense) you are developing and deploying in.

It makes a difference whether you have a well structured system in front of you, where you can reach your goal by a series of orthogonal steps, or you have some knocked together system which barely works and is missing essential tools.