Theory is all fine and dandy, but there is a wealth of evidence to suggest just the opposite of what you propose.
I didn't give you theory, I gave you FACT. A fact is something that can be independently verified; and I gave you links to studies and standards concerning exposure to microwave radiation.
...
By no means are the proposed mechanisms [that you referenced] necessarily correct, nor will they explain everything, but your assertion that it is impossible for cell phones to cause cancer is not only poorly thought out, but negligent of the harm that it causes when naive individuals take you at your word.
In other words, what you've given me is speculation. It's exactly this kind of speculation which has gotten us where we are today; where people are afraid of cell phones and cell towers for no proven reason. I'll attempt to read up on the biological mechanisms you've referred to in order to try to understand them, but until I find proof that negates the prior evidence I have that EM radiation is not cancer-causing, I'm maintaining my original position.
The answer is no; the different frequencies travel separately and do not "mix".
Why does it work that way for sound and not for radio frequencies?
It doesn't work that way for sound, either; if it did, then if two people spoke at once you wouldn't be able to hear them both -- the sounds would MIX and change frequencies, scrambling the sound. Since that doesn't happen, the sounds from the two people travel independently, too.
IIRC, this is how the idea of microwave ovens came about - high power radar dishes (which operate in the microwave spectrum) were literally cooking birds to death that roosted in front of the dishes - and they roosted there because the air was nice and warm...
They tested this on Mythbusters, strapping a chicken carcass to front of a high-powered radar dish. After several hours, the chicken was still the same temperature as when they started. So even high-powered microwaves won't necessarily hurt you.
I heard the myth of birds being cooked by radar dishes, too. I don't know if it's true, but the respected documentation of where the microwave oven came from is in the document "The History of the Microwave Oven: A Critical Review" by John M. Osepchuk, ISBN number 978-1-4244-2804-5/09. In case you don't find the document, the microwave heating effect was found by Percy Spencer in 1945-1946, who was then working at Raytheon Manufacturing Company. That's a lot earlier than most people would expect.
The reason is that the frequencies cell phones use are below the spectrum of ultraviolet light. It is near the spectrum of ultraviolet light where the first ionizing radiation occurs, which is required to be able to cause cancer. Ionizing means that the energy level of the individual photons of the transmission have enough energy to disturb the molecular structure of live cells.
Certain viruses, such as HPV, can cause cancer without ever producing anything in the EM spectrum more energetic than miniscule amounts of IR radiation. It probably is the case that cell phones don't cause cancer, and theoretical considerations are important, but it'd be foolish to not regard the observational data as the real arbiter of this. If a statistically robust connection is found, then the interesting thing is to find out how that can happen.
On theoretical grounds, dark energy either doesn't exist, or it should be 10^(huge number) times larger. But observations clearly show that it's real.
I understand your desire for observational data to draw your own conclusion -- that's cool. The IEEE C95.1 report has 76 pages of it dedicated to listing all of the hundreds of references to documentation and studies on the subject. It's nearly impossible to find online, but at least at one time is possible to find the PDF form by searching for the ISBN number. Give that a try and see what you find.
Print: ISBN 0-7381-4834-2 SH95389 PDF: ISBN 0-7381-4835-0 SS95389
So, perhaps some type of very localized heating might lead to accelerated cell growth with higher replication error rate which then gives cancer. This suggestion is likely totally bogus, but is intended to illustrate the way some type of alternative mechanism to ionizing radiation might come into play. i.e. data is always the master, not the theory.
The idea you've given is that somehow a higher replication rate causes cancer. I have no idea whether that idea has merit or not, but it sounds like speculation.
The whole problem with the idea that cell phones cause cancer is that it's based on speculation. It's much more difficult to disprove an idea than it is to prove it; and that's why more speculation won't help.
Ionizing radiation is not why cells phones maybe dangers to your brain. I remember seeing a TV News spiel about this and it was even smart enough to explain that the worry was heating the brain like a microwave does. More specifically heating small blood filters which when heated became ineffective allowing pollution and waste byproducts into sensitive brain tissue. I think there is even some worry on it's effect on mental health.
Well, again, even this doesn't make sense, because the cell phone only transmits a couple of watts, which isn't enough to do any effective heating. Heck, the actual *heat* the cell phone itself has to dissipate does more heating than the transmitted energy does. A microwave oven magnetron tube typically transmits between 500 W - 1000 W in a sealed RF enclosure, so that any energy that isn't absorbed by the water molecules in the food bounces around the RF enclosure until it does. A cell phone radiates in nearly an isotropic pattern (in all directions, like a bare light bulb does), so even those couple of watts (at most) that is transmitted, more than 50% of it never makes it to your head even when the cell phone is against your ear. Also, the antennas in cell phones are down by the mouthpiece these days, to keep the transmitting antenna from interfering with hearing aids.
And when it comes to the brain, why would there be blood filters in it? If there were, how would the waste that was filtered be expelled? Isn't this the job done by the kidneys? See, that doesn't make sense, either.
I don't doubt that you saw what you saw on TV, though; the idea that cell phones are dangerous and is a very popular opinion. I don't think the argument the TV news program was making has any merit.
Is it possible for multiple radio waves of a non-harmful frequency to overlap and produce harmful frequencies? It seems just from picturing it in my mind that it would work but it would produce a signal with less power.
The answer is no; the different frequencies travel separately and do not "mix". There's a device called a "mixer" which uses tiny diodes in order to create the sums and differences between two signals (the "LO" or Local Oscillator signal and the "RF" which is the input signal, and outputting a third "IF" signal or Intermediate Frequency). And if this happened inside of the cell phone itself, it would cause interference internal to the cell phone, so as the signal is processed it's done in shielded areas to protect it from it's own interference. [It's also known as "intersymbol distortion".]
I explain that as BAD STATISTICS. What is being described in the article is called CORRELATION -- but it is not proving CAUSATION. (Usually this is explained as "CORRELATION != CAUSATION.") Basically the argument they're making is A) the area around the Vatican has an unusually high rate of cancer, B) the area around the Vatican has a lot of radio aerials, therefore C) the radio aerials must be causing the cancer. However, this is an error in logic; all they know is that the area around the Vatican has a high rate of cancer, but not why.
The reason is that the frequencies cell phones use are below the spectrum of ultraviolet light. It is near the spectrum of ultraviolet light where the first ionizing radiation occurs, which is required to be able to cause cancer. Ionizing means that the energy level of the individual photons of the transmission have enough energy to disturb the molecular structure of live cells. Microwave "radiation" (which has absolutely nothing to do with nuclear radiation) is far within the level of the non-ionizing radiation spectrum, so there is no possibility of it having the energy required to cause cancer.
This is total bullshit. There are a lot of studies show the link between EM radiation at longer wavelengths than the UV causing an increase in cancer rates. I'm not even going to bother providing a references to one of the thousand papers on this subject. Just look at some studies performed in England and Belgian on the incidence of cancer for radar operators in WW2. We are speaking of other magnitudes of energy levels, but it still invalids your opening statement. Maybe you also overlooked non-ionizing biological effects?
No; as I said, the non-ionizing effects are microwave heating... and there aren't any ionizing effects. And I quoted both U.S. and international studies and standards that cover over 60 years of scientific research on the subject.
The only thing you're correct about in your comment is that there are papers as well as books that claim a link between microwaves and cancer; it's a very popular myth, and has been for over a decade. I'm saying it's a myth, and I've told you why I'm personally sure it's a myth, and I've given you some of my research on the subject....and you've given me your opinion.
And then... the eyes... Again a falsehood. The eyes are very actively cooled, and that with a very high blood flow, to cool them down from the incoming and concentrated (through the eye optics) radiation. On a very sunny day, where you have over 1 kW/m^2 of irradiance, without a good cooling, they would simply burn/cook.
I wonder how one can present such a thought out post, with calculations and everything, but with such blatantly falls information at the same time.
I never said the eyes weren't actively cooled; I said that they're the most sensitive part of the body because they don't have much blood flow due to only having capillaries in them. They're also the most sensitive because with a sufficient increase in temperature, cataracts will result. On other places on the body, an increase in temperature would mostly cause temporary damage or a burn that would heal later -- but not with the eyes.
The reason is that the frequencies cell phones use are below the spectrum of ultraviolet light. It is near the spectrum of ultraviolet light where the first ionizing radiation occurs, which is required to be able to cause cancer. Ionizing means that the energy level of the individual photons of the transmission have enough energy to disturb the molecular structure of live cells. Microwave "radiation" (which has absolutely nothing to do with nuclear radiation) is far within the level of the non-ionizing radiation spectrum, so there is no possibility of it having the energy required to cause cancer.
Cell phones use frequencies around 800 MHz to around 2 GHz or so. 3 GHz has an energy level of about 12.4 ueV; ultraviolet light where the first ionizing radiation is possible is around 124ev -- that's a 10,000,000:1 difference in energy level. Have a look at the energy level chart on the right hand side of:
or even better, see page 3 of FCC OET Bulletin 56, which is a Q&A on Biological Effects and Potential Hazards of Radiofrequency Electromagnetic Fields:
People are also afraid of the cell base stations, because they don't know how safe they actually are. The transmitters for these typically send 20 - 40 watts -- that's all. This is then sent through directional "sectored" antennas that typically have 120 degrees of horizontal beam width and only 6 to 15 degrees of vertical beam width; so the three-dimensional antenna pattern is like a 120 degree slice of a pancake, yielding gain of about 13 dBi. This focusing is where the "gain" of antennas comes from -- by focusing where the energy is transmitted.
In the U.S., the standard for specifically what frequencies and power levels are considered safe is the IEEE C95.1 standard, which is unfortunately not freely available, however there's a an overview here: http://www.interferencetechnology.com/uploads/media/AG_07.pdf
This standard is incredibly long to read, but boils down to this: the only proven effect of microwave radiation in 60 years of research is the effect of microwave heating. No cancer. Further than that, the standard narrows down to the power levels that are safe for various frequency regions concerning microwave heating.
Now, if you go through the MATH of how close you have to be to the antennas of a cell tower for it to be "unsafe", the result is pretty interesting:
Spec limit for human-absorbed power per IEEE C95-1 at 900 MHz: 50 Watts/m^2
13 dBi gain = gain of 20
EIRP = 20 W transmitted power * gain of 20 = 400 W
400 W / 4*pi*R^2 = 50 W/m^2
R = 0.636 meters
0.636 meters = 2.09 feet
So at 900 MHz and with a typical transmit power of 20 Watts and a sectored antenna with 13 dBi gain, you need to be 2 feet in front of the antenna while it's transmitting for it to be considered unsafe. This means the only way it's unsafe for a human being is if they're not only on the tower, but right in front of the antenna while it's operating at full power.
The cell phones themselves have a limit on how much power they are allowed to transmit. There are different power limits in various countries; in the U.S. the limit is 1.6 W/kg SAR, in Canada I believe the limit is 10 W/kg SAR. SAR stands for "Specific Absorption Rate". What you really want to know is "what SAR power level is unsafe?", and the answer is that in lab t
The reason is that the frequencies cell phones use are below the spectrum of ultraviolet light. It is near the spectrum of ultraviolet light where the first ionizing radiation occurs, which is required to be able to cause cancer. Ionizing means that the energy level of the individual photons of the transmission have enough energy to disturb the molecular structure of live cells. Microwave "radiation" (which has absolutely nothing to do with nuclear radiation) is far within the level of the non-ionizing radiation spectrum, so there is no possibility of it having the energy required to cause cancer.
Cell phones use frequencies around 800 MHz to around 2 GHz or so. 3 GHz has an energy level of about 12.4 ueV; ultraviolet light where the first ionizing radiation is possible is around 124ev -- that's a 10 million to one difference in energy level. Have a look at the energy level chart on the right hand side of:
or even better, see page 3 of FCC OET Bulletin 56, which is a Q&A on Biological Effects and Potential Hazards of Radiofrequency Electromagnetic Fields:
People are also afraid of the cell base stations, because they don't know how safe they actually are. The transmitters for these typically send 20 - 40 watts -- that's all. This is then sent through directional "sectored" antennas that typically have 120 degrees of horizontal beam width and only 6 to 15 degrees of vertical beam width; so the three-dimensional antenna pattern is like a 120 degree slice of a pancake, yielding gain of about 13 dBi. This focusing is where the "gain" of antennas comes from -- by focusing where the energy is transmitted.
In the U.S., the standard for specifically what frequencies and power levels are considered safe is the IEEE C95.1 standard, which is unfortunately not freely available, however there's a an overview here: http://www.interferencetechnology.com/uploads/media/AG_07.pdf
This standard is incredibly long to read, but boils down to this: the only proven effect of microwave radiation in 60 years of research is the effect of microwave heating. No cancer. Further than that, the standard narrows down to the power levels that are safe for various frequency regions concerning microwave heating.
Now, if you go through the MATH of how close you have to be to the antennas of a cell tower for it to be "unsafe", the result is pretty interesting:
Spec limit for human-absorbed power per IEEE C95-1 at 900 MHz: 50 Watts/m^2
13 dBi gain = gain of 20
EIRP = 20 W transmitted power * gain of 20 = 400 W
400 W / 4*pi*R^2 = 50 W/m^2
R = 0.636 meters
0.636 meters = 2.09 feet
So at 900 MHz and with a typical transmit power of 20 Watts and a sectored antenna with 13 dBi gain, you need to be 2 feet in front of the antenna while it's transmitting for it to be considered unsafe. This means the only way it's unsafe for a human being is if they're not only on the tower, but right in front of the antenna while it's operating at full power.
The cell phones themselves have a limit on how much power they are allowed to transmit. There are different power limits in various countries; in the U.S. the limit is 1.6 W/kg SAR, in Canada I believe t
As far as intro to programming goes, when I took High School Computer Science, our textbook was the Dietel & Dietel C++ How to Program. It was definitely aimed at the beginner to intermediate level programmers and did a pretty good job at explaining fundamentals of programming to a bunch of high school sophomores and making it understandable.
I really liked the Dietel & Dietel books, also. At SUNY New Paltz, engineering students that take C are using the Kernigham and Ritchie book, the authors of C, and that seems to be working out very well. This is where you'll find out what a "K & R block" is. Had I the opportunity to start all over again, I would have started with the K&R book, and then gone on to Dietel & Dietel.
The reason I mention this is that C is a subset of C++, so if you want to start with the basics of non-OOP C++, it might make sense to start with C, depending on your end goals. For instance, the Linux kernel is C and Assembly, not C++. C is also common in embedded systems. The other reason to start with C would be to gain understanding of pointers. These can be very useful in C++ also.
LFS user here. Will 2.6.39 get the LTS treatment just like 2.6.35 down to 2.6.32? Would be nice to have a stable target for years to come. I have a box that's still using 2.6.16 (formerly LTS) and another that's 2.4.37. Moving up from "minor" releases, e.g. from 2.6.35 to 2.6.36 haven't really been as minor as they used to be. They tend to be somewhat nerve-wracking experiences. Personally sticking to 2.6.35 as long I can.
ALL new releases of the Linux kernel are considered to be stable releases. These get security updates and fixes (at least for a couple of months) for issues are reported; the rules are "no regressions", so if something breaks that used to work, you can report it and it will get fixed.
Something you could call an "LTS" version essentially only happens when someone chooses to take ownership of maintaining a particular release for a while, usually for their own reasons. So if a Red Hat engineer decides to maintain 2.6.18 and backport drivers and fixes, you'd think of it as an LTS release, but it would mainly be that one person maintaining that branch rather than something all of the Linux developers decided to do. The maintainers as a whole have no good reason to do an LTS release a-la-Ubuntu, because every new kernel release is a stable kernel release, so from their point of view, doing an LTS release would just bog down development work.
Additionally, even when someone or a distribution (like RHEL) decides to maintain a particular kernel as if it were an LTS release for a while, the Linux maintainers generally frown upon it, because it's quite difficult to keep up with all of the changes going on in the development kernel and sometimes might be difficult or impossible to backport due to internal infrastructure changes. Thus these old kernels tend not to keep up with newer kernel features and newer drivers, which is why the kernel maintainers think trying to do this isn't worth the effort.
Now, I happen to be a person who builds his own kernel also, so I understand where you're coming from concerning the "minor" releases being a bit scary. Sometimes they are, like the Ext3 bug that happened in 2.6.19. I think the best you can do is exactly what you're doing -- which is to hold back one or two kernel versions such that they get security/bug fixes. However if everybody did that, then nobody would find the bugs to be fixed, so at the same time it's also nice to experiment with newer kernel versions in order to give the Linux kernel maintainers feedback, try out some of the new features, and to get some vision as to what is coming.
This is one area where it's nice to be able to use some kind of package management, because that way you can add your own kernel and remove it later if it doesn't work out. Generally I make such kernel packages on Debian via 'make-kpkg' which is in the 'kernel-package' package, but the Linux kernel also itself has a make target for making.deb or.rpm packages, too. (Try running 'make help' within a top-level Linux kernel directory, and look under the "Kernel packaging:" section.) I'd like to think that your LFS distribution would let you do some kind of package management.
Note: this post I made is incorrect -- so this is a retraction. The aircraft was IN A STALL but yet level, so when they reached terminal velocity, they actually DID feel 1G downward.:-/ And unfortunately since the stall warning ceased, they THOUGHT they had corrected for the stall.
I've been using KDE4 since about KDE 4.2.2, and have just upgraded to KDE 4.6.3. For the most part I really like it; it's got a long list of features and a large feature-rich set of applications, and I enjoy the Qt backend, too. There are three major exceptions to the things I like, and one minor exception.
Tthe major exceptions:
1) Strigi
2) Nepomuk
3) Akonadi
Strigi and Nepomuk are what turn most people off to KDE4, because these both cause performance problems. Strigi is a Desktop file indexer; Nepomuk deals with metatagging of files for tagging or rating. Strigi immediately wants to index files on the system as soon as you first log in, and that heavy immediate I/O load makes the first impressions of KDE4 to be poor. Nepomuk is a more consistent performance problem -- last I used it, even selecting a hundred files in Krusader took multiple seconds (and on my old Desktop, more like half a minute to a full minute). The system pretty much has no choice but to perform badly in file operations because inotify has to watch the entire system for file moves. None of these performance problems are discussed in the documentation. >:-| Discussing it with developers is extremely frustrating; it starts with "get used to it, Nepomuk and Strigi are not going away", and ending with dropping the job of documenting the performance problems onto some user's lap.
Thankfully, both Strigi file indexing and Nepomuk metatagging can be disabled within the "Desktop Search" settings. That fixes the performance problems most of the time. Last I checked, disabling these does not clear out the database, though -- on my Desktop system the Virtuoso SQL database grew to be > 2 GB as stored on the filesystem, and I had to clear that out manually. (And as I mentioned, performance was abysmal.)
Akonadi is the storage for personal information (names, email addresses, phone numbers, etc) which uses SQL for storage: and by default it wants to use MySQL server for this. Using a 30 MB MySQL server instance required just in order to hold a few contacts is overkill. There are now several Akonadi SQL back-ends such as Sqlite3, however the configuration defaults to using MySQL and changing the back-end is done on an individual basis within each user's home directory (in ~/.config/akonadai/akonadaiconnectionrc) -- and as far as I know there is no way to change the system-wide default. >:-| That is not pleasing.
So the combination ends up by default being a large SQL database file index in Virtuoso for Strigi and Nepomuk, and a separate SQL database in MySQL for Akonadi.
The last minor issue I have with KDE4 have to do with plasmoid configurability, such as the clock, network monitoring, temperature monitoring, etc. There are always details I would like to see which I cannot get to be shown, such as being able to manually choose rendering font and font size, colors, and whether or not to show a number value as well as a graph. The plasmoid configuration options change between KDE4 versions, sometimes adding features and sometimes removing them. For instance, in the previous version of KDE4 the Digital Clock plasmoid was one of the few plasmoids that allowed changing not only the font used to display the clock, but also the font size... however now in KDE 4.6.3, the font size options have been removed for that plasmoid. ? Weird
I consider KDE4 a great achievement, and I enjoy using it. At the same time, I still don't consider KDE 4.6.3 to be on-par with where KDE 3.5 left off -- KDE 3.5 was a well-oiled machine, and KDE4 is getting close but isn't quite at that same level yet.
The problem for your description, of course, is that the plane wasn't flying directly downwards, or anywhere close to that.
Yes, you're right. I "RTFA"'d, but the actual article didn't explain this -- only the original report did. I made a second reply stating this, but didn't reply to my OWN comment to make it clear I had been wrong in my first post..:-/ Best thing I can do now is to at least admit my original mistake.
1. Unless it's pressurization system was faulty (it wasn't) the pressure change wouldn't have been great. 2. Unless accelerating, you wouldn't know you were going down (or up, or banked or upside down...).
Unfortunately, you're right -- because they were stalled but yet relatively level, the passengers felt 1G downward as if they were in normal flight. So they had a brief rough ride during the initial stall, but then after they seemed to "recover" and reached terminal velocity, they felt 1G and as if everything was normal.
What's most interesting in this case is that the systems warned the pilots of an impending stall, but then once they were in a stall, there was no warning at all, as if they had recovered from the stall. That's really unfortunate.
1. Unless it's pressurization system was faulty (it wasn't) the pressure change wouldn't have been great. 2. Unless accelerating, you wouldn't know you were going down (or up, or banked or upside down...).
So the claim that the passengers probably didn't think it was anything more than turbulence is not hard to believe.
This pre-supposes that the passengers felt approximately 1G of gravity downward from their point of view, which pilots normally carefully maintain for passenger comfort. A banked turn that maintains 1G of gravity downward by carefully controlling the turn rate feels "normal" as if the plane were flying straight. Pilots can't do this in an emergency when there are systems failures.
Remove that 1G of gravity like in a free-fall, or flying straight down, and the passengers are going to become acutely alarmed very quickly. Normal turbulence of sufficient magnitude can do this -- and the conditions they were in were worse.
So put your thinking cap on for a second, and consider how it might be possible for a plane flying directly downward to somehow create 1G of gravity sideways such that from the point of view of the passengers, they feel 1G "downward". How is that possible? The only way that could be done is through centrifical force, such as if plane were pulling up, and if it's flying strait down, it's not pulling up. At best, the passengers felt gravity at their backs from the acceleration downwards. As soon as they reached terminal velocity downward, the gravity they felt would be 1G to their front. I'm quite sure that as a passenger I'd notice all of that.
I think this was three minutes of terror for everybody on that plane.
If you're running Sid, then try running 'cat/etc/debian-version' ; you'll see it reports:
wheezy/sid
You're correct that packages normally go through Sid to get to Wheezy, but that doesn't mean that every package that exists in Sid also exists in Wheezy, and vice-versa.
Recently a friend in MHVLUG decided to try running Debian because he had recently upgraded to Ubuntu 11.04 and hated it. So he asked me what I ran, I explained that I ran Debian Sid, so that's what he decided to try. Lo and behold, Perl is upgraded in Sid that week and there were package conflicts during this period, and he broke his system trying to upgrade things. [I found the upgrade tricky.] This is why for most people I recommend either Stable or Testing -- and not Sid. There's nothing wrong with running Sid experimentally and to learn more about Debian or how to deal with package conflicts and so forth -- but you need to be ready for that and to EXPECT that occasionally. And yes, Testing is covered by the Security Team, and that matters too.
Right now, if you download the latest Linux kernel via Git (see git.kernel.org), you'll get EVERY commit that ever happened since the Linux 2.6 kernel was hosted by Git. That's a LOT of commits; in fact, so many that there are several commits that have exactly the same SHA1 hash, so we're hitting SHA1 collisions.
Git is surprisingly good at compressing the Git history, but even it has its limits. For instance, we can examine the disk space usage of linux-2.6.37.y.git verses the decompressed tarball for linux-2.6.37.6.tar.bz2:
$ du -sh linux-2.6.37.y/
890M linux-2.6.37.y/
$ du -sh linux-2.6.37.6
469M linux-2.6.37.6
So this means that the Git version of linux-2.6.37.6 takes up about TWICE the disk space as f linux-2.6.37.6 does from the tarball. This means that the space being taken up by the Git history is now about the same size as the source code itself is. [And, obviously, 2.6.38 and now 2.6.39 are going to be even more so.]
The only way to fix this is to create a new major branch and migrate, possibly along with seeding the new repository with some recent history to allow 'git bisect' to be able to do something reasonable.
Please don't recommend Debian Sid for those that aren't ready for it. There is a reason it's called "unstable"; packages uploaded to Sid are "bleeding edge" and there is occasionally breakage, and the person running the box needs to be ready to handle that and know what to do and how to fix it. This isn't for everybody. Running Testing (currently named Wheezy) is a relatively safe bet.
Sid is not even a complete distribution -- Stable and Testing are, but Sid and Experimental aren't. I didn't realize this about Sid/Unstable either until I attended DebConf10 and was told so by a developer from Australia.
And if you continue to recommend running Sid, at least also tell people about installing 'apt-listbugs' so that they at least if someone else has reported grave or critical bugs on packages that they're about to install that they get warned about that. I.e. this is your "Debian Unstable condom".
The only downside to running Testing is that there are some source packages in Sid that you might need that aren't in Testing. For those situations I think it's fine to install JUST those packages from Sid onto your Testing box. That generally works fine.
The traditional problem with drive-by-wire or fly-by-wire systems is that they are susceptible to high power radio frequency interference. The long wire for the controls can act like an antenna, and a high enough power RF signal can become stronger than the control signal so that the computer acts on it instead. There have been a few instances of fly-by-wire military aircraft crashing into the deck of a carrier due to the high power RF from the carrier's onboard radar. Likewise there have been a few drive-by-wire mishaps on the road due to high power RF from CB radios boosted with linear amplifiers well beyond the legal limits. There have been instances of drive-by-wire cement trucks dumping their load onto highway due to these issues.
Problems with drive-by-wire and fly-by-wire occasionally repeat because these high power RF corner cases are unexpected and *theoretically* shouldn't happen, but do.
So it's not at all a surprise that no FAULT with the electronic hardware has been found, because the problem likely ISN'T a fault with the electronic hardware.
Someone I know did this by setting up Linux routers with "Advanced Router" kernel features -- namely source-routing on established connections, so that established TCP connections could be consistently kept onto a single ISP connection. Without doing this then packets can be sent (or received) from an IP address not associated with the TCP connection, so they're dropped.
Obviously this won't work on UDP packets, since they're stateless; so if you have programs that need to stream data via UDP, that will be an issue.
Slashdot Mirror
Theory is all fine and dandy, but there is a wealth of evidence to suggest just the opposite of what you propose.
I didn't give you theory, I gave you FACT. A fact is something that can be independently verified; and I gave you links to studies and standards concerning exposure to microwave radiation.
...
By no means are the proposed mechanisms [that you referenced] necessarily correct, nor will they explain everything, but your assertion that it is impossible for cell phones to cause cancer is not only poorly thought out, but negligent of the harm that it causes when naive individuals take you at your word.
In other words, what you've given me is speculation. It's exactly this kind of speculation which has gotten us where we are today; where people are afraid of cell phones and cell towers for no proven reason. I'll attempt to read up on the biological mechanisms you've referred to in order to try to understand them, but until I find proof that negates the prior evidence I have that EM radiation is not cancer-causing, I'm maintaining my original position.
The answer is no; the different frequencies travel separately and do not "mix".
Why does it work that way for sound and not for radio frequencies?
It doesn't work that way for sound, either; if it did, then if two people spoke at once you wouldn't be able to hear them both -- the sounds would MIX and change frequencies, scrambling the sound. Since that doesn't happen, the sounds from the two people travel independently, too.
IIRC, this is how the idea of microwave ovens came about - high power radar dishes (which operate in the microwave spectrum) were literally cooking birds to death that roosted in front of the dishes - and they roosted there because the air was nice and warm...
They tested this on Mythbusters, strapping a chicken carcass to front of a high-powered radar dish. After several hours, the chicken was still the same temperature as when they started. So even high-powered microwaves won't necessarily hurt you.
I heard the myth of birds being cooked by radar dishes, too. I don't know if it's true, but the respected documentation of where the microwave oven came from is in the document "The History of the Microwave Oven: A Critical Review" by John M. Osepchuk, ISBN number 978-1-4244-2804-5/09. In case you don't find the document, the microwave heating effect was found by Percy Spencer in 1945-1946, who was then working at Raytheon Manufacturing Company. That's a lot earlier than most people would expect.
The reason is that the frequencies cell phones use are below the spectrum of ultraviolet light. It is near the spectrum of ultraviolet light where the first ionizing radiation occurs, which is required to be able to cause cancer. Ionizing means that the energy level of the individual photons of the transmission have enough energy to disturb the molecular structure of live cells.
Certain viruses, such as HPV, can cause cancer without ever producing anything in the EM spectrum more energetic than miniscule amounts of IR radiation.
It probably is the case that cell phones don't cause cancer, and theoretical considerations are important, but it'd be foolish to not regard the observational data as the real arbiter of this. If a statistically robust connection is found, then the interesting thing is to find out how that can happen.
On theoretical grounds, dark energy either doesn't exist, or it should be 10^(huge number) times larger. But observations clearly show that it's real.
I understand your desire for observational data to draw your own conclusion -- that's cool. The IEEE C95.1 report has 76 pages of it dedicated to listing all of the hundreds of references to documentation and studies on the subject. It's nearly impossible to find online, but at least at one time is possible to find the PDF form by searching for the ISBN number. Give that a try and see what you find.
Print: ISBN 0-7381-4834-2 SH95389
PDF: ISBN 0-7381-4835-0 SS95389
So, perhaps some type of very localized heating might lead to accelerated cell growth with higher replication error rate which then gives cancer.
This suggestion is likely totally bogus, but is intended to illustrate the way some type of alternative mechanism to ionizing radiation might come into play.
i.e. data is always the master, not the theory.
The idea you've given is that somehow a higher replication rate causes cancer. I have no idea whether that idea has merit or not, but it sounds like speculation.
The whole problem with the idea that cell phones cause cancer is that it's based on speculation. It's much more difficult to disprove an idea than it is to prove it; and that's why more speculation won't help.
Ionizing radiation is not why cells phones maybe dangers to your brain. I remember seeing a TV News spiel about this and it was even smart enough to explain that the worry was heating the brain like a microwave does. More specifically heating small blood filters which when heated became ineffective allowing pollution and waste byproducts into sensitive brain tissue. I think there is even some worry on it's effect on mental health.
Well, again, even this doesn't make sense, because the cell phone only transmits a couple of watts, which isn't enough to do any effective heating. Heck, the actual *heat* the cell phone itself has to dissipate does more heating than the transmitted energy does. A microwave oven magnetron tube typically transmits between 500 W - 1000 W in a sealed RF enclosure, so that any energy that isn't absorbed by the water molecules in the food bounces around the RF enclosure until it does. A cell phone radiates in nearly an isotropic pattern (in all directions, like a bare light bulb does), so even those couple of watts (at most) that is transmitted, more than 50% of it never makes it to your head even when the cell phone is against your ear. Also, the antennas in cell phones are down by the mouthpiece these days, to keep the transmitting antenna from interfering with hearing aids.
And when it comes to the brain, why would there be blood filters in it? If there were, how would the waste that was filtered be expelled? Isn't this the job done by the kidneys? See, that doesn't make sense, either.
I don't doubt that you saw what you saw on TV, though; the idea that cell phones are dangerous and is a very popular opinion. I don't think the argument the TV news program was making has any merit.
Is it possible for multiple radio waves of a non-harmful frequency to overlap and produce harmful frequencies? It seems just from picturing it in my mind that it would work but it would produce a signal with less power.
The answer is no; the different frequencies travel separately and do not "mix". There's a device called a "mixer" which uses tiny diodes in order to create the sums and differences between two signals (the "LO" or Local Oscillator signal and the "RF" which is the input signal, and outputting a third "IF" signal or Intermediate Frequency). And if this happened inside of the cell phone itself, it would cause interference internal to the cell phone, so as the signal is processed it's done in shielded areas to protect it from it's own interference. [It's also known as "intersymbol distortion".]
If the frequency is not the problem, then how do you explain the large number of children having cancer, living near the radio aerials in the Vatican?
http://www.bbc.co.uk/news/world-europe-10634977
I explain that as BAD STATISTICS. What is being described in the article is called CORRELATION -- but it is not proving CAUSATION. (Usually this is explained as "CORRELATION != CAUSATION.") Basically the argument they're making is A) the area around the Vatican has an unusually high rate of cancer, B) the area around the Vatican has a lot of radio aerials, therefore C) the radio aerials must be causing the cancer. However, this is an error in logic; all they know is that the area around the Vatican has a high rate of cancer, but not why.
I'd mod you up "insightful" if I could! Thanks, though -- this is another link to add to the collection of why cell phones are actually SAFE.
Not a popular opinion, unfortunately.
The reason is that the frequencies cell phones use are below the spectrum of ultraviolet light. It is near the spectrum of ultraviolet light where the first ionizing radiation occurs, which is required to be able to cause cancer. Ionizing means that the energy level of the individual photons of the transmission have enough energy to disturb the molecular structure of live cells. Microwave "radiation" (which has absolutely nothing to do with nuclear radiation) is far within the level of the non-ionizing radiation spectrum, so there is no possibility of it having the energy required to cause cancer.
This is total bullshit. There are a lot of studies show the link between EM radiation at longer wavelengths than the UV causing an increase in cancer rates. I'm not even going to bother providing a references to one of the thousand papers on this subject. Just look at some studies performed in England and Belgian on the incidence of cancer for radar operators in WW2. We are speaking of other magnitudes of energy levels, but it still invalids your opening statement. Maybe you also overlooked non-ionizing biological effects?
No; as I said, the non-ionizing effects are microwave heating... and there aren't any ionizing effects. And I quoted both U.S. and international studies and standards that cover over 60 years of scientific research on the subject.
The only thing you're correct about in your comment is that there are papers as well as books that claim a link between microwaves and cancer; it's a very popular myth, and has been for over a decade. I'm saying it's a myth, and I've told you why I'm personally sure it's a myth, and I've given you some of my research on the subject. ...and you've given me your opinion.
And then... the eyes... Again a falsehood. The eyes are very actively cooled, and that with a very high blood flow, to cool them down from the incoming and concentrated (through the eye optics) radiation. On a very sunny day, where you have over 1 kW/m^2 of irradiance, without a good cooling, they would simply burn/cook.
I wonder how one can present such a thought out post, with calculations and everything, but with such blatantly falls information at the same time.
I never said the eyes weren't actively cooled; I said that they're the most sensitive part of the body because they don't have much blood flow due to only having capillaries in them. They're also the most sensitive because with a sufficient increase in temperature, cataracts will result. On other places on the body, an increase in temperature would mostly cause temporary damage or a burn that would heal later -- but not with the eyes.
The reason is that the frequencies cell phones use are below the spectrum of ultraviolet light. It is near the spectrum of ultraviolet light where the first ionizing radiation occurs, which is required to be able to cause cancer. Ionizing means that the energy level of the individual photons of the transmission have enough energy to disturb the molecular structure of live cells. Microwave "radiation" (which has absolutely nothing to do with nuclear radiation) is far within the level of the non-ionizing radiation spectrum, so there is no possibility of it having the energy required to cause cancer.
Cell phones use frequencies around 800 MHz to around 2 GHz or so. 3 GHz has an energy level of about 12.4 ueV; ultraviolet light where the first ionizing radiation is possible is around 124ev -- that's a 10,000,000:1 difference in energy level. Have a look at the energy level chart on the right hand side of:
http://en.wikipedia.org/wiki/Electromagnetic_spectrum
or even better, see page 3 of FCC OET Bulletin 56, which is a Q&A on Biological Effects and Potential Hazards of Radiofrequency Electromagnetic Fields:
http://www.fcc.gov/Bureaus/Engineering_Technology/Documents/bulletins/oet56/oet56e4.pdf
People are also afraid of the cell base stations, because they don't know how safe they actually are. The transmitters for these typically send 20 - 40 watts -- that's all. This is then sent through directional "sectored" antennas that typically have 120 degrees of horizontal beam width and only 6 to 15 degrees of vertical beam width; so the three-dimensional antenna pattern is like a 120 degree slice of a pancake, yielding gain of about 13 dBi. This focusing is where the "gain" of antennas comes from -- by focusing where the energy is transmitted.
In the U.S., the standard for specifically what frequencies and power levels are considered safe is the IEEE C95.1 standard, which is unfortunately not freely available, however there's a an overview here: http://www.interferencetechnology.com/uploads/media/AG_07.pdf
This standard is incredibly long to read, but boils down to this: the only proven effect of microwave radiation in 60 years of research is the effect of microwave heating. No cancer. Further than that, the standard narrows down to the power levels that are safe for various frequency regions concerning microwave heating.
But if you really want something to "bite your teeth on", have a look at the international ICNIRP guidelines: http://www.icnirp.de/documents/emfgdl.pdf
Now, if you go through the MATH of how close you have to be to the antennas of a cell tower for it to be "unsafe", the result is pretty interesting:
Spec limit for human-absorbed power per IEEE C95-1 at 900 MHz: 50 Watts/m^2
13 dBi gain = gain of 20
EIRP = 20 W transmitted power * gain of 20 = 400 W
400 W / 4*pi*R^2 = 50 W/m^2
R = 0.636 meters
0.636 meters = 2.09 feet
So at 900 MHz and with a typical transmit power of 20 Watts and a sectored antenna with 13 dBi gain, you need to be 2 feet in front of the antenna while it's transmitting for it to be considered unsafe. This means the only way it's unsafe for a human being is if they're not only on the tower, but right in front of the antenna while it's operating at full power.
The cell phones themselves have a limit on how much power they are allowed to transmit. There are different power limits in various countries; in the U.S. the limit is 1.6 W/kg SAR, in Canada I believe the limit is 10 W/kg SAR. SAR stands for "Specific Absorption Rate". What you really want to know is "what SAR power level is unsafe?", and the answer is that in lab t
Cell phones cannot cause cancer.
The reason is that the frequencies cell phones use are below the spectrum of ultraviolet light. It is near the spectrum of ultraviolet light where the first ionizing radiation occurs, which is required to be able to cause cancer. Ionizing means that the energy level of the individual photons of the transmission have enough energy to disturb the molecular structure of live cells. Microwave "radiation" (which has absolutely nothing to do with nuclear radiation) is far within the level of the non-ionizing radiation spectrum, so there is no possibility of it having the energy required to cause cancer.
Cell phones use frequencies around 800 MHz to around 2 GHz or so. 3 GHz has an energy level of about 12.4 ueV; ultraviolet light where the first ionizing radiation is possible is around 124ev -- that's a 10 million to one difference in energy level. Have a look at the energy level chart on the right hand side of:
http://en.wikipedia.org/wiki/Electromagnetic_spectrum
or even better, see page 3 of FCC OET Bulletin 56, which is a Q&A on Biological Effects and Potential Hazards of Radiofrequency Electromagnetic Fields:
http://www.fcc.gov/Bureaus/Engineering_Technology/Documents/bulletins/oet56/oet56e4.pdf
People are also afraid of the cell base stations, because they don't know how safe they actually are. The transmitters for these typically send 20 - 40 watts -- that's all. This is then sent through directional "sectored" antennas that typically have 120 degrees of horizontal beam width and only 6 to 15 degrees of vertical beam width; so the three-dimensional antenna pattern is like a 120 degree slice of a pancake, yielding gain of about 13 dBi. This focusing is where the "gain" of antennas comes from -- by focusing where the energy is transmitted.
In the U.S., the standard for specifically what frequencies and power levels are considered safe is the IEEE C95.1 standard, which is unfortunately not freely available, however there's a an overview here: http://www.interferencetechnology.com/uploads/media/AG_07.pdf
This standard is incredibly long to read, but boils down to this: the only proven effect of microwave radiation in 60 years of research is the effect of microwave heating. No cancer. Further than that, the standard narrows down to the power levels that are safe for various frequency regions concerning microwave heating.
But if you really want something to "bite your teeth on", have a look at the international ICNIRP guidelines: http://www.icnirp.de/documents/emfgdl.pdf
Now, if you go through the MATH of how close you have to be to the antennas of a cell tower for it to be "unsafe", the result is pretty interesting:
Spec limit for human-absorbed power per IEEE C95-1 at 900 MHz: 50 Watts/m^2
13 dBi gain = gain of 20
EIRP = 20 W transmitted power * gain of 20 = 400 W
400 W / 4*pi*R^2 = 50 W/m^2
R = 0.636 meters
0.636 meters = 2.09 feet
So at 900 MHz and with a typical transmit power of 20 Watts and a sectored antenna with 13 dBi gain, you need to be 2 feet in front of the antenna while it's transmitting for it to be considered unsafe. This means the only way it's unsafe for a human being is if they're not only on the tower, but right in front of the antenna while it's operating at full power.
The cell phones themselves have a limit on how much power they are allowed to transmit. There are different power limits in various countries; in the U.S. the limit is 1.6 W/kg SAR, in Canada I believe t
As far as intro to programming goes, when I took High School Computer Science, our textbook was the Dietel & Dietel C++ How to Program. It was definitely aimed at the beginner to intermediate level programmers and did a pretty good job at explaining fundamentals of programming to a bunch of high school sophomores and making it understandable.
I really liked the Dietel & Dietel books, also. At SUNY New Paltz, engineering students that take C are using the Kernigham and Ritchie book, the authors of C, and that seems to be working out very well. This is where you'll find out what a "K & R block" is. Had I the opportunity to start all over again, I would have started with the K&R book, and then gone on to Dietel & Dietel.
Link to the 2nd edition: http://www.amazon.com/Programming-Language-2nd-Brian-Kernighan/dp/0131103628
The reason I mention this is that C is a subset of C++, so if you want to start with the basics of non-OOP C++, it might make sense to start with C, depending on your end goals. For instance, the Linux kernel is C and Assembly, not C++. C is also common in embedded systems. The other reason to start with C would be to gain understanding of pointers. These can be very useful in C++ also.
LFS user here. Will 2.6.39 get the LTS treatment just like 2.6.35 down to 2.6.32? Would be nice to have a stable target for years to come. I have a box that's still using 2.6.16 (formerly LTS) and another that's 2.4.37. Moving up from "minor" releases, e.g. from 2.6.35 to 2.6.36 haven't really been as minor as they used to be. They tend to be somewhat nerve-wracking experiences. Personally sticking to 2.6.35 as long I can.
ALL new releases of the Linux kernel are considered to be stable releases. These get security updates and fixes (at least for a couple of months) for issues are reported; the rules are "no regressions", so if something breaks that used to work, you can report it and it will get fixed.
Something you could call an "LTS" version essentially only happens when someone chooses to take ownership of maintaining a particular release for a while, usually for their own reasons. So if a Red Hat engineer decides to maintain 2.6.18 and backport drivers and fixes, you'd think of it as an LTS release, but it would mainly be that one person maintaining that branch rather than something all of the Linux developers decided to do. The maintainers as a whole have no good reason to do an LTS release a-la-Ubuntu, because every new kernel release is a stable kernel release, so from their point of view, doing an LTS release would just bog down development work.
Additionally, even when someone or a distribution (like RHEL) decides to maintain a particular kernel as if it were an LTS release for a while, the Linux maintainers generally frown upon it, because it's quite difficult to keep up with all of the changes going on in the development kernel and sometimes might be difficult or impossible to backport due to internal infrastructure changes. Thus these old kernels tend not to keep up with newer kernel features and newer drivers, which is why the kernel maintainers think trying to do this isn't worth the effort.
Now, I happen to be a person who builds his own kernel also, so I understand where you're coming from concerning the "minor" releases being a bit scary. Sometimes they are, like the Ext3 bug that happened in 2.6.19. I think the best you can do is exactly what you're doing -- which is to hold back one or two kernel versions such that they get security/bug fixes. However if everybody did that, then nobody would find the bugs to be fixed, so at the same time it's also nice to experiment with newer kernel versions in order to give the Linux kernel maintainers feedback, try out some of the new features, and to get some vision as to what is coming.
This is one area where it's nice to be able to use some kind of package management, because that way you can add your own kernel and remove it later if it doesn't work out. Generally I make such kernel packages on Debian via 'make-kpkg' which is in the 'kernel-package' package, but the Linux kernel also itself has a make target for making .deb or .rpm packages, too. (Try running 'make help' within a top-level Linux kernel directory, and look under the "Kernel packaging:" section.) I'd like to think that your LFS distribution would let you do some kind of package management.
Note: this post I made is incorrect -- so this is a retraction. :-/ And unfortunately since the stall warning ceased, they THOUGHT they had corrected for the stall.
The aircraft was IN A STALL but yet level, so when they reached terminal velocity, they actually DID feel 1G downward.
I've been using KDE4 since about KDE 4.2.2, and have just upgraded to KDE 4.6.3. For the most part I really like it; it's got a long list of features and a large feature-rich set of applications, and I enjoy the Qt backend, too. There are three major exceptions to the things I like, and one minor exception.
Tthe major exceptions:
1) Strigi
2) Nepomuk
3) Akonadi
Strigi and Nepomuk are what turn most people off to KDE4, because these both cause performance problems. Strigi is a Desktop file indexer; Nepomuk deals with metatagging of files for tagging or rating. Strigi immediately wants to index files on the system as soon as you first log in, and that heavy immediate I/O load makes the first impressions of KDE4 to be poor. Nepomuk is a more consistent performance problem -- last I used it, even selecting a hundred files in Krusader took multiple seconds (and on my old Desktop, more like half a minute to a full minute). The system pretty much has no choice but to perform badly in file operations because inotify has to watch the entire system for file moves. None of these performance problems are discussed in the documentation. >:-| Discussing it with developers is extremely frustrating; it starts with "get used to it, Nepomuk and Strigi are not going away", and ending with dropping the job of documenting the performance problems onto some user's lap.
Thankfully, both Strigi file indexing and Nepomuk metatagging can be disabled within the "Desktop Search" settings. That fixes the performance problems most of the time. Last I checked, disabling these does not clear out the database, though -- on my Desktop system the Virtuoso SQL database grew to be > 2 GB as stored on the filesystem, and I had to clear that out manually. (And as I mentioned, performance was abysmal.)
Akonadi is the storage for personal information (names, email addresses, phone numbers, etc) which uses SQL for storage: and by default it wants to use MySQL server for this. Using a 30 MB MySQL server instance required just in order to hold a few contacts is overkill. There are now several Akonadi SQL back-ends such as Sqlite3, however the configuration defaults to using MySQL and changing the back-end is done on an individual basis within each user's home directory (in ~/.config/akonadai/akonadaiconnectionrc) -- and as far as I know there is no way to change the system-wide default. >:-| That is not pleasing.
See: http://api.kde.org/kdesupport-api/kdesupport-apidocs/akonadi/html/classAkonadi_1_1DataStore.html
So the combination ends up by default being a large SQL database file index in Virtuoso for Strigi and Nepomuk, and a separate SQL database in MySQL for Akonadi.
The last minor issue I have with KDE4 have to do with plasmoid configurability, such as the clock, network monitoring, temperature monitoring, etc. There are always details I would like to see which I cannot get to be shown, such as being able to manually choose rendering font and font size, colors, and whether or not to show a number value as well as a graph. The plasmoid configuration options change between KDE4 versions, sometimes adding features and sometimes removing them. For instance, in the previous version of KDE4 the Digital Clock plasmoid was one of the few plasmoids that allowed changing not only the font used to display the clock, but also the font size... however now in KDE 4.6.3, the font size options have been removed for that plasmoid. ? Weird
I consider KDE4 a great achievement, and I enjoy using it. At the same time, I still don't consider KDE 4.6.3 to be on-par with where KDE 3.5 left off -- KDE 3.5 was a well-oiled machine, and KDE4 is getting close but isn't quite at that same level yet.
If you want me to take your words seriously, please don't use a patronizing attitude next time.
Cheers.
The problem for your description, of course, is that the plane wasn't flying directly downwards, or anywhere close to that.
Yes, you're right. I "RTFA"'d, but the actual article didn't explain this -- only the original report did. I made a second reply stating this, but didn't reply to my OWN comment to make it clear I had been wrong in my first post.. :-/ Best thing I can do now is to at least admit my original mistake.
1. Unless it's pressurization system was faulty (it wasn't) the pressure change wouldn't have been great.
2. Unless accelerating, you wouldn't know you were going down (or up, or banked or upside down...).
Unfortunately, you're right -- because they were stalled but yet relatively level, the passengers felt 1G downward as if they were in normal flight. So they had a brief rough ride during the initial stall, but then after they seemed to "recover" and reached terminal velocity, they felt 1G and as if everything was normal.
What's most interesting in this case is that the systems warned the pilots of an impending stall, but then once they were in a stall, there was no warning at all, as if they had recovered from the stall. That's really unfortunate.
1. Unless it's pressurization system was faulty (it wasn't) the pressure change wouldn't have been great.
2. Unless accelerating, you wouldn't know you were going down (or up, or banked or upside down...).
So the claim that the passengers probably didn't think it was anything more than turbulence is not hard to believe.
This pre-supposes that the passengers felt approximately 1G of gravity downward from their point of view, which pilots normally carefully maintain for passenger comfort. A banked turn that maintains 1G of gravity downward by carefully controlling the turn rate feels "normal" as if the plane were flying straight. Pilots can't do this in an emergency when there are systems failures.
Remove that 1G of gravity like in a free-fall, or flying straight down, and the passengers are going to become acutely alarmed very quickly. Normal turbulence of sufficient magnitude can do this -- and the conditions they were in were worse.
So put your thinking cap on for a second, and consider how it might be possible for a plane flying directly downward to somehow create 1G of gravity sideways such that from the point of view of the passengers, they feel 1G "downward". How is that possible? The only way that could be done is through centrifical force, such as if plane were pulling up, and if it's flying strait down, it's not pulling up. At best, the passengers felt gravity at their backs from the acceleration downwards. As soon as they reached terminal velocity downward, the gravity they felt would be 1G to their front. I'm quite sure that as a passenger I'd notice all of that.
I think this was three minutes of terror for everybody on that plane.
If you're running Sid, then try running 'cat /etc/debian-version' ; you'll see it reports:
wheezy/sid
You're correct that packages normally go through Sid to get to Wheezy, but that doesn't mean that every package that exists in Sid also exists in Wheezy, and vice-versa.
Recently a friend in MHVLUG decided to try running Debian because he had recently upgraded to Ubuntu 11.04 and hated it. So he asked me what I ran, I explained that I ran Debian Sid, so that's what he decided to try. Lo and behold, Perl is upgraded in Sid that week and there were package conflicts during this period, and he broke his system trying to upgrade things. [I found the upgrade tricky.] This is why for most people I recommend either Stable or Testing -- and not Sid. There's nothing wrong with running Sid experimentally and to learn more about Debian or how to deal with package conflicts and so forth -- but you need to be ready for that and to EXPECT that occasionally. And yes, Testing is covered by the Security Team, and that matters too.
Right now, if you download the latest Linux kernel via Git (see git.kernel.org), you'll get EVERY commit that ever happened since the Linux 2.6 kernel was hosted by Git. That's a LOT of commits; in fact, so many that there are several commits that have exactly the same SHA1 hash, so we're hitting SHA1 collisions.
Git is surprisingly good at compressing the Git history, but even it has its limits. For instance, we can examine the disk space usage of linux-2.6.37.y.git verses the decompressed tarball for linux-2.6.37.6.tar.bz2:
$ du -sh linux-2.6.37.y/
890M linux-2.6.37.y/
$ du -sh linux-2.6.37.6
469M linux-2.6.37.6
So this means that the Git version of linux-2.6.37.6 takes up about TWICE the disk space as f linux-2.6.37.6 does from the tarball. This means that the space being taken up by the Git history is now about the same size as the source code itself is. [And, obviously, 2.6.38 and now 2.6.39 are going to be even more so.]
The only way to fix this is to create a new major branch and migrate, possibly along with seeding the new repository with some recent history to allow 'git bisect' to be able to do something reasonable.
Please don't recommend Debian Sid for those that aren't ready for it. There is a reason it's called "unstable"; packages uploaded to Sid are "bleeding edge" and there is occasionally breakage, and the person running the box needs to be ready to handle that and know what to do and how to fix it. This isn't for everybody. Running Testing (currently named Wheezy) is a relatively safe bet.
Sid is not even a complete distribution -- Stable and Testing are, but Sid and Experimental aren't. I didn't realize this about Sid/Unstable either until I attended DebConf10 and was told so by a developer from Australia.
And if you continue to recommend running Sid, at least also tell people about installing 'apt-listbugs' so that they at least if someone else has reported grave or critical bugs on packages that they're about to install that they get warned about that. I.e. this is your "Debian Unstable condom".
The only downside to running Testing is that there are some source packages in Sid that you might need that aren't in Testing. For those situations I think it's fine to install JUST those packages from Sid onto your Testing box. That generally works fine.
The traditional problem with drive-by-wire or fly-by-wire systems is that they are susceptible to high power radio frequency interference. The long wire for the controls can act like an antenna, and a high enough power RF signal can become stronger than the control signal so that the computer acts on it instead. There have been a few instances of fly-by-wire military aircraft crashing into the deck of a carrier due to the high power RF from the carrier's onboard radar. Likewise there have been a few drive-by-wire mishaps on the road due to high power RF from CB radios boosted with linear amplifiers well beyond the legal limits. There have been instances of drive-by-wire cement trucks dumping their load onto highway due to these issues.
Problems with drive-by-wire and fly-by-wire occasionally repeat because these high power RF corner cases are unexpected and *theoretically* shouldn't happen, but do.
So it's not at all a surprise that no FAULT with the electronic hardware has been found, because the problem likely ISN'T a fault with the electronic hardware.
Someone I know did this by setting up Linux routers with "Advanced Router" kernel features -- namely source-routing on established connections, so that established TCP connections could be consistently kept onto a single ISP connection. Without doing this then packets can be sent (or received) from an IP address not associated with the TCP connection, so they're dropped.
Obviously this won't work on UDP packets, since they're stateless; so if you have programs that need to stream data via UDP, that will be an issue.
Good luck with the project.