The purpose of WHOIS contact information is to allow users and operators of other Internet sites to get in touch with you if your site is causing a problem. The Internet is cooperative, recall -- it could not exist at all without the thousands of sites and networks agreeing to carry each other's traffic. This cooperation requires that operators be able to contact one another in case of a problem. The alternative is that if I see anything even remotely resembling an attack coming from your network, I block your entire network -- regardless of whether you yourself are responsible, or some idiot who signed up as your customer.
If you want cooperation from the rest of the network -- in the form of allowing your traffic rather than blocking it -- you have to be reachable in case of problems. You don't get to operate an Internet site and not be accountable for it, because your site's behavior impacts everyone else on the network.
Your obligation to be reachable to other Internet operators does not go away just because spammers can abuse it -- just as a business's obligation to file incorporation papers (including a physical address) with the state doesn't go away just because the Mafia can search incorporation papers for your business's address and come around to demand protection money. The problem there is the Mafia, not the incorporation papers.
If you are concerned about spammers taking your WHOIS contact information and spamming you, you have reason to be -- spammers will take email addresses from anywhere and abuse them. However, you should recognize that this is the fault of spammers, not WHOIS: put the spammers in jail for computer crime, and the problem goes away.
I'm afraid that if all they focus on is ridiculous shit like 419s, people will just dismiss the problem as something only fools will fall for.
You're echoing in microcosm a common concern in the anti-spam world. If legislative or technical efforts against spam target only the most egregious types -- 419-scammers, barnyard porn peddlers, password phishers -- then they may be, inadvertently, making the world safer for spammers who are less blatantly evil. So-called "mainsleaze" spam -- unsolicited bulk email from "legitimate" companies -- is also on the rise, and has just as much potential to destroy the email facility as "scams & porn" spam does.
There are millions of legitimate, aboveboard companies in the world. Spamming is cheap, so spammers rarely have an incentive to spam a targeted list of likely customers rather than the largest group they can. So imagine the result if just 1% of all legitimate companies sent you a spam once per year -- it would amount to thousands of spams a day. This would destroy email just as thoroughly as all the sUUp3r v14'6rA C14Li$ and h0+ T33,N L3$b1An spam could.
And quite a few "legitimate" companies have already dirtied their legitimacy by sending spam. E-pending, or searching out the email addresses of offline customers and spamming them, has become a fad among a certain class of marketers. Others contract out the job of spamming past customers to large operations like MessageReach and DigitalImpact (m0.net).
(Some claim that if you do business with a company, they should have the right to send "offers" to you by email without being considered to be spamming. But think about the number of companies you do business with in the course of a year, directly or indirectly. Suppose you buy a "Harry Potter" bath towel at Sears for your young cousin's birthday present. Should that give three companies -- Sears, the towel manufacturer, and Scholastic (publisher of Harry Potter) -- the right to "e-pend" your email address and send you ads?)
If email is to be protected from the potential onslaught of thousands of spams a day per person, it needs to be defended not only against blatant scammers, but also against anyone else who is tempted to scratch up a few more bucks by spamming.
Meanwhile, MySQL is now doing transactions, and VIEWs are on their way in 5.1.
Is it going to have a data type for IP addresses in the next release, too?
It really, truly astounds me that MySQL has caught on as a DBMS for Internet-facing applications -- including logging, network management, and so forth -- when (at least as of the versions I've seen) it doesn't have data types or operations for IP addresses or CIDR blocks. My partner is in the middle of a CMU NetReg deployment. CMU NetReg is a MySQL-backed Perl application for allowing authenticated users to register their computers into a DHCP network. It has to store all IP addresses as integers, and do binary math in Perl, because the DBMS is too stupid to tell whether 10.128.128.52 is in 10.128.128.0/24.
(Note, I'm not talking about the internal representation of IP addresses. Obviously IP addresses are 32-bit integers. I'm talking about what you see when you do SELECT ip_addr FROM hosts and get 167870644 instead of an IP address. I'm talking about whether the database can compare IP addresses, SELECT those addresses in a netblock, and so forth. Or, as with most things MySQL, you have to implement basic data manipulation in your application because the DBMS can't be arsed.)
Meanwhile, PostgreSQL has IPv4, IPv6, netblock, and MAC address data types and built-in functions to process them. Those make it a darn sight easier to write network management programs, or any other program that needs to reason about IP addresses.
Prior to MS DOS, every operating system was sold by a hardware manufacturer, and they wouldn't sell the OS without a computer. But Microsoft changed that. With MS DOS, it was possible for computers from two different manufacturers to run the same application without porting or recompiling.
CP/M ran on the Zilog Z-80, Motorola m68k, and Intel 8080 and 8086 architectures -- on microcomputers not manufactured by CP/M's publisher, Digital Research. MS-DOS copied many features from CP/M, and several early MS-DOS programs such as dBase and WordStar were ports from CP/M.
Neither Microsoft nor IBM invented the idea of a microcomputer operating system separable from a particular manufacturer's hardware. Indeed, several of the first IBM-clones (by which many would ironically include the IBM PCjr) were notoriously buggy, and many MS-DOS programs would not run on them. (CP/M programs were generally compatible on the same processor.)
As usual, the Microsoft-based copy of someone else's idea was much poorer. However, the Microsoft marketing machine -- and, more importantly, the willingness of the computing world to forget or deny the better options not taken -- have come into play.
a) SMTP HELO's with names whose IP addresses don't match the originating IP
That's interesting.. when you send a mail from a windows machine, it uses its NetBIOS name as it's HELO.
... Well, my mail server does not need to be receiving mail from remote Windows client systems. Windows mail servers, yes, but presumably those can follow the protocol and HELO with their real name, not their Microsoft made-up toy name.
Indeed, I might be willing to discriminatorily greylist all mail from any remote Windows system. (Greylisting: Sending a 4xx temporary failure the first time a host tries to send mail to a particular recipient. This causes a normal MTA to retry in a few minutes, but fire-and-forget spamware and worms generally abort.)
How to apply this to Windows only? OpenBSD's passive OS fingerprinting would be a start. It allows one to selectively redirect traffic based on the detected OS, and thus to offer different quality of service based on the quality of the client system. Since there is a much greater likelihood that a given Windows host's connection to my MTA is delivering spam and worms than that a given Solaris or Red Hat host is delivering spam and worms, there is a good reason to deteriorate service (as by greylisting) for Windows hosts -- as long as it can be done in a way which retains (eventual) delivery of real mail.
If Unix mail server admins all chose to greylist remote Windows hosts -- including Windows MTAs as well as client hosts -- then Windows servers would eat the cost of keeping messages in queue during the greylisting period. This would, effectively, be the cost of proving you're a real Windows MTA, not a worm or spamware. This lays part of the burden of the Windows system's susceptibility to malware back upon those responsible for it (deployers of Windows) whereas currently they are able to offload it upon the rest of us in the form of junk mail from worms.
(Incidentally, yes, the majority of mail exchangers run some form of Unix. Less than half, however, run Sendmail.)
the licence itself is not accepted, hence the licence reverts to standard copyright, which does not allow distribution.
The GPL isn't a contract, which has to be "accepted" by the receiving party to be effective. It is a straight copyright license. So that argument would not fly -- except for one thing: equitable estoppel.
"Equitable estoppel prevents one party from taking a different position at trial than they did at an earlier time if another party would be harmed by the change[d] position." -- Wikipedia
In other words: You can't argue in a custody suit that you're the child's father and then argue in the following child-support suit that you aren't.
The GPL, as Eben Moglen points out, is a distributor's defense when accused of copyright infringement by an author: "I'm not infringing -- because this author granted me permission to copy, under this here license." However, SCO have argued elsewhere that the GPL is invalid. Therefore, even though the GPL is a valid license, and would be a valid license for SCO's use of nmap, SCO is estopped from raising it in court as a defense.
Our concept of liberty is a somewhat subtle and contradictary thing. It involves tolerance of low-level civil disobediance, basic distrust of all forms of government and law enforcement, and most of all, the understanding that the only true guarantee to liberty is in the Bill of Rights and it's fair interpretation by the courts.
No.
The only true guarantee of liberty is for people -- every one of us, or enough of us to outvote the sniveling scum who bend over for tyranny -- to stand up for it. If you don't vote, you cannot expect the courts to be any good, since elected officials appoint the judges. If you squirm your way out of jury duty, you give up your most potent right of review over the acts of law enforcement and other arms of the government, in exchange for temporary convenience.
Freedom is no more a gift from judges and lawyers than it is a privilege handed out by kings. Freedom is ours by our nature, as long as we care to defend it.
There are four boxes to be used in defense of freedom: soap, ballot, jury, and ammo. No, make that:
soap,
ballot,
jury, and
ammo. Use in that order.
Anyway, if you are interested in knowing more, have a look at the records at SPEWS
Ah. That explains a lot. The anti-spam folks (including SPEWS) have been trying to bring this ISP's child-porn-spammer problem to their attention for months. It hadn't worked; the child porn stayed up on their servers and the spammers kept blasting ads for it to all and sundry -- including a very worried biologist at my site, who wanted to know why he seemed to be on some spammer's list of paedophiles?
By the time the FBI got around to investigating, the ISP had probably (as "bulletproof bulker hosting" ISPs usually do) told their spammer customer that they were taking fire. Under those circumstances, the FBI's move was probably a good one -- to keep the child-porn spammers from deleting all their files and hiding their traces.
When I managed a computer store and someone came in who was A+ certified, it was almost a strike against them. I found repeatedly that the technicians that were self-taught were far better at maintaining their skills in a rapidly changing environment.
I'm of two minds about this matter. On the one hand, it's obvious that a lot of the "certification" courses hinge on rote recitation of lessons which may have little indeed to do with the real world -- and fail to test either the underlying principles of knowledge, or the experience, that are really needed to be certifiably skilled. It's clear, too, that a shallow knowledge of the technology that happened to be fashionable a few years ago is not going to help you much a few years from now.
However, I also firmly believe that the skills and knowledge -- and the deeper understanding -- needed to work with computers are not the exclusive province of those who seem like born hacker wizards. These are things that can be taught and learned, just as surely as people can learn a second language, or mathematics. The workings of computer electronics, or the algorithms that go into software, or the organization of a whole computer system are sometimes counterintuitive, but so is just about anything that's worth the effort of learning. What's more, most people are going to learn these things better with a teacher or guide who can point them in the right direction.
It takes time, and it takes effort -- and as with anything, expending effort in a "self-directed" fashion is no guarantee of success, when that direction is wrong. I used to work with one unfortunate case who had observed coworkers with more background than she had, and had come to the conclusion that printing out reams of PHP documentation and studying it like a monk would make her into a Web programmer. It did not work -- she could recite all sorts of things about specific functions, but had no idea how to put functions together to accomplish a task. She seemed to find it incredibly unjust that expending effort was not necessarily rewarding.
It's true that many of the present institutions for teaching IT skills and certifying technicians are abject failures for that purpose. Many are able to teach and to test only the shallowest of knowledge; first, because they categorically fear teaching "theory" (read: background knowledge), and second, because they wish to be salable to those with no experience. However, these are not necessary flaws, but signs of the desperation of the current market. It is very profitable to bullshit when there's a lot of bullshit flying around and people can't tell you're bullshitting -- this is as true now as it was in the days of snake-oil merchants.
What I would like to see is a spam signature sharing, Spam Detection Servers SDS would collect hash per spam email sent within a time period.
What I would like to see is some kind of convenient exothermic chemical reaction, which would convert abundant materials -- such as, say, wood, or possibly carbonaceous minerals -- into glowing gases we could use to heat things up with. This would be of great use in preparing food and keeping warm in the winter.
Little hint: Before you say "I wish a thing like this existed," you might want to do some research in the field. As a matter of fact, a few projects along the lines of what you describe already do exist. Google for "Distributed Checksum Clearinghouses" (DCC, created by Vernon Schryver) and "Vipul's Razor" (created by Vipul Ved Prakash).
No -- unscrupulous: lacking in moral measure; unable to discern the moral weight of one's actions.
(A "scruple" is a unit of weight, don't you know.)
Publicly posting government records of children's whereabouts is not a morally neutral act; it is a reprehensible one. The programmer in question was not, it is claimed, ignorant of the nature of the data he had in hand; he simply did not correctly value that data. He failed to make a necessary value judgment: that to post masses of information on children's whereabouts is, in our world, a wrong thing to do.
It is not simply a stupid or ignorant thing to do. It is not simply incompetent, like writing C code with gets() in it, or turning in code to one's boss which won't compile. Rather, it is a form of carelessness that shows that one places no value upon that with which one has been entrusted.
If you're the sysadmin of a mail system, reading other people's mail for fun is an unethical act. However, leaving the mail-system password lying around, so that random hooligans can read other people's mail, is also an unethical act. Not just stupid. Wrong. It shows that you don't value your users' privacy -- that your values do not match up with your users' values. That, while you may be competent to operate a system for them, you are not trustworthy to do so.
That is a very different way to be bad at one's job.
It's misleading to say that Groklaw is "biased" against SCO. Bias, or prejudice, occurs when someone pre-judges a matter -- when pre-existing opinions lead one to a conclusion that does not respect the evidence at hand, or miscolor one's experience of a situation. It does not occur when someone draws an unpleasant conclusion, or one you don't like, on the basis of actual evidence at hand.
It is not biased to dislike something on the basis of experience, or to distrust someone who has been proven to lie. To accuse someone of bias in this regard is to suggest that having discovered unpleasant truths somehow worsens rather than improves one's ability to draw true conclusions about the world. It is to praise ignorance and naivete' over experience, on the grounds that unpleasant experiences can cause you to think ill of those responsible for the unpleasantness.
Ms. Jones and the others at Groklaw are not biased against SCO. They have come to their conclusions about SCO's dishonesty on the basis of facts, not merely prejudices. People do not simply call SCO liars and scoundrels because they want SCO's claims to be false and self-contradictory, but because SCO's claims have been demonstrated publicly to be false and self-contradictory. That's not bias; it's reasoning.
Yesterday, we rejected some thousands more emails than we usually process on a weekday. Our mail exchangers -- two Dell PowerEdge 2450s with Debian, Postfix, and SpamAssassin -- usually make between 30k and 45k deliveries each day, and reject between 4500 and 5500 messages as spam.
Yesterday, we made the usual 40k deliveries, but additionally rejected 52k messages, most due to the Mydoom outbreak. Over 29k of those rejections were "user unknown"; 13.6k were based on the strings found in the body of Mydoom messages, and 3k were based on our general policy of rejecting EXE attachments based on the Base-64-encoded MZ header.
All spam rejections (including SPEWS and Spamhaus SBL-XBL, plus content filters) totaled only 11% of total rejections.
Maximum load average was around 2. Our mail system is deliberately overengineered, to provide "utility grade" reliability even under load a lot higher than this worm. (Think "mailbomb".) In fact, given how crappy the electrical service is here, I'd say we do rather better than "utility grade".
This attitude is highly counterproductive in the open source community, where the tasks at hand are great and the available talent is currently limited.
Those people's "talent" is only "available" to the people who own it, not to you or "the community". Only the people who choose to do whatever it is they do -- programming, making their own distributions, drawing pretty desktop backgrounds and Mozilla themes -- have the authority or ability to choose what is valuable for them to do.
It doesn't matter whether you criticize their choices as "elitist" or "wasteful". Other people's time and skills belong to them, not to you or "the community," and it is not yours to direct. You do not have access to their minds, their preferences, the systems of values by which they direct their decisions. When you call their choices "wasteful", choices they make using their own resources and time, what you are actually saying is "Boo hoo, all these smart people don't want to work on what I think is important."
Maybe they aren't interested in making a distro for you; they're doing it for their own purposes. You should go up to some biker while he's repairing his Harley, and tell him that he's "wasting time" working on a motorcycle, and that if he is so good as a mechanic then he should repair city buses "for the community".
After all, who is arrogant -- the volunteer who works on his own project, or the user who whines that the volunteer doesn't work on the user's favorite project instead? The volunteers who write and collect free software are not doing it for your sake. You are fortunate that you can benefit at all from their efforts; you have no standing to complain that they "waste" their time on what they see as interesting or worthwhile to do.
Now, if you knew SPF, you would recognize that the last bit -- ?all -- means that AOL is not stating that AOL-user mail is only legitimate if sent from AOL mail servers. The ?all tag means that hosts that don't match the rest of the SPF record are taken as unknown -- not as failures. That would be -all.
Why do we need so many distros when we already have 1 or 2 well developed, well supported good ones?
It isn't a question of "we need", and it never has been. People create new Linux distributions for the same reason a lot of open-source software gets created -- because they want to. This is an obvious result of freedom: people can do what they want to, regardless of whether it is what anyone says "we" need.
In a free society, the motivation for individuals doing things is not that some authority thinks that society needs the outcome. Rather, it is that individuals choose to do things, for whatever obvious or inscrutable reasons they may have, using their own time, resources, and skills.
What you could ask, instead, is: "What motivates people to create more Linux distributions, or other free software that's similar to existing software?" Human action is often inscrutable indeed -- we often cannot even correctly state in retrospect the precise reasons we ourselves make choices. However, I suspect that several factors may enter into the decision to make new software to accomplish the same goals as existing software:
Aesthetics. People have particular opinions and preferences for how things should be done. They write code and assemble collections of software that reflect these preferences, so they can work in a computing environment that is more fulfilling or enjoyable to them personally. Thus, people may create software that meets the same functional goals as existing software, but does so in a way they enjoy more.
Ethics. Many people believe that free software is a moral good, or that dependence on software under particular licenses is harmful or risky. Thus, people may create software that meets the same functional goals as existing software, but is under a different license. (See GNOME and KDE, or some folks' preference for BSD over GPL.)
Confidence. Some people feel more confident in using a tool if they have built it themselves, and therefore understand more fully than a tool built by someone else.
Control of development. Likewise, people may see an existing software project as hampered by constraints on its development, and create (or fork) a new one to reap specific benefits of control. For instance, Mandrake Linux was created originally as a fork of Red Hat optimized for Pentium processors. (The "constraint" on Red Hat was 386-compatibility.)
Quality. Sometimes, there's existing software that fills a need, but it is known to have flaws, or is built in such a way that it is difficult to prove correct or to make secure. A number of the non-Sendmail MTAs (particularly Postfix and Qmail) have been designed to avoid Sendmail's monolithic architecture and consequent security problems.
Put another way, it is usually only from a particular (often, biased) perspective that two pieces of software meet all of the same needs and desires. It would be a short-sighted person indeed who complained that GNU Mailman is duplicative of the efforts that went into the writing of Majordomo. After all, people's interest in pieces of software (and in writing and assembling software) is so often individual -- not aggregate or social -- and nobody but the person doing it can really know why.
I'm not sure that it's accurate to lump everyone who's opposed to the current copyright schemes together as "leftists," which seems to be the implication. Indeed, one would think that a return to a 14 + 14 "founder's copyright" would be not so much radical as reactionary.
Indeed, there's a right-anarchist argument that, unlike private property, copyright is nothing but a government-created monopoly. (Of course, there's also a left-anarchist argument that private property is a government-created monopoly too, but I'm not so sure -- territory is a pretty fundamental idea for a lot of species that don't have governments or copyright.)
I don't think the argument extends, though, to one of the other disparate bits of law that's lumped into the nonsense rubric of "intellectual property" -- trademark. A trademark, like a person's signature, isn't property so much as it is a kind of statement about the trademarked goods: "This luncheon meat was made by the Hormel company," "This document was signed by John Hancock." Falsely applying someone else's trademark to the goods you sell is like forging their signature on an IOU: it's not a property violation against the person whose sigil you forge, but rather a fraud against your customer, or whomever you're passing the IOU to.
(Yes, "right-anarchist" is another word for the American use of "libertarian", and "left-anarchist" for the European "libertarian socialist" or the American "anarchist".)
Terminal programs don't support standard desktop keys anyway, this is no issue. Ctrl-home etc. won't do what you expect either. Just forget about trying to get traditional terminal shells to obey desktop keys and write a new terminal program that does.
It's a bad habit to respond to a post without reading the whole post. As I mentioned, the Mac OS X Terminal.app is just that -- "a new terminal program" that behaves correctly in a GUI environment, including supporting the GUI keyboard commands, including "copy". KDE's Konsole and Gnome's gnome-terminal also attempt (with a lesser degree of success) to work with rather than against the GUI.
I'm not talking about making new GUI environments compatible with xterm. I'm talking about making new GUI environments' terminal emulators more compatible with (1) existing terminal-based programs, and (2) the GUI environments themselves.
Why does Terminal.app fit better with its surrounding environment (Mac OS X) than Konsole fits in its (KDE)? Because, for all its features, Konsole (which I use) has to forego some of the surrounding environment's standard keystrokes because they were chosen in such a way that they conflict with necessary terminal keys.
Konsole doesn't trap Ctrl-C or Ctrl-X; this fact makes Konsole better as a terminal program than if it did, but worse as a KDE application (because KDE does use Ctrl-C for "copy" by default). If KDE's defaults had been chosen in such a way as not to conflict with terminal keys, then Konsole would not need to deviate from the KDE standard behavior -- just as Terminal.app does not deviate from the Macintosh standard behavior.
Ohhh, well the first thing I would do is seperate the action of selecting an object and the actual act of copying that object to the clipboard. Then I would add a specific trigger or event to copy the current selection to the clipboard. Something like the "Control" key and lets see...well how about "C", as that's the first letter of the word "Copy"?
Bad choice. Ctrl-C is for the terminal; it's used to enter control characters. If you allocate Ctrl-C for "copy" in the GUI standard, then one of the following three design flaws emerges:
The terminal program doesn't support copying text, or
The terminal program can't send Ctrl-C to a terminal application, or
The terminal program uses a different (nonstandard) keystroke for "copy".
All of these are unacceptable on a Unix system.
If you want to allocate keystrokes for the GUI, you are much better off using a key that has no meaning to the terminal. On the Macintosh, for instance, there's a key (Command, aka the Apple key) which is reserved for GUI application keyboard shortcuts. Thus, in the Macintosh Terminal.app:
The terminal program supports copy,
The terminal program supports Ctrl-C for terminal applications, and
The terminal program works the same as any other application with regards to copying.
The "traditional" PC keyboard is one key short -- not really that surprising, since it was never designed for a GUI. (The PC keyboard descends from the IBM 3270 terminal keyboard.) The very earliest Mac keyboard was a key short too -- it didn't have Ctrl! This was fixed pretty damn quick, though, when Apple realized how badly it fucked up terminal emulators.
On the PC keyboard, you still have a number of choices, though. You could use Alt for GUI keyboard commands like "copy". However, some Emacs users bind Alt to Meta. You might be able to convince them to go back to using Esc for Meta. Maybe.
Alternately, if you only care about supporting recent PC keyboards, you could use the System key (Windows key) for Meta, or for the GUI keyboard commands. This would be reasonable for a system (such as a Linux desktop) that wants to support both PC and Mac keyboards -- the PC System key takes the place of the Mac Command key.
But please don't futz with Ctrl. Ctrl is for what it says on the tin -- entering control characters.
The original Unix contracts signed by IBM et al, have language that is a little bit ambiguous about ownership of code that each party adds to Unix, more specifically, it was really to do with Unix trade-secrets, not actual copyright.
At this late date -- and even in 1991, when Linus created the first Linux kernel -- no "Unix trade secrets" can be said to exist.
The structure and function of Unix have been a matter of public academic discussion and research for years. POSIX, which codifies the behavior of Unix-like systems, is an industrial standard. Published research papers and industrial standards are not places where "trade secrets" hang out.
The exchange of ideas and code between "commercial Unix" and public academic research was so promiscuous that, when AT&T accused UC Berkeley of copyright infringement, the court actually found that it was AT&T who had copied Berkeley code and published it without acknowledgment.
Trade-secret status is something rather narrowly defined. In order to have a trade secret in a given process, a firm has to protect that secret quite thoroughly. At the very least, the firm has to avoid publishing the "secret" itself! That's why you can't have a trade secret and a patent on the same process -- patents require publication. (So, as I recall, do registered copyrights.) And yet Unix code has been published far and wide -- including by Novell and Caldera/SCO.
The idea of any trade secrets existing in System V Unix is, simply, absurd.
From what I have gathered, the SPEWS philosophy isn't just indifference to collateral damage (ie, 'civilian casualties'); they actively do this damage in order to try to force ISPs into changing their habits. And they are extremely difficult to both reach and reason with; you can post on a newsgroup and hope someone pays attention to your pleas.
Unfortunately, SPEWS does not speak up for themselves, so a certain set of fanatics on newsgroups have taken to speaking up in SPEWS' place and offering listees their flawed interpretation of what SPEWS does and is. You will find absolutely nothing in SPEWS' own documentation -- including the FAQ -- asserting any of the following myths.
"SPEWS wants to cause 'collateral damage'." The popularization of the term "collateral damage" is entirely due to a minority of militaristic posters on the newsgroup news.admin.net-abuse.email. These folks like to fantasize that fighting spam is a "war" rather than simply good systems administration. Even though SPEWS doesn't speak in their terms or play their game, they want to enlist it on their side in the war, trump it up as a scary weapon that ISPs should fear. The fact of the matter is that SPEWS does not intend to cause collateral blocking, and in fact does not serve well the purposes of those who want to do collateral blocking of spammy ISPs. That is what the blackholes.us lists are for -- blocking all the netblocks of an ISP you think is a spam source. Less than 1% of mail blocked by using SPEWS is non-spam mail, so if you wanted to block a lot of non-spam mail from spammy ISPs, SPEWS would not help you do that very well.
"If you're listed in SPEWS, complain in a newsgroup."
This is based on some semiliterate person's misreading of the SPEWS FAQ. The FAQ nowhere suggests that complaining on a newsgroup will get you delisted. Rather, it offers pointers to a couple of newsgroups as places to discuss spam and blocklisting in general. When people come to the newsgroups and post "del1st m33" they get treated about as you'd expect someone who wanders into a conversation mumbling about how mistreated they are gets treated -- with distate and suspicion. Abuse newsgroups are not your fucking tech support. They are for systems administrators and other concerned parties to discuss abuse problems -- not for you to whine about how SPEWS doesn't want to receive your mail. You know how bad an idea it is to whine at your own site's BOFH? It's hundreds of times worse to whine at dozens of BOFHen who have no obligation to you, who have every reason to flame you into a crisp and block all your netblocks with a message like 550 goatse wanker.
"SPEWS accuses us of being spammers." There are many DNSBLs out there that are "spam-source" DNSBLs. That is, they list the IP addresses of hosts that have transmitted spam to a spamtrap address or honeypot system, or that have been reported by their users as sending spam. Not every DNSBL is a spam-source DNSBL. There are a lot of types of DNSBL that have nothing directly to do with whether an IP address has sent spam. For instance, the Blitzed Open Proxy Monitor DNSBL started as a way for IRC operators to keep track of open proxies that were an abuse risk for IRC servers -- nothing to do with spam whatsoever. SPEWS, likewise, is not a spam-source DNSBL. It is a predictive DNSBL, hence the words "early warning" in its name. Its goal is like a "spam hurricane watch" -- it isn't just to tell you where the hurricane is today, but also where it will be tomorrow. It's a fact of the world that netblocks that willingly harbor some spammers tend to get more spammers, and so it's reasonable if one wishes to predict where the spam will come from tomorrow, to say that it will come from the same wider netblocks that the spammers ar
Slashdot editors, technical journalists, and others writing serious articles on the subject would be well-advised to drop terms such as "VoIP security flaw" or "products that use VoIP". Voice-over-IP is a general application category, and gives very little help in discerning whether an issue affects a particular site or product.
Suppose that a new bug were described as a "file sharing security flaw". Now, does that affect Samba? FTP? NFS? Kazaa? File server bots on IRC? One expects good technical reporting to mention the affected services -- or better yet, actual products -- rather than simply describing a general application category.
Specifically, in the VoIP application category, there are two major signaling protocols in use: H.323 and SIP. The last round of "VoIP security flaws" affected SIP software. The current discoveries affect H.323. Describing both as "VoIP flaws" and suggesting that the application domain itself is "threatened" is really quite silly. It is as if someone suggested that a certain bug in IIS and another in Freenet together suggested that "file transfer" on the Internet were threatened.
(For those who don't know much about VoIP: H.323 is the older of the two protocols, and is closer to the "telecoms" way of doing things. It was, IIRC, originally connected to ISDN. SIP is newer, and closer to the "Internet" way of doing things -- if you look at packet captures of it, they look vaguely reminiscent of HTTP, only they're UDP.)
True, but even under GPL, doesn't it still kinda belong directly to the original creator, if only by name alone?
Red Hat was the copyright holder. They got eCos when they bought (IIRC) Cygnus. Thus, what they are doing here is not simply licensing eCos to FSF; they are transferring the copyright to FSF. FSF now is the copyright holder, not simply a licensee.
My reading of this is that it means that Red Hat is not interested in spending money defending the eCos copyright, if it should be violated. Only the copyright holder can pursue a claim when a copyright is violated. FSF has a history of doing this for GNU products they hold copyright to -- going back to the '80s when they nicely informed Steve Jobs that he had to follow the GPL for NeXT's gcc derivative.
(One of the lies people like to tell about the GPL is that "it's unproven because it's never been tested in court". Fact is, it's never had to be tested in court -- violators have always backed down before they had to be sued. NeXT was violating the GPL by distributing an extended gcc -- with Objective-C support -- without source. Once FSF confronted them, they released the source. The descendant of that gcc is still used in Mac OS X.)
It's been suggested in nanae that as a brutal display of the efficacy of spam-fighting and, most importantly, blocklisting, major ISPs all simultaenously turn off their spam defenses for a day to show users just how much UCE spew is clogging the internet every day.
Of course, the idea is repeatedly turned down for its utter lack of pragmatism.
No, it is repeatedly turned down because it would represent deliberate dereliction of duty on the part of each mail administrator participating. Since you are replaceable, you cannot show off how important your job is by failing to do it and causing everyone a pain. You will just be fired and replaced with someone who puts duty and ethics ahead of making political points at your users' expense.
Nor is it any better of a move if done with the approval of management. Each ISP who does it will alienate its own customers -- "You let spam into my mailbox to prove to me that spam is bad? I already knew that, shithead!" -- and will lose customers to those ISPs who do not breach their customers' trust in this fashion.
In short, letting spam in doesn't demonstrate that spam is bad. We already know that spam is bad. All it demonstrates is that you are willing to hurt people who trust you in order to make a point. That's called being an asshole. And that is why this "protest" has been shot down time and again.
Slashdot Mirror
The purpose of WHOIS contact information is to allow users and operators of other Internet sites to get in touch with you if your site is causing a problem. The Internet is cooperative, recall -- it could not exist at all without the thousands of sites and networks agreeing to carry each other's traffic. This cooperation requires that operators be able to contact one another in case of a problem. The alternative is that if I see anything even remotely resembling an attack coming from your network, I block your entire network -- regardless of whether you yourself are responsible, or some idiot who signed up as your customer.
If you want cooperation from the rest of the network -- in the form of allowing your traffic rather than blocking it -- you have to be reachable in case of problems. You don't get to operate an Internet site and not be accountable for it, because your site's behavior impacts everyone else on the network.
Your obligation to be reachable to other Internet operators does not go away just because spammers can abuse it -- just as a business's obligation to file incorporation papers (including a physical address) with the state doesn't go away just because the Mafia can search incorporation papers for your business's address and come around to demand protection money. The problem there is the Mafia, not the incorporation papers.
If you are concerned about spammers taking your WHOIS contact information and spamming you, you have reason to be -- spammers will take email addresses from anywhere and abuse them. However, you should recognize that this is the fault of spammers, not WHOIS: put the spammers in jail for computer crime, and the problem goes away.
You're echoing in microcosm a common concern in the anti-spam world. If legislative or technical efforts against spam target only the most egregious types -- 419-scammers, barnyard porn peddlers, password phishers -- then they may be, inadvertently, making the world safer for spammers who are less blatantly evil. So-called "mainsleaze" spam -- unsolicited bulk email from "legitimate" companies -- is also on the rise, and has just as much potential to destroy the email facility as "scams & porn" spam does.
There are millions of legitimate, aboveboard companies in the world. Spamming is cheap, so spammers rarely have an incentive to spam a targeted list of likely customers rather than the largest group they can. So imagine the result if just 1% of all legitimate companies sent you a spam once per year -- it would amount to thousands of spams a day. This would destroy email just as thoroughly as all the sUUp3r v14'6rA C14Li$ and h0+ T33,N L3$b1An spam could.
And quite a few "legitimate" companies have already dirtied their legitimacy by sending spam. E-pending, or searching out the email addresses of offline customers and spamming them, has become a fad among a certain class of marketers. Others contract out the job of spamming past customers to large operations like MessageReach and DigitalImpact (m0.net).
(Some claim that if you do business with a company, they should have the right to send "offers" to you by email without being considered to be spamming. But think about the number of companies you do business with in the course of a year, directly or indirectly. Suppose you buy a "Harry Potter" bath towel at Sears for your young cousin's birthday present. Should that give three companies -- Sears, the towel manufacturer, and Scholastic (publisher of Harry Potter) -- the right to "e-pend" your email address and send you ads?)
If email is to be protected from the potential onslaught of thousands of spams a day per person, it needs to be defended not only against blatant scammers, but also against anyone else who is tempted to scratch up a few more bucks by spamming.
Is it going to have a data type for IP addresses in the next release, too?
It really, truly astounds me that MySQL has caught on as a DBMS for Internet-facing applications -- including logging, network management, and so forth -- when (at least as of the versions I've seen) it doesn't have data types or operations for IP addresses or CIDR blocks. My partner is in the middle of a CMU NetReg deployment. CMU NetReg is a MySQL-backed Perl application for allowing authenticated users to register their computers into a DHCP network. It has to store all IP addresses as integers, and do binary math in Perl, because the DBMS is too stupid to tell whether 10.128.128.52 is in 10.128.128.0/24.
(Note, I'm not talking about the internal representation of IP addresses. Obviously IP addresses are 32-bit integers. I'm talking about what you see when you do SELECT ip_addr FROM hosts and get 167870644 instead of an IP address. I'm talking about whether the database can compare IP addresses, SELECT those addresses in a netblock, and so forth. Or, as with most things MySQL, you have to implement basic data manipulation in your application because the DBMS can't be arsed.)
Meanwhile, PostgreSQL has IPv4, IPv6, netblock, and MAC address data types and built-in functions to process them. Those make it a darn sight easier to write network management programs, or any other program that needs to reason about IP addresses.
CP/M ran on the Zilog Z-80, Motorola m68k, and Intel 8080 and 8086 architectures -- on microcomputers not manufactured by CP/M's publisher, Digital Research. MS-DOS copied many features from CP/M, and several early MS-DOS programs such as dBase and WordStar were ports from CP/M.
Neither Microsoft nor IBM invented the idea of a microcomputer operating system separable from a particular manufacturer's hardware. Indeed, several of the first IBM-clones (by which many would ironically include the IBM PCjr) were notoriously buggy, and many MS-DOS programs would not run on them. (CP/M programs were generally compatible on the same processor.)
As usual, the Microsoft-based copy of someone else's idea was much poorer. However, the Microsoft marketing machine -- and, more importantly, the willingness of the computing world to forget or deny the better options not taken -- have come into play.
Indeed, I might be willing to discriminatorily greylist all mail from any remote Windows system. (Greylisting: Sending a 4xx temporary failure the first time a host tries to send mail to a particular recipient. This causes a normal MTA to retry in a few minutes, but fire-and-forget spamware and worms generally abort.)
How to apply this to Windows only? OpenBSD's passive OS fingerprinting would be a start. It allows one to selectively redirect traffic based on the detected OS, and thus to offer different quality of service based on the quality of the client system. Since there is a much greater likelihood that a given Windows host's connection to my MTA is delivering spam and worms than that a given Solaris or Red Hat host is delivering spam and worms, there is a good reason to deteriorate service (as by greylisting) for Windows hosts -- as long as it can be done in a way which retains (eventual) delivery of real mail.
If Unix mail server admins all chose to greylist remote Windows hosts -- including Windows MTAs as well as client hosts -- then Windows servers would eat the cost of keeping messages in queue during the greylisting period. This would, effectively, be the cost of proving you're a real Windows MTA, not a worm or spamware. This lays part of the burden of the Windows system's susceptibility to malware back upon those responsible for it (deployers of Windows) whereas currently they are able to offload it upon the rest of us in the form of junk mail from worms.
(Incidentally, yes, the majority of mail exchangers run some form of Unix. Less than half, however, run Sendmail.)
The GPL isn't a contract, which has to be "accepted" by the receiving party to be effective. It is a straight copyright license. So that argument would not fly -- except for one thing: equitable estoppel.
"Equitable estoppel prevents one party from taking a different position at trial than they did at an earlier time if another party would be harmed by the change[d] position." -- Wikipedia
In other words: You can't argue in a custody suit that you're the child's father and then argue in the following child-support suit that you aren't.
The GPL, as Eben Moglen points out, is a distributor's defense when accused of copyright infringement by an author: "I'm not infringing -- because this author granted me permission to copy, under this here license." However, SCO have argued elsewhere that the GPL is invalid. Therefore, even though the GPL is a valid license, and would be a valid license for SCO's use of nmap, SCO is estopped from raising it in court as a defense.
No.
The only true guarantee of liberty is for people -- every one of us, or enough of us to outvote the sniveling scum who bend over for tyranny -- to stand up for it. If you don't vote, you cannot expect the courts to be any good, since elected officials appoint the judges. If you squirm your way out of jury duty, you give up your most potent right of review over the acts of law enforcement and other arms of the government, in exchange for temporary convenience.
Freedom is no more a gift from judges and lawyers than it is a privilege handed out by kings. Freedom is ours by our nature, as long as we care to defend it.
There are four boxes to be used in defense of freedom: soap, ballot, jury, and ammo. No, make that: soap, ballot, jury, and ammo. Use in that order.
Ah. That explains a lot. The anti-spam folks (including SPEWS) have been trying to bring this ISP's child-porn-spammer problem to their attention for months. It hadn't worked; the child porn stayed up on their servers and the spammers kept blasting ads for it to all and sundry -- including a very worried biologist at my site, who wanted to know why he seemed to be on some spammer's list of paedophiles?
By the time the FBI got around to investigating, the ISP had probably (as "bulletproof bulker hosting" ISPs usually do) told their spammer customer that they were taking fire. Under those circumstances, the FBI's move was probably a good one -- to keep the child-porn spammers from deleting all their files and hiding their traces.
I'm of two minds about this matter. On the one hand, it's obvious that a lot of the "certification" courses hinge on rote recitation of lessons which may have little indeed to do with the real world -- and fail to test either the underlying principles of knowledge, or the experience, that are really needed to be certifiably skilled. It's clear, too, that a shallow knowledge of the technology that happened to be fashionable a few years ago is not going to help you much a few years from now.
However, I also firmly believe that the skills and knowledge -- and the deeper understanding -- needed to work with computers are not the exclusive province of those who seem like born hacker wizards. These are things that can be taught and learned, just as surely as people can learn a second language, or mathematics. The workings of computer electronics, or the algorithms that go into software, or the organization of a whole computer system are sometimes counterintuitive, but so is just about anything that's worth the effort of learning. What's more, most people are going to learn these things better with a teacher or guide who can point them in the right direction.
It takes time, and it takes effort -- and as with anything, expending effort in a "self-directed" fashion is no guarantee of success, when that direction is wrong. I used to work with one unfortunate case who had observed coworkers with more background than she had, and had come to the conclusion that printing out reams of PHP documentation and studying it like a monk would make her into a Web programmer. It did not work -- she could recite all sorts of things about specific functions, but had no idea how to put functions together to accomplish a task. She seemed to find it incredibly unjust that expending effort was not necessarily rewarding.
It's true that many of the present institutions for teaching IT skills and certifying technicians are abject failures for that purpose. Many are able to teach and to test only the shallowest of knowledge; first, because they categorically fear teaching "theory" (read: background knowledge), and second, because they wish to be salable to those with no experience. However, these are not necessary flaws, but signs of the desperation of the current market. It is very profitable to bullshit when there's a lot of bullshit flying around and people can't tell you're bullshitting -- this is as true now as it was in the days of snake-oil merchants.
But snake oil doesn't sell forever.
What I would like to see is some kind of convenient exothermic chemical reaction, which would convert abundant materials -- such as, say, wood, or possibly carbonaceous minerals -- into glowing gases we could use to heat things up with. This would be of great use in preparing food and keeping warm in the winter.
Little hint: Before you say "I wish a thing like this existed," you might want to do some research in the field. As a matter of fact, a few projects along the lines of what you describe already do exist. Google for "Distributed Checksum Clearinghouses" (DCC, created by Vernon Schryver) and "Vipul's Razor" (created by Vipul Ved Prakash).
(A "scruple" is a unit of weight, don't you know.)
Publicly posting government records of children's whereabouts is not a morally neutral act; it is a reprehensible one. The programmer in question was not, it is claimed, ignorant of the nature of the data he had in hand; he simply did not correctly value that data. He failed to make a necessary value judgment: that to post masses of information on children's whereabouts is, in our world, a wrong thing to do.
It is not simply a stupid or ignorant thing to do. It is not simply incompetent, like writing C code with gets() in it, or turning in code to one's boss which won't compile. Rather, it is a form of carelessness that shows that one places no value upon that with which one has been entrusted.
If you're the sysadmin of a mail system, reading other people's mail for fun is an unethical act. However, leaving the mail-system password lying around, so that random hooligans can read other people's mail, is also an unethical act. Not just stupid. Wrong. It shows that you don't value your users' privacy -- that your values do not match up with your users' values. That, while you may be competent to operate a system for them, you are not trustworthy to do so.
That is a very different way to be bad at one's job.
It is not biased to dislike something on the basis of experience, or to distrust someone who has been proven to lie. To accuse someone of bias in this regard is to suggest that having discovered unpleasant truths somehow worsens rather than improves one's ability to draw true conclusions about the world. It is to praise ignorance and naivete' over experience, on the grounds that unpleasant experiences can cause you to think ill of those responsible for the unpleasantness.
Ms. Jones and the others at Groklaw are not biased against SCO. They have come to their conclusions about SCO's dishonesty on the basis of facts, not merely prejudices. People do not simply call SCO liars and scoundrels because they want SCO's claims to be false and self-contradictory, but because SCO's claims have been demonstrated publicly to be false and self-contradictory. That's not bias; it's reasoning.
Yesterday, we made the usual 40k deliveries, but additionally rejected 52k messages, most due to the Mydoom outbreak. Over 29k of those rejections were "user unknown"; 13.6k were based on the strings found in the body of Mydoom messages, and 3k were based on our general policy of rejecting EXE attachments based on the Base-64-encoded MZ header.
All spam rejections (including SPEWS and Spamhaus SBL-XBL, plus content filters) totaled only 11% of total rejections.
Maximum load average was around 2. Our mail system is deliberately overengineered, to provide "utility grade" reliability even under load a lot higher than this worm. (Think "mailbomb".) In fact, given how crappy the electrical service is here, I'd say we do rather better than "utility grade".
Those people's "talent" is only "available" to the people who own it, not to you or "the community". Only the people who choose to do whatever it is they do -- programming, making their own distributions, drawing pretty desktop backgrounds and Mozilla themes -- have the authority or ability to choose what is valuable for them to do.
It doesn't matter whether you criticize their choices as "elitist" or "wasteful". Other people's time and skills belong to them, not to you or "the community," and it is not yours to direct. You do not have access to their minds, their preferences, the systems of values by which they direct their decisions. When you call their choices "wasteful", choices they make using their own resources and time, what you are actually saying is "Boo hoo, all these smart people don't want to work on what I think is important."
Maybe they aren't interested in making a distro for you; they're doing it for their own purposes. You should go up to some biker while he's repairing his Harley, and tell him that he's "wasting time" working on a motorcycle, and that if he is so good as a mechanic then he should repair city buses "for the community".
After all, who is arrogant -- the volunteer who works on his own project, or the user who whines that the volunteer doesn't work on the user's favorite project instead? The volunteers who write and collect free software are not doing it for your sake. You are fortunate that you can benefit at all from their efforts; you have no standing to complain that they "waste" their time on what they see as interesting or worthwhile to do.
No, they haven't. Here's the current TXT record for aol.com.:
v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/24 ip4:205.188.157.0/24 ip4:205.188.159.0/24 ip4:64.12.136.0/24 ip4:64.12.137.0/24 ip4:64.12.138.0/24 ptr:mx.aol.com ?all
Now, if you knew SPF, you would recognize that the last bit -- ?all -- means that AOL is not stating that AOL-user mail is only legitimate if sent from AOL mail servers. The ?all tag means that hosts that don't match the rest of the SPF record are taken as unknown -- not as failures. That would be -all.
It isn't a question of "we need", and it never has been. People create new Linux distributions for the same reason a lot of open-source software gets created -- because they want to. This is an obvious result of freedom: people can do what they want to, regardless of whether it is what anyone says "we" need.
In a free society, the motivation for individuals doing things is not that some authority thinks that society needs the outcome. Rather, it is that individuals choose to do things, for whatever obvious or inscrutable reasons they may have, using their own time, resources, and skills.
What you could ask, instead, is: "What motivates people to create more Linux distributions, or other free software that's similar to existing software?" Human action is often inscrutable indeed -- we often cannot even correctly state in retrospect the precise reasons we ourselves make choices. However, I suspect that several factors may enter into the decision to make new software to accomplish the same goals as existing software:
Put another way, it is usually only from a particular (often, biased) perspective that two pieces of software meet all of the same needs and desires. It would be a short-sighted person indeed who complained that GNU Mailman is duplicative of the efforts that went into the writing of Majordomo. After all, people's interest in pieces of software (and in writing and assembling software) is so often individual -- not aggregate or social -- and nobody but the person doing it can really know why.
Indeed, there's a right-anarchist argument that, unlike private property, copyright is nothing but a government-created monopoly. (Of course, there's also a left-anarchist argument that private property is a government-created monopoly too, but I'm not so sure -- territory is a pretty fundamental idea for a lot of species that don't have governments or copyright.)
I don't think the argument extends, though, to one of the other disparate bits of law that's lumped into the nonsense rubric of "intellectual property" -- trademark. A trademark, like a person's signature, isn't property so much as it is a kind of statement about the trademarked goods: "This luncheon meat was made by the Hormel company," "This document was signed by John Hancock." Falsely applying someone else's trademark to the goods you sell is like forging their signature on an IOU: it's not a property violation against the person whose sigil you forge, but rather a fraud against your customer, or whomever you're passing the IOU to.
(Yes, "right-anarchist" is another word for the American use of "libertarian", and "left-anarchist" for the European "libertarian socialist" or the American "anarchist".)
It's a bad habit to respond to a post without reading the whole post. As I mentioned, the Mac OS X Terminal.app is just that -- "a new terminal program" that behaves correctly in a GUI environment, including supporting the GUI keyboard commands, including "copy". KDE's Konsole and Gnome's gnome-terminal also attempt (with a lesser degree of success) to work with rather than against the GUI.
I'm not talking about making new GUI environments compatible with xterm. I'm talking about making new GUI environments' terminal emulators more compatible with (1) existing terminal-based programs, and (2) the GUI environments themselves.
Why does Terminal.app fit better with its surrounding environment (Mac OS X) than Konsole fits in its (KDE)? Because, for all its features, Konsole (which I use) has to forego some of the surrounding environment's standard keystrokes because they were chosen in such a way that they conflict with necessary terminal keys.
Konsole doesn't trap Ctrl-C or Ctrl-X; this fact makes Konsole better as a terminal program than if it did, but worse as a KDE application (because KDE does use Ctrl-C for "copy" by default). If KDE's defaults had been chosen in such a way as not to conflict with terminal keys, then Konsole would not need to deviate from the KDE standard behavior -- just as Terminal.app does not deviate from the Macintosh standard behavior.
Bad choice. Ctrl-C is for the terminal; it's used to enter control characters. If you allocate Ctrl-C for "copy" in the GUI standard, then one of the following three design flaws emerges:
- The terminal program doesn't support copying text, or
- The terminal program can't send Ctrl-C to a terminal application, or
- The terminal program uses a different (nonstandard) keystroke for "copy".
All of these are unacceptable on a Unix system.If you want to allocate keystrokes for the GUI, you are much better off using a key that has no meaning to the terminal. On the Macintosh, for instance, there's a key (Command, aka the Apple key) which is reserved for GUI application keyboard shortcuts. Thus, in the Macintosh Terminal.app:
The "traditional" PC keyboard is one key short -- not really that surprising, since it was never designed for a GUI. (The PC keyboard descends from the IBM 3270 terminal keyboard.) The very earliest Mac keyboard was a key short too -- it didn't have Ctrl! This was fixed pretty damn quick, though, when Apple realized how badly it fucked up terminal emulators.
On the PC keyboard, you still have a number of choices, though. You could use Alt for GUI keyboard commands like "copy". However, some Emacs users bind Alt to Meta. You might be able to convince them to go back to using Esc for Meta. Maybe.
Alternately, if you only care about supporting recent PC keyboards, you could use the System key (Windows key) for Meta, or for the GUI keyboard commands. This would be reasonable for a system (such as a Linux desktop) that wants to support both PC and Mac keyboards -- the PC System key takes the place of the Mac Command key.
But please don't futz with Ctrl. Ctrl is for what it says on the tin -- entering control characters.
At this late date -- and even in 1991, when Linus created the first Linux kernel -- no "Unix trade secrets" can be said to exist.
The structure and function of Unix have been a matter of public academic discussion and research for years. POSIX, which codifies the behavior of Unix-like systems, is an industrial standard. Published research papers and industrial standards are not places where "trade secrets" hang out.
The exchange of ideas and code between "commercial Unix" and public academic research was so promiscuous that, when AT&T accused UC Berkeley of copyright infringement, the court actually found that it was AT&T who had copied Berkeley code and published it without acknowledgment.
Trade-secret status is something rather narrowly defined. In order to have a trade secret in a given process, a firm has to protect that secret quite thoroughly. At the very least, the firm has to avoid publishing the "secret" itself! That's why you can't have a trade secret and a patent on the same process -- patents require publication. (So, as I recall, do registered copyrights.) And yet Unix code has been published far and wide -- including by Novell and Caldera/SCO.
The idea of any trade secrets existing in System V Unix is, simply, absurd.
Unfortunately, SPEWS does not speak up for themselves, so a certain set of fanatics on newsgroups have taken to speaking up in SPEWS' place and offering listees their flawed interpretation of what SPEWS does and is. You will find absolutely nothing in SPEWS' own documentation -- including the FAQ -- asserting any of the following myths.
"SPEWS wants to cause 'collateral damage'."
The popularization of the term "collateral damage" is entirely due to a minority of militaristic posters on the newsgroup news.admin.net-abuse.email. These folks like to fantasize that fighting spam is a "war" rather than simply good systems administration. Even though SPEWS doesn't speak in their terms or play their game, they want to enlist it on their side in the war, trump it up as a scary weapon that ISPs should fear. The fact of the matter is that SPEWS does not intend to cause collateral blocking, and in fact does not serve well the purposes of those who want to do collateral blocking of spammy ISPs. That is what the blackholes.us lists are for -- blocking all the netblocks of an ISP you think is a spam source. Less than 1% of mail blocked by using SPEWS is non-spam mail, so if you wanted to block a lot of non-spam mail from spammy ISPs, SPEWS would not help you do that very well.
"If you're listed in SPEWS, complain in a newsgroup."
This is based on some semiliterate person's misreading of the SPEWS FAQ. The FAQ nowhere suggests that complaining on a newsgroup will get you delisted. Rather, it offers pointers to a couple of newsgroups as places to discuss spam and blocklisting in general. When people come to the newsgroups and post "del1st m33" they get treated about as you'd expect someone who wanders into a conversation mumbling about how mistreated they are gets treated -- with distate and suspicion. Abuse newsgroups are not your fucking tech support. They are for systems administrators and other concerned parties to discuss abuse problems -- not for you to whine about how SPEWS doesn't want to receive your mail. You know how bad an idea it is to whine at your own site's BOFH? It's hundreds of times worse to whine at dozens of BOFHen who have no obligation to you, who have every reason to flame you into a crisp and block all your netblocks with a message like 550 goatse wanker.
"SPEWS accuses us of being spammers."
There are many DNSBLs out there that are "spam-source" DNSBLs. That is, they list the IP addresses of hosts that have transmitted spam to a spamtrap address or honeypot system, or that have been reported by their users as sending spam. Not every DNSBL is a spam-source DNSBL. There are a lot of types of DNSBL that have nothing directly to do with whether an IP address has sent spam. For instance, the Blitzed Open Proxy Monitor DNSBL started as a way for IRC operators to keep track of open proxies that were an abuse risk for IRC servers -- nothing to do with spam whatsoever. SPEWS, likewise, is not a spam-source DNSBL. It is a predictive DNSBL, hence the words "early warning" in its name. Its goal is like a "spam hurricane watch" -- it isn't just to tell you where the hurricane is today, but also where it will be tomorrow. It's a fact of the world that netblocks that willingly harbor some spammers tend to get more spammers, and so it's reasonable if one wishes to predict where the spam will come from tomorrow, to say that it will come from the same wider netblocks that the spammers ar
Your quicksort traverses the list three times in those spiffy list comprehensions.
/pons asinorum/ is actually the list initialization. This is the newbie way:
Try:
def quicksort(list):
if len(list) > 1:
pivot = list[0]
left, middle, right = []. []. []
for item in list:
if item < pivot: left.append(item)
if item == pivot: middle.append(item)
if item > pivot: right.append(item)
return quicksort(left) + middle + quicksort(right)
else:
return list
The
left = middle = right = []
... which makes all three names for the same structure.
Suppose that a new bug were described as a "file sharing security flaw". Now, does that affect Samba? FTP? NFS? Kazaa? File server bots on IRC? One expects good technical reporting to mention the affected services -- or better yet, actual products -- rather than simply describing a general application category.
Specifically, in the VoIP application category, there are two major signaling protocols in use: H.323 and SIP. The last round of "VoIP security flaws" affected SIP software. The current discoveries affect H.323. Describing both as "VoIP flaws" and suggesting that the application domain itself is "threatened" is really quite silly. It is as if someone suggested that a certain bug in IIS and another in Freenet together suggested that "file transfer" on the Internet were threatened.
(For those who don't know much about VoIP: H.323 is the older of the two protocols, and is closer to the "telecoms" way of doing things. It was, IIRC, originally connected to ISDN. SIP is newer, and closer to the "Internet" way of doing things -- if you look at packet captures of it, they look vaguely reminiscent of HTTP, only they're UDP.)
My reading of this is that it means that Red Hat is not interested in spending money defending the eCos copyright, if it should be violated. Only the copyright holder can pursue a claim when a copyright is violated. FSF has a history of doing this for GNU products they hold copyright to -- going back to the '80s when they nicely informed Steve Jobs that he had to follow the GPL for NeXT's gcc derivative.
(One of the lies people like to tell about the GPL is that "it's unproven because it's never been tested in court". Fact is, it's never had to be tested in court -- violators have always backed down before they had to be sued. NeXT was violating the GPL by distributing an extended gcc -- with Objective-C support -- without source. Once FSF confronted them, they released the source. The descendant of that gcc is still used in Mac OS X.)
Nor is it any better of a move if done with the approval of management. Each ISP who does it will alienate its own customers -- "You let spam into my mailbox to prove to me that spam is bad? I already knew that, shithead!" -- and will lose customers to those ISPs who do not breach their customers' trust in this fashion.
In short, letting spam in doesn't demonstrate that spam is bad. We already know that spam is bad. All it demonstrates is that you are willing to hurt people who trust you in order to make a point. That's called being an asshole. And that is why this "protest" has been shot down time and again.