By no talking and no phones, you mean "I don't talk and don't use the phone", right? Because there generally *is* talking and phone ringing/use by other people in the theater. And if the half gallon of soda I just drank prompts me to have to pee before the movie's over, a pause button would certainly be handy.
Was your point to list how irritating theaters can be?:)
Does he work on the gnome Evolution team, and on Kmail? Vfolders based on searches are cool. As I mentioned in another post, I'd think that a VFS type thing that presented the mbox file as something like a maildir would be a somewhat elegant solution, though I'm not sure what kind of support OS X has for that kind of thing.
A VFS subsystem would be handy for lots of other things, too - I'm specifically thinking about KDE's audio ripping stuff as an example, where an audio CD is shown as having an ogg folder and mp3 folder where you can drag the CDDB-looked-up filenames out and they're encoded on the fly.
Couldn't that just be handled by a plugin that mapped "files" to the appropriate message inside of the mbox file, kinda like the address book workaround? I thought that's what the plugin architecture was for. The use of a virtual file system would work as well for this...
By the way, HFS doesn't handle lots of small files very well, IMO. I had a backup server running on 10.3 (with journaling), and *clean* reboots took hours - several hours. Granted, it had some 750 million files to deal with, and most people won't get that many files built up in their maildir, but I'm not sure how good of an idea it is to use maildirs for more than a few people on a Mac. Unless someone's got ReiserFS support on OS X, that is, and I've a feeling that'd bring its own problems in a mac environment.
I'm not sure, but I'd suggest digging around in google to find a way to disable compatability resource fork generation or somethign along those lines. That's OS X's way of storing resource forks on a non-HFS filesystem, and I could have sworn that there was a mount option or something that could be set to disable that. Check out macosxhints.com as well - theres lots of useful stuff up there along these lines.
As far as blocking them at the network level - you'd probably need a proxy or a different file server. The file server won't help if you're peer to peer, and I don't know of any smb proxies, so you're probably stuck with figuring out how to disable them on OS X...
Alright - you took the time to use bold and bullet points. So, I'll concede that the impetus behind the main post was a bit of irritation over the Apple fanboys getting excited every time Apple does anything, whether it's truly innovative or not. I certainly don't hate Apple - I'm typing this with Firefox running under Jaguar on a Dual G4 machine.:)
Spotlight's implementation is cool. The integration is really neat. Generating a hashing algorithm that will scale well to handle the indexing of the all those English-based file contents without lots of hash collisions (and the associated slowdown in search speed) is a notable feat - if they did that.
The realtime updating isn't terribly amazing - they control the portal to file access, so updating the database with the contents of a file at creation/edit time is not a grand feat. I did that once on a smaller scale (the repository indexes about 75GB). BFS did that in the 90's (though I don't think it indexed file contents - just metadata). Windows did that in 2001. I guess I'm not impressed at the idea because, if I was working on a system-wide search system, I'd definitely investigate using hooks to the filesystem to keep an index up to date, and I expect people who get paid more than me to do this for a living to be more creative than me. I wouldn't have thought to call it spotlight and to shine a spotlight on the files found, but that doesn't count as innovation - that's fluff.:)
I honestly think that the main reason this hasn't been done before is one of lack of cheap storage space or lack of spare processor power - and lack of a coherent UI spec on Win32. The idea is pretty obvious, and so it irritates me when people say it's some kind of amazing innovation. The implementation of the UI is very good. I'm also fairly impressed with the search syntax. So I guess they did implement it about as creatively as one can expect, but it's just not knocking my socks off.
And yes, I'm defining the separation between the idea and the implementation as whatever best fits my argument.:)
Use rsync and hardlinked snapshots. There are lots of examples out there. I rolled my own a while back, but if you want something relatively nicely polished and based on that idea, check out dirvish (I didn't find that until after I already had my system set up).
I really like having several months worth of nightly snapshots, all conveniently accessible just like any other filesystem, and just taking up slightly more than the space of the changed files.
Just for fun, find all the messages he sent containing image attachments with grep:
for F in `grep -lr george ~/Maildir`; do grep -i 'mime.*: image/' $F; done
Basically. (files a maildir shouldn't have spaces or other weird chars, so the shell splitting will work fine). Spotlight's certainly much easier and quicker than that, though - and not all greps have the recursive option.:)
BFS did automatic indexing of metadata at the filesystem level.:)
The MySQL/web example was just to illustrate a prior implementation of a similar backend concept. It's relevent because the only access to the files is through the web interface, which auto-updates. If all of your files were stored in the repository, it'd index them all. Spotlight's repository is the hard drive (minus excluded ranges). The *concept* is similar, though Apple's implementation is obviously more polished and does more than is easily done with HTML.:) I'm not comparing my GUI skillz with those in Cupertino at all, just illustrating that the general idea isn't breathtaking.
A Reiser4 plugin could do the same thing at the filesystem level on Linux (is anyone listening - write that plugin), indexing everything on the system in a database. Hooray for filesystems with plugin capability! Speaking of which, I haven't heard how Spotlight will behave with files modified in terminal sessions - that much I'm very interested in.
And I like the GUI on spotlight. The highlighted files in the finder view are nifty, the "saved searches represented as folders" idea is cool, and the tight integration is great. That feature is not driving my purchase of the upgrade, though - the new driver support is.:)
I am more efficient with a CLI because the kind of work I do is not well assisted by a GUI. This does not make me superior to anyone. Different people learn differently and work differently, and should therefore use tools that they're most comfortable with. I wholeheartedly recommend Win32 for most of my users (and OS X for several others), because it's the best tool for them. That does not make them inferior (though, not learning to effectively use their environment of choice might bump them down a notch).
Also, I did not denigrate the GUI or any UI devleopment (command line tools have to take user interface into account, too, possibly more so than GUI apps in some cases). In fact, I stated that the tech was not impressive, and granted that the GUI was the only innovative part.
Fast app launcing? Prelinking has been around for a long time, too.;)
Nice strawman regarding your *assumption* about my feelings about user interface design, but this has nothing to do with that. Apple subscribes to the "simplicity is better" school of design, which works fine in their target market. They do a damned good job of it. I don't particularly like it for my uses, but that's because it doesn't work well with my particular usage patterns. I support several users who are on OS X systems, and that's fine for them. I'm actually very interested in interface design, and I'm not talking about pretty icons. Interface design is a major part of each and every program I develop, both for my own personal use and for public consumption.
For the record, I read the docs when I started in on this. Uninformed opinions suck. And, for the record, I could give half a shit about "hacker respect". I use vim and a command line because they're the most efficient tools for the tasks that *I* use them for. I've put the time in to learning them, and it pays off. I'd be a fool to expect all of my users to do the same, though. For lots of them, GUI tools really are better. And there are some situations where I prefer a GUI. I'm not a sadist. Heck, I run X most of the time (which might contradict the sadism part, in some circles).:)
I think you read my posts and figured I was one of those 31337 kidz that pushed a CLI over a GUI at all costs, because only super geeks should use computers, and then only at a text console. That's straight up wrong. A good interface is mandatory for a good program, and often that means a good GUI. Apple does a good GUI for their target market, and spotlight is a really good GUI on top of the search features it provides. But the praise is all directed at the least impressive part - the technology behind spotlight. That's just a simple database tied in with the file system.
My point? The technology just isn't amazing. The application of the technology and the UI they used to apply it deserves some credit, but the general concept is old news.
BTW, I didn't say that Spotlight's just find and grep - I said that find and grep can search contents of files in response to someone who said it was impossible. I said that Spotlight's just an enhanced version of locate with strong integration with the OS. Call it an understatement if you like, but don't call it wrong. I fact, I don't believe that I was wrong about anything or "pulled anything out of my ass"
To answer your riddle, BeOS. It's not real popular now, what with the whole "company sold all assets years ago" thing, but it had indexed metadata built right in to the filesystem - years ago. BFS is cool.
Oh, and the automobile is just a carriage with an engine turning the wheels. The assembly line was the real revolution.;) (yes, I'm kidding)
find can't do that? I use this to find content in email all the time: grep 'john doe' `find ~/Maildir -type f`
The idea of keeping indexed content in a database is not a new idea. Locate did it with just filenames decades ago. I've personally done it using MySQL's full-text indexes to manage a large document repository. This document repository even has a nice web-based GUI that will do "grep-like searches" in the database for content and document names. It gets the text out of several well-known document types, including PDFs. It updates when files are added It allows searching meta data, file contents, and file names. It has a pretty GUI based on user feedback. Whooptie-shit, it took a few weeks to develop. I guess I deserve a/. story and a whole bunch of zealots loving me for my innovation.
Spotlight is just a simple UI on a commonly used programming idiom. Generate a database with some keys that correspond to words in a document, use a hashing algorithm to get about O(1) search times, repeat search on every key press.
Holy cow! That's amazing! A GUI for something that programmers have been doing for years! All bow to the almighty Apple.
It's cool, and they're the first to do it "this way" on "that OS", and the first to make it easy for dummies, but revolutionary it's not. If you think it is, *you* don't get it.
If you're running samba as a file server, you can set those files to hidden or veto them relatively easily. I'm not sure how to turn them off on the Mac side, so I just set them to hidden on the server.
If you're running windows servers (that's just weird), then I'm not sure what to tell you. Set up a scheduled task to get rid of them...
I haven't used it, so I don't know how fast it is. If the results are truly instant, that'd be dandy. If the results show up like the network browsing results - you know, a few, then a few more, and some more - it'll just be a pain in the butt.
I'm saying I'd like it to be selectable. I often see all those extra results as a distracting waste of time in other apps that do the same thing, but do agree that some feedback is nice. Of course, the letters that appear in the textbox as the user types count as "feedback" too...:)
I'm not knocking Apple for the pretty UI, though. It's a Good Thing. I'm knocking the press and users who claim that it's the most un-friggin-believable super cool new awesome enhacement ever, when it's just a simple UI tweak that's been used many times before.
Thanks for the note about contents of some files being indexed, though I wonder if that's limited to recognized/specific file types, or all files in general...
The main innovation in Spotlight is incremental searching, not waiting until pressing enter
s/onSubmit/onKeyPress/
Boy, what will those fellows at Cupertino think of next? I personally dislike things that search as I type - I know what I'm searchign for, and I can press "return" when I've typed it. Searching on the first few letters is just a waste of processing time, esp when I misspell something.
And from what I've read, it doesn't involve grep. It doesn't search filecontents, just metadata (which most of the OS X users I know don't even use). Windows Indexing Service, however, *does* search file contents, and was introduced in Windows 2000. You know, 5 years ago? Using that little NTFS thing that allows file metadata?
Apple may have put a fancy interface on it, but that's all of the innovating they did on this one. They have done some cool stuff, but Spotlight is not up there with the "most amazing".
Before you go to bed, "emerge -B yourpackageandoptions". That'll build a binary package, but not install it. Then, later on, just install the package (emerge -K yourpackage), which takes about the same time as any other package manager. If you choose reasonable cflags your binaries will work on your other machines, too.
BTW, I used distcc over ssh to use distcc on some of the machines at work before I picked up a 2GHz machine at home. It worked pretty well.:)
Spotlight is "locate" with something like fam automatically updating a database when a file's name or metadata is changed. The gnu findutils have been on *nix systems- including OS X for a long time, and have been available under Win32 for as long. Windows also has had what's called "indexing service" since Win2K, and "Microsoft Fast Find" as part of Ms Office for a while. All of those things are file indxing systems like spotlight. All Apple did to "innovate" was to make the interface a little prettier and tie it in to Finder/Explorer/the file system API a little more tightly. It certainly doesn't "change everything", since I still plan to use locate from the terminal on OS X, like I've been doing since 10.2.
Anyway, to get that functionality on your windows network, turn indexing service on - it's off by default. Then define some usage guidelines and distribute them to your users. The reason they can't all work together in a coherent way is that they don't have a coherent plan. Solving the problem with an index is not solving the problem, it's working around the problem.:)
Probably experience. I get a lot more probes than attacks on my Apache servers. Those probes are looking for a vulnrability, and don't take much time to run. Trying every attack on every web server does take time and bandwidth, and makes the kiddie a little more obvious target. At least a couple of them have thought of that by now...
The busy 4-way stops that I've seen generally include at least 2 people who think that all they have to do is stop, "waiting their turn" is a rather unnecesary component.
Why would you move anything? All you have to do is change the server string. Oh, and turn off logging, since your server logs will be filled up with IIS vulnurability attacks within minutes.
Why do people insist on making anything but democracy sound bad? We don't even live in a true democracy here in the US, but somehow that's the ultimate form of government. Other forms have good points, too, and the one we're using sure isn't working out all that well...
No, posts complaining about the "increased noise over the last X period of time" have been happening since the dawn of Slashdot. They're usually anonymous cowards, to hide that they've only had accounts with/. for a few months. "Moderated insightful" my butt.
I'm partial to just assuming that the wireless network is unsafe, and setting up VPN connections to get to anything outside of the wireless. I trust several of the VPN technologies "enough", wheras I just don't trust anything wireless. The earlier post mentioning "captive portals" is right on, IMHO.
That's not irony, it's just sad, sad reality.
Does submitting messages in unintelligible English count as security through obscurity?
I think the PDF would still be secure if the only instructions for getting the confidential info were written by the submitter in "Engligh"...
By no talking and no phones, you mean "I don't talk and don't use the phone", right? Because there generally *is* talking and phone ringing/use by other people in the theater. And if the half gallon of soda I just drank prompts me to have to pee before the movie's over, a pause button would certainly be handy.
:)
Was your point to list how irritating theaters can be?
Does he work on the gnome Evolution team, and on Kmail? Vfolders based on searches are cool. As I mentioned in another post, I'd think that a VFS type thing that presented the mbox file as something like a maildir would be a somewhat elegant solution, though I'm not sure what kind of support OS X has for that kind of thing.
A VFS subsystem would be handy for lots of other things, too - I'm specifically thinking about KDE's audio ripping stuff as an example, where an audio CD is shown as having an ogg folder and mp3 folder where you can drag the CDDB-looked-up filenames out and they're encoded on the fly.
Couldn't that just be handled by a plugin that mapped "files" to the appropriate message inside of the mbox file, kinda like the address book workaround? I thought that's what the plugin architecture was for. The use of a virtual file system would work as well for this...
By the way, HFS doesn't handle lots of small files very well, IMO. I had a backup server running on 10.3 (with journaling), and *clean* reboots took hours - several hours. Granted, it had some 750 million files to deal with, and most people won't get that many files built up in their maildir, but I'm not sure how good of an idea it is to use maildirs for more than a few people on a Mac. Unless someone's got ReiserFS support on OS X, that is, and I've a feeling that'd bring its own problems in a mac environment.
$80 for a free trial?
I'm not sure, but I'd suggest digging around in google to find a way to disable compatability resource fork generation or somethign along those lines. That's OS X's way of storing resource forks on a non-HFS filesystem, and I could have sworn that there was a mount option or something that could be set to disable that. Check out macosxhints.com as well - theres lots of useful stuff up there along these lines.
As far as blocking them at the network level - you'd probably need a proxy or a different file server. The file server won't help if you're peer to peer, and I don't know of any smb proxies, so you're probably stuck with figuring out how to disable them on OS X...
Alright - you took the time to use bold and bullet points. So, I'll concede that the impetus behind the main post was a bit of irritation over the Apple fanboys getting excited every time Apple does anything, whether it's truly innovative or not. I certainly don't hate Apple - I'm typing this with Firefox running under Jaguar on a Dual G4 machine. :)
:)
:)
Spotlight's implementation is cool. The integration is really neat. Generating a hashing algorithm that will scale well to handle the indexing of the all those English-based file contents without lots of hash collisions (and the associated slowdown in search speed) is a notable feat - if they did that.
The realtime updating isn't terribly amazing - they control the portal to file access, so updating the database with the contents of a file at creation/edit time is not a grand feat. I did that once on a smaller scale (the repository indexes about 75GB). BFS did that in the 90's (though I don't think it indexed file contents - just metadata). Windows did that in 2001. I guess I'm not impressed at the idea because, if I was working on a system-wide search system, I'd definitely investigate using hooks to the filesystem to keep an index up to date, and I expect people who get paid more than me to do this for a living to be more creative than me. I wouldn't have thought to call it spotlight and to shine a spotlight on the files found, but that doesn't count as innovation - that's fluff.
I honestly think that the main reason this hasn't been done before is one of lack of cheap storage space or lack of spare processor power - and lack of a coherent UI spec on Win32. The idea is pretty obvious, and so it irritates me when people say it's some kind of amazing innovation. The implementation of the UI is very good. I'm also fairly impressed with the search syntax. So I guess they did implement it about as creatively as one can expect, but it's just not knocking my socks off.
And yes, I'm defining the separation between the idea and the implementation as whatever best fits my argument.
Use rsync and hardlinked snapshots. There are lots of examples out there. I rolled my own a while back, but if you want something relatively nicely polished and based on that idea, check out dirvish (I didn't find that until after I already had my system set up).
I really like having several months worth of nightly snapshots, all conveniently accessible just like any other filesystem, and just taking up slightly more than the space of the changed files.
Just for fun, find all the messages he sent containing image attachments with grep:
:)
for F in `grep -lr george ~/Maildir`; do grep -i 'mime.*: image/' $F; done
Basically. (files a maildir shouldn't have spaces or other weird chars, so the shell splitting will work fine). Spotlight's certainly much easier and quicker than that, though - and not all greps have the recursive option.
BFS did automatic indexing of metadata at the filesystem level. :)
:) I'm not comparing my GUI skillz with those in Cupertino at all, just illustrating that the general idea isn't breathtaking.
:)
The MySQL/web example was just to illustrate a prior implementation of a similar backend concept. It's relevent because the only access to the files is through the web interface, which auto-updates. If all of your files were stored in the repository, it'd index them all. Spotlight's repository is the hard drive (minus excluded ranges). The *concept* is similar, though Apple's implementation is obviously more polished and does more than is easily done with HTML.
A Reiser4 plugin could do the same thing at the filesystem level on Linux (is anyone listening - write that plugin), indexing everything on the system in a database. Hooray for filesystems with plugin capability! Speaking of which, I haven't heard how Spotlight will behave with files modified in terminal sessions - that much I'm very interested in.
And I like the GUI on spotlight. The highlighted files in the finder view are nifty, the "saved searches represented as folders" idea is cool, and the tight integration is great. That feature is not driving my purchase of the upgrade, though - the new driver support is.
I am more efficient with a CLI because the kind of work I do is not well assisted by a GUI. This does not make me superior to anyone. Different people learn differently and work differently, and should therefore use tools that they're most comfortable with. I wholeheartedly recommend Win32 for most of my users (and OS X for several others), because it's the best tool for them. That does not make them inferior (though, not learning to effectively use their environment of choice might bump them down a notch).
Also, I did not denigrate the GUI or any UI devleopment (command line tools have to take user interface into account, too, possibly more so than GUI apps in some cases). In fact, I stated that the tech was not impressive, and granted that the GUI was the only innovative part.
Fast app launcing? Prelinking has been around for a long time, too. ;)
:)
;) (yes, I'm kidding)
Nice strawman regarding your *assumption* about my feelings about user interface design, but this has nothing to do with that. Apple subscribes to the "simplicity is better" school of design, which works fine in their target market. They do a damned good job of it. I don't particularly like it for my uses, but that's because it doesn't work well with my particular usage patterns. I support several users who are on OS X systems, and that's fine for them. I'm actually very interested in interface design, and I'm not talking about pretty icons. Interface design is a major part of each and every program I develop, both for my own personal use and for public consumption.
For the record, I read the docs when I started in on this. Uninformed opinions suck. And, for the record, I could give half a shit about "hacker respect". I use vim and a command line because they're the most efficient tools for the tasks that *I* use them for. I've put the time in to learning them, and it pays off. I'd be a fool to expect all of my users to do the same, though. For lots of them, GUI tools really are better. And there are some situations where I prefer a GUI. I'm not a sadist. Heck, I run X most of the time (which might contradict the sadism part, in some circles).
I think you read my posts and figured I was one of those 31337 kidz that pushed a CLI over a GUI at all costs, because only super geeks should use computers, and then only at a text console. That's straight up wrong. A good interface is mandatory for a good program, and often that means a good GUI. Apple does a good GUI for their target market, and spotlight is a really good GUI on top of the search features it provides. But the praise is all directed at the least impressive part - the technology behind spotlight. That's just a simple database tied in with the file system.
My point? The technology just isn't amazing. The application of the technology and the UI they used to apply it deserves some credit, but the general concept is old news.
BTW, I didn't say that Spotlight's just find and grep - I said that find and grep can search contents of files in response to someone who said it was impossible. I said that Spotlight's just an enhanced version of locate with strong integration with the OS. Call it an understatement if you like, but don't call it wrong. I fact, I don't believe that I was wrong about anything or "pulled anything out of my ass"
To answer your riddle, BeOS. It's not real popular now, what with the whole "company sold all assets years ago" thing, but it had indexed metadata built right in to the filesystem - years ago. BFS is cool.
Oh, and the automobile is just a carriage with an engine turning the wheels. The assembly line was the real revolution.
find can't do that? I use this to find content in email all the time:
/. story and a whole bunch of zealots loving me for my innovation.
grep 'john doe' `find ~/Maildir -type f`
The idea of keeping indexed content in a database is not a new idea. Locate did it with just filenames decades ago. I've personally done it using MySQL's full-text indexes to manage a large document repository. This document repository even has a nice web-based GUI that will do "grep-like searches" in the database for content and document names. It gets the text out of several well-known document types, including PDFs. It updates when files are added It allows searching meta data, file contents, and file names. It has a pretty GUI based on user feedback. Whooptie-shit, it took a few weeks to develop. I guess I deserve a
Spotlight is just a simple UI on a commonly used programming idiom. Generate a database with some keys that correspond to words in a document, use a hashing algorithm to get about O(1) search times, repeat search on every key press.
Holy cow! That's amazing! A GUI for something that programmers have been doing for years! All bow to the almighty Apple.
It's cool, and they're the first to do it "this way" on "that OS", and the first to make it easy for dummies, but revolutionary it's not. If you think it is, *you* don't get it.
If you're running samba as a file server, you can set those files to hidden or veto them relatively easily. I'm not sure how to turn them off on the Mac side, so I just set them to hidden on the server.
If you're running windows servers (that's just weird), then I'm not sure what to tell you. Set up a scheduled task to get rid of them...
I haven't used it, so I don't know how fast it is. If the results are truly instant, that'd be dandy. If the results show up like the network browsing results - you know, a few, then a few more, and some more - it'll just be a pain in the butt.
:)
I'm saying I'd like it to be selectable. I often see all those extra results as a distracting waste of time in other apps that do the same thing, but do agree that some feedback is nice. Of course, the letters that appear in the textbox as the user types count as "feedback" too...
I'm not knocking Apple for the pretty UI, though. It's a Good Thing. I'm knocking the press and users who claim that it's the most un-friggin-believable super cool new awesome enhacement ever, when it's just a simple UI tweak that's been used many times before.
Thanks for the note about contents of some files being indexed, though I wonder if that's limited to recognized/specific file types, or all files in general...
The main innovation in Spotlight is incremental searching, not waiting until pressing enter
s/onSubmit/onKeyPress/
Boy, what will those fellows at Cupertino think of next? I personally dislike things that search as I type - I know what I'm searchign for, and I can press "return" when I've typed it. Searching on the first few letters is just a waste of processing time, esp when I misspell something.
And from what I've read, it doesn't involve grep. It doesn't search filecontents, just metadata (which most of the OS X users I know don't even use). Windows Indexing Service, however, *does* search file contents, and was introduced in Windows 2000. You know, 5 years ago? Using that little NTFS thing that allows file metadata?
Apple may have put a fancy interface on it, but that's all of the innovating they did on this one. They have done some cool stuff, but Spotlight is not up there with the "most amazing".
Before you go to bed, "emerge -B yourpackageandoptions". That'll build a binary package, but not install it. Then, later on, just install the package (emerge -K yourpackage), which takes about the same time as any other package manager. If you choose reasonable cflags your binaries will work on your other machines, too.
:)
BTW, I used distcc over ssh to use distcc on some of the machines at work before I picked up a 2GHz machine at home. It worked pretty well.
Spotlight is "locate" with something like fam automatically updating a database when a file's name or metadata is changed. The gnu findutils have been on *nix systems- including OS X for a long time, and have been available under Win32 for as long. Windows also has had what's called "indexing service" since Win2K, and "Microsoft Fast Find" as part of Ms Office for a while. All of those things are file indxing systems like spotlight. All Apple did to "innovate" was to make the interface a little prettier and tie it in to Finder/Explorer/the file system API a little more tightly. It certainly doesn't "change everything", since I still plan to use locate from the terminal on OS X, like I've been doing since 10.2.
:)
Anyway, to get that functionality on your windows network, turn indexing service on - it's off by default. Then define some usage guidelines and distribute them to your users. The reason they can't all work together in a coherent way is that they don't have a coherent plan. Solving the problem with an index is not solving the problem, it's working around the problem.
Probably experience. I get a lot more probes than attacks on my Apache servers. Those probes are looking for a vulnrability, and don't take much time to run. Trying every attack on every web server does take time and bandwidth, and makes the kiddie a little more obvious target. At least a couple of them have thought of that by now...
The busy 4-way stops that I've seen generally include at least 2 people who think that all they have to do is stop, "waiting their turn" is a rather unnecesary component.
Why would you move anything? All you have to do is change the server string. Oh, and turn off logging, since your server logs will be filled up with IIS vulnurability attacks within minutes.
Why do people insist on making anything but democracy sound bad? We don't even live in a true democracy here in the US, but somehow that's the ultimate form of government. Other forms have good points, too, and the one we're using sure isn't working out all that well...
No, posts complaining about the "increased noise over the last X period of time" have been happening since the dawn of Slashdot. They're usually anonymous cowards, to hide that they've only had accounts with /. for a few months. "Moderated insightful" my butt.
I'm partial to just assuming that the wireless network is unsafe, and setting up VPN connections to get to anything outside of the wireless. I trust several of the VPN technologies "enough", wheras I just don't trust anything wireless. The earlier post mentioning "captive portals" is right on, IMHO.