Are the pilots making errors in situations that the autopilot would have handled fine or are they making errors because they are in a dificult situation that the autopilot was unable to handle forcing them to take over?

So the news articles claimed but at least for me pidgin still seems to connect sucessfully to it and get the buddy list (though it's a while since i've actually tried to talk to anyone on it, been using irc more laterly)

Edit: apparently the old rabbit phones couldn't take incoming calls either.

Service piggybacked on home wifi without externally mounted access points is going to suck unless you are very close to the house from which is served. Wifi is a pretty short range system as it is and the external walls of the house. I doubt there will be any decent handoff support either and I think it is likely we will see several competing systems.

So to use it you will have to find a house with a good signal and then stay there while you use it. Like with the old "rabbit phones" but unlike the old rabbit phones they won't be signposted and it will be difficult to receive incoming communications.

You connect and then you have to login. No login means no route to the internet.

If someone else is already using the "public" side of the access point when you want to connect then you could probably hijack their session by cloning their IP and mac address but if only the "private" side is in use that option is ruled out.

It wasn't an electronic copy of the domesday book, it was a project collecting various stuff including photos and videos from schools that was supposedly in the spirit of the domesday book and putting it into a newflangled computer based system.

The problem with that project was it was ahead of it's time and as such needed some pretty esoteric hardware*. Normal computing hardware from that era is still easy enough to find but the esoteric stuff needed for the domesday syste is not.

* Specifically it used a BBC master (common) with a 6502 second processor card (fairly rare), a SCSI card (very rare) and a specific model of laserdisk player (very rare)

Afaict there were two issues.

1: Mozilla didn't like the use of the firefox name with the "unbranded" logos and debian considered the copyright license of the "branded" logos non-free.
2: Mozilla wanted to be asked for aproval for every patch.

Personally I say kudos to debian for not rolling over to these demands.

The procedure for safely using an untrusted wireless access point that has a captive portal with a VPN goes something like:

1: shut down any internet using applications that could potentially send private information over unencrypted connections. Hope you didn't miss any.
2: connect to the wifi
3: launch your browser with special parameters to make sure it doesn't try to do a session restore or otherwise leak any private data from pre-existing cookies. Alternatively keep a seperate browser that you only use for interacting with captive portals.
4: deal with the captive portal, hope they used ssl to encrypt any authentication details.
5: make sure your VPN is configured to send all traffic through the VPN and not for "split horizon" operation
6: launch your internet using apps

This is awkward as heck on a regular desktop/laptop OS, i'm not sure it's feasible at all on most phone/tablet operating systems. I very much doubt any significant number of users are going to do it.

Specifically the release file is signed. That contains the secure hashes of the package lists files which in turn contain secure hashes of the actual packages. If files don't match the expected hashes apt will refuse to use them. If the release file is unsigned or signed by an unknown key apt will warn the user and ask them if they want to continue.

We DO have signed repositories and apt DOES check the signatures. However there are a couple of traps the unwary could fall into.

1: Some people may have just decided to ignore the security warning rather than properly set up the key for a third party repository.
2: The first assumption of someone getting a key error who isn't aware that the domain is no longer in trusted hands may well be to think that they haven't installed the key properly and to go to reinstall the key. Unfortunately they are unlikely to do so in a secure manner. They are likely to either go to the website on the domain in question to get the key or download it from a public keyserver by it's 32-bit key ID (which are easy enough to collide).

The real problem is that WPA lacks a mode suitable for secure public hotspots. Such a mechanism would need to provide

1: a way of verifying with a reasonable degree of certainty that the operator is who they claim to be evern though the user hasn't previously interfacted with them. Likely this means some kind of certification authority. At least the WPA enterprise deployment i've used (eduroam) required the user to manually install a certificate to connect securely.
2: a way of connecting as an "unknown user" with limited connectivity so that the user can go through the steps needed (agreeing to terms and conditions, possiblly providing payment) to request full connectivity.

So in practice wifi hotspots tend to either use unsecure wifi with a "captive portal" for authentication or they use WPA PSK with the password printed on a peice of paper and stuck on the wall.

HTTP STS helps mitigate the damage to some extent but it doesn't solve the underlying problem of the lack of a suitable WPA mode for hotspot operators.

It's SUPPOSED to be carried over https.

Unfrotunately people rarely go to websites by typing in a https url. They go to websites by typing something in a search box or by typing in a url without protocol (which for historical reasons defaults to http). This gives an attacker an opertunity to hijack things before the user switches to https and keep the client on plain http as the connection from attacker to server switches to https.

There is a new spec called http strict transport security which tries to mitigate this by allowing servers to tell the browser "if in future you see a http url pointing to me use https instead". TFA is complaining that IOS doesn't implement this new spec while andriod does and also complaining that carriers set up open wifi networks by default (though honestly even if they didn't most users would probablly end up adding several open wifi networks manually because wifi is usually faster and cheaper than cellular data).

And then they need to show that the new fuel formulation won't adversely affect reliability and get the paperwork done to let people fly it legally either by recertifying every plane or by making a blanket rule that the new fuel can be considered equivilent and legally flown in any plane certified for the existing fuel.

That is the big difference between cars and planes, in a car if your engine dies it's an inconviniance but unlikely to cause significant damage to the vehicle or to be life threatening (unless you set out on a trip with totally inadequate preperation). AIUI while pilots try to avoid situations where an engine failure would lead to a crash there are some flights where it is basically unavoidable (consider taking off from an airport in a dense urban area, what do you do if your engine fails and you don't have enough altitude yet to turn and glide back in) so aircraft engines are held to much higher standards than car engines.

Agilent techologies are a company that demerged from HP taking the test equipment buisness and a few other bits and peices. They also produce (or at least produced, I think they may have spun it off.........) some very expensive software for RF circuit design.

Our labs at uni are full of HP/agilent gear.

Wikipedia claims

"In the 1950s the Panama disease, a wilt caused by the fungus Fusarium oxysporum, wiped out vast tracts of ‘Gros Michel’ plantations in South America and Africa, but the cultivar survived in Thailand."

I know wikipedia can be manipulated but still I trust is more than an anonymous coward on /.