"Without disputing anything you say, how is this different from PHP, Python, or Ruby?"
They offered somehting smelling "new" and the ability to do something percieved as "new" at the time of their (percieved) birth: PHP brougth web development to the masses; Python brought "modern" programming paradigms to the masses; Ruby brought web frameworks to the masses.
What is the "new with a new name" that Perl 6 will bring to the masses? Remember that specially regarding mass adoption it doesn't need to do so much with facts as with perceptions.
"Considering that Python 3 scripts are being written, I see no reason to doubt that Perl 6 scripts will be written too."
Apple to oranges. I have no doubt that Perl 5 scripts will be written long after Perl 6 hits "stable". But I do too think that Perl 6 day was five/six years ago or never.
I myself come from the sysadmin camp (and on the develoment side that means "apprentice of everything, master of nothing") so I hacked together my fair share of Perl rubish as well as Bash or C -and the more I went into Perl, the less I needed to program in C, except for some low level or in need for speed hacks. Latter it came PHP for fast web-facing rubish replacing C or Perl CGI's because it brought better bang for the buck on this field. After that it was again Perl the one that payed the price on the "pure systems" side being progressively substituted by Python and (ironically) a bit more of Bash because, again, it brings more bang for the buck (OOP, relatively nice syntax, quite a lot of companion libraries... and Bash -not Perl, for the really simple things). Now, given the time I put into Python, probably PHP will go out of my belt for web-facing dirty hacks and I'll use instead Python plus some framework (probably Turbo Gears as of today).
Sincerily I don't see how Perl 6 will give me benefit enough to look for a(nother) change unless it brings with him another "soft" revolution (right now I had to go with some Ruby, basically against my will, in order to support Redmine and Puppet but I don't see myself getting more time to Ruby than the strictly necessary and not for "internal" new developments -same with Perl 6 while, certainly, time will say).
"If the IT department's blatant over charging causes his department to rely on local hard drives to store all their media and a drive goes pfft!, there goes a ton of man-hours."
Uh... as much as making palatable the original bill of 30$ per month per gig? If that's the case, they are only maximizing their profits in quite a free market way. After all, the whole issue of backcharging is in order to bring the marvellousness of free market within the corporation!
"Our IT shop charges $35/gig per year for raided and backed-to-tape storage."
How much does it charges per deployed PC? Per LAN cable yard? Per CPU cycle at the server room? Per port (and does it take into account if it is 10, 100, 1000, 10000MB?)? Per IP? You see the trend: there's an awful lot of things your IT dept. is not charging back to you and usually that means that your IT dept. will have to procure them anyway within a ridiculously low budget, if any at all.
"No monthly cost to our group. Once its bought, the ongoing operations cost comes out of someone else's budget."
Which rises the point of the vagueness from the original question.
He tolds us that he should pay "$30 per gigabyte per month" but he doesn't tell us what else does it pay and, more interestingly, what else doesn't he pay for. Maybe "$30 per gigabyte per month" is *all* his dept. pays back to IT, or maybe his dept. pays for raw storage and number or PCs but anything else, or...
The question is that that's not an external provider: he doesn't tell us what is he *really* paying for, just that whatever he is paying for is *billed* as "gigabyte per month".
But it's easy to at least check reality: his boss just needs to go the board of directors and tell them: "I don't want IT", I can do it cheaper and see what happens (it would be quite surprising the CTO/CIO would have a stronger position than any other CxO in these days and ages).
"Gee, since the submitter said "internally hosted space" I'm going to take a shot in the dark and guess storage."
As in "there: your 500GB SATA disk, have fun with it"?
Maybe "hosted space" includes personnel wages? Maybe "hosted space" includes servers? backup? bandwith? real state? server apps for access the "space"?...
"The next step if they don't pay is to bring in a collection agency, who will harass them for payment in return for a percentage. Paying a vig to the collection agent may sting a bit, but if it's more about principle than money it could be well worth it."
You can bet it won't be about principles for the collection agency but about money so all the effort you can expect from them will be about "expected collectable money * percentage for them - benefits". Unless "expected collectable money" is significative all you'll get from the collection agency is "next, please".
Well, there are two options in fact (plus a default one).
1) Sue. Have you the time, money and will to go that path? 2) Bad PR. Have you the time, money and will to go that path? 3) Do nothing.
In the end it's always the same: the strongest win (for a variable definition of "stronger": bigger purse, better contacts, strongest will...).
You already had to know about that: if you cross a border with an army, you'd better have a stronger army than the other country's since armies are what is the measure of power regarding country borders. If you back your work with a license or contract, you'd better have the legal means to hold your position since legaleese is the measure of power in this case.
Just as you wouldn't declare war against USA by yourself with a slingshot even if there's a legal way to properly do that (unless you are Peter Sellers in "The Mouse That Roared", of course) you shouldn't use a license you can't back with legal means just because the license is there (unless you want to look like starring a Peter Sellers' comedy, of course).
Next time you'd better refrain from publishing by yourself, publish under some kind of BSD-like license so it doesn't matter if others "abuse" your work or pass the copyrights to someone that can make something about it (ala FSF).
"hiring a developer to fix is one way to say "paying for support"..."
True, but incomplete.
In open source world, hiring a developer to fix is one way to say "paying for support", one that stands by the free market laws. On the other hand, in closed source world, you are tied to monopolistic service. I know what I'd choose, and you?
"Also, I think you'll find that arguments and legislation have "changed the truth" exactly as frequently as debates have: never."
Well... for some definitions of truth.
Just the most obvious: the truth is you can copy and share music and films as much as you want as long as there is no direct positive economical gain, and not, minored expenditures or alleged financial damage doesn't count; it's called the private copy right. That's the truth... in Spain. In USA a piece of legislation has changed that truth (and, of course, the SGAE -Spanish RIAA-like, is trying to change it in Spain too).
"The answer is that most of the newer methods are merely bloat, developed not for speed and efficiency, but for ease of development and maintenance."
Economically regulated systems tend to optimize the strongest economic constrain. Since in IT that usually means "programmer time", optimizing "for ease of development and maintenance" *is* optimizing "for speed and efficiency" for all that matter.
"No Google is cheaper because it economizes such things."
Yes, I know the argument but still haven't seen the case for it or the how.
It's obviously true you gain from economy of scales when going from one user to two users; from two to three, etc. but is there a ceiling on the gainings?
Where else can you go cheaper once you can pay for, say, three people on staff and two colocated servers with some proper backup/restore in place? Where are the economies of scale from serving 10.000 people to serving one million? There *is* economy of scales and there is a fact that the more of a comodity the higher the ceiling but it's false that economy of scales is everything it goes.
In my apreciation Google has made for the "economies of scale" argument on this much more than facts can support: their products are just basically functional and not as stable as publicly sold. In my observation they are not cheaper because of economies of scale but because they offer an inferior product backed up with the proper marketing brouhaha.
"If you find a brand new vulnerability and go straight to IRC with it you are not just hurting Microsoft or sticking it to the man. Your hurting everyone that runs that software."
Uh... no. The one hurting the user is the company that didn't put enough effort into their development and QA practices. The one that prevents other market rivals to offer a properly engineered work by going cheap against them.
It's funny how big corporations are able to mutate public opinion in such weird ways and they even get some people to play by their rules.
Now as per big corps interest they managed to get out with the stupid idea that if you show how to load a gun, how to aim it and how to pull the trigger you become a muderer accomplice.
"Yes, all you need is a top-notch group of administrators with up-to-date skills to setup the system and monitor every security mailing list so that nothing leaks out. Plus routine maintinance, handling user requests, backup, recovery, and environment testing. Throw in their salaries along with datacenter floor space, power, and cooling on run-time costs not to mention depereciation and support on the hardware. Don't forget the additional staff time to document and track changes so that if someone leaves, dies, or is fired that the system can continue running."
It seems you are implying that Google is cheaper because somehow they don't need to have all those things.
"This is a problem with many lines of work, not just IT and I deal with it daily: You cannot count on superman to do the job. Just because your current staff is top notch doesn't mean they'll still be there if another web boom happens. Then what?"
It seems you are implying Google somehow won't suffer such a problem... maybe because they don't hire top notch staff?
"Sure, you can tunnel ssh externally by sending it on port 443, but when the traffic pattern doesn't match web traffic, gotcha."
You know you can funnel *any* kind of traffic under HTTPS don't you? So unless you block *all* traffic except whitelist (and I don't know of any company that would burden so much their bottom line) you are already doomed.
But, well, having people that gladly works with you instead of the competition is so against corporate America's style, isn't it?
"Did you notice the story is about targeted attacks? OS doesn't have much to do with those. In fact since these are companies internal networks and servers and not workstations"
Since these are companies internal networks the best bastion to launch an attack from is oh, surprise! an internal workstation (after all they usually access the servers, don't they?) and guess what the system is most probably such a workstation's going to run? Why should I hack a server when I can easily hack a workstation (and even easier a laptop) which will trustfully gain access as expected to the servers?
Maybe you are right but: a) There are judges if the case arises b) That already happened and that was the way Linus Torvalds dealt with it (when he moved the kernel to the GPL license).
"The license prohibits liberalness, because you are only allowed to share source code under strict conditions."
So strict indeed that all can be said as in "if you want to share this code do it in the very same conditions it were shared to you". Don't find that so strict. If you find that to be unbearable strict you are absolutly free not to use the code.
"It prohibits zealotry, because it ensures that others are free to fork a project and not bow to your vision of a project."
For this to happen you at least have to share it. But you don't have to: if you want your copy to be only for you, you can.
"No. The kernel is(at this point, whether anybody likes it or not) basically GPL2 permanently. Without any "copyright assignment" requirement to some organization, there are just too many interlocking owners for any re-licensing."
Linus Torvalds don't see that problem. Kernel is not moving from GPLv2 just because he doesn't want to. The day Linus wants to move to GPLv3 (if) he will just do so together with a public anouncement of the change. Whoever finds entitled ownership to a piece of code will be free to ask his commits out of the tree if he feel not wanting the change and that's all.
"just because he started a open-source project does not mean he owns it."
To all practical purposes he does own his tree. And due to the GPL license that's no problem at all: you can own your own tree as soon as you want and be as zelous or as liberal as you want with it.
"you can demonstrate that some mathematical definitions hold water I disagree."
Since that's the very basis of Mathematics from Euclides to Gödel I'm sorry to say it won't be enough to say "I disagree": you'll have to prove it somehow.
"Can you demonstrate the existence of the mathematical definition that leads to a device that perfectly distinguishes live fingers from fake fingers?"
When did I say that I would demonstrate the validity of any assertion you want to come with? I only said that some mathematical assertions are bound to be find true". Here comes one: "On an euclidean geometry there can only be one straight line that cross over two distinct points".
"I'm not convinced that as of July 2010, the correct recognition algorithm [that validates something-you-know] to be verified is even known."
So what? Even if that were true (which it isn't: the algorithm for the "something you know" is trivial; you tell something to someone and make sure that such someone is the only one to know it... can it be anymore simpler like that?) how the fact that it can be built today or not makes any mathematical assertion any more false or true? Are you implying that "a straigtht line is endless" is false just because as of July 2010 we can't build such a line?
"And people can potentially remember and flawlessly enter a 20-character something-you-know that changes every day. But security in practice is made of..."
You are aware how much your argument seems to be that of the "real Scotchsman falacy", ain't you?
"memorize with as much precision as you want your key's profile. Now, try to open the door without a key. Memorize the spec. Go to a shop and cut a key with this spec. Open the door."
So you recognize you can't open the door without the token, do you? QED.
"And you still need the keypad connected to the door"
so a PIN is not a pure "something you know"
A PIN is by definition a "something that you know" token. And as such, I can intro the PIN by means of a card, a keypad or a voice recognition system. If I need a physical token then it is a "something that you have" token. If it is a PIN bound to a card then it is a two-way system "something that you have/something that you know". It's really not so dificult to grasp.
"Thus making a fingerprint not the perfect "something you are" test, not throwing any logical fault to the premise. I think Bruce Schneier's thesis is that there exists no perfect "something you are" test."
That's quite a different issue. Even then, if "Bruce Schneier's thesis", whatever it is, it is demonstrably true then it would mean that you can't be confident on a "something you are" device, not that a that a theoretically proper "something you are" device wouldn't fit the place.
"Thus making the testing device buggy Like all testing devices."
Sorry but that's false. You can demonstrate the certain logical devices are bound to certain algorithms; you can demonstrate that certain algorithms are bound to a mathematical definition and you can demonstrate that some mathematical definitions hold water hence, you can demonstrate that at least *some* logical devices are *not* buggy.
"A biometric identification measure is only as good as its best implementation."
True. But the value of biometric identification measures are potentially as good as their theoretically best possible implementation. Since you are not showing any device diagram nor software code, that's what I'm bound to.
"To take your analogy, it would be as if nobody had yet produced correct login software."
And the fact that nobody has produced any bug-free login software yet would mean that it is impossible to write any such software? And if it is possible to write bug-free login software, how the miriad of bug-full implementations would limit the potential of such a bug-free one?
Slashdot Mirror
"Without disputing anything you say, how is this different from PHP, Python, or Ruby?"
They offered somehting smelling "new" and the ability to do something percieved as "new" at the time of their (percieved) birth: PHP brougth web development to the masses; Python brought "modern" programming paradigms to the masses; Ruby brought web frameworks to the masses.
What is the "new with a new name" that Perl 6 will bring to the masses? Remember that specially regarding mass adoption it doesn't need to do so much with facts as with perceptions.
"Considering that Python 3 scripts are being written, I see no reason to doubt that Perl 6 scripts will be written too."
Apple to oranges. I have no doubt that Perl 5 scripts will be written long after Perl 6 hits "stable". But I do too think that Perl 6 day was five/six years ago or never.
I myself come from the sysadmin camp (and on the develoment side that means "apprentice of everything, master of nothing") so I hacked together my fair share of Perl rubish as well as Bash or C -and the more I went into Perl, the less I needed to program in C, except for some low level or in need for speed hacks. Latter it came PHP for fast web-facing rubish replacing C or Perl CGI's because it brought better bang for the buck on this field. After that it was again Perl the one that payed the price on the "pure systems" side being progressively substituted by Python and (ironically) a bit more of Bash because, again, it brings more bang for the buck (OOP, relatively nice syntax, quite a lot of companion libraries... and Bash -not Perl, for the really simple things). Now, given the time I put into Python, probably PHP will go out of my belt for web-facing dirty hacks and I'll use instead Python plus some framework (probably Turbo Gears as of today).
Sincerily I don't see how Perl 6 will give me benefit enough to look for a(nother) change unless it brings with him another "soft" revolution (right now I had to go with some Ruby, basically against my will, in order to support Redmine and Puppet but I don't see myself getting more time to Ruby than the strictly necessary and not for "internal" new developments -same with Perl 6 while, certainly, time will say).
"If the IT department's blatant over charging causes his department to rely on local hard drives to store all their media and a drive goes pfft!, there goes a ton of man-hours."
Uh... as much as making palatable the original bill of 30$ per month per gig? If that's the case, they are only maximizing their profits in quite a free market way. After all, the whole issue of backcharging is in order to bring the marvellousness of free market within the corporation!
"Our IT shop charges $35/gig per year for raided and backed-to-tape storage."
How much does it charges per deployed PC? Per LAN cable yard? Per CPU cycle at the server room? Per port (and does it take into account if it is 10, 100, 1000, 10000MB?)? Per IP? You see the trend: there's an awful lot of things your IT dept. is not charging back to you and usually that means that your IT dept. will have to procure them anyway within a ridiculously low budget, if any at all.
"IT outsourcing companies love this, because they can easily compare apples to apples."
Well, IT outsourcing companies love this because they can pass an apples to oranges comparation as an apples to apples one.
"No monthly cost to our group. Once its bought, the ongoing operations cost comes out of someone else's budget."
Which rises the point of the vagueness from the original question.
He tolds us that he should pay "$30 per gigabyte per month" but he doesn't tell us what else does it pay and, more interestingly, what else doesn't he pay for. Maybe "$30 per gigabyte per month" is *all* his dept. pays back to IT, or maybe his dept. pays for raw storage and number or PCs but anything else, or...
The question is that that's not an external provider: he doesn't tell us what is he *really* paying for, just that whatever he is paying for is *billed* as "gigabyte per month".
But it's easy to at least check reality: his boss just needs to go the board of directors and tell them: "I don't want IT", I can do it cheaper and see what happens (it would be quite surprising the CTO/CIO would have a stronger position than any other CxO in these days and ages).
"Gee, since the submitter said "internally hosted space" I'm going to take a shot in the dark and guess storage."
As in "there: your 500GB SATA disk, have fun with it"?
Maybe "hosted space" includes personnel wages?
Maybe "hosted space" includes servers? backup? bandwith? real state? server apps for access the "space"?...
"Actually, the fact that this is happening in a private company and not in a public entity is the surprising thing..."
Because? Please pay attention that this is "internal money" here: it has as much to be with real costs as monopoly banknotes.
"There is zero ethical difference between these two"
Sorry, that's untrue.
"if you take the a product that is not offered freely without meeting their terms... that's just stealing."
Sorry, that's untrue, both in the legal and common senses for the word "stealing".
"The next step if they don't pay is to bring in a collection agency, who will harass them for payment in return for a percentage. Paying a vig to the collection agent may sting a bit, but if it's more about principle than money it could be well worth it."
You can bet it won't be about principles for the collection agency but about money so all the effort you can expect from them will be about "expected collectable money * percentage for them - benefits". Unless "expected collectable money" is significative all you'll get from the collection agency is "next, please".
"It's the only option really."
Well, there are two options in fact (plus a default one).
1) Sue. Have you the time, money and will to go that path?
2) Bad PR. Have you the time, money and will to go that path?
3) Do nothing.
In the end it's always the same: the strongest win (for a variable definition of "stronger": bigger purse, better contacts, strongest will...).
You already had to know about that: if you cross a border with an army, you'd better have a stronger army than the other country's since armies are what is the measure of power regarding country borders. If you back your work with a license or contract, you'd better have the legal means to hold your position since legaleese is the measure of power in this case.
Just as you wouldn't declare war against USA by yourself with a slingshot even if there's a legal way to properly do that (unless you are Peter Sellers in "The Mouse That Roared", of course) you shouldn't use a license you can't back with legal means just because the license is there (unless you want to look like starring a Peter Sellers' comedy, of course).
Next time you'd better refrain from publishing by yourself, publish under some kind of BSD-like license so it doesn't matter if others "abuse" your work or pass the copyrights to someone that can make something about it (ala FSF).
"hiring a developer to fix is one way to say "paying for support"..."
True, but incomplete.
In open source world, hiring a developer to fix is one way to say "paying for support", one that stands by the free market laws. On the other hand, in closed source world, you are tied to monopolistic service. I know what I'd choose, and you?
"Also, I think you'll find that arguments and legislation have "changed the truth" exactly as frequently as debates have: never."
Well... for some definitions of truth.
Just the most obvious: the truth is you can copy and share music and films as much as you want as long as there is no direct positive economical gain, and not, minored expenditures or alleged financial damage doesn't count; it's called the private copy right. That's the truth... in Spain. In USA a piece of legislation has changed that truth (and, of course, the SGAE -Spanish RIAA-like, is trying to change it in Spain too).
"The answer is that most of the newer methods are merely bloat, developed not for speed and efficiency, but for ease of development and maintenance."
Economically regulated systems tend to optimize the strongest economic constrain. Since in IT that usually means "programmer time", optimizing "for ease of development and maintenance" *is* optimizing "for speed and efficiency" for all that matter.
"Funny that, I find Perl really shines when I use it to extract data and create a report."
Yeah, it's quite practical.
"No Google is cheaper because it economizes such things."
Yes, I know the argument but still haven't seen the case for it or the how.
It's obviously true you gain from economy of scales when going from one user to two users; from two to three, etc. but is there a ceiling on the gainings?
Where else can you go cheaper once you can pay for, say, three people on staff and two colocated servers with some proper backup/restore in place? Where are the economies of scale from serving 10.000 people to serving one million? There *is* economy of scales and there is a fact that the more of a comodity the higher the ceiling but it's false that economy of scales is everything it goes.
In my apreciation Google has made for the "economies of scale" argument on this much more than facts can support: their products are just basically functional and not as stable as publicly sold. In my observation they are not cheaper because of economies of scale but because they offer an inferior product backed up with the proper marketing brouhaha.
"If you find a brand new vulnerability and go straight to IRC with it you are not just hurting Microsoft or sticking it to the man. Your hurting everyone that runs that software."
Uh... no. The one hurting the user is the company that didn't put enough effort into their development and QA practices. The one that prevents other market rivals to offer a properly engineered work by going cheap against them.
It's funny how big corporations are able to mutate public opinion in such weird ways and they even get some people to play by their rules.
Now as per big corps interest they managed to get out with the stupid idea that if you show how to load a gun, how to aim it and how to pull the trigger you become a muderer accomplice.
"Yes, all you need is a top-notch group of administrators with up-to-date skills to setup the system and monitor every security mailing list so that nothing leaks out. Plus routine maintinance, handling user requests, backup, recovery, and environment testing. Throw in their salaries along with datacenter floor space, power, and cooling on run-time costs not to mention depereciation and support on the hardware. Don't forget the additional staff time to document and track changes so that if someone leaves, dies, or is fired that the system can continue running."
It seems you are implying that Google is cheaper because somehow they don't need to have all those things.
"This is a problem with many lines of work, not just IT and I deal with it daily: You cannot count on superman to do the job. Just because your current staff is top notch doesn't mean they'll still be there if another web boom happens. Then what?"
It seems you are implying Google somehow won't suffer such a problem... maybe because they don't hire top notch staff?
"Sure, you can tunnel ssh externally by sending it on port 443, but when the traffic pattern doesn't match web traffic, gotcha."
You know you can funnel *any* kind of traffic under HTTPS don't you? So unless you block *all* traffic except whitelist (and I don't know of any company that would burden so much their bottom line) you are already doomed.
But, well, having people that gladly works with you instead of the competition is so against corporate America's style, isn't it?
"Did you notice the story is about targeted attacks? OS doesn't have much to do with those. In fact since these are companies internal networks and servers and not workstations"
Since these are companies internal networks the best bastion to launch an attack from is oh, surprise! an internal workstation (after all they usually access the servers, don't they?) and guess what the system is most probably such a workstation's going to run? Why should I hack a server when I can easily hack a workstation (and even easier a laptop) which will trustfully gain access as expected to the servers?
"I'm afraid that is not how copyright law works."
Maybe you are right but:
a) There are judges if the case arises
b) That already happened and that was the way Linus Torvalds dealt with it (when he moved the kernel to the GPL license).
"The license prohibits liberalness, because you are only allowed to share source code under strict conditions."
So strict indeed that all can be said as in "if you want to share this code do it in the very same conditions it were shared to you". Don't find that so strict. If you find that to be unbearable strict you are absolutly free not to use the code.
"It prohibits zealotry, because it ensures that others are free to fork a project and not bow to your vision of a project."
For this to happen you at least have to share it. But you don't have to: if you want your copy to be only for you, you can.
"No. The kernel is(at this point, whether anybody likes it or not) basically GPL2 permanently. Without any "copyright assignment" requirement to some organization, there are just too many interlocking owners for any re-licensing."
Linus Torvalds don't see that problem. Kernel is not moving from GPLv2 just because he doesn't want to. The day Linus wants to move to GPLv3 (if) he will just do so together with a public anouncement of the change. Whoever finds entitled ownership to a piece of code will be free to ask his commits out of the tree if he feel not wanting the change and that's all.
"just because he started a open-source project does not mean he owns it."
To all practical purposes he does own his tree. And due to the GPL license that's no problem at all: you can own your own tree as soon as you want and be as zelous or as liberal as you want with it.
"you can demonstrate that some mathematical definitions hold water
I disagree."
Since that's the very basis of Mathematics from Euclides to Gödel I'm sorry to say it won't be enough to say "I disagree": you'll have to prove it somehow.
"Can you demonstrate the existence of the mathematical definition that leads to a device that perfectly distinguishes live fingers from fake fingers?"
When did I say that I would demonstrate the validity of any assertion you want to come with? I only said that some mathematical assertions are bound to be find true". Here comes one: "On an euclidean geometry there can only be one straight line that cross over two distinct points".
"I'm not convinced that as of July 2010, the correct recognition algorithm [that validates something-you-know] to be verified is even known."
So what? Even if that were true (which it isn't: the algorithm for the "something you know" is trivial; you tell something to someone and make sure that such someone is the only one to know it... can it be anymore simpler like that?) how the fact that it can be built today or not makes any mathematical assertion any more false or true? Are you implying that "a straigtht line is endless" is false just because as of July 2010 we can't build such a line?
"And people can potentially remember and flawlessly enter a 20-character something-you-know that changes every day. But security in practice is made of..."
You are aware how much your argument seems to be that of the "real Scotchsman falacy", ain't you?
"memorize with as much precision as you want your key's profile. Now, try to open the door without a key.
Memorize the spec.
Go to a shop and cut a key with this spec.
Open the door."
So you recognize you can't open the door without the token, do you?
QED.
"And you still need the keypad connected to the door"
so a PIN is not a pure "something you know"
A PIN is by definition a "something that you know" token. And as such, I can intro the PIN by means of a card, a keypad or a voice recognition system. If I need a physical token then it is a "something that you have" token. If it is a PIN bound to a card then it is a two-way system "something that you have/something that you know". It's really not so dificult to grasp.
"Thus making a fingerprint not the perfect "something you are" test, not throwing any logical fault to the premise.
I think Bruce Schneier's thesis is that there exists no perfect "something you are" test."
That's quite a different issue. Even then, if "Bruce Schneier's thesis", whatever it is, it is demonstrably true then it would mean that you can't be confident on a "something you are" device, not that a that a theoretically proper "something you are" device wouldn't fit the place.
"Thus making the testing device buggy
Like all testing devices."
Sorry but that's false. You can demonstrate the certain logical devices are bound to certain algorithms; you can demonstrate that certain algorithms are bound to a mathematical definition and you can demonstrate that some mathematical definitions hold water hence, you can demonstrate that at least *some* logical devices are *not* buggy.
"A biometric identification measure is only as good as its best implementation."
True. But the value of biometric identification measures are potentially as good as their theoretically best possible implementation. Since you are not showing any device diagram nor software code, that's what I'm bound to.
"To take your analogy, it would be as if nobody had yet produced correct login software."
And the fact that nobody has produced any bug-free login software yet would mean that it is impossible to write any such software? And if it is possible to write bug-free login software, how the miriad of bug-full implementations would limit the potential of such a bug-free one?