This brings up a vital point: for compute clusters, you absolutely need a good, solid, easily installed OS image. You can use it for VMware setups, new hardware installations, testing new configurations, and scrubbing a machine after some developer with root has committed absurdities. You can also use it as a matter of scheduled system upgrading, to make sure that no weirdnesses have crept into one machine that are not universally present and interfere with work.
You make more sense to me now. I really think that you've not tried dealing with the vagaries of Sun's versions of tools in comparison to the open source tools: that Sun tar vs. GNU tar comparison is a tiny tip of the iceberg of Sun practices that are dangerous and should have been discarded 10 years ago.
But I've seen numerous systems where the flaws of Solaris commercial C was revealed in comparison to gcc. And people use gcc and gmake for development because they can't afford whatever specific compilers Sun sells to test with. If they want customers to be able to use the products they need, they can embrace the newer de facto standards or be left behind.
Manpages, I agree with you about. People get way too cute with those, and often can't be bothered to write them, and when they do tend to include multi-language oddnesses that break them in standard tools. But why should they? They're a big problem. But the Sun versions are way, way out of data: the GNU versions of tools nroff, make, and tar are in fact the standards in the developer world, and Sun needs to suck it up and move forward with those.
The Sun Cluster setup I saw last was, in fact, some foolish mortal doing a not well thought out request. But I've actually seen what the clients referred to as a Beowulf Cluster managed as something like a high availability farm: it was weird, but it worked.
Sir, that is because Microsoft does not cooperate with CERT in admitting the existence of IIS flaws. CERT cooperates so extensively with vendors that they have hundreds if not thousands of long-existing, deep security flaws in their files, all of which are pending vendor fixes or vendor permission to publish.
And I'm sorry, but I've seen several IIS flaws discussed in internal security documents, causing the companies to hop to Apache. The flaws in IIS are unfixed, and still show up in testing with exploit tools having been sent to Microsoft engineers although I've seen no public announcement from Microsoft or on CERT whatsoever. From this, I conclude that Microsoft sends no announcements to CERT whatsoever: that Microsoft only reads what's on CERT, rather than admitting anything on its own.
I agree with you, sir. And if you're trying to make an extremely small tool, such as a real-time or critical security tool, relying on the local Perl installation is like using a car's headlight as a flashlight: it's the wrong tool for the job.
The incompatibility of C++ compilers, and Java compilers, also leads me not to use them if at all avoidable. Plain old gcc-compilable C works robustly across a wide variety of platforms in a way those tools never will.
Unfortunately, the raw numbers are misleading. Many of the Windows bugs are fundamental to the way they do things: auto-opening and auto-executing downloads is amazingly stupid, and the particular vulnerability used after that point is irrelevant, but those are the defaults for all Microsoft distributions.
Second, the Linux/Mac/UNIX holes tend to be very small: they require a clever programmer to detect the vulnerability, they require skill to exploit, they often require the user to do something additionally stupid such as hand-downloading and opening a file, and they're repaired with an easily installed patch within 48 hours. Many of the Windows holes are gaping, remain unfixed for years, and hundreds if not thousands more are not being published by CERT for years because they have never been resolved by Microsoft.
Third, the open development communities around Linux, UNIX, and Macs tend to publish vulnerabilities and exploits. The Windows community absolutely does not: companies that detect flaws report them to Microsoft only if necessary, but generally keep them internal and refuse to discuss them with outsiders because they think revealing security flaws is asking people to exploit them, so as a matter of secure practices, they refuse to publish what they've found.
Given all those factors, and a lack of scanning for known vulnerabilities that have never been fixed, it's very hard to trust an analysis of an analysis of CERT numbers as really showing relative security of the operating systems.
No, it's "chgrp {staffgroup}/home/public" and "chmod 2775/home/public". That prevents the "anonymous" user from over-writing the files there or replacing them with fascinating links or binaries that will do something really rude, and it causes the group ownership to be propagated to new files and subdirectories in that group.
Oh, brother. That happened just before I started a job: someone created a cron job with a typo that flushed the company's core source control server, then it turned out that the backup system got around a limitation by turning one directory into *2000* distinct subdirectories, and it would take 10 days to get it all back online.
One of the core lessons of this applies to the original cluster manager: make sure your backups are tested for restoring system. This is different for cluster machines than it is for core server. Setting aside a few cluster machines for testing OS updates, install tools, and alternative configurations is often a very good idea, and leaves you a few spare machines that can be swapped for ones that the users manage to seriously ruin while you restore them from scratch.
I think you missed the point. The tools and issues with Sun tools, which I described in detail, are not fixed by making the machines Linux. They're fixed by making the machines far more GNU or other Free Source based. Sun has repeatedly pursued proprietary, closed technologies to achieve goals and seen them discarded by most developers and engineers in favor of the more supportable, more robust, and more cross-platform and therefore more familiar tools of the GNU or other open-source license world.
Linux is based on that world, but most of that world is the open source in the operating system, not Linus's kernel. One result is that in numerous Sun shops, you see people stapling in important open source tools and seeing them ignored by Sun, despite their clear usefulness, and the result is a lot of support pain trying to wedge together the different open-source components to make a complete system. How many Sun systems have you had to build "top" for?
The other result is that if you want a fast, capable, and easily configured NIS server, you don't use Sun. You use Linux, or you use a Sun over your protests and staple Webmin on top of it to give you a decent interface, because the defaults of Webmin and of the Linux world for NIS configuration are so much saner. If you want files shared with Windows boxes, you don't use that horrible old PC-NFS tool or buy one of the commercial Sun-only SMB server packages, you install Samba and you're done. If you want cheap backup and tape management from a Sun, you don't lay out many thousands of dollars for a Veritas license and client licenses, you slap in Amanda and maybe an array of external disk for staging the backup, and you're done.
If you need individual Sun servers for overwhelmingly large applications, like an Oracle database with high load, I'd recommend them. They're a great replacement at lower cost than the old IBM big-iron. But for cluster computation? There's no point to buying Suns.
Of course they need a local compiler! Matlab uses one for building local OS dependent bits of tools, or you can use one to build dozens of kernels or X distributions simultaneously, or to build up 50 slightly different versions of software in all its permutations for regression testing.
The compilation itself is one of the most time-consuming parts of its operation in many environments. Without it, you're single threading a core operation onto that build machine, and made that one machine with the compiler absolutely critical to what should be a set of 20 or 100 or 500 identical machines. Depending on what you're doing, the compiler is the whole point of the cluster, matched only by the source control in importance.
Suns also lack, as a default configuration, literally dozens of extremely useful tools that power users expect. That starts with a decent compiler built into the OS, (although I understand they're finally including gcc), standard X libraries and development libraries (because Sun's environment has always been way off the beaten path and need hundreds of man-hours to beat into shape with each new release at least up through Solaris 2.8), tend to be very short on RAM for the same amount of money, have a version of "tar" that inconsiderately makes it incredible painful to do a "ssh root@hostname tar cf -/etc/passwd | tar xf - -C/tmp" and yet have it overwrite your local/etc/passwd because it doesn't strip the leading slashes, have one of the strangest versions of LDAP I've ever seen, and their pkg package management system needs to be....
Well, I'm going to avoid using that kind of language on a bulletin board, but it's not good. But the amount of work necessary to weld together a cluster of 100 Suns into a large and flexible working unit with whatever software the users need to do their jobs is easily enough to pay for another 50 servers. The money saved by buying something other than Suns will buy the backup and cooling systems needed for the whole setup.
You should be able to get around the 32 group limit with netgroups. I haven't run into that problem, myself.
You're very lucky to have such educable users. I deal with a lot of people coming from the Windows world who didn't even realize when what they were doing was broken beyond imagination, because they always had local "Administrator" privilages and absolutely needed it because hardware drivers did not work without it.
A few years ago Muhammad Ali's daughter was training for a fight with her dad watching. She's good: strong, fast, tough, with something to prove, and not someone I'd want to fight without reason. She invited him up to the ring to spar with her, even though his Parkinson's was pretty advanced, and failed to realize that many Parkinson's sufferes can still move with their old speed in reflex or extremely familiar tasks.
She went *DOWN* in a matter of moments. Trained or not, good genes or not, that old man has four inches of reach and a good 80 pounds on her.
Ahh, I see. By losing money on every dose, you think the manufacturers can make up in volume what they lose in profits.
Given your post, I also expect that you have gone to your local Red Cross and donated at least a gallon of blood this year, submitted your name for kidney and bone marrow transplants, and are supporting at least 6 foster children with your Christmas bonus instead of spending it on your own kids. After all, following your reasoning, anyone who deliberately restricts life-saving bodily parts or money to only people they know is a ****.
The obvious candidate for early treatment is severe diabetes, the kind that requires insulin to support. There are millions of sufferers worldwide, including extremely ill people whose bodies cannot take the numerous complications anymore such as destruction of kidneys, or eyes and who have already lost their feet due to the circulation problems that occur with long-term diabetes. (My mother died this way, after years of discomfort and very, very expensive care as her kidneys failed and no donor could be found for such an old and ill woman.)
The idea that stem cells could be used to provide insulin producing cells for thost "Type 1" diabetics is appealing: transplants have been tried but have never worked well, and a very modest supply of stem cells could be easily cultured and cure millions, young and old alike, and save many billions of dollars worldwide treating these most severe cases. The big problem has been reluctance to use stem cells due to their source and the issues of where to harvest them without violating birth control and abortion opponents, not the technical ones of doing the testing.
Don't forget CygWin on Windows! The problems getting patches for CygWin into the XFree86 source tree lent huge support to the switch to Xorg for all those Windows users. Then there's VNC, that also is wildly platform agnostic but is now built on Xorg instead of XFree86.
RPM bassed systems will be fine: it'll have to be a forklift upgrade, because the new packages will have to list "Obsoletes:" components in their SPEC files so they get discarded correctly.
In fact, there's a big advantage in that the modular components will avoid having to also install unrelated packages that share a not-very-important dependency. Updating a single driver, for example, often wound up forcing a matching update of dozens of other related XFree86 packages. This shouldn't happen anymore.
The source breakdown is an idea whose time has come. Now, in order to build a new mouse or video driver, you don't have to have a local and entirely compiled copy of the X11 source tree to pull the various libraries and headers from due to the way Imake handled things.
It was very painful to make X updates for a long time. This will help a lot.
Re: This highlights the actual problem, which is..
on
Microsoft Ends IE for Mac
·
· Score: 2, Informative
I agree. Moreover, sites that stick to basics and use straightforward HTML and CGI load faster, work on far more configurations of even the approved browser, are easier to fix, and don't get created by vaporware consultants who promise the stars and the moon to their clients but then charge New York taxi rates for the trip there.
I've actually told a consultant that I wouldn't pay them if they kept insisting on JavaScript pop-ups instead of a plain old clickable link, which they insisted on doing even after I introduced them to the vision impaired company lawyer who hates these things because they screw up the text->speech software that lawyer uses.
Cell phones rely on identity chips that have burned in ID numbers, and that identify the cell phone to the local network so that the phone can make or receive calls. (Making and receiving calls has some other differences we'll ignore for now.)
Technically, the function of the identity chips is well understood. You just have to monitor the traffic from that cell phone for long enough to work out the identity key for that phone, and then you can duplicate it and use it on any phone of similar model that you wish. Such phones are hot commodity items in lots of neighborhoods: drug dealers in the US use these and stolen cell phones or phones obtained with fake contracts to avoid wiretaps and having a traceable address. These leave less of a paper trail than a stolen cell phone or a fake contract purchased phone. It's unsurprising that violent radicals also use them: the technical expertise to bug a house or detect wiretaps on your own phones is easily applied to that kind of theft.
If you'd like to see the behavior of people who do this sort of thing for a hobby, read back issues of 2600, and look for the details of how Eric Corley feels he was singled out for police harassment because he got caught caught selling the hardware to make phones that steal telephone service.
True. But without un-Patriot Act allowing this unconstitutional and horrid behavior, they'll be answerable to the courts, and find it much tougher to hide the evidence of illegal searches and wrongdoing under the shroud of national security.
Warrantless searches and lack of oversight by anyone else is at the core of a police state. It can make investigations faster, but it often makes them sloppier because the failed investigations don't show up in court or in the accounting.
Good thoughts. I'd also recommend that the study leader take a good look at Eric Raymond's famous rants about open source interfaces, covered here at Slashdot some time ago and readable at http://www.catb.org/~esr/writings/taouu/html/ch05s 01.html. Eric makes a lot of good points about where open source interfaces often fail to actually be useful without reading the source code or for new users, as opposed to experts.
My contact with them is admittedly old: if they've gone to low-power infrared, effectively, then good for the developers. The old bright light was very uncomfortable. But that doesn't offset the part where the focusing headpiece can become risky if mis-handled, if for example the padding of the eyepiece becomes frayed, which is a kind of disrepair that I've actually seen. Unless someone's invented a new, wildly more durable form of padding and a maintainer who will actually keep it fixed, there's still a small danger to unsuspecting users who've just removed their glasses and see very well.
Old experience may be out of date, but have you seen any evidence of the other factor being addressed? I suspect not. And the expense of the things is still hideous even compared to fingerprint scanners.
The light used is typically quite bright, bright enough to be uncomfortable or even damaging to some people with very sensitive eyes. Look up "retinal scanner" and "eye damage" as keywords to find half a dozen good references.
Tne one I tried perhaps 10 years ago not only was so bright as to be uncomfortable, it required you to remove your glasses. Take someone who's really astigmatic or farsighted, ask them to put their face right into this binoculars like setup, and use bad cushioning material on it that frays easily in use or stiffens up so much in harsh cold that you can gouge your eye as you lean over to it in cold weather. They replaced the frayed material when I pointed it out, but that thing was frighteningly dangerous for someone with visual problems from removing their glasses.
Retinal ID is hideously expensive and sometimes damaging to the eye. Please don't believe that it's a useful tool just because you've seen it in movies.
The Gummi Finger articles previously mentioned on Slashdot covered that technique. They succeeded in faking out fingerprint scanners with a gelatin cover placed over a real finger, easily used surreptitously.
Take a look at http://cryptome.org/fake-prints.htm for examples of how the technique is done. Basically fingerprint scanners are like the US airport guards. They make people feel more secure and help prevent casual attack, but they're not good enough to provide genuine security from an even slightly clever attacker.
Slashdot Mirror
This brings up a vital point: for compute clusters, you absolutely need a good, solid, easily installed OS image. You can use it for VMware setups, new hardware installations, testing new configurations, and scrubbing a machine after some developer with root has committed absurdities. You can also use it as a matter of scheduled system upgrading, to make sure that no weirdnesses have crept into one machine that are not universally present and interfere with work.
You make more sense to me now. I really think that you've not tried dealing with the vagaries of Sun's versions of tools in comparison to the open source tools: that Sun tar vs. GNU tar comparison is a tiny tip of the iceberg of Sun practices that are dangerous and should have been discarded 10 years ago.
But I've seen numerous systems where the flaws of Solaris commercial C was revealed in comparison to gcc. And people use gcc and gmake for development because they can't afford whatever specific compilers Sun sells to test with. If they want customers to be able to use the products they need, they can embrace the newer de facto standards or be left behind.
Manpages, I agree with you about. People get way too cute with those, and often can't be bothered to write them, and when they do tend to include multi-language oddnesses that break them in standard tools. But why should they? They're a big problem. But the Sun versions are way, way out of data: the GNU versions of tools nroff, make, and tar are in fact the standards in the developer world, and Sun needs to suck it up and move forward with those.
The Sun Cluster setup I saw last was, in fact, some foolish mortal doing a not well thought out request. But I've actually seen what the clients referred to as a Beowulf Cluster managed as something like a high availability farm: it was weird, but it worked.
Sir, that is because Microsoft does not cooperate with CERT in admitting the existence of IIS flaws. CERT cooperates so extensively with vendors that they have hundreds if not thousands of long-existing, deep security flaws in their files, all of which are pending vendor fixes or vendor permission to publish.
And I'm sorry, but I've seen several IIS flaws discussed in internal security documents, causing the companies to hop to Apache. The flaws in IIS are unfixed, and still show up in testing with exploit tools having been sent to Microsoft engineers although I've seen no public announcement from Microsoft or on CERT whatsoever. From this, I conclude that Microsoft sends no announcements to CERT whatsoever: that Microsoft only reads what's on CERT, rather than admitting anything on its own.
I agree with you, sir. And if you're trying to make an extremely small tool, such as a real-time or critical security tool, relying on the local Perl installation is like using a car's headlight as a flashlight: it's the wrong tool for the job.
The incompatibility of C++ compilers, and Java compilers, also leads me not to use them if at all avoidable. Plain old gcc-compilable C works robustly across a wide variety of platforms in a way those tools never will.
Unfortunately, the raw numbers are misleading. Many of the Windows bugs are fundamental to the way they do things: auto-opening and auto-executing downloads is amazingly stupid, and the particular vulnerability used after that point is irrelevant, but those are the defaults for all Microsoft distributions.
Second, the Linux/Mac/UNIX holes tend to be very small: they require a clever programmer to detect the vulnerability, they require skill to exploit, they often require the user to do something additionally stupid such as hand-downloading and opening a file, and they're repaired with an easily installed patch within 48 hours. Many of the Windows holes are gaping, remain unfixed for years, and hundreds if not thousands more are not being published by CERT for years because they have never been resolved by Microsoft.
Third, the open development communities around Linux, UNIX, and Macs tend to publish vulnerabilities and exploits. The Windows community absolutely does not: companies that detect flaws report them to Microsoft only if necessary, but generally keep them internal and refuse to discuss them with outsiders because they think revealing security flaws is asking people to exploit them, so as a matter of secure practices, they refuse to publish what they've found.
Given all those factors, and a lack of scanning for known vulnerabilities that have never been fixed, it's very hard to trust an analysis of an analysis of CERT numbers as really showing relative security of the operating systems.
No, it's "chgrp {staffgroup} /home/public" and "chmod 2775 /home/public". That prevents the "anonymous" user from over-writing the files there or replacing them with fascinating links or binaries that will do something really rude, and it causes the group ownership to be propagated to new files and subdirectories in that group.
Oh, brother. That happened just before I started a job: someone created a cron job with a typo that flushed the company's core source control server, then it turned out that the backup system got around a limitation by turning one directory into *2000* distinct subdirectories, and it would take 10 days to get it all back online.
One of the core lessons of this applies to the original cluster manager: make sure your backups are tested for restoring system. This is different for cluster machines than it is for core server. Setting aside a few cluster machines for testing OS updates, install tools, and alternative configurations is often a very good idea, and leaves you a few spare machines that can be swapped for ones that the users manage to seriously ruin while you restore them from scratch.
I think you missed the point. The tools and issues with Sun tools, which I described in detail, are not fixed by making the machines Linux. They're fixed by making the machines far more GNU or other Free Source based. Sun has repeatedly pursued proprietary, closed technologies to achieve goals and seen them discarded by most developers and engineers in favor of the more supportable, more robust, and more cross-platform and therefore more familiar tools of the GNU or other open-source license world.
Linux is based on that world, but most of that world is the open source in the operating system, not Linus's kernel. One result is that in numerous Sun shops, you see people stapling in important open source tools and seeing them ignored by Sun, despite their clear usefulness, and the result is a lot of support pain trying to wedge together the different open-source components to make a complete system. How many Sun systems have you had to build "top" for?
The other result is that if you want a fast, capable, and easily configured NIS server, you don't use Sun. You use Linux, or you use a Sun over your protests and staple Webmin on top of it to give you a decent interface, because the defaults of Webmin and of the Linux world for NIS configuration are so much saner. If you want files shared with Windows boxes, you don't use that horrible old PC-NFS tool or buy one of the commercial Sun-only SMB server packages, you install Samba and you're done. If you want cheap backup and tape management from a Sun, you don't lay out many thousands of dollars for a Veritas license and client licenses, you slap in Amanda and maybe an array of external disk for staging the backup, and you're done.
If you need individual Sun servers for overwhelmingly large applications, like an Oracle database with high load, I'd recommend them. They're a great replacement at lower cost than the old IBM big-iron. But for cluster computation? There's no point to buying Suns.
Of course they need a local compiler! Matlab uses one for building local OS dependent bits of tools, or you can use one to build dozens of kernels or X distributions simultaneously, or to build up 50 slightly different versions of software in all its permutations for regression testing.
The compilation itself is one of the most time-consuming parts of its operation in many environments. Without it, you're single threading a core operation onto that build machine, and made that one machine with the compiler absolutely critical to what should be a set of 20 or 100 or 500 identical machines. Depending on what you're doing, the compiler is the whole point of the cluster, matched only by the source control in importance.
Suns also lack, as a default configuration, literally dozens of extremely useful tools that power users expect. That starts with a decent compiler built into the OS, (although I understand they're finally including gcc), standard X libraries and development libraries (because Sun's environment has always been way off the beaten path and need hundreds of man-hours to beat into shape with each new release at least up through Solaris 2.8), tend to be very short on RAM for the same amount of money, have a version of "tar" that inconsiderately makes it incredible painful to do a "ssh root@hostname tar cf - /etc/passwd | tar xf - -C /tmp" and yet have it overwrite your local /etc/passwd because it doesn't strip the leading slashes, have one of the strangest versions of LDAP I've ever seen, and their pkg package management system needs to be....
Well, I'm going to avoid using that kind of language on a bulletin board, but it's not good. But the amount of work necessary to weld together a cluster of 100 Suns into a large and flexible working unit with whatever software the users need to do their jobs is easily enough to pay for another 50 servers. The money saved by buying something other than Suns will buy the backup and cooling systems needed for the whole setup.
You should be able to get around the 32 group limit with netgroups. I haven't run into that problem, myself.
You're very lucky to have such educable users. I deal with a lot of people coming from the Windows world who didn't even realize when what they were doing was broken beyond imagination, because they always had local "Administrator" privilages and absolutely needed it because hardware drivers did not work without it.
Funny you should mention this.
A few years ago Muhammad Ali's daughter was training for a fight with her dad watching. She's good: strong, fast, tough, with something to prove, and not someone I'd want to fight without reason. She invited him up to the ring to spar with her, even though his Parkinson's was pretty advanced, and failed to realize that many Parkinson's sufferes can still move with their old speed in reflex or extremely familiar tasks.
She went *DOWN* in a matter of moments. Trained or not, good genes or not, that old man has four inches of reach and a good 80 pounds on her.
Ahh, I see. By losing money on every dose, you think the manufacturers can make up in volume what they lose in profits.
Given your post, I also expect that you have gone to your local Red Cross and donated at least a gallon of blood this year, submitted your name for kidney and bone marrow transplants, and are supporting at least 6 foster children with your Christmas bonus instead of spending it on your own kids. After all, following your reasoning, anyone who deliberately restricts life-saving bodily parts or money to only people they know is a ****.
The obvious candidate for early treatment is severe diabetes, the kind that requires insulin to support. There are millions of sufferers worldwide, including extremely ill people whose bodies cannot take the numerous complications anymore such as destruction of kidneys, or eyes and who have already lost their feet due to the circulation problems that occur with long-term diabetes. (My mother died this way, after years of discomfort and very, very expensive care as her kidneys failed and no donor could be found for such an old and ill woman.)
The idea that stem cells could be used to provide insulin producing cells for thost "Type 1" diabetics is appealing: transplants have been tried but have never worked well, and a very modest supply of stem cells could be easily cultured and cure millions, young and old alike, and save many billions of dollars worldwide treating these most severe cases. The big problem has been reluctance to use stem cells due to their source and the issues of where to harvest them without violating birth control and abortion opponents, not the technical ones of doing the testing.
Don't forget CygWin on Windows! The problems getting patches for CygWin into the XFree86 source tree lent huge support to the switch to Xorg for all those Windows users. Then there's VNC, that also is wildly platform agnostic but is now built on Xorg instead of XFree86.
RPM bassed systems will be fine: it'll have to be a forklift upgrade, because the new packages will have to list "Obsoletes:" components in their SPEC files so they get discarded correctly.
In fact, there's a big advantage in that the modular components will avoid having to also install unrelated packages that share a not-very-important dependency. Updating a single driver, for example, often wound up forcing a matching update of dozens of other related XFree86 packages. This shouldn't happen anymore.
The source breakdown is an idea whose time has come. Now, in order to build a new mouse or video driver, you don't have to have a local and entirely compiled copy of the X11 source tree to pull the various libraries and headers from due to the way Imake handled things.
It was very painful to make X updates for a long time. This will help a lot.
I agree. Moreover, sites that stick to basics and use straightforward HTML and CGI load faster, work on far more configurations of even the approved browser, are easier to fix, and don't get created by vaporware consultants who promise the stars and the moon to their clients but then charge New York taxi rates for the trip there.
I've actually told a consultant that I wouldn't pay them if they kept insisting on JavaScript pop-ups instead of a plain old clickable link, which they insisted on doing even after I introduced them to the vision impaired company lawyer who hates these things because they screw up the text->speech software that lawyer uses.
Cell phones rely on identity chips that have burned in ID numbers, and that identify the cell phone to the local network so that the phone can make or receive calls. (Making and receiving calls has some other differences we'll ignore for now.)
Technically, the function of the identity chips is well understood. You just have to monitor the traffic from that cell phone for long enough to work out the identity key for that phone, and then you can duplicate it and use it on any phone of similar model that you wish. Such phones are hot commodity items in lots of neighborhoods: drug dealers in the US use these and stolen cell phones or phones obtained with fake contracts to avoid wiretaps and having a traceable address. These leave less of a paper trail than a stolen cell phone or a fake contract purchased phone. It's unsurprising that violent radicals also use them: the technical expertise to bug a house or detect wiretaps on your own phones is easily applied to that kind of theft.
If you'd like to see the behavior of people who do this sort of thing for a hobby, read back issues of 2600, and look for the details of how Eric Corley feels he was singled out for police harassment because he got caught caught selling the hardware to make phones that steal telephone service.
True. But without un-Patriot Act allowing this unconstitutional and horrid behavior, they'll be answerable to the courts, and find it much tougher to hide the evidence of illegal searches and wrongdoing under the shroud of national security.
Warrantless searches and lack of oversight by anyone else is at the core of a police state. It can make investigations faster, but it often makes them sloppier because the failed investigations don't show up in court or in the accounting.
Good thoughts. I'd also recommend that the study leader take a good look at Eric Raymond's famous rants about open source interfaces, covered here at Slashdot some time ago and readable at http://www.catb.org/~esr/writings/taouu/html/ch05s 01.html. Eric makes a lot of good points about where open source interfaces often fail to actually be useful without reading the source code or for new users, as opposed to experts.
I found several stories like this: http://www.engr.wisc.edu/bme/newsletter/2002_sprin gsummer/Article01_ECG.html. I admit that a more targeted search phrase, such as "Can retinal scanners damage the eye"?, gets better results.
My contact with them is admittedly old: if they've gone to low-power infrared, effectively, then good for the developers. The old bright light was very uncomfortable. But that doesn't offset the part where the focusing headpiece can become risky if mis-handled, if for example the padding of the eyepiece becomes frayed, which is a kind of disrepair that I've actually seen. Unless someone's invented a new, wildly more durable form of padding and a maintainer who will actually keep it fixed, there's still a small danger to unsuspecting users who've just removed their glasses and see very well.
Old experience may be out of date, but have you seen any evidence of the other factor being addressed? I suspect not. And the expense of the things is still hideous even compared to fingerprint scanners.
The light used is typically quite bright, bright enough to be uncomfortable or even damaging to some people with very sensitive eyes. Look up "retinal scanner" and "eye damage" as keywords to find half a dozen good references.
Tne one I tried perhaps 10 years ago not only was so bright as to be uncomfortable, it required you to remove your glasses. Take someone who's really astigmatic or farsighted, ask them to put their face right into this binoculars like setup, and use bad cushioning material on it that frays easily in use or stiffens up so much in harsh cold that you can gouge your eye as you lean over to it in cold weather. They replaced the frayed material when I pointed it out, but that thing was frighteningly dangerous for someone with visual problems from removing their glasses.
Retinal ID is hideously expensive and sometimes damaging to the eye. Please don't believe that it's a useful tool just because you've seen it in movies.
The Gummi Finger articles previously mentioned on Slashdot covered that technique. They succeeded in faking out fingerprint scanners with a gelatin cover placed over a real finger, easily used surreptitously.
Take a look at http://cryptome.org/fake-prints.htm for examples of how the technique is done. Basically fingerprint scanners are like the US airport guards. They make people feel more secure and help prevent casual attack, but they're not good enough to provide genuine security from an even slightly clever attacker.