Imagine someone who walks with a cane trying to get out of the window seat in an emergency. Or even get in and out of it at all. Or what happens when the window seat person has to go to the bathroom?

I think this might be a good seating plan for getting more troops into less space in a military transport aircraft. But for civilian airliners? I just can't imagine that it would work.

And my axe. Get off it also.

We won't have a truck manager on every truck. We'll have truck managers responsible for a region of maybe a couple hours' drive. When a truck gets sick, the local truck manager drives out to where it is and fixes it. So we're replacing a couple million jobs with a couple thousand.

Team driving is a big thing. Some trucking companies - notably Covenant - have moved to an all-team format for company drivers. Owner-operators can do what they want, but solo drivers are likely to be outcompeted by team drivers.

The issue is that in recent years, driver duty regulations have been much more strictly enforced, so you truly cannot have your truck moving for more than 11 hours a day as a solo driver. If you have two drivers on board, you can keep the load moving all the time except for rest breaks.

Several vendors make dedicated EFB devices. They're a lot more expensive, though, and their UI is generally awful.

It's no great mystery.

Uber has been working with state legislatures to try to get all the bans and regulatory uncertainty to go away. The legislation reads like a list of things Uber already does, except for the required markings, which is something Uber surely wants but can't force on its drivers - "it's not our fault, it's the law now in Massachusetts, so pick - Uber or Lyft - you can't have both."

But in that case, what's the advantage of implanting it? I mean, other than thieves now wanting to cut out my spleen instead of just taking my wallet.

There are a number of Youtube videos of people flying hobby drones well above 10,000 feet. Above 10,000, several safety measures go out of effect - airline passengers can remove their seat belts, airliners can exceed 250 knots, etc - so a hobby drone at 10,001 feet is much more dangerous than a drone at 9,999. Above 18,000, all flights must be conducted under IFR and pilots are no longer required to see and avoid - so they stop looking out the window and get busy with other tasks. So a hobby drone at 18,001 feet is yet more dangerous still, as well as being a whole new level of illegal.

You can bet your bottom dollar that hobby drone operators know none of this.

The FAA, for very good common-sense safety reasons, wants like hell to put a stop to this. However, Congress legislated away the FAA's power to actually regulate or provide standards for hobby drones. The FAA can't say "don't fly them above 10,000 feet" because they are now prohibited by the FAA Modernization and Reform Act of 2012 from *any* rulemaking regarding model aircraft. And according to the Act, the model aircraft can be *up to 55 pounds* - and it seems like FAA concepts like "controlled airspace" don't apply. The only requirement is that if you are going to fly within 5 miles of an airport, the operator has to provide prior notice - *not ask permission* - from the airport's air traffic control.

During the period 1958-2012, the FAA was solely responsible for aviation safety and airspace regulation, and maintained a profoundly excellent safety record. From 2012, there are now two agencies responsible for air safety - the FAA for manned aircraft, and vaguely-defined "community-based set of safety guidelines" for recreational drones in the same airspace. Common sense says that this can't, and won't, work - so basically, Congress has decided that we will wait until a drone takes down an airliner, then over-react and probably outlaw all hobby drones everywhere. And probably blame the FAA.

This is what passes for policy-making in the US today. It's really very sad.

Well, I was programming in the 1970s, so this is recollection for me, not history. And you've got it wrong in either case.

The famous port of the Unix kernel to C was in 1972/73, not 1970, and at that time, C was still a private language within Bell Labs. The K&R book "The C Programming Language" was published in 1978, but C didn't gain much traction outside Bell Labs until Microsoft and Borland released compilers for it in the mid 1980s.

In the period from 1965-1970, computer science was taught using ALGOL, and between 1970 and 1980, it was taught using PASCAL - mostly the UCSD p-System. The Christmas shopping season of 1977 was the first time you could buy a computer and take it to your house, and these machines were programmed using interpreted BASIC and hand-coded assembler - nobody in microcomputers had ever heard of C. The first compiled language for microcomputers that had any widespread success was Turbo Pascal, released in 1983 for CP/M and DOS. C did not make any serious inroads into microcomputer popularity until the mid to late 1980s.

This wasn't just some random thing - there were good reasons for it. Many of the microcomputers of that era didn't have curly brace keys, so there was a version of C where you could type (* and *) instead of { and }. But more to the point, compiling Pascal is incredibly faster and easier than compiling C. Pascal does not have a preprocessor, header files or multiple passes - the syntax of the language lends itself to being fast and cheap to use on extremely minimal hardware architectures.

Some of the features of Turbo Pascal - like the "with" statement and the set operator - have never been duplicated in any other language. Trying to paint Pascal as an also-ran to C is both historically and technically incorrect.

> Why do we need yet another language, that has no particularly useful features?

You do understand that Pascal was first released in 1970, right? Many Pascal programmers in the 1970s asked the same question - why do we need C, with its dangerous string handling and obtuse preprocessor, if it doesn't solve any new problems?

> I used Pascal in some college courses, and felt that my productivity went down by about 50% compared to C

I felt the same when I switched from Pascal to C. I had to spend half my life squinting at curly braces and trying to track down what the origin of some multi-level-#defined thing was. It is normal to feel a reduction in productivity when changing languages, but that doesn't mean the new language is worse.

The plan is presumably to offer heavy discounts on purchases for a couple years to get everyone to start using it, and then take away the discounts once it becomes "normal." They're betting consumers are too dumb to realize that 20% off some DVDs isn't worth losing credit card liability protection forever. I'm not sure they're wrong.

At least they went through a rulemaking process. Some agencies (recently FAA, FDA) figure if the issue only affects a narrow interest group (pilots, drug makers) that they don't actually have to bother with public comments or even actually writing the rule down before starting to enforce it.

New versions of Windows are also generally better than previous versions.

The word "refactor" has been insanely successful in getting managers to approve rewrites. Before the Agile Manifesto, when programmers wanted to take a completed function and write it again, they would ask to "rewrite" it. The manager would ask what's wrong with it, the programmers would say, "nothing, really" and the manager would decline the request. Now, the programmers ask to "refactor" the function, the manager asks what that means, and the programmers give a confused answer whose only consistent message is that whatever-it-is is urgently needed. So the manager says, "okay, I guess."

The first case leads to crufty codebases that are hard to add new functions to. The second case leads to writing the same functions over and over and getting nowhere. It's not clear to me which is better, but it is clear to me that substituting the word "refactor" for "rewrite" has changed the world.

The Windows HAL is certainly not the greatest API ever, but somehow everyone other than Apple manages to have their device detection work by callback or event sink, not by polling. If Apple really is polling for USB presence, then there's really no way you can blame that on the Microsoft API, which does provide better ways of doing USB device presence detection.