Reform is coming, but the present style of system won't go away until the monarchy finally keels over.
Brilliant, then you can get on with your transition to Ingsoc and your licking of Dim Georgie Bush's chickenhawk boots. Whatever happened to "Britons never shall be slaves"?
The whole point of Internet email is to allow people whom you've never heard of to get in touch with you.
Yes, people who you have never heard of, but people who you have provided your email address to in one way or another.
Right. On a Web page, a public staff directory, a Usenet post -- any of the other places that spam-overwhelmed people are more and more loath to disclose their email addresses. Why? Because some spammer's abusive bot will come along and harvest it, and send spam to it.
People publish their email addresses for certain reasons, and not for others. Hearing about horse pr0n or Joe's Aluminum Siding and Bait Shop is not one of them. This is no different from any other personal resource, such as one's front door. It's OK for people to come up to your door and say hello. It's not OK for people to set huge garish advertising signs on your doorstep, knock the door, and run away to the next house to repeat the trick.
It's really not OK for people to burn crosses on the front lawns of people who complain about your advertising. But Joe Yu of Valuenet hasn't been prosecuted.
(Sure, it's a silly analogy. Analogies for spam are silly, because it's such a fucking silly problem. Only on the Net would people suggest that the appropriate response to crime is to clean up after it and ignore the criminals. Yet that's still a popular suggestion people make to victims of spam crime -- "Just hit delete, isn't that easy?" "Just filter your mail client-side, the spammers will still be spamming you but you won't see it!")
You cannot legislate away structural problems. Spam is the direct consequence of having an unprotected communications ecosystem.
The whole point of Internet email is to allow people whom you've never heard of to get in touch with you. That is, to send unsolicited email. If it were only needed to allow people whom you know and trust to communicate with you, then you could just give them a user account on your box and they could send you local mail.
A "protected communications ecosystem" is exactly what the Net is not supposed to be. Whenever you have something that is "protected", you have someone who is doing the protecting, and who has to make decisions whether or not to allow you to use it for what you want to use it for. In the case of communications, we call that role a censor. The Net allows endpoints to make connections (both literal TCP connections and figurative human connections) without prior arrangement in the middle. That's a design criterion of TCP at the transport level and of Internet protocols in general at the app level. Adding a censor is breaking the system.
The problem of spam is not properly corrected by destroying the opportunity for "unprotected", unsolicited email or other communications -- just as the problems of littering and drunken driving is not properly corrected by tearing up the sidewalks and roads... or by having the cops challenge every passerby for their ID.
Just as the problem of drunk driving is not a "roads technology problem", the problem of spam is not an "email technology problem". Both are social problems, criminal problems -- they are not born fully-formed from the technology, but rather come from people's willing choices to abuse that technology.
It is, of course, important to use technology to provide some basic safeguards against abuse: even though bank-robbing is recognized as a criminal problem, banks have sturdy vaults and security guards. However, it is simply absurd (and absurdly expensive) to look to technology to forestall opportunities for abuse.
How do we eliminate drunken driving? We can't eliminate it entirely, and we know that -- but we can (1) criminalize it, so people who are caught at it are punished as an example to others, and (2) stigmatize it, make it a shameful thing to do, so that fewer people are likely to do it. Fewer people get killed by drunk drivers when driving drunk is seen as an irresponsible act -- when responsible people do things like designate a driver and take their drunk friends' keys.
The same goes for spamming. As long as there is the ability to send mail to people you don't know -- an ability which is valuable! -- there is the possibility that someone will spam. But the present spam flood can be mitigated by dealing with it as a criminal problem. By making spamming a criminal offense and prosecuting some spammers, we can show those who are tempted to spam that they can go to jail for it. By making spamming a shameful act, we can make firms which are tempted to spam reconsider whether they want their Mom & Pop store to be associated in people's minds with horse pr0n.
However, most operating systems do not require alteration at any level below the distributor. Users are actively discouraged from changing their systems. Changing the system means possibly breaking compatibility with other systems which leads to headaches down the road as the forks diverge.
That's silly. It's like saying that having the freedom to remodel your building means that you're going to undermine its foundations and break its compliance with the building code. Of course you don't do that.
When you have a large site with higher potential migration costs, you would be fiscally irresponsible to hand your system over to a single-source vendor. You wouldn't sign a building contract which specified that only the original builder could fix the roof if it leaked, would you? He could charge any price he wanted -- your only options would be to pay it, or to live in a leaky building, or to demolish or abandon the building and build another. That is what lock-in and migration costs mean in proprietary software.
It's true that you, or your staff, may never need to make changes to your software yourself. However, you still benefit from the fact that others can, and that you are not locked-in to someone else's way of doing business.
ftp.sco.com is 216.250.128.13. www.sco.com is 216.250.128.12. They are on the same network segment. However, the first is completely and normally responsive, while the second is entirely unresponsive. This is not in any way characteristic of any sort of modern flood-type denial-of-service attack -- that is, a DDoS aimed at flooding the network itself. Whatever is disturbing SCO, it is not a DoS of the sort they evidently believe it to be.
Unfortunately, SCO has taken the "cargo cult security" measure of blocking pings, so it is not possible to gather any information about their disturbance in that fashion. I suspect that the best method to gather information about SCO's disturbance is, in fact, for SCO to fully and legally respond to IBM's discovery requirements.
("SYN flood" is obviously wrong. Although some firewalls and IDS still report TCP-based DoS floods as "SYN floods", the condition that used to be associated with SYN floods has been fixed in current operating systems. Unless they are running a system old enough to be called grossly negligent, they aren't susceptible to TCB starvation. The current unavailability of www.sco.com looks more like someone tripped over the Ethernet cable.)
When you talk about changing the economy of spam, you are talking about creating scarcity with regard to communication by taxing it. I couldn't disagree more with the suggestion that we must restrict communications in order to solve the spam problem.
The problem of spam is not caused by the freedom of email, any more than murder is caused by the availability of knives and other weapons. It is too easy for technically-minded people to see spam as a technical problem, which is to be solved by replacing the existing mail system with something more restrictive. However, the spam problem is not spontaneously generated by the mail system, just as knives do not go around murdering people. Spamming, like murder, is a human action that certain humans choose to engage in.
It is, of course, useful to use technology to make harmful actions more difficult. Locking up valuables makes theft more difficult; hiring bodyguards makes assassinations more difficult. However, we do not pretend that technology should make theft or murder impossible, or that the world should be transformed into a padded cell so that everyone is technologically prevented from doing anything wrong. Instead we deter and punish crime through education and law enforcement. Technology can reduce the likelihood and impact of harmful human actions, but we cannot use it as a replacement for social responses.
Regardless of whether particular legislatures have passed laws which specifically address spam, we recognize spamming as a lawless and criminal endeavor. Spammers co-opt the property of others against the will of the property owners. (Note that this is worse than simply using that property without permission.) Just as gangs protect their core unlawful enterprises with further crimes such as murdering rivals and bribing police, spammers have come to use cracking, viruses, and DDoS to protect their core activity. Structurally, spam is just like other sorts of lawless action which we see as the proper jurisdiction of law enforcement rather than technological kludgery.
There is no shortage of evidence, gathered from public sources and fully admissible in court, that particular spammers are engaged in criminal actions such as the above. Contrary to common belief, these spammers are not in "third-world nations"; they are in Western nations such as the USA, Canada, and the UK -- nations which have broadly functional legal systems, and nations whose Internet users are the chief recipients of spam as well. Volunteers have already carefully collected this information in the Registry of Known Spam Operations. What is needed is twofold: (1) Funding for law enforcement to go after the known criminal enterprises; (2) Further litigation by major victims of spam, such as large ISPs, against those who are victimizing them.
But this is all secondary. The most important fallacy in blaming the computers for dumbing the classrooms is in that the teachers don't have a clue what the computers are for. Where I went to school, the games were prohibited. You had do write you program using pen and paper. Then you had to prove (in D. Knuth's way) to the teacher that it works. Only after that you were allowed to type your code in and try compiling it.
Well, computer science is not what most students are being taught with computers. Many teachers, like most people in our society, do not entirely realize that computer programs are mathematical functions, nor that they are something that ordinary human beings can learn to write.
(Yes, you read correctly: "ordinary human beings." The cult of the "computer nerd" or "wizard" -- the idea that only a tiny few exceptionally intelligent people are capable of understanding computers -- has existed for only a short time. The vast majority of computer programmers have never been computer fanatics. In science and industry, most still are not. Microsoft and the computer game business are exceptions which deliberately cultivate the "nerd" or "wizard" attitude -- regardless of whether the code or the games are any better!)
Much of the use of computers in schools has nothing to do with programming. Some of it involves playing "educational" computer games. Some of it involves vocational training in the use of word processors and spreadsheets -- which in my opinion is improperly generalized to too much of the student population. (See below.) Some of it involves online research, which has become connected these days to library science. None of these have anything in particular to do with computer science.
It is unfortunate when students are given vocational training on particular pieces of software, and which skimps on the underlying concepts necessary to learn other pieces of software. Teaching students Microsoft Word is giving money to Microsoft. Teaching students basic ideas about operating systems (such as "A computer can be running programs in background, which you don't necessarily see") would be rather more valuable.
Trying to teach students computer science itself early on may not be the best approach to cultivating future computer scientists or programmers. Logic, reasoning, and mathematics are prerequisites to computer science ideas like algorithms and correctness. Training children to use critical reasoning, not just guesswork and opinion, in their everyday studies, is probably the best step towards a better understanding of computing.
It's been more than adequately demonstrated that spammers already break the law. They use services belonging to other people without their consent and against their will. They commit computer crimes such as breaking into systems and spreading viruses. They frequently send ads which are themselves fraudulent; many also advertise products which are otherwise unlawful, such as quack medications and devices for stealing cable TV service. They defy existing regulations on email advertisements, such as state laws prohibiting forgery of return addresses and requiring the subject-line prefix "ADV:" on advertisements. Indeed, the spammer's common false claim that "you opted in" has been ruled an act of fraud.
The problem of spam is already a problem of laws going unenforced against an entrenched criminal element. While spamming itself may not be explicitly illegal, the act of spamming is not separable from acts which are illegal, such as fraud, conversion, and theft of services. Many (including some spammers) are under the misapprehension that because these laws go unenforced, spam is thereby legal. Indeed, the problem of enforcement is so bad that blatantly destructive acts such as denial-of-service attacks against anti-spam services have gone utterly uninvestigated by law enforcement. (This may be changing.)
It is utterly unnecessary to create further laws which penalize ordinary Net users, in an effort to stop spammers. Indeed, such laws simply aggravate the problem already posed by spam: increasing the bother, inconvenience, and expense of using and operating the mail system. In effect, such laws would help the spammers destroy email.
A couple of days ago, Slashdot announces an interview with the CEO of Red Hat. I ask, more or less, "Why the hell don't you have educational discounts?" The question goes to +5, which presumably means it gets forwarded to CEO Szulik. Other posters from educational institutions follow-up my post, to the effect that they are already planning to abandon Red Hat rather than eat the steep price hike to Red Hat Enterprise.
FreshRPMs was just updates and 3rd party builds which Redhat doesn't require you buy at all anyway. You sure you used redhat and aren't just pulling our chain?
We have hundreds of systems running supported Red Hat versions from 9 back to 7.1, and a small number of systems running manually-maintained 6.2 on projects that are particularly sensitive to library fiddling. As you should know, the free version of Red Hat's up2date service is restricted in a few ways: notably, the last time I checked it permits only a single host per registered user, and it allows access only to a busy FTP site which is frequently not usable.
Those of a criminal persuasion might be tempted to suggest that we defraud Red Hat by manipulating the Red Hat Network registration system. Since we are a research institution and not an enterprise of organized crime, this sort of thing is not an option for us. We require procedures which are legal, not crooked -- and in any event, the Red Hat Network facility is going away along with the expectation of future security patches available for current Red Hat Linux systems by this or any other facility (such as FreshRPMs).
For what it's worth, for systems I administer I don't see the need for commercial software support. (Heck, I use Debian for servers and my own workstation.) However, this is not the position that our scientists are in, and they would prefer a commercially-supported system. If Red Hat prices itself out of our market -- which they seem aimed to do -- that will probably end up being SuSE.
Freshrpms.net IS supporting Fedora. Or do you mean you suspect Freshrpms won't continue to support RedHat9?
That is precisely what I said, and what I meant. FreshRPMs redistributes Red Hat's backported fixes for Red Hat Linux releases. It doesn't strike me as a good bet to expect that to continue when the upstream source of those fixes (Red Hat's support for Red Hat Linux) dries up.
Our scientists are not in a position to use a distribution with Fedora's promised rapid release cycles. We require more stability than that, particularly in ABI for third-party applications (including proprietary ones such as MATLAB).
Fedora is documented by Red Hat as targeting developers and early-adopters who are willing to do this rapid-release schedule rather than the backported-fixes model. Our scientists are not within this target market. We are overall far more likely to use slow-and-stable Debian than fast-and-flaky Fedora, although a commercial distribution like SuSE or Mandrake has some advantages.
I work for a world-renowned research institution. We have ~500 Red Hat Linux systems in labs and on desktops, mostly administered by scientists and technicians rather than central IT staff -- so keeping them up to date is a challenge.
We have twice, over the past few years, attempted to contact Red Hat regarding site licensing or educational volume licensing for access to Red Hat Network. Both times the answer has been that -- unlike Sun, Microsoft, Apple, and our other OS suppliers -- Red Hat has no licensing programs for the education and science markets. For this reason, we have turned our Red Hat Linux users away from Red Hat Network and towards FreshRPMs APT as a source of regular software updates.
With the discontinuation of the Red Hat Linux product line, we are now at an impasse. We do not expect FreshRPMs to conjure up security and bug-fix updates for a system that will no longer be supported upstream. My clients would prefer a more guaranteed solution than FreshRPMs. However, Red Hat still shows no signs of interest in the education and research market. Fedora is not an option, as we can't expect our science staff to accept major upgrades every 2-3 months -- they are science nerds, not Linux nerds.
Is there any chance that your plans for Red Hat Enterprise Linux include site- and volume-licensing oriented at the educational and research community? For if not, my colleagues and I will have a hard row to hoe -- migrating existing Red Hat Linux users to supportable distributions such as SuSE or Mandrake.
But no, you don't -- shouldn't -- need to be able to program your CMOS for that.
Thanks for your response -- it leads me to clarify exactly how I meant to relate liberated computer use, programming, and logic. I don't mean to call programming useless, especially as it isn't; rather, I mean that it is the wrong place to start looking for freedom from the machine. The right place to look is mathematics and logic. If one understands these, one can learn programming languages and skills as needed. However, if one lacks these, one will be even more inept at programming than one is at a GUI.
Logic is a prerequisite to computer freedom, as well as to programming. If one unprepared by logic delves into programming, I suspect we can all predict the result. I've seen code written by people who've tried to get into C or Perl without basic mathematics: it's rather akin to the sounds a baby makes before its nervous system is developed enough to allow syllables. It shows effort, but the underlying control is simply not there.
I suspect, by the way, that the tyranny of the machine and that of its human controllers are tyrannies closer-allied than you have implied. We need only inspect the thorougly abused user: the poor fellow whose computer is riddled with viruses, adware, spyware, spamware, antisoftware of all kinds. The tyranny of his ignorance exposes him to the false belief that this is normal; and also to the specific abuses of these noxious programs' controllers. He would benefit if he could seize control of his computer and throw off the tyrants. However, he neither realizes this is possible, nor does he have any handhold by which to seize it.
What Evans' article suggests -- a conclusion, I might add, that I would not attribute to Neal Stephenson -- is that understanding computation has become necessary to individual freedom in our computerized society. That is, because we have to use these immensely complex and versatile artifacts, we must understand them and be able to control them, in order to call ourselves free. If we cannot control them, it follows, they will be used to control us.
In the olden days, there was an expression used to refer to those disciplines and sciences deemed necessary to the free man. That expression was the liberal arts. Though today we might associate that phrase with endless "humanities" classes, or with a college degree not useful for any particular career, of old it meant simply those arts -- practices -- necessary to exercise the liberty of a free citizen. The classical liberal arts were seven: grammar, rhetoric, logic, arithmetic, geometry, astronomy (for which read "physics other than ballistics"), and music.
(Please note that literary criticism, social theory, and deconstruction are not named among the liberal arts.)
We still recognize (I hope) that one who cannot recognize a fallacy in argumentation, or who cannot do arithmetic, is severely impaired in exercising the freedoms of man and citizen. A person who is unacquainted with works of literature may miss cultural references in a politician's speech, but a person unable to cope with rhetoric and logic cannot even tell if the speaker is contradicting himself. Likewise, one who cannot add and subtract cannot tell if he is being cheated in the marketplace.
From a classical viewpoint, what Evans is suggesting is that an understanding of computation has become a liberal art: a discipline necessary to exercise freedom. It is unfortunate and misleading, however, to frame this in terms of "programming languages" or "command lines" -- both of which are simply abstractions (just as is the GUI) on top of the mathematics of computation. The essence that must be understood is no language other than mathematics.
(As an aside: Historically, computer science -- which has little, I might note, to do with "knowing programming languages" -- is an outgrowth of mathematical logic, which is itself an extension of the liberal arts of arithmetic, geometry, and classical (syllogistic) logic. Thus, Aristotle and Dodgson, to pick two, prefigure Turing and McCarthy.)
The same fundamental calculi of functions, algorithms, and Boolean binary logic underlie all of the abstractions we may encounter in computing. GUIs, shells, assemblers, virtual worlds -- all of these are necessarily founded upon the same mathematics. No matter how complex the language or how pretty the interface, it must abide by mathematical logic or it cannot function.
Thus, if Dylan Evans seeks, with Neo, "the code behind the graphics", he should not look to the Unix shell, to C, or even to machine code to find it. Those are tools, not truths, and freedom comes with understanding truths, not simply with mastering tools. Learn the liberal arts -- mathematics and logic -- and you will be much better prepared to defend yourself as a free citizen in a computerized world.
It only took a few hundred dollars to pay her off.
Even extortion is cheaper when done overseas.
And that is called paying the Dane-geld;
But we've proved it again and again,
That if once you have paid him the Dane-geld
You never get rid of the Dane.
Once you have proven that you can be extorted from -- that you will pay the cash demands of those who hold something over your head -- you can expect nothing but more of the same. The more willing you are to "pay him cash to go away," the weaker your position will be the next time the extortionist comes a-viking.
Better far to repel him -- to turn whatever resources and defenses you may have, be they litigious in this case or otherwise -- to prove that you will not be threatened. And, of course, next time to never allow yourself to be put in that position.
Dude, I realize your post is about knocking perl regexes,
Actually, it wasn't. It was a discussion of the ways people use regex in Perl, and of the only other regex notation I'm familiar with besides Perl's.
Did you know that there are thousands of people in the world who discuss all manner of differemces without "knocking" anything? For instance, when biologists who study insects meet biologists who study lizards, they do not rant at one another about whether lizards r0x0r and insects sux0r or vice versa.
but there's no need to obfuscate what could just as easily have been written as: foo|bar|b(a|uz)z
Well yes, but I was using "foo" to stand in for any sequence. It was intended as an example of a more full regex syntax.
My problem with Perl is the ubiquitous use of the regular expressions.
It's true that people writing in Perl tend to use regular expressions in places where they're not necessarily appropriate. For instance, algorithmically speaking, subsequence matches are faster than regular-expression matches. (This is why Python has the.startswith and.endswith string methods, and the in operator.) However, the Perl regular-expression engine (PCRE) is optimized to heck and its raw speed can usually overcome this.
That said, the traditional regular-expression syntax is rather arcane. The only real alternative I've seen is the S-expression syntax of cl-ppcre -- the Common Lisp PCRE implementation. This allows you to write complex regular expressions as tree structure rather than as strings of character glyphs.
For instance, in place of the regex string "(?:foo)|(?:bar)|(?:b(a|(?:uz))z)" you can write:
(:alternation "foo" "bar" (:sequence "b" (:alternation "a" "uz") "z"))
Now, that might not be any clearer to you if you don't know Lisp, but it gets better as the regex gets more complicated. (I've been a little tricky by putting a lot of ?: in the original regex string. That's the code for "I want to do grouping, but I don't want to capture groups into variables." In the Lisp syntax, you have to mark when you do want capture, not when you don't. People writing in Perl usually let their groups get captured even when they don't make any use of the resulting variables.)
Interestingly enough, the authors of cl-ppcre claim that it outperforms Perl -- a remarkable claim, but they seem to have pretty comprehensive statistics as to when it does and when it doesn't. It's odd to think that even though many people think Lisp is slow, compiled Lisp can really be quite speedy for tasks that people usually use a specialized language for.
since it was the first real object oriented language.
Huh? What about Simula, the first object oriented language?
Or what about Common Lisp, the first object-oriented language with a published standard?
It doesn't make much sense to say that any particular language was "the first real object-oriented language" because people have different religious beliefs as to what constitutes a "real" object-oriented language.
People get into hideous flamewars about that word "real" when applied to categories like "object-oriented", "functional", or "Christian".:)
The monoculture risk is real when you're looking at the 64,000 view -- the entire population. They're not really all that much of a risk when you're dealing with, say, an enterprise's systems, and there's not that much benefit to them in that kind of environment (disregarding things like security devices for the moment).
On the contrary, the monoculture risk should affect an enterprise decision whether to participate in that monoculture. When making such decisions, people shouldn't take into account the network benefits (such as being able to skimp on staff training on the grounds that "everyone already knows Windows") without taking into account the network risks (such as the increased likelihood of heavy virus outbreak).
It's true that your organization can't change the fact that the majority of the world uses Windows, and as a result the Internet as a whole is subject to DDoS and packet storms from Windows viruses. However, your organization can reduce its own risks by choosing a different system, one that may still feel the second-hand effects of the harm of monoculture but does not receive the brunt of the damage.
But systems are not equally buggy. I discuss this here. No design and no development method is perfect. However, it is incontrovertible that some designs and some development methods yield software that fails less often; that fails less severely; and that fails more recoverably. We can inspect systems' behavior and say that for particular purposes, certain software is better than others. We can say this on the basis of technical facts, not merely marketing claims and promises of "support" and "warranty". We can also say it on the basis of historical evidence -- some systems have failed more often and more severely than others.
A Microsoft Exchange mail server stores users' mail in a binary database, in a proprietary format. A Postfix or Qmail mail server stores users' mail in text files in a simple directory structure. We can make a reasonable (and correct!) prediction that in case of failure, it is easier to recover the content of mail from a Postfix or Qmail system than from Exchange. And, indeed, this is borne out by the experience of administrators: a maildir can get into an inconsistent state, but it's much easier to recover it than to recover an Exchange mail database.
(Note that I'm not describing frequency of failure, but rather severity. We can also make predictions about the former, of course....)
Security holes are, from an engineering standpoint, simply another kind of failure. We can look at design choices such as privilege separation and chrooting -- applications of the Principle of Least Privilege -- and say that some systems will fail worse than others. A program that can't access files outside of/home/myprog cannot scribble on the kernel in/boot/vmlinuz. A Web server that runs as Administrator on Windows 2000 has opportunities to fail worse than a Web server that runs as www-data on Solaris.
Simply put, there exist objective facts about security design, just as there exist objective facts about, say, civil engineering. Why doesn't the city construct water mains out of balsa wood and bridges out of papier-mache? It simply doesn't work very well.:)
The relational model is a general model of data -- it can model anything, including what one would think of as a typical object.
Having trotted out "Database Debunkings" before myself, I agree with you in part. Certainly a relational database can store facts about objects. This is, however, not the same as storing objects themselves. The difference is one of identity.
Chris Date's articles on "OODBMS" seem to deal mainly with the need not to throw away the relational model simply because OO users want more complex data types in order to model objects. This is of course eminently reasonable -- regardless of what data types you are working with, the relational model still makes sense and indeed is required to make your database make sense. It also is orthogonal to the point I was trying to make above.
The crux of my point is that tuples do not carry identity. Tuples are values, not objects -- they are more akin to the number 5 than to the variable x in the C statement int x = 5; The relational model precisely does not let us talk about their position, address, or pointers to them -- it lets us talk about them only as values, and relations as sets of values.
You can have tuples about things which have identity -- after all, customers have identity. To represent customers' identity, we may use unique keys. (Incidentally, because they are not unique, SSNs do not form a candidate key.) However, this is "representing facts about entities which have identity", which isn't what OO users want. They want to store data objects that have identity -- because their objects in core do have identity, and all they want from the database is a persistent object store.
Again: the OO person wants to store objects with identity. The RDBMS offers him the ability to represent facts about objects with identity.
What do I mean by "identity"? Good question. One simple way of putting it is that objects with identity are unique; references to them can be stored, and they can be addressed and updated uniquely by them. References to them (e.g. pointers) can be compared by comparing the references only. The C++ reference variables (or C pointers) first_customer and current_customer point to the same object iff they are themselves equal. We can store a reference to that object by copying a reference variable -- and when we indirect through it later, we know we will get the same object, not merely one with the same values. The relational model does not admit of such objects -- it has no pointers, only values in sets.
(Those familiar with Lisp are reminded of EQ vs. EQUAL.)
Objects in OO can store references to other objects. Tuples in databases cannot; they can only store common values (like foreign keys). A foreign key is not a reference to another tuple; it is simply a value that is noted as being in common with another tuple, which tuple is in a set wherein that value is unique. So when you store facts about an object into a database, how do you store the fact "this object contains a reference to that other one"? Serial numbers as foreign keys? Then how many passes does it take to reconstitute the pointers in core from the serial numbers in the database?
The problem of discerning identity out of facts is not simply hard in computing. It is hard in the real world -- that is why it is a major subject of metaphysics in philosophy. (Which has nothing to do with "metaphysics" in the sense of "supernaturalism".) Those who sweep it under the table as "academic theory" or "irrelevant to business" will get bitten by it later in ambiguous results.
It's true that an RDBMS doesn't map well to the object-oriented ideology. That's because an RDBMS does not store objects, or anything like them.
The object-oriented ideology as instantiated in C++ and Java is founded upon breaking data into objects, bearers of identity, which belong to classes, bearers of structure and behavior. (C++ and Java make little account of metaclasses, which are used in more dynamic object systems such as Python's class system and Common Lisp's CLOS. Templates are not metaclasses.) Objects have identity, so they can be equated; they are the unique bearers of attributes about themselves; and each object's structure is dictated by the class to which it belongs.
When object-oriented partisans look at a database, they see its relvars (or table headers) as bearers of structure and think of classes, and its tuples (or rows) as bearers of identity and think of objects. They see a database as a place to store objects persistently.
But this is not what an RDBMS does. An RDBMS isn't an object store; its relvars are not classes and its tuples are not objects. So what is an RDBMS? What is "relational" anyhow? Relational databases are founded upon relational mathematics, which is what you get when you cross set theory with predicate calculus.
Set theory is the branch of math that deals with collections of elements which behave according to formal axioms. Set theory lets you say, for instance, that if you have a non-null set R and a non-null set S, that you can construct a set R*S of all the possible pairs of elements from R and S.
Predicate calculus is the branch of logic that deals with quantified statements about entities. It lets you formalize logical arguments such as the syllogism: All men are mortal; Socrates is a man; therefore, Socrates is mortal. Predicate calculus deals with generalizations and instantiations of those generalizations.
What do we get by combining set theory and predicate calculus? We get a system that allows us to operate upon sets of tuples of values satisfying predicates. A relation holds tuples of values which make some predicate true. For instance, consider the predicate "Person x owes me y dollars." Tuples which satisfy this predicate will be pairs (x,y) for which the sentence is true. For instance, if Fred owes me 40 dollars, (Fred, 40) satisfies the predicate. It could thus be a tuple in the relation described by the predicate -- the one relating people's names to how much they owe me.
With the relational algebra (or an RDBMS) we can do operations upon this relation and others. We could, for instance, select a result set of all those people who owe me more than 50 dollars -- or join this result set with those people's addresses. Whatever result set we ask for will be calculated from the facts in the database. We might get back this result set:
(Barney, 75, 40 Elm Road)
(Megan, 60, 9 High Street)
Now, are the elements of this result set objects in the object-oriented sense? They are not. They do not have identity. The tuple about Barney is not Barney himself, or even a machine representation of him. It doesn't uniquely store attributes of Barney -- after all, we created it by joining tables which also contain such attributes. It is not even, truly, a fact about Barney exclusively -- for it is also a fact about the number 75, and about the address 40 Elm Road. It isn't an object; it's a tuple value, and values do not have identity as objects do.
Moreover, note that by joining, we can construct new relations from old ones. Thus, not only are tuples not objects, but relvars are not classes. After all, in OO we do not create new classes by joining, but by inheritance or encapsulation of old ones -- and creating a new class does not cause it to be instantiated into known-correct objects.
So what does this matter to OO people faced with RDBMS as a
"The Internet Architecture Board issued this response to an ICANN inquiry about Verisign's SiteFinder service."
Actually, if you read that article you will find that it is dated January 25 and is a response to another Verisign screwup. That one was similar to the present one, but had specifically to do with "internationalized" domain names -- DNS records for strings with characters above ASCII position 127.
Historians find it important to check the dates of events and documents, so they can know which ones could possibly be responses to which other situations. For instance, an American comedian telling anti-French racial jokes in August 2001 could not possibly be responding to the French objection to Bush's war. Similarly, a document released January 25 2003 cannot be a response to a situation that arises the following September. Time just doesn't work that way.
It is not the ISP's job to protect you from the insecurity of the software that you choose to run on your connection. Therefore, the ISP should not block ports (or take other steps) for the purpose of protecting you from worms, viruses, or crackers -- unless you contract with them for that purpose.
However, it is the ISP's job to maintain service quality for the other thousand people served by the same point of presence that you use. It is its job to protect its service from DoS attacks, to ensure that those who don't have a worm are able to use the service.
Therefore, when a worm outbreak borders upon DDoS, it is very likely in the ISPs' best interest to interfere with it. They should do so minimally, because their purpose in so doing is to minimize its effect on their business and responsible network operators -- not to Quixotically defend irresponsible network operators.
At different stages of an outbreak, and depending on the specific behavior of the worm, an ISP's best response may differ. For instance, if a tiny number of customer hosts are infected and are blasting huge amounts of traffic, the best response may simply be to remove them from the network, or block the relevant ports on the proximal router.
If they call and complain, the first-line technical support can read off a prepared statement, which (when boiled down) says basically this: "Your computer was being used for a Federal crime, breaking in to other people's computers. We shut down the network to protect our other customers from this criminal activity. It's possible your computer was infected by a virus that was being used to perpetrate this crime. Because of this possibility, we didn't call the FBI and report you as the source of the criminal activity. It's your responsibility to keep your computer from being used to hurt other people." They can then go on to offer, for a small fee, a CD of licensed antivirus and worm removal software -- or, for a larger fee, a visit from a technician who will run the same. Connectivity is not restored until the system is clean, whether by this means or any other.
In the case of a widespread outbreak, where more than 5-10% of the client systems are infected, it's probably more expedient to just block the ports on the core routers first. Then find a way of enumerating the infected systems and dealing with them, if it's deemed worthwhile.
Of course, any such measure should be announced. Exactly how to announce it I'm not sure, since many ISP users don't use an ISP mail account (and the ISP must not send spam), nor do they read the ISP's local newsgroup or visit the Web page.
In the case of a local ISP, the newspaper is always an option.
A security expert who cannot be bothered to turn a knob on his door... eh, what?
I used to work for a guy who had a saying on this subject: "Locks are to keep your friends out." That is to say, security measures impose barriers to unauthorized access, but these barriers are only so high -- if you have enemies willing to break down your door, locking it will not help you; if you don't, what function does locking serve?
Well, one function of a lock, or a password, is its social effect: it says, loud and clear, "Keep out -- this place is only for those who have the key." Most people want to think of themselves as nice and respectful people. Most people aren't crackers or thieves, and will respect a security measure simply because someone went to the bother of putting it there. Against these people, you set a password on your account simply so they will realize it is not a public resource. You lock your machine room door so they won't wander in randomly in search of a terminal to check their email.
Securing things against concerted attackers is different from securing them from wandering friends. You rarely need to enact security measures that will keep a concerted attacker out forever -- only ones that will keep him out long enough for you to notice his assault and cuff him. Bank safes are rated in minutes: rather than proclaiming a safe "uncrackable", the rating states how long a certain level of attacker will take, to crack the safe. So as long as the bank has their security guard come by more often than that, it doesn't matter that the safe isn't perfectly uncrackable.
Slashdot Mirror
Right. On a Web page, a public staff directory, a Usenet post -- any of the other places that spam-overwhelmed people are more and more loath to disclose their email addresses. Why? Because some spammer's abusive bot will come along and harvest it, and send spam to it.
People publish their email addresses for certain reasons, and not for others. Hearing about horse pr0n or Joe's Aluminum Siding and Bait Shop is not one of them. This is no different from any other personal resource, such as one's front door. It's OK for people to come up to your door and say hello. It's not OK for people to set huge garish advertising signs on your doorstep, knock the door, and run away to the next house to repeat the trick.
It's really not OK for people to burn crosses on the front lawns of people who complain about your advertising. But Joe Yu of Valuenet hasn't been prosecuted.
(Sure, it's a silly analogy. Analogies for spam are silly, because it's such a fucking silly problem. Only on the Net would people suggest that the appropriate response to crime is to clean up after it and ignore the criminals. Yet that's still a popular suggestion people make to victims of spam crime -- "Just hit delete, isn't that easy?" "Just filter your mail client-side, the spammers will still be spamming you but you won't see it!")
The whole point of Internet email is to allow people whom you've never heard of to get in touch with you. That is, to send unsolicited email. If it were only needed to allow people whom you know and trust to communicate with you, then you could just give them a user account on your box and they could send you local mail.
A "protected communications ecosystem" is exactly what the Net is not supposed to be. Whenever you have something that is "protected", you have someone who is doing the protecting, and who has to make decisions whether or not to allow you to use it for what you want to use it for. In the case of communications, we call that role a censor. The Net allows endpoints to make connections (both literal TCP connections and figurative human connections) without prior arrangement in the middle. That's a design criterion of TCP at the transport level and of Internet protocols in general at the app level. Adding a censor is breaking the system.
The problem of spam is not properly corrected by destroying the opportunity for "unprotected", unsolicited email or other communications -- just as the problems of littering and drunken driving is not properly corrected by tearing up the sidewalks and roads ... or by having the cops challenge every passerby for their ID.
Just as the problem of drunk driving is not a "roads technology problem", the problem of spam is not an "email technology problem". Both are social problems, criminal problems -- they are not born fully-formed from the technology, but rather come from people's willing choices to abuse that technology.
It is, of course, important to use technology to provide some basic safeguards against abuse: even though bank-robbing is recognized as a criminal problem, banks have sturdy vaults and security guards. However, it is simply absurd (and absurdly expensive) to look to technology to forestall opportunities for abuse.
How do we eliminate drunken driving? We can't eliminate it entirely, and we know that -- but we can (1) criminalize it, so people who are caught at it are punished as an example to others, and (2) stigmatize it, make it a shameful thing to do, so that fewer people are likely to do it. Fewer people get killed by drunk drivers when driving drunk is seen as an irresponsible act -- when responsible people do things like designate a driver and take their drunk friends' keys.
The same goes for spamming. As long as there is the ability to send mail to people you don't know -- an ability which is valuable! -- there is the possibility that someone will spam. But the present spam flood can be mitigated by dealing with it as a criminal problem. By making spamming a criminal offense and prosecuting some spammers, we can show those who are tempted to spam that they can go to jail for it. By making spamming a shameful act, we can make firms which are tempted to spam reconsider whether they want their Mom & Pop store to be associated in people's minds with horse pr0n.
That's silly. It's like saying that having the freedom to remodel your building means that you're going to undermine its foundations and break its compliance with the building code. Of course you don't do that.
When you have a large site with higher potential migration costs, you would be fiscally irresponsible to hand your system over to a single-source vendor. You wouldn't sign a building contract which specified that only the original builder could fix the roof if it leaked, would you? He could charge any price he wanted -- your only options would be to pay it, or to live in a leaky building, or to demolish or abandon the building and build another. That is what lock-in and migration costs mean in proprietary software.
It's true that you, or your staff, may never need to make changes to your software yourself. However, you still benefit from the fact that others can, and that you are not locked-in to someone else's way of doing business.
ftp.sco.com is 216.250.128.13. www.sco.com is 216.250.128.12. They are on the same network segment. However, the first is completely and normally responsive, while the second is entirely unresponsive. This is not in any way characteristic of any sort of modern flood-type denial-of-service attack -- that is, a DDoS aimed at flooding the network itself. Whatever is disturbing SCO, it is not a DoS of the sort they evidently believe it to be.
Unfortunately, SCO has taken the "cargo cult security" measure of blocking pings, so it is not possible to gather any information about their disturbance in that fashion. I suspect that the best method to gather information about SCO's disturbance is, in fact, for SCO to fully and legally respond to IBM's discovery requirements.
("SYN flood" is obviously wrong. Although some firewalls and IDS still report TCP-based DoS floods as "SYN floods", the condition that used to be associated with SYN floods has been fixed in current operating systems. Unless they are running a system old enough to be called grossly negligent, they aren't susceptible to TCB starvation. The current unavailability of www.sco.com looks more like someone tripped over the Ethernet cable.)
The problem of spam is not caused by the freedom of email, any more than murder is caused by the availability of knives and other weapons. It is too easy for technically-minded people to see spam as a technical problem, which is to be solved by replacing the existing mail system with something more restrictive. However, the spam problem is not spontaneously generated by the mail system, just as knives do not go around murdering people. Spamming, like murder, is a human action that certain humans choose to engage in.
It is, of course, useful to use technology to make harmful actions more difficult. Locking up valuables makes theft more difficult; hiring bodyguards makes assassinations more difficult. However, we do not pretend that technology should make theft or murder impossible, or that the world should be transformed into a padded cell so that everyone is technologically prevented from doing anything wrong. Instead we deter and punish crime through education and law enforcement. Technology can reduce the likelihood and impact of harmful human actions, but we cannot use it as a replacement for social responses.
Regardless of whether particular legislatures have passed laws which specifically address spam, we recognize spamming as a lawless and criminal endeavor. Spammers co-opt the property of others against the will of the property owners. (Note that this is worse than simply using that property without permission.) Just as gangs protect their core unlawful enterprises with further crimes such as murdering rivals and bribing police, spammers have come to use cracking, viruses, and DDoS to protect their core activity. Structurally, spam is just like other sorts of lawless action which we see as the proper jurisdiction of law enforcement rather than technological kludgery.
There is no shortage of evidence, gathered from public sources and fully admissible in court, that particular spammers are engaged in criminal actions such as the above. Contrary to common belief, these spammers are not in "third-world nations"; they are in Western nations such as the USA, Canada, and the UK -- nations which have broadly functional legal systems, and nations whose Internet users are the chief recipients of spam as well. Volunteers have already carefully collected this information in the Registry of Known Spam Operations. What is needed is twofold: (1) Funding for law enforcement to go after the known criminal enterprises; (2) Further litigation by major victims of spam, such as large ISPs, against those who are victimizing them.
Well, computer science is not what most students are being taught with computers. Many teachers, like most people in our society, do not entirely realize that computer programs are mathematical functions, nor that they are something that ordinary human beings can learn to write.
(Yes, you read correctly: "ordinary human beings." The cult of the "computer nerd" or "wizard" -- the idea that only a tiny few exceptionally intelligent people are capable of understanding computers -- has existed for only a short time. The vast majority of computer programmers have never been computer fanatics. In science and industry, most still are not. Microsoft and the computer game business are exceptions which deliberately cultivate the "nerd" or "wizard" attitude -- regardless of whether the code or the games are any better!)
Much of the use of computers in schools has nothing to do with programming. Some of it involves playing "educational" computer games. Some of it involves vocational training in the use of word processors and spreadsheets -- which in my opinion is improperly generalized to too much of the student population. (See below.) Some of it involves online research, which has become connected these days to library science. None of these have anything in particular to do with computer science.
It is unfortunate when students are given vocational training on particular pieces of software, and which skimps on the underlying concepts necessary to learn other pieces of software. Teaching students Microsoft Word is giving money to Microsoft. Teaching students basic ideas about operating systems (such as "A computer can be running programs in background, which you don't necessarily see") would be rather more valuable.
Trying to teach students computer science itself early on may not be the best approach to cultivating future computer scientists or programmers. Logic, reasoning, and mathematics are prerequisites to computer science ideas like algorithms and correctness. Training children to use critical reasoning, not just guesswork and opinion, in their everyday studies, is probably the best step towards a better understanding of computing.
The problem of spam is already a problem of laws going unenforced against an entrenched criminal element. While spamming itself may not be explicitly illegal, the act of spamming is not separable from acts which are illegal, such as fraud, conversion, and theft of services. Many (including some spammers) are under the misapprehension that because these laws go unenforced, spam is thereby legal. Indeed, the problem of enforcement is so bad that blatantly destructive acts such as denial-of-service attacks against anti-spam services have gone utterly uninvestigated by law enforcement. (This may be changing.)
It is utterly unnecessary to create further laws which penalize ordinary Net users, in an effort to stop spammers. Indeed, such laws simply aggravate the problem already posed by spam: increasing the bother, inconvenience, and expense of using and operating the mail system. In effect, such laws would help the spammers destroy email.
A couple of days ago, Slashdot announces an interview with the CEO of Red Hat. I ask, more or less, "Why the hell don't you have educational discounts?" The question goes to +5, which presumably means it gets forwarded to CEO Szulik. Other posters from educational institutions follow-up my post, to the effect that they are already planning to abandon Red Hat rather than eat the steep price hike to Red Hat Enterprise.
And now, Red Hat has educational discounts.
We have hundreds of systems running supported Red Hat versions from 9 back to 7.1, and a small number of systems running manually-maintained 6.2 on projects that are particularly sensitive to library fiddling. As you should know, the free version of Red Hat's up2date service is restricted in a few ways: notably, the last time I checked it permits only a single host per registered user, and it allows access only to a busy FTP site which is frequently not usable.
Those of a criminal persuasion might be tempted to suggest that we defraud Red Hat by manipulating the Red Hat Network registration system. Since we are a research institution and not an enterprise of organized crime, this sort of thing is not an option for us. We require procedures which are legal, not crooked -- and in any event, the Red Hat Network facility is going away along with the expectation of future security patches available for current Red Hat Linux systems by this or any other facility (such as FreshRPMs).
For what it's worth, for systems I administer I don't see the need for commercial software support. (Heck, I use Debian for servers and my own workstation.) However, this is not the position that our scientists are in, and they would prefer a commercially-supported system. If Red Hat prices itself out of our market -- which they seem aimed to do -- that will probably end up being SuSE.
That is precisely what I said, and what I meant. FreshRPMs redistributes Red Hat's backported fixes for Red Hat Linux releases. It doesn't strike me as a good bet to expect that to continue when the upstream source of those fixes (Red Hat's support for Red Hat Linux) dries up.
Our scientists are not in a position to use a distribution with Fedora's promised rapid release cycles. We require more stability than that, particularly in ABI for third-party applications (including proprietary ones such as MATLAB).
Fedora is documented by Red Hat as targeting developers and early-adopters who are willing to do this rapid-release schedule rather than the backported-fixes model. Our scientists are not within this target market. We are overall far more likely to use slow-and-stable Debian than fast-and-flaky Fedora, although a commercial distribution like SuSE or Mandrake has some advantages.
We have twice, over the past few years, attempted to contact Red Hat regarding site licensing or educational volume licensing for access to Red Hat Network. Both times the answer has been that -- unlike Sun, Microsoft, Apple, and our other OS suppliers -- Red Hat has no licensing programs for the education and science markets. For this reason, we have turned our Red Hat Linux users away from Red Hat Network and towards FreshRPMs APT as a source of regular software updates.
With the discontinuation of the Red Hat Linux product line, we are now at an impasse. We do not expect FreshRPMs to conjure up security and bug-fix updates for a system that will no longer be supported upstream. My clients would prefer a more guaranteed solution than FreshRPMs. However, Red Hat still shows no signs of interest in the education and research market. Fedora is not an option, as we can't expect our science staff to accept major upgrades every 2-3 months -- they are science nerds, not Linux nerds.
Is there any chance that your plans for Red Hat Enterprise Linux include site- and volume-licensing oriented at the educational and research community? For if not, my colleagues and I will have a hard row to hoe -- migrating existing Red Hat Linux users to supportable distributions such as SuSE or Mandrake.
Thanks for your response -- it leads me to clarify exactly how I meant to relate liberated computer use, programming, and logic. I don't mean to call programming useless, especially as it isn't; rather, I mean that it is the wrong place to start looking for freedom from the machine. The right place to look is mathematics and logic. If one understands these, one can learn programming languages and skills as needed. However, if one lacks these, one will be even more inept at programming than one is at a GUI.
Logic is a prerequisite to computer freedom, as well as to programming. If one unprepared by logic delves into programming, I suspect we can all predict the result. I've seen code written by people who've tried to get into C or Perl without basic mathematics: it's rather akin to the sounds a baby makes before its nervous system is developed enough to allow syllables. It shows effort, but the underlying control is simply not there.
I suspect, by the way, that the tyranny of the machine and that of its human controllers are tyrannies closer-allied than you have implied. We need only inspect the thorougly abused user: the poor fellow whose computer is riddled with viruses, adware, spyware, spamware, antisoftware of all kinds. The tyranny of his ignorance exposes him to the false belief that this is normal; and also to the specific abuses of these noxious programs' controllers. He would benefit if he could seize control of his computer and throw off the tyrants. However, he neither realizes this is possible, nor does he have any handhold by which to seize it.
In the olden days, there was an expression used to refer to those disciplines and sciences deemed necessary to the free man. That expression was the liberal arts. Though today we might associate that phrase with endless "humanities" classes, or with a college degree not useful for any particular career, of old it meant simply those arts -- practices -- necessary to exercise the liberty of a free citizen. The classical liberal arts were seven: grammar, rhetoric, logic, arithmetic, geometry, astronomy (for which read "physics other than ballistics"), and music.
(Please note that literary criticism, social theory, and deconstruction are not named among the liberal arts.)
We still recognize (I hope) that one who cannot recognize a fallacy in argumentation, or who cannot do arithmetic, is severely impaired in exercising the freedoms of man and citizen. A person who is unacquainted with works of literature may miss cultural references in a politician's speech, but a person unable to cope with rhetoric and logic cannot even tell if the speaker is contradicting himself. Likewise, one who cannot add and subtract cannot tell if he is being cheated in the marketplace.
From a classical viewpoint, what Evans is suggesting is that an understanding of computation has become a liberal art: a discipline necessary to exercise freedom. It is unfortunate and misleading, however, to frame this in terms of "programming languages" or "command lines" -- both of which are simply abstractions (just as is the GUI) on top of the mathematics of computation. The essence that must be understood is no language other than mathematics.
(As an aside: Historically, computer science -- which has little, I might note, to do with "knowing programming languages" -- is an outgrowth of mathematical logic, which is itself an extension of the liberal arts of arithmetic, geometry, and classical (syllogistic) logic. Thus, Aristotle and Dodgson, to pick two, prefigure Turing and McCarthy.)
The same fundamental calculi of functions, algorithms, and Boolean binary logic underlie all of the abstractions we may encounter in computing. GUIs, shells, assemblers, virtual worlds -- all of these are necessarily founded upon the same mathematics. No matter how complex the language or how pretty the interface, it must abide by mathematical logic or it cannot function.
Thus, if Dylan Evans seeks, with Neo, "the code behind the graphics", he should not look to the Unix shell, to C, or even to machine code to find it. Those are tools, not truths, and freedom comes with understanding truths, not simply with mastering tools. Learn the liberal arts -- mathematics and logic -- and you will be much better prepared to defend yourself as a free citizen in a computerized world.
And that is called paying the Dane-geld;
But we've proved it again and again,
That if once you have paid him the Dane-geld
You never get rid of the Dane.
Once you have proven that you can be extorted from -- that you will pay the cash demands of those who hold something over your head -- you can expect nothing but more of the same. The more willing you are to "pay him cash to go away," the weaker your position will be the next time the extortionist comes a-viking.
Better far to repel him -- to turn whatever resources and defenses you may have, be they litigious in this case or otherwise -- to prove that you will not be threatened. And, of course, next time to never allow yourself to be put in that position.
Actually, it wasn't. It was a discussion of the ways people use regex in Perl, and of the only other regex notation I'm familiar with besides Perl's.
Did you know that there are thousands of people in the world who discuss all manner of differemces without "knocking" anything? For instance, when biologists who study insects meet biologists who study lizards, they do not rant at one another about whether lizards r0x0r and insects sux0r or vice versa.
Well yes, but I was using "foo" to stand in for any sequence. It was intended as an example of a more full regex syntax.Oh, and don't call me "dude".
It's true that people writing in Perl tend to use regular expressions in places where they're not necessarily appropriate. For instance, algorithmically speaking, subsequence matches are faster than regular-expression matches. (This is why Python has the .startswith and .endswith string methods, and the in operator.) However, the Perl regular-expression engine (PCRE) is optimized to heck and its raw speed can usually overcome this.
That said, the traditional regular-expression syntax is rather arcane. The only real alternative I've seen is the S-expression syntax of cl-ppcre -- the Common Lisp PCRE implementation. This allows you to write complex regular expressions as tree structure rather than as strings of character glyphs.
For instance, in place of the regex string "(?:foo)|(?:bar)|(?:b(a|(?:uz))z)" you can write:
Now, that might not be any clearer to you if you don't know Lisp, but it gets better as the regex gets more complicated. (I've been a little tricky by putting a lot of ?: in the original regex string. That's the code for "I want to do grouping, but I don't want to capture groups into variables." In the Lisp syntax, you have to mark when you do want capture, not when you don't. People writing in Perl usually let their groups get captured even when they don't make any use of the resulting variables.)
Interestingly enough, the authors of cl-ppcre claim that it outperforms Perl -- a remarkable claim, but they seem to have pretty comprehensive statistics as to when it does and when it doesn't. It's odd to think that even though many people think Lisp is slow, compiled Lisp can really be quite speedy for tasks that people usually use a specialized language for.
It doesn't make much sense to say that any particular language was "the first real object-oriented language" because people have different religious beliefs as to what constitutes a "real" object-oriented language.
People get into hideous flamewars about that word "real" when applied to categories like "object-oriented", "functional", or "Christian". :)
On the contrary, the monoculture risk should affect an enterprise decision whether to participate in that monoculture. When making such decisions, people shouldn't take into account the network benefits (such as being able to skimp on staff training on the grounds that "everyone already knows Windows") without taking into account the network risks (such as the increased likelihood of heavy virus outbreak).
It's true that your organization can't change the fact that the majority of the world uses Windows, and as a result the Internet as a whole is subject to DDoS and packet storms from Windows viruses. However, your organization can reduce its own risks by choosing a different system, one that may still feel the second-hand effects of the harm of monoculture but does not receive the brunt of the damage.
But systems are not equally buggy. I discuss this here. No design and no development method is perfect. However, it is incontrovertible that some designs and some development methods yield software that fails less often; that fails less severely; and that fails more recoverably. We can inspect systems' behavior and say that for particular purposes, certain software is better than others. We can say this on the basis of technical facts, not merely marketing claims and promises of "support" and "warranty". We can also say it on the basis of historical evidence -- some systems have failed more often and more severely than others.
A Microsoft Exchange mail server stores users' mail in a binary database, in a proprietary format. A Postfix or Qmail mail server stores users' mail in text files in a simple directory structure. We can make a reasonable (and correct!) prediction that in case of failure, it is easier to recover the content of mail from a Postfix or Qmail system than from Exchange. And, indeed, this is borne out by the experience of administrators: a maildir can get into an inconsistent state, but it's much easier to recover it than to recover an Exchange mail database.
(Note that I'm not describing frequency of failure, but rather severity. We can also make predictions about the former, of course ....)
Security holes are, from an engineering standpoint, simply another kind of failure. We can look at design choices such as privilege separation and chrooting -- applications of the Principle of Least Privilege -- and say that some systems will fail worse than others. A program that can't access files outside of /home/myprog cannot scribble on the kernel in /boot/vmlinuz. A Web server that runs as Administrator on Windows 2000 has opportunities to fail worse than a Web server that runs as www-data on Solaris.
Simply put, there exist objective facts about security design, just as there exist objective facts about, say, civil engineering. Why doesn't the city construct water mains out of balsa wood and bridges out of papier-mache? It simply doesn't work very well. :)
Having trotted out "Database Debunkings" before myself, I agree with you in part. Certainly a relational database can store facts about objects. This is, however, not the same as storing objects themselves. The difference is one of identity.
Chris Date's articles on "OODBMS" seem to deal mainly with the need not to throw away the relational model simply because OO users want more complex data types in order to model objects. This is of course eminently reasonable -- regardless of what data types you are working with, the relational model still makes sense and indeed is required to make your database make sense. It also is orthogonal to the point I was trying to make above.
The crux of my point is that tuples do not carry identity. Tuples are values, not objects -- they are more akin to the number 5 than to the variable x in the C statement int x = 5; The relational model precisely does not let us talk about their position, address, or pointers to them -- it lets us talk about them only as values, and relations as sets of values.
You can have tuples about things which have identity -- after all, customers have identity. To represent customers' identity, we may use unique keys. (Incidentally, because they are not unique, SSNs do not form a candidate key.) However, this is "representing facts about entities which have identity", which isn't what OO users want. They want to store data objects that have identity -- because their objects in core do have identity, and all they want from the database is a persistent object store.
Again: the OO person wants to store objects with identity. The RDBMS offers him the ability to represent facts about objects with identity.
What do I mean by "identity"? Good question. One simple way of putting it is that objects with identity are unique; references to them can be stored, and they can be addressed and updated uniquely by them. References to them (e.g. pointers) can be compared by comparing the references only. The C++ reference variables (or C pointers) first_customer and current_customer point to the same object iff they are themselves equal. We can store a reference to that object by copying a reference variable -- and when we indirect through it later, we know we will get the same object, not merely one with the same values. The relational model does not admit of such objects -- it has no pointers, only values in sets.
(Those familiar with Lisp are reminded of EQ vs. EQUAL.)
Objects in OO can store references to other objects. Tuples in databases cannot; they can only store common values (like foreign keys). A foreign key is not a reference to another tuple; it is simply a value that is noted as being in common with another tuple, which tuple is in a set wherein that value is unique. So when you store facts about an object into a database, how do you store the fact "this object contains a reference to that other one"? Serial numbers as foreign keys? Then how many passes does it take to reconstitute the pointers in core from the serial numbers in the database?
The problem of discerning identity out of facts is not simply hard in computing. It is hard in the real world -- that is why it is a major subject of metaphysics in philosophy. (Which has nothing to do with "metaphysics" in the sense of "supernaturalism".) Those who sweep it under the table as "academic theory" or "irrelevant to business" will get bitten by it later in ambiguous results.
The object-oriented ideology as instantiated in C++ and Java is founded upon breaking data into objects, bearers of identity, which belong to classes, bearers of structure and behavior. (C++ and Java make little account of metaclasses, which are used in more dynamic object systems such as Python's class system and Common Lisp's CLOS. Templates are not metaclasses.) Objects have identity, so they can be equated; they are the unique bearers of attributes about themselves; and each object's structure is dictated by the class to which it belongs.
When object-oriented partisans look at a database, they see its relvars (or table headers) as bearers of structure and think of classes, and its tuples (or rows) as bearers of identity and think of objects. They see a database as a place to store objects persistently.
But this is not what an RDBMS does. An RDBMS isn't an object store; its relvars are not classes and its tuples are not objects. So what is an RDBMS? What is "relational" anyhow? Relational databases are founded upon relational mathematics, which is what you get when you cross set theory with predicate calculus.
Set theory is the branch of math that deals with collections of elements which behave according to formal axioms. Set theory lets you say, for instance, that if you have a non-null set R and a non-null set S, that you can construct a set R*S of all the possible pairs of elements from R and S.
Predicate calculus is the branch of logic that deals with quantified statements about entities. It lets you formalize logical arguments such as the syllogism: All men are mortal; Socrates is a man; therefore, Socrates is mortal. Predicate calculus deals with generalizations and instantiations of those generalizations.
What do we get by combining set theory and predicate calculus? We get a system that allows us to operate upon sets of tuples of values satisfying predicates. A relation holds tuples of values which make some predicate true. For instance, consider the predicate "Person x owes me y dollars." Tuples which satisfy this predicate will be pairs (x,y) for which the sentence is true. For instance, if Fred owes me 40 dollars, (Fred, 40) satisfies the predicate. It could thus be a tuple in the relation described by the predicate -- the one relating people's names to how much they owe me.
With the relational algebra (or an RDBMS) we can do operations upon this relation and others. We could, for instance, select a result set of all those people who owe me more than 50 dollars -- or join this result set with those people's addresses. Whatever result set we ask for will be calculated from the facts in the database. We might get back this result set:
(Barney, 75, 40 Elm Road)
(Megan, 60, 9 High Street)
Now, are the elements of this result set objects in the object-oriented sense? They are not. They do not have identity. The tuple about Barney is not Barney himself, or even a machine representation of him. It doesn't uniquely store attributes of Barney -- after all, we created it by joining tables which also contain such attributes. It is not even, truly, a fact about Barney exclusively -- for it is also a fact about the number 75, and about the address 40 Elm Road. It isn't an object; it's a tuple value, and values do not have identity as objects do.
Moreover, note that by joining, we can construct new relations from old ones. Thus, not only are tuples not objects, but relvars are not classes. After all, in OO we do not create new classes by joining, but by inheritance or encapsulation of old ones -- and creating a new class does not cause it to be instantiated into known-correct objects.
So what does this matter to OO people faced with RDBMS as a
Actually, if you read that article you will find that it is dated January 25 and is a response to another Verisign screwup. That one was similar to the present one, but had specifically to do with "internationalized" domain names -- DNS records for strings with characters above ASCII position 127.
Historians find it important to check the dates of events and documents, so they can know which ones could possibly be responses to which other situations. For instance, an American comedian telling anti-French racial jokes in August 2001 could not possibly be responding to the French objection to Bush's war. Similarly, a document released January 25 2003 cannot be a response to a situation that arises the following September. Time just doesn't work that way.
However, it is the ISP's job to maintain service quality for the other thousand people served by the same point of presence that you use. It is its job to protect its service from DoS attacks, to ensure that those who don't have a worm are able to use the service.
Therefore, when a worm outbreak borders upon DDoS, it is very likely in the ISPs' best interest to interfere with it. They should do so minimally, because their purpose in so doing is to minimize its effect on their business and responsible network operators -- not to Quixotically defend irresponsible network operators.
At different stages of an outbreak, and depending on the specific behavior of the worm, an ISP's best response may differ. For instance, if a tiny number of customer hosts are infected and are blasting huge amounts of traffic, the best response may simply be to remove them from the network, or block the relevant ports on the proximal router.
If they call and complain, the first-line technical support can read off a prepared statement, which (when boiled down) says basically this: "Your computer was being used for a Federal crime, breaking in to other people's computers. We shut down the network to protect our other customers from this criminal activity. It's possible your computer was infected by a virus that was being used to perpetrate this crime. Because of this possibility, we didn't call the FBI and report you as the source of the criminal activity. It's your responsibility to keep your computer from being used to hurt other people." They can then go on to offer, for a small fee, a CD of licensed antivirus and worm removal software -- or, for a larger fee, a visit from a technician who will run the same. Connectivity is not restored until the system is clean, whether by this means or any other.
In the case of a widespread outbreak, where more than 5-10% of the client systems are infected, it's probably more expedient to just block the ports on the core routers first. Then find a way of enumerating the infected systems and dealing with them, if it's deemed worthwhile.
Of course, any such measure should be announced. Exactly how to announce it I'm not sure, since many ISP users don't use an ISP mail account (and the ISP must not send spam), nor do they read the ISP's local newsgroup or visit the Web page.
In the case of a local ISP, the newspaper is always an option.
I used to work for a guy who had a saying on this subject: "Locks are to keep your friends out." That is to say, security measures impose barriers to unauthorized access, but these barriers are only so high -- if you have enemies willing to break down your door, locking it will not help you; if you don't, what function does locking serve?
Well, one function of a lock, or a password, is its social effect: it says, loud and clear, "Keep out -- this place is only for those who have the key." Most people want to think of themselves as nice and respectful people. Most people aren't crackers or thieves, and will respect a security measure simply because someone went to the bother of putting it there. Against these people, you set a password on your account simply so they will realize it is not a public resource. You lock your machine room door so they won't wander in randomly in search of a terminal to check their email.
Securing things against concerted attackers is different from securing them from wandering friends. You rarely need to enact security measures that will keep a concerted attacker out forever -- only ones that will keep him out long enough for you to notice his assault and cuff him. Bank safes are rated in minutes: rather than proclaiming a safe "uncrackable", the rating states how long a certain level of attacker will take, to crack the safe. So as long as the bank has their security guard come by more often than that, it doesn't matter that the safe isn't perfectly uncrackable.