Slashdot Mirror

The plural of "virus" is "viruses", not "viriiii.

The plural of "virus" is "viruses", not "viriii.

The plural of "virus" is "viruses", not "virii.

The plural of "virus" is "viruses". It was not a 2nd declension masculine noun in Latin, and therefore does not go to "-i". And it was not "-ius" like filius, so definitely doesn't go to "virii". See Tom Christiansen's page about this.

Well over fifty posts, and no one has called him on such a blatant mispelling.

Oh well, I propose it be made a real word, in the context of computers, kind of like "mouses" is the plural of those pointing devices.

What, you don't think that's a real word either? Damn language nazis...

...not the "cure-all" for a insecure system. Chmod and chgrp are tools, just like /etc/hosts.deny. Security is a combination of a software engineering issue and a policy issue: great security ideas are often poorly implemented, either in software, or by a particular system administrator (*cough*... NT... *cough*).

For example, Windows NT has a much more granular permissions implementation than most Unix systems (NT uses ACLs), but viruses still run rampant on NT boxes due to poor administration. If I had a dollar (or hell, even five cents) for every time I saw someone logged in as Administrator to use M$ Office, I'd be a rich man. The virus problem is even worse under Win9x variants: there aren't any (or very many) security tools, including filesystem permissions, to use.

A well-thought out security policy can guard against most any virus - it's ignorance that viruses prey on, regardless of the OS.

And please: the plural of virus is viruses, not viri or any other abuse of Latin ;). Check out this page for an explanation. (Link kindly donated by a previous /. article.)

being a latin derived word

Yep

has a plural of virii

Nope. Virii would be the plural of virius, which isn't a word. In fact, authorities disagree on the plural of virus -- see here for a reasonably erudite discussion.

The authors' comment on "Virii" is:

"Virii is still completely silly, so don't do that; otherwise, everyone will know you're just a blathering script kiddie.

I think this is a bit harsh, and probably motivated by an otherwise admirable Anglo-Saxonism, favouring "Viruses". For my money, virus in meaning plus etymology is a group of items, treated as a single item which follows the literal Latin meaning of "poison". As a result, it is analagous with "prospectus", and the correct plural is "virus", with a long final 'u'.

For those who are really interested in the reasoning behind this interpretation, this site may be of interest.

Hm -- do you actually know anything about Latin? I would suggest you check Tom Christiansen's detailed page on this topic. Maybe it will help you avoid "shooting off your mouth" in the future.

Can you offer a shred of evidence to support that claim? AFAIK, Tom C. doesn't hesitate to apply an editor's perogative to any documentation in the Perl core.

Yeah, I couldn't remember exactly where I had read the comment when I originally posted, but I remembered that I had found it in the past couple of weeks through Slashdot. With a little searching I turned it up. It is in an article entitled The Sins of Perl Revisited. I'm not trying to complain about the great job that the authors of the Perl man pages have done. I keep a printed copy in my office, and just knowing where to look things up has branded me as the local Perl guru. I couldn't do that without good documentation.

Do you honestly think you can write one book that is better than as you say many?

I would rather you spend your time and energy updating and improving the existing Perl documentation. For example, go to http://www.perl.com/pub/1999/11/sins.ht ml#8.

• Sensei - Started LinuxNewbie.org
  
• Matt Welsh - Wrote a couple of books. his homepage is here
  
• Havoc Pennington - Works on GNOME for Red Hat. His page is here
  
• Tom Christiansen - Did a lot of Perl documentation. More info here
  

Don't try to outsmart yourself with Latin. The correct plural is "viruses".

Natural selection happens. It will happen with this drug. It will happen without this drug. It will happen on a train. It will happen on a plane. It is impossible (or nearly so) to stop. Unless biology changes drastically, evolution will keep going until every strain of every organism is obliterated.

Good biologists laugh, cry and bang their heads in frustration when people worry about whether resistance against some deadly substance will happen. The evolution of many organisms is hard to track because we do not notice great survival pressures bearing down on them. Provide enough pressure, and the organisms will evolve. If a drug, pesticide or herbicide is good enough, it will provide selective pressure. Evolution will happen. It happened against superpesticides that farmers thought would work forever. It happened against our miracle drugs.

The smart doctors and farmers have stopped thinking ridiculous thoughts such as, "Will evolution happen this time?" They know that, somehow, it will. Even if they drive one species to extinction, another one can take its place. They concentrate on finding methods that make their weapons as effective as possible for as long as possible.

Viruses are not living according to the biologists I know. They probably would not call them organisms. Many viruses carry DNA, just as living organisms do. Some carry RNA, and it functions similarly. All DNA and RNA molecules are subject to damage and to errors in base pairing. Mutation is going to happen. When mutation happens, evolution can and will happen.

The promise of carefully designed drugs is that we can keep pace with evolution better. Much drug development is still done with a shotgun. Researchers expose the bugs to chemicals and pick out the effective ones. We do not understand how many antimicrobials work. We just know that they do work and that they are not too toxic. By understanding disease mechanisms, more drugs can be designed and not just discovered. Even when a new bug appears, researchers will be able to discover how it works and to design chemicals that interfere.

Wrong!

alt.comp.virus FAQ

There's another page with some serious analysis of the Latin words

right here

I believe "virus" has a Latin root, which makes the plural "virii". This is distinct from a word such as "data", which is a plural and who's singular is datum.

