Those 6 hex values aren't completely random. The first three numbers are vendor specific.
So by looking at "AA:BB:CC" you immediately guess who the vendor is, (C0:CB:38 is Broadcom, 5C:26:0A is Intel).

Also, most constructor don't assign the last 3 completely randomly but use incremental number.
By looking within which range the last 3 falls, you can also guess which range of product this is.

So a MAC address CAN INDEED be used to infer the wifi chipset in the phone.

See a MAC address in a range that Apple typically use for iPhones? well you know that the user has an iPhone in his pocket. You might even pin-point it down to the latest iteration.
Fire up the hipster advertising mode.

See a MAC address from broadcom, a mid-range or budget wifi chipset? Probably a poor student with a netbook enjoying the stores free WiFi.
Good idea to advertise special offers on ramen packages.

Ekiga is a good replacement for SkypeIn/SkypeOut, as there are hundred of VoIP-to-landline SIP providers, all competing on prices, to choose from.

(And also, this gives a possibility to communicate with Skype users through their SkypeIn number)

But Ekiga only supports SIP (and H323), but not XMPP/Jingle yet.
Thus you're still a victim of Skype's network effect, and can't leverage all your Google and Facebook friends to chat with them.

My solution is using a combo of both Ekiga (for call to landlines) and Pidgin (to chat with my friends through XMPP)

But the network effect stop being a barrier once you realise that Jitsi support XMPP among other standards and Google Talk use it too.

