It may be analagous to a US Design Patent.

Of course it's possible. My company does it all the time. There are several effective methods, the simplest being putting a jumper on the write-enable pin of the device that holds the firmware, and the removal of that jumper before you ship.

It may be an effective component to your total bug strategy, but it should be the last on the list. The primary effort should be oriented to not releasing the bugs to begin with.

Let's say I create an adversarial system in my company. I pay developers a base salary plus an at-risk bonus for delivery of software QA by the deadline. If they deliver before the deadline, the at-risk bonus increases.
QA has base salary plus can earn that at-risk bonus by finding the bugs between when it's delivered to them for analysis and the delivery commit date. Developers have incentive to deliver bug-free code, because that maximizes their bonus. QA is incentivized to find all the bugs, because that maximizes their bonus.

A lot of other posters have focused on other aspects of the workplace and opinions are all over the place. As a manager with a few years behind me in that role, I want to focus on one of the last areas you mentioned: HR and corporate.

They're the developers that do the actual work that makes money. Your job is to enable and encourage them to do that efficiently. (This goes for every other kind of productive work too, whether it's developing code or manufacturing widgets.) So there's time management and making sure they're on task but one big thing you can do is INSULATE THEM FROM CORPORATE BULLSHIT. Dealing with the bullshit is YOUR job. As much as possible, you keep it from affecting them and their work. If they are more than vaguely aware of HR policies, that's usually you not doing your job.

Another aspect is to insulate them from each other's bullshit so they don't detrimentally affect one another's. Sometimes that's necessary, especially if you have one or more primadonnas on the team.

To make reviews not suck (as much):
1. Keep a log of the assignments you give each person, the times when they agreed they would be done and when they actually were done and the quality of their work.
2. Most corps will make you or them define "goals" each year. Make sure those goals are in line with what they should be doing anyway. Have frequent meetings with them either as a group for group goals or one on one for individual goals and ask them about progress. Provide a sounding board about them.
3. Come review time, you will have a list of the things they accomplished, an assessment of how well they did them and how timely they were and their goals will either have been accomplished to your satisfaction or you will already know the reasons why.
4. When there are problem behaviors, talk to your devs about them right away. Never leave them to review time.

The review is then mostly just a summary discussion of the stuff in your log, unless they were a problem. You identify the qualities that helped them get their work done and any problem behaviors that came up repeatedly. Compliment them on their good behaviors again as you should have throughout the year. Summarize by saying how they're doing relative to your expectations. (Not relative to other team members -- they can all be doing great or they can all suck.)

At a lot of companies HR will require you to fill out some form that addresses behaviors and goals. You have to do that, and you have to nominally discuss it with your employees. But keep that as terse as possible and then put your real assessment in the overall comments area or on an attached document. Make it clear that what's important to you is not the HR form but what they do every day, that their actual work is valuable to you and the company.

Roots are usually included in the term "vegetables."

Yeah, it's true that modern people have some adaptations due to what they call "niche construction" which appears to be a fancy term for "agriculture" + "cooking" when it comes to diet.

For example, most modern people can digest milk, whereas our paleolithic ancestors mostly couldn't, and some populations of humans have developed heightened tolerance for carbohydrate-heavy diets that probably would have given our paleolithic ancestors diabetes. They still do that to many people today.

And the fact that we can tolerate foods our ancestors couldn't doesn't necessarily mean they're better for us than the kinds of foods they ate are for us. Humans never lost the ability to digest meat, fish, fruit and vegetables. All evidence shows that a diet heavier in fruits and vegetables with some fish and meat (not as much as most Americans eat) is optimal, and whether you attribute that to the adaptations of two million years of evolution or not doesn't really change the bottom line.

If you include fruits, it's pretty damn close to true. People didn't start eating grains in significant quantities until about 10000 years ago. Before that nearly 100% of their diet consisted of fruits, vegetables and meat (including fish). Humans became "behaviorally modern" about 40000 to 50000 years ago. So it's clear that a diet containing no grains can be nutritionally adequate for modern humans.

The only net benefit of eating grains and processed foods is that they're a cheaper way of fulfilling your caloric requirement but arguably they displace higher quality foods.

It's irrelevant that some people are allergic to milk; some people are allergic to any food you can name. Milk is a high quality food for people that can digest it.

That sounds like an argument for shipping purified methane or some other liquid fuel from Earth.

Do you get enough extra delta v from converting 4 kilos of hydrogen to 16 kilos of CH4 to make that worthwhile?

The same issue is a challenge to internal combustion engine design and a number of other applied physics problems. Combustion is a chaotic process and thus a hard challenge for computational modeling. Developing better simulators for combustion would reduce the cost of developing reliable and safe systems.

That's not even the hardest problem they're up against. Generating fuel on Mars is a much more difficult one. As far as we know, there may be no way to produce or find and mine hydrocarbons such as methane. Mars's atmosphere lacks significant hydrogen content. If there's subsurface minable water, that could solve the problem, but only if there's plenty of it.

Only if one is not intent on running Windows ON A MAC. It's to be presumed that you wouldn't run Boot Camp if you just wanted to have a system that runs Windows.

If you must run Windows on a Mac, is there a problem with running it in Virtualbox instead of Boot Camp?

The idea of virtual water is superfluous and somewhat silly. There's a real water shortage, so there has to be prioritization. Market pricing of water makes sense as part of the solution. But first you have to answer the question of who owns it in the first place. Maybe the State owns all the water rights and creates the market? Water law in the west is a mess.

How much does it cost for the password?

True. Electrical engineers usually know more about information technology.

That's not bullshit. They really are to some extent different occupations. The guy that designs power grids for a city can't necessarily design an IC and doesn't need to. To him, ICs are components that are on circuit assemblies that are inside systems that he cares about. The IC designer likewise doesn't need to know how to design a power grid. He doesn't even need to know when to use a Y vs. a delta transformer. In fact, he never uses transformers, except to couple RF signals onto the test boards for the ICs he's designing. Power comes from a regulator chip for him, not from a gas-fired generator.

But you get the same nominal degree to do both jobs.

Here's actual data from the BLS:
17-2060 Computer Hardware Engineers broad 77,670
17-2070 Electrical and Electronics Engineers broad 303,450

But the 17-2060 and 17-2070 categories mostly have BSEE degrees, some of them also holding MSEE and PhD's.

Then there's the software folks:
15-1130 Software Developers and Programmers broad 1,442,500
15-1140 Database and Systems Administrators and Network Architects broad 618,480
15-1150 Computer Support Specialists broad 706,360
15-1190 Miscellaneous Computer Occupations broad 196,280

So yeah, there are a lot more people doing software. It figures. A relatively few people are required to figure out how to make electrical and electronic hardware. A lot of that hardware consists of programmable machines that can in principle be programmed to do anything. Naturally there are more things to do with computer hardware than there are needs for different kinds of electronic hardware.

Perspective: I'm an electronics engineer and manager of several of the same. We're staying busy.