Not correct. A commercial pilot certificate lets you fly for non-scheduled operations - think charter flights, on-demand sightseeing flights, powerline and pipeline inspections. "Uber for the sky" would be exactly this - non-scheduled on-demand operations ("Part 135"). An Airline Transport Certificate is required for scheduled operations - which includes not just Delta, American etc but also FedEx and UPS who fly under Part 121.

It's not based on whether it's passengers or cargo.

I absolutely hate this answer. I graduated from a school (Michigan) that had both EE, CE, and CS. That was 2004 (later went to Carnegie Mellon to do a Ph.D. cause it seemed like the "next thing"). Today I work for a large bay area software company and recruit from UM, amongst a number of other universities. In general, having done a few hundred interviews, I find that CE students (or CS students who tried to go the hardware route within the CS program) are a jack of all trades and master of none. They may have a decent understanding of computer architecture but since that was their major design class, they opted not to take neither an O/S nor a compilers class, so they really have no idea of what is running on top of that simplistic CPU they designed. They didn't take a software engineering class (sure, they did the intro programming but they have no idea what singletons or factories are) so their code sucks. They didn't do VLSI so they don't really know how that Verilog they wrote translates into silicon. They've heard of timing constraints but have no idea how to actually place/route so as to alleviate this.

I could hire one of these people and maybe they'd be able to figure things out. Or, I could hire someone who actually chose a specialty and attained something approaching mastery (relative for a student) of some area. Someone whom I'd actually trust to write good code, who understands threading, who understands the performance implications of what they're writing... or I could hire that guy who knows just enough in a lot of areas to be dangerous.

Can you speak to these parts? Maybe. Would I trust you to work on it? Probably not. Want to prove me wrong? Send me a message and a resume and I'll be happy to set up an interview.

The reality of DRM is that, absent having a TPM that enforces some sort of software integrity that reasonably ensures that the player is sending the video to a trusted display (TPM validating OS validating player software validating HDCP connection), you're going to be stuck with some security-by-obscurity closed source components, or "plugins". It's unfortunate but I can't honestly see a way around that without much larger changes (like trusted computing, but in a slightly less evil implementation hopefully). The "better alternative" to native apps then becomes allowing DRM to be done in the browser in the least intrusive manner possible -- that is, use as much of the browser's code as possible and have the plugin footprint be as small as possible. Today Flash and Silverlight are used not just for DRM but for the entire player application, ideally the player application could be mostly in HTML and using the browser's stack as much as possible, calling out to the DRM module only for either decryption or saying "Please composite this decrypted stream into that div".

It's so tempting to just sit in the corner and say "DRM is evil, we don't want to taint the web with it" but unfortunately, as is often the case in the real world, we don't get to make decisions in isolation of their consequences. DRM on the web is already a reality, largely using Flash or Silverlight (see e.g. Hulu, Netflix). However, both of these platforms face problems -- Silverlight in particular seems to have a rather uncertain future, Flash availability on tablets and mobile in general is largely non-existant. The poster asks us to "please use other applications when necessary" - is this really a good answer? That is going to lead to even less interoperability, and I would argue it hurts the web at a time when it's already fighting a serious battle against native apps that generally offer developers better control (of UI, no random GC pauses, actual threading models, etc). It's easy to say "DRM will harm the web", it's a bit harder to foresee what the eventualities of telling people "please go away and use native apps" are.

I expect this is likely not going to be a popular response, but in short please realize that this is not as simple as saying "DRM is bad". Yes, DRM sucks but I'd argue that in the long run, having a hobbled web platform losing out to native apps (see e.g. iOS) is going to suck more.

I respectfully disagree. I think the career experiences you gain after university can take you in many different directions, and with CS especially you have options in many different fields (far more opportunity to move around from CS to something else than from Aero to CS). Straight out of college, the Aero or MechE degree isn't going to get you a job as a software engineer at Google or Facebook. It may get you a job "programming" somewhere obscure, but you're going to be hard pressed to find a top-tier employer hiring a software engineer these days with a person who is a recent graduate and who didn't do CS. (I also believe there's a difference between computer science, software engineering, and programming, but that's probably a long enough rant for a different post.) The computer scientist could easily get a job at Northrop or Boeing working on embedded control systems for aeronautical / space systems. If they build the systems that model these components and work closely enough in the field, perhaps that bleeds over into an actual aero design job, but to be frank I'd say the chance of that happening is about the same as someone with an aero or MechE background landing a job as a software engineer at a top-tier company. However, the CS person has a much wider swath of potential employers and industries than the Aero person.