I'm on my third Mac now, and every time I've bought one, I buy used -- they're half the price of a new one (granted, a used PC would tend to be 10% the price of a new one...) but they're still pretty damned good computers. I'm not ready to plunk down for a new one though until the much prophesied next generation machines come along. Articles like this make it sound like it could be just a year off (which is about what I heard a year ago, and a year before that...). Now you're saying that a two generation jump should be available in 18 months? Hell, that's just another disincentive for me to go out & buy a Mac.
To my half thought-through way of seeing things, this is a strong argument for coming up with a product roadmap, even if such things are half-truths in the end. Apple is so secretive about everything that it's impossible to know if something like this -- or something else entirely! -- is going to come out in a month or a year or ever, and consumers like me are perfectly willing to wait. And wait. And apparently, wait indefinitely. Clearing up some of that uncertainty would certainly make me more eager to buy new gear...
If you're so worked up about it, then pay attention to the prior art. At the time the Google project was underway at Stanford, a similar project called Clever was going on at IBM's Almaden research center doing similar analysis of link structure as part of a web search strategy.
Writeups on that project cite Google as a contemporary parallel project, and refer to earlier work in the same field that was drawn upon by both Google & Clever. It could be that the unique conception of the ideas as put in the Google filing are what made it patentable, but there was clearly similar work going on at the same time & earlier -- you don't even have to branch out to other fields of study.
(Sorry, I'd elaborate, provide URLs, etc -- but this is already in my journal and an earlier post, so repeating it again doesn't seem useful now:-)
A few months before I first learned about Google -- and I learned about Google when it was still a Stanford research project at google.stanford.edu -- there was an article in Scientific American about the "Clever Project" at the IBM Almaden Research Center. The basic idea was similar to PageRank -- analyze the link structure of the web in order to identify important sources of information. Quoting from that second URL:
A number of groups are also investigating the power of hyperlinks for searching the Web. Sergey Brin and Lawrence Page of Stanford University, for instance, have developed a search engine dubbed Google that implements a link-based ranking measure related to the influence weights of Pinski and Narin. The Stanford scientists base their approach on a model of a Web surfer who follows links and makes occasional haphazard jumps, arriving at certain places more frequently than others. Thus, Google finds a single type of universally important page--intuitively, locations that are heavily visited in a random traversal of the Web's link structure. In practice, for each Web page Google basically sums the scores of other locations pointing to it. So, when presented with a specific query, Google can respond by quickly retrieving all pages containing the search text and listing them according to their preordained ranks.
Google and Clever have two main differences. First, the former assigns initial rankings and retains them independently of any queries, whereas the latter assembles a different root set for each search term and then prioritizes those pages in the context of that particular query. Consequently, Google's approach enables faster response. Second, Google's basic philosophy is to look only in the forward direction, from link to link. In contrast, Clever also looks backward from an authoritative page to see what locations are pointing there. In this sense, Clever takes advantage of the sociological phenomenon that humans are innately motivated to create hublike content expressing their expertise on specific topics.
So there was similar (but not identical) work going on at the same time with Google & Clever, and there was earlier work going on with the work done by Pinski & Narin. I'm not sure what the exact terms of the Google patent are -- I haven't read it yet, sorry -- but if prior art is going to turn up it seems like this is a good place to start.
If you *ahem* Google for Clever, you'll find plenty of hits.
What can I say, it doesn't take much to reduce an already absurd slogan to more obvious absurdity:-)
My real point, which I think you're well aware of, is that pat, convenient slogans like this are often too simplistic, and there's a danger that by taking them to heart you're taking away the wrong lesson.
By broadening the definition, my hope is that people will think a little more about parroting things like this and consider that, in this case, security by obscurity *isn't* per se a bad thing. It has a place, a role, and proper ways to apply it. Having it as the first & only line of defence usually isn't one of the proper ways, but as part of a balanced security plan it can fit in very effectively.
Running diverse software on the roots is probably a Good Thing, but security through obscurity isn't
Man this is such a false meme, where did it get started? Obscurity by itself is questionable security, but as a component of a multi-layered security strategy it's perfectly reasonable.
Security by obscurity is your world-readable/etc/passwd file, with the password data either hashed (obscured) or moved to the shadow file (also obscured). (And if your shadow password file isn't world readable, that's just more obscurity.)
Security by obscurity is the fact that most people don't have the names & addresses of the personnel running the US military's nuclear weapons systems so that these people can't be blackmailed. Maybe these people can be trusted not to betray their country under torture and such, but keeping their identities non-public -- an obscurity measure -- is important too.
Security by obscurity is restricting access to your company's co-location facility, so that untrusted people can't get physical access to your equipment.
In short, in a broad sense, "security by obscurity" is a lot of good ideas, when you think about it. Any of these ideas can be an Achilles heel, but the solution there is not to cut off the heel altogether, but to wear sensible shoes when going out in the wilderness:)
To get back to the original topic, obscurity is a perfectly good tactic for the people running these DNS servers as part of their overall strategy for protecting the system. It's perfectly reasonable for certain aspects of their systems, processes, etc to be kept on a need to know basis. Sure, there is a benefit to keeping software source open as a security measure, though the benefit of doing that is debatable (and no, I'm not going to be the one to debate it -- I agree that it's generally a good idea but can understand some of the objections). But in this case, where the software is a black box to the outside world, and it's explicitly *not* meant for general DNS use (it's meant for authoritative servers only!) I don't see any particular harm in keeping their doors locked down pretty well.
Not that they're doing that in the first place. As another reply noted, you yourself write that both the betas & release will be available under a BSD style license:-)
But moreover, your objections are I think misplaced -- as are most of the people that blindly parrot the "obscurity is bad" meme. Think about what you're saying -- it really doesn't hold up to scrutiny.
It's all well & good to complain that spam is the organized crime of the internet, but it's another matter to actually use that rhetoric to get the gangsters thrown in jail or at least into a different line of work (as an aside, here's a scary thought: Dave Ralsky as a character in "The Sopranos" or "Godfather IV". yow!) How do we get there? At last month's Spam Conference, the impression I got was that no one strategy is by itself going to be enough to handle the spam problem:
Legislation won't be enough, because some people will just move their operations do different jurisdictions, while others will ignore the law (by analogy, bank robberies still happen even though they're not illegal, since that's where the money is)
Filtering won't be enough to save us, because spammers can keep evolving to avoid filters faster than filter writers can adapt
Blacklists are even worse than spam, since they always lead to false positives & deletion of legitimate mail
Network changes are unlikely to help, because many of the proposed ideas are disruptive than the spam problem itself
Etc.
(Subjectively, the spam I've received since the conference has gotten *much* more difficult to filter. In spite of the great tools I learned about that day, the tactics of the spammers have gotten more crafty. This is turning into an arms race, and one I'm not sure we can win. Are you concerned that things may have changed for the worse since the Conference, or on the whole did the "good guys" come out ahead?)
Given that, to steal Fred Brooks' line, "there is no silver bullet" to solve the spam problem, how do you propose that we handle it? It seems like there are grassroots efforts to prevent spam delivery (things like SpamAssassin, Paul Graham's statistical work, realtime blacklists), topdown efforts to control spam on a network (Brightmail, MessageLabs, etc) and lateral attacks on the legal & economic side of things (Jon Praed's lawsuits on AOL's behalf, Microsoft pledging to sue Hotmail spammers). These are all chipping away at the problem, but none of these people seemed to feel that their efforts alone would be enough to make spam go away.
The general consensus at the conference seemed to be that the only truly effective tactic would be to fundamentally disrupt the business model of spam: if you can make spam less profitable than say traditional junk mail, or stealing hubcaps, then you remove the incentive to take it up as a living. Do you agree with this? If so, then where are the thresholds at which spam becomes less profitable than hubcaps, and what tactics will bring us to that level most effectively?
In short, we all know what the problem is, and a lot of smart people have started to identify aspects of the problem. But are we making enough progress? If not, how can progress most effectively be made? Where are we falling behind? Has the Spam Conference been a turning point for the better, or do the spammers just have the rest of us on the run now? Can you please enumerate, in your opinion what seems to be working (if anything) and what seems to be falling short, and put this in context by describing which strategies (technology, legislation, etc) that you think will be most effective in the long run.
Thank you, and thanks for the Conference talk. It was very entertaining:-)
The term is commonly used in printers rather than display technlogy, but the concept applies just fine to displays -- do some math before complaining!:)
All it means is "dots per inch", and it's perfectly valid to find that ratio for a typical resolution (640x480 on the low end up to, what, 1920x1240 on the high end?) and screen size (14" for a small CRT, 12" for a small laptop LCD, up to maybe 23" for the biggest common screens today?).
For the low end, that works out to roughly 45dpi and on the high end 83dpi (approximately -- I'm dividing screen pixel width by screen diagonal inches, which isn't quite right, but it gets you in the ballpark anyway). Last time I checked, even the cheapest bubblejet printers could do 300dpi printing, and did half that at "low" resolution.
Even the best video technology available does barely a quarter of the rate cheap printers typically do -- nevermind high quality ones. The difference may not seem obvious, but it is very real, and all computer users are probably subconsciously aware of it, if not consciously -- this plays a big role in the perceived strain in reading large amounts of material off a monitor.
This reminds me of a recent entry of David Hyatt, the guy that is (among other things) current lead of Apple's Safari project and former lead of the Chimera Mozilla variant. He was mocking recent efforts in Mozilla to "improve the splash screen" because people didn't seem to like it very much. He didn't either -- which is why the browsers he has worked on are meant to start up so fast that you don't *need* a splash screen.
Put another way, here's another story. In the early days of the interstate highway system, there was a problem with the roadway signage where, because the signs didn't give people enough warning that an exit was coming up, drivers kept colliding with the signs, destroying them, while trying to veer off the highway at the last minute. When the project engineers were told about this, the solution they came up with was simple, elegant, and completely wrong: build a sign strong enough to withstand an impact from a car moving at highway speeds.
The lessons there should be obvious. Rather than identify what today might be called the usability problems of the signage system, they focused only on the sign device itself. Their solution didn't make the problem go away, and it probably made impacts with signs much more dangerous for people in the car. The right solution, which we have since moved to, is to come up with standards to give people more information ahead of the exits so that collisions like this are much less probably.
I think the Mozilla people are falling for the same trap. They've heard the complaints, but rather than take them to heart, they poke fun at it -- and in fact adding in code for this easter egg, even if you are downloading the xml from mozilla.org's servers, is only adding to the application's bloat. Like the splash screen example, this is itself a great sign *ahem* that the project developers aren't listening to the concerns of their users. Rather, it's just starting to seem like a colossal exercise in self-gratification.
I'm not sure if I'm on the wrong track here, but I definitely feel out of step with the other comments I've seen so far. It seems to me like your main problem isn't so much the software you're using as it is the display technology itself, yes?
This is a pretty well known & documented UI shortcoming with contemporary screens: between the fact that the typical monitor is backlit (thus, you're staring into a lightbulb the whole time -- and a flickering one at that) and the very low resolution compared to print (isn't typical resolution on the order of 72 dpi? that's worse than a cheap bubble-jet printer...), reading long texts off a CRT or LCD display isn't comfortable for most people. It's been written that this resolution issue is making computers a lot more uncomfortable for people than most folks realize, and that only with better screens (reflective instead of back-lit, and resolutions of say 1000dpi and higher) will reading electronic displays come to feel as comfortable as paper does for the average user.
I forget if I read about this in some of Jakob Nielsen's stuff, or Donald Norman, or maybe someone else, but in any case it's a matter that UI specialists are aware of. Last time I was reading about this -- a year or two ago now, maybe a little longer -- it was estimated that such technology is still a decade off, and I'm not sure how much progress has been made since then. Probably not much.
My favorite idea for dealing with this is the "electronic paper" being tested by groups like Xerox PARC and E-ink, where a sheet of this paper-like film has a matrix of particles that can, depending on the charge being applied to different parts of the matrix, arrange themselves to display arbitrary text or images. The idea is to figure out how to make a high quality version of this stuff that can be mass produced & sold for little more than traditional paper, so that a computer of the future might end up looking a lot like the books of the past, with the pages for the display and the computing components in the spine. That way you could have whole libraries in a portable format, textbooks (or Gutenberg texts:) could be downloaded & students would keep the same "book" from class to class, you could scribble notes on it for your own reference, or maybe even have it recognize what you're writing & use a stylus instead of a keyboard, etc. But aside from all the neat potential aspects of such a device, one of the explicit goals in trying to build it would be to end up with an electronic display format that is as comfortable & familiar as paper.
A case in point for this was the meta key on BeOS. Because the system was aimed at both Mac & Windows users, they wanted to accomodate the standard keystroke modifier for both of those systems.
So while on the Mac you get cut copy & paste from cmd+X, cmd+C, and cmd+V (where command is the Apple/cloverleaf key next to the space bar), on windows the equivalents are ctrl+X, ctrl+C, and ctrl+V (where control on a typical PC keyboard is at the outer corner of the keyboard). BeOS had a global setting so that you could choose which of these you'd go by as a modifier key, ctrl or cmd (or for the equivalent position on the PC keyboard, alt instead of cmd).
This one little configuration option was such a pain in the butt when reading system documentation or books like Scot Hacker's _The BeOS Bible_, because every time the author referred to one of these keystrokes (all the time), they'd have to put in the footnote about how for some users the keystroke would be "this", and for others it would be "that". One little option, and it doubled the amount of documentation that was necessary in certain sections of the reference material.
It's easy to imagine how things can fall apart when the number of configuration options starts to accumulate.
It's funny, my first instinct is that I want to be able to customize the system to my liking. When setting up a new Windows account, there is a laundry list of settings that I need to change before I can do anything else, and have done these several dozen adjustments so many times that I can almost do it by rote now. (On the other hand, when setting up a new *nix or OSX account, I can generally download a copy of my ~/.files, ~/Library, etc and be off in under five minutes, but the end result is the same -- I just get there a hell of a lot faster:-).
But stepping back a little, I don't like tweaking things *that* much. I only want to change so many of the settings on Windows because so many of the defaults are so mollycoddling & restrictive, but I don't actually want to replace major components like Explorer or the taskbar. Once you turn off all the hand-holding settings in the interface (and of course get Cygwin & Gvim installed:-) it's really not that bad.
Then you've ot OSX, which if you think about it is a *really* inflexible work environment, much less configurable than Windows by a long stretch. Don't like the menu bar? Tough noogies. Fink the Aqua esthetic boring after a while? Too bad. You have no control over these fundamental interface aspects. And yet, I like the way it's done, a lot. I've tried out things like haxies & Konfabulator, but I'm happy with the default interface setup. Even in areas where I find Aqua lacking (I miss OS9's windowshade trick, I miss X11's virtual desktops, I miss Window's tree/preview style file system browser), I don't miss them so much that I want to switch, or experiment with crude third party hacks. I'm willing to accept this straightjacket happily.
Compare that on the other hand to X11, Gnome, and KDE, where you have fine-grained control over *everything*. Modern setups are nice enough that you no longer have to spend a week trying to just get a working Xfree86 / $windowmanager setup up & running with your hardware, but you're still dumped into an endless maze of switches & knobs, all alike. You are likely to be eaten by a GNU:-)
As much as I appreciate the hard work into making the high quality KDE & Gnome suites, I think the Mac interface is a pretty strong example of how a single well thought out interface can trump an infinitely configurable one for a large fraction of users. If I'm anything like the typical user, then the typical user doesn't want to waste time coming up with just the right "mood" for the UI. Good enough will do -- I've got things I'd rather be thinking about, like the work I'm trying to get done with the computer.
The UI should be a mean, not an end, ya know? As far as I'm concerned, the more configurable / skinnable software is, the less likely that it was designed with this simple point in mind.
Ahh, I misunderstood. I thought that Ken Williams had a working Perl package that hadn't been officially adopted by the project, but I haven't really been keeping up with the mailing lists so I probably missed whatever negative side effects come up from his (or anyone else's) stab at the problem.
In any case, if Darwin is getting an upgrade to 5.8.0, then maybe Jaguar's successor (Panther, was it?) will as well, and the whole debate can become moot. Or at least, until 5.8.1 comes along...:-)
This is what Jesse Vincent has been using for RT: Request Tracker development for several months now, rather than CVS. Apparently it's much nicer than CVS, but it's exotic and not many people know about it or how to submit patches with it, so RT3 from what I can tell is kind of a one man project at the moment. In any case though, I've heard nothing but good things about Aegis, and it seems like a tool worth checking out if you have a software project to manage.
(And for that matter, if you need to track software bugs & other issues, RT rocks. Don't bother with Bugzilla, it's not half as good as RT is for most of the same tasks. And no, no one is paying me to endorse RT or anything, it's just great software and, in reference to Aegis, I respect the judgement of the guy developing it...)
But that isn't a valid comparison, since -- most obviously -- a whole lot of people -- many millions of them -- are Americans of Hispanic descent. You're suggesting that if someone is American, then they must not be Hispanic, but of course that's not true. If you'd said one American & one Mexican, that would have made a little more sense, but not much.
A slightly better analogy would be one Native American state, and another non-native (European, Hispanic, Asian, African, etc). That doesn't quite compare either, because in the case of Israel/Palestine, *both* groups have an ancient claim to the territory. But then, like in the USA, the more recent (from a certain point of view) ethnic group -- the Jews -- has become the dominant group, economically, militarily, and otherwise. You can't just tell them to go back to the ghettos in Europe or anything like that, just as it wouldn't do any good for America to be given "back" to the Native Americans. It's home now for all of us, native & non-native alike -- after a couple of generations, ancient tradition doesn't mean quite so much.
Not that I have any proposals for the situation, mind you. Like a mathematician [Paul Erdos?] once said, "I don't have an answer for your problem, but I appreciate the complexity of it."
Har har har. I just take the meal, not the uniform -- not least because if people that do tend to get at least as much harassment in situations like going through customs (hippies always seem to get searched) as any other particular group of people.
That and, as you suggest, the hippie uniform look really silly:)
Well yes, but that's the loophole isn't it? Not only is my meal going to be vegetarian, but it's also going to be kosher and [insert Arabic word for religiously acceptable here].
So if someone wants to avoid pork without giving away their religious background, asking for a vegetarian meal is the loophole they need -- which means that, if the feds want to learn something here, they have to assume that all people requesting non-pork meals, including vegetarian meals, need to be examined.
It's a distinction without a difference in this light.
Sorry if I was too subtle -- it was meant sarcastically against people that actually do think that way. (Hence the quotes around "known" -- I don't accept that idea at all.)
To be absolutely clear, I do not think that Muslims are by fact of their religion any more likely to do violent things than anyone else. If I gave a different impression, I apologize.
I was trying (and failing) to be apolitical there, but in fact the current situation in Israel & Palestine seems to me like pretty clear evidence that both of these particular groups can be extremely violent towards one another if they want to. And of course one doesn't have to dig hard at all to come up with a long list of dumb things that people & groups of people have violently done to each other in the past and again today.
But I was trying to keep close to the context of this article, which was asserting that if you know who on a plane is going to avoid pork then you somehow have a better idea of who is going to do something violent. I think that idea is more than a little questionable, and the comment that offended you was meant to hint at that in a subtle way. Too subtle, I guess.
They want to know who requested a meal without pork? As a vegetarian, that is going to include me. Does that make me a potential terrorist? They say Hitler was a vegetarian, so I guess that puts me under suspicion...:(
This is an interesting data point to want to collect, but how much does it really mean? Both Islam & Judaism shun pork, but only the former are "known" to be the bomber type. And if someone was going to do something, couldn't they take the generic meal & not eat it? (I know that personally I wouldn't want to have my last meal be a tray of warmed over airline food -- yuck.) Or if they really want to avoid suspicions, just not eat the part they find offensive? That seems best for someone that assumes thie meal choice is going to raise suspicions & wants to keep a low profile.
It seems to me that the meal choice is something that a person who is up to something would either [a] be too preoccupied to worry about, or [b] would think of & take a non-obvious choice (like the default meal, or a vegetarian meal) in order to avoid suspicions. Either way, the "bad guys" aren't going to do the obvious thing, and you end up with a crude form of racial profiling for thousands of honest people. How is that helpful?
The George Buh [sick] security doctrine: grasp at enough straws & throw out enough civil liberties and maybe, just maybe, you can trick the public into believing that these policies are going to do a whit of good. Remarkably, it seems to be working, if only domestically...
For philosophical reasons that I don't entirely agree with, the Fink developers have specifically *not* provided a Perl package in Fink. I just ran a "fink list perl" and this hasn't changed.
Basically, they don't want to replace anything that is already provided by the system, and since so much of OSX depends on having that 5.6.0 version of Perl, they refuse to put a sanctioned Fink version under theie/sw tree. Of course, this doesn't explain why there are Fink packages for Ruby (part of Jaguar), Python (part of Jaguar, also 10.1?), Apache (part of the Public Beta, if not even earlier), or Grep (older than dirt:-)...but not Perl.
There's a logic to it, I just don't quite agree with it. In any case, the important thing is that there is not a binary version of Perl available from the Fink project. The closest you're going to get is that, if you read the archives of the Fink-users mailing list, there has been non-official package descriptions that you can add to/sw/fink/dists/local/ in order to have your own custom Perl installed by the normal Fink tools. But this isn't & probably never will be something you can get directly from the Fink project itself -- you have to dig for it.
I've been wondering about that since the Spam Conference last month, where both an engineer from Microsoft Research and a representative from Brightmail spoke about how they're trying to filter spam from large networks such as Hotmail and MSN. The scenario you describe is a common perception -- the most obvious explanation for the way even unused, "funny looking" (not dictionary words, numbers, etc) Hotmail addresses get so much spam is that the company must be selling their subscription list to spammers. But if that were actually true, then why are they putting so much effort into filtering out spam at both the network & mail client levels?
A different idea that came up at the conference was what I'll describe as "bigger targets attract more arrows". That is, an ISP with millions of subscribers (Hotmail, Yahoo, AOL, Earthlink) is a more appealing target for things like dictionary attacks than, say, my personal DynDNS account with two legitimate users behind it.
If you're going to carry out a dictionary attack against a domain, diminishing returns will take over for the little one (one billion tries, two hits -- 2e9%), but for the big one you can expect a reasonable hit rate (one billion tries, 3 million hits -- 0.003% -- and in fact a reasonably big fraction of all users on the network).
In practice, this means today that the bigger the netwowrk, the greater the current spam volume, to the point that of the largest ISPs and corporate networks around today, something like 40% to 50% of their mail traffic is now spam.
I think this is a better explanation for what's going at Hotmail et al., and it also does a better job of why they want so badly to control the spam issue. The explanation they'll give to the public is that this is good customer service, and to an extent that's true. But at the same time, trying to handle all this network traffic is probably a technical nightmare (and comments about the migration from FreeBSD to Win2000 are not helpful here:). For a free service, having to handle that much unwanted traffic is probably killing them, and bringing it under control for that reason is probably at least as important as maintaining customer good will.
Sorry for the massive parroting, but I find this amusing:
All the widgets that come with it are useless to me.
The widgets that come with it are merely very simple examples! You can make a widget to do that task you've always wanted to do even if you have no programming knowledge. A widget that does about anything can be made with about a page of code.
OMG, the widgets are just eye candy that take up too much desk space!@ Plus, I have menu extras that do everything!@
1. Then make a widget that is whatever size YOU want it to be!
2. Make a widget that ISN'T eye candy (in your opinion), and displays the data however YOU want!
3. The widgets that come with Konfabulator are simple examples, to show the kinds of things that can be done, while also being visually pleasing.
4. The size issue has been discussed at length. The response seems to indicate the ability to actively scale any widget just didn't make it into 1.0. (I don't speak for the authors, but that was my interpretation.)
Konfabulator still isn't worth it to me...like I said, I have menu extras and docklings that do all this stuff!
If you can't see any purpose for Konfabulator, and can't think beyond applications you already have, and are stuck on the size of the default widgets, then you have utterly, totally missed the point of Konfabulator: to let people with very minimal programming language, i.e. almost anyone, make a small application that does whatever they want it to and looks however they want it to; the ability to actively obtain and display information by any scripted action, or to cause events to occur by any scripted action, all in the interface of your choosing.
The widget library is all clocks and newsreaders!@
Konfabulator has only been out for a week, and relatively few people know about it. There are already over 75 widgets. Yes, there are a lot of people who are just "skinning" the existing widgets, but this is the beginning. There are two people who can benefit from Konfabulator: those who are willing to write a little JavaScript, and those who are talented with artwork and graphics. There's nothing wrong with 20 beautiful clocks that people may want to choose from. Lots more widgets will continue to come.
[....]
This is bullshit! They're charging you $25 so that YOU have to go out and do the work of making widgets!!
Look, you can decide if this thing is worth $25 to you or not. They're not charging $25 for the default widgets; they're charging $25 for an easy-to-use and innovative programming/scripting framework. The default widgets are JUST EXAMPLES. Also, we'd better warn Metrowerks to stop charging for CodeWarrior, after all, CodeWarrior is useless unless you actually make an application with it!
Gee, does anyone else get the impression that the quality (or lack thereof) of the default widgets is kind of a sore spot?
If these things are such bad examples of what Konfabulator is supposed to be able to do -- and based on shreiking, panicked self-defence like this it must really be getting to these guys -- then why are the default widgets being distributed at all?
I admit, I tried Konfab. over the weekend, though "oh okay, this is annoying skin candy -- just like Kaleidoscope & Enlightenment & every damn MP3 player that isn't iTunes -- and trashed it after about 15 minutes. Friends tried to convince me that the framework is the interesting part, and I'm willing to accept that that may be so. But these default widgets are fucking annoying, and as far as I can tell the licensing scheme -- $25 for the framework, and you have to agree to distribute any widgets you make for free -- seems to guarantee that future widgets aren't going to be a whole lot better. (If the shareware ethic is to make something that a few people would want to pay five bucks for, and you can't do that, then the model falls apart, doesn't it? I'm not sure, I have a better feel for how Free software economics works, this shareware stuff still seems funny to me:).
I dunno. Konfab. might be a great framework, but the crappiness of the widgets I've seen so far -- and the way these things are so far outside the normal interface conventions -- makes me very unenthusiastic about this. I'd be happy to be corrected, but so far I just don't see it. *shrug*
Re:EE Times weighs in, without the sensationalism
on
WiFi Woes With .11g
·
· Score: 1
...slow to 11.
You say that like it's a bad thing. I used to have a Marshall stack that slowed to 11, but the doctors told me not use it anymore.
Am I the only one that has all of the mailing lists I subscribe to bypass SpamAssassin?
I was going to do this, except that at least one of the lists I'm on -- as it happens, the one I'm most interested in reading -- itself tends to get spam every now and then. As long as lists have open membership rules -- and in general I think that's the right policy -- then spammers will be able to sign up to deliver unwanted messages. Hence, SpamAssassin has to scan that mail as well.
As it happens, the only list that I exclude from SA is a Craigslist classified ads list, since a lot of the legit mail from it is actually people making TRULY GREAT OFFERS with INCREDIBLE DEALS and WHOLE LINES OF SHOUTING about things that I SIMPLY CANNOT MISS! As annoyingly over the tp some of these postings are, as a whole it is actually mail that I want to receive, so I don't want SA to flag it as spam. And because Craigslist's software sets the From header to that of the person sending out the posting, as opposed to nobody@craigslist.org like they used to, it was easier to just exclude CL mail from SA filtering than trying to come up with a whitelist rule based on CL's mail servers.
I've just checked the headers for this month's Cryptogram, and the current version of SpamAssassin (2.44) did not flag it as spam. To wit (slightly reformatted because of Slashdot's "this Nerd site will not accept technical postings thankyouverymuch" comment filter):
If only. I do this every time I get a telemarketing call, and it's only partially effective. The standard line I give it something like "where did you get my number? please have this number removed both from your list and from the list of whoever gave my number to you." The first one they have to comply with, the second is kind of a gamble but if they can do it then great.
If the poor shmoe making the call gives me a hard time about taking my number off their list, I immediately switch to "may I please speak to your manager" and that usually gets them to either cooperate or, if they actually put the manager on the line, that person cooperates. Every now and then they've hung up on me for asking questions like this (they get paid by the number of calls made, so wasting time with an uppity customer that wants off the list is doubleplus ungood), but the company always seems to call back a day or two later and the second caller always seems to be more reasonable than the first one.
When asking to be taken off the list, they invariably say that getting off the list "may take four to six weeks", which seems like total bullshit to me -- as others have noted, they legally have 30 days and I'm sure that is the constraint they go by, not any technical or procedural reason they can't get you off the list sooner. But whatever, I can deal with that -- like I say, I consistently do this with telemarketers, and it does consistently help.
But it hasn't eliminated the problem. Not by a long shot. I dropped down from multiple calls per day to less than one a week (and almost none during the evening, which is nice) but they still keep coming through.
It's like email spam. I think at this point "best practices" suggest that you should filter incoming mail with something like SpamAssassin, and you should report obvious UCE spam to Spamcop.net, and doing these does make the problem less annoying. But it doesn't, and never will, eliminate it. Legislation will help, but it won't eliminate it either -- people can just go offshore, or find loopholes, or whatever. But it'll help.
In the end though, the only way to really stop it is to disrupt the economics enough to make telemarketing & spam untenable. If you & your neighbors can all waste their time on the phone then they won't be able to make as many calls per hour, and if they can't make as many calls per hour then they have to work harder to make a profit, and if we can make them have to work hard enough then it won't be worthwhile to engage in telemarketing. If you & your neighbors can all waste the spammers time by filtering out the bulk (forcing them to test their spam against all the major filters to make sure things work, driving up their costs in the process) and if you can make sure that most of it is never seen and if you can get their ISP to give them a hard time, then it won't be worthwhile to engage in spamming.
Filters & do not call lists & legislation won't by themselves end the telemarketing & spam problems, but cumulatively they can work to bring it under control, make it unprofitable, and hopefully convince these people to find some other way to make a living. Like selling popup ads...:)
Slashdot Mirror
To my half thought-through way of seeing things, this is a strong argument for coming up with a product roadmap, even if such things are half-truths in the end. Apple is so secretive about everything that it's impossible to know if something like this -- or something else entirely! -- is going to come out in a month or a year or ever, and consumers like me are perfectly willing to wait. And wait. And apparently, wait indefinitely. Clearing up some of that uncertainty would certainly make me more eager to buy new gear...
</wibbling>
Writeups on that project cite Google as a contemporary parallel project, and refer to earlier work in the same field that was drawn upon by both Google & Clever. It could be that the unique conception of the ideas as put in the Google filing are what made it patentable, but there was clearly similar work going on at the same time & earlier -- you don't even have to branch out to other fields of study.
(Sorry, I'd elaborate, provide URLs, etc -- but this is already in my journal and an earlier post, so repeating it again doesn't seem useful now :-)
So there was similar (but not identical) work going on at the same time with Google & Clever, and there was earlier work going on with the work done by Pinski & Narin. I'm not sure what the exact terms of the Google patent are -- I haven't read it yet, sorry -- but if prior art is going to turn up it seems like this is a good place to start.
If you *ahem* Google for Clever, you'll find plenty of hits.
My real point, which I think you're well aware of, is that pat, convenient slogans like this are often too simplistic, and there's a danger that by taking them to heart you're taking away the wrong lesson.
By broadening the definition, my hope is that people will think a little more about parroting things like this and consider that, in this case, security by obscurity *isn't* per se a bad thing. It has a place, a role, and proper ways to apply it. Having it as the first & only line of defence usually isn't one of the proper ways, but as part of a balanced security plan it can fit in very effectively.
Man this is such a false meme, where did it get started? Obscurity by itself is questionable security, but as a component of a multi-layered security strategy it's perfectly reasonable.
Security by obscurity is your world-readable /etc/passwd file, with the password data either hashed (obscured) or moved to the shadow file (also obscured). (And if your shadow password file isn't world readable, that's just more obscurity.)
Security by obscurity is the fact that most people don't have the names & addresses of the personnel running the US military's nuclear weapons systems so that these people can't be blackmailed. Maybe these people can be trusted not to betray their country under torture and such, but keeping their identities non-public -- an obscurity measure -- is important too.
Security by obscurity is Dick Cheney's "undisclosed location" (*cough* Greenbrier Resort, White Sulphur Springs, West Virginia)
Security by obscurity is restricting access to your company's co-location facility, so that untrusted people can't get physical access to your equipment.
In short, in a broad sense, "security by obscurity" is a lot of good ideas, when you think about it. Any of these ideas can be an Achilles heel, but the solution there is not to cut off the heel altogether, but to wear sensible shoes when going out in the wilderness :)
To get back to the original topic, obscurity is a perfectly good tactic for the people running these DNS servers as part of their overall strategy for protecting the system. It's perfectly reasonable for certain aspects of their systems, processes, etc to be kept on a need to know basis. Sure, there is a benefit to keeping software source open as a security measure, though the benefit of doing that is debatable (and no, I'm not going to be the one to debate it -- I agree that it's generally a good idea but can understand some of the objections). But in this case, where the software is a black box to the outside world, and it's explicitly *not* meant for general DNS use (it's meant for authoritative servers only!) I don't see any particular harm in keeping their doors locked down pretty well.
Not that they're doing that in the first place. As another reply noted, you yourself write that both the betas & release will be available under a BSD style license :-)
But moreover, your objections are I think misplaced -- as are most of the people that blindly parrot the "obscurity is bad" meme. Think about what you're saying -- it really doesn't hold up to scrutiny.
It's all well & good to complain that spam is the organized crime of the internet, but it's another matter to actually use that rhetoric to get the gangsters thrown in jail or at least into a different line of work (as an aside, here's a scary thought: Dave Ralsky as a character in "The Sopranos" or "Godfather IV". yow!) How do we get there? At last month's Spam Conference, the impression I got was that no one strategy is by itself going to be enough to handle the spam problem:
- Legislation won't be enough, because some people will just move their operations do different jurisdictions, while others will ignore the law (by analogy, bank robberies still happen even though they're not illegal, since that's where the money is)
- Filtering won't be enough to save us, because spammers can keep evolving to avoid filters faster than filter writers can adapt
- Blacklists are even worse than spam, since they always lead to false positives & deletion of legitimate mail
- Network changes are unlikely to help, because many of the proposed ideas are disruptive than the spam problem itself
Etc.(Subjectively, the spam I've received since the conference has gotten *much* more difficult to filter. In spite of the great tools I learned about that day, the tactics of the spammers have gotten more crafty. This is turning into an arms race, and one I'm not sure we can win. Are you concerned that things may have changed for the worse since the Conference, or on the whole did the "good guys" come out ahead?)
Given that, to steal Fred Brooks' line, "there is no silver bullet" to solve the spam problem, how do you propose that we handle it? It seems like there are grassroots efforts to prevent spam delivery (things like SpamAssassin, Paul Graham's statistical work, realtime blacklists), topdown efforts to control spam on a network (Brightmail, MessageLabs, etc) and lateral attacks on the legal & economic side of things (Jon Praed's lawsuits on AOL's behalf, Microsoft pledging to sue Hotmail spammers). These are all chipping away at the problem, but none of these people seemed to feel that their efforts alone would be enough to make spam go away.
The general consensus at the conference seemed to be that the only truly effective tactic would be to fundamentally disrupt the business model of spam: if you can make spam less profitable than say traditional junk mail, or stealing hubcaps, then you remove the incentive to take it up as a living. Do you agree with this? If so, then where are the thresholds at which spam becomes less profitable than hubcaps, and what tactics will bring us to that level most effectively?
In short, we all know what the problem is, and a lot of smart people have started to identify aspects of the problem. But are we making enough progress? If not, how can progress most effectively be made? Where are we falling behind? Has the Spam Conference been a turning point for the better, or do the spammers just have the rest of us on the run now? Can you please enumerate, in your opinion what seems to be working (if anything) and what seems to be falling short, and put this in context by describing which strategies (technology, legislation, etc) that you think will be most effective in the long run.
Thank you, and thanks for the Conference talk. It was very entertaining :-)
All it means is "dots per inch", and it's perfectly valid to find that ratio for a typical resolution (640x480 on the low end up to, what, 1920x1240 on the high end?) and screen size (14" for a small CRT, 12" for a small laptop LCD, up to maybe 23" for the biggest common screens today?).
For the low end, that works out to roughly 45dpi and on the high end 83dpi (approximately -- I'm dividing screen pixel width by screen diagonal inches, which isn't quite right, but it gets you in the ballpark anyway). Last time I checked, even the cheapest bubblejet printers could do 300dpi printing, and did half that at "low" resolution.
Even the best video technology available does barely a quarter of the rate cheap printers typically do -- nevermind high quality ones. The difference may not seem obvious, but it is very real, and all computer users are probably subconsciously aware of it, if not consciously -- this plays a big role in the perceived strain in reading large amounts of material off a monitor.
Put another way, here's another story. In the early days of the interstate highway system, there was a problem with the roadway signage where, because the signs didn't give people enough warning that an exit was coming up, drivers kept colliding with the signs, destroying them, while trying to veer off the highway at the last minute. When the project engineers were told about this, the solution they came up with was simple, elegant, and completely wrong: build a sign strong enough to withstand an impact from a car moving at highway speeds.
The lessons there should be obvious. Rather than identify what today might be called the usability problems of the signage system, they focused only on the sign device itself. Their solution didn't make the problem go away, and it probably made impacts with signs much more dangerous for people in the car. The right solution, which we have since moved to, is to come up with standards to give people more information ahead of the exits so that collisions like this are much less probably.
I think the Mozilla people are falling for the same trap. They've heard the complaints, but rather than take them to heart, they poke fun at it -- and in fact adding in code for this easter egg, even if you are downloading the xml from mozilla.org's servers, is only adding to the application's bloat. Like the splash screen example, this is itself a great sign *ahem* that the project developers aren't listening to the concerns of their users. Rather, it's just starting to seem like a colossal exercise in self-gratification.
Good thing I can use Safari :-)
This is a pretty well known & documented UI shortcoming with contemporary screens: between the fact that the typical monitor is backlit (thus, you're staring into a lightbulb the whole time -- and a flickering one at that) and the very low resolution compared to print (isn't typical resolution on the order of 72 dpi? that's worse than a cheap bubble-jet printer...), reading long texts off a CRT or LCD display isn't comfortable for most people. It's been written that this resolution issue is making computers a lot more uncomfortable for people than most folks realize, and that only with better screens (reflective instead of back-lit, and resolutions of say 1000dpi and higher) will reading electronic displays come to feel as comfortable as paper does for the average user.
I forget if I read about this in some of Jakob Nielsen's stuff, or Donald Norman, or maybe someone else, but in any case it's a matter that UI specialists are aware of. Last time I was reading about this -- a year or two ago now, maybe a little longer -- it was estimated that such technology is still a decade off, and I'm not sure how much progress has been made since then. Probably not much.
My favorite idea for dealing with this is the "electronic paper" being tested by groups like Xerox PARC and E-ink, where a sheet of this paper-like film has a matrix of particles that can, depending on the charge being applied to different parts of the matrix, arrange themselves to display arbitrary text or images. The idea is to figure out how to make a high quality version of this stuff that can be mass produced & sold for little more than traditional paper, so that a computer of the future might end up looking a lot like the books of the past, with the pages for the display and the computing components in the spine. That way you could have whole libraries in a portable format, textbooks (or Gutenberg texts :) could be downloaded & students would keep the same "book" from class to class, you could scribble notes on it for your own reference, or maybe even have it recognize what you're writing & use a stylus instead of a keyboard, etc. But aside from all the neat potential aspects of such a device, one of the explicit goals in trying to build it would be to end up with an electronic display format that is as comfortable & familiar as paper.
So while on the Mac you get cut copy & paste from cmd+X, cmd+C, and cmd+V (where command is the Apple/cloverleaf key next to the space bar), on windows the equivalents are ctrl+X, ctrl+C, and ctrl+V (where control on a typical PC keyboard is at the outer corner of the keyboard). BeOS had a global setting so that you could choose which of these you'd go by as a modifier key, ctrl or cmd (or for the equivalent position on the PC keyboard, alt instead of cmd).
This one little configuration option was such a pain in the butt when reading system documentation or books like Scot Hacker's _The BeOS Bible_, because every time the author referred to one of these keystrokes (all the time), they'd have to put in the footnote about how for some users the keystroke would be "this", and for others it would be "that". One little option, and it doubled the amount of documentation that was necessary in certain sections of the reference material.
It's easy to imagine how things can fall apart when the number of configuration options starts to accumulate.
But stepping back a little, I don't like tweaking things *that* much. I only want to change so many of the settings on Windows because so many of the defaults are so mollycoddling & restrictive, but I don't actually want to replace major components like Explorer or the taskbar. Once you turn off all the hand-holding settings in the interface (and of course get Cygwin & Gvim installed :-) it's really not that bad.
Then you've ot OSX, which if you think about it is a *really* inflexible work environment, much less configurable than Windows by a long stretch. Don't like the menu bar? Tough noogies. Fink the Aqua esthetic boring after a while? Too bad. You have no control over these fundamental interface aspects. And yet, I like the way it's done, a lot. I've tried out things like haxies & Konfabulator, but I'm happy with the default interface setup. Even in areas where I find Aqua lacking (I miss OS9's windowshade trick, I miss X11's virtual desktops, I miss Window's tree/preview style file system browser), I don't miss them so much that I want to switch, or experiment with crude third party hacks. I'm willing to accept this straightjacket happily.
Compare that on the other hand to X11, Gnome, and KDE, where you have fine-grained control over *everything*. Modern setups are nice enough that you no longer have to spend a week trying to just get a working Xfree86 / $windowmanager setup up & running with your hardware, but you're still dumped into an endless maze of switches & knobs, all alike. You are likely to be eaten by a GNU :-)
As much as I appreciate the hard work into making the high quality KDE & Gnome suites, I think the Mac interface is a pretty strong example of how a single well thought out interface can trump an infinitely configurable one for a large fraction of users. If I'm anything like the typical user, then the typical user doesn't want to waste time coming up with just the right "mood" for the UI. Good enough will do -- I've got things I'd rather be thinking about, like the work I'm trying to get done with the computer.
The UI should be a mean, not an end, ya know? As far as I'm concerned, the more configurable / skinnable software is, the less likely that it was designed with this simple point in mind.
In any case, if Darwin is getting an upgrade to 5.8.0, then maybe Jaguar's successor (Panther, was it?) will as well, and the whole debate can become moot. Or at least, until 5.8.1 comes along... :-)
(And for that matter, if you need to track software bugs & other issues, RT rocks. Don't bother with Bugzilla, it's not half as good as RT is for most of the same tasks. And no, no one is paying me to endorse RT or anything, it's just great software and, in reference to Aegis, I respect the judgement of the guy developing it...)
A slightly better analogy would be one Native American state, and another non-native (European, Hispanic, Asian, African, etc). That doesn't quite compare either, because in the case of Israel/Palestine, *both* groups have an ancient claim to the territory. But then, like in the USA, the more recent (from a certain point of view) ethnic group -- the Jews -- has become the dominant group, economically, militarily, and otherwise. You can't just tell them to go back to the ghettos in Europe or anything like that, just as it wouldn't do any good for America to be given "back" to the Native Americans. It's home now for all of us, native & non-native alike -- after a couple of generations, ancient tradition doesn't mean quite so much.
Not that I have any proposals for the situation, mind you. Like a mathematician [Paul Erdos?] once said, "I don't have an answer for your problem, but I appreciate the complexity of it."
That and, as you suggest, the hippie uniform look really silly :)
But thanks for the vitriol!
So if someone wants to avoid pork without giving away their religious background, asking for a vegetarian meal is the loophole they need -- which means that, if the feds want to learn something here, they have to assume that all people requesting non-pork meals, including vegetarian meals, need to be examined.
It's a distinction without a difference in this light.
To be absolutely clear, I do not think that Muslims are by fact of their religion any more likely to do violent things than anyone else. If I gave a different impression, I apologize.
I was trying (and failing) to be apolitical there, but in fact the current situation in Israel & Palestine seems to me like pretty clear evidence that both of these particular groups can be extremely violent towards one another if they want to. And of course one doesn't have to dig hard at all to come up with a long list of dumb things that people & groups of people have violently done to each other in the past and again today.
But I was trying to keep close to the context of this article, which was asserting that if you know who on a plane is going to avoid pork then you somehow have a better idea of who is going to do something violent. I think that idea is more than a little questionable, and the comment that offended you was meant to hint at that in a subtle way. Too subtle, I guess.
This is an interesting data point to want to collect, but how much does it really mean? Both Islam & Judaism shun pork, but only the former are "known" to be the bomber type. And if someone was going to do something, couldn't they take the generic meal & not eat it? (I know that personally I wouldn't want to have my last meal be a tray of warmed over airline food -- yuck.) Or if they really want to avoid suspicions, just not eat the part they find offensive? That seems best for someone that assumes thie meal choice is going to raise suspicions & wants to keep a low profile.
It seems to me that the meal choice is something that a person who is up to something would either [a] be too preoccupied to worry about, or [b] would think of & take a non-obvious choice (like the default meal, or a vegetarian meal) in order to avoid suspicions. Either way, the "bad guys" aren't going to do the obvious thing, and you end up with a crude form of racial profiling for thousands of honest people. How is that helpful?
The George Buh [sick] security doctrine: grasp at enough straws & throw out enough civil liberties and maybe, just maybe, you can trick the public into believing that these policies are going to do a whit of good. Remarkably, it seems to be working, if only domestically...
Basically, they don't want to replace anything that is already provided by the system, and since so much of OSX depends on having that 5.6.0 version of Perl, they refuse to put a sanctioned Fink version under theie /sw tree. Of course, this doesn't explain why there are Fink packages for Ruby (part of Jaguar), Python (part of Jaguar, also 10.1?), Apache (part of the Public Beta, if not even earlier), or Grep (older than dirt :-) ...but not Perl.
There's a logic to it, I just don't quite agree with it. In any case, the important thing is that there is not a binary version of Perl available from the Fink project. The closest you're going to get is that, if you read the archives of the Fink-users mailing list, there has been non-official package descriptions that you can add to /sw/fink/dists/local/ in order to have your own custom Perl installed by the normal Fink tools. But this isn't & probably never will be something you can get directly from the Fink project itself -- you have to dig for it.
A different idea that came up at the conference was what I'll describe as "bigger targets attract more arrows". That is, an ISP with millions of subscribers (Hotmail, Yahoo, AOL, Earthlink) is a more appealing target for things like dictionary attacks than, say, my personal DynDNS account with two legitimate users behind it.
If you're going to carry out a dictionary attack against a domain, diminishing returns will take over for the little one (one billion tries, two hits -- 2e9%), but for the big one you can expect a reasonable hit rate (one billion tries, 3 million hits -- 0.003% -- and in fact a reasonably big fraction of all users on the network).
In practice, this means today that the bigger the netwowrk, the greater the current spam volume, to the point that of the largest ISPs and corporate networks around today, something like 40% to 50% of their mail traffic is now spam.
I think this is a better explanation for what's going at Hotmail et al., and it also does a better job of why they want so badly to control the spam issue. The explanation they'll give to the public is that this is good customer service, and to an extent that's true. But at the same time, trying to handle all this network traffic is probably a technical nightmare (and comments about the migration from FreeBSD to Win2000 are not helpful here :). For a free service, having to handle that much unwanted traffic is probably killing them, and bringing it under control for that reason is probably at least as important as maintaining customer good will.
Gee, does anyone else get the impression that the quality (or lack thereof) of the default widgets is kind of a sore spot?
If these things are such bad examples of what Konfabulator is supposed to be able to do -- and based on shreiking, panicked self-defence like this it must really be getting to these guys -- then why are the default widgets being distributed at all?
I admit, I tried Konfab. over the weekend, though "oh okay, this is annoying skin candy -- just like Kaleidoscope & Enlightenment & every damn MP3 player that isn't iTunes -- and trashed it after about 15 minutes. Friends tried to convince me that the framework is the interesting part, and I'm willing to accept that that may be so. But these default widgets are fucking annoying, and as far as I can tell the licensing scheme -- $25 for the framework, and you have to agree to distribute any widgets you make for free -- seems to guarantee that future widgets aren't going to be a whole lot better. (If the shareware ethic is to make something that a few people would want to pay five bucks for, and you can't do that, then the model falls apart, doesn't it? I'm not sure, I have a better feel for how Free software economics works, this shareware stuff still seems funny to me :).
I dunno. Konfab. might be a great framework, but the crappiness of the widgets I've seen so far -- and the way these things are so far outside the normal interface conventions -- makes me very unenthusiastic about this. I'd be happy to be corrected, but so far I just don't see it. *shrug*
You say that like it's a bad thing. I used to have a Marshall stack that slowed to 11, but the doctors told me not use it anymore.
What? Endangered species? Oh. Nevermind...
:-)
Sorry...
I was going to do this, except that at least one of the lists I'm on -- as it happens, the one I'm most interested in reading -- itself tends to get spam every now and then. As long as lists have open membership rules -- and in general I think that's the right policy -- then spammers will be able to sign up to deliver unwanted messages. Hence, SpamAssassin has to scan that mail as well.
As it happens, the only list that I exclude from SA is a Craigslist classified ads list, since a lot of the legit mail from it is actually people making TRULY GREAT OFFERS with INCREDIBLE DEALS and WHOLE LINES OF SHOUTING about things that I SIMPLY CANNOT MISS! As annoyingly over the tp some of these postings are, as a whole it is actually mail that I want to receive, so I don't want SA to flag it as spam. And because Craigslist's software sets the From header to that of the person sending out the posting, as opposed to nobody@craigslist.org like they used to, it was easier to just exclude CL mail from SA filtering than trying to come up with a whitelist rule based on CL's mail servers.
C'est la guerre :-)
Note that SpamAssassin isn't on my whitelist or anything like that -- it just worked.
False alarm?
If the poor shmoe making the call gives me a hard time about taking my number off their list, I immediately switch to "may I please speak to your manager" and that usually gets them to either cooperate or, if they actually put the manager on the line, that person cooperates. Every now and then they've hung up on me for asking questions like this (they get paid by the number of calls made, so wasting time with an uppity customer that wants off the list is doubleplus ungood), but the company always seems to call back a day or two later and the second caller always seems to be more reasonable than the first one.
When asking to be taken off the list, they invariably say that getting off the list "may take four to six weeks", which seems like total bullshit to me -- as others have noted, they legally have 30 days and I'm sure that is the constraint they go by, not any technical or procedural reason they can't get you off the list sooner. But whatever, I can deal with that -- like I say, I consistently do this with telemarketers, and it does consistently help.
But it hasn't eliminated the problem. Not by a long shot. I dropped down from multiple calls per day to less than one a week (and almost none during the evening, which is nice) but they still keep coming through.
It's like email spam. I think at this point "best practices" suggest that you should filter incoming mail with something like SpamAssassin, and you should report obvious UCE spam to Spamcop.net, and doing these does make the problem less annoying. But it doesn't, and never will, eliminate it. Legislation will help, but it won't eliminate it either -- people can just go offshore, or find loopholes, or whatever. But it'll help.
In the end though, the only way to really stop it is to disrupt the economics enough to make telemarketing & spam untenable. If you & your neighbors can all waste their time on the phone then they won't be able to make as many calls per hour, and if they can't make as many calls per hour then they have to work harder to make a profit, and if we can make them have to work hard enough then it won't be worthwhile to engage in telemarketing. If you & your neighbors can all waste the spammers time by filtering out the bulk (forcing them to test their spam against all the major filters to make sure things work, driving up their costs in the process) and if you can make sure that most of it is never seen and if you can get their ISP to give them a hard time, then it won't be worthwhile to engage in spamming.
Filters & do not call lists & legislation won't by themselves end the telemarketing & spam problems, but cumulatively they can work to bring it under control, make it unprofitable, and hopefully convince these people to find some other way to make a living. Like selling popup ads... :)