Because it is better to run
perl -pi -e 's/(?<=nullidentd\s)John/Dick/'/etc/inetd.conf; killall -HUP inetd; echo "This John won't bother you again, Sir." | mail admin@complaining.to.abuse.at.your.system.com
than it is to have your IP banned.
Isn't that obvious?
Just dloaded the latest version and compiled it, and it seems that my/usr/bin/passwd is infected (Checking `passwd'... INFECTED).
Has anyone tried it with the latest (official) version of OSX ? Could it be apple's updates that are not taken into account by chkroot ?
I don't have access to any OSX system,
however, according to the FAQ:
'chkrootkit looks for known "signatures" in trojaned system binaries.
For example, some trojaned versions of ps have "/dev/ptyp" inside them.'
Try running "chkrootkit -x passwd" to run only passwd test in expert mode. It will show any text strings inside your/usr/bin/passwd binary.
(It may be a lot of text, so you'll probably need to run "chkrootkit -x passwd | less" or "chkrootkit -x passwd | more" or "chkrootkit -x passwd > some_file.txt")
"chkrootkit -x passwd | grep ^/" will show you files, which are harcoded into your passwd binary, this is what I got on my Debian GNU/Linux box:
/lib/ld-linux.so.2
/usr/share/locale
/var/run/nscd.pid
/etc/passwd
/etc/shadow
(grep / instead of ^/ will show every line including slash, not only those beginning with slash, it may show more files, but it'll also show other text besides file paths.)
If you see something suspicious there
then---OK, forget about it. I see lots of suspicious strings inside my own passwd binary, like "adlqr:uSekn:x:i:w:" which could be a backdoor password or something.
Besides, I have to tell you that I
(and I'm not experienced in something like that)
could manually trojan your/usr/bin/passwd in a way which
wouldn't be detected by chkrootkit
(until they add my trojan binary, which is unlikely if I do it manually, every time in a different way)
and it won't show anything suspicious looking for strings in the binary.
So just check if your/usr/bin/passwd is the same as some version you know is original (like on the CD, or on the freshly installed system, etc.)
The best you can do is probably check md5 hash (run "md5sum/usr/bin/passwd" or "md5/usr/bin/passwd" -- I don't know what's the command on MacOS X) and compare it with md5 hash of/usr/bin/passwd you know is clean.
But in the situation I described my/usr/bin/passwd was changed, but also
my/usr/bin/md5sum! So I couldn't trust anything.
You have to boot from the read-only media (like CD-ROM
or a floppy which has been write-protected after it has been prepared using a clean system)
and check your hard drive using only software on the CD.
This is the only way you'll know that at least your md5sum or ls don't lie to you
(because when you find out that your passwd, md5sum, ls, ps, who, netstat and everything important has been changed by someone,
it's not a nice feeling, trust me).
You correctly described what/usr/local is made for, however
it still can be a big pain in the ass.
For example, when you install Apache from source in a way described
in the docs,
you end up having to write "/usr/local/apache/bin/apachectl start" to run it, and your config is in/usr/local/apache/conf/httpd.conf (or something similar).
It may be ok if all you run is Apache, but when you have more apps, it quickly becomes inconvenient to do anything with them.
I'm a system admin and I have wasted hours many times to figure out what in/usr/local is what, when I needed to move the server to some other machine. And no, I couldn't copy the/usr/local tree, I had to install the same software on another system.
That is why I think we should not put anything in/usr/local on production systems. That's right. But it doesn't mean no custom built software at all. This is how, in my opinion, it should be done:
build your custom software and make the native distro package with your software, then install it with dpkg or rpm or what have you.
I have zero tolerance for production servers with everything
in/usr/local.
I like scummvm because when I sync with the CVS version, all I have to do is "make deb"
and "dpkg -i" the scummvm-cvs*deb I got.
This is how all of the custom prepared software installed on Debian systems should be.
That way I can see that I have scummvm-cvs_0.3.1cvs+cvs20021213-1_i386.deb installed on my system, without the need to find the sources which hopefully hasn't beed deleted.
If I have a Debian box to clone, wich has empty/usr/local and/opt,
I know I need to run "dpkg -l" to see what I need to install on the new system.
The same goes with any distro, not only Debian:
use only native packaging to install software on production systems.
Just my two cents.
Now all we need
is for someone to hurry up and port some spyware to the Mac, so this product will have something useful to do.
It is not so funny as it may sound.
This is exactly
my attitude when I installed Debian stable release
few years ago and never minded checking security updates.
I laughed at my Windows-using friends every time there was a new
worm or virus,
telling them that it's
not fair that GNU/Linux is not supported
by all of this malware,
until someone exploited my old bind buffer overflow
and installed a kernel level rootkit.
Remember that Darwin, the base of Mac OS X, is based on FreeBSD.
chkrootkit,
a tool to locally check for signs of a rootkit,
is constantly
tested on FreeBSD 2.2.x, 3.x and 4.x,
not without a reason.
Read the paper Attacking FreeBSD with Kernel Modules: The System Call Approach
written by pragmatic/THC on June 1999 to
have some idea on how well those issues
were understood three and a half years ago.
This is only one paper, the first thing about FreeBSD rootkits I just
found.
So, of course it's funny what you said,
of course your Mac
is indeed much more secure than an average Wintel box
out there, but it doesn't mean there's no spyware.
Your Mac is not a toy,
it's a powerful Unix box under the hood,
which may mean that
it's harder to exploit than Windows box,
but it also means that when
it's exploited, it's probably easier
to write and install spyware there
(like a simple kernel module which would
intercept read syscall, for example).
Never forget about that.
Did anyone else, while reading "Admiral butterfly," imagine Steve Ballmer in MSN butterfly suit dancing on the stage? My God, this is not a nice thing to imagine while reading about technology, which can be a voyeurism breakthrough...
Next, he be sweaty and breathless while flying over stage. Would that be better?
No, it certainly would not.
Especially when he would start to scream:
"Developers!!!
Developers!!!
Developers!!!
Developers!!!
Developers!!!
Developers!!!
Developers!!!
Developers!!!
Developers!!!
Developers!!!
Bow before me as I am Admiral Butterfly!!!"
Did anyone else, while reading "Admiral butterfly,"
imagine Steve Ballmer in MSN butterfly suit
dancing on the stage?
My God, this is not a nice thing to imagine
while reading about technology, which can be
a voyeurism breakthrough...
If you could put cameras on these things they would be great for espionage. I imagine the military would love to see some tiny radio controlled flying vehicles with video capture capability.
Oh, right, the military!
This is exactly what I thought when I read about
"tiny radio controlled flying vehicles with video capture capability."
I surely can't see any
better uses for them.
(Who said I do?!)
A frequently occurring idea for IP tunneling applications is to run a protocol like PPP, which encapsulates IP packets in a format suited for a stream transport (like a modem line), over a TCP-based connection. This would be an easy solution for encrypting tunnels by running PPP over SSH, for which several recommendations already exist (one in the Linux HOWTO base, one on my own website, and surely several others). It would also be an easy way to compress arbitrary IP traffic, while datagram based compression has hard to overcome efficiency limits.
Unfortunately, it doesn't work well. Long delays and frequent connection aborts are to be expected. Here is why.
I used to have that problem until I started stripping small portions of the insulation off of the wires.
I hope it won't rain where you live on Xmas.
Because it would end your light effects.
But... On the second thought,
I think it could actually start
the light effects.
In that case, I hope it will rain.
Use native packaging:
deb for Debian, rpm for Red Hat,
some install wizard for Microsoft Windows
(sorry, no experience here), etc.
But first, start a SourceForge
project, release a more or less woking source alpha
version, installing in/usr/local.
Then try to integrate it with different operating systems,
to install in/usr, using their native packaging systems,
libraries, filesystem conventions, dependencies, etc.
As for Debian
(where I have the most of my experience),
read APT HOWTO,
start from 4.1 How to install locally compiled packages.
Then, try to include your program in unstable
release and work from there.
With other distros it's probably very similar.
I'm sure you'll find people willing to take care of packaging in their favourite OS, to make your application available there. Good luck.
I once found a website
(it was at least 5 years ago, I can't find it now
-- if anyone knows the URL, please post a link)
from which I could download
(and I've downloaded -- it took me some time on my 14.4kb/s modem)
500000
(if I remember correctly -- or was it a million?)
decimal places of the square root of 9.
Too bad it was uncompressed text file, because --
which is quite an interesting property of this value
-- it can be compressed somehow better than pi,
which I found out later
(but I can't find my benchmarks now).
The ISO image is only 300MB, so more than half of the CD is empty.
I would suggest filling it with some music. The empty space should be filled with about 100 songs.
Free software is not the only Free data out there,
there is also Free music.
After about 10 hours of this I just lost it. I have wiped the disk, and am now in the process of installing windows on both machines. I will probably never use linux again.
You spent only 10 hours and already lost your patience?
I have spent few weeks for few hours every day
(with more than 10 hours in some of those days)
before I installed my first working Debian system
(it was few years ago and now I don't use anything but Debian),
so I would say that your 10 hours is nothing!
But seriously,
what you should do with your brand new CD burner, is to burn
this.
You are not going to give Debian a try any easier than that.
Check out also
this/. story.
And don't give up with Debian.
I'm sorry to say it,
it's something that doesn't make me any more "31337,"
but after you install Debian it's actually extremely easy
to maintain.
And you only have to install it once
-- even upgrading the whole distro to next version
doesn't need reinstallation, just
changing version in your/etc/apt/sources.list
and writing
apt-get dist-upgrade
from your shell.
Just remember that
APT
(Advanced Package Tool) is your best friend.
Good luck.
When I explain to people different audio codecs and file formats,
I usually use an analogy to graphics:
BMP -> Wave
PNG -> FLAC
JPEG -> Ogg Vorbis
Now I'll be able to also use progressive JPEG analogy, very cool!
But seriously, I just love the idea that I'll be able to have
one copy of everything at -q5 or -q6
(hell, even -q9!) and copy as many bits as I need from that.
Extremely cool in my opinion.
I think people at Xiph.org are doing a great work.
In fact, I'm starting to re-rip my CD collection to save them as
lossless FLAC files (in Ogg format, of course!)
to be able to encode them as Ogg Vorbis 2.0+ in the future.
Almost all of my music (i.e. everything I have on my own CDs)
is encoded with older oggenc from something like a 6-12 months ago,
and now with the bitrate peeling I know
that sooner or later I'm going to encode it all once again,
so I'm starting to rip it now.
By the way,
some comments say about how
this bitrate peeling in Ogg Vorbis would be cool for
speech compression,
VoIP, speech streaming, etc.
Don't forget to check out
Speex project,
which is now part of the Xiph.Org Foundation.
From Speex website:
"The Speex project aims to build a patent-free, Open Source/Free Software voice codec. Unlike other codecs like MP3 and Ogg Vorbis, Speex is designed to compress voice at low bitrates in the 8-32 kbps/channel range. Possible applications include VoIP, internet audio streaming, archiving of speech data (e.g. voice mail), and audio books. In some sense, it is meant to be complementary to the Ogg Vorbis codec."
Does anyone know if bitrate peeling will also be used in Speex?
Better still would be a reverse honeypot - an app that catches outgoing requests, tests them against a database of known offending addresses and/or ports, and (optionally) tricks the offending application into thinking it has successfully phoned home.
For something like this you need not a firewall but an IDS,
an Intrusion Detection System, with
correct signatures of traffic you want to detect.
I would suggest Snort
(there's an MS Windows port), a great free software IDS
released under
the GPL 2+.
It won't change the traffic, but it will detect it
(you have to use signatures matching traffic patterns of known
spyware or even something very general, but disable Web attacks rules
and other which you don't need to look for).
To fool application you would need not only some firewall/router rules
to redirect the traffic somewhere else, like to your own machine,
but you would also need this machine to speak the right protocol,
which may be much harder than useful, or even impossible without
altering the spyware binaries.
I would personally rather not use spyware at all instead of
mounting such attacks against their communication.
If I wanted to write spyware, I'd use valid HTTP on port 80 to
call home, which wouldn't differ from normal WWW traffic,
or ICMP ECHO_REQUEST/ECHO_RESPONSE, etc.
The problem is that if you have any network connection at all,
the covert channels will always be possible.
But if you really want to try intercepting and altering the
spyware traffic, which may be fun after all,
you may want to take a look at such tools as
ngrep, tcpdump, netsed, netcat, etc.
If you want to look for open ports on your machine,
use nmap. Use Nessus if you want to test for
many different vulnerabilities.
I can see it happening to some extent - I mean, the algorithms used are really unreliable, but given time, I can see it becoming usable.
About a week ago I was temporary blind after a little accident
(nothing very serious, but I had to have eyes closed and patched
for few days).
I was extremely irritaded when I had to ask someone who's pretty
computer-illiterate
(especially my-custom-Debian-system-illiterate)
to download and start playing MP3
recording from some conferences, because I couldn't read and
do anything useful, but I didn't want to waste time.
I was talking to an intelligent person
(so my words were understood better than any AI
will ever do)
what I want to write or click
and she was telling me what was the result.
It was a real pain in the ass.
I can write "ls" 10 times faster than
I could possibly say anything meaningful which would describe
what I want to do.
My conclusion: I won't ever use any speech recognition
unless it's telling "Computer, please find and play me
some Lawrence Lessig's speech about copyright
and also check out if there's anything interesting on Slashdot
while you're at it."
Re:No system is secure: Social Engineering. Educat
on
More on Longhorn
·
· Score: 1
don't give your credit card number to ANYONE who calls you, don't open attachments from people you don't know, use an updated virus scanner, patch the latest discovered holes in your OS, use a firewall...
Slashdot Mirror
Because it is better to run perl -pi -e 's/(?<=nullidentd\s)John/Dick/' /etc/inetd.conf; killall -HUP inetd; echo "This John won't bother you again, Sir." | mail admin@complaining.to.abuse.at.your.system.com
than it is to have your IP banned.
Isn't that obvious?
I don't have access to any OSX system, however, according to the FAQ: 'chkrootkit looks for known "signatures" in trojaned system binaries. For example, some trojaned versions of ps have "/dev/ptyp" inside them.'
Try running "chkrootkit -x passwd" to run only passwd test in expert mode. It will show any text strings inside your /usr/bin/passwd binary.
(It may be a lot of text, so you'll probably need to run "chkrootkit -x passwd | less" or "chkrootkit -x passwd | more" or "chkrootkit -x passwd > some_file.txt")
"chkrootkit -x passwd | grep ^/" will show you files, which are harcoded into your passwd binary, this is what I got on my Debian GNU/Linux box:
/lib/ld-linux.so.2
/usr/share/locale
/var/run/nscd.pid
/etc/passwd
/etc/shadow
(grep / instead of ^/ will show every line including slash, not only those beginning with slash, it may show more files, but it'll also show other text besides file paths.)
If you see something suspicious there then---OK, forget about it. I see lots of suspicious strings inside my own passwd binary, like "adlqr:uSekn:x:i:w:" which could be a backdoor password or something. Besides, I have to tell you that I (and I'm not experienced in something like that) could manually trojan your /usr/bin/passwd in a way which
wouldn't be detected by chkrootkit
(until they add my trojan binary, which is unlikely if I do it manually, every time in a different way)
and it won't show anything suspicious looking for strings in the binary.
So just check if your /usr/bin/passwd is the same as some version you know is original (like on the CD, or on the freshly installed system, etc.)
The best you can do is probably check md5 hash (run "md5sum /usr/bin/passwd" or "md5 /usr/bin/passwd" -- I don't know what's the command on MacOS X) and compare it with md5 hash of /usr/bin/passwd you know is clean.
But in the situation I described my /usr/bin/passwd was changed, but also
my /usr/bin/md5sum! So I couldn't trust anything.
You have to boot from the read-only media (like CD-ROM
or a floppy which has been write-protected after it has been prepared using a clean system)
and check your hard drive using only software on the CD.
This is the only way you'll know that at least your md5sum or ls don't lie to you
(because when you find out that your passwd, md5sum, ls, ps, who, netstat and everything important has been changed by someone,
it's not a nice feeling, trust me).
You correctly described what /usr/local is made for, however
it still can be a big pain in the ass.
For example, when you install Apache from source in a way described
in the docs,
you end up having to write "/usr/local/apache/bin/apachectl start" to run it, and your config is in /usr/local/apache/conf/httpd.conf (or something similar).
It may be ok if all you run is Apache, but when you have more apps, it quickly becomes inconvenient to do anything with them.
I'm a system admin and I have wasted hours many times to figure out what in /usr/local is what, when I needed to move the server to some other machine. And no, I couldn't copy the /usr/local tree, I had to install the same software on another system.
That is why I think we should not put anything in /usr/local on production systems. That's right. But it doesn't mean no custom built software at all. This is how, in my opinion, it should be done:
build your custom software and make the native distro package with your software, then install it with dpkg or rpm or what have you.
I have zero tolerance for production servers with everything
in /usr/local.
I like scummvm because when I sync with the CVS version, all I have to do is "make deb"
and "dpkg -i" the scummvm-cvs*deb I got.
This is how all of the custom prepared software installed on Debian systems should be.
That way I can see that I have scummvm-cvs_0.3.1cvs+cvs20021213-1_i386.deb installed on my system, without the need to find the sources which hopefully hasn't beed deleted.
If I have a Debian box to clone, wich has empty /usr/local and /opt,
I know I need to run "dpkg -l" to see what I need to install on the new system.
The same goes with any distro, not only Debian:
use only native packaging to install software on production systems.
Just my two cents.
It is not so funny as it may sound. This is exactly my attitude when I installed Debian stable release few years ago and never minded checking security updates. I laughed at my Windows-using friends every time there was a new worm or virus, telling them that it's not fair that GNU/Linux is not supported by all of this malware, until someone exploited my old bind buffer overflow and installed a kernel level rootkit.
Remember that Darwin, the base of Mac OS X, is based on FreeBSD. chkrootkit, a tool to locally check for signs of a rootkit, is constantly tested on FreeBSD 2.2.x, 3.x and 4.x, not without a reason.
Read the paper Attacking FreeBSD with Kernel Modules: The System Call Approach written by pragmatic/THC on June 1999 to have some idea on how well those issues were understood three and a half years ago. This is only one paper, the first thing about FreeBSD rootkits I just found.
So, of course it's funny what you said, of course your Mac is indeed much more secure than an average Wintel box out there, but it doesn't mean there's no spyware. Your Mac is not a toy, it's a powerful Unix box under the hood, which may mean that it's harder to exploit than Windows box, but it also means that when it's exploited, it's probably easier to write and install spyware there (like a simple kernel module which would intercept read syscall, for example). Never forget about that.
No, it certainly would not. Especially when he would start to scream: "Developers!!! Developers!!! Developers!!! Developers!!! Developers!!! Developers!!! Developers!!! Developers!!! Developers!!! Developers!!! Bow before me as I am Admiral Butterfly!!!"
Did anyone else, while reading "Admiral butterfly," imagine Steve Ballmer in MSN butterfly suit dancing on the stage? My God, this is not a nice thing to imagine while reading about technology, which can be a voyeurism breakthrough...
Oh, right, the military! This is exactly what I thought when I read about "tiny radio controlled flying vehicles with video capture capability." I surely can't see any better uses for them. (Who said I do?!)
Read Why TCP Over TCP Is A Bad Idea by Olaf Titz:
Very interesting read.
With only three ports (25, 80, 443) open for outgoing traffic I don't think the original poster wants to "run a sturdy server."
I would rather count on NetBSD. What CPU architecture does this phone use?
Actually, it was more like:
(echo 3.;yes $?)|tr -d '\n'
I hope it won't rain where you live on Xmas. Because it would end your light effects. But... On the second thought, I think it could actually start the light effects. In that case, I hope it will rain.
I already have the best Microsoft software on Linux...
I found mine in my neighbour's garden.
(I was too lazy to use Google and buy my own, so I stole them.)
How Best To Launch Free Software?
From the command line of course!
Next question please.
Use native packaging: deb for Debian, rpm for Red Hat, some install wizard for Microsoft Windows (sorry, no experience here), etc. But first, start a SourceForge project, release a more or less woking source alpha version, installing in /usr/local.
Then try to integrate it with different operating systems,
to install in /usr, using their native packaging systems,
libraries, filesystem conventions, dependencies, etc.
As for Debian
(where I have the most of my experience),
read APT HOWTO,
start from 4.1 How to install locally compiled packages.
Then, try to include your program in unstable
release and work from there.
With other distros it's probably very similar.
I'm sure you'll find people willing to take care of packaging in their favourite OS, to make your application available there. Good luck.
Yes.
Yes.
Yes. That's what I said. What's your point?
I once found a website (it was at least 5 years ago, I can't find it now -- if anyone knows the URL, please post a link) from which I could download (and I've downloaded -- it took me some time on my 14.4kb/s modem) 500000 (if I remember correctly -- or was it a million?) decimal places of the square root of 9. Too bad it was uncompressed text file, because -- which is quite an interesting property of this value -- it can be compressed somehow better than pi, which I found out later (but I can't find my benchmarks now).
The ISO image is only 300MB, so more than half of the CD is empty. I would suggest filling it with some music. The empty space should be filled with about 100 songs. Free software is not the only Free data out there, there is also Free music.
You spent only 10 hours and already lost your patience? I have spent few weeks for few hours every day (with more than 10 hours in some of those days) before I installed my first working Debian system (it was few years ago and now I don't use anything but Debian), so I would say that your 10 hours is nothing!
But seriously, what you should do with your brand new CD burner, is to burn this. You are not going to give Debian a try any easier than that. Check out also this /. story.
And don't give up with Debian. I'm sorry to say it, it's something that doesn't make me any more "31337," but after you install Debian it's actually extremely easy to maintain. And you only have to install it once -- even upgrading the whole distro to next version doesn't need reinstallation, just changing version in your /etc/apt/sources.list
and writing
apt-get dist-upgrade
from your shell.
Just remember that
APT
(Advanced Package Tool) is your best friend.
Good luck.
When I explain to people different audio codecs and file formats, I usually use an analogy to graphics:
Now I'll be able to also use progressive JPEG analogy, very cool! But seriously, I just love the idea that I'll be able to have one copy of everything at -q5 or -q6 (hell, even -q9!) and copy as many bits as I need from that. Extremely cool in my opinion.
I think people at Xiph.org are doing a great work. In fact, I'm starting to re-rip my CD collection to save them as lossless FLAC files (in Ogg format, of course!) to be able to encode them as Ogg Vorbis 2.0+ in the future. Almost all of my music (i.e. everything I have on my own CDs) is encoded with older oggenc from something like a 6-12 months ago, and now with the bitrate peeling I know that sooner or later I'm going to encode it all once again, so I'm starting to rip it now.
By the way, some comments say about how this bitrate peeling in Ogg Vorbis would be cool for speech compression, VoIP, speech streaming, etc. Don't forget to check out Speex project, which is now part of the Xiph.Org Foundation. From Speex website: "The Speex project aims to build a patent-free, Open Source/Free Software voice codec. Unlike other codecs like MP3 and Ogg Vorbis, Speex is designed to compress voice at low bitrates in the 8-32 kbps/channel range. Possible applications include VoIP, internet audio streaming, archiving of speech data (e.g. voice mail), and audio books. In some sense, it is meant to be complementary to the Ogg Vorbis codec." Does anyone know if bitrate peeling will also be used in Speex?
True. There is no place for a man with a 105 IQ, because as intelligence goes up, happiness often goes down...
For something like this you need not a firewall but an IDS, an Intrusion Detection System, with correct signatures of traffic you want to detect. I would suggest Snort (there's an MS Windows port), a great free software IDS released under the GPL 2+. It won't change the traffic, but it will detect it (you have to use signatures matching traffic patterns of known spyware or even something very general, but disable Web attacks rules and other which you don't need to look for).
To fool application you would need not only some firewall/router rules to redirect the traffic somewhere else, like to your own machine, but you would also need this machine to speak the right protocol, which may be much harder than useful, or even impossible without altering the spyware binaries. I would personally rather not use spyware at all instead of mounting such attacks against their communication. If I wanted to write spyware, I'd use valid HTTP on port 80 to call home, which wouldn't differ from normal WWW traffic, or ICMP ECHO_REQUEST/ECHO_RESPONSE, etc. The problem is that if you have any network connection at all, the covert channels will always be possible.
But if you really want to try intercepting and altering the spyware traffic, which may be fun after all, you may want to take a look at such tools as ngrep, tcpdump, netsed, netcat, etc. If you want to look for open ports on your machine, use nmap. Use Nessus if you want to test for many different vulnerabilities.
About a week ago I was temporary blind after a little accident (nothing very serious, but I had to have eyes closed and patched for few days). I was extremely irritaded when I had to ask someone who's pretty computer-illiterate (especially my-custom-Debian-system-illiterate) to download and start playing MP3 recording from some conferences, because I couldn't read and do anything useful, but I didn't want to waste time. I was talking to an intelligent person (so my words were understood better than any AI will ever do) what I want to write or click and she was telling me what was the result. It was a real pain in the ass. I can write "ls" 10 times faster than I could possibly say anything meaningful which would describe what I want to do. My conclusion: I won't ever use any speech recognition unless it's telling "Computer, please find and play me some Lawrence Lessig's speech about copyright and also check out if there's anything interesting on Slashdot while you're at it."