That would make sense if you had to pull bios with an article, which should hardly be the case. At most, you'd have to pull in current authors' affiliations. A bio would ideally stay behind an author link, and be pulled in quite rarely. I for one would much rather have a list of authors immediately followed by the abstract than having to move through several pages of biographies for an article with 4-5 authors in order to find the abstract an the actual article. So for me the decision to put every bio in every article looked like a poorly researched one. YMMV and all that.

There are no valid cases for assert() in release code. It's about as uninformative as it gets for that. If you really need thosue checks done, put an actual check in place - you know, something that will log/tell you useful information like what invalid value was encountered versus what was expected, a stack trace, and so on. Not just printing out __FILE__ and __LINE__ and expect what, that the customer will have a debugger already attached to the process to pick up the rest of the info a developer would need?

assert() is a debug macro. If you need to test release code then use/write something appropriate for release. Especially something that does not abort() when returning an error code would be sufficient.

What's stopping you to make a special locked-down profile for it in selinux, apparmor or whatever favorite RBAC system you have and then check for access violations? THEN you'll know if it messes up with the system.[*] Or are you trying to argue that the client is bidding its time now, playing it safe and will do the nasty things only when Skynet becomes operational?

[*] Of course, 'demonstrate' is not what this would be doing. One can't demonstrate absolute safety on a system that can update itself any more than one can predict the future. However, one can obtain a reasonable system lockdown with judicious use of RBAC and if that is not enough for you then maybe you shouldn't be contemplating gaming on such a high-security-requirements machine in the first place.

Mate, your opinions on yourself are your own business and those on myself are lighter than a feather, so please consider not wasting page space next time. As they say, stones and sticks may break my bones and all that jazz.

Now as to your question. A picture of your face is in the majority of cases not a definitive means of identification - especially the limited type in photo IDs. Maybe you've heard of people looking alike. Perhaps that's one reason why some places (like banks) would ask you for 2 photo IDs for identification? OTOH a fingerprint is supposed to be a unique means of identifying a person. Try proving your innocence in court if the prosecution has only a picture of someone looking like you, versus them having found your fingerprint at the scene.

So you're unknown to the government if they don't have your prints now? I guess before this breakthrough invention a census was a meaningless exercise. And IDs and passports a joke. And paper trail for taxes, properties and so on just something to kindle fire. Oh, how silly of so many other countries.

Yeah, whoever heard of things that you either have or don't. Also, you're a little pregnant, you know?

Right. Of course. And whoever does not fully trust that bunch of selfish bureaucrats is a traitor. Or a terrorist. Or something. Mussolini would be proud of you, son.

Huh? Encrypted bits are asthmatic and can't run as fast as unencrypted ones? Coming from someone at Google this statement is quite the WTF. Is it too technical now to say that encrypting data requires extra calculations which introduce delays so gmail will respond somewhat slower?

I think it's a neat calculation. We've all lost track of what fast actually means for a modern CPU.

Yeah, it's a fast CPU. And it gets faster if you have smaller hands. Or if you watch your hands move by at close to the speed of light. Way cool.

Should sell like crazy in Japan.