I can see you haven't read the other postings here lately. You see, your simplified view really was not how Latin worked. Here's the short story from today, and here's the long one from some time ago. Thank goodness we don't have to remember all those rules in English!

I find it painfully but amusingly ironic that you should have used who's improperly in the cited passage above. You need the relative pronoun to be in the genitive case--to wit, whose. I believe this falls under the category of throwing stones in glass houses. :-)

To be honest, the Unix security model is almost as weak as the Windows security model in this aspect.

--tom

_______________________________

No, it's really far more complex than that.

You are correct that it is no mean trick to write a program that can damage the system it runs on, largely irrespective of what kind of system we're talking about. And so long as you can hoodwink some unwitting user into executing that program on their system, that program can, of course, cause damages commensurate with the privileges and capabilities of that user.

What you've failed to consider is how the dramatic cultural differences between Unix and the much-maligned consumerist toys serve to affect the issue to our benefit and their detriment.

Probably the most important of these cultural differences is that Unix has historically been a source-only world. Programs are distributed in the form of source code, code which shall be configured, built, and ultimately installed on the target machine. Programs solely accessible in machine language form fall immediately under a taint of mistrust.

Think back to the last time you read a notice from someone whom you've never heard of before that was asking you to go fetch some random binary program from some random place on the net and then to run that program under full sysadmin privileges? I can already see the incredulous Unix sysadmin reading that and bursting out in uncontrollable guffaws. Because the de facto standard for program interchange in Unix is as source code, a Unix programmer will be far less likely to fall for your ploy than would your average Prisoner of Bill, who has been lulled into gullibility by a binary-only culture.

But for the sake of the argument, let's say that you've found a way to effect this trick. Suppose you're an employee of some reasonably respected company that happens to produce a binary-only distribution of their commercial software, and you decide to sneak something wicked into the binary image. You manage to replace the standard, clean copy on your company's ftp or http server, or even floppies or CDs, with your own naughty version. People are accustomed to downloading from your company, or using your company's floppies, so they do as they've always done, run the installation as the superuser, and you thereby have your way with their system.

