How do you figure? Write to ram is a whole lot faster than write to flash, especially if the flash block has to erase first.

Every write, not every read. Reads are satisfied as soon as either drive returns the data. And if the raid controller has a battery or supercap so it can cache writes, you'll almost never notice the difference.

Plan A: Ask for a perpetual non-exclusive license to the copyrights you create where the work is a general-purpose utility not directly related to the products and services the company provides. Tell the boss straight up that you'd like to refine some of those utilities into products on your own time and then sell them. Agree that the company will retain a perpetual non-exclusive license to any products you produce during your employment which made use of the work you built for the company.

Plan B: Request permission to release the utilities into the public domain. Consume and refine the software on your own time, selling the result. The result, with the productization additions unnecessary for your primary work is covered by your copyright. Anyone could but no one will go back to the public domain work and build back up.

It does garner a higher premium. Someone was stupid enough to post a cleared job at a rate nobody cleared would accept. I guarantee you they didn't fill it at that rate.

No citizenship, no clearance. A green card gets you the right to work in the US in general. A clearance (and the jobs which require it) will have to wait until you're a full citizen.

ANY USG security clearance, not just a high one. Only a U.S. citizen may receive a federal security clearance. No exceptions. If the job requires the employee to hold a U.S. security clearance it can never be worked by a foreign national, including anyone on an H1B VISA.

Correct. What's changed is me: I've gained the wisdom to recognize which new technologies shouldn't be used yet because they break easy and cause more problems than they solve.

No one wants to hear that the in-vogue tech isn't all it's cracked up to be. Wisdom is not valued in a software developer.

Well sure, but Al Capone and John Gotti have a decidedly odd slant on liberty and restrictions on government action.

It's not ageism per se. Devs over 40, like myself, haven't embraced the latest greatest technology. We haven't drunk the kool aide because it's probably another passing fad.

This appears to be missing skills or an enthusiasm gap during the interview.

Take puppet for example. It's the current craze in devops -- automated software deployment. It's also a piece of trash. It implements a lot of novel concepts that will probably evolve into something good over the next decade, but along the way puppet's young developers threw out nearly all the hard lessons learned by the folks who built package managers such as dpkg and rpm. Lessons like "uninstall." Puppet has no concept of "undo" or "revert." It's all the badness that was "make install" back before package managers existed.

But God forbid you should want a job in devops without puppet experience.

We have indeed tasked loyal people with a job. You misunderstand that job. The job is to keep us as safe as possible within the restrictions on methods that liberty requires.

Tozzi overthinks it in the article. The kernel succeeded by being in the right place in the right time and then continuously being good enough that there was insufficient reason for change.

Linux, the OS not the kernel, was the first mostly complete Unix available on a college student's budget that would install on hardware the college student mostly already had. Right place, right time. Hurd didn't exist in any usable form, Minix and Solaris were $$ and the *BSD's didn't start to release for a year or two later.

Fast forward four years and when those graduating college students met the Internet bubble, Linux was the server OS they knew. Right place, right time.

Byeond that it was a game of, "don't eff it up." That's where Torvalds' pragmatism came in to play.

Tozzi overthinks it in the article. The kernel succeeded by being in the right place in the right time and then continuously being good enough that there was insufficient reason for change.

Linux, the OS not the kernel, was the first mostly complete Unix available on a college student's budget that would install on hardware the college student mostly already had. Right place, right time. Hurd didn't exist in any usable form, Minix and Solaris were $$ and the *BSD's didn't start to release for a year or two later.

Fast forward four years and when those graduating college students met the Internet bubble, Linux was the server OS they knew. Right place, right time.

Byeond that it was a game of, "don't eff it up." That's where Torvalds' pragmatism came in to play.

Most myths contain an element of truth. The truth is that computers are very unforgiving to software code which is not exactly, precisely correct. Few human beings are capable of operating near that level precision in any intellectual activity, let alone coding. Fewer still are capable of self-checking their results to catch the errors.

So until we develop a DWIM interface (do what I mean) there is and will be a sharp line between the folks who are good enough and the folks who aren't. There's a limited amount of difference in work product between the folks who "aren't quite" and the folks who "aren't at all."

I'll take option 4: suggest you try a little google expertise yourself and look up a word: hyperbole.

But hey, what does the FAA know about thin air and hypoxia.