Insofar, this is the only response I've gotten that actually addresses what I asked, and is not merely the reaction of butthurt fanbois who don't like the concept of someone questioning their sacred cattle. Plus, it's quite reasonable and realistic

Thanks for that, dude.

OK, so I asked you the following:

As well as

To which you responded

All I can think to say is something along the lines of, "No shit, Sherlock - I was kind of looking for specifics."

I find your assumption that my statement is an insinuation of an inherent lack of non-driving-related skills, and thus an insult to professional drivers, quite telling - Firstly, being offered an opportunity to pay for a Bachelor's Degree isn't really all that impressive, considering how many other people in the world have received similar offers. It's also not a paying job, so far as I'm aware; what will you do to cover expenses while in the program?

Also, there is something to be said for experience - 20 years behind the wheel of a semi might help you get an EE job once you finish your degree... on the other hand, it might hinder you, since a lot of employers today want people with degrees and field experience. If you're not lucky, you might just end up back behind the wheel of that big-rig, sans a few tens of thousands of dollars.

Finally, I wanted to state for the record that I hold no ill will towards those who drive for a living - my uncle and one of my best friends are both lifetime OTR drivers, and without guys like that our economy would grind to a standstill.

So we've probably removed via technology more jobs than currently exist. What should one conclude from that "fact"?

I'm not making an argument. I'm pointing out a very real possibility, and asking for input on possible solutions. In other words, it's an RFI.

That was supposed to be:
Taxi drivers are only the tip of the iceberg, most drivers are employed transporting goods B2B, B2C or C2B.

Well, CoreText isn't in kernel, it's a library, and the exploit just allows crashes in userspace, not actual "rooting." Your account of the computer science involved is pretty terrible, in particular your conflation of any runtime environment and a privileged execution environment, and your confusion on the meaning of information-theoretic compactness. Your blanket condemnation of 30 years of desktop printing technology, the implementers of PostScript, and Donald Knuth(!) is also somewhat concerning.

But aside from that I would like to subscribe to your newsletter.

And the ideas existed before MAC as well. This sort of stuff used to be standard for operating systems.

What's changed since then is that the PC and Unix have taken over most of the computing world. The PC grew up as a "personal" computer (ie, the owner of the PC was assumed to have total control). Unix grew up as both a personal as well as small group computer (you trust everyone in your group). Those systems were designed so that administration was easy. Lack of solid security is not a problem at all if it's not part of your design goal. Though over time the design goals change and security gets grafted on.

You need the human touch to grow pot or cook meth. No machine could... Oh dammit! Drug-bot 3000 done took our jerbs, and it don't blow up or burn down no trailers.

Don't worry. You need the human touch to pimp out your ride so you're down wid da' homies out front da sto' where you buy shit wid da' EBT card.

Oh no! Pimp-bot 3000 done took our jerbs. Damn, he fly.

Don't worry. You need the human touch to kill terminators. Oh no! Da terminators are killin' eachother. Look at that. HoneyBadger 4000 is killing that other robot. He don't care. HoneyBadger 4000 don't give a shit.

Don't worry. You need the human touch to choke on burning robot fumes...

Well, sort of. The super-user idea in Unix is pretty awful for a securely managed system. It's great for a personal or departmental computer, but for a larger shared system it misses a lot. Many other big operating systems divide up the various roles instead of having an all-or-nothing administrator. You assign particular roles or duties. Ie, ability to kill processes or close network connections could be one role, and someone with that role can simultaneously be disallowed from reading someone else's files. Junior admins get a limited set of privileges, senior admins get more privileges, and no one individually has access to all privileges.

My first post-college job was with the administration group for VMS machines, and while I could do some things (nightly backups) I was disallowed from most activities. When someone went on vacation I would temporarily become the admin and get a few more temporary privileges. There was no way for me as an individual to grab total control without either cracking into the system or physically interacting with the machine in the machine room (and the machine had a key as well that I would have needed for console access). To do my job I never switched to a different account with higher privileges, instead I would request higher privileges during an operation; thus any action I did was always logged with my own ID.

Whereas when I did some Unix admin later in the same job it was completely different. "Su" into a different account than my own, even for many basic operations. It was much easier to make big mistakes. To get the sort of finer grained control you'd create new accounts and put add them into particular groups (ie, users allowed to use tape drives), or you'd use some newer Unix features with Access Control Lists, but all of that was basically about file permission only. If you needed to kill someone else's runaway task or even merely lower its priority you would need to be root. Set-uid programs were how you got around a lot of this and simulated finer grained control but it felt clumsy compared to a system that had security ideas built in from the start.

Taxi drivers are only the tip of the iceberg, most people are employed transporting goods B2B, B2C or C2B. Who do you think brings the groceries to the grocery store? Deliver you pizza? Collect your trash? A self-driving car would solve the hardest part, being able to load up a truck and have someone meet it at the other end would be huge. Also imagine all the people who can be more effective by doing paperwork and such while going site to site instead of driving, that too should let fewer people do the same work. A self-driving car is going to be an Industrial Revolution-class change.

It seems like we're reading the part about the sole inventive feature being that it is a computer program a little differently, so we're coming up with different interpretations. My perspective on computer programs is that they're always implementations of some kind of algorithm or design that isn't a computer program, so there's no such thing as a solo computer program that qualifies as an invention. It just seems so intuitive and obvious to me that it's hard to understand how anyone can read it differently. Of course, I have to acknowledge that the reality of the situation is that legal types are going to mostly interpret it the way you are.

I'm curious - what new careers do you foresee, that current professional drivers would qualify for? Or are you saying they should give up their fairly-decent-wage driving work and go flip burgers whilst sucking hind teet for minimum wage, social consequences be damned?

See, that's the real problem - I'm sure we can all come up with a million ideas for work the next few generations can do, but that means precisely jack shit to the current generation who will lose their only source of income.

What's the stop-gap for the time period between auto-cars taking work from humans, work they need to pay their bills, and the creation of these ephemeral 'new jobs' that won't exist for a good while?

Such separation of access is fundamentally impossible. You either trust the admin or you don't. Anyone who says otherwise is simply kidding him/herself.

The admin is responsible for installing software. In a matter of minutes, I can patch any app to silently write a copy of each file that the user accesses in a shared location or upload it to a server somewhere. If I'm the admin and can therefore cause those other people to run my Trojan version of the app, then their data is compromised.

Well, you can ask someone who installs them. They'll probably have a positive bias....they install them. They're faster and easier to put in....and aren't likely to leak for several years, meaning that he's either 1) not experienced, 2)has seen it and minimizes it, 3) has seen it, knows its bad, but gets a kick back or other incentive from the company or his employer, 4) or they actually are good walls.... Regardless, will I get an honest opinion? Probably only if I am related to the person in someway.

This is why you take multiple bids and ask each one to explain why they took the approach that they did before making the final decision.

While you're at it, seek out a retired construction worker (who has no financial motive one way or the other), and ask that person, "If this were your house, would you do this?" If his or her answer is "no", then your answer should also be "no".