I've known folks whose workplaces used to pay Sun a license fee for Perl... the same Perl you could download for free (as in beer); and yes, the same Perl that is one of the usual examples of successful free (as in speech) software.
No, they didn't get tech support. They didn't get to file bugs against Perl that would be resolved by a Sun engineer. They didn't even get a custom build of Perl optimized for their Sun hardware. They didn't even get a CD. What they got was an invoice... precisely what their company's IT procurement process required.
It's idiotic, but there is in fact a market for nothing: if you are correctly positioned as a trusted supplier, there are cases when you can get paid for delivering no product at all, but merely for carrying out the ritual of delivering a product, with all the paperwork thereunto appertaining.
Freedom of speech and of the press; freedom of religion and assembly;
freedom to speak your mind without fear of governmental violence of
any sort. Can't say it too many times: expression is sacrosanct.
Right to keep, control, and protect one's own property. The rights
of physical property owners to control devices in their ownership
reaffirmed over and against claims by "intellectual property" owners.
You don't get to scramble my hard drive just because you think maybe
I'm a pirate.
Domestic espionage upon political rivals by government agencies,
or other use of law enforcement powers for political gain, declared
to be a "high crime" removing the perpetrator's right to run for office
or occupy any government position.
Protection from unnecessarily destructive or disruptive searches and
seizures. Disallow seizure of property when access to information is
sufficient for law enforcement purposes: if you need a copy of a
public Web site, you take it with "wget" from a secured and audited
computer certified to be part of the evidence chain, not by seizing all
the owner's computers, stereo, and video game systems too.
Right against self-incrimination extended to passwords, crypto keys.
Right to technically competent counsel in criminal cases where the
details of technology are directly pertinent to the case.
Namely when the pet shop owner finally acknowledges that the parrot is dead but before he agrees to have it replaced, he could have said something like - "I don't know how that could have happened. That parrot never did that while we had it." In that case it would have been similar to the Greek joke, but it would have stretched the Monty Python sketch a bit out of it's flow.
Yes, it would -- because the funny part of the Monty Python sketch is that it's basically about trying too hard.
The shopkeeper is trying to convince the patron that everything is all right, that he doesn't need to make a fuss. He is a bit of a cheat in that he sold a dead parrot as a live one, but likewise the customer is a bit of a fool for buying it. But by the middle of the sketch it is clear that the shopkeeper is merely trying much too hard to recuperate a failing social situation: the patron is not going to be fooled again, and the shopkeeper's desperate, inventive, and doomed attempts to maintain a polite and friendly atmosphere, while continuing to insist that nothing is wrong (that the parrot is alive) are much of the humor.
For the shopkeeper to admit that the parrot is dead, as in the Greek joke, would be to spoil the scene.
(I get the sense that many Python fans think the sketch is about the patron's widely-quoted rant. I disagree.)
A lot of Monty Python is like that: the humor is in how a perfectly ordinary and unfunny event becomes an outrageous farce after something goes very wrong, because someone in the situation simply refuses to admit that anything is out of the ordinary. It's all about how pretending that everything is okay makes you into a total buffoon.
There are not just two kinds of programming languages. There are a whole bunch of different features that languages can have, that affect how programmers think about problems. I mentioned a few of them above, but consider:
Extensible syntax. Some programming languages have extensible syntax; they allow you to define macros or "parsing words" that act like new syntactic constructs. Lisp is the usual example here, but some of the stack-based languages, like Factor, also have this property. C++, Java, and Python do not have it. Extensible languages allow programmers to create embedded domain-specific languages, moving the language's syntax closer to that of the problem domain.
Type system differences. This isn't just static vs. dynamic typing, either. In Haskell, you create types that describe the meanings of the values your program will manipulate. In contrast, C++ programmers usually use types just to describe the implementation of data structures in memory. In Common Lisp you can talk about "the type composed of integers from 0 to 10".
Density and function length. Languages that are very dense and do not have a lot of syntactic sugar tend to encourage very small functions. Languages that are more verbose tend to encourage longer functions, if only because it takes more words to get an idea out.
Object system. There are many kinds of object-oriented languages: prototype-based ones like JavaScript, static ones like C++, multiple-dispatch ones like Common Lisp, and so on. Interfaces? Multiple inheritance? Mixins? Around methods? MOP? The presence or absence of these features greatly influences how you can use objects in a program.
These are not minor differences. They dramatically change the way that you have to approach problems in order to write good code in a language. If you write Common Lisp as if it were C++, you are going to be producing bad code. If you write functions in Haskell that are as long as the ones you'd write in Java, you are going to produce incomprehensible code.
Your programming skills should not be tied to the language you use.
Anyone who thinks this doesn't know very much about the diversity of programming languages, I suspect.
What you say may be true about a restricted set of languages: I would expect a good C++ programmer to be readily able to learn C# or Java; likewise I would expect a Python programmer to be readily able to learn Ruby. But that's because C++ and Java are not very far apart, nor are Python and Ruby.
But there are plenty of good C++ or Java programmers who would be completely lost in Lisp or Haskell. Why? Because a good Lisp or Haskell program does not break the problem down along the same lines as a good C++ or Java program. They involve a different set of skills. C++ coders do not tend to think of programming as extending the language to fit their problem space; they do not tend to use higher-order functions; they do not necessarily isolate I/O from core algorithm as Haskell programmers must; and they don't have access to anything even remotely resembling Lisp macros.
Now, you might say that a person is not a good programmer unless they have mastered a wide range of languages with vastly different approaches. But that's a much higher bar than most folks would use to qualify programmers.
Of course, the Wikinews article was not deleted prior to publication. All Wikinews articles, even ones in development, are accessible by the public, and are therefore "published" in the sense of the law. Articles in development are simply not placed in as prominent of positions on the site as those which are considered to be finished.
The claim that the Wikimedia Foundation exerts pre-publication control over Wikinews articles is therefore false. Merely because the Wikinews site may refer to some publicly-accessible articles as "published" and other publicly-accessible articles as "in development" does not change the fact that both classes of articles are, for legal purposes, published: that is, intentionally placed in the public view.
Re:Excession and Look to Windward?
on
Matter
·
· Score: 1
Excession seems to be the lightest of the Culture novels: the hyperintelligent Minds are played as a bunch of squabbling aristocrats, and the obligatory cruel aliens are so over-the-top that they come across as caricatures of fox-hunting Brits rather than the moral horror of the Azad apices in The Player of Games or the outright threat of the Idirans. When the Culture ambassador chooses to join the Affront, it comes across as a rather goofy case of "going native" rather than a morally culpable decision to choose cruelty.
But as a result, I can't imagine it would work very well as an introduction to the setting: it's almost a self-parody of the setting.
All in all, the only Culture novel I haven't yet been willing to re-read -- because it's too disturbing -- is Use of Weapons. I don't think there's a single reference anywhere in fiction that gives me the same sense of revulsion as the word "Chairmaker".
Trust simulation and purpose-blindness
on
Ethics In IT
·
· Score: 5, Interesting
The point of authorization systems (like user permissions on a Unix system) is to simulate and thereby enforce the trust relationships that people have with regards to data. You aren't allowed to read my email, so you don't have read access. You're allowed to use a certain amount of disk space, so there's a quota.
But here's a problem: Technology is purpose-blind. It doesn't know for what purpose you're trying to do a particular thing -- only whether you've got access to do it. However, in the real world, we frequently want to trust someone with a particular resource, but only for certain purposes.
You're allowed to drive Daddy's T-bird to the library, but not to the hamburger stand. But the ignition system doesn't know that; it just knows you put the right key in. Your sysadmin is allowed to read your email files if she thinks something's wrong with the mail server, but not just because she thinks you're cute and wants to stalk you. But the permissions bits don't know that.
You're allowed to access Scientology's Web page to read it, but not to repeatedly reload it just to put load on their server and run up their bandwidth bill. But neither your browser (or wget) nor their server necessarily understand that.
So there's an ethical problem: you frequently have access to things for only certain purposes. How are those purposes defined and agreed on? Is it possible to make authorization systems more purpose-aware? Would that even be desirable, or would it just cause problems with unexpected situations?
Suppose Daddy's T-bird only allows you to drive to the library, by shutting off the engine if you try to go somewhere else... and Daddy has a heart attack and you need to get him to the hospital. Down that road lie DRM and other systems that decrease the value of technology by getting in the way of legitimate uses.
I am "unauthorized" to walk around town or drink my coffee. Nobody, certainly not the RIAA, has granted me any permission to do so. However, I also require no authorization.
This is the important thing to learn here: when someone says you have no permission to do something, ask yourself whether any permission is needed. You need nobody's permission to exercise your rights. As soon as you accept the lie that you do, you're lost.
The question then is; how did somebody at Sony arrive at the conclusion that they should try to protect their IP right in this manner?
This is probably not best discussed in terms of "protecting IP rights" but rather in terms of:
Individual decision-makers in the organization trying to protect their own personal interests (cover your ass, look busy, do something!);
An interest in seizing control (squatting, adverse possession, invasion) of the user's desktop, in order to use that as a foothold to greater control over the medium;
High-pressure and deceptive sales tactics by the spyware makers.
Someone at Sony was charged with "doing something" and "making the piracy problem go away". They were desperate. They also wanted something to show for their efforts, namely, an ability to exercise power on user desktops. (Recall, the copyright terrorists have long wanted "self-help" capabilities that amount to sabotaging users' property at will.)
Spyware must have seemed like a perfect solution: it doesn't just "do something" about the pirates, it accomplishes a long-standing goal of seizing greater control of the medium. It is not at all about "IP rights"; it's about power -- in this case, about ripping power out of the users' hands.
As a computer technician I'm sure you've encountered cases before where a user asks you, "How do I do thus-and-so?" when really they're looking to accomplish some goal only tangentially related to what they're asking. Maybe this is best treated as the same sort of problem.
What is the user actually trying to accomplish? Is she worried that her son will become some kind of sex fiend? It's too late -- to paraphrase a line from Buffy, even linoleum makes teenage boys think about sex. Is she concerned that he'll get bad ideas about sex from Internet porn? Maybe some sex education is needed: "Son, just so you know, real women don't like bukkake gang-bangs. They like hugs. And clitoral stimulation too, but hugs first." Does she just have moral or ethical objections to porn in general? Maybe she should be talking about her values with her son a little more.
No matter what the problem is, it's almost certainly a social and educational one, not a technical one. Deploying a technical solution is probably not the answer.
Don't oversell. Linux is not a cure-all, and it is not something that most people can pick up overnight. Depending on your hardware, your chosen distro may not work right out of the box. But you can try it risk-free (with any number of live CDs) and you might like it.
Linux is not a Windows replacement. It is the same general kind of thing as Windows, but in many ways it's as different as a motorboat is from an SUV. If you're really into Windows and understand it well... you should recognize that you've spent a lot of time and effort gaining that ability. Windows is not "intuitive", and neither is Linux; to get really good at it, you will need to acquire a different set of skills. However, you can do it; you learned one complex and funky system and you can learn another.
"Good" and "easy" and "functional" are not scalar values. There are things that are much easier to do in an open-source environment (be it Linux or just OpenOffice on Windows)... like making PDFs, or browsing the Web safely. There are other things that are harder, like printing to cheap printers or playing commercial games.
The real long-term benefits will take a while to show up. The big one is that with Linux, nobody is deliberately trying to get in your way, to make you spend money, to take over your life. There is no DRM; there are no registration codes; there is no "genuine Windows verification". There is no spyware. You don't get out of having to do software upgrades... but they're a lot less likely to hose you, and they will never be intended to hose you.
My first job was for a small -- very small -- college. The IT department didn't have money for things like proper servers. We had cheap-ass desktop PCs stuck on a shelf in the one air-conditioned room in the office. Most of them, we built ourselves from the cheapest parts we could find -- usually, the corpses of broken workstations. The really important servers even had a UPS.
The machine with the user accounts on it had a few more hot, high-speed disks than the case was really designed to keep cool. It got hot and beeped. My boss wouldn't consider replacing it or even getting a new case. So I was forced to improvise: I cut a hole in the front panel and fitted a spare case fan into it. Then I realized that the motherboard didn't have another power connector for the case fan... but I had a spare 5V wall-wart. A little wire-cutting and electrical-taping later, I had an externally cooled disk bay.
That "machine room" sucked. It was in the corner of the basement of a college office building. In the winter, the (crappy, household-type) AC unit iced over and the servers overheated. One summer, the facilities staff decided to power-wash the wood siding of the building. High-pressure water ran up through the wall and rained down right onto the server shelf. The only thing that blew up was the fancy new monitor that had come with the expensive and utterly overpowered RS/6000 just purchased by the library.
A couple of years ago when I visited the campus, they were still using that wall-wart-powered fan to cool the disks....
Does the Internet's favorite DBMS have an IP address datatype yet?
How about MAC address? CIDR block?
"An IP address is just a 32-bit unsigned int, duh. Any DBMS can store those."
Wrong. A datatype isn't just about storage, but also about operations. In PostgreSQL, when you do a SELECT across a table with IP addresses in it, you get them formatted and displayed as IP addresses, not as opaque ints. Likewise with CIDR blocks, like "192.168.42.0/23". There's also a comparison operator for asking whether an IP address is within a CIDR block.
If you're implementing a network registration system or an incident logging system, how much of your time do you want to waste staring at opaque ints like 3232246272 rather than IP addresses like 192.168.42.0 when you're trying to debug it?
MySQL is a bimbo, a fratboy: it's easy, but so shallow! The amount of time you save in one-time setup, you will lose many times over in all the little annoyances and deficiencies of a DBMS that was originally designed by folks who didn't really believe in DBMSes. Over time they've slowly been shamed into including many of the features they used to despise: transactions, relational integrity checks, and so on. But there's still so much missing... not just essential integrity features, but little fiddly bits like good datatype support, the kinds of things that make your life easier (as a programmer or as a DBA) in the long run.
A millennium is mille + annus: a thousand years.
A millenium is mille + anus: a thousand assholes.
If you get it wrong, you're anal; if you get it right, you're annual.
Re:"splice" - because Microsoft did it?
on
Linux 2.6.17 Released
·
· Score: 2, Informative
"Zero copy" tends to be overrated. It makes some benchmarks look good, but it's only useful if your system is mostly doing very dumb I/O bound stuff. In environments where web pages have to be ground through some engine like PHP before they go out, it won't help much.
On the contrary, there are many cases in a dynamic serving system where you can determine that, after some point, the rest of the operation merely involves copying data from a file or buffer out to the network. Or, similarly, that a large portion of the operation involves such copying.
So even though the whole operation can't be reduced to a splice() or sendfile(), a substantial portion of it can. And the speed improvement you take isn't just that you avoid copying -- as "zero copy" implies; you also avoid unnecessary cache dirtiness.
The usual effect of adding "zero copy" to something is that the performance goes up a little, the complexity goes up a lot, and the number of crashes increases.
I wonder what your sample size is for "usual" there. As far as I can tell, you discuss only one case where this is so: Windows. And since we know that Windows has lots of other architectural problems leading to crashes, and in any event has an architecture entirely different from Linux's, we know that case to be irrelevant.
All in all, your analysis is critically, embarrassingly bad. There is no "serving Web pages from the kernel" going on here. There is simply an optimization for a common case, with no degradation to the less-common cases -- that's why it's implemented as a separate system call.
Re:No one notices a well done security job...
on
Security's Shaky State
·
· Score: 4, Insightful
Likewise, the security side of an I.T. department is the sort of job that is hard to justify to people who assume that if they don't notice results, the job isn't really doing much.
Here's a possible fix for that situation: Document and present to your bosses the nature of what you are preventing.
Gather information about sites that are less fortunate or less competent than your own. Make sure that your boss knows when your competitor's Web site gets vandalized, or when some well-known business starts spewing out virus spam. Provide information about the specific techniques that you used which kept that from happening to your site.
"In May of 20x6, businesses and home users across the Internet were hit by the Quigmorf worm, which was reported on the front page of the New York Times as causing $25 billion in damage. Our mail server anti-virus filtering rejected an average of 16 copies of this worm per second over the worst day of the outbreak."
Disseminate periodic alerts about viruses that have stricken other sites, but which your own defenses are ably filtering out. Couch these in the language of protecting your users from threats they may face on other (and hence lesser) networks.
"This Monday, Snarkashvili Anti-Virus discovered a new virus known as 'Quigmorf'. This virus infects Windows systems by sending email messages with a subject line of 'I love Quigmorf, click here to see why!' Infected systems become very slow and send out thousands of viruses to other email users. While our mail server anti-virus program is blocking Quigmorf, your home ISP may not be. Be sure to delete any messages with this subject line without opening them."
Instrument your systems. Gather logs and present them in understandable form. Bosses know what a quarterly report is, and they can understand claims such as:
"In 4Q05, our mail server blocked an average of 100 spam and 50 viruses every minute. This is a 25% increase over last quarter, and a 50% increase over last year. Spam complaints to spam@oursite.net are down by 65% over last year on a total email volume of 30% more messages. We attribute the improvement to the free open-source anti-spam and anti-virus programs that we installed last quarter."
If worse comes to worst, you could always try talking time and money:
"Our mail server blocks 100 spam every minute -- all day, every day; during working hours and after hours. It takes approximately 3 seconds for an employee to look at a message, recognize it as spam, and press the Delete key. This means our mail server does the work of more than twenty full-time employees dedicated to doing nothing but deleting spam."
It's true! (100 spam / minute) * (1 minute / 60 sec) * (3 person*sec / spam) = 5 person, but a person only works less than 1/4 of the time (8 out of 24 hours, 5 out of 7 days) whereas a mail server works 24/7.
Finally, my feeling as a teacher is that I do have a right to ask students who are losers not to distract from the educational experience of the people who are really there to learn.
Exactly. I don't have much patience for the "I'm paying for it, so I can waste it" crowd.
Here's an analogy. Suppose that you join a chess club, where you pay dues in exchange for being hooked up with two chess matches every weekend. Then someone joins who's willing to pay, but doesn't really want to play chess -- they show up at their assigned match, then goof off, juggle the pieces, and forfeit the game. By the "I'm paying for it, so I can waste it" logic, they're not doing anything wrong. But, of course, they are -- they're ripping off the person they're playing with! That person paid for a chess match, not to watch someone goof off. The chess club would be right to kick the goof out... and would be wrong if it failed to kick them out.
The same is true in colleges. Students aren't just paying for the opportunity to listen to lectures and take tests. In any properly functioning educational setting, they're paying (in part) to participate with other students. So any one student who chooses to goof off thereby diminishes everyone else's education... and professors and colleges are right to have standards for student behavior, and to kick out students who want to goof off in class.
This isn't to say that colleges should be fascistic. Monitoring student Internet access and handing out demerits is a stupid idea. But professors should take the lead in setting some standards in the classroom, correcting or ejecting students who want to goof off... and (just as importantly) administrations should support them.
Advertising executives, recording industry flacks, and marketers are more likely than high school or college students to abuse their spouses or children, to be long-term (10 years or more) alcoholics, to be involved in health care fraud, or to rape or sexually assault their maids or nannies.
Now, most people would consider rape and domestic violence to be more severe offenses than copyright violation. So clearly there needs to be much greater law-enforcement attention paid to the high-risk demographic categories of advertising executives, recording industry flacks, and marketers.
Actually, default deny is just as stupid as default allow, as if you have default deny, people just get sick of being asked if they want to allow something, and end up clicking "yes" on every box they see.
Default deny makes more sense when you think of it at the organizational level -- like a firewall. Both default deny and allow mean that you have to respond to new needs... but default allow means you have to respond to new attacks (by blocking them) whereas default deny means you have to respond to new user needs (by allowing them). I've operated both sorts of firewalls -- and when you are in good communication with your user base, default deny is both more reliable and MUCH LESS WORK.
So you want to write a virus scanner that somehow can recognise viruses without being told which programs are viruses.
Ah... you didn't read the article, did you? Every program that's running on your system that you didn't authorize to be there, is a problem. It doesn't matter if it's a "virus" or not, or if it's on Symantec's bad-guy list yet. Consider the following dialogue I had with a Windows technician:
Me: Windows host foo.example.org is cracked. It's portscanning out and trying to break into things. I've blocked it off the network.
Tech: I just ran an anti-virus scan on foo, and it didn't find anything. The user wants to get back to work; please put it back on the network.
Me: I didn't say it had a virus; I said it was scanning out and trying to break into things. It's still trying to scan out. I'm not going to put it back on the network.
Tech: Antivirus software says clean!
Me: snort says scanning out!
Tech: Antivirus software says clean!
Me: tcpdump says scanning out! Go get Clueful Tech to look at it.
Clueful Tech: Oh yeah, it's got all these processes called "fuck.exe" running. It's hosed. I'm reinstalling it.
Me: Thank you, Clueful Tech.
If you need antivirus software, your problem is not viruses -- it is that you don't have any control over what programs are getting to run on your computer. Get that control, and you don't need antivirus software.
So you are saying we should write code without bugs and holes? What a great idea that is? why did no-one think of saying that before?
Anyone who tells you that all software has bugs is being honest. Anyone who tells you that all software is equally buggy is trying to sell you Microsoft IIS. We can go a long way towards "code without bugs" just by observing the history of software and going with those options which have proven to need much less patching in the past.
We can also -- and more importantly, I think! -- favor software that is architected in such a way as to minimize security exposure. That means privilege separation and least privilege. Running your Web server as root is a brain-dead idea. It means not using more complicated software than you need -- if boa or publicfile serves your needs, don't use Apache.
You think people should learn how to stop hacking and intrusion without learning how existing hacks work?
It's interesting, but it isn't essential to the job. What you need to know is that attacks work by exploiting mistakes in the design and implementation of programs. What you need to know about buffer overflows, for instance, isn't how to exploit one for fun and profit -- but rather, that any C program that uses gets() is broken... and that programs written in higher-level languages that have checked strings can't suffer from them.
There is a place that I've found that "hacking knowledge" is useful -- in demonstrating incontrovertibly that a problem exists. Joe Moron has a Windows-based embedded print server that's vulnerable
"Information wants to be free" was not originally a rallying cry to advocate the freedom of information. Rather, it was a statement along the lines of "Water wants to flow downhill" -- an observation; a statement of what is, rather than what should be.
In what sense does information want to be free? In the sense that it is frequently very difficult to keep it bottled up! To keep water from flowing downhill we build water towers, dams, levees, and so forth -- we expend a great deal of effort to resist water's tendency to flow downhill. The same is true of many kinds of information.
If we wish to keep a piece of information private, we have to expend resources to protect it. This is as true if "we" are private citizens, or a government agency. Governments have to exert a lot of effort to deter people from leaking secrets -- for instance, in punishing people who do so; or denying access to reporters who publish "embarrassing" stories. This takes effort.
The same is true of personal information. As we go about our lives, particularly online, we effectively radiate all kinds of identifying facts about ourselves -- HTTP cookies, usernames, email addresses, browsing and shopping preferences, and so on. If we want to bottle up this information and keep it private -- or obfuscate it so that nobody can build up a profile of us -- we have to make some effort to do so.
When we say "information wants to be free" in an advocacy sense, what we may frequently mean is that for some classes of information, the cost of keeping them bottled up is too high -- economically, socially, or personally. For instance, one cost of keeping the facts about the rape of underage Iraqi girls at Abu Ghraib bottled up, is that many people place an erroneous trust in the U.S. Army that its soldiers will not rape underage girls. This erroneous cost is a social evil caused by information being kept unfree.
Anyway, isn't the idea that a good AI is indistinguishable from a female just a little bit.... sexist?
And it was proposed by a gay man, too. Turing had some preconceptions on which would be a more difficult test -- I think he assumed some traditional stereotypes about women being more emotional or social than men, meaning that imitating a woman should be harder than imitating a man.
For an amusing discussion of the Turing test and gender, see Douglas Hofstadter's "A Coffeehouse Conversation on the Turing Test" -- it's in Metamagical Themas.
I'm going to take that subject line in a completely different direction. The difference between an informal "standard" and a formal one is that conformance to a formal standard can be tested.
Indeed, that's what the word "standard" meant of old. A standard is a pole, a stick -- such as a flagpole, hence the term "standard-bearer". However, more usefully, a standard is also a measuring-stick. (Another word for a well-sized stick is canon, which gives us the word canonical, meaning correct or orthodox, as well as cane, a walking-stick.) The purpose of a measuring-stick is to see if someone or something measures up -- if it is standards-compliant. Standards equals testing.
A real IT standard spells out required behaviors of the implementation. In a standards-compliant C compiler, the function printf accepts certain formatting codes, and generates specified formatting therefrom. A C compiler which (say) inserts extra decimal places when formatting a floating-point number is not just wrong, but provably wrong. You can write a test suite based on the C99 standard that enumerates every possible printf formatting code, and tests that the implementation does the right thing.
A standard can also spell out what is at fault in a failure. The DNS standards spell out the consequences of lame delegation. The SMTP email standards spell out responsibility for message delivery -- if your mail server accepts a message from a sending system, it is required to deliver it or transmit a bounce message. If you reject the message, it is up to the sending system to transmit the bounce. If the sender complains that their mail was not received and they got no bounce message, an inspection of the server logs can show which system is at fault by being out of compliance with the standard. Again, testing is of the essence here: one system is measuring up; the other is not.
An informal "standard" is an invitation to arguments over what is "acceptable" behavior. A formal standard that spells out exactly what is to be sent over the wire (or recorded in the file, or accepted in source code) can still be a source of debate, but at least the participants can accept that there can be right and wrong answers.
We're going to need some basic trespassing legislation here: in brief, a recognition that my phone is my property and that your freedom of commercial speech does not extend to the use of my property to carry your speech at my costs.
However, we're also going to need some software tools. A lot of sites, my own workplace included, are rolling out VoIP systems. Some of these are COTS systems of various levels of quality. Others (like us) are using open systems like Asterisk PBX and SIP Express Router (SER). Currently, as far as I have seen neither the proprietary nor the open tools have what it takes regarding abuse rejection:
Dictionary attack rejection. Any caller who makes a vast number of wrong numbers in a day is just trying to guess numbers, and should be rejected.
Call rate limiting. A single caller IP address should not be able to make a vast number of simultaneous or near-simultaneous inbound calls.
Site-local blocklisting. One good way of telling if an IP address is going to spam me is if it has spammed the guy the next office over. The VoIP PBX is a good place to aggregate abuse information. Asterisk has the beginnings of a blocklist system, but it's not quite there yet.
Distributed blocklisting. DNSBLs have worked very well in the email world, where a single highly reliable list such as Spamhaus SBL-XBL can deflect over 50% of spam. We will need this ability in VoIP.
Abuse reporting. If I'm getting VoIP abuse from your site, I need a way to report it to you or your ISP. Likewise, VoIP sites that want to be reputable should offer call recipients a way of reporting harassment, spamming, and other sorts of abuse.
This past December, one of the engineers at my workplace gave a presentation on WINE. Since I'm the security guy, somone asked me if Windows viruses ran under WINE. So I tried three: Lovgate, a Mydoom variant, and a Netsky variant.
Lovgate simply exited without doing anything. Mydoom actually crashed WINE into its debugger. The Netsky variant, as the article describes (SomeFool is Netsky) actually ran. Moreover, it did a passel of DNS queries and actually tried to send e-mail (which was rejected). So, if that e-mail had been accepted, Netsky would have been able to propagate under WINE. As in the article, Ctrl-C proved necessary and effective.
To make a long story short, yes, some Windows viruses do run under WINE. Of course, you have to tell WINE to run them -- not exactly the social engineering that viruses are intended to do. However, as WINE gets more popular and reliable, I would expect that this will be more of a problem for people who choose to (e.g.) run Outlook in WINE.
(For what it's worth, WINE isn't the only way to run Windows viruses and worms on your non-Windows system. I've had to explain to users that yes, their VMware or Virtual PC system is quite capable of getting wormed, and that yes, they did need to do their Windows Update on that "virtual" Windows system, too.)
Slashdot Mirror
I've known folks whose workplaces used to pay Sun a license fee for Perl ... the same Perl you could download for free (as in beer); and yes, the same Perl that is one of the usual examples of successful free (as in speech) software.
No, they didn't get tech support. They didn't get to file bugs against Perl that would be resolved by a Sun engineer. They didn't even get a custom build of Perl optimized for their Sun hardware. They didn't even get a CD. What they got was an invoice ... precisely what their company's IT procurement process required.
It's idiotic, but there is in fact a market for nothing: if you are correctly positioned as a trusted supplier, there are cases when you can get paid for delivering no product at all, but merely for carrying out the ritual of delivering a product, with all the paperwork thereunto appertaining.
Yes, it would -- because the funny part of the Monty Python sketch is that it's basically about trying too hard.
The shopkeeper is trying to convince the patron that everything is all right, that he doesn't need to make a fuss. He is a bit of a cheat in that he sold a dead parrot as a live one, but likewise the customer is a bit of a fool for buying it. But by the middle of the sketch it is clear that the shopkeeper is merely trying much too hard to recuperate a failing social situation: the patron is not going to be fooled again, and the shopkeeper's desperate, inventive, and doomed attempts to maintain a polite and friendly atmosphere, while continuing to insist that nothing is wrong (that the parrot is alive) are much of the humor.
For the shopkeeper to admit that the parrot is dead, as in the Greek joke, would be to spoil the scene.
(I get the sense that many Python fans think the sketch is about the patron's widely-quoted rant. I disagree.)
A lot of Monty Python is like that: the humor is in how a perfectly ordinary and unfunny event becomes an outrageous farce after something goes very wrong, because someone in the situation simply refuses to admit that anything is out of the ordinary. It's all about how pretending that everything is okay makes you into a total buffoon.
There are not just two kinds of programming languages. There are a whole bunch of different features that languages can have, that affect how programmers think about problems. I mentioned a few of them above, but consider:
Extensible syntax. Some programming languages have extensible syntax; they allow you to define macros or "parsing words" that act like new syntactic constructs. Lisp is the usual example here, but some of the stack-based languages, like Factor, also have this property. C++, Java, and Python do not have it. Extensible languages allow programmers to create embedded domain-specific languages, moving the language's syntax closer to that of the problem domain.
Type system differences. This isn't just static vs. dynamic typing, either. In Haskell, you create types that describe the meanings of the values your program will manipulate. In contrast, C++ programmers usually use types just to describe the implementation of data structures in memory. In Common Lisp you can talk about "the type composed of integers from 0 to 10".
Density and function length. Languages that are very dense and do not have a lot of syntactic sugar tend to encourage very small functions. Languages that are more verbose tend to encourage longer functions, if only because it takes more words to get an idea out.
Object system. There are many kinds of object-oriented languages: prototype-based ones like JavaScript, static ones like C++, multiple-dispatch ones like Common Lisp, and so on. Interfaces? Multiple inheritance? Mixins? Around methods? MOP? The presence or absence of these features greatly influences how you can use objects in a program.
These are not minor differences. They dramatically change the way that you have to approach problems in order to write good code in a language. If you write Common Lisp as if it were C++, you are going to be producing bad code. If you write functions in Haskell that are as long as the ones you'd write in Java, you are going to produce incomprehensible code.
Anyone who thinks this doesn't know very much about the diversity of programming languages, I suspect.
What you say may be true about a restricted set of languages: I would expect a good C++ programmer to be readily able to learn C# or Java; likewise I would expect a Python programmer to be readily able to learn Ruby. But that's because C++ and Java are not very far apart, nor are Python and Ruby.
But there are plenty of good C++ or Java programmers who would be completely lost in Lisp or Haskell. Why? Because a good Lisp or Haskell program does not break the problem down along the same lines as a good C++ or Java program. They involve a different set of skills. C++ coders do not tend to think of programming as extending the language to fit their problem space; they do not tend to use higher-order functions; they do not necessarily isolate I/O from core algorithm as Haskell programmers must; and they don't have access to anything even remotely resembling Lisp macros.
Now, you might say that a person is not a good programmer unless they have mastered a wide range of languages with vastly different approaches. But that's a much higher bar than most folks would use to qualify programmers.
Of course, the Wikinews article was not deleted prior to publication. All Wikinews articles, even ones in development, are accessible by the public, and are therefore "published" in the sense of the law. Articles in development are simply not placed in as prominent of positions on the site as those which are considered to be finished.
The claim that the Wikimedia Foundation exerts pre-publication control over Wikinews articles is therefore false. Merely because the Wikinews site may refer to some publicly-accessible articles as "published" and other publicly-accessible articles as "in development" does not change the fact that both classes of articles are, for legal purposes, published: that is, intentionally placed in the public view.
Excession seems to be the lightest of the Culture novels: the hyperintelligent Minds are played as a bunch of squabbling aristocrats, and the obligatory cruel aliens are so over-the-top that they come across as caricatures of fox-hunting Brits rather than the moral horror of the Azad apices in The Player of Games or the outright threat of the Idirans. When the Culture ambassador chooses to join the Affront, it comes across as a rather goofy case of "going native" rather than a morally culpable decision to choose cruelty.
But as a result, I can't imagine it would work very well as an introduction to the setting: it's almost a self-parody of the setting.
All in all, the only Culture novel I haven't yet been willing to re-read -- because it's too disturbing -- is Use of Weapons. I don't think there's a single reference anywhere in fiction that gives me the same sense of revulsion as the word "Chairmaker".
But here's a problem: Technology is purpose-blind. It doesn't know for what purpose you're trying to do a particular thing -- only whether you've got access to do it. However, in the real world, we frequently want to trust someone with a particular resource, but only for certain purposes.
You're allowed to drive Daddy's T-bird to the library, but not to the hamburger stand. But the ignition system doesn't know that; it just knows you put the right key in. Your sysadmin is allowed to read your email files if she thinks something's wrong with the mail server, but not just because she thinks you're cute and wants to stalk you. But the permissions bits don't know that.
You're allowed to access Scientology's Web page to read it, but not to repeatedly reload it just to put load on their server and run up their bandwidth bill. But neither your browser (or wget) nor their server necessarily understand that.
So there's an ethical problem: you frequently have access to things for only certain purposes. How are those purposes defined and agreed on? Is it possible to make authorization systems more purpose-aware? Would that even be desirable, or would it just cause problems with unexpected situations?
Suppose Daddy's T-bird only allows you to drive to the library, by shutting off the engine if you try to go somewhere else ... and Daddy has a heart attack and you need to get him to the hospital. Down that road lie DRM and other systems that decrease the value of technology by getting in the way of legitimate uses.
I am "unauthorized" to walk around town or drink my coffee. Nobody, certainly not the RIAA, has granted me any permission to do so. However, I also require no authorization. This is the important thing to learn here: when someone says you have no permission to do something, ask yourself whether any permission is needed. You need nobody's permission to exercise your rights. As soon as you accept the lie that you do, you're lost.
This is probably not best discussed in terms of "protecting IP rights" but rather in terms of:
Someone at Sony was charged with "doing something" and "making the piracy problem go away". They were desperate. They also wanted something to show for their efforts, namely, an ability to exercise power on user desktops. (Recall, the copyright terrorists have long wanted "self-help" capabilities that amount to sabotaging users' property at will.)
Spyware must have seemed like a perfect solution: it doesn't just "do something" about the pirates, it accomplishes a long-standing goal of seizing greater control of the medium. It is not at all about "IP rights"; it's about power -- in this case, about ripping power out of the users' hands.
As a computer technician I'm sure you've encountered cases before where a user asks you, "How do I do thus-and-so?" when really they're looking to accomplish some goal only tangentially related to what they're asking. Maybe this is best treated as the same sort of problem.
What is the user actually trying to accomplish? Is she worried that her son will become some kind of sex fiend? It's too late -- to paraphrase a line from Buffy, even linoleum makes teenage boys think about sex. Is she concerned that he'll get bad ideas about sex from Internet porn? Maybe some sex education is needed: "Son, just so you know, real women don't like bukkake gang-bangs. They like hugs. And clitoral stimulation too, but hugs first." Does she just have moral or ethical objections to porn in general? Maybe she should be talking about her values with her son a little more.
No matter what the problem is, it's almost certainly a social and educational one, not a technical one. Deploying a technical solution is probably not the answer.
Linux is not a Windows replacement. It is the same general kind of thing as Windows, but in many ways it's as different as a motorboat is from an SUV. If you're really into Windows and understand it well ... you should recognize that you've spent a lot of time and effort gaining that ability. Windows is not "intuitive", and neither is Linux; to get really good at it, you will need to acquire a different set of skills. However, you can do it; you learned one complex and funky system and you can learn another.
"Good" and "easy" and "functional" are not scalar values. There are things that are much easier to do in an open-source environment (be it Linux or just OpenOffice on Windows) ... like making PDFs, or browsing the Web safely. There are other things that are harder, like printing to cheap printers or playing commercial games.
The real long-term benefits will take a while to show up. The big one is that with Linux, nobody is deliberately trying to get in your way, to make you spend money, to take over your life. There is no DRM; there are no registration codes; there is no "genuine Windows verification". There is no spyware. You don't get out of having to do software upgrades ... but they're a lot less likely to hose you, and they will never be intended to hose you.
The machine with the user accounts on it had a few more hot, high-speed disks than the case was really designed to keep cool. It got hot and beeped. My boss wouldn't consider replacing it or even getting a new case. So I was forced to improvise: I cut a hole in the front panel and fitted a spare case fan into it. Then I realized that the motherboard didn't have another power connector for the case fan ... but I had a spare 5V wall-wart. A little wire-cutting and electrical-taping later, I had an externally cooled disk bay.
That "machine room" sucked. It was in the corner of the basement of a college office building. In the winter, the (crappy, household-type) AC unit iced over and the servers overheated. One summer, the facilities staff decided to power-wash the wood siding of the building. High-pressure water ran up through the wall and rained down right onto the server shelf. The only thing that blew up was the fancy new monitor that had come with the expensive and utterly overpowered RS/6000 just purchased by the library.
A couple of years ago when I visited the campus, they were still using that wall-wart-powered fan to cool the disks ....
Does the Internet's favorite DBMS have an IP address datatype yet?
How about MAC address? CIDR block?
"An IP address is just a 32-bit unsigned int, duh. Any DBMS can store those."
Wrong. A datatype isn't just about storage, but also about operations. In PostgreSQL, when you do a SELECT across a table with IP addresses in it, you get them formatted and displayed as IP addresses, not as opaque ints. Likewise with CIDR blocks, like "192.168.42.0/23". There's also a comparison operator for asking whether an IP address is within a CIDR block.
If you're implementing a network registration system or an incident logging system, how much of your time do you want to waste staring at opaque ints like 3232246272 rather than IP addresses like 192.168.42.0 when you're trying to debug it?
MySQL is a bimbo, a fratboy: it's easy, but so shallow! The amount of time you save in one-time setup, you will lose many times over in all the little annoyances and deficiencies of a DBMS that was originally designed by folks who didn't really believe in DBMSes. Over time they've slowly been shamed into including many of the features they used to despise: transactions, relational integrity checks, and so on. But there's still so much missing ... not just essential integrity features, but little fiddly bits like good datatype support, the kinds of things that make your life easier (as a programmer or as a DBA) in the long run.
A millennium is mille + annus: a thousand years.
A millenium is mille + anus: a thousand assholes.
If you get it wrong, you're anal; if you get it right, you're annual.
So even though the whole operation can't be reduced to a splice() or sendfile(), a substantial portion of it can. And the speed improvement you take isn't just that you avoid copying -- as "zero copy" implies; you also avoid unnecessary cache dirtiness.
I wonder what your sample size is for "usual" there. As far as I can tell, you discuss only one case where this is so: Windows. And since we know that Windows has lots of other architectural problems leading to crashes, and in any event has an architecture entirely different from Linux's, we know that case to be irrelevant.All in all, your analysis is critically, embarrassingly bad. There is no "serving Web pages from the kernel" going on here. There is simply an optimization for a common case, with no degradation to the less-common cases -- that's why it's implemented as a separate system call.
Here's a possible fix for that situation: Document and present to your bosses the nature of what you are preventing.
Gather information about sites that are less fortunate or less competent than your own. Make sure that your boss knows when your competitor's Web site gets vandalized, or when some well-known business starts spewing out virus spam. Provide information about the specific techniques that you used which kept that from happening to your site.
"In May of 20x6, businesses and home users across the Internet were hit by the Quigmorf worm, which was reported on the front page of the New York Times as causing $25 billion in damage. Our mail server anti-virus filtering rejected an average of 16 copies of this worm per second over the worst day of the outbreak."
Disseminate periodic alerts about viruses that have stricken other sites, but which your own defenses are ably filtering out. Couch these in the language of protecting your users from threats they may face on other (and hence lesser) networks.
"This Monday, Snarkashvili Anti-Virus discovered a new virus known as 'Quigmorf'. This virus infects Windows systems by sending email messages with a subject line of 'I love Quigmorf, click here to see why!' Infected systems become very slow and send out thousands of viruses to other email users. While our mail server anti-virus program is blocking Quigmorf, your home ISP may not be. Be sure to delete any messages with this subject line without opening them."
Instrument your systems. Gather logs and present them in understandable form. Bosses know what a quarterly report is, and they can understand claims such as:
"In 4Q05, our mail server blocked an average of 100 spam and 50 viruses every minute. This is a 25% increase over last quarter, and a 50% increase over last year. Spam complaints to spam@oursite.net are down by 65% over last year on a total email volume of 30% more messages. We attribute the improvement to the free open-source anti-spam and anti-virus programs that we installed last quarter."
If worse comes to worst, you could always try talking time and money:
"Our mail server blocks 100 spam every minute -- all day, every day; during working hours and after hours. It takes approximately 3 seconds for an employee to look at a message, recognize it as spam, and press the Delete key. This means our mail server does the work of more than twenty full-time employees dedicated to doing nothing but deleting spam."
It's true! (100 spam / minute) * (1 minute / 60 sec) * (3 person*sec / spam) = 5 person, but a person only works less than 1/4 of the time (8 out of 24 hours, 5 out of 7 days) whereas a mail server works 24/7.
Exactly. I don't have much patience for the "I'm paying for it, so I can waste it" crowd.
Here's an analogy. Suppose that you join a chess club, where you pay dues in exchange for being hooked up with two chess matches every weekend. Then someone joins who's willing to pay, but doesn't really want to play chess -- they show up at their assigned match, then goof off, juggle the pieces, and forfeit the game. By the "I'm paying for it, so I can waste it" logic, they're not doing anything wrong. But, of course, they are -- they're ripping off the person they're playing with! That person paid for a chess match, not to watch someone goof off. The chess club would be right to kick the goof out ... and would be wrong if it failed to kick them out.
The same is true in colleges. Students aren't just paying for the opportunity to listen to lectures and take tests. In any properly functioning educational setting, they're paying (in part) to participate with other students. So any one student who chooses to goof off thereby diminishes everyone else's education ... and professors and colleges are right to have standards for student behavior, and to kick out students who want to goof off in class.
This isn't to say that colleges should be fascistic. Monitoring student Internet access and handing out demerits is a stupid idea. But professors should take the lead in setting some standards in the classroom, correcting or ejecting students who want to goof off ... and (just as importantly) administrations should support them.
Now, most people would consider rape and domestic violence to be more severe offenses than copyright violation. So clearly there needs to be much greater law-enforcement attention paid to the high-risk demographic categories of advertising executives, recording industry flacks, and marketers.
Default deny makes more sense when you think of it at the organizational level -- like a firewall. Both default deny and allow mean that you have to respond to new needs ... but default allow means you have to respond to new attacks (by blocking them) whereas default deny means you have to respond to new user needs (by allowing them). I've operated both sorts of firewalls -- and when you are in good communication with your user base, default deny is both more reliable and MUCH LESS WORK.
Ah ... you didn't read the article, did you? Every program that's running on your system that you didn't authorize to be there, is a problem. It doesn't matter if it's a "virus" or not, or if it's on Symantec's bad-guy list yet. Consider the following dialogue I had with a Windows technician:
Me: Windows host foo.example.org is cracked. It's portscanning out and trying to break into things. I've blocked it off the network.
Tech: I just ran an anti-virus scan on foo, and it didn't find anything. The user wants to get back to work; please put it back on the network.
Me: I didn't say it had a virus; I said it was scanning out and trying to break into things. It's still trying to scan out. I'm not going to put it back on the network.
Tech: Antivirus software says clean!
Me: snort says scanning out!
Tech: Antivirus software says clean!
Me: tcpdump says scanning out! Go get Clueful Tech to look at it.
Clueful Tech: Oh yeah, it's got all these processes called "fuck.exe" running. It's hosed. I'm reinstalling it.
Me: Thank you, Clueful Tech.
If you need antivirus software, your problem is not viruses -- it is that you don't have any control over what programs are getting to run on your computer. Get that control, and you don't need antivirus software.
Anyone who tells you that all software has bugs is being honest. Anyone who tells you that all software is equally buggy is trying to sell you Microsoft IIS. We can go a long way towards "code without bugs" just by observing the history of software and going with those options which have proven to need much less patching in the past.
We can also -- and more importantly, I think! -- favor software that is architected in such a way as to minimize security exposure. That means privilege separation and least privilege. Running your Web server as root is a brain-dead idea. It means not using more complicated software than you need -- if boa or publicfile serves your needs, don't use Apache.
It's interesting, but it isn't essential to the job. What you need to know is that attacks work by exploiting mistakes in the design and implementation of programs. What you need to know about buffer overflows, for instance, isn't how to exploit one for fun and profit -- but rather, that any C program that uses gets() is broken ... and that programs written in higher-level languages that have checked strings can't suffer from them.
There is a place that I've found that "hacking knowledge" is useful -- in demonstrating incontrovertibly that a problem exists. Joe Moron has a Windows-based embedded print server that's vulnerable
In what sense does information want to be free? In the sense that it is frequently very difficult to keep it bottled up! To keep water from flowing downhill we build water towers, dams, levees, and so forth -- we expend a great deal of effort to resist water's tendency to flow downhill. The same is true of many kinds of information.
If we wish to keep a piece of information private, we have to expend resources to protect it. This is as true if "we" are private citizens, or a government agency. Governments have to exert a lot of effort to deter people from leaking secrets -- for instance, in punishing people who do so; or denying access to reporters who publish "embarrassing" stories. This takes effort.
The same is true of personal information. As we go about our lives, particularly online, we effectively radiate all kinds of identifying facts about ourselves -- HTTP cookies, usernames, email addresses, browsing and shopping preferences, and so on. If we want to bottle up this information and keep it private -- or obfuscate it so that nobody can build up a profile of us -- we have to make some effort to do so.
When we say "information wants to be free" in an advocacy sense, what we may frequently mean is that for some classes of information, the cost of keeping them bottled up is too high -- economically, socially, or personally. For instance, one cost of keeping the facts about the rape of underage Iraqi girls at Abu Ghraib bottled up, is that many people place an erroneous trust in the U.S. Army that its soldiers will not rape underage girls. This erroneous cost is a social evil caused by information being kept unfree.
And it was proposed by a gay man, too. Turing had some preconceptions on which would be a more difficult test -- I think he assumed some traditional stereotypes about women being more emotional or social than men, meaning that imitating a woman should be harder than imitating a man.
For an amusing discussion of the Turing test and gender, see Douglas Hofstadter's "A Coffeehouse Conversation on the Turing Test" -- it's in Metamagical Themas.
Indeed, that's what the word "standard" meant of old. A standard is a pole, a stick -- such as a flagpole, hence the term "standard-bearer". However, more usefully, a standard is also a measuring-stick. (Another word for a well-sized stick is canon, which gives us the word canonical, meaning correct or orthodox, as well as cane, a walking-stick.) The purpose of a measuring-stick is to see if someone or something measures up -- if it is standards-compliant. Standards equals testing.
A real IT standard spells out required behaviors of the implementation. In a standards-compliant C compiler, the function printf accepts certain formatting codes, and generates specified formatting therefrom. A C compiler which (say) inserts extra decimal places when formatting a floating-point number is not just wrong, but provably wrong. You can write a test suite based on the C99 standard that enumerates every possible printf formatting code, and tests that the implementation does the right thing.
A standard can also spell out what is at fault in a failure. The DNS standards spell out the consequences of lame delegation. The SMTP email standards spell out responsibility for message delivery -- if your mail server accepts a message from a sending system, it is required to deliver it or transmit a bounce message. If you reject the message, it is up to the sending system to transmit the bounce. If the sender complains that their mail was not received and they got no bounce message, an inspection of the server logs can show which system is at fault by being out of compliance with the standard. Again, testing is of the essence here: one system is measuring up; the other is not.
An informal "standard" is an invitation to arguments over what is "acceptable" behavior. A formal standard that spells out exactly what is to be sent over the wire (or recorded in the file, or accepted in source code) can still be a source of debate, but at least the participants can accept that there can be right and wrong answers.
However, we're also going to need some software tools. A lot of sites, my own workplace included, are rolling out VoIP systems. Some of these are COTS systems of various levels of quality. Others (like us) are using open systems like Asterisk PBX and SIP Express Router (SER). Currently, as far as I have seen neither the proprietary nor the open tools have what it takes regarding abuse rejection:
Lovgate simply exited without doing anything. Mydoom actually crashed WINE into its debugger. The Netsky variant, as the article describes (SomeFool is Netsky) actually ran. Moreover, it did a passel of DNS queries and actually tried to send e-mail (which was rejected). So, if that e-mail had been accepted, Netsky would have been able to propagate under WINE. As in the article, Ctrl-C proved necessary and effective.
To make a long story short, yes, some Windows viruses do run under WINE. Of course, you have to tell WINE to run them -- not exactly the social engineering that viruses are intended to do. However, as WINE gets more popular and reliable, I would expect that this will be more of a problem for people who choose to (e.g.) run Outlook in WINE.
(For what it's worth, WINE isn't the only way to run Windows viruses and worms on your non-Windows system. I've had to explain to users that yes, their VMware or Virtual PC system is quite capable of getting wormed, and that yes, they did need to do their Windows Update on that "virtual" Windows system, too.)