A new XML could make all close tags "</", since the name of the element you're closing is predetermined and there's nothing permitted after a slash other than a >. The > could be dropped from empty tags, too.
You could go a little bit further. Attributes are syntactic sugar for nested tags. The difference between <A FOO="BAR"/> and <A><FOO>BAR</></> is primarily aesthetic rather than semantic. So (as many people have done in practice) you can replace attributes with nesting. This also lets you eliminate the needless = mark, and even eliminate "" when you're referring to a known symbol rather than an actually arbitrary string.
Then, since you've earlier eliminated distinct close tags for different open tags, instead of making the close tag </ you make the open tag simply not have the final >... use that for the close tag instead. So for what started as <A FOO="BAR"/> ends up as <A <FOO BAR>>.
Now, angle brackets are kind of ugly. It would be more aesthetically pleasing to use something a little more rounded, something that has a history in mathematics of meaning "nested syntax for evaluation". Like, say, parentheses.
So you end up with (A (FOO BAR)). Conveniently enough, this is also a syntax for which highly efficient parsers have existed since... oh, 1960 or so. There are, today, two major common schemes for evaluating trees like this as code, and three or so different standards for expressing syntax-to-syntax transformations on trees like this -- kind of like XSLT, but actually efficient.
I try to avoid relying on a product which has a single supplier or is not standards-compliant, even if it does meet the FSF's standards.
Standards compliance is a great thing. Recently I've been working on a VoIP deployment using SIP phones, Asterisk, and SER. One of the things that has impressed us the most about SIP telephony -- as contrasted with earlier VoIP and digital office phone systems -- is that the major vendors' products all interoperate at a basic level (placing and receiving calls) out of the box. This is a big contrast with earlier systems where (e.g.) Nortel sold you a Succession VoIP system, and nobody else's phones would work on it.
Most of these SIP phones are not open-source. Cisco's and Grandstream's phones are the usual binary-only deal -- compliant with open standards, but not even source-available. However, some SIP phones are open-source, notably SNOM phones, which run embedded Linux, and for which you can download an SDK from their Web site and build your own firmware image. Not too terribly surprisingly, SNOM's phones are not the slickest in appearance (that would be Cisco) or the cheapest (Grandstream) but they are, as far as we can tell, the most configurable.
Much the same seems to be true of VoIP gateway systems. Many people with whom I've spoken are using Cisco instruments as their gateway between SIP and the PSTN (conventional phone system). We are using Asterisk. Although it is hardly the easiest software to configure -- it's kind of like the Sendmail of VoIP, minus the security hell -- the Asterisk/Zaptel/Linux system is far more flexible than closed equivalents.
So what does this have to do with the advantages of open source? In a field of open standards, such as SIP telephony, open source can really shine. Open standards mean that there is little space for vendor lock-in, so vendors cannot exclude open source in the usual fashion. Open source is largely immune to the problem of treating standards as "tick-list features", which some appliance developers seem to suffer from: implementing the standard in a slapdash way so that you can mention it in the four-color glossies. ("Do we have, um, this 'SIP' thing?" "Uh... [type type]... sure, we do now!")
So how does this contrast with some of open source's notable weaker points, like user interface and graphics software mentioned in the article? It seems to me that open standards and open source both have their strengths in infrastructure as opposed to interface: not the buttons that users push on their desktops, but the underlying systemry that really makes the system (and the network) run. The advantage of Asterisk over proprietary PSTN gateways is much more than the advantage (if any!) of SNOM over Cisco SIP phones. The same is true in other infrastructural roles: the advantage of Apache over Microsoft IIS is much more than the advantage (if any!) of KDE over, say, the Mac OS X interface.
For the user of closed-source end-user systems (be they phones or desktop computers) the presence of open source in the infrastructure means that it can be customized by experts (IT staff or consultants) to the needs of the organization. It also often means that the infrastructure is simply higher-quality, which benefits everyone. The folks who get VoIP phones on their desks at my workplace don't care whether the gateway is Asterisk or Cisco, but they do care if we can implement features they request. Likewise, our Web designers using Dreamweaver benefit more from the fact that we use Apache (since their work is safer than it would be with IIS) than they would by using an open-source end-user tool.
To make a tangent, consider Microsoft. Their tradit
Let them move. Let them live in paranoid armed compounds in "small poor nations" and fear that the locals will dig up their phone lines for the copper. Let them hide in places where the corrupt telecoms monopoly has run Internet access so badly that their IP addresses are already widely blocked for spam and abuse. Let them eventually get lined up by a tin-pot dictator and executed at dawn by firing squad, since they want to live beyond the rule of law. (After all, we can always block 'em -- I understand getting an email out of Nigeria is pretty tricky these days.)
Currently, the bulk of the big spammers live and operate within the United States. They may host their Web sites in China, buy lists of open proxies from Romania, and commission viruses from Russian Mafia programmers -- but they live in the "comfort" of the U.S. whose laws they flout.
They do not want to move overseas. They want the comforts of home -- to make millions without leaving the couch. They are small-minded, hurtful, nasty little people. They want the world delivered to their door, and are willing to steal and destroy to get it -- but only if they can do that stealing and destroying from behind a screen. They are not brave. When they are challenged, they retreat into paranoia and lash out with lawsuits based on conspiracy theories. Can't do that from East Bumfuckistan.
How do you return an anonymous function from a function in Python?
You don't use lambda. You define a function (with def) under a temporary name and return it. The temporary name is local to the enclosing function, so it doesn't pollute the namespace: Python def differs in this regard from CL defun.
But seriously, Common Lisp is the Common Lisp for the 21st century. It's doing quite nicely; in the past couple of years folks have taken this "old" programming language and added excellent support for all kinds of current needs -- a Web application server (TBNL), a remarkable SQL interface (CL-SQL), general-purpose dataflow programming (Kenny Tilton's Cells), PDF typesetting and generation (CL-PDF, a rival to TeX!), OpenGL....
(Peter Seibel's Practical Common Lisp is highly recommended for the "modern" programmer interested in this "old" language. Practical examples include spam filtering, an MP3 database, and a Shoutcast server.)
The What's New document gives a somewhat inaccurate description of the importance of the Decimal type. Naturally, switching from binary to decimal changes which fractions can be exactly represented, but it does not change the fact that some cannot.
The importance of decimal arithmetic is not that it is more accurate than binary, but rather that it conforms more closely to what people expect from using decimal in daily life. These expectations are codified into various social rules such as accounting practices.
There's been some heated discussion of Python 2.4's Decimal, in this very regard, on the Lambda the Ultimate languages blog.
I work for a research institution. We have an Internet 2 connection. I'm the security guy, and (as if that ain't enough work) I sysadmin the mail exchangers, including maintaining anti-spam and anti-virus there. If you send email to the abuse or postmaster addresses at our site, I get it. If you send email to our domain contact about a security or abuse matter, he forwards it to me, and I answer it.
We get complaints every once in a while from the MPAA or their lackeys, claiming that some host on our network is sharing copies of movies -- The Matrix, Harry Potter, Star Wars: Revenge of George Lucas's Crack Pipe... you name it.
Here's the funny thing: they're all wrong.
Every one of them. Wrong. I have never received an MPAA copyright-violation complaint that even had the slightest chance of being correct.
Here's how I know: We have a ridiculously big IP allocation, several times more than we need. Most IP addresses in our space are not used, and have never been used. Like, say, X.Y.1.1, or X.Y.64.64. And yet it is for addresses just such as these that we get complaints.
As far as I can tell, the cause of it is that shitheads somewhere in the world abuse our IP addresses behind NAT, instead of using RFC1918 private addresses as God intended them to. And just like with SIP or any other protocol that uses IP addresses in the protocol level to name hosts, file-trading protocols leak NAT addresses.
The abused addresses get published onto file-trading networks as places to get files. The MPAA's drones pick up these leads, and -- without checking -- give them full credence, and fire off complaints to us. They do not even bother to ping the host and listen for our router screaming back, "You blithering fool, there's no such host. There isn't even such a network!"
Any network operator who still gives any credence to these complaints is a fool. They are all wrong. Even if I got one for an address that actually had a host on it -- or, at least, had ever had a host on it! -- I expect it would also be wrong.
Every once in a while I get a complaint from these losers on a slow day, when I have some spare time and am feeling bored in the office. So I put on my slowest, laziest "I've been working a cushy, do-nothing public-sector IT management job for years, I don't know my ass from a router" tone of voice and phone up the MPAA lackey whose number's on the complaint.
I'm oh so very concerned. There's a pirate on our network? Is he breaking the law? What's his computer? You know -- what's his computer? Yeah, I mean, his eye pee. How do I connect to his eye pee and prove he's got these files? Do I need kazz-uh to do that? Wait... can I do that legally, or am I breaking the Constitution? What's a pee-to-pee anyway, is that some kind of sex perversion?
You get the idea. I thoroughly encourage every other research and educational site network operator to do the very same. Waste their time. Get your stupid out. Stall 'em, stymie 'em, but be very concerned that you don't want any of them Internet pirates pirating your Internet. (Or ask if they know where to find hot lesbian porn.) Most important -- keep the stooge on the line; the MPAA is probably paying him hourly.
In the realm of biological viruses and bacteria, there are steps we can take to discourage the evolution of worse and worse plagues. Although computer viruses are designed rather than evolved, some of these may apply to the computer realm as well.
It's well-known that a parasite that kills its host damages its own chances for survival or reproduction. A germ that doesn't make you sick enough to stay home from work leaves you in able condition to cough that germ all over your coworkers. One that kills you right off has a much decreased chance of spreading to those people... that is, unless your town is in the habit of leaving corpses lying around.
If germs in corpses are able to infect the living, then there is much less "incentive" for germs to leave their hosts alive. If, on the other hand, your civilization isolates corpses, especially obviously infectious ones, then being in a corpse becomes a bad replication strategy for a germ.
This is clearly a way in which human cultural practices affect the evolutionary environment of infectious disease organisms. Under medieval conditions, the Black Plague was pretty darned optimal as a survival strategy. In isolated villages in Congo, the Ebola bacterium can leave messy, nasty corpses lying around and still survive. In places with more effective medical response, that would not be a very effective survival strategy.
What is the analogy to computer viruses? Right now, large portions of the Net have ridiculously crappy "medical response" to computers that are effectively "killed" (rendered useless) by virus and worm infection. Most commercial ISP networks are, to the unprotected Windows computer, the equivalent of rolling around naked in medical waste. This septic environment, in which dead and dying bodies are left to rot and spread their infections, just promote viruses that completely overwhelm the host.
Moreover, the average Windows system and user have the equivalent of terrible hygiene practices. Personal hygiene, in the real world, means that you avoid filthy things when you can; you wash when you've come into contact with them; you wash regularly even if you don't think you have filth on you; and you make sure not to mix filth with your food. Public hygiene means that your society keeps filth and corpses away from the food supply, and keeps rotting garbage off the open street. When these practices break down, you get plagues.
How to prevent this? First, some rudimentary public sanitation would help -- when a system is infected, it must be quarantined and prevented from infecting others. Second, computer users must learn to choose software which has good sanitary practices -- isolating untrusted data ("filth") from the system software ("food") and making sure to clean up those parts of the system that come into contact with the filth.
Can Windows do this? I don't know. The SP2 firewall settings are an improvement. However, it is still a system with terrible hygiene, since user software which handles filth routinely runs with administrator privileges that have access to the food supply. Ick.
This just goes to show what security folks who have to deal with ordinary, average users have been saying for quite some time now: spyware is the #1 security problem for the ordinary Windows user today. Break-ins, worms, and viruses are all nasty problems indeed, but they do not cause the level of sheer aggravation and suffering that spyware does.
A worm outbreak today is an acute disorder -- the bulk of the damage is done in one day, even a handful of hours or minutes. Even though recovering a business or department from it can take longer, the outbreak itself burns through the vulnerable population pretty quickly, and starves itself. Spyware, because it's rooted in long-standing bad security practices both by Microsoft and by Windows users, is a chronic disorder -- it doesn't just shut you down for a day or so; it degrades your online life over a long, nasty time.
To extend the analogy perhaps too far: A flash worm is like Ebola: it kills its victims quickly and messily and leaves a disgusting corpse. Everyone knows when it's in town because of the gory sacks of flesh lying around the streets. Spyware is like cirrhosis of the liver. It comes from doing something bad over a long period of time. It doesn't spread to others materially, though long-term excessive drinking (which causes it) can "spread" memetically in a population, as do bad Windows security practices. And, eventually, it causes the affected organ to be overwhelmed and just shut down.
The spyware situation today is one created by a nexus of influences:
Bad security design in Microsoft Windows,
Absent security education for the ordinary user,
The unethical business practice of contract date-rape, and
Negligent refusal on the part of law enforcement to respond to electronic trespass offenses in other media, such as e-mail spam.
The first two are well-known and I will not address them further. The latter are not.
What I call contract date-rape is the evil represented by so-called "end-user license agreements" and other documents which purport to represent agreements between software publishers and computer owners. The unethical business practice of software publishers is as follows: The computer owner buys a piece of software and installs it, only to find that it is designed so that it cannot be run without "accepting" an "agreement" which waives the owner's rights -- such as resale rights, rights to a refund for defective merchandise, or even free-speech rights. Then, when the software does something harmful and the owner seeks recourse, he is told that he "consented" to whatever harm was done, simply by the act of using what he purchased.
It is contract date-rape which puts the lie to that old FUD about open-source software: "But whom do you sue when it breaks and doesn't get fixed?" The owner of a computer using proprietary software under a Microsoft-style EULA does not have any enforceable rights against the publisher. Windows does break in many ways that Microsoft doesn't fix, but nobody is suing Microsoft for it. Why? Whether the EULA is in fact legally binding or not, both Microsoft and computer owners regard it as leaving Microsoft with no obligations.
(Of course, software was not always sold on "as-is" terms that were intended in law for used and defective products. Nor was it sold on terms that used copyright law as a cudgel with which to deprive users of rights such as fair comment and resale. Contract date-rape is not an endemic problem of proprietary software; it is one that proprietary software publishers have chosen for themselves.)
And it is the methodical use of contract date-rape which leads to the situation we have with spyware today. Spyware gets into a computer owner's property unannounced, alongside some piece of (presumably) desired software. It is a Trojan horse in the original sense -- sooner or later, it bursts open and out pour the soldiers of the enemy, who go about merrily burning w
The FAQ is a literary form, like the sonnet or the mathematics textbook. Every literary form has rules: a sonnet has a rhyme scheme; a mathematics textbook has problem sets and the phrase "left as an exercise for the reader". A sonnet is a particular form of poetry, and a person who writes one is a poet. An FAQ is a particular form of technical writing, and a person who writes one is a technical writer.
FAQs differ from other styles of technical writing in many respects. Foremost, however, is that they are written as a dialogue between novice and expert. The novice, or a collection of (imaginary or real) novices pose questions, and an expert (or aggregate of experts) responds.
Some FAQs are just that -- simple catenations of question and answer on a subject, with no particular connection between one and the next. Others group questions into broad categories, or have one question lead into another, sometimes in a long chain of increasing detail.
One difference among FAQs is how much background understanding they try to convey. Some writers presume that readers merely want shallow, rote answers to their problems: the question "I'm getting a 0x0F00 error" gets the answer "Run the reset_foo command" without further insight. Others use the FAQ form to present deeper facts about the system being documented -- using the question-and-answer format to lead the novice into deeper understanding.
One of the common misunderstandings of FAQs is to treat them as if they should be only a collection of actual questions which have been frequently asked: that the author should not "waste" the reader's time on questions which should be asked (because their answers provide insight) but are not asked (because people do not seek insight as much as they should).
This misunderstanding is an outgrowth of the peculiar form of ideological hatred which many people hold towards those who know more. Consider the computer user who proudly claims to be "computer illiterate", who believes that learning about the system he must use is beneath him. What he wants from documentation -- on the rare occasion that he deigns to read it! -- is only a rote answer to his precise question. Anything else is "wasting his time".
Why does he resent it so when anyone tries to teach him the principles upon which his system operates, so that he can solve his next problem himself? Because for the expert (or FAQ writer) to teach him principles is to tell him that the expert will not be at his beck and call to answer his next trivial question. (If you teach a man to fish, you thereby tell him that you will not hand him a fish every day.)
Teaching the underlying principles is ultimately egalitarian. It says that I, who today am the expert, will not be your servant and will not be your master. I will instead place you on the same level as myself; I will teach you what I know so that you can solve your problem as I would solve it if it were my own. This is why it is unacceptable to people who believe knowledge to be beneath them.
And this is why it is a benefit -- not a problem -- when FAQs include unasked (but worthy) questions as well as those that have been actually posed. It is a benefit, that is, to those who are actually interested in learning; and it hurts and offends those who are interested instead in the degradation of knowledge. That is a good thing.
Email systems developers have come up with a number of tools to reject email abuse:
Local access lists. Every serious SMTP MTA supports access control based on IP address, reverse DNS, attested address (HELO), and so forth.
DNSBLs and other sorts of published blocklists. A DNSBL is nothing but a site's IP-address access list, published over the DNS so that others can use it.
Protocol enforcement techniques such as greylisting. Greylisting tests that the sending host is willing to make the effort of retransmitting, as required by the protocol.
Content filtering. Even a server-side antivirus program is a content filter; much more so the statistical filters often used today.
Multi-site statistical tools. Vernon Schryver's DCC and Vipul's Razor come to mind.
Traffic limiting. ISPs can restrict the number of SMTP messages a host can send per day or hour.
Many of these techniques can be adapted to VoIP systems. I am surprised that SER and Asterisk do not already support DNSBLs -- even if there is no call for them yet, we will certainly need published lists of abusive hosts or networks within a few years.
The flexibility with which one can express access restrictions is an important part of any system's security. My workplace is just starting a VoIP deployment. I want to be able to say things like:
No single outside host may make calls to more than 50 different destinations in a day.
No host may send more than ten pending SIP invites at any time. (Prevent predictive dialing!)
No host may send SIP IMs to more than 20 addresses in the same minute.
After an inbound call is completed, the recipient can dial *666 on our Asterisk PBX to report it as an abusive call. If five different addresses report abusive calls from the same originator, that originator is flagged and blocked for 24 hours.
I can see the Mac thing entirely, but if you're talking PC, why wouldn't you install XP?
In my environment, where we have good and competent central IT support, but do not mandate what our clients (researchers) can run on their desktops, we've found that a lot of people simply do not see any compelling reason to upgrade Windows. By and large, people move from one Windows version to the next when they get a new PC. This is in contrast to our Mac OS X population, who upgrade quickly, and our Linux population, who are in between.
Licensing is not an issue, since we have site licenses for Windows, Mac OS X, and other systems. We have a Windows subscription that allows us to upgrade any Windows install to any later version; and the same for Mac OS X. For Linux, it is of course no problem.
Today, about 60% of the computers on our network are running Windows, according to my p0f results. About 15% each are running Linux and Mac OS X, and the remainder are running a "classic" Unix or Mac OS Classic. Of the Windows users, about 60% are running Windows 2000, 35% are running XP, and the remainder are running Windows NT, 98, or older versions.
So why don't Windows users upgrade? My suspicion is that there is not sufficient benefit from upgrading to make up for two persistent problems: retraining oneself, on the one hand; and broken or lagging third-party software, on the other.
First off, major releases of Windows make substantial disruptive user interface changes. Windows users, in my experience, tend to memorize a lot of rote behaviors -- I do this to dial up, that to search for files, the other to set up printers. The upgrade from Windows 98 to 2000, and then from 2000 to XP, each make a lot of relatively gratuitous changes. (Contrast the XP Control Panel with the 2000 one. Even if you like the XP one better, you've got to admit it looks unfamiliar to someone used to the other.)
Second, a lot of third-party apps break when you upgrade Windows. The version of Matlab the user has installed on Windows 2000 quits working on XP, and so they have to rev Matlab as well. Oops, the Matlab script they got from NASA doesn't work on the new Matlab; gotta get the new one of those. And so it goes. Scientific software is frequently not particularly robust over operating system changes. So an upgrade is a lot more pain for our users than it might be for a business user who does nothing but Word, Outlook, and IE.
Some contrasts from the other platforms:
Our Linux installed base is probably around 90% Red Hat, and the remainder Debian or SuSE -- with almost all of the Debian systems being central IT servers, since we prefer it for its stability there. The Red Hat users are impelled to upgrade chiefly by the obsolescence of older releases: when Red Hat dropped support for 6.2, we had a big migration to 7.x; when they dropped 7.3, to 9; and now to Fedora and RHEL. The driving force behind Red Hat upgrades, for our users, is chiefly the assurance of support and security fixes. I expect that this will calm down a lot now for our RHEL users, who have been promised a stabler upgrade cycle.
(For our Debian systems, in contrast, the drive to upgrade (when a new release comes out!) is to have access to the vast new supply of native packages.)
As for our Mac OS X users, they are the quickest to jump on new releases. Why? I think it's because Apple promotes their new releases with lots of new user features: utilities, non-disruptive appearance tweaks, and speed improvements. I can't emphasize the latter too much: each release of Mac OS X has made it faster, and this is a big reason for a scientist (or a ordinary end user, for that matter!) to upgrade.
It's been said that Microsoft's chief competition today is itself, five years ago -- that is, rather than contending for market share against Apple, Red Hat, or SuSE, each new re
Ingres is a fantastic technology. Open innovation has been blocked above the operating system. By open sourcing Ingres, we will create the next generation of database and application innovation. CA will embed a management database based on Ingres into several core technologies.
M. Greenblatt appears to be unable to discuss any actual advantages of the Ingres database software. Instead, he resorts to smears like this one against existing open-source competitors to his product. Naturally, since he is answering a question about existing enterprise open-source database systems, to deny that they exist is nothing more than lying.
Moreover, it's a lie that simply will not be believed in this forum, where the audience is already much more familiar and comfortable with these competitors than with Ingres. So why bother lying? When a person lies even when they know that they will not be believed, it suggests that there is something seriously the matter with them.
My point is this: Graham seems to really like the "small is better" approach, for which interpreted languages really shine.
Actually, the language that Graham is most associated with is Common Lisp, which is neither a small nor an interpreted language. It is relatively large for a Lisp dialect (much larger than Scheme), and a compiler is part of the specification.
(I'm not counting Arc, since it doesn't exist yet.)
Yes, forgery can cause problems for particular users of the email system. These problems break down as follows. None of them are nearly on the scale of the spam problem... and SPF doesn't really help any of them:
Casual mischief. People have played silly-buggers with the ability to pretend to be someone else online for years. Mostly this has amounted to kids forging mail in the name of their teachers for petty harassment. While annoying, casual mischief is not a hazard to email itself, in the way that spam is. SPF does not stop casual mischief, since this is usually confined to a single site and domain.
Misconfigured systems. Virus bounces, vacation messages to public mailing lists, and the like are all examples of operator cluelessness. Yes, forgery of spam and virus messages triggers your awareness of this cluelessness, but it isn't the root of the problem. Nobody's mail server should be sending bounce messages for content inspection, when every enterprise-grade MTA supports real-time inspection during the SMTP transaction. SPF offers no protection against misconfigured or negligently configured systems -- do you expect that the idiot whose antivirus software sends you spurious bounces is in any hurry to check your SPF record?
Reputation problems. Joe jobs are the exemplar here: someone sends spam that purports to advertise your service, and your service gets a public black eye as a spammer for it. SPF can stop joe-jobbers from sending mail that in the SMTP dialog purports to be from your domain. But hey! -- spammers don't send mail from their own domains, they send it from zombies and just include HTML links pointing to their own Web sites. Joe jobbers can do the same to your Web site, and SPF in no way stops them.
In each case, SPF doesn't actually prevent the malicious user or clueless operator from causing you the damage he can cause you now. Why then should you bother to support it?
Being seen as doing something is good enough reason for Microsoft. They'll take any chance they get to be represented in the media as part of the solution when everyone in the trenches knows they are the root of the problem -- nets of worms, preferred system of trojans, spawner of zombies.
But the workaday operator, you and me -- that lie just sits wrong with us. We give a damn about the system we work all day to maintain. We give a damn about our fellows at other sites who have to deal with the same freakin' virus and spam bullshite we do. We shouldn't give our nod to flashy systems that our own experience and knowledge prove have no chance of working to solve the real problem.
Forgery is a failing of the current mail system, yes. But it is not responsible for spam, and spam crime can operate gleefully without the kind of "forgery" that SPF attacks. I know that users aren't always 100% happy with tough-on-spam answers like greylisting and blocklists, but those are the ones that work. Why waste time on junk like SPF that gets headlines but doesn't actually inconvenience the spammers at all?
Protect yourself from the next round of worms due out in a few weeks, and install XP SP2 to take down your system before a Worm does. If your system is offline, it cannot be infected by a worm, you are protected 100%!
Don't laugh quite so hard. This was, only a few years ago, the logic of the "precautionary disconnect". In order to protect Windows computers from being made unavailable by virus attacks, major corporations took their entire operations offline. That was back in 1999, when Bill Clinton was trying to bomb Osama bin Laden, but the media were touting "cyber-terrorism" as the latest threat. Ironically enough, it was two years before Code Red or Nimda showed what a worm outbreak could be like. Moreover, it was three years before spammer viruses proved that it wasn't "cyber-terrorism" but the spammers' twisted idea of "online commerce" that would cause us the greater Internet security hassle.
In what sense is Microsoft's adoption of SPF "proof that technology works" for stopping spam?
First off, it hasn't happened yet. Nothing has been proven to work here, since they haven't actually done anything yet.
Second, SPF doesn't stop spam in the long run. SPF does not even address the problem of spam per se -- it addresses email forgery, and that not very well. In the unlikely event that every email system everywhere implemented SPF restrictions, spammers would still be able to send spam. They simply would not be able to send it under forged addresses in domains that publish restrictive SPF records. They could still send forged spam under domains that cannot (for their own reasons) use highly restrictive SPF, or they could send spam under their own domains.
(Yes, spammers have their own domains. Usually lots of them -- domain registrars' "bulk register" systems allow them to get LOTS of them easily. The registrars get their money, so most of them don't care that the domains are being used for spamming and the contact information is bogus.)
SPF is a case of "solving the wrong problem". The patient has a broken arm, but the quack doctor does not know how to set bones so he gives the patient an aspirin. But the patient's problem is not basically that he is in pain, but that his arm is broken -- the quack is solving the wrong problem.
The Internet's email system basically does not have a forgery problem. People who need to send each other forgery-proof email are already able to do this using systems like PGP. The email system does, however, have a spam problem. Though a good deal of spam is forged, the spam problem goes deeper than forgery. If SPF is widely deployed, spammers will just work around it... just as they worked around the closing of SMTP open relays by deploying zombie viruses.
The spam problem is today one of ISP accountability, not email forgery. Spammers do their thing, and when people come around to complain, spam-friendly ISPs shine them on. No joke -- take a look around the Spamhaus Project, where professional researchers have tracked down the ISPs that do the most to help spammers.
SPF isn't the solution to spam. SPF isn't even the solution to forgery. But it makes nice headlines. People who want to look busy, and look like they are Doing Something to solve a nasty problem, sometimes don't care if the Something they're Doing is actually effective at all.
(Besides, honestly, why would you expect a company which itself sends spam for hire to actually try to stop spam? Microsoft bCentral operates some legitimate mailing lists, but it also allows its list operators to send unsolicited "opt-out" spam. This is an archive of reported spam sent using bCentral facilities.)
The reported study discusses the number and claimed severity of official security advisories for different systems. The factitious claims being made do not address the following problems:
Different suppliers report vulnerabilities differently. Consider every "cumulative update" you've seen, and every "multiple vulnerabilities in $product" advisory from CERT. A supplier which is more honest and meticulous about vulnerability reporting may have more advisories but better security -- while one which batches up several bugs in a single advisory will underreport.
A system which includes more software may have more advisories, even though most advisories do not affect most computers running that system. In Windows, a database server is a separate product whose advisories would not be counted against "Windows". Many Linux systems include at least two database servers, but they are not turned on by default. If a hole in MS SQL doesn't count against Windows, should one in mySQL count against Red Hat?
Unpatched vulnerabilities may go for months without the release of an official advisory. For instance, a number of holes in Internet Explorer have been known and discussed within the security community well in advance of any official advisory from Microsoft.
Systems which have better default system-wide security settings (e.g. packet filtering, services turned off by default) may have all kinds of "vulnerabilities" that can't actually be exploited. For instance, Mac OS X includes OpenSSH, but it's turned off until the user asks for it. A hole in OpenSSH cannot be exploited on a default-install Mac system.
Leaving it up to the supplier to decide if something is a "vulnerability" or a "feature" leads to underreporting. Take CD autorun, for instance, which allows the installation of spyware when a (mostly-)audio CD is inserted into a Windows PC. A security-conscious user regards this as a vulnerability, but the supplier regards it as a beneficial feature.
Some of the most common attacks -- such as viruses -- rely on social engineering, and on "features" that are not classed as "vulnerabilities". However, these attacks are also more prominent on some systems than on others. Any comparative assessment of security which discounts the most common attacks blinds itself to a wide segment of the security landscape.
and what exactly, is wrong with portscanning?
...Isn't that how the internet was navigated, pre-gopher?
Actually, it isn't. Before Gopher, people found Internet resources by being told about them, or reading about them in mailing list posts, FAQs, or the like. For Internet users with Usenet access (Usenet was not originally an Internet service) there were regularly-posted lists of public FTP sites. There was also Archie, a search engine with which FTP site operators would voluntarily register their sites to be indexed.
Mass portscanning would have then been unacceptable not only because of the intrusion, but because of the traffic. Scanning 1024 well-known ports on 254 possible hosts on a Class-C network involves sending something like 2 MB of traffic. Multiply that by several target networks and you get quite a bit of traffic for the days of 14.4kbps modems and 56k leased lines. It would take hours, and consume expensive bandwidth that would be better used by real applications.
Be honest and up-front with security advice. You know that Windows is a massive security risk. You know that Linux, BSD, and Mac OS X systems aren't virus-proof, but that they have on average a lot fewer problems. You know that a Windows system can be operated reasonably securely only if it's protected with up-to-date anti-virus software, zero-day Windows Update, and careful choices of third-party software. Communicate these facts.
Let students make choices freely, but offer them the tools you think are worth using. Don't require them to install particular software -- especially not something they will find untrustworthy, like monitoring software. Instead, make tools easily available which you have found to be valuable. That may mean a site license for your favorite anti-virus software. It may mean handing out Knoppix CDs. Or it may mean selling inexpensive NAT "firewalls" in the campus store, and giving the Help Desk the setup instructions.
Support smart choices, not just popular ones. Sure, most of your students use Windows. Some don't. Of the Windows users, most use Internet Explorer. Some don't. Make sure the ones who don't are welcome. The campus Web site needs to work in Safari, Konqueror, Galeon, and Firefox. The wireless network can't rely on a Cisco client program that only works properly on Windows. The help desk needs to be able to answer Mac OS X questions and some basic Linux desktop questions -- or, if not, refer them to someone who can, like the campus LUG.
Monitor for problems that harm others -- don't snoop. Ideally, every border on your campus network should have enough IDS to detect portscans. If not, no big deal -- monitor what you can. You're looking for signs of viruses, break-ins, bots, backdoors. You aren't looking for porn, MP3s, or passwords. You do not have the right to access students' files on their own computers; those are their property. (Don't claim to have that right in your AUP. You still don't have it.)
Cut off compromised systems. When you find a compromised system, cut it off the network first, then contact the owner. Use MAC-based blocking -- automatic, if at all possible. If your network registration system (you do have one, right?) associates the wired and wireless interfaces of a given computer, make sure to block both, since XP will wake up wireless if the wired cuts out. (Really, this is not all that much Perl!)
Don't punish accidents, but don't shield students from their choices' consequences. If a student's computer is infected with a virus and cut off, that's a bummer for the student. But it's probably in part the consequence of that student's choices. (After all, the Mac user next door didn't get the virus, and neither did the XP user who installed this week's patch the day it came out.) Your IT staff are not obligated to provide free disinfection services or OS reinstalls, and you are entitled to bill for clean-up, just as the residential life office would if someone trashed their room. The purpose here isn't punishment; it's simply to place the costs on the persons whose choices incurred those costs.
Some troublemaker freshmen will be your student computing assistants next year. Not all of them will. But you will hear about students who are doing "bad things" on the network. (You will hear -- you probably don't have to scan for them.) Students who act up, portscan their dorm, index the SMB shares of all the lusers who didn't realize they were exporting all their porn, piss off the systems staff, and make crazy demands are probably not sociopathic techno-crooks. They will get over it. Call them in and make friends with them. Some will start being useful to others. Hire them. Others will be nasty and malicious. Get them expelled.
The problem I see here is not ads, or non-Linux ads, or even Microsoft ads. Dave Whitinger actually glosses over the real problem: it is deceptive Microsoft ads -- or any other ads which deceptively attack open-source software.
Most publications have advertising standards. They will not accept advertisements which do not meet these standards. You can get ad space in The New York Times to promote your product, or to set out your political position, or to call for a boycott, or to celebrate your wedding. You cannot get ad space in The New York Times to call someone by a derogatory racial epithet. You cannot get ad space in The New York Times to propound a claim that the editors know to be maliciously false. You cannot get ad space in The New York Times to advocate violence against women.
I suggest that a useful outcome of this controversy would be for Linux- and free-software-related Web publications to adopt strong advertising standards. These standards need to embrace not only basic standards of respectable public conduct (as in the examples above) but also a clear respect for the free-software and open-source world. They should refuse any advertisement which is, at its core, an attack upon free software and open source. It is wrong for publications which derive their livelihoods from free software to allow their visibility to be used to harm it.
The FS/OSS world is closely coupled to the public discourse about software. Many free-software developers are motivated not by profit but by art, personal need, and the perceived interests of their fellows. Public and professional discussion about software has always informed free-software development. We see this in the early discussions of software freedom and the rise of Project GNU. We see it in the collaboration which brought forth Linux -- collaboration mediated by discussions on Usenet and mailing lists. We see it when projects today fork (or merge) on the basis of public statements of animosity or admiration. Software is speech (as was confirmed in Bernstein v. United States) and the open-source world is uniquely close to this fact. This is why we hate lies about our work: because our work is about information, and spurred on by meaningful collaboration; deception is the opposite of these things.
It's not just us, either. Professionals in any field are revulsed by misinformation about their field. Climatologists have expressed little but disdain for the movie The Day After Tomorrow. Medical doctors hate quackery. Lawyers mock bad law advice. Sex educators despise the myths which lead teenage girls to try douching with Coca-Cola to prevent pregnancy. How much more is this in a case in a field whose lifeblood is information itself? An innocently false statement is a bug; a lie is a deliberately planted backdoor.
Advertisements which present falsehoods about open-source software should not be accepted -- not by Linux Today, not by Slashdot, and not by any other publication which lives by free software. It would not be too extreme, I suspect, to banish any advertisement whose focus is an attack on any piece of free software / open source, or one focused on attacking the idea of free software itself.
Sure, Mr. and Ms. Open-Source Publications, take ads from Microsoft. Take ads promoting a new version of Windows; or the latest Xbox game; or the C# language. But don't take ads that mislead, that say "Windows is cheaper than Linux"; don't take ads that propound SCOX's libels, even by sulfuric little hints; don't take ads that harm the community whose existence and whose contributions make your publication possible.
dictionary.com says "Having hidden meaning; mystifying". I think all of those can apply to that command and the majority of commands that make up linux/unix.
There may be two problems here -- one personal, and one more technical.
First, Unix people may read "cryptic" as a slander, and others may use it as such as well: for "cryptic", read "obfuscated". The slanderous implication is that programmers make complicated interfaces for no good reason -- or specifically for a bad reason, such as to maintain prestige or "job security". This is, or at least feels like, a personal attack: "Computers are not inherently hard to use. Computer nerds have deliberately made them hard to use, in order to hurt me. Therefore, my inability to use computers productively is not due to my own refusal to learn; it is, rather, due to their malicious action."
Second, the unexpressed alternatives to "cryptic" may well be "verbose" and "dumbed-down", and being cryptic may be the least of these three evils. A syntax appears cryptic when it tries to represent a large amount of complexity without requiring a large amount of typing. For a powerful syntax which prefers verbosity over crypticity, see COBOL -- by all reports a capable programming language, but one that few wish to use because it requires you write ADD 1 TO X GIVING X where C has x++;.
If one wishes a system to be neither verbose nor cryptic, the only option is to dumb it down: to remove capabilities which can only be represented with complicated expressions. Most Unix programs are far more powerful than their Windows analogues; you can do much more with the find command than you can with Windows' GUI equivalent.
Most Unix programmers choose likewise: if one has the choice to be either dumbed-down, or verbose, or cryptic, one should choose the last of these. Why? Of the three, the cryptic (but not maliciously obfuscated) system is the one which most rewards learning. Becoming an expert in a dumbed-down system is no great shakes: you can't do much more than the novice can, because all the system's functionality is geared towards the novice. Becoming an expert in a verbose system gives you power, but you have to wear your fingers down to stubs. Becoming an expert in a cryptic system allows you all that power without so much pain.
Why not just invent a better protocol that can't be abused as easily?
Take a shot. Some design criteria you should keep in mind:
People need to be able to send messages to people they don't know, and have no common contacts with. A system which relies on "introducers" can be layered on top of a more open system (think PGP) but is not adequate alone. If one user can't send email to any other off-the-cuff, you lose, since people will have to resort to SMTP when they need it... and if they have to do that, why use your system?
Sites require their own servers, and no dependence on a central authority to process messages. They can choose to delegate authority over filtering (as with DNSBLs) but it can't be a requirement. If you (the system's creator) or any other power (say, Verisign) can monitor, censor, or shut off anyone's email, you lose -- why should General Electric trust your system?
A new mail system must support gateways to SMTP. After all, SMTP would never have replaced UUCP, BITNET, and Fidonet mail if it had not been able to gateway to them. (If the only mail system you know about is SMTP, you don't know enough to build a new mail system.) These gateways must not themselves be easily abusable, or users of SMTP will reject mail from them. If that happens, your gateways get kicked off their ISPs for being spam sources, and you lose.
A new mail system must offer its early adopters immediate benefit. If a new system doesn't offer real benefits until 51% of the world is using it, then no more than 0.1% will ever adopt it. If the only way your abuse-proof protocol is abuse-proof is to reject email from the whole dirty SMTP world, you lose.
The standard must be a single open protocol, not a single implementation. Developers must be able to implement that protocol on disparate platforms on all different scales. Any implementation conformant with the standard must be able to talk to any other. Handing the world a Perl script and saying "this is the new email system" means you lose -- most people don't have Perl on their Windows and Palm systems and aren't going to install it to try out a new mail system.
Think you're up to it? Go for it. You have nothing to lose, right?
Spam is not a technical result of the email system, the way that (say) packet collisions are a technical result of shared-media Ethernets. Rather, spam -- just like theft -- is a result of individual human beings (the spammers) choosing to offend. They are aided in this choice by other individuals (employees and managers of spam-supporting ISPs) choosing to permit their resources to be used for this offense.
It is a category error to treat spam as a software bug rather than as human misbehavior. It's true that technical measures can reduce or ameliorate the spam problem, just as technical measures such as locks and sturdy vaults can reduce or deter robbery. However, that doesn't make spam (or robbery) a technical rather than a behavioral problem.
There is no technical fix for spam. Real fixes for the spam problem must take place on the human level: enforcement of laws against spam and spam-related computer crime; refusal of connectivity to spammers and spam supporters; boycotting of firms which spam or benefit from spam.
It ain't a joke. Honest software makers will indeed likely support it, since it allows them to make clear how their software differs from crapware. I'd go for a few more labels, though, intended to illustrate the intent of the software, so you get what you are paying for.
A portcullis. This software filters or alters the content of files or incoming Internet traffic. Web pages you see, for instance, might not represent the exact transmissions of the Web server or the intent of the author. Appropriate to anti-virus software, porn-filtering censorware, privacy software... and adware that replaces ad banners with other ad banners.
A police badge. This software runs by default under elevated or superuser ("root" or "Administrator") privilege. (Simply requiring superuser privilege to install the software doesn't count. Creating a dummy user with most of the privileges of the superuser does, though.) Therefore a bug in this software, including a security vulnerability, can affect anything on your computer -- not just the files owned by the user actively using it.
A cable plugged into a wall socket. This software accepts incoming network connections in the default configuration. If you do not intend this software to accept traffic from the Internet, you will need to change the configuration or have a firewall.
A computer with an arrow through the monitor. This software is designed to be remotely disabled by the publisher under certain circumstances (such as breach of license or expiration of subscription). The fact that it is installed and working today does not imply that it will continue to work without future intervention.
A closed mouth with a finger making the "shush" gesture. This software's license forbids or encumbers the publication of reviews without the permission of the publisher. Reviews you may have read of this software may have been selected by the publisher to represent it in an unfairly positive light.
A pair of handcuffs. Documents or other files you produce using this software are encumbered by its license, patents, or other proprietary rights of the publisher. Appropriate for a word processor whose file format is patented, or a compiler whose license forbids you to use it to write software that competes with the publisher's other software.
Slashdot Mirror
Then, since you've earlier eliminated distinct close tags for different open tags, instead of making the close tag </ you make the open tag simply not have the final > ... use that for the close tag instead. So for what started as <A FOO="BAR" /> ends up as <A <FOO BAR>>.
Now, angle brackets are kind of ugly. It would be more aesthetically pleasing to use something a little more rounded, something that has a history in mathematics of meaning "nested syntax for evaluation". Like, say, parentheses.
So you end up with (A (FOO BAR)). Conveniently enough, this is also a syntax for which highly efficient parsers have existed since ... oh, 1960 or so. There are, today, two major common schemes for evaluating trees like this as code, and three or so different standards for expressing syntax-to-syntax transformations on trees like this -- kind of like XSLT, but actually efficient.
Sounds like a win to me.
Standards compliance is a great thing. Recently I've been working on a VoIP deployment using SIP phones, Asterisk, and SER. One of the things that has impressed us the most about SIP telephony -- as contrasted with earlier VoIP and digital office phone systems -- is that the major vendors' products all interoperate at a basic level (placing and receiving calls) out of the box. This is a big contrast with earlier systems where (e.g.) Nortel sold you a Succession VoIP system, and nobody else's phones would work on it.
Most of these SIP phones are not open-source. Cisco's and Grandstream's phones are the usual binary-only deal -- compliant with open standards, but not even source-available. However, some SIP phones are open-source, notably SNOM phones, which run embedded Linux, and for which you can download an SDK from their Web site and build your own firmware image. Not too terribly surprisingly, SNOM's phones are not the slickest in appearance (that would be Cisco) or the cheapest (Grandstream) but they are, as far as we can tell, the most configurable.
Much the same seems to be true of VoIP gateway systems. Many people with whom I've spoken are using Cisco instruments as their gateway between SIP and the PSTN (conventional phone system). We are using Asterisk. Although it is hardly the easiest software to configure -- it's kind of like the Sendmail of VoIP, minus the security hell -- the Asterisk/Zaptel/Linux system is far more flexible than closed equivalents.
So what does this have to do with the advantages of open source? In a field of open standards, such as SIP telephony, open source can really shine. Open standards mean that there is little space for vendor lock-in, so vendors cannot exclude open source in the usual fashion. Open source is largely immune to the problem of treating standards as "tick-list features", which some appliance developers seem to suffer from: implementing the standard in a slapdash way so that you can mention it in the four-color glossies. ("Do we have, um, this 'SIP' thing?" "Uh ... [type type] ... sure, we do now!")
So how does this contrast with some of open source's notable weaker points, like user interface and graphics software mentioned in the article? It seems to me that open standards and open source both have their strengths in infrastructure as opposed to interface: not the buttons that users push on their desktops, but the underlying systemry that really makes the system (and the network) run. The advantage of Asterisk over proprietary PSTN gateways is much more than the advantage (if any!) of SNOM over Cisco SIP phones. The same is true in other infrastructural roles: the advantage of Apache over Microsoft IIS is much more than the advantage (if any!) of KDE over, say, the Mac OS X interface.
For the user of closed-source end-user systems (be they phones or desktop computers) the presence of open source in the infrastructure means that it can be customized by experts (IT staff or consultants) to the needs of the organization. It also often means that the infrastructure is simply higher-quality, which benefits everyone. The folks who get VoIP phones on their desks at my workplace don't care whether the gateway is Asterisk or Cisco, but they do care if we can implement features they request. Likewise, our Web designers using Dreamweaver benefit more from the fact that we use Apache (since their work is safer than it would be with IIS) than they would by using an open-source end-user tool.
To make a tangent, consider Microsoft. Their tradit
Currently, the bulk of the big spammers live and operate within the United States. They may host their Web sites in China, buy lists of open proxies from Romania, and commission viruses from Russian Mafia programmers -- but they live in the "comfort" of the U.S. whose laws they flout.
They do not want to move overseas. They want the comforts of home -- to make millions without leaving the couch. They are small-minded, hurtful, nasty little people. They want the world delivered to their door, and are willing to steal and destroy to get it -- but only if they can do that stealing and destroying from behind a screen. They are not brave. When they are challenged, they retreat into paranoia and lash out with lawsuits based on conspiracy theories. Can't do that from East Bumfuckistan.
But seriously, Common Lisp is the Common Lisp for the 21st century. It's doing quite nicely; in the past couple of years folks have taken this "old" programming language and added excellent support for all kinds of current needs -- a Web application server (TBNL), a remarkable SQL interface (CL-SQL), general-purpose dataflow programming (Kenny Tilton's Cells), PDF typesetting and generation (CL-PDF, a rival to TeX!), OpenGL ....
(Peter Seibel's Practical Common Lisp is highly recommended for the "modern" programmer interested in this "old" language. Practical examples include spam filtering, an MP3 database, and a Shoutcast server.)
The importance of decimal arithmetic is not that it is more accurate than binary, but rather that it conforms more closely to what people expect from using decimal in daily life. These expectations are codified into various social rules such as accounting practices.
There's been some heated discussion of Python 2.4's Decimal, in this very regard, on the Lambda the Ultimate languages blog.
We get complaints every once in a while from the MPAA or their lackeys, claiming that some host on our network is sharing copies of movies -- The Matrix, Harry Potter, Star Wars: Revenge of George Lucas's Crack Pipe ... you name it.
Here's the funny thing: they're all wrong.
Every one of them. Wrong. I have never received an MPAA copyright-violation complaint that even had the slightest chance of being correct.
Here's how I know: We have a ridiculously big IP allocation, several times more than we need. Most IP addresses in our space are not used, and have never been used. Like, say, X.Y.1.1, or X.Y.64.64. And yet it is for addresses just such as these that we get complaints.
As far as I can tell, the cause of it is that shitheads somewhere in the world abuse our IP addresses behind NAT, instead of using RFC1918 private addresses as God intended them to. And just like with SIP or any other protocol that uses IP addresses in the protocol level to name hosts, file-trading protocols leak NAT addresses.
The abused addresses get published onto file-trading networks as places to get files. The MPAA's drones pick up these leads, and -- without checking -- give them full credence, and fire off complaints to us. They do not even bother to ping the host and listen for our router screaming back, "You blithering fool, there's no such host. There isn't even such a network!"
Any network operator who still gives any credence to these complaints is a fool. They are all wrong. Even if I got one for an address that actually had a host on it -- or, at least, had ever had a host on it! -- I expect it would also be wrong.
Every once in a while I get a complaint from these losers on a slow day, when I have some spare time and am feeling bored in the office. So I put on my slowest, laziest "I've been working a cushy, do-nothing public-sector IT management job for years, I don't know my ass from a router" tone of voice and phone up the MPAA lackey whose number's on the complaint.
I'm oh so very concerned. There's a pirate on our network? Is he breaking the law? What's his computer? You know -- what's his computer? Yeah, I mean, his eye pee. How do I connect to his eye pee and prove he's got these files? Do I need kazz-uh to do that? Wait ... can I do that legally, or am I breaking the Constitution? What's a pee-to-pee anyway, is that some kind of sex perversion?
You get the idea. I thoroughly encourage every other research and educational site network operator to do the very same. Waste their time. Get your stupid out. Stall 'em, stymie 'em, but be very concerned that you don't want any of them Internet pirates pirating your Internet. (Or ask if they know where to find hot lesbian porn.) Most important -- keep the stooge on the line; the MPAA is probably paying him hourly.
It's well-known that a parasite that kills its host damages its own chances for survival or reproduction. A germ that doesn't make you sick enough to stay home from work leaves you in able condition to cough that germ all over your coworkers. One that kills you right off has a much decreased chance of spreading to those people ... that is, unless your town is in the habit of leaving corpses lying around.
If germs in corpses are able to infect the living, then there is much less "incentive" for germs to leave their hosts alive. If, on the other hand, your civilization isolates corpses, especially obviously infectious ones, then being in a corpse becomes a bad replication strategy for a germ.
This is clearly a way in which human cultural practices affect the evolutionary environment of infectious disease organisms. Under medieval conditions, the Black Plague was pretty darned optimal as a survival strategy. In isolated villages in Congo, the Ebola bacterium can leave messy, nasty corpses lying around and still survive. In places with more effective medical response, that would not be a very effective survival strategy.
What is the analogy to computer viruses? Right now, large portions of the Net have ridiculously crappy "medical response" to computers that are effectively "killed" (rendered useless) by virus and worm infection. Most commercial ISP networks are, to the unprotected Windows computer, the equivalent of rolling around naked in medical waste. This septic environment, in which dead and dying bodies are left to rot and spread their infections, just promote viruses that completely overwhelm the host.
Moreover, the average Windows system and user have the equivalent of terrible hygiene practices. Personal hygiene, in the real world, means that you avoid filthy things when you can; you wash when you've come into contact with them; you wash regularly even if you don't think you have filth on you; and you make sure not to mix filth with your food. Public hygiene means that your society keeps filth and corpses away from the food supply, and keeps rotting garbage off the open street. When these practices break down, you get plagues.
How to prevent this? First, some rudimentary public sanitation would help -- when a system is infected, it must be quarantined and prevented from infecting others. Second, computer users must learn to choose software which has good sanitary practices -- isolating untrusted data ("filth") from the system software ("food") and making sure to clean up those parts of the system that come into contact with the filth.
Can Windows do this? I don't know. The SP2 firewall settings are an improvement. However, it is still a system with terrible hygiene, since user software which handles filth routinely runs with administrator privileges that have access to the food supply. Ick.
A worm outbreak today is an acute disorder -- the bulk of the damage is done in one day, even a handful of hours or minutes. Even though recovering a business or department from it can take longer, the outbreak itself burns through the vulnerable population pretty quickly, and starves itself. Spyware, because it's rooted in long-standing bad security practices both by Microsoft and by Windows users, is a chronic disorder -- it doesn't just shut you down for a day or so; it degrades your online life over a long, nasty time.
To extend the analogy perhaps too far: A flash worm is like Ebola: it kills its victims quickly and messily and leaves a disgusting corpse. Everyone knows when it's in town because of the gory sacks of flesh lying around the streets. Spyware is like cirrhosis of the liver. It comes from doing something bad over a long period of time. It doesn't spread to others materially, though long-term excessive drinking (which causes it) can "spread" memetically in a population, as do bad Windows security practices. And, eventually, it causes the affected organ to be overwhelmed and just shut down.
The spyware situation today is one created by a nexus of influences:
The first two are well-known and I will not address them further. The latter are not.
What I call contract date-rape is the evil represented by so-called "end-user license agreements" and other documents which purport to represent agreements between software publishers and computer owners. The unethical business practice of software publishers is as follows: The computer owner buys a piece of software and installs it, only to find that it is designed so that it cannot be run without "accepting" an "agreement" which waives the owner's rights -- such as resale rights, rights to a refund for defective merchandise, or even free-speech rights. Then, when the software does something harmful and the owner seeks recourse, he is told that he "consented" to whatever harm was done, simply by the act of using what he purchased.
It is contract date-rape which puts the lie to that old FUD about open-source software: "But whom do you sue when it breaks and doesn't get fixed?" The owner of a computer using proprietary software under a Microsoft-style EULA does not have any enforceable rights against the publisher. Windows does break in many ways that Microsoft doesn't fix, but nobody is suing Microsoft for it. Why? Whether the EULA is in fact legally binding or not, both Microsoft and computer owners regard it as leaving Microsoft with no obligations.
(Of course, software was not always sold on "as-is" terms that were intended in law for used and defective products. Nor was it sold on terms that used copyright law as a cudgel with which to deprive users of rights such as fair comment and resale. Contract date-rape is not an endemic problem of proprietary software; it is one that proprietary software publishers have chosen for themselves.)
And it is the methodical use of contract date-rape which leads to the situation we have with spyware today. Spyware gets into a computer owner's property unannounced, alongside some piece of (presumably) desired software. It is a Trojan horse in the original sense -- sooner or later, it bursts open and out pour the soldiers of the enemy, who go about merrily burning w
The FAQ is a literary form, like the sonnet or the mathematics textbook. Every literary form has rules: a sonnet has a rhyme scheme; a mathematics textbook has problem sets and the phrase "left as an exercise for the reader". A sonnet is a particular form of poetry, and a person who writes one is a poet. An FAQ is a particular form of technical writing, and a person who writes one is a technical writer.
FAQs differ from other styles of technical writing in many respects. Foremost, however, is that they are written as a dialogue between novice and expert. The novice, or a collection of (imaginary or real) novices pose questions, and an expert (or aggregate of experts) responds.
Some FAQs are just that -- simple catenations of question and answer on a subject, with no particular connection between one and the next. Others group questions into broad categories, or have one question lead into another, sometimes in a long chain of increasing detail.
One difference among FAQs is how much background understanding they try to convey. Some writers presume that readers merely want shallow, rote answers to their problems: the question "I'm getting a 0x0F00 error" gets the answer "Run the reset_foo command" without further insight. Others use the FAQ form to present deeper facts about the system being documented -- using the question-and-answer format to lead the novice into deeper understanding.
One of the common misunderstandings of FAQs is to treat them as if they should be only a collection of actual questions which have been frequently asked: that the author should not "waste" the reader's time on questions which should be asked (because their answers provide insight) but are not asked (because people do not seek insight as much as they should).
This misunderstanding is an outgrowth of the peculiar form of ideological hatred which many people hold towards those who know more. Consider the computer user who proudly claims to be "computer illiterate", who believes that learning about the system he must use is beneath him. What he wants from documentation -- on the rare occasion that he deigns to read it! -- is only a rote answer to his precise question. Anything else is "wasting his time".
Why does he resent it so when anyone tries to teach him the principles upon which his system operates, so that he can solve his next problem himself? Because for the expert (or FAQ writer) to teach him principles is to tell him that the expert will not be at his beck and call to answer his next trivial question. (If you teach a man to fish, you thereby tell him that you will not hand him a fish every day.)
Teaching the underlying principles is ultimately egalitarian. It says that I, who today am the expert, will not be your servant and will not be your master. I will instead place you on the same level as myself; I will teach you what I know so that you can solve your problem as I would solve it if it were my own. This is why it is unacceptable to people who believe knowledge to be beneath them.
And this is why it is a benefit -- not a problem -- when FAQs include unasked (but worthy) questions as well as those that have been actually posed. It is a benefit, that is, to those who are actually interested in learning; and it hurts and offends those who are interested instead in the degradation of knowledge. That is a good thing.
Many of these techniques can be adapted to VoIP systems. I am surprised that SER and Asterisk do not already support DNSBLs -- even if there is no call for them yet, we will certainly need published lists of abusive hosts or networks within a few years.
The flexibility with which one can express access restrictions is an important part of any system's security. My workplace is just starting a VoIP deployment. I want to be able to say things like:
In my environment, where we have good and competent central IT support, but do not mandate what our clients (researchers) can run on their desktops, we've found that a lot of people simply do not see any compelling reason to upgrade Windows. By and large, people move from one Windows version to the next when they get a new PC. This is in contrast to our Mac OS X population, who upgrade quickly, and our Linux population, who are in between.
Licensing is not an issue, since we have site licenses for Windows, Mac OS X, and other systems. We have a Windows subscription that allows us to upgrade any Windows install to any later version; and the same for Mac OS X. For Linux, it is of course no problem.
Today, about 60% of the computers on our network are running Windows, according to my p0f results. About 15% each are running Linux and Mac OS X, and the remainder are running a "classic" Unix or Mac OS Classic. Of the Windows users, about 60% are running Windows 2000, 35% are running XP, and the remainder are running Windows NT, 98, or older versions.
So why don't Windows users upgrade? My suspicion is that there is not sufficient benefit from upgrading to make up for two persistent problems: retraining oneself, on the one hand; and broken or lagging third-party software, on the other.
First off, major releases of Windows make substantial disruptive user interface changes. Windows users, in my experience, tend to memorize a lot of rote behaviors -- I do this to dial up, that to search for files, the other to set up printers. The upgrade from Windows 98 to 2000, and then from 2000 to XP, each make a lot of relatively gratuitous changes. (Contrast the XP Control Panel with the 2000 one. Even if you like the XP one better, you've got to admit it looks unfamiliar to someone used to the other.)
Second, a lot of third-party apps break when you upgrade Windows. The version of Matlab the user has installed on Windows 2000 quits working on XP, and so they have to rev Matlab as well. Oops, the Matlab script they got from NASA doesn't work on the new Matlab; gotta get the new one of those. And so it goes. Scientific software is frequently not particularly robust over operating system changes. So an upgrade is a lot more pain for our users than it might be for a business user who does nothing but Word, Outlook, and IE.
Some contrasts from the other platforms:
Our Linux installed base is probably around 90% Red Hat, and the remainder Debian or SuSE -- with almost all of the Debian systems being central IT servers, since we prefer it for its stability there. The Red Hat users are impelled to upgrade chiefly by the obsolescence of older releases: when Red Hat dropped support for 6.2, we had a big migration to 7.x; when they dropped 7.3, to 9; and now to Fedora and RHEL. The driving force behind Red Hat upgrades, for our users, is chiefly the assurance of support and security fixes. I expect that this will calm down a lot now for our RHEL users, who have been promised a stabler upgrade cycle.
(For our Debian systems, in contrast, the drive to upgrade (when a new release comes out!) is to have access to the vast new supply of native packages.)
As for our Mac OS X users, they are the quickest to jump on new releases. Why? I think it's because Apple promotes their new releases with lots of new user features: utilities, non-disruptive appearance tweaks, and speed improvements. I can't emphasize the latter too much: each release of Mac OS X has made it faster, and this is a big reason for a scientist (or a ordinary end user, for that matter!) to upgrade.
It's been said that Microsoft's chief competition today is itself, five years ago -- that is, rather than contending for market share against Apple, Red Hat, or SuSE, each new re
M. Greenblatt appears to be unable to discuss any actual advantages of the Ingres database software. Instead, he resorts to smears like this one against existing open-source competitors to his product. Naturally, since he is answering a question about existing enterprise open-source database systems, to deny that they exist is nothing more than lying.
Moreover, it's a lie that simply will not be believed in this forum, where the audience is already much more familiar and comfortable with these competitors than with Ingres. So why bother lying? When a person lies even when they know that they will not be believed, it suggests that there is something seriously the matter with them.
Actually, the language that Graham is most associated with is Common Lisp, which is neither a small nor an interpreted language. It is relatively large for a Lisp dialect (much larger than Scheme), and a compiler is part of the specification.
(I'm not counting Arc, since it doesn't exist yet.)
In each case, SPF doesn't actually prevent the malicious user or clueless operator from causing you the damage he can cause you now. Why then should you bother to support it?
Being seen as doing something is good enough reason for Microsoft. They'll take any chance they get to be represented in the media as part of the solution when everyone in the trenches knows they are the root of the problem -- nets of worms, preferred system of trojans, spawner of zombies.
But the workaday operator, you and me -- that lie just sits wrong with us. We give a damn about the system we work all day to maintain. We give a damn about our fellows at other sites who have to deal with the same freakin' virus and spam bullshite we do. We shouldn't give our nod to flashy systems that our own experience and knowledge prove have no chance of working to solve the real problem.
Forgery is a failing of the current mail system, yes. But it is not responsible for spam, and spam crime can operate gleefully without the kind of "forgery" that SPF attacks. I know that users aren't always 100% happy with tough-on-spam answers like greylisting and blocklists, but those are the ones that work. Why waste time on junk like SPF that gets headlines but doesn't actually inconvenience the spammers at all?
First off, it hasn't happened yet. Nothing has been proven to work here, since they haven't actually done anything yet.
Second, SPF doesn't stop spam in the long run. SPF does not even address the problem of spam per se -- it addresses email forgery, and that not very well. In the unlikely event that every email system everywhere implemented SPF restrictions, spammers would still be able to send spam. They simply would not be able to send it under forged addresses in domains that publish restrictive SPF records. They could still send forged spam under domains that cannot (for their own reasons) use highly restrictive SPF, or they could send spam under their own domains.
(Yes, spammers have their own domains. Usually lots of them -- domain registrars' "bulk register" systems allow them to get LOTS of them easily. The registrars get their money, so most of them don't care that the domains are being used for spamming and the contact information is bogus.)
SPF is a case of "solving the wrong problem". The patient has a broken arm, but the quack doctor does not know how to set bones so he gives the patient an aspirin. But the patient's problem is not basically that he is in pain, but that his arm is broken -- the quack is solving the wrong problem.
The Internet's email system basically does not have a forgery problem. People who need to send each other forgery-proof email are already able to do this using systems like PGP. The email system does, however, have a spam problem. Though a good deal of spam is forged, the spam problem goes deeper than forgery. If SPF is widely deployed, spammers will just work around it ... just as they worked around the closing of SMTP open relays by deploying zombie viruses.
The spam problem is today one of ISP accountability, not email forgery. Spammers do their thing, and when people come around to complain, spam-friendly ISPs shine them on. No joke -- take a look around the Spamhaus Project, where professional researchers have tracked down the ISPs that do the most to help spammers.
SPF isn't the solution to spam. SPF isn't even the solution to forgery. But it makes nice headlines. People who want to look busy, and look like they are Doing Something to solve a nasty problem, sometimes don't care if the Something they're Doing is actually effective at all.
(Besides, honestly, why would you expect a company which itself sends spam for hire to actually try to stop spam? Microsoft bCentral operates some legitimate mailing lists, but it also allows its list operators to send unsolicited "opt-out" spam. This is an archive of reported spam sent using bCentral facilities.)
Different suppliers report vulnerabilities differently. Consider every "cumulative update" you've seen, and every "multiple vulnerabilities in $product" advisory from CERT. A supplier which is more honest and meticulous about vulnerability reporting may have more advisories but better security -- while one which batches up several bugs in a single advisory will underreport.
A system which includes more software may have more advisories, even though most advisories do not affect most computers running that system. In Windows, a database server is a separate product whose advisories would not be counted against "Windows". Many Linux systems include at least two database servers, but they are not turned on by default. If a hole in MS SQL doesn't count against Windows, should one in mySQL count against Red Hat?
Unpatched vulnerabilities may go for months without the release of an official advisory. For instance, a number of holes in Internet Explorer have been known and discussed within the security community well in advance of any official advisory from Microsoft.
Systems which have better default system-wide security settings (e.g. packet filtering, services turned off by default) may have all kinds of "vulnerabilities" that can't actually be exploited. For instance, Mac OS X includes OpenSSH, but it's turned off until the user asks for it. A hole in OpenSSH cannot be exploited on a default-install Mac system.
Leaving it up to the supplier to decide if something is a "vulnerability" or a "feature" leads to underreporting. Take CD autorun, for instance, which allows the installation of spyware when a (mostly-)audio CD is inserted into a Windows PC. A security-conscious user regards this as a vulnerability, but the supplier regards it as a beneficial feature.
Some of the most common attacks -- such as viruses -- rely on social engineering, and on "features" that are not classed as "vulnerabilities". However, these attacks are also more prominent on some systems than on others. Any comparative assessment of security which discounts the most common attacks blinds itself to a wide segment of the security landscape.
Actually, it isn't. Before Gopher, people found Internet resources by being told about them, or reading about them in mailing list posts, FAQs, or the like. For Internet users with Usenet access (Usenet was not originally an Internet service) there were regularly-posted lists of public FTP sites. There was also Archie, a search engine with which FTP site operators would voluntarily register their sites to be indexed.
Mass portscanning would have then been unacceptable not only because of the intrusion, but because of the traffic. Scanning 1024 well-known ports on 254 possible hosts on a Class-C network involves sending something like 2 MB of traffic. Multiply that by several target networks and you get quite a bit of traffic for the days of 14.4kbps modems and 56k leased lines. It would take hours, and consume expensive bandwidth that would be better used by real applications.
Most publications have advertising standards. They will not accept advertisements which do not meet these standards. You can get ad space in The New York Times to promote your product, or to set out your political position, or to call for a boycott, or to celebrate your wedding. You cannot get ad space in The New York Times to call someone by a derogatory racial epithet. You cannot get ad space in The New York Times to propound a claim that the editors know to be maliciously false. You cannot get ad space in The New York Times to advocate violence against women.
I suggest that a useful outcome of this controversy would be for Linux- and free-software-related Web publications to adopt strong advertising standards. These standards need to embrace not only basic standards of respectable public conduct (as in the examples above) but also a clear respect for the free-software and open-source world. They should refuse any advertisement which is, at its core, an attack upon free software and open source. It is wrong for publications which derive their livelihoods from free software to allow their visibility to be used to harm it.
The FS/OSS world is closely coupled to the public discourse about software. Many free-software developers are motivated not by profit but by art, personal need, and the perceived interests of their fellows. Public and professional discussion about software has always informed free-software development. We see this in the early discussions of software freedom and the rise of Project GNU. We see it in the collaboration which brought forth Linux -- collaboration mediated by discussions on Usenet and mailing lists. We see it when projects today fork (or merge) on the basis of public statements of animosity or admiration. Software is speech (as was confirmed in Bernstein v. United States) and the open-source world is uniquely close to this fact. This is why we hate lies about our work: because our work is about information, and spurred on by meaningful collaboration; deception is the opposite of these things.
It's not just us, either. Professionals in any field are revulsed by misinformation about their field. Climatologists have expressed little but disdain for the movie The Day After Tomorrow. Medical doctors hate quackery. Lawyers mock bad law advice. Sex educators despise the myths which lead teenage girls to try douching with Coca-Cola to prevent pregnancy. How much more is this in a case in a field whose lifeblood is information itself? An innocently false statement is a bug; a lie is a deliberately planted backdoor.
Advertisements which present falsehoods about open-source software should not be accepted -- not by Linux Today, not by Slashdot, and not by any other publication which lives by free software. It would not be too extreme, I suspect, to banish any advertisement whose focus is an attack on any piece of free software / open source, or one focused on attacking the idea of free software itself.
Sure, Mr. and Ms. Open-Source Publications, take ads from Microsoft. Take ads promoting a new version of Windows; or the latest Xbox game; or the C# language. But don't take ads that mislead, that say "Windows is cheaper than Linux"; don't take ads that propound SCOX's libels, even by sulfuric little hints; don't take ads that harm the community whose existence and whose contributions make your publication possible.
There may be two problems here -- one personal, and one more technical.
First, Unix people may read "cryptic" as a slander, and others may use it as such as well: for "cryptic", read "obfuscated". The slanderous implication is that programmers make complicated interfaces for no good reason -- or specifically for a bad reason, such as to maintain prestige or "job security". This is, or at least feels like, a personal attack: "Computers are not inherently hard to use. Computer nerds have deliberately made them hard to use, in order to hurt me. Therefore, my inability to use computers productively is not due to my own refusal to learn; it is, rather, due to their malicious action."
Second, the unexpressed alternatives to "cryptic" may well be "verbose" and "dumbed-down", and being cryptic may be the least of these three evils. A syntax appears cryptic when it tries to represent a large amount of complexity without requiring a large amount of typing. For a powerful syntax which prefers verbosity over crypticity, see COBOL -- by all reports a capable programming language, but one that few wish to use because it requires you write ADD 1 TO X GIVING X where C has x++;.
If one wishes a system to be neither verbose nor cryptic, the only option is to dumb it down: to remove capabilities which can only be represented with complicated expressions. Most Unix programs are far more powerful than their Windows analogues; you can do much more with the find command than you can with Windows' GUI equivalent.
Most Unix programmers choose likewise: if one has the choice to be either dumbed-down, or verbose, or cryptic, one should choose the last of these. Why? Of the three, the cryptic (but not maliciously obfuscated) system is the one which most rewards learning. Becoming an expert in a dumbed-down system is no great shakes: you can't do much more than the novice can, because all the system's functionality is geared towards the novice. Becoming an expert in a verbose system gives you power, but you have to wear your fingers down to stubs. Becoming an expert in a cryptic system allows you all that power without so much pain.
Take a shot. Some design criteria you should keep in mind:
- People need to be able to send messages to people they don't know, and have no common contacts with. A system which relies on "introducers" can be layered on top of a more open system (think PGP) but is not adequate alone. If one user can't send email to any other off-the-cuff, you lose, since people will have to resort to SMTP when they need it
... and if they have to do that, why use your system?
- Sites require their own servers, and no dependence on a central authority to process messages. They can choose to delegate authority over filtering (as with DNSBLs) but it can't be a requirement. If you (the system's creator) or any other power (say, Verisign) can monitor, censor, or shut off anyone's email, you lose -- why should General Electric trust your system?
- A new mail system must support gateways to SMTP. After all, SMTP would never have replaced UUCP, BITNET, and Fidonet mail if it had not been able to gateway to them. (If the only mail system you know about is SMTP, you don't know enough to build a new mail system.) These gateways must not themselves be easily abusable, or users of SMTP will reject mail from them. If that happens, your gateways get kicked off their ISPs for being spam sources, and you lose.
- A new mail system must offer its early adopters immediate benefit. If a new system doesn't offer real benefits until 51% of the world is using it, then no more than 0.1% will ever adopt it. If the only way your abuse-proof protocol is abuse-proof is to reject email from the whole dirty SMTP world, you lose.
- The standard must be a single open protocol, not a single implementation. Developers must be able to implement that protocol on disparate platforms on all different scales. Any implementation conformant with the standard must be able to talk to any other. Handing the world a Perl script and saying "this is the new email system" means you lose -- most people don't have Perl on their Windows and Palm systems and aren't going to install it to try out a new mail system.
Think you're up to it? Go for it. You have nothing to lose, right?It is a category error to treat spam as a software bug rather than as human misbehavior. It's true that technical measures can reduce or ameliorate the spam problem, just as technical measures such as locks and sturdy vaults can reduce or deter robbery. However, that doesn't make spam (or robbery) a technical rather than a behavioral problem.
There is no technical fix for spam. Real fixes for the spam problem must take place on the human level: enforcement of laws against spam and spam-related computer crime; refusal of connectivity to spammers and spam supporters; boycotting of firms which spam or benefit from spam.