> You can't sign away many such rights

You can make a contract for all _sorts_ of interesting things, including marriage and adoption. So yes, a contract that holds one party free from liability can be quite enforceable. The details of whether the protected party fulfilled their part of the contract is a critical facet of such a contract, as is the exchange of some benefit or privilege to the other party.

> Multiple eyes on code, security, these are things that are great about open source, except they aren't. This is a prime example of how bugs get through anyhow, major bugs. So it is now shown beyond a shadow of anyones doubt, open source is NOT superior in these respects.

Really, no. The horses are still pulling plows, and carts, and carriages, every day. The library is still in use in operating systems world wide.

This is more visiting the barn that had horses stolen and making sure the locks and doors actually work the way they should before it's trusted at all again.

> Any remotely well organised IT department will have processes for handling both emergency deployments and retrospective approval

Not when the architect is offline and is needed for every significant change. If there is going to _be_ a policy, a manager needs to be ready to enforce it, or it's going to be everyone making up their own undocumented and impossible to synchronize policies.

> MOST of the critical infrastructure, the really important stuff, is NOT unprotected.

Yes, it has 95% coverage. Unfortunately, it's alike a dike against a flood. One weak spot and the intruders are in. The intruders don't even have to be clever, just persistent.

> Have you ever noticed that companies locate their research divisions away from the day-to-day operations divisions? It is to keep the timeframes separate.

No, it's turf building and budget protection. By segregating the developers from devops, devops can _hide_ their resources and keep them sequestered from developer requests. And putting the systems into a "requests go to managers, and only then to devops" makes the managers vital to allocating resources. It can protect their team from excess pecuniary demands, but far too often it's used to make the manager more important to the process than they should be, and grants them personal power over other groups' projects.

I've been documenting a tragic example of this for the past few weeks. I'm afraid the manager is in for a _big_ surprise when they find out that writing run books is their new highest priority, and their personal approval of run books is no longer expected.

I jump under desks! But I'm a very, very senior technologist, and I spend a lot of my time _teaching_ people how to do these things.

> This sysadmin/scripter/system architect/DBA

And then they stop doing _any_ of the tasks well. They don't show up for planning. they don't document their code, because "it's self documenting" or "documentation is unrelable". They say "Just Google It" when most of what is on Google about the task is _wrong_ and written by people who aren't aware of the subtleties. They refuse to mentor, because it keeps them away from the meetings where they can soak up and interfere in _every single groups's projects_ by citing standards that are only in their head, or worse, are only in the mental image of what other people remember they said once about something else.

One of the great pleasures of my professional life is finding these people and educating them in how _not_ to be a micro-managing block to everyone's work: it involves actually documenting the _working procedures_ for daily tasks so other people can do them. Many of them are afraid of the loss of control or possible errors, but the improvement in speed of daily procedures is enormously satisfying.

No. It's not. The most effective and efficient forms map the face to a uniform shape, almost spherical shape, especially for 3D facial recognition. The resulting consistent transform is *edge* based, not 3d structure shaped. Anything that adds extra edges, or re-arranges them, like makeup that adds eyebrow like dark markings or makes the face strongly asymmetrical consuses the hell out of it.

> C++ (and do a lesser extent C) lose support because of their extremely poor support for utf8.

That's because for most programming, UTF8 is not worthy of support. It's inconsistently used, it arbitrarily increases the of individual. It would be much safer used as only binary strings, not as actual characters which must be parsed and reformatted among different environments. The advent and popularity of UTF8 with its confusing and ill defined management of case and formally POSIX compliant operations such as file naming has effectively slowed system programming by many years.

> Actually it can't. That's kind of the point of git.

Unfortunately, many git users keep their SSH keys unencrypted on their local hard drives or on network accessible home directories. This means that a careless git admin may have their SSH keys stolen by quite amateur crackers, and leave the public repositories open to quite malicious changes. I've had precisely such discussions with personnel who insist that they trust the people they work with and they have a firewall, so they're not at risk.

> And yes I think if Texas voted to join Mexico the USA would accep

Not a _chance_. Texas has oil, just like Iraq.

The NSA was _able_ put in back doors. According to the report, the build environments were not safe enough and well enough controlled, or verified, to _prevent_ back doors. Given the NSA's strong interest in having one, and their level of skill, I'm afraid I'd have to assume that they did, indeed, create one. Whether a system that is at risk of such a back door is good enough for personal or even business is something you'd have to decide on a personal basis.

It does seem a good step in the right direction for open source tools to _get_ a thorough security audit, rather than merely relying on "many eyes" to ensure security.

I'm afraid I've seen some very dangerous maneuvers of people pulling off to take a phone call. I'm afraid I've even done them when I was on call and on my way to an urgent job site, and had to reset my priorities for taking such calls.

Zipcars are actually a problem this way. I've used them occasionally while traveling, and they've been quite useful. But as is inevitable when borrowing someone else's car, the controls are "intuitively" re-arranged into inconsistent confusion on most of the cars I've used. As a simple safety measure, I try to schedule the first 10 or 15 minutes of any car rental to just find all the controls: lights, emergency blinkers, parking brake, heat and air conditioning, emergency brake, getting the trunk and hood open, cigarette lighter sockets for power connections, radio controls, adjusting the seats, fuel and water and oil nozzles, console displays for fuel and temperature and speed, etc.

We need cars to have safe places to hold the cell phone, possibly tied to the car's audio. While many modern cars have a USB connection to the car stereo and for recharging a cell phone, there is no safe place to deposit your cell phone so it can continue to give directions or be voice controlled. The result is a mad scramble to put your phone down somewhere in the right orientation so it will continue to give good directions. Or worse, flailing around to run your finger across the "accept this call" slider without crashing the car. That part is not helped by voice->text systems, or an ear bud.