I don't know whether it is true whether Chinese eat more calories (I'd be sceptical). From trips to the north of China I've noticed their food is quite different to western food. Chinese there do not eat highly-refined foods as much as we do. Indeed, there is very little sugar in their foods. Their meals have substantial amounts of fresh vegetables, which tend to be cooked more lightly than over here. The most refined things they eat are the dough of their breakfast buns and pancakes, and of their dumpling & won-ton skins! When they snack, they seem to snack mostly on fresh fruit and nuts.
The calorific content stated for foods here is determined by burning up the food-stuff. I.e. it determines more the/maximal/ energy content. However, our bodies efficiency at digesting food is not uniform. Fibreous and/or more whole foods are literally harder to digest than more refined foods - it literally takes more energy to break such foods down than the more refined foods. Some of that energy goes toward the extra bacteria that are required to pre-process and break-down the extra fibre. Some of that food will literally go undigested, and through us.
MSG is a natural seaweed extract, which has been used in Asia for a long long time. There's nothing wrong it. The big problem with ready-made, convenience dinners is fats and, especially, salt. They always seem to be *stuffed* with salt.
The sugar in fruit is bound together with fibre and cells from the fruit. It's harder to digest than fructose in more refined, low-fibre foods. Plus, all the fibre of the fruit will make you feel full quicker. It's very hard to get fat on raw fruit.
It could display 24x32 graphics characters, where each graphics character was 2x2, so 64x48 effectively. It's not at all unusual for favicons to be 64x64, so yes - less resolution than a favicon.;)
The parent is not a troll. There's a powerful message there, even if some reading it will feel uncomfortable with it - try avoid the knee-jerk reaction.
Commodore 64? 16 colours? Luxury! When I wur a lad we had ZX81s, and pixels were black & white, and we had fewer of those than the "favicons" that browsers show in the address bar for a website!;)
This vulnerability was already demonstrated on german TV, a good few years ago. The security expert who demonstrated it actually got enough material through for a nice thermite bomb, using a normal side-pocket of a jacket as well as his mouth.
And exactly the same situation in AF447, the 2nd office / right-seat co-pilot (and pilot-flying initially) kept pulling on the stick. At least with coupled yokes, such as in IX-212, that this is occurring is clear to the other pilot who can then take some physical action. On AF447, because on Airbus there is no cross-stick control-input feedback and because resultant command is averaged from both stick inputs, the 1st office / left-seat pilot and the captain were left completely unaware that the right-seat co-pilot - who had been ordered to relinquish control - was still pulling on the stick. They spent over two and a half minutes falling, stalled, out of the sky, with the 1st officer trying to recover the aircraft and the 2nd officer preventing this from having any chance at all by pulling on the stick. Even towards the end, ~40s before impact, when the 2nd officer let slip he'd been pulling back and was ordered repeatedly to let go of the control, he still kept pulling back (though at that point, it was almost certainly too late).
No, the Airbus FMSes go into alternate law when they lose speed data. In alternate law the FMS does not apply any envelope protections to control inputs - the pilots have unfettered control. This was the case in the AF447 crash. The reason for its crash appears to be that the 2nd co-pilot first stalled the aircraft at high altitude, and then continued to apply control-inputs that prevented the other pilot from recovering from the stall. AF447 was literally flown into the sea by the junior co-pilot. Sadly, because of the design of the controls, neither the more experienced co-pilot (acting as pilot-in-command in the left hand seat), and the captain (behind them, he came in once the plane was already stalled) had any idea that the junior co-pilot was applying inappropriate commands to the control stick.
Popular Mechanics had a good article recently on AF447, including detailed CVR extracts. One thing that needs to be changed though is that the Airbus average the control inputs from each stick, and does not give any feedback to either pilot that the other is applying a contradictory input. In older aircraft control yokes were mechanically linked, and it was entirely obvious to each pilot what the resulting command to the aircraft was, and what pressure was being applied. Airbus need to add this to theirs (and do Boeing do too perhaps?).
3 button mice existed long before mice with scroll wheels were common. Unix systems nearly always had 3 button mice, and PC Unix/Linux users usually managed to get their hands on such mice too. (E.g. Logitech made the mice for SGI and for later Sun boxes, and made PS/2 versions). Flightgear of course started out as a Unix/Linux flight sim.
What you're complaining about isn't bad UI design per se, but that you were using a windows port of software designed for Unix user hardware.
It's quite legitimate to want to minimise your exposure to radiation. Dosages basically relate probability that particles will adversely interact with your tissues. These probabilities are additive - the risks of radiation exposure are cumulative. So whether to allow yourself to be irradiated is a risk/benefit analysis. When you fly you have decided the benefit of travelling outweighs the risk of the increased galactic radiation at altitude. Back-scatter X-rays OTOH do not have a direct benefit to the individual, and some people feel they have no benefit at all (you can easily conceal things from them). Thus, without any benefit, there is nothing to offset the risk of even the low exposure.
Further, the low radiation dose relates to optimal operation. Radiographic equipment in hospitals are operated by very highly-trained people, and are checked daily. Even so, on rare occasions such equipment does malfunction and injure and even kills people. We accept this because the benefits of such equipment greatly outweighs the risk. Back-scatter X-rays scanners in airport situations are being operated by people with very little education, and without the rigorous maintenance schedules of medical X-rays. Yet these machines are *just* as capable of delivering lethal doses of X-rays should they malfunction. Should we tolerate the inevitable rate of deaths from malfunctioning backscatter machines (low as that rate might be) when the benefits of these machines are so questionable, perhaps non-existent?
It's all about risk/benefit analysis. Just because one risk is beneficial enough to be worth taking does not mean some other risk is worth it - even if lower.
Well, weigh the probability that the child being used by a terrorist, versus the probability the screener is a paedophile. There are a lot more paedophiles out there than terrorists, so the latter is going to be at least an order of magnitude more likely, particularly if TSA screener is a job that gives you reason to touch kids.
PS: A pedophile is someone who likes feet, while a paedophile is someone who likes children. Different words...
It may be in some circumstances, it may not be in others. Note carefully "of itself" in my post. I.e. IPC, of itself - or any other mere technicality - is not necessarily sufficient to affect copyright derivation status. IANAL, but this is corporate, legal advice I've been privy to.
E.g. (And this is just *my* laymans understanding, NB) if the copyright holders of some work go out and deliberately create a well-defined, stable plugin architecture intended for general use, then other works that code to that interface need not be derived of the work providing the plugin interface - particularly so if the functional nature of that plugin interface is demonstrated by a 2nd implementation. OTOH, if you want to extend someone else's work, such that your work would be derived from it, and you think that by putting a bit of IPC in there you escape, think again - a judge or jury need not be impressed by "But, we're not infringing cause we shove what would otherwise be infringing function calls first through some shared memory! But we released the code to the modifications we made to add the ad-hoc IPC!".
Other than some underlying systems bits that's copyleft (Linux kernel, Bluez, some system utils), or BSD licensed, Google generally own most of the Android code outright. So Google don't ever have to release Honeycomb. It's their code, they don't have to give source if they don't want to. (That said, I reckon their bluetooth stack depends sufficiently on BlueZ that their userspace becomes derived from that GPL code - stuffing IPC between your code and GPL code does NOT, of itself, mean your code escapes from the GPL; but that still doesn't mean they'd have to release their code).
Apple OTOH started WebKit/WebCore as a fork of KHTML, which is LGPL. So it wasn't their code at all to start with and, unless they're rewritten ALL the code since the fork AND gotten appropriate grants from the other contributors to WebKit, Apple are obliged to honour the *other* copyright holders and follow the LGPL licence.
That link is precisely the case I was referring to (and also linked to by the Wired article I linked above). So which part of "Boeing designed the 787" (note the *past tense*, and note this was after 9/11 and locked cabin doors, and, especially, note my last sentence stating I presumed this had already been fixed) was incorrect? I'm all for nitpicking, but...
Ok, sorry, yes, the reactor in Fukushima is inside a concrete shell. However, the storage pool is not. Further, the Fukushima concrete shell was not designed for explosive or impact containment, because it seems it was broken apart by the hydrogen explosion in at least one of the reactor buildings (which I gather was outside of the concrete containment). Pictures taken from the air of the damaged buildings appear to show the top of the actual reactor pressure vessel (which was itself inside a steel containment vessel) exposed in at least reactor 4:
I.e. the Fukushima design does NOT appear to have had any high-strength concrete containment, other than one designed for general structural support and low-pressure vapour/liquid containment.
Slashdot Mirror
I don't know whether it is true whether Chinese eat more calories (I'd be sceptical). From trips to the north of China I've noticed their food is quite different to western food. Chinese there do not eat highly-refined foods as much as we do. Indeed, there is very little sugar in their foods. Their meals have substantial amounts of fresh vegetables, which tend to be cooked more lightly than over here. The most refined things they eat are the dough of their breakfast buns and pancakes, and of their dumpling & won-ton skins! When they snack, they seem to snack mostly on fresh fruit and nuts.
The calorific content stated for foods here is determined by burning up the food-stuff. I.e. it determines more the /maximal/ energy content. However, our bodies efficiency at digesting food is not uniform. Fibreous and/or more whole foods are literally harder to digest than more refined foods - it literally takes more energy to break such foods down than the more refined foods. Some of that energy goes toward the extra bacteria that are required to pre-process and break-down the extra fibre. Some of that food will literally go undigested, and through us.
Not all calories are equal.
MSG is a natural seaweed extract, which has been used in Asia for a long long time. There's nothing wrong it. The big problem with ready-made, convenience dinners is fats and, especially, salt. They always seem to be *stuffed* with salt.
The sugar in fruit is bound together with fibre and cells from the fruit. It's harder to digest than fructose in more refined, low-fibre foods. Plus, all the fibre of the fruit will make you feel full quicker. It's very hard to get fat on raw fruit.
It could display 24x32 graphics characters, where each graphics character was 2x2, so 64x48 effectively. It's not at all unusual for favicons to be 64x64, so yes - less resolution than a favicon. ;)
The parent is not a troll. There's a powerful message there, even if some reading it will feel uncomfortable with it - try avoid the knee-jerk reaction.
Commodore 64? 16 colours? Luxury! When I wur a lad we had ZX81s, and pixels were black & white, and we had fewer of those than the "favicons" that browsers show in the address bar for a website! ;)
This vulnerability was already demonstrated on german TV, a good few years ago. The security expert who demonstrated it actually got enough material through for a nice thermite bomb, using a normal side-pocket of a jacket as well as his mouth.
That is a crucial detail. Thanks for adding this info about the priority button and the auditory feedback.
And exactly the same situation in AF447, the 2nd office / right-seat co-pilot (and pilot-flying initially) kept pulling on the stick. At least with coupled yokes, such as in IX-212, that this is occurring is clear to the other pilot who can then take some physical action. On AF447, because on Airbus there is no cross-stick control-input feedback and because resultant command is averaged from both stick inputs, the 1st office / left-seat pilot and the captain were left completely unaware that the right-seat co-pilot - who had been ordered to relinquish control - was still pulling on the stick. They spent over two and a half minutes falling, stalled, out of the sky, with the 1st officer trying to recover the aircraft and the 2nd officer preventing this from having any chance at all by pulling on the stick. Even towards the end, ~40s before impact, when the 2nd officer let slip he'd been pulling back and was ordered repeatedly to let go of the control, he still kept pulling back (though at that point, it was almost certainly too late).
The lack of feedback is lethal.
FbW aircraft still use hydraulics to actuate the actual surfaces. E.g. the A380 has 2 separate, redundant hydraulic systems.
No, the Airbus FMSes go into alternate law when they lose speed data. In alternate law the FMS does not apply any envelope protections to control inputs - the pilots have unfettered control. This was the case in the AF447 crash. The reason for its crash appears to be that the 2nd co-pilot first stalled the aircraft at high altitude, and then continued to apply control-inputs that prevented the other pilot from recovering from the stall. AF447 was literally flown into the sea by the junior co-pilot. Sadly, because of the design of the controls, neither the more experienced co-pilot (acting as pilot-in-command in the left hand seat), and the captain (behind them, he came in once the plane was already stalled) had any idea that the junior co-pilot was applying inappropriate commands to the control stick.
Popular Mechanics had a good article recently on AF447, including detailed CVR extracts. One thing that needs to be changed though is that the Airbus average the control inputs from each stick, and does not give any feedback to either pilot that the other is applying a contradictory input. In older aircraft control yokes were mechanically linked, and it was entirely obvious to each pilot what the resulting command to the aircraft was, and what pressure was being applied. Airbus need to add this to theirs (and do Boeing do too perhaps?).
3 button mice existed long before mice with scroll wheels were common. Unix systems nearly always had 3 button mice, and PC Unix/Linux users usually managed to get their hands on such mice too. (E.g. Logitech made the mice for SGI and for later Sun boxes, and made PS/2 versions). Flightgear of course started out as a Unix/Linux flight sim.
What you're complaining about isn't bad UI design per se, but that you were using a windows port of software designed for Unix user hardware.
It's quite legitimate to want to minimise your exposure to radiation. Dosages basically relate probability that particles will adversely interact with your tissues. These probabilities are additive - the risks of radiation exposure are cumulative. So whether to allow yourself to be irradiated is a risk/benefit analysis. When you fly you have decided the benefit of travelling outweighs the risk of the increased galactic radiation at altitude. Back-scatter X-rays OTOH do not have a direct benefit to the individual, and some people feel they have no benefit at all (you can easily conceal things from them). Thus, without any benefit, there is nothing to offset the risk of even the low exposure.
Further, the low radiation dose relates to optimal operation. Radiographic equipment in hospitals are operated by very highly-trained people, and are checked daily. Even so, on rare occasions such equipment does malfunction and injure and even kills people. We accept this because the benefits of such equipment greatly outweighs the risk. Back-scatter X-rays scanners in airport situations are being operated by people with very little education, and without the rigorous maintenance schedules of medical X-rays. Yet these machines are *just* as capable of delivering lethal doses of X-rays should they malfunction. Should we tolerate the inevitable rate of deaths from malfunctioning backscatter machines (low as that rate might be) when the benefits of these machines are so questionable, perhaps non-existent?
It's all about risk/benefit analysis. Just because one risk is beneficial enough to be worth taking does not mean some other risk is worth it - even if lower.
The deployed systems in the USA, used by the TSA, are largely back-scatter X-ray, aren't they?
Well, weigh the probability that the child being used by a terrorist, versus the probability the screener is a paedophile. There are a lot more paedophiles out there than terrorists, so the latter is going to be at least an order of magnitude more likely, particularly if TSA screener is a job that gives you reason to touch kids.
PS: A pedophile is someone who likes feet, while a paedophile is someone who likes children. Different words...
The SGI logo was cooler: http://www.youtube.com/watch?v=Nqf6TjE49N8
Harmony is Apache licensed, which is a BSD++ licence: No source redistribution is required at all.
AFAIK, the kernel bits are available from Googles' android trees on kernel.org.
It may be in some circumstances, it may not be in others. Note carefully "of itself" in my post. I.e. IPC, of itself - or any other mere technicality - is not necessarily sufficient to affect copyright derivation status. IANAL, but this is corporate, legal advice I've been privy to.
E.g. (And this is just *my* laymans understanding, NB) if the copyright holders of some work go out and deliberately create a well-defined, stable plugin architecture intended for general use, then other works that code to that interface need not be derived of the work providing the plugin interface - particularly so if the functional nature of that plugin interface is demonstrated by a 2nd implementation. OTOH, if you want to extend someone else's work, such that your work would be derived from it, and you think that by putting a bit of IPC in there you escape, think again - a judge or jury need not be impressed by "But, we're not infringing cause we shove what would otherwise be infringing function calls first through some shared memory! But we released the code to the modifications we made to add the ad-hoc IPC!".
IMLU, ICBW, etc.
Other than some underlying systems bits that's copyleft (Linux kernel, Bluez, some system utils), or BSD licensed, Google generally own most of the Android code outright. So Google don't ever have to release Honeycomb. It's their code, they don't have to give source if they don't want to. (That said, I reckon their bluetooth stack depends sufficiently on BlueZ that their userspace becomes derived from that GPL code - stuffing IPC between your code and GPL code does NOT, of itself, mean your code escapes from the GPL; but that still doesn't mean they'd have to release their code).
Apple OTOH started WebKit/WebCore as a fork of KHTML, which is LGPL. So it wasn't their code at all to start with and, unless they're rewritten ALL the code since the fork AND gotten appropriate grants from the other contributors to WebKit, Apple are obliged to honour the *other* copyright holders and follow the LGPL licence.
Sure. The bone I'm picking is with the ancestor comment that claims all the dangerous stuff is safely under plane-impact proof, 10ft thick concrete.
That link is precisely the case I was referring to (and also linked to by the Wired article I linked above). So which part of "Boeing designed the 787" (note the *past tense*, and note this was after 9/11 and locked cabin doors, and, especially, note my last sentence stating I presumed this had already been fixed) was incorrect? I'm all for nitpicking, but...
Where are my mod-points? :)
Ok, sorry, yes, the reactor in Fukushima is inside a concrete shell. However, the storage pool is not. Further, the Fukushima concrete shell was not designed for explosive or impact containment, because it seems it was broken apart by the hydrogen explosion in at least one of the reactor buildings (which I gather was outside of the concrete containment). Pictures taken from the air of the damaged buildings appear to show the top of the actual reactor pressure vessel (which was itself inside a steel containment vessel) exposed in at least reactor 4:
http://cryptome.org/eyeball/daiichi-npp8/daiichi-photos8.htm
I.e. the Fukushima design does NOT appear to have had any high-strength concrete containment, other than one designed for general structural support and low-pressure vapour/liquid containment.
Here you go: http://www.wired.com/politics/security/news/2008/01/dreamliner_security