Just enter you google account and you can as of today chat and call any of your friends who also has a google account.
(The other could even be using Google's web interface, so you are the only one installing the software - though by doing so you accept some limitation, mostly security, like unable to run an encryption and avoiding the possibility that Google eavesdrop).

No need to convince anybody. Just use what they already have.

The fact that they signed the privacy for facebook is also interesting: that mean that they HAVE a facebook account.
And facebook provides also a XMPP gateway to their chat system.

That mean that, without any convince work to do, you can also chat with all the friends you have on facebook.

Although again with some limitations:
- Facebook users can only chat with other facebook users (forget about using your @gmail.com account to chat to someone @facebook.com. They don't support federation.)
- The audio/video isn't available in XMPP/Jingle standard, only as a derivative of skype webplugin technology.

(And the same limitations as above: if only one end is using jitsi/pidgin/whatever and the other end is using the web interface, no encryption is possible everything ends up in facebook's archives).

Well as Skype doesn't inter-operate nicely with any standard, that indeed makes thing a little bit more complicated.

But you can still use your own SIP-to-landline provider to call their SkypeIn number and vice-versa.

You lose quality and latency because of the extra hop through landlines (the nearest Skype server and SIP provider communicate) and no ability to form a direct peer-2-peer channel.

But at least in most combination this should involve free calls and thus no extra costs.

That's what you think when you buy into skype's hype.

But what you have to realise that skype is closed (not only the source, but even the protocole is kept secret).

There are industry standards already out there. Not as in some technical document written by a master student. But as in currently widely deployed and used by lots of companies/users/etc.

XMPP (started by Jabber) is an open standard with wide adoption for internet messaging. And it allows federation (users on any server can chat with users of any other server. For exemple between @gmail.com and @jabber.org).
Jingle is a layer developed by Google which adds audio/video capabilities to the XMPP infrastructure.
Among other:
- Google uses XMPP for its Google Talk chat (and allows federation).
- MSN and Facebook offer XMPP gateway to their chat system. (Although with a few limitation: no federation, so only chat with users on the same network, and both use some proprietary skype web-plugin technology for audio/video).

SIP is an industry standard for VoIP (and chat, thanks to the SIMPLE extension). As in virtually everybody else beside skype is using it.
- It allows some federation (@iptel.org user can chat and call @ekiga.net users)
- it's the absolute standard. If you here of a non-slype VoIP-to-landline, chance are they are accessed using SIP.

And now come the best part of using open technologies:

OTR (for of the record) is an end-to-end encryption layer which can be stacked above any chat system. It's included by default in some popular chat software (Adium, Jitsi, etc)
That means you can also run it above XMPP, so Google can't read your messages.
As long as both ends use OTR, you can encrypt your messages no matter the chat system underneath.
(That means it could be even theoretically implemented above Skype)

Both XMPP/Jingle and SIP use RTP for their media channels which *is* peer-2-peer (unless a TURN server is required, and even then the user can chose a trusted server). Due to the way this work (Jingle and SIP are signaling protocols: they are used to get point to agree to open an audio/video session, but the actual session happens over RTP), its very easy to add security here too. And it's been done: its called SRTP and ZRTP and they are standards too.
As long as both ends support SRTP/ZRTP its possible to encrypt any audio/video RTP session no matter the signaling used (so even for users of Google Talk).

Well if you think about creating your own new chat system, there's indeed a network effect in favour of skype.

BUT remember those standard mentioned above?
XMPP is already used by Google. That means there are already hundreds of million registered users there too.

(you could also count Facebook in, if you consider the limitations - they can only chat with other facebook users, and use a proprietary fomat for audio/video chat)

Suddenly Skype is "just another player in the field".

Are you kidding? This is just plain uninformed.

SkypeIn/SkypeOut is far from the only VoIP-2-Phone access provider.
There are hundreds of such providers out there.
And virtually all of them are using the SIP standard (some are also offering the older H323 standard) (and I think google's own voice system is also available as XMPP/Jingle).

In fact, they are much more interesting: as they use an open standard, you can pick any of your choosing. It's a free open market with a real pressure to keep the prices low.

If you use Skype, you're limited to only using their SkypeIn/SkypeOut service and their prices.

If you use another software based on open standard, not only can you chat with all the people you already have from Google (or Facebook) but you can also make calls using the landline provider you choose which has the best prices for you (my SIP-to-landline provider is cheaper than skype)

And that's only for traditional service provider. As SIP is an open standard, you can even imagine other usages. Some DSL modem (like Fritz!Box) have also ISDN/analog connection and feature VoIP-2-landline: recieve call from you landline to your VoIP devices (laptop, smartphone) or use a regular or cordless phone to call VoIP targets.

Where's my WebOS client? I also have an idea of a cool rasberry pi project can I have a generic Linux/ARM client ?
Can I also have a cross-platform client written in Java ? and embed it inside a webpage ?

There are several skype clients. But they only run on the selected few platforms that skype and microsoft choose to port it to.

Meanwhile there *is* just a crazy amount of clients supporting open standards.

I can download today a java client like Jitsi, or a Linux/ARM port of pidgin, fire it up, connect it with my google account and chat securely with any of my contacts also on google.

The alternative is already here. Thank to widespread standard usage there's already a network to leverage.

The only single historical advantage of Skype has been its setup:
almost no network configuration required. Skype leverages Kazaa technology to be able to create P2P connection even behind NATs, firewall, etc.

But nowadays, with UPnP, STUN, TURN and specially ICE (and also with the advances of IPv6) these advantages are eroding.

Nuts *might benefit* from better health care. But also, it would be best if nuts couldn't get easy access to guns.

If guns and ammos are available in supermarkets and if people can store any weapon they want at home, if a crazies snaps, he can immediatly grab the nearest weapon and go on a rampage.
An impulsive idea can immediately be but in action.

On the other hand, with gun control laws, the acquisition of weapon might require complex paperwork, and guns able to find big number of ammos might be required to be stored at the armoury. If a crazies snaps, he can't immediatly act his rage out. He first needs to jump through the necessary hoops in order to get access to his weapon (either going through all the steps required to buy one, or having to go get back the weapon from its storage while filling the necessary paperwork). This takes time, and this delay might be enough to unwind the crazy.
An impulse can't immediatly be put into action, and by the time the crazies finishes preparing his stuff, the anger could probably have gone down.

Gun control laws aren't here to stop criminal organising a robbery (determined criminals will always be able to get access to a gun).
Gun control are here to slow down/delay some nut going postal and give them time to think again about their actions.

http://youtube.com/html5
to manually enable/disable HTML5 video.
if you're logged in, this preference can even be saved.

Youtube automatically detects which codecs are supported (Chrome and Firefox both support WebM. Chrome also supports H.264. Older versions of Firefox don't (due to licensing restrictions), newer version of Firefox will tap into whatever system codecs is available for firefox to use: GStreamer on Linux, DirectShow in Windows, hardware codecs wherever supported).

Also, video ads require flash to play.

If we take your example of "fake windows":

- most Linux based embed systems with a Unix-like userland, would be the equivalent of taking Windows "XPe" keeping it almost as-is, disabling only the shell, and using firefox as a shell instead. Or taking a Windows Server. and installing it in "headless" mode, not running any graphical interface, but running in command-line mode.
It doesn't visually look at all like a regular Windows, but under the hood most of the pieces are here. It still uses Aero and/or DirectX for graphics and sound, CMD is there if you need it, etc.

99% of the files are the same, even if visually there's a lot of difference.

- Android, and the firmware of a few NASes and Media Players, would be the equivalent of only using a small subset of the ".SYS" files of Windows (the various peace of the kernel), only those for accessing hardware, filesystems, task switching, etc. Absolutely everything else is replaced by a huge custom .EXE (and its attached .DLLs) no trace of anything from the original Windows beyond the kernel (these NASes and media player usually take over from the INIT process it self and provide a huge custom monolithic stuff from this point onward. To keep the metaphor, this .EXE+few .DLL is entirely written in .NET because C# is popular (Android use massively Java because its popular). But instead of compiled to bytecode running on the classical .NET DLR virtual machine it runs uses Perl6's ParrotVM :-P (Android doesn't use the JVM, it use its own Dalvik).

Only a couple of .SYS files inside "system32" are shared is a regular Windows. Most of the rest is taken care of in this big weird .NET .EXE. It doesn't even have support for Win32 api.

I agree. But back in 2003 when the development started, the main constraints for anybody in this field was: there's no way to cram a full Unix environment in a mere phone, its a crazy idae and an awful waste of resource, no current phone hardware could sustain this. Let's instead implement everything we need in a light-weight userland that we're writing from scratch. (And lets use something similar to Java for it, because it's popular and enterprisy)

Not only is the terminal window missing (because as you say 99% of the users don't give a shit about it). But absolutely everything under the hood is missing.

Unlike other people rambling in this thread, I never accused Google of being anti-FOSS.

I just responded to the discussion: the parent was astonished that Android was considered limited by some. His argument being: you can run anything you want and this is all thank to Android "being Linux".
My counter argument are: unlike any other regular Linux distribution, Android doesn't share much in common beyond the kernel. What is usually done by the regular Unix-like stack in any random other distro, is handled by parts in the the Java-like userland.
You can run anything you want, but for most stuff you'll need to put back that regular Linux stack for this to function.

And this brings us back to what the parent posters were speaking about before I jump in:
Android is an appliance OS and indeed is designed with a completely different scope in mind. And in fact, "out-of-the-box" is designed to run a less vast gamut of software than what a Linux distro can.

That's what I've said, too.

Yes and no.

Your comment is correct regarding things like the C library. Currently Android uses google's own Bionic. Previously it had used components coming from the GNU ecosystem. Among the reason why google developed it, the license is indeed one of them: Bionic come from the BSD userland and is BSD licensed, thus giving more freedom to 3rd party to hack it without needing to publish their modifications. (But thus restricting the freedom to hack of the end users themselves). On the other hand, the predecessor inside android, glibc had several short comings too. (eglibc, which tries to adress several of these shortcomings, notably by being easier to port on embed architecture, and being easier to build a lightweight version by disabling features, only started to gain acceptance later).

But for the rest, that isn't exactly the case.

Android started being developed almost 10 years ago (2003).
As a reference, iOS got released officially in 2007. And even if it was the same usual BSD-derivative architecture under the hood (with only a different user interface and application layer slapped on it), the user-facing elements were designed with non-multi-tasking in mind.
As another reference, in the Palm/Handspring world, from 2002 until 2005, Treo were running PalmOS (a OS that I personally appreciate a lot, having own palm IIIc and T3) which is not even multi-tasking (Palm OS 5 did introduce some very limited forms of multi-tasking). Windows Mobile (as shitty as it is, at least is truely multitasking) was only introduced in 2006.

Back then, smartphones weren't that much popular yet. Most of the phone were simply feature phones. Most of the phones didn't have that much processing power anyway.
Putting a whole unix platform on a phone was considered insane: its a huge overkill of resource.
If you're doing a firmware for a phone, most likely you're making a big monolithic app. You're not trying to cram a whole workstation OS inside a phone (Nokia's Maemo/Meego got such a huge popularity among geeks when it was released in 2005 exactly because of that: Unlike everyone else back then, Nokia successfully managed to cram a whole Linux distribution with the whole stack into a pocket device. And this device still wasn't mainstream/typical even when it was released).
If a phone happened to "run Linux", it would most likely be only the kernel (to leverage its hackability and to use the capabilities of the kernel itself: resource management, filesystem access, etc.) and over it, instead of a whole linux workstation stack, you just found a big monolith. (Very often Java was popular in this bundle). Motorola's RAZR2 is a nice example of that. It uses a Linux kernel. It was released later (2007) so it contains much more pieces of actual Linux (they could afford more) but the biggest part is still a blob.

So back in 2003, when developer started working on Android, they did what everyone found logical in this field:
- They took the Linux kernel because its nice, customisable and contains lots of well tested parts (ressource management, file system, etc.)
- They made a big blob to run on it.
- Java being popular a lot, they created the java-like dalvik.

They didn't as much replace one by one the various part of the usual linux userland with inhouse stuff because of the license, as much as they simply refused to start using them in the first place, because back in 2003 cramming an actual linux stack inside a feature phone sounded like an impossible idea (due to the limited resource) and looked really stupid. Writing your phone firmware as a big single program or collection of programs runing on a bare kernel was the norm and what everybody was doing due to the limited capabilities of the hardware.

Interestingly Palm webOS started its life the same way:
as "Nova" a light-weight OS from Pixo. But for various reasons (development dragged. such custom lightweight OSes are difficult and cumbersome to program due to various tradeofs. you need to reinvent the wheel for everything) this was progressively scaled back (in the first released webOS device, Nova is reduced to a middle ware handling a few stuff. The rest of the OS is a pretty much a regular Linux stack, except for the UI. But this UI is based around webkit so even this use widespread parts, because of ease of development [the cited exemple is that centering text in the interface in Nova take 5 lignes of code. in the final webOS its just HTML getting centered by regular Webkit. Speak of an improvement]). By 2009 when the first Pre arrived, using as much regular linux component as possible (like, for exemple, using pulseaudio for audio routing/mixing) was realistically possible, and was a nice idea (re-use the usual proven modules, instead of reinventing the wheel poorly and inefficiently)

So to go back to Android: Android use a different userland than most distro. Not because google replaced each piece one by one to get rid of the GPL license (otherwise they would have replaced the kernel by now). But because of the unusual roots of Android: it started its life at a time when everyone rolled their own lightweight in-house system. Android started as such a in-house system, designed aroudn a Java-like Dalvik, which just happened to run above a linux kernel.

Under regular conditions, its in the range of minutes, maybe up to hours.
RNA isn't that stable. (In labs, it needs to be handled specially. You need to either freeze it a deep temperatures (you put your RNA samples in the -80C freezer) or copy/convert it to DNA (use a reverse-transcriptase to make much more stable DNA out of it).

...as in one birds poops into the water while another is drinking (= oro-fecal pathway I mentioned 2 levels higher in the thread). Not as in 2 birds which happen to drink from the same river a few apart. You need a time frame of a few minutes up to a couple of hours max.
(In birds, poop contains the biggest amount of virus, and as it moist and protects from light, viruses have the highest chance for surviving a longer time).

It's the bird's equivalent of humans sneezing on each other's face. (You can catch flu this way. Whereas, your risks of catching flu by walking in the same room as where someone sneeze the day before are bleak) (in humans that's aerosol/particulate transmission).

By the time the chicken reaches the kitchen, most of the virus will probably have died/become inactive. Chance of transmission at this point in the chain of the poultry production are low. But are much higher at the other side of the chain.
At some point of time the dead chicken in your dish (and in the kitchen of the restaurant where you're eating) used to be alive (I realise that I'm starting to sound like a Monthy Python's sketch).
This chicken has been slaughtered, de feathered, butchered and otherwise conditioned before being sent to the restaurant.
At that point of time, the chicken was alive not so long ago (so there should be still active virus in it), and the whole preparation is bound to release quite a lot of the virus in the air. People working at this point in the chain (very often the farmers themselves) are at a higher risk.

We're still speaking of only a dozen of people per year, though.

Now the problem is that this transmission (bird-to-human) is so rare, that we don't really have enough stats to support this kind of conclusion. All I can say is that all the bird-to-human transmission I've heard about in the past were in people handling the birds (farmers, and the like), none of them were people working in the kitchen of restaurants service poultry, nor people eating chicken.
But well, with such a small pool (a dozen of cases per year) nothing is really 100% sure. We definitely lack enough data to give the exact life-time of a virus, or the odds of infection at each precise stage of poultry preparation, between the farm all the way to your dish.

And any way, this is bio science, not hardcore-hard science. Anything can happen anyway (although we're slowly drifting into the kind of "anything" territory, as western people in big city catching malaria although they've never travelled abroad ever, but just happen to live near an airport, and managed to get bitten by a mosquito which travelled all the way from Africa while trapped on a plain. This kind of Rube Goldbergesque situation does happen, but we're speaking single-digit amount of cases in total)

Yup, a dozen of people caught the disease, out of whom 6 died.

Now to put things into perspective, according to WHO, each season, regular human flu infection gets *half a dozen millions* of individuals out of which *up to half a million* die.

The number of "bird flu in humans" is so small that it looks like a fluke. As I said before :

Life sciences are not hardcore-hard sciences. You can never say "never" nor "always". There will always be some weird exception. If you start digging literature for weird case reports you could probably even find single digit occurrences of probable infection by things for which we aren't even the normally taxonomic phylum (who knows that one single virus might have a just that critical mutation just right before jumping onto you). FFS, the human genome contains genes which originally come from life forms to which we aren't even evolutionarily related (if you're curious, it's called "Horizontal Gene Transfer", normally *bacteria* are the ones doing it a lot, but well, never say "never", apparently even the human genome stole a few genes this way).

If you're that much concerned about getting avian flu, go play the lottery instead. Your odds are better at winning cash than catching bird-cold.

Now to back to the poor schmucks who died of avian flu:
- They are people who get exposed to birds a lot (I mention farmers, DigiShaman mentions cock fighting handlers). They get exposed tu much more massive amount of virus. More viruses are playing the "let's try to hop to a human" game, odds of 1 of them winning this game are higher.
- As I mentioned before, these aren't rich westerner in a big modern rich city, they are poor guys in backwaters. Once these get sick, they don't have an as easy access to proper treatments as the former. And risks to get a complication (pneumonia) are higher for them.
(- And for the biologically inclined there might be a - though less important, but interesting - 3rd factor. As this is a bird disease, it looks a lot less like previous seasons' flu than the regular human flu, and thus the white blood cells have a lot less "prior knowledge" to leverage in fighting this peculiar disease. In biological term: chances are lower that one of the "memory B and T cells" have a receptor which more or less works a tiny bit with the newer virus. Same reasons why the last swine flu could more easily infect younger people than the previous flu: it didn't look like anything we've seen since in the last 60 years).

So even if you managed to win the lottery and catch avian flu:
- your personal odds at surviving it are much higher as you'll seek a doctor if you don't feel well and you do have access to proper medication.
- you will probably NOT be dangerous to people around you: the 1 virus who got you has had an enormous chance of managing to infect you across specie barrier. To infect another human, it would need to have the same luck twice in a row. *very-very-very* unlikely... but...
- ...if you happen to have a normal human flu virus inside you at the same time, due to the special way in which influenza genetics works, then there's a risk that both will mix and produce a hybrid which has the human flu's ability to bind to and infect human cells easily.
(Same logic as above also applies to pigs but with a much higher risk for them catching a bird flu)

So I stand by what I've said before:

Yup, I happen to have a medical degree, and an additional degree in bioinformatics, if that's of any interest for you.

This is one of the few cases where RMS's rambling about GNU and how distros should be called "GNU/Linux" actually makes sense.

LINUX is only a KERNEL.
As in the stuff that directly talks to your hardware and handles low-level stuff.

Above this kernel, you need a "userland" actual regular programs which are called.
And Android DOES NOT use the same GNU userland as most distributions.
Whereas regular distribution are "GNU/Linux" (i.e.: runs the Linux kernel and a bunch of userland program, lots from the GNU project [for low-level stuff like C library, shell, etc.], but quite a lots of other stuff [KDE, Firefox, LibreOffice.org]) and are fully POSIX compatible and can run almost any general purpose UNIX software out of the box (as long it was compiled for it), Android is Linux kernel + a very special userland made by Google (among which the most well known part is the Dalvik java-like environment. Even the C library is Google's own Bionic instead of the usual glibc, ulibc and other forks).
Out-of-the box, Android doesn't run most Unix software because several parts are missing.

(This is different from other mobile OS: Maemo/Meego/whatever-the-nom-du-jour-is, OpenMoko's SHR, Palm/HP WebOS, etc. all run a normal GNU/Linux stack, although in WebOS case, it uses a non standard gui instead of X.
Even router provide a unix like environment, only using more light-wieght embed-friendly components like Busyboy and ulibc or eglibc and without a graphic interface at all)

Again, the usual user-land, the "GNU/" part of "GNU/Linux" is missing.

That's what your compensating by running a Debian chroot. You provide the missing userland.

You share the same kernel (Linux), but run a different set of userland programs on it. You provied a C library (I think Debian moved to eglibc ?) a shell, and hundreds of other part that make the userland environment. You provide back the "GNU/" part of "GNU/Linux".
And now, thanks to all the pieces provided by your chroot, you can run any Unix code.

Now, indeed, this is possible because Android uses the Linux kernel as a foundation, and its opensource make it possible to port a Debian userland to Android and run it along the normal system. So in a way you're right.

But I insist, Android is unlike any other GNU/Linux distribution around. (And until recently, it needed some special kernel functions that weren't in stock kernels).

This is unlike other Linux based mobile device, which already are based mostly on these pieces. You don't need to provide them. You can already run most of what you want on Maemo/Meego, OpenMoko, webOS based device (except for the part of webOS lacking X out of the box).

Out of the box, an Android machine is designed to run the default apps packaged with it and to fetch special android-apps from a special app market.

Now, thank to the general openness of the platform, it is possible to repurpose it, but out of the box, this is not your regular Unix-like OS. You need to install a chroot, or at least a lot of userland components.

And that's what the parent was referring to:
- Android stick : runs android, designed to run a few android apps (but you can do more if you want).
- RPi : runs a GNU/Linux disto, designed to pretty much do anything you want out of the box.

Android makes the device limited to run only Android apps out-of-the-box, unless you go out of the way and install the missing userland bit to turn it into a full Unix-like box.
But thanks to the open nature of the Linux kernel, this is actually possible. (It's not a locked down device that needs to be hacked)

Android and the classic Unix-like userland (of debian) are completely orthogonal one to another.

NO. YOU. CAN'T.

First and fore most:
- Influenza is a virus.
- It doesn't have a biochemistry of its own, it must use its host's. outside of a cell it's just an inert object.
- It is produced by one infected cell in the sick individual. And needs to reach a fresh cell within its (short) life time.
(its a virus containing RNA, and not encapsulated in a protein shell but in a lipid membrance. This means it won't survive long without a host cell whose biochemistry to use).
In short: that means that it must be quickly sneezed onto someone else (aerosol and particulate transmission). IT CANNOT STAY LURKING FOR A LONG TIME OUTSIDE IT'S PREVIOUS HOST UNTIL IT MEETS A NEW ONE.
This a *virus* (and a fragile one). Not a *bacteria*, not a *bacteria's spore*. Not a parasite. Nor one of the few more durable viruses wich might, under the right condition, resist a longer time until finding a new host (HIV viruses hidden inside the needle of a used syringe can survive a few hours before finding a new host)

- That means you need a living host, with living cell secreting viruses to transmit it.
- A fried émicé in a nice curry sauce sevred along a side dish of rice *DEFINITELY FAILS* the "living cell" definition.

Also, if you're cooking impaired:
- poultry meat is ALWAYS served thoroughly cooked. chicken are rather filthy animals and if you don't cook their meat, you're at high risk of food poisoning due to parasites, bacteria, and other stuff. Influenza is the least of your problems. YOU CAN'T EAT CHICKEN RAW.
- cooking destroys and sterilise almost anything (the only exception are prions. prions could somewhat survive some amount of cooking and still be able to replicate afterward. mad cow disease CAN BE transmitted by cooked food, but that's an exception)
- viruses will be *COMPLETELY DESTROYED* during the cooking (along with all the other bad stuff. this make the food safe and edible. cooking was invented exactly for this purpose) the only usual risks that remain after cooking are non infectious but chemical (pollution, toxins, poison).

Last but not least:
- Avian flu (H5N1) is *A. BIRD. DISEASE*.
- It's got a Haemagglutinin 5 (H5) on its surface - that's were it's codename comes from.
- H5 binds to bird cell. It can easily infect birds.
- H1, H2 and H3 are the one binding to human cells. You would need on of these to infect humans.
- It can only *very very very rarely* enter a human host, only by sheer luck, almost *by error*. We're speaking about a few dozens of individuals each year during avian flu outbreaks, and this is mostly the poeple who are exposed to birds a lot (the farmers handling them working in the overcrowded farms with thousand of chicken cramed in a small place. not the guy eating a chicken wing).

So even if the virus was magically able to survive a long time outside a living host (it doesn't) AND even if the virus was able to magically survive cooking (it doesn't neither) chance for catching avian flu through eating are close to none.

On the other hand, if you're a poor farmer working daily on a farm with thousands of chickens packed together and if an avian flu epidemic spreads among your flock, there's a small chance for you to catch it to. (And sadly for you, because you're a poor farmer in the backland and not a wealthy citizen in the big city, you will let the disease evolve without treatment, hoping that it will end on its own, and you might have a complication, like a pneumonia).

In short:
- You can catch bird flu, if you're a living bird and another living bird sneeze on you.
(Among birds, the oro-fecal pathway works too. Don't peck neither on other birds' fresh shit)

- You can catch bird flu, if you're a (living) human and you got sneezed on by sick birds several thousand times a day in the tiny overcrowded farm where you work and you are not lucky.
If you're already sick and *really not lucky at all*, you could even father a human-spreading hybrid.
(- same as above, but higher risk rates, if you're a pig).

- You *CAN'T* catch bird flu, if you're a (healthy) human eating a deep fried chicken.

Thank you for repeating the second half of my post.
That explains why an epidemic of flu among chicken is problematic to humans.
Bird flu is not dangerous to humans per se. But if it spreads among birds, you increase the chance of making a hybrid which will be abble to spread among humans.
That's one of the reason will you want to avoid a bird flu epidemic among birds.

As I said, you don't want 1 virus managing to win the mutation/evolution lottery and gain capability to spread among humans.

Read your quote. The problem is not Android it self, the problems are BLOBs (binary large ojects) - big pieces of non-free software that is installed on some machine and is required to run them.

Android it self is open-source. You can get 3rd party modified builds (like CyanogenMod), a sure sign that the freedom to tinker (FSF's and RMS's goals in life) are respected. BUT...

Several ARM chipsets (including the one used in the TFA's motherboard) need a proprietary binary driver for the graphic core. (Some other components, like webcam, and radio interfaces, might need such modules too. Like the camera of HP's phones and tablets. At least for this laptop, TFA's author plan to USB webcams so it would be easy to select some standard UVC cams).

So the stuff installed on an Android phone might not be entirely opensource. You can get a 3rd party firmware, but you're not entirely free to tinker it: you might need non-free bits (mostly the openGL ES modules and drivers) to make it work.

FOR NOW.

People reading sources like Phoronix might have noticed that some mobile GPUs are either getting reverse engineered drivers (similar to Nouveau for Nvidia on the desktop) or even getting collaboration from the original manufacturer (like the opensource drivers for AMD on the desktop).
Lima for Mali, Freedno for Adreno, even Nvidia having released specs and code for the 2D part of Tegra, etc.

So, someday it should be possible to install a fully opensourced variant of Android on your phone/tablet/netbook. Although maybe not with all feature fully functional (it's going to take some time until the opensource drivers are on par with the current closed source BLOBs. And some other parts, like webcams, might still not be opensourced).

I addition to RMS's rant, I should add another problem: DRM/Tivoization. Some devices don't let you install your arbitrary firmware, and require you to jump through hoops in order to be able to run non-signed code. (like the whole story with "Gold-Cards" and replacing the booting firmware on some HTC phones).

As the author/copyright holder of the code of Android, they can do pretty much anything they like with their own code. (as any author holding copyright on any other piece of software can, too. Even Linus could make shit with the few parts of the Linux kernel he holds copyright on. Except that, as the copyright of Linux parts is distributed among lots of authors, the possibilities are much more limited).

In addition to that, the code is licensed under a BSD-like license. 3rd parties using it aren't require to release it either (the phone manufacturer aren't required to publish their modifictaions. Don't hope of HTC releasing their HTC Sense).

Now, the most critical part is the Linux kernel, and due to its GPL licensing, 3rd parties like Google and manufacturer ARE REQUIRED to publish their modifications, and they do.
So anything required to boot an android device (minus binary drivers and DRM as mentioned before) is available, even if you might be limited to use another users space (using stock opensource android, instead of HTC's sense).

As of google delaying releases (well beside the fact that as mentionned before, they have the right to do it being the authors and copyright holder) well:
- They have explained their reasons: Android 3.x was a quickly hacked/cobled together version to have it run on tablets. The code was a hackish mess, they didn't want to publish the code until having cleaned and stabilised it for Android 4.x.
- They have always kept their promise to release code (even if they weren't required to): Android 4x *IS* out.

And most importantly:
free software is above all about the freedom to tinker.
the current situation doesn't prevent these freedom.
even if the manufacturer and/or carrier are assholes and refuse to upgrade the firmware and you're stuck with a buggy Androird 3.x derivative on your device,
you can still get a 3rd party free alternative firmware, and boot your own custimozied linux kernel, with your own compiled andoird 4.x on the device. (like for example a firmware from Cyanogen).

Again, the only limits are availability of drivers as mentioned in your quote of RMS. And DRM making the installation of 3rd party more difficult.
The slowness of google release and a skipped version (again, skipped. as in "there's no public 3.x, wait for the 4.x version very soone". not as in "we'll definitely stop releasing code after 3.x forever") doesn't prevent your freedom, at worse it requires a little bit patience.

I still don't get it why such things are considered "security question".
The only thing they might protect against is a completely blind random automated probing.

And I can't understand why in 2012 anyone would still give actual answers to this question: it take a couple of seconds maximum to find the relevant info on facebook.
If you can't block such security holes, at least use some form of joke or pun: you mother's maiden name is "Chtulhu" or "this is none of your business" as First pet, etc.
If a celebrity use as security measure, an info that 99.9% of her fan know already, she almost deserve to get her nude pic uploaded.

(and that's ignoring the fact that some of them would probably enjoy the free publicity).