The Scorpio Blue 1TB drive spins at only 5400RPM but its performance is actually surprising. Since areal density per platter has increased significantly, the drive actually bests some 7200RPM drives.
Has there ever been a single generation of drives in which the next generation of 5400 RPM drives did not beat the existing generation of 7200 RPM drives? Okay, maybe you have to skip two generations. Either way, it's not unusual by any means. When people ask on audio recording boards whether they need 7200 RPM drives, I'm always quick to point out that a new 5400 RPM laptop drive approaches the speed of the early 15,000 RPM desktop drives, and can spank the 7200 RPM laptop drives from just a few years back.
The only thing surprising about this drive is that normally the 7200 RPM drives come first, before the 5400 RPM drives at that density.
The issue isnt File System corruption.. when the issue happens, the machine simply can no longer detect the drives no matter what you do. Its not simply data loss.. complete loss of any access to the device.
You're talking about a completely different failure than the "time warp". The "time warp" bug that I was referring to causes all the data on your disk to suddenly revert to a previous state.
Now it is possible that the two failures have the same root cause—I wouldn't begin to speculate on that—but they are not the same failure.
And if it's such an obvious bug, one would think it would have turned up in the last 29 version 6 releases?
No, honestly. This wasn't caught before because nobody used those flags. Oracle decided that these flags should be turned on by default. Therefore, the onus was on Oracle to thoroughly and broadly test these flags before promoting them to be used by default.
I guarantee you'll find some hairy bugs if you enable lots of random, rarely enabled flags in just about any compiler. The difference between a good compiler and a bad compiler is that a good compiler tests flags thoroughly before either enabling any the flags by default or rolling them into a commonly used option. In effect, what Oracle did was to take an obscure, poorly tested code path and promote it into the hot path through their code. This is something that any first-year CS student should know is risky.
The best part of this is that (assuming other Slashdot comments are correct) this occurs in commonly used third-party libraries, and was disclosed to Oracle several days before the release shipped. Where I work, that's what is known as a P1 block-ship bug, and people will be called in to work on it day and night until the problem is resolved, and if necessary, features will get temporarily pulled (e.g. turning that optimization back off by default).
Not really. In my mind, durability is the ability to survive abuse. Reliability is the ability to survive ordinary, typical use. It's not really interesting to say that a drive lasts for a hundred years when left spun down in a temperature controlled clean room, so any useful measure of reliability must take into account typical usage, or else it is a completely useless metric.
Remember that desktop drives are expected to sit in one place and never move, but laptop drives aren't. Laptop drives are designed to be used in laptops, and people move laptops around. Thus, for a laptop, some amount of motion-caused stress is expected as part of the normal operation of the device. If a device fails under the designed operating conditions, it's a reliability problem, not a durability problem.
Laptop drives take a lot of stress in ordinary use even if you don't drop the machines. It's not the "falling off a table" problem, but rather the "dropped half an inch to the table when I slid my fingers out from under it" problem that kills hard drives. Being able to survive the "falling off a table" problem is largely solved in the hard drive world, thanks to motion sensors in the drives and in laptops. Thus, I would not expect hard drives to be that much more durable than SSDs. However, the "dropped half an inch" problem is still very much a problem. For that reason, I would expect the reliability of SSDs to be much better than hard drives.
Only if the failure is caused by the flash parts wearing out. Most SSD failures are, amusingly, caused by cold solder joints, same as a sizable percentage of hard drive failures.
I'm still waiting for somebody to build a micro-RAID out of solid state storage. Use a single SATA connector, but make them show up on separate LUNs. Have a row of stick-style SSDs connected to a single controller, all in the space of a standard laptop HD. Then RAID the individual sticks with a drop-dead simple controller that does nothing more than LUN rewriting and switched routing.
I understand that the latest crop of SSD's from companies like OCZ have been a real nightmare. I suspect the OCZ issue has to do with powering down the device, with the capacitor responsible for ensuring this happens correctly isnt supply enough power for long enough to let all the buffers write out correctly.. most of the failure posts you see on newegg begin "I put the machine to sleep....".. in other words, several gigs were written out right before the device lost its primary supply of power. So it could easily be that final book-keeping is failing to complete correctly, leaving the flash in a "corrupted" (the controller cant make sense of its own "block system") state
More likely, it is a case of drives playing fast and loose with the ATA spec. A rather dangerous way to speed up performance on filesystem metadata operations is to ignore the commands that tell you to flush buffers to disk. This means that multiple metadata writes to the same block return much more quickly, but it also means that the data isn't really committed to stable storage when the OS thinks that it is. If the machine shuts down and that data still hasn't been flushed, it goes away.
A more common variation on that is to actually perform the sync operation, but return immediately saying that the operation is finished even if you are still writing the buffer out to disk. With a typical disk that has only a handful of tracks in its buffer, that's usually not a problem, but when you crank up to a larger buffer size, if the computer doesn't take extra time before powering down, you get data loss. Operating systems have huge quirk tables to work around exactly these sorts of broken drives.
The result in either case is exactly this sort of behavior: one minute your data is there, the next it isn't. I'd imagine the problem on these drives is similar.
I've also heard of the "sync returns immediately" bug on a lot of cheap USB enclosures, and in some cases, on the drives within the enclosures. If both the enclosure and the drive lie to you, that's when things get really ugly.
I used to have this data loss problem reliably with an internal ATA drive in a beige PowerMac G3. I ended up working around it by always rebooting the machine once before shutting it down. In that case, I vaguely recall that Apple fixed the problem with an OS update, but that was well over a decade back, so I can't say I'm certain; it might have been a drive firmware update.
Either way, the point is that this sort of problem has been happening periodically with hard drives for decades, and the only reason the OCZ drive "time warp" is getting so much attention is that these drives are the new shiny. Give it ten years for SSDs to be old tech, and this will still be happening, but it just won't get reported. Quality costs money, and "mostly works" is usually good enough.
At least one "For the People" caucus asspile (Feinstein) is for it... because she's the chair.
I keep hoping California will get just a couple of competent Republicans running for major offices so we can get rid of Boxer and Feinstein, but instead, the Republicans keep giving us people like Meg Whitman (who ran one of the most evil companies of the Internet age) and Carly Fiorina (who nearly bankrupted two major technology companies in a row before trying her hand at politics...).
It's purely the illusion of choice. California Democrats give us incompetent candidates that don't represent the state, and California Republicans give us incompetent candidates that don't represent the state. Simply amazing.
Suddenly, it makes sense why all the senators and representatives are making so much noise about the debt ceiling instead of just voting to fix what should have been a relatively minor and uncontentious issue. To paraphrase Douglas Adams, the purpose of government is not to wield power, but to distract attention away from it.
Here's the thing: non-particle ionizing radiation (e.g. ultraviolet light) is fundamentally just higher energy because of the higher frequency. Claims that UV causes damage while lower frequency RF signals can never cause damage are just plain contrary to reason. Nothing else in nature has a sudden threshold like that; there's always a continuum, such that you start to see significant numbers of additional deaths at some concentration, with near complete destruction of the population at some point, but that doesn't mean that levels below the level where you saw the first death aren't dangerous.
As a general rule, it is silly to assume that there is some magic threshold above or below which you can say that suddenly this energy is or isn't going to cause damage. This strongly suggests that the dividing line between ionizing and non-ionizing radiation is really nothing more than an arbitrary cutoff below which the odds of damage are small enough that we consider it to be "mostly harmless", not a point below which RF is completely harmless. Thus, you would expect chance to play a major role in whether the effects are or are not detectable at those levels. Crank up the gain by a factor of a million and see if the effects are still undetectable. If they suddenly become consistently observable, then what you are seeing is really no more than the difference between one instance and zero instances in a sample size that's too small to adequately show the effect.
Here's what I don't understand: why don't the jailbreakers modify the phone to add trust for a Cydia root cert (or whoever's), then use that to provide free certs for devs to sign apps on Cydia, etc.? That would provide the same flexibility as a full jailbreak, but without the security impact. Or heck, add trust for all the major CAs so that any standard code signing cert will work.
The problem is that jailbreaking started out as a hack and still hasn't grown up from being a hack into being a usable tool. Then again, I guess I shouldn't expect usability from an app that presents you with a "Loading data" screen for five minutes while it downloads a description of the entire set of available packages.... Apparently, they've never heard of doing updates on background threads, performing on-demand loading, etc. What a mess.
AFAIK, using 's to form a contraction between a noun and the word "is" isn't considered acceptable in formal written English, so an apostrophe on a noun is not ambiguous except in fairly informal writing.
Good public transit can work in cities, assuming you can get the cities to get over their power trips long enough to vote for creating a single board of directors to oversee all of the transit agencies in a region rather than having a thousand little Eichmanns each setting their own schedules and managing their own little sections of the transportation infrastructure. In other words, it's much less likely than unicorns; at least a unicorn could theoretically be created by genetic engineering, assuming you don't want it to actually be able to fly.
The other significant problem in the U.S. is that only a little over 68% of the population live in what most people would call a city, and nearly a quarter of people in the U.S. live in rural area or in towns of fewer than 5,000 people. (Source: DOT) For them, public transit is pretty much a nonstarter.
And unicorns, faeries, dragons, and wizards as well. All are equally plausible.
Re:Data, Images, Binary builds etc.
on
The Rise of Git
·
· Score: 1
and you've just screwed the entire configuration process there.
No, not really. Images that are likely to change are almost invariably not an important part of your app. They're things like the marketing messages you see when you launch a game, the artist of the week blurb you see when you open iTunes and click the store tab, etc.
Images that are actually fundamental to the working of your app almost never change more than two, maybe three times over the entire lifetime of an app, statistically speaking. You add new ones sometimes, but the old images seldom change except when you're doing a major UI redesign; if you're doing major redesigns frequently, that probably says a lot about the quality of the app in question, or more precisely, the lack thereof.
The only real exception to this would be skin collections. In that case, each skin should be in its own repository, and again, each of those individual repositories is unlikely to have very many graphic file changes once the theme is finished. In your main repository, you need only maintain a list of themes and revisions of those themes for each release so you can reproduce a release precisely. Anything beyond that is superfluous.
Re:Data, Images, Binary builds etc.
on
The Rise of Git
·
· Score: 1
Pictures and video are fluid, They change, maybe release to release.
Usually less so than the code, actually. If somebody is embedding an image into source code, 99% of the time, it's an icon or some other rarely updated graphic. If somebody is updating an image regularly, odds are they'll have the app pull that image from a web server and cache it somewhere, in which case it wouldn't live in the DVCS (unless your website does).
Only if you don't actually try to make what you invent. If you do, then somebody else will come and sue you over twelve hundred "inventions" that they previously patented that are similar to some minor aspect of what you invented.
In the current patent climate, only patent trolls win. The only way to fix this is to shorten patent terms and limit transferability of patents from employees to their employers.
Not really. Syquest had been doing the same basic thing for years by the time they got into the game. About the only thing revolutionary about the Zip drive was that it used a 3.5" platter instead of a 5.25" platter as the previous Syquest hardware did. Even the capacity wasn't particularly revolutionary—100 megabytes as compared with the 88 megabyte cartridges that Syquest had been selling for at least a year or two prior.
And the Zip hardware was so unreliable that we'd have to reformat some cartridges every couple of weeks due to them becoming completely unreadable. Zip drives were just plain horrible. Making something cheaper and less reliable is not revolutionary. At best, it's evolutionary, at worst it's devolutionary.
Even around '97 a CDR (not RW) cost many hundreds of dollars, ran at 1x or 2x speeds, required a 3rd party program because there was no OS integration (and they were all horrible), and produced as many coasters as finalized disks, at nearly $1 per disk.
Nobody said they were cheap, but hundreds of dollars wasn't exactly breaking the bank even in the 1990s. The PowerBook G3 line started at about $2,000, if memory serves. Put in that context, having a CD burner in the mid-90s was definitely not unheard of. Unusual, yes, but not unheard of.
Tektronix is borderline incompetent. They added USB to support flash drives, but unless they've released a firmware upgrade since I last checked, they still haven't moved past FAT16, so they only support flash drives with 2GB capacity or smaller (which are just about impossible to buy these days). Given how far behind the rest of the universe their hardware stays, their products aren't a very good indication of whether a technology is still alive....:-)
Same way that (according to a CNN report) box cutters were found planted on aircraft on 9/11 that hadn't yet had any passengers on them. You get someone who already has physical access to the hardware to do the job, e.g. a service technician, a TSA screener, a member of the night cleaning crew, a member of law enforcement, etc.
Note: I don't have any actual proof that this is what happened on 9/11. It's remotely possible that terrorists got through security in a previous week and planted knives on the right planes during previous flights as a hedge against getting caught with knives on the actual day of the attacks. It is, however, fairly unlikely, given that previous flights on those same routes by the terrorists would have likely been noted in at least one news report if that were the case, and given that planes don't always fly the same routes.
Of course, it is also possible that the plane flew a different route than usual, and that the weapons were planted for a fifth 9/11 flight that didn't get hijacked because the wrong plane flew that morning. If so, then one must ask who the other terrorists are in our country waiting for another chance, and why they have not struck yet. This seems somewhat less likely to me than the simpler explanation, though, which is that a member of the ground crew is a terrorist, in which case none of this screening actually matters in the first place.
Slashdot Mirror
Has there ever been a single generation of drives in which the next generation of 5400 RPM drives did not beat the existing generation of 7200 RPM drives? Okay, maybe you have to skip two generations. Either way, it's not unusual by any means. When people ask on audio recording boards whether they need 7200 RPM drives, I'm always quick to point out that a new 5400 RPM laptop drive approaches the speed of the early 15,000 RPM desktop drives, and can spank the 7200 RPM laptop drives from just a few years back.
The only thing surprising about this drive is that normally the 7200 RPM drives come first, before the 5400 RPM drives at that density.
Even if you do, if you put it on your lap, it's going to be moving around.
You're talking about a completely different failure than the "time warp". The "time warp" bug that I was referring to causes all the data on your disk to suddenly revert to a previous state.
Now it is possible that the two failures have the same root cause—I wouldn't begin to speculate on that—but they are not the same failure.
No, honestly. This wasn't caught before because nobody used those flags. Oracle decided that these flags should be turned on by default. Therefore, the onus was on Oracle to thoroughly and broadly test these flags before promoting them to be used by default.
I guarantee you'll find some hairy bugs if you enable lots of random, rarely enabled flags in just about any compiler. The difference between a good compiler and a bad compiler is that a good compiler tests flags thoroughly before either enabling any the flags by default or rolling them into a commonly used option. In effect, what Oracle did was to take an obscure, poorly tested code path and promote it into the hot path through their code. This is something that any first-year CS student should know is risky.
The best part of this is that (assuming other Slashdot comments are correct) this occurs in commonly used third-party libraries, and was disclosed to Oracle several days before the release shipped. Where I work, that's what is known as a P1 block-ship bug, and people will be called in to work on it day and night until the problem is resolved, and if necessary, features will get temporarily pulled (e.g. turning that optimization back off by default).
For shame, Oracle.
Not really. In my mind, durability is the ability to survive abuse. Reliability is the ability to survive ordinary, typical use. It's not really interesting to say that a drive lasts for a hundred years when left spun down in a temperature controlled clean room, so any useful measure of reliability must take into account typical usage, or else it is a completely useless metric.
Remember that desktop drives are expected to sit in one place and never move, but laptop drives aren't. Laptop drives are designed to be used in laptops, and people move laptops around. Thus, for a laptop, some amount of motion-caused stress is expected as part of the normal operation of the device. If a device fails under the designed operating conditions, it's a reliability problem, not a durability problem.
Laptop drives take a lot of stress in ordinary use even if you don't drop the machines. It's not the "falling off a table" problem, but rather the "dropped half an inch to the table when I slid my fingers out from under it" problem that kills hard drives. Being able to survive the "falling off a table" problem is largely solved in the hard drive world, thanks to motion sensors in the drives and in laptops. Thus, I would not expect hard drives to be that much more durable than SSDs. However, the "dropped half an inch" problem is still very much a problem. For that reason, I would expect the reliability of SSDs to be much better than hard drives.
Only if the failure is caused by the flash parts wearing out. Most SSD failures are, amusingly, caused by cold solder joints, same as a sizable percentage of hard drive failures.
I'm still waiting for somebody to build a micro-RAID out of solid state storage. Use a single SATA connector, but make them show up on separate LUNs. Have a row of stick-style SSDs connected to a single controller, all in the space of a standard laptop HD. Then RAID the individual sticks with a drop-dead simple controller that does nothing more than LUN rewriting and switched routing.
More likely, it is a case of drives playing fast and loose with the ATA spec. A rather dangerous way to speed up performance on filesystem metadata operations is to ignore the commands that tell you to flush buffers to disk. This means that multiple metadata writes to the same block return much more quickly, but it also means that the data isn't really committed to stable storage when the OS thinks that it is. If the machine shuts down and that data still hasn't been flushed, it goes away.
A more common variation on that is to actually perform the sync operation, but return immediately saying that the operation is finished even if you are still writing the buffer out to disk. With a typical disk that has only a handful of tracks in its buffer, that's usually not a problem, but when you crank up to a larger buffer size, if the computer doesn't take extra time before powering down, you get data loss. Operating systems have huge quirk tables to work around exactly these sorts of broken drives.
The result in either case is exactly this sort of behavior: one minute your data is there, the next it isn't. I'd imagine the problem on these drives is similar.
I've also heard of the "sync returns immediately" bug on a lot of cheap USB enclosures, and in some cases, on the drives within the enclosures. If both the enclosure and the drive lie to you, that's when things get really ugly.
I used to have this data loss problem reliably with an internal ATA drive in a beige PowerMac G3. I ended up working around it by always rebooting the machine once before shutting it down. In that case, I vaguely recall that Apple fixed the problem with an OS update, but that was well over a decade back, so I can't say I'm certain; it might have been a drive firmware update.
Either way, the point is that this sort of problem has been happening periodically with hard drives for decades, and the only reason the OCZ drive "time warp" is getting so much attention is that these drives are the new shiny. Give it ten years for SSDs to be old tech, and this will still be happening, but it just won't get reported. Quality costs money, and "mostly works" is usually good enough.
Oblig. xkcd: Until I see more data, I'm going to assume cancer causes cell phones.
Constitution? You mean that fancy toilet paper with writing that they have in the Senate bathrooms?
I keep hoping California will get just a couple of competent Republicans running for major offices so we can get rid of Boxer and Feinstein, but instead, the Republicans keep giving us people like Meg Whitman (who ran one of the most evil companies of the Internet age) and Carly Fiorina (who nearly bankrupted two major technology companies in a row before trying her hand at politics...).
It's purely the illusion of choice. California Democrats give us incompetent candidates that don't represent the state, and California Republicans give us incompetent candidates that don't represent the state. Simply amazing.
You're assuming that all of the energy necessary to produce such a transition must come from a single, controlled source.
Suddenly, it makes sense why all the senators and representatives are making so much noise about the debt ceiling instead of just voting to fix what should have been a relatively minor and uncontentious issue. To paraphrase Douglas Adams, the purpose of government is not to wield power, but to distract attention away from it.
Here's the thing: non-particle ionizing radiation (e.g. ultraviolet light) is fundamentally just higher energy because of the higher frequency. Claims that UV causes damage while lower frequency RF signals can never cause damage are just plain contrary to reason. Nothing else in nature has a sudden threshold like that; there's always a continuum, such that you start to see significant numbers of additional deaths at some concentration, with near complete destruction of the population at some point, but that doesn't mean that levels below the level where you saw the first death aren't dangerous.
As a general rule, it is silly to assume that there is some magic threshold above or below which you can say that suddenly this energy is or isn't going to cause damage. This strongly suggests that the dividing line between ionizing and non-ionizing radiation is really nothing more than an arbitrary cutoff below which the odds of damage are small enough that we consider it to be "mostly harmless", not a point below which RF is completely harmless. Thus, you would expect chance to play a major role in whether the effects are or are not detectable at those levels. Crank up the gain by a factor of a million and see if the effects are still undetectable. If they suddenly become consistently observable, then what you are seeing is really no more than the difference between one instance and zero instances in a sample size that's too small to adequately show the effect.
Am I the only one thinking of that song from Blazing Saddles here?
Here's what I don't understand: why don't the jailbreakers modify the phone to add trust for a Cydia root cert (or whoever's), then use that to provide free certs for devs to sign apps on Cydia, etc.? That would provide the same flexibility as a full jailbreak, but without the security impact. Or heck, add trust for all the major CAs so that any standard code signing cert will work.
The problem is that jailbreaking started out as a hack and still hasn't grown up from being a hack into being a usable tool. Then again, I guess I shouldn't expect usability from an app that presents you with a "Loading data" screen for five minutes while it downloads a description of the entire set of available packages.... Apparently, they've never heard of doing updates on background threads, performing on-demand loading, etc. What a mess.
AFAIK, using 's to form a contraction between a noun and the word "is" isn't considered acceptable in formal written English, so an apostrophe on a noun is not ambiguous except in fairly informal writing.
Good public transit can work in cities, assuming you can get the cities to get over their power trips long enough to vote for creating a single board of directors to oversee all of the transit agencies in a region rather than having a thousand little Eichmanns each setting their own schedules and managing their own little sections of the transportation infrastructure. In other words, it's much less likely than unicorns; at least a unicorn could theoretically be created by genetic engineering, assuming you don't want it to actually be able to fly.
The other significant problem in the U.S. is that only a little over 68% of the population live in what most people would call a city, and nearly a quarter of people in the U.S. live in rural area or in towns of fewer than 5,000 people. (Source: DOT) For them, public transit is pretty much a nonstarter.
And unicorns, faeries, dragons, and wizards as well. All are equally plausible.
No, not really. Images that are likely to change are almost invariably not an important part of your app. They're things like the marketing messages you see when you launch a game, the artist of the week blurb you see when you open iTunes and click the store tab, etc.
Images that are actually fundamental to the working of your app almost never change more than two, maybe three times over the entire lifetime of an app, statistically speaking. You add new ones sometimes, but the old images seldom change except when you're doing a major UI redesign; if you're doing major redesigns frequently, that probably says a lot about the quality of the app in question, or more precisely, the lack thereof.
The only real exception to this would be skin collections. In that case, each skin should be in its own repository, and again, each of those individual repositories is unlikely to have very many graphic file changes once the theme is finished. In your main repository, you need only maintain a list of themes and revisions of those themes for each release so you can reproduce a release precisely. Anything beyond that is superfluous.
Usually less so than the code, actually. If somebody is embedding an image into source code, 99% of the time, it's an icon or some other rarely updated graphic. If somebody is updating an image regularly, odds are they'll have the app pull that image from a web server and cache it somewhere, in which case it wouldn't live in the DVCS (unless your website does).
Only if you don't actually try to make what you invent. If you do, then somebody else will come and sue you over twelve hundred "inventions" that they previously patented that are similar to some minor aspect of what you invented.
In the current patent climate, only patent trolls win. The only way to fix this is to shorten patent terms and limit transferability of patents from employees to their employers.
SSME stands for Space Shuttle Main Engine. You're thinking of the SRBs.
Not really. Syquest had been doing the same basic thing for years by the time they got into the game. About the only thing revolutionary about the Zip drive was that it used a 3.5" platter instead of a 5.25" platter as the previous Syquest hardware did. Even the capacity wasn't particularly revolutionary—100 megabytes as compared with the 88 megabyte cartridges that Syquest had been selling for at least a year or two prior.
And the Zip hardware was so unreliable that we'd have to reformat some cartridges every couple of weeks due to them becoming completely unreadable. Zip drives were just plain horrible. Making something cheaper and less reliable is not revolutionary. At best, it's evolutionary, at worst it's devolutionary.
Nobody said they were cheap, but hundreds of dollars wasn't exactly breaking the bank even in the 1990s. The PowerBook G3 line started at about $2,000, if memory serves. Put in that context, having a CD burner in the mid-90s was definitely not unheard of. Unusual, yes, but not unheard of.
Tektronix is borderline incompetent. They added USB to support flash drives, but unless they've released a firmware upgrade since I last checked, they still haven't moved past FAT16, so they only support flash drives with 2GB capacity or smaller (which are just about impossible to buy these days). Given how far behind the rest of the universe their hardware stays, their products aren't a very good indication of whether a technology is still alive.... :-)
Same way that (according to a CNN report) box cutters were found planted on aircraft on 9/11 that hadn't yet had any passengers on them. You get someone who already has physical access to the hardware to do the job, e.g. a service technician, a TSA screener, a member of the night cleaning crew, a member of law enforcement, etc.
Note: I don't have any actual proof that this is what happened on 9/11. It's remotely possible that terrorists got through security in a previous week and planted knives on the right planes during previous flights as a hedge against getting caught with knives on the actual day of the attacks. It is, however, fairly unlikely, given that previous flights on those same routes by the terrorists would have likely been noted in at least one news report if that were the case, and given that planes don't always fly the same routes.
Of course, it is also possible that the plane flew a different route than usual, and that the weapons were planted for a fifth 9/11 flight that didn't get hijacked because the wrong plane flew that morning. If so, then one must ask who the other terrorists are in our country waiting for another chance, and why they have not struck yet. This seems somewhat less likely to me than the simpler explanation, though, which is that a member of the ground crew is a terrorist, in which case none of this screening actually matters in the first place.