I love my french press! It was one of those wedding gifts that gets constant use. For some reason, the coffee brewed in the press simply tastes better than my drip maker. The only drawback is that cleaning the press is a bit of a mess. The coffee grounds are separated from the liquid easily enough by the screen, but you end up with half a cup of grounds in the brewpot. Shake them out and rinse out the rest. Not horrible, but some people freak out when you dump a few grounds down their kitchen sink. This is one reason why the drip/filtered coffee maker is more popular. They just don't cut it for coffee snobs like me, though.;-)
Slightly off topic, but has anyone used the MrCoffee Iced Tea makers? They're awful. It operates on the same principle as a drip coffee maker, but it drips over tea bags into a large 2.5-3 quart pitcher half filled with ice cubes. I find the tea it brews as bitter and undrinkable. A simple sun-tea jug is the only acceptable way to make iced tea, IMHO.
I'm running Debian Sarge (testing) with a 2.4.23 kernel, XFree86 v4.2.1-12.1 (admittadly behind the 4.3 curve), and a Radeon 7200 (I bought this before X supported the DDRAM chips) on an AMD Thunderbird 1.4GHz processor. Whereas this setup is perfectly fine for Unreal Tournament and Quake3, it was sorely lacking when trying to run the Savage demo. I felt like I was playing on a 486. Needless to say, I didn't buy the game. I have some spare change to purchase some software titles, but not enough to retrofit my computer.
I'd be willing to try again, if this patch works on the demo. My impression from the website is that this patch only supports the retail versions of the software. Honestly now, would you purchase a game you couldn't run on your computer?
Didn't you know? SMTP is the "new" fileshare protocol! Send your monolithic, uncompressed Micro$oft Word and Excel files by simply attaching them to an email and sending them to your distribution list! 300MB? No problem. 1GB? Who cares? Everyone uses Broadband now anyway, right?
There's more truth to this than you realize. We've been battling this problem at our University for years now. Because there is no convenient, University-wide fileservers to exchange data on, people simply use email. Frankly, it's a waste of bandwidth and taxes the email servers unnecessarily.
I would love to intercept large attachments and publish them via a secured, anonymous website or ftp site. The MIME specification provides for external attachments for this very reason. If anyone comes up with a Free Software SMTP attachment-filtering gateway, please let us know! Perhaps a plugin for amavisd-ng or spamassassin would be the answer!
I have two, both at the same company. I was hired on as The Tech Guy(TM) at a local OEM Manufacturer. They were willing to take me on w/limited experience but my pay reflected it. My first job was to replace their existing DOS-Cobal Manufacturing Resource Planning (MRP) software before the Y2K problems hit. The original software company wasn't supporting the old version any longer and the Mfg was getting too large for the program. They looked at a number of demos that were slow and painful, but they decided to try a "favorable" application (See also: cheap).
My mistake was to give the techie "thumbs up" under pressure. I folded to the "We needed this yesterday" argument despite my misgivings about the software. I paid for that mistake for the next year in slavish tech support. We became the software company's test bed as we found bug after bug. The software "worked", but operator efficiency dropped, and uptime was sub-optimal. "Customization" caused problems, etc., etc.
The second mistake I made was to attempt to use VPN over Broadband with Citrix MetaFrame. Although MetaFrame was a pretty secure and slim protocol for remote desktops, the Internet provider on the remote site had horrible latency problems and was run by a group of amatures. I should have stuck with the original Sprint frame relay proposal.
Morals of the story: don't let PHB push you into a solution you don't trust, and when network reliability is important, pay for assured quality of frame relay.
at least 15 people got really nasty, ranging from "read the fucking channel topic"
I am also very disappointed with some of the responses on the #debian channel on OPN, and as a developer, it pains me to see this type of representation of the Debian project. Although #debian@OPN can be useful, I would limit your use of it to simple questions no longer than one or two segments in length. If you get flak, just leave the channel. It's not worth your time arguing with pedantic channel ops.
@chanop: I'm sorry, you must form your question in the form of a question. Confused? Read useless URL at....."
needhelp: But I am just having issues with
@chanop: No excuse! Read the URL or be silenced!
needhelp: this is bogus...
You have been silenced!
Rather than get beat-up on IRC, send a detailed message to debian-user. There are lots of knowledgable users and developers that lurk on the list who could possibly help you out. Plus, being verbose in email isn't generally frowned upon as long as people can get to the root of your question without reading a dissertation. The chanops in #debian@OPN are far less forgiving.
Read Kernel Traffic, the periodical summary of conversations on the Linux Kernel Mailing List (LKML). In article #240, you will find your answer. If in doubt, email the authors directly.
There is an automatic partitioning option, but personally I'm much more picky about how my disk is set up. The article actually gives a sane setup for newbies.
You obviously didn't read the article. The debian-installer is about presenting a consistent installation method for eleven, count them, 11 architectures. Yes, Knoppix works great for i386 and its grandchildren, but doesn't work so great for sparc.
Remember, Debian isn't just a desktop distribution.
It's not out of the question. As you pointed out, there is prior art and experience in distributed networks to draw upon. There are a number of libraries out there that would help you build the applications. Latency problems can be mitigated with an automatic server election protocol based on network connectivity and speed. Gnutella2 uses this as do others.
In addition, you could add web proxying to the client to get a truly distributed web surfing experience. Tying bittorrent to gnutella's search protocol. Not a bad idea at all.
He is mostly off base here. WINE Is Not an Emulator. It is a native implementation of the Windows API. The API in and of itself is not the problem. It is the lacksidasical attention of the program author for issues such as buffer overflows. Not only can we hope that the WINE authors are more attentive to memory leaks and out-of-bounds errors in its own implementation of the less than optimal Windows API, we can examine and test the source code for ourselves. However clean the API might be, the program that runs on WINE may still be buggy.
If you believe that applications written for Windows are inherently insecure, then there is no convincing you otherwise. If, however, you limit your argument to the WINE implementation of the Windows API, then hopefully you can place a little more faith in the Free Software developers to ensure that they are not making the same mistakes as Microsoft. Remember the "many eyes equals shallow bugs" addage.
Now, if we can accept that the quality of the API turned out by the WINE developers is above par in comparison to the Microsoft developers, then we place the blame for faulty and exploitable Windows programs upon the original developer/company.
So, if the bug is with the application itself because of some programming error, which is not unheard of, then how will the environment in which WINE runs insulate you from the effects of the Microsoft virus/worm?
The answer lies in the security model of UNIX-like operating systems. A virus may affect you, an individual user, if you're gullible enough to run an email attachment through a WINE emulator. However, this does not guarantee that the virus will identify and use vulnerable applications, such as Lookout Express. Nor does it guarantee that a virus could affect the system any further than a normal user could otherwise do without the aide of sudo or su.
Is it possible to run a virus or worm under the WINE environment? Certainly. Will it really matter? Most likely not.
I would like to thank you for breaking that pesky DNS protocol. I
mean, why should people rely upon standards-based protocols anyway? I
really didn't need the "reject_unknown_recipient_domain" and
"reject_unknown_sender_domain" options from my postfix email server
anyway. They're useless, right? You have saved us from having
effective address resolution for numerous internet protocols, well
established networking practices, and sanity.
Thank you, again, for thinking only of your customer.
Sincerely,
Chad C. Walstrom
A disgruntled Network Administrator who has spent all afternoon trying
to "fix" what you broke.
Darl's position doesn't surprise me in the least. He sticks to his guns, true to the marketing and political antics of the SCO Group, drumming up news headlines and "branding" it's products through the elevated press. Given that litigation is what Canopy does as a business, Darl is the perfect spokesperson. He's a salesman, true to none but his paycheck.
His letter implies that the DDoS attack against SCO Group was a surprise; we know you're smarter than that, Darl. His letter implies that Bruce Perens "admitted" that Linux contains SCO Intellectual Property from SGI's IRIX, a derivative of Sys V UNIX, and by copyright license, property of SCO Group. Let's not forget that Darl is a Master of Ceremony; it's his job to discredit anyone and anything that stands in his way. This case is being tried in the eye of the public long before it ever reaches the court room floor. SCO Group has nothing to loose and everything to gain by being the bully.
SCO Groups claims are a sham, and Darl is its spokesman. Their back is against the wall, and the Open Source community is pressuring them to put up or ship out. Their products cannot compete with Public Domain, GPL, or hobby software, because they don't innovate. They're embarrassed and scared, so they're snapping at anything that gets within reach.
...someone needs to shoot this rabid dog and put it out of its misery.
I recall watching a cable television show, perhaps on the Discovery channel, that showcased a German an automated refuse and waste management factory. It separated the organic materials from inorganic, separated broken glass by color, etc. The only that couldn't automatically be separated were things like batteries.
In any case, a bacteria culture was used on the organic components to digest the "unburnable" products. Later, the dried organic waste was used as a fuel for eletricity generation. Imagine the efficiency boots if the engineers could employ the electricity-producing bacteria as well.
...the cheapest bid. Don't forget that Cities and Municipalities operate on a budget, and although Flywheel Energy Storage units may have been more environment friendly and cheaper for long-term maintenance, they were probably far more expensive up-front. Long-term financing isn't often a concern for short-term problems, so my guess is that the 2k sq. ft. battery was the cheapest.
I'm not surprised someone is using punctuated equilibrium to explain some of the development patterns in Free Software. Short periods of intense development followed by long periods of inactivity. Sounds like a pattern of a volunteer developer to me, giving his or her free time to a project. Since free time rarely occurs as contiguous segments, the parallelism to punctuated equilibrium is easy to see. I just hope this paper doesn't earn these two yokels anything but a quick pat on the back for pointing out the obvious.
Hark! What is this! I believe it is a person unfamiliar with the coolness that is apt-get and dpkg. Debian packages actually have a field called "Build-Deps:" that lists versioned dependencies on source packages. Yes, there is such a thing as a source package. In Debian, a source "package" is actually three files: the "original" tarball of the source code (*.tar.gz), the Debian Source Control file (*.dsc), and the patch file (*.diff.gz).
Building your own binary involves making sure your "deb-src" line has been entered in your/etc/apt/sources.list file and then running the following commands:
$ apt-get build-dep PACKAGE
$ apt-get source --compile PACKAGE
You can certainly keep up to date w/most of the packages you need by recompiling in your own custom environment. Pull a couple source packages and test it out.
P.S. You can get around with not having to use apt-get's source.list file if you download the appropriate files yourself. Then use dpkg-buildpkg from the build-essentials package to build each package dependency manually. You are definitely NOT locked in with Debian.
There was an interesting concept I read about in a sci-fi book regarding the legislation a high-tech society had put in place to protect its citizens privacy where cameras and surveillance was a rule, not an exception. The idea was simple. Surveillance of individuals while in private residence or private transportation vehicles was not admissable in court. Essentially, the action of the individuals dictated what was private and what was public record. Step into a private dining booth, and everything is "off the record." Etc.
It is already technologically possible to tap into conversations, even under adverse conditions. It will only become easier in the future. The legislation knows this and will certainly receive pressure from all sides, to maintain the citizen's right to privacy. We'll see how well they do.
I had once helped a couple friends install Linux systems at a small extension high school, one of them was a teacher railroaded into the part-time IT Coordinator position. Even though we had successfully deployed a stable, secure, low-maintenance, low-cost Linux environment, his peers were committed to causing his eventual resignation.
Windows was the only "real" answer for his peers, even while staring into the eye of a year of success with Linux. A year of success. Sometimes you simply cannot win against the engrained "religious" beliefs of some computer users, especially those people who influence financial and policy decisions in your work place.
Check out Debian's GNU/Hurd port. It's running from Debian's unstable branch (sid), but it looks installable and usable. GNU/Hurd isn't dead. It's just starting to stablize.
There is a very nice site that the US Copyright Office has put up that explains Copyright
Basics. Now, IANAL, but it sounds like this proposal would nullify the current policy to secure a copyright, which is to effectively do nothing!
No publication or registration or other action in the Copyright Office is required to secure copyright.
How does the proposed amendment to the copyright law possibly outweight the advantages we currently possess? It tries to solve one problem, which is, "How do we offset the cost to proactively obtain original works for the Public Domain?" You do it by requiring a proactive registration system?
The VRFY command isn't always enabled, because it can be used by a SPAM'er to collect valid email addresses. I'm not sure how much this really matters, because the following mechanism can be used as well, and it cannot be shut off.
% telnet mail.domain.tld 25
Trying mail.domain.tld...
Connected to mail.domain.tld...
Escape character is '^]'.
220 mail.domain.tld ESMTP Postfix
EHLO myhost.mydomain.tld
250-mail.domain.tld
250-PIPELINING
250-ETRN
250-XVERP
250 8BITMIME
MAIL FROM: postmaster@myhost.mydomain.tld
250 Ok
RCPT TO: spammer-sender@mail.domain.tld
550 User unknown in local recipient table
So, although VRFY may speed things up a bit, there are ways to validate the existance of an account. You can use this technique to validate whether or not a Sender address, as listed in the email for a local recepient, exists or not. If it doesn't exist, you can drop the email as a 550 error for not having a valid return address. It's all very logical, if not a slight slow down in email delivery.
IIRC, the exim email server can do this, and sendmail and postfix are customizable for such a mechanism. With postfix, you may have to use a custom filter program, but that's do-able.
This type of biometric measurement, bogus patent claim excluding, can be useful. It is limited, however, to how the input is collected. For local machine access, it is possible, given that the OS allows access to the input device. Remote access, however, is another beast altogether. If we were to limit the use of this biometric to simple 100BaseT full duplex ethernet LANS, and if you allow for a larger standard deviation of timing, there are only a few communication protocols that you could use this test on.
Telnet will "work", for example. Open up an instance of tcpdump or some other real-time packet sniffer and telnet into your local machine. Type in your password. For every character you type in a telnet session, a packet is sent. This is one reason it is such a poor protocol for restricted or secure access. Add the fact that it's a plain text protocol, and someone could mimic your biometric quite easily.
SSH, on the other hand, has lots of little enhancements to combat the network sniffer. Firstly, the traffic is encrypted. Secondly, ssh doesn't send your password one character at a time. It varies the packet sizes and timings "randomly", and well, it's just plain cool. So, unless you add a biometric test to password timing for the local ssh client used to connect to the server, you couldn't gather the information at all.
Use with HTTP would also depend upon the cooperation of the remote client, but if there's anything a knowledgable programmer has learned over the years, it's that you NEVER trust client information fully. (Just as people don't fully trust closed-source software, but that's way off topic.) Always validate your input.
So, although such biometric validation can be useful under certain circumstances, it's not reliable enough to be depended upon. I do like the idea that one poster presented for auditing user behavior, such as violating a system policy of sharing passwords for a single account, but once again, it's a very limited biometric.
Slashdot Mirror
Slightly off topic, but has anyone used the MrCoffee Iced Tea makers? They're awful. It operates on the same principle as a drip coffee maker, but it drips over tea bags into a large 2.5-3 quart pitcher half filled with ice cubes. I find the tea it brews as bitter and undrinkable. A simple sun-tea jug is the only acceptable way to make iced tea, IMHO.
I'd be willing to try again, if this patch works on the demo. My impression from the website is that this patch only supports the retail versions of the software. Honestly now, would you purchase a game you couldn't run on your computer?
There's more truth to this than you realize. We've been battling this problem at our University for years now. Because there is no convenient, University-wide fileservers to exchange data on, people simply use email. Frankly, it's a waste of bandwidth and taxes the email servers unnecessarily.
I would love to intercept large attachments and publish them via a secured, anonymous website or ftp site. The MIME specification provides for external attachments for this very reason. If anyone comes up with a Free Software SMTP attachment-filtering gateway, please let us know! Perhaps a plugin for amavisd-ng or spamassassin would be the answer!
My mistake was to give the techie "thumbs up" under pressure. I folded to the "We needed this yesterday" argument despite my misgivings about the software. I paid for that mistake for the next year in slavish tech support. We became the software company's test bed as we found bug after bug. The software "worked", but operator efficiency dropped, and uptime was sub-optimal. "Customization" caused problems, etc., etc.
The second mistake I made was to attempt to use VPN over Broadband with Citrix MetaFrame. Although MetaFrame was a pretty secure and slim protocol for remote desktops, the Internet provider on the remote site had horrible latency problems and was run by a group of amatures. I should have stuck with the original Sprint frame relay proposal.
Morals of the story: don't let PHB push you into a solution you don't trust, and when network reliability is important, pay for assured quality of frame relay.
I am also very disappointed with some of the responses on the #debian channel on OPN, and as a developer, it pains me to see this type of representation of the Debian project. Although #debian@OPN can be useful, I would limit your use of it to simple questions no longer than one or two segments in length. If you get flak, just leave the channel. It's not worth your time arguing with pedantic channel ops.
Rather than get beat-up on IRC, send a detailed message to debian-user. There are lots of knowledgable users and developers that lurk on the list who could possibly help you out. Plus, being verbose in email isn't generally frowned upon as long as people can get to the root of your question without reading a dissertation. The chanops in #debian@OPN are far less forgiving.
Read Kernel Traffic, the periodical summary of conversations on the Linux Kernel Mailing List (LKML). In article #240, you will find your answer. If in doubt, email the authors directly.
There is an automatic partitioning option, but personally I'm much more picky about how my disk is set up. The article actually gives a sane setup for newbies.
Remember, Debian isn't just a desktop distribution.
It's not out of the question. As you pointed out, there is prior art and experience in distributed networks to draw upon. There are a number of libraries out there that would help you build the applications. Latency problems can be mitigated with an automatic server election protocol based on network connectivity and speed. Gnutella2 uses this as do others. In addition, you could add web proxying to the client to get a truly distributed web surfing experience. Tying bittorrent to gnutella's search protocol. Not a bad idea at all.
If you believe that applications written for Windows are inherently insecure, then there is no convincing you otherwise. If, however, you limit your argument to the WINE implementation of the Windows API, then hopefully you can place a little more faith in the Free Software developers to ensure that they are not making the same mistakes as Microsoft. Remember the "many eyes equals shallow bugs" addage.
Now, if we can accept that the quality of the API turned out by the WINE developers is above par in comparison to the Microsoft developers, then we place the blame for faulty and exploitable Windows programs upon the original developer/company.
So, if the bug is with the application itself because of some programming error, which is not unheard of, then how will the environment in which WINE runs insulate you from the effects of the Microsoft virus/worm?
The answer lies in the security model of UNIX-like operating systems. A virus may affect you, an individual user, if you're gullible enough to run an email attachment through a WINE emulator. However, this does not guarantee that the virus will identify and use vulnerable applications, such as Lookout Express. Nor does it guarantee that a virus could affect the system any further than a normal user could otherwise do without the aide of sudo or su.
Is it possible to run a virus or worm under the WINE environment? Certainly. Will it really matter? Most likely not.
I would like to thank you for breaking that pesky DNS protocol. I mean, why should people rely upon standards-based protocols anyway? I really didn't need the "reject_unknown_recipient_domain" and "reject_unknown_sender_domain" options from my postfix email server anyway. They're useless, right? You have saved us from having effective address resolution for numerous internet protocols, well established networking practices, and sanity.
Thank you, again, for thinking only of your customer.
Sincerely,
Chad C. Walstrom
A disgruntled Network Administrator who has spent all afternoon trying to "fix" what you broke.
Darl's position doesn't surprise me in the least. He sticks to his guns, true to the marketing and political antics of the SCO Group, drumming up news headlines and "branding" it's products through the elevated press. Given that litigation is what Canopy does as a business, Darl is the perfect spokesperson. He's a salesman, true to none but his paycheck.
His letter implies that the DDoS attack against SCO Group was a surprise; we know you're smarter than that, Darl. His letter implies that Bruce Perens "admitted" that Linux contains SCO Intellectual Property from SGI's IRIX, a derivative of Sys V UNIX, and by copyright license, property of SCO Group. Let's not forget that Darl is a Master of Ceremony; it's his job to discredit anyone and anything that stands in his way. This case is being tried in the eye of the public long before it ever reaches the court room floor. SCO Group has nothing to loose and everything to gain by being the bully.
SCO Groups claims are a sham, and Darl is its spokesman. Their back is against the wall, and the Open Source community is pressuring them to put up or ship out. Their products cannot compete with Public Domain, GPL, or hobby software, because they don't innovate. They're embarrassed and scared, so they're snapping at anything that gets within reach.
...someone needs to shoot this rabid dog and put it out of its misery.
In any case, a bacteria culture was used on the organic components to digest the "unburnable" products. Later, the dried organic waste was used as a fuel for eletricity generation. Imagine the efficiency boots if the engineers could employ the electricity-producing bacteria as well.
...the cheapest bid. Don't forget that Cities and Municipalities operate on a budget, and although Flywheel Energy Storage units may have been more environment friendly and cheaper for long-term maintenance, they were probably far more expensive up-front. Long-term financing isn't often a concern for short-term problems, so my guess is that the 2k sq. ft. battery was the cheapest.
Considering that it's parent is highly overrated, this post, which is informative, should at least get one or two mods.
ha ha ha ha ha ha ha ha ha ha ha ha! I just want to know who'll be suckered into paying this license fee! ROFL!
I'm not surprised someone is using punctuated equilibrium to explain some of the development patterns in Free Software. Short periods of intense development followed by long periods of inactivity. Sounds like a pattern of a volunteer developer to me, giving his or her free time to a project. Since free time rarely occurs as contiguous segments, the parallelism to punctuated equilibrium is easy to see. I just hope this paper doesn't earn these two yokels anything but a quick pat on the back for pointing out the obvious.
Building your own binary involves making sure your "deb-src" line has been entered in your /etc/apt/sources.list file and then running the following commands:
$ apt-get build-dep PACKAGE
$ apt-get source --compile PACKAGE
You can certainly keep up to date w/most of the packages you need by recompiling in your own custom environment. Pull a couple source packages and test it out.
P.S. You can get around with not having to use apt-get's source.list file if you download the appropriate files yourself. Then use dpkg-buildpkg from the build-essentials package to build each package dependency manually. You are definitely NOT locked in with Debian.
It is already technologically possible to tap into conversations, even under adverse conditions. It will only become easier in the future. The legislation knows this and will certainly receive pressure from all sides, to maintain the citizen's right to privacy. We'll see how well they do.
I had once helped a couple friends install Linux systems at a small extension high school, one of them was a teacher railroaded into the part-time IT Coordinator position. Even though we had successfully deployed a stable, secure, low-maintenance, low-cost Linux environment, his peers were committed to causing his eventual resignation.
Windows was the only "real" answer for his peers, even while staring into the eye of a year of success with Linux. A year of success. Sometimes you simply cannot win against the engrained "religious" beliefs of some computer users, especially those people who influence financial and policy decisions in your work place.
Check out Debian's GNU/Hurd port. It's running from Debian's unstable branch (sid), but it looks installable and usable. GNU/Hurd isn't dead. It's just starting to stablize.
Debian has been running a sub-project called DebianEdu for some time now. You can read up on the project at the above link or from the mailing lists.
How does the proposed amendment to the copyright law possibly outweight the advantages we currently possess? It tries to solve one problem, which is, "How do we offset the cost to proactively obtain original works for the Public Domain?" You do it by requiring a proactive registration system?
% telnet mail.domain.tld 25 Trying mail.domain.tld...
Connected to mail.domain.tld...
Escape character is '^]'.
220 mail.domain.tld ESMTP Postfix
EHLO myhost.mydomain.tld
250-mail.domain.tld
250-PIPELINING
250-ETRN
250-XVERP
250 8BITMIME
MAIL FROM: postmaster@myhost.mydomain.tld
250 Ok
RCPT TO: spammer-sender@mail.domain.tld
550 User unknown in local recipient table
So, although VRFY may speed things up a bit, there are ways to validate the existance of an account. You can use this technique to validate whether or not a Sender address, as listed in the email for a local recepient, exists or not. If it doesn't exist, you can drop the email as a 550 error for not having a valid return address. It's all very logical, if not a slight slow down in email delivery.
IIRC, the exim email server can do this, and sendmail and postfix are customizable for such a mechanism. With postfix, you may have to use a custom filter program, but that's do-able.
Telnet will "work", for example. Open up an instance of tcpdump or some other real-time packet sniffer and telnet into your local machine. Type in your password. For every character you type in a telnet session, a packet is sent. This is one reason it is such a poor protocol for restricted or secure access. Add the fact that it's a plain text protocol, and someone could mimic your biometric quite easily.
SSH, on the other hand, has lots of little enhancements to combat the network sniffer. Firstly, the traffic is encrypted. Secondly, ssh doesn't send your password one character at a time. It varies the packet sizes and timings "randomly", and well, it's just plain cool. So, unless you add a biometric test to password timing for the local ssh client used to connect to the server, you couldn't gather the information at all.
Use with HTTP would also depend upon the cooperation of the remote client, but if there's anything a knowledgable programmer has learned over the years, it's that you NEVER trust client information fully. (Just as people don't fully trust closed-source software, but that's way off topic.) Always validate your input.
So, although such biometric validation can be useful under certain circumstances, it's not reliable enough to be depended upon. I do like the idea that one poster presented for auditing user behavior, such as violating a system policy of sharing passwords for a single account, but once again, it's a very limited biometric.