If this scenario were to play out, just how dangerous--how destructive--could it really prove? Whom could you harm, and who would be immune to your ploy? The answer is that you could only hurt those folks running the exact platform for which your binary had been compiled, and everybody else is unassailable. By platform, I mean the whole feature vector that includes processor chip (eg Sparc vs Intel), operating system (e.g. SGI vs BSD), shared libraries (e.g. libc vs glibc), and site-specific configuration (e.g. shadowed vs non-shadowed password files.

Let's not get too full of ourselves and pretend that the Unix culture's predilection for source-only program distribution derives only, or even mainly, from altruism. We have no choice in this matter. If you're on Unix, you don't have the source, then you can't run the program on all your diverse systems. And if Unix programmers do not provide source, they cannot hope to have their program as widely used as it would otherwise be.

Consumer-targetted systems from Microsoft or Apple are two instances are a static monoculture, as vulnerable to mayhap as a field of cloned sweet corn. It only takes one genetically engineered virus to bring down the whole field. Unix is different.

In his acclaimed essay, In The Beginning, Neal Stephenson writes:

It is this sort of acculturation that gives Unix hackers their confidence in the system, and the attitude of calm, unshakable, annoying superiority captured in the Dilbert cartoon. Windows 95 and MacOS are products, contrived by engineers in the service of specific companies. Unix, by contrast, is not so much a product as it is a painstakingly compiled oral history of the hacker subculture. It is our Gilgamesh epic.

What made old epics like Gilgamesh so powerful and so long-lived was that they were living bodies of narrative that many people knew by heart, and told over and over again--making their own personal embellishments whenever it struck their fancy. The bad embellishments were shouted down, the good ones picked up by others, polished, improved, and, over time, incorporated into the story. Likewise, Unix is known, loved, and understood by so many hackers that it can be re-created from scratch whenever someone needs it. This is very difficult to understand for people who are accustomed to thinking of OSes as things that absolutely have to be bought.

Let me now return to your particular suggestion, that of a malignant Perl program activated by a Makefile rule at installation time. Because you're talking source code, and because Perl tries rather hard to attain a high level cross-platform intercompatibility, this form of subterfuge would appear exempt from the inherent protections stemming from diversity in variant Unix platforms. So, could your trick be done? How much of a problem could this really be? What might happen?

The answer is that of course, it could be done. And in point of fact, a demonstration model is already available, courtesy of Abigail. Guess what? There's no reason to run around like a chicken with its head cut off: the sky isn't falling. This sort of approach stands little chance of making a big splash, because you aren't going to insinuate it into a place that can affect a lot of people. Sure, you might catch a few folks, but just how long to you think this kind of thing will go unnoticed? Remember, it's in source code. That means anybody who wonders what happened can just look at it. There's a very low barrier to entry. And even if the naughtiness removes itself from your copy once its dirty deeds are done, that naughtiness is still sitting there in plain view for easy inspection back wherever you got your copy from.

Is there a way around this? Well, yes, if you're as clever as Ken Thompson. Fortunately, you aren't, and neither are the crackers. If they were, they'd doubtless receive more Turing Awards for their vaunted efforts. :-)

The only way you're going to get good propagation is if your nastiness into a copy that a lot of people will download and install. There's a very fine reason why so many archives contain a checksum of the image. It's to help with this problem. Security of course depends on several matters, including the strength of the algorithm and the integrity of the authenticating agent. But better that than nothing.

Let's talk about propagation some more. I assume that the goal is to have a notable impact, which means you need to spread your bad code as widely as possible. A hacked up install script, even if all goes to your liking, just doesn't have a very high rate of reproduction. First of all, how often do how many people install this software? Secondly, how do you plan to trick them into doing so? It's not really much of a challenge to get one person to this, especially if they trust. If that's your goal, maybe you'll succeed. But the risk of being traced and apprehended is high.

So how come this stuff can spread like wildfire amongst the OS-challenged? Can't whatever mechanism that's used there be used to get at the rest of us, too?

Over the last few years, a frighteningly frequent conduit of contagion for viral infection on toy systems has been the implicit, automatic execution of code with little or not manual intervention on the part of the box's owner. DOWN THIS PATH LIES MADNESS!. That this can ever, ever happen is as a plain a symptom of complete and total cretinization in the toybox world as you are ever going to see. It's stupid, it's crazy, and it's dangerous. Any programmer who even suggests it needs to go back to flipping hamburgers. Any user who asks for this feature needs to be quietly taken into the back room by the doleful men in long trenchcoats, where he will be told in no uncertain terms that his request is not only in the best interest of no one but criminals, but that he also now has a permanent record even for asking about it.

No, I don't care that a customer asked for it. Customers are idiots, just like any other user. So what if they pay you? They're still idiots, and it's your professional responsibility to act responsibly, to refuse to go along with their madnesses. The customer is not always right. In fact, they're very often wrong. A physician or a lawyer doesn't do whatever the customer requests, and neither do you. They, meaning the customers or users, simply don't have the background and training; they don't have the experience of seeing why automatic execution from untrustable source is the work of the Devil.

It's not as though we in Unix have never seen this issue before. In fact, we've seen it time and time again. And guess what? We recognized the problem and we addressed it. And we don't cater to that kind of lunacy anymore.

Here are a few concrete examples.

Remember when vi would--or at least, could--automatically execute macro commands embedded in a file in a specific way? That was a dubious feature called modelines. On my OpenBSD systems, if I type :set modeline, the program comes back and says set: the modeline option may never be turned on.

Another example of learning from our mistakes is the issue of shell archives. Instead of automatically running the sharfile through /bin/sh, there are specially made unshar programs that will do the common things, safely, and nothing else.

When CGI was first getting big, owners of toy systems would blindly install compilers and interpreters in such a way that these would easily execute arbitrary content coming in off the wire. Despite my pleas, both Netscape and Microsoft were actually advocating this! After a year of warning admins not to do this, and sending mail to the companies who were saying to just go ahead, nothing changed. So I released latro. Then and only then did various companies retract their suggestions, even though they'd been aware of the nature of the problem for a long, long time. Sure, you could be equally stupid on Unix, but for some reason, we weren't. History counts.

Implicit execution of untrusted material is simply stupid beyond words. And for some reason, the toybox people keep falling for the same chump moves, from MIME attachments to word processor and spreadsheet macros to embedded active scripting controls. I don't know quite why they just keep doing this crap. My hunch, and it's only a hunch, is that this is happening because Microsoft and their moronic minions simply cannot for the all the tea in China ever manage to think outside of their quaint but completely fictional little single-user universe. Maybe they don't hire people who come from a background in multiuser and/or networked computing systems. Maybe they don't hire people with real experience at all, just script-kiddies trying to make a buck legitimately but with no true understanding. Maybe the software makers simply can't say no to a customer request, no matter how suicidal they know that request to be. I don't know.

Whatever the cause, decades of history are completely and repeatedly ignored. They keep making the same mistakes, and they don't fix the underlying causes. Sure, there are things that are hard. Denial of service attacks are hard. People who know exactly all the ramifications of IP who go sending maliciously hand-crafted packets aren't much fun either.

But these highly technical ploys aren't why most folks on their toyboxes are being screwed up, down, left, right, and sideways. They're being screwed because of very simple matters. They don't have the notion of a protected execution mode. They don't have file permissions or memory protections. They automatically execute content willy-nilly, often with complete access to the whole machine. They expect a program to show up in binary not source form. They don't compare robust checksums from a strongly authenticated sources. They live in an infinitely vulnerable monoculture. They expect things to just magically happen for them without a thought or a care, and guess what? Their wishes are duly granted, much to their eventual dismay.

It is possible that mass-market factors may someday end up plaguing Unix systems in ways not so far removed from the stupidities that the toy boxes are riddled with. We just have to tell them no, and to condemn in the strongest and loudest possible terms any backsliding into insecurities that if we ever had, long ago banished. Looking at the Winix phenomenon, in which a dozen different vendors put together and ship their own Linux operating systems, all specifically constructed to be user-obsequious and Unix-hostile all in order to appease the lowered expectations of a hundred million Windows idiots, who, despite their numbes, really can still be wrong. The stupidity of the masses must never be underestimated.

secondly, even if it is Latin, "virii" is not a correct Latin pluralization! ("Viri" would be.)

Not all nouns that ended in -us became -i in the nominative plural. Only second declension masculine nouns did so. There are several (I can think of three) other flavors of -us nouns, none of which follows that rule.

1. 2nd declension "irregulars", which were either full-time or part-time neuters and often of Greek descent, such as pelagus/*, vulgus/*, and the interesting case (as it were :-) of cêtus/cêtê.
2. Nouns from the 3rd declension, like corpus/corpora, genus/genera, and tempus/tempora.
3. Nouns from the 4th declension, like status/statûs, apparatus/apparatûs, and prospectus/prospectûs.

So virus fails to follow the focus/foci rule for at least three different reasons:

1. Virus was not masculine, but neuter.
2. Virus was not a count noun, but a mass noun, like vulgus, which was also (usually) neuter.
3. Virus probably wasn't even from the 2nd declension, but from the 4th declension.

I implore you, Mr Penguin, to read this FMTEYEWTK on the matter. Latin just didn't work the way you claim that it did, and neither does English.

--tom

The computer *is* the game

[ Reply to This | Parent ]

Re: More "News for Nerds" Please... (Score:7, Brilliant)
by Hemos (hemos@slashdot.org) on Thursday January 06, @05:08PM EDT
(User Info) http://hemos.net

Recently disturbed by News for Nerds thread, but inspired by Tolkien, I wrote this:

I sit beside the screen and think
Of all that I have seen
Of flaming trolls and clueless nerds
And topics that have been.

I sit beside the screen and think
Of how Slashdot shall be
When programs come without a source
That I shall ever see.

[ Reply to This | Parent ]

Re: More "News for Nerds" Please... (Score:3, Funny)
by Tom Christiansen (tchrist@perl.com) on on Thursday January 06, @05:15PM EDT
(User Info) http://language.perl.com/

Sure, Hemos, rig it so you get a 7. Sheesh! That's what happens when *you* have the source code. :-)

--tom

The computer *is* the game

[ Reply to This | Parent ]

Re: More "News for Nerds" Please... (Score:7, Brilliant)
by Hemos (hemos@slashdot.org) on Thursday January 06, @05:08PM EDT
(User Info) http://hemos.net

Recently disturbed by News for Nerds thread, but inspired by Tolkien, I wrote this:

I sit beside the screen and think
Of all that I have seen
Of flaming trolls and clueless nerds
And topics that have been.

I sit beside the screen and think
Of how Slashdot shall be
When programs come without a source
That I shall ever see.

[ Reply to This | Parent ]

Re: More "News for Nerds" Please... (Score:3, Funny)
by Tom Christiansen (tchrist@perl.com) on on Thursday January 06, @05:15PM EDT
(User Info) http://language.perl.com/

Sure, Hemos, rig it so you get a 7. Sheesh! That's what happens when *you* have the source code. :-)

• Tom Christiansen is an author and lecturer...

Tom Christiansen is not someone who has planned, staffed, lead or coded a large, commercial software project at any time since the "e-commerce explosion" began in 1995 or so. Tom Christiansen is a zealot so blinded by his Perlcentrism, that he predicted that Java would be too complicated to catch on with "ordinary programmers." [LOL]. More humor at perl.org is a three-year-old rant about how some Perl vaporware is going to squash Java completely.

I find it endlessly hilarious and completely ironic that Tom repeatedly accuses people of not understanding the basic realities of the programming world. Utterly hilarious.

• Tom Christiansen is an author and lecturer...

Tom Christiansen is not someone who has planned, staffed, lead or coded a large, commercial software project at any time since the "e-commerce explosion" began in 1995 or so. Tom Christiansen is a zealot so blinded by his Perlcentrism, that he predicted that Java would be too complicated to catch on with "ordinary programmers." [LOL]. More humor at perl.org is a three-year-old rant about how some Perl vaporware is going to squash Java completely.

I find it endlessly hilarious and completely ironic that Tom repeatedly accuses people of not understanding the basic realities of the programming world. Utterly hilarious.

Obfuscated maybe but CPAN gives perlpossibly the most reusable collection of code in use. This is one of the features that makes perl so enduring. Download a perl CPAN package, read some POD documentation and within mintues you can saving hours of work.

Perl is then maybe the most reused language on the planet.

Perl is good because of the flexability. Perl, for me, is GREAT because of the huge number of modules that allow you to do things that normally would take C/C++ API calls. It's slower that the API call, obviously, but you can't beat it for prototyping and problem-solving.
Don't believe me? Check out http://www.perl.com/CPAN/ and scroll through the vast listing. The strength of Perl in the number of appplications it's been applied to is, indeed, a strenght of the language. For example, I recently had need of a dirt-simple SMTP server. I could have written it in Perl, C, any number of languages that allow socket programming. But Perl had an easy to use, OO-based module that allowed me to setup and accept messages from clients in less than 10 lines of code.
Nothing fancy, but I didn't need fancy. If I had wanted a "real" SMTP server, I would have found/built it in C, or used an external program. But Perl has, so far as I can tell, the greatest number of easy-to-use modules for a variety of tasks I've ever seen.

As for OO, Perl got it because it helps solve certain problems well, and it's a cool buzzword. :) Seriously, a lot of modules use it exclusivly now, and I personally prefer OO syntax to "standard" Perl syntax in many cases (using CGI.pm, for instance). And, save for those modules and the tie functionalty, you don't have to use OO if you don't want to. There's more than one what to do it!

Why though? Why return the year minus 1900 if the intent is NOT to get a 2 digit year? And if the intent is to get a 2 digit year then clearly the code has a Y2K issue as it no longer does so.

As noted, the code itself returns exactly what it says it will upon them turn to the year 2000. The assumption of others that the code must, for some reason, generate a 2-digit number is odd, at best. Think this way; given that you have a eventual rollover to 2000, or even, say, 1900, or 1800, or any 4-digit time, what would _you_ do to solve the problem? This solution gives a small number (>255), is highly flexable, and did not break when the century changes. Code that makes assumptions based upon not reading documentation is, sometimes, asking for failure.

Alt. solutions? You could have it return seperate times for pre and post 2K, or even have two seperate functions. This is similar to what is occuring now, and some would say is no different, after all, people are changing code left and right. The 1900 + solution, however, gives one set of numbers that will work indefinitly, given that you add correctly.

Or, you could have the function simply return the 4 digit year. Actually, localtime, when called in scalar context, does exactly that. They could have simply said, "We'll find a better soluation later", and gave out the last two digits. But, that solution also goes aganist the other date/time code in Unix, which is based upon a running count of time. Instead, they found a solution that would work over a longer span of time, if the programmer looked to his code properly at the beginning.

If the intent is NOT to get a 2 digit year, what is the intent? The function returns 'the year minus 1900' then we have to 'add 1900' to get the correct year.. how does this make sense? Given all of that information, I think it would be a reasonable mistake, and as such not treated so.. hrm.. arrogantly?

It is a reasonable mistake -- if you have not read the localtime information. You list the page http://language.perl.com/news/y2k.html -- did you read it before you coded? Or the man page for localtime? Or the listing for localtime in _Programming Perl_, _Perl in a Nutshell_, etc? All of these mention the 1900 + issue. And that page tells you how to fix the very problem you refer to. If you refer to Usenet/Mailing list messages, then you might have a point. But I find it hard to believe that the localtime issue was not mentioned. There's even a contest about it!

In short, Y2K issues in Perl come from assuming, and not reading the basic info about the functions in use -- information that comes with the program, and is not hidden away in a dark corner of the documentation. In fact, you must read this info in order to use the function at all! Adding numbers to 1900 makes sense in the context of the majority of uses for such a function, does not break upon transition to a new century, and can be easily switch from 1900 to 2000 and back, used in 2 digit or 4 digit mode without loss of information, while you work with less data all the while. What could be better?

The equivalent to your python code in Perl is as simple as the following:

for (@array_of_things) {
print;
}

# look -- indentation is irrelevant!
for (@array_of_things)
{
print;
}

# so is that trailing semicolon
for (@array_of_things) { print }

# :-) suppose i, good be can postfix
print for @array_of_things;

# this one is a tad different
print "@array_of_things\n";

# this one could be best, depending on formatting
print @array_of_things;

# and then there's this one
print join("\n", @array_of_things, '');

# Or this:
{
local($\, $,) = ("\n", "\n");
print for @array_of_things;
}

I believe that it's easy to write beautiful code in Perl if you want to. I'm very sad that people don't want to. Here's one old example where I've made a stab at using indentation to make nice code. I could probably put a bit more work in it. I've many more recent examples as well, if you care. I believe seeing good examples of well-formatted code is critical for a beginner. We tried to do that in the Perl Cookbook, but there's always room for more.

"We are just using an entirely new way to represent the date that isn't more human readable, or more machine friendly, that just happens to look exactly like the standard 2 digit year format until the year 2000 occurs, at which point it still works exactly as planned."

It's clearly documented. Always has been. You were just guessing how localtime(3) behaved instead of looking it up and reading the precise behaviour. A library API is a contract. If you sign up to using that library without reading the fine print, then you cannot complain when that fine print bites you in the ass. Stop guessing, and read!

You are incorrect in your assumption that this is somehow peculiar to Perl. Whether it's peculiar in general is another question entirely. :-) I wrote about this in a letter to Dan Gillmor. Essentially, you need to understand a struct tm. Apparently the situation is even worse in Java Script, where it appears that different implementations behave differently.

If you're on the cutting edge of Perl technology, please pay special attention to the new -DPERL_Y2KWARN configuration option. It produces an effect like this:

% perl -we 'printf "Year is 19%d\n", (localtime)[5]'
Possible Y2K bug: %d format string following '19' at -e line 1.
Year is 19100

The following information about Perl and the year 2000 is a modified version of the information that can be found in the Frequently Asked Question (FAQ) documents.

Does Perl have a year 2000 problem? Is Perl Y2K compliant?

Short answer: No, Perl does not have a year 2000 problem. Yes, Perl is Y2K compliant (whatever that means). The programmers you've hired to use it, however, probably are not. If you want perl to complain when your programmers create programs with certain types of possible year 2000 problems, a build option allows you to turn on warnings.

Long answer: The question belies a true understanding of the issue. Perl is just as Y2K compliant as your pencil --no more, and no less. Can you use your pencil to write a non-Y2K-compliant memo? Of course you can. Is that the pencil's fault? Of course it isn't.

The date and time functions supplied with perl (gmtime and localtime) supply adequate information to determine the year well beyond 2000 (2038 is when trouble strikes for 32-bit machines). The year returned by these functions when used in an array context is the year minus 1900. For years between 1910 and 1999 this happens to be a 2-digit decimal number. To avoid the year 2000 problem simply do not treat the year as a 2-digit number. It isn't. When gmtime() and localtime() are used in scalar context they return a timestamp string that contains a fully- expanded year. For example, $timestamp = gmtime(1005613200) sets $timestamp to "Tue Nov 13 01:00:00 2001". There's no year 2000 problem here.

That doesn't mean that Perl can't be used to create non- Y2K compliant programs. It can. But so can your pencil. It's the fault of the user, not the language. At the risk of inflaming the NRA: ``Perl doesn't break Y2K, people do.'' See http://language.perl.com/news/y2k.html for a longer exposition.

If you want perl to warn you when it sees a program which catenates a number with the string "19" -- a common indication of a year 2000 problem -- build perl using the Configure option "-Accflags=-DPERL_Y2KWARN". (See the file INSTALL for more information about building perl.)

"We are just using an entirely new way to represent the date that isn't more human readable, or more machine friendly, that just happens to look exactly like the standard 2 digit year format until the year 2000 occurs, at which point it still works exactly as planned."

It's clearly documented. Always has been. You were just guessing how localtime(3) behaved instead of looking it up and reading the precise behaviour. A library API is a contract. If you sign up to using that library without reading the fine print, then you cannot complain when that fine print bites you in the ass. Stop guessing, and read!

You are incorrect in your assumption that this is somehow peculiar to Perl. Whether it's peculiar in general is another question entirely. :-) I wrote about this in a letter to Dan Gillmor. Essentially, you need to understand a struct tm. Apparently the situation is even worse in Java Script, where it appears that different implementations behave differently.

If you're on the cutting edge of Perl technology, please pay special attention to the new -DPERL_Y2KWARN configuration option. It produces an effect like this:

% perl -we 'printf "Year is 19%d\n", (localtime)[5]'
Possible Y2K bug: %d format string following '19' at -e line 1.
Year is 19100

The following information about Perl and the year 2000 is a modified version of the information that can be found in the Frequently Asked Question (FAQ) documents.

Does Perl have a year 2000 problem? Is Perl Y2K compliant?

Short answer: No, Perl does not have a year 2000 problem. Yes, Perl is Y2K compliant (whatever that means). The programmers you've hired to use it, however, probably are not. If you want perl to complain when your programmers create programs with certain types of possible year 2000 problems, a build option allows you to turn on warnings.

Long answer: The question belies a true understanding of the issue. Perl is just as Y2K compliant as your pencil --no more, and no less. Can you use your pencil to write a non-Y2K-compliant memo? Of course you can. Is that the pencil's fault? Of course it isn't.

The date and time functions supplied with perl (gmtime and localtime) supply adequate information to determine the year well beyond 2000 (2038 is when trouble strikes for 32-bit machines). The year returned by these functions when used in an array context is the year minus 1900. For years between 1910 and 1999 this happens to be a 2-digit decimal number. To avoid the year 2000 problem simply do not treat the year as a 2-digit number. It isn't. When gmtime() and localtime() are used in scalar context they return a timestamp string that contains a fully- expanded year. For example, $timestamp = gmtime(1005613200) sets $timestamp to "Tue Nov 13 01:00:00 2001". There's no year 2000 problem here.

That doesn't mean that Perl can't be used to create non- Y2K compliant programs. It can. But so can your pencil. It's the fault of the user, not the language. At the risk of inflaming the NRA: ``Perl doesn't break Y2K, people do.'' See http://language.perl.com/news/y2k.html for a longer exposition.

If you want perl to warn you when it sees a program which catenates a number with the string "19" -- a common indication of a year 2000 problem -- build perl using the Configure option "-Accflags=-DPERL_Y2KWARN". (See the file INSTALL for more information about building perl.)

Hey, that's "you ignorant splut!"...

You might try satire. It seems to work better for me. I've got about seven more of those waiting for the right moment. :-)

tchrist's article on Extreme Keyboarding is something of a pæan to vi.

I know a lot of pianists who prefer vi. This must say something.

I nominate Tom Christiansen for best poster. His articles ranged from the hilarious to the insightful to the informative. And yes, I've been saving his links. :-)

I nominate Tom Christiansen for best poster. His articles ranged from the hilarious to the insightful to the informative. And yes, I've been saving his links. :-)

I nominate Tom Christiansen for best poster. His articles ranged from the hilarious to the insightful to the informative. And yes, I've been saving his links. :-)

I nominate Tom Christiansen for best poster. His articles ranged from the hilarious to the insightful to the informative. And yes, I've been saving his links. :-)

I nominate Tom Christiansen for best poster. His articles ranged from the hilarious to the insightful to the informative. And yes, I've been saving his links. :-)

I nominate Tom Christiansen for best poster. His articles ranged from the hilarious to the insightful to the informative. And yes, I've been saving his links. :-)

What CPAN.pm does is bridge the gap between your desktop perl code and the rest of the world, with both elegance and great functionality. The CPAN itself, in collaboration with CPAN.pm, has made perl the first popular programming language that lives and breathes on the internet.

Jamie McCarthy

Here's the start:

Abstract

Before use Coy: run
code...read rebuke. After use
Coy: run code...haiku!

Introduction

Error messages
strewn across my terminal.
A vein starts to throb.

Their reproof adds the
injury of insult to
the shame of failure.

When a program dies
what you need is a moment
of serenity.

The Coy.pm
module brings tranquillity
to your debugging.

The module alters
the behaviour of die and
warn (and croak and carp).

It also provides
transcend and enlighten, two
Zen alternatives.

Like Carp.pm,
reports errors from the
caller's point-of-view.

But it prefaces
the bad news of failure with
a soothing poem.

Haiku as error messages

The use of haiku
to couch an error message
is by no means new.

The easiest way
to ornament errors is
with a "canned" haiku.

Salon magazine
suggested this approach in
1998.

They asked readers to
submit error messages
written as haiku.

The winning entries
are now widely known. The best
of them is perhaps:

Three things are certain:
Death, taxes, and lost data.
Guess which has occurred.

But just as canned fish
soon grow less appetizing,
so too canned poems.

Inevitably,
constant repetition robs
them of their piquance.

Besides, there are too
many error messages
that need a haiku.

Perl's diagnostics
alone would require just
under 500.

And, of course, there's an
endless supply of user-
defined messages.

Here are references for you:

• The paper referenced above
• Damian's directory on CPAN
• The Coy.pm module itself
• Damian's home page

I imagine that this module will now allow ending haiku postings on Slashdot.:-)

Here's the start:

Abstract

Before use Coy: run
code...read rebuke. After use
Coy: run code...haiku!

Introduction

Error messages
strewn across my terminal.
A vein starts to throb.

Their reproof adds the
injury of insult to
the shame of failure.

When a program dies
what you need is a moment
of serenity.

The Coy.pm
module brings tranquillity
to your debugging.

The module alters
the behaviour of die and
warn (and croak and carp).

It also provides
transcend and enlighten, two
Zen alternatives.

Like Carp.pm,
reports errors from the
caller's point-of-view.

But it prefaces
the bad news of failure with
a soothing poem.

Haiku as error messages

The use of haiku
to couch an error message
is by no means new.

The easiest way
to ornament errors is
with a "canned" haiku.

Salon magazine
suggested this approach in
1998.

They asked readers to
submit error messages
written as haiku.

The winning entries
are now widely known. The best
of them is perhaps:

Three things are certain:
Death, taxes, and lost data.
Guess which has occurred.

But just as canned fish
soon grow less appetizing,
so too canned poems.

Inevitably,
constant repetition robs
them of their piquance.

Besides, there are too
many error messages
that need a haiku.

Perl's diagnostics
alone would require just
under 500.

And, of course, there's an
endless supply of user-
defined messages.

Here are references for you:

• The paper referenced above
• Damian's directory on CPAN
• The Coy.pm module itself
• Damian's home page

I imagine that this module will now allow ending haiku postings on Slashdot.:-)

Over the past couple years, hundreds of emails have piled up that I should have replied to and handled in some way, but I didn't because I was both busy and lazy. At the same time, I've been accumulating quite a few books about things I want to learn. They sit on a shelf or the floor, mostly unread. Sometimes I look at all that I am supposed to be doing and want to do, and it's just overwhelming. My time management is severely lacking. The dawn of the 2000s (with the 3rd millennium / 21st century now less than a year away) provides an excellent opportunity to get my life in order.

I've given some thought to how I can learn and do more while enjoying a less chaotic life. Rather than just semipassively dealing with things as they come, I need to set specific goals and outline incremental steps toward their achievement. These steps should be mapped into a timetable that I will make a sincere effort to follow. This will not and should not be rigid, but should allow flexibility and changes as appropriate. I'm not going hard-line on myself -- just trying to apportion my time in an optimal manner.

Here's an example of how I intend to work this: I would like to learn Perl in the first half of this year. I own O'Reilly's Learning Perl book, which has 19 chapters. I'm in chapter 2. All I need to do is read at least three chapters per month (trying for one a week), and I should have enough basic skills to make my website more dynamic. It's easy to allocate an hour here and there for a trivial chunk of reading. What's important is that I stick to it.

I'll probably read several books concurrently so I don't get bored or frustrated with one while another one like Java beckons enticingly. No log jams here. :)

I'm not limiting this time management approach to just books, either. There are some things I seriously need to work on IRL. Exercise is just one of these. I've found it hard to drag myself to a nearby health club for a few minutes every week. Well, I'm going to step it up, because a healthy body leads to a healthy mind... or at least a better lifestyle.

But the point of this message is that I believe that self-discipline is the key to achieving goals and making the most of the time and resources God has given us.

Happy 2000!

I take exception with your nick, Mr Gnu's-Not-Good. I believe you are speaking ill of the Good Software Group, without whom no good could come of any software. Don't you realize how evil you are? :-)

Try Activestate for your download. The clipboard module can easily be used to write a convenient utility to demoronize your html.

Oh right, and take a look at The Perl Power Tools. Put a few of those in your path and it may do something for your sanity.

OTOH you could just install Linux and look innocent... :-)

Cheers,
Ben

finish learning your latin conjugations.

[singular] virus
[plural] virii

No discs are shiny acrylic things. Disks are probably what you're talking about. And hard drives work too.

Even if Red Hat goes bankrupt tomorrow, all their code will be around for anyone to use. And just as importantly, their code will not be used in a way that is harmful to the Open Source communitiy, such as in a closed source distro by Microsoft or another giant corporation. Why? Because of the GPL.

The commercial BSD vendor, Berkeley Software Design, Inc., and Eric Allman's companym, Sendmail, Inc., share several characterics. (Note: I may be wrong about some of the following. Corrections welcome) They both started with free software. They both added proprietary enhancements. The both sell their value-added product as a revenue source. Both give you source code to the product you bought. And both forbid you from redistributing that source or changes to it to those who don't hold a licence.

Two critical questions are:

1. What's the current technology transfer? To what extend do corporate BSDI enhancements return to the free BSD distributions?
2. If these companies go down, what happens to their code? Licence holders still have the source, but so what? Is it dead?

To add one more pair of companies to the stack, consider John Ousterhout's TCL-based Scriptics company, or the Canadian Perl-related firm, ActiveState. My understanding is that there's more technology transfer between these two companies and their core free software roots than might be immediately obvious with the previous pair. I cannot really speak of the TCL world, but in the case of the Perl one, that firm funds not only the salary of the Perl release manager, they also fund development for porting to non-free systems. For example, they've made Perl's fork() call work "right" on Microsoft systems (actually, Microsoft paid for that work!) and have immediately returned those corporately funded enhancements back to the world of free software.

Yes, that means that the current developer release of Perl, version 5.005_63, supports fork(2) with Unix semantics even on Microsoft. Hurray!

If you want other mixed-mode business models, think about Alladin Ghostscript. The interesting issue of licensing is covered in the FAQ. There's also Sleepycat Software, whose database product, Berkeley DB, was used in Netscape with neither credit nor compensation, thus triggering a good bit of bad blood on the authors' parts because of lack of public recognition and appreciate for their work. The resulting `poison pill' licence seeks to avoid a repeat of this unpleasantry.

Now, we have in contrast to those situations, look at companies that are making a business, or trying to make a business, out of GPL'd software. The two most obvious examples, RHAT and LNUX, are hardly typical cases due to their current market valuations, which are obviously astronomically overvalued. But even in their cases, you'll find things that aren't what you would call "free software". In fact, they aren't even open source; look at the way Redhat ships "demo versions" of things without source. Now, I would be willing to argue that this is in fact a good thing because it shows people that Redhat's operating system is a viable platform for traditional licensed software. Others, however, dispute this, pointing out that that software would be orphaned if the company who produces it were to die.

My point is that I believe we now have a sufficiently long list of corporate endeavours which are based, at least with respect to some definitions of the term, free software. That means we have actual cases to look at, not hypothetical cases. I'm sure I've only named a couple of them here. What about other companies? I'm not talking about simple packagers and distributors. I mean firms that do serious development work based on free software. (I would mention Cygnus, but they've recently become an acquisition by Redhat.)

Do we have examples of companies that have died or otherwise abandoned their work in these areas? The university Ingress experience and Britten-Lee? Can we come up with other examples to look at? What has happened to the product of their work? Has it truly gone the way of all things, or did humanity derive some benefit from it?

For those of you who are thinking about speech as the interface of the future, doubtless you are correct for some cases. However, there will always be a place for precision work. Think about CAD programs. Can you imagine just speaking to them and getting the accuracy you need? Plus, until we have programming languages that are redesigned not to use punctuation that need be spoken, you'll be able to enter your code much easily with a keyboard.

Hmmm... I think you really do lose some of the power if the interface isn't perfect... example: make menuconfig is *far* more navigable and easy to use than make xconfig. hands stay on keyboard - tab, space, enter, and the up/down arrows are all you need to *quickly* get around (and F1 is close for descriptions). xconfig doesn't allow you to scroll through choices with the arrow keys - you *need* to use the mouse. That alone slows things up considerably...

As you see, mere aggregation with the infected Jack does not pass the virus back up to Mom, nor over to his sister Jane. Aggregation does not infect. This is true whether Dick and Jane are programs, or whether they are libraries. It doesn't matter. I'll say it once more for the logic-impaired: Aggregation does not infect. Otherwise they are trying to dictate what is or is not legitimate use. Copyright law does not permit this.

If the FSF shows up to break your kneecaps, as another poster semi-amusingly seemed to imply might happen, and so you feel need a more legalistic way around this library infection issue, here's why you're safe.

It's time to let go of your fear. The virus doesn't transmit across library aggregation. The reign of terror is ended, and the black death is put back into its bottle. You are now free. Code in peace.

Free Software is *NOT* "freeware"

I am not now nor have I ever been a member of the so-called `goodware' movement. I am the founding father of `Good Software' movement, which is completely different.

-- Gilbert Oram Dawson

I could say more about the intentional deception, but you should just laugh instead.

Linux has much better documentation

Take Redhat/Linux, for example (please :-). Most of what Redhat ships is undocumented, and that which exists is severely underpowered compared with BSD.

For example, let's suppose you'd like to learn about the interface to the system's terminal drivers. That's in tty(4).

redhat% man 4 tty | wc -l
66

redhat% find /usr/man/man4 '*.*' -type f -name -print | wc -l
62

openbsd% man 4 tty | wc -l
299

openbsd% find /usr/share/man/cat4 '*.*' -type f -name -print | wc -l
371

And that's just part of it. Here's a bug list on Redhat docs that I've submitted, along with programs to automatically detect these problems. You should really read those over to start to get a feel for how bad it is.

I'd like to make clear that redhat has done a very great job at fielding these bugs and trying to do something about them. I am completely happy with their customer service. I'm not trying to knock that.

Some of the tools I used for this are:

• cfman - make sure manpages have accurate SEE ALSOs
• no3man - identify which library calls aren't mannable
• noman - identify which commands are installed without manpages
• scatman - find turds in mantrees

My point of view is that it isn't fair to the user of your system for you to ever include something that isn't documented. When I have been part of releases, either the old Unix releases from years ago or even the new Perl releases today, the rule was simple: if it isn't documented, it isn't shipped. No excuses.

I strongly believe that the Linuces should do the same. Let no program or library be shipped which is undocumented. It's the very least a systems integrator can do. That's just part of what we mean when we say that BSD distributions are more "solid" than Linux distributions. The commercial Unices and the free BSDs take this kind of thing seriously. The Linuces, so far, do not. I have hope that this will change, and Redhat has a truly positive attitude about all this, but right now, you just can't compare them.