Slashdot Mirror

I think you are right, but Parrot is not in the same game with Java and .NET., yet.

Even /. has gotten over (most of) its .NET trolling and is starting to look at the platform in a practical, even positive light. There are coding projects well into production, some are finished, and surely there are some in maintenance stages. By the time Longhorn rolls out, the .NET runtime will probably be on the majority of active Windows systems. Mono may be an even bigger contender in the near future.

Meanwhile, programmers are waiting, many patiently, for Parrot which is just at 0.1.0. As an equivalent, Parrot isn't really in the race yet. Everyone would love to seriously consider it, but it's not a contender (in the same way .NET and JVM are) to technically consider yet. I hear things like mod_parrot are still in need of work, though there are related projects coming about.

Hopefully Parrot will become adopted over projects like Mono, not just in concept and ideology but in a practical platform. I think Python support may be critical, even more so than Perl6. Let's hope Parrot's maturity doesn't need to wait for Perl6.

Recent developement summaries on Parrot and other Perl-related things. Is there a timeline for Parrot? I haven't seen it.

"People get scared when they hear the word Apocalypse, but here I mean it in the good sense: a Revealing."
-Larry Wall, Perl 6 Apocalypse 1

UK programmer, maintainer of perl.com, and Anglican missionary Simon Cozens has re-rendered the 10th-century Japanese classic Pillow Book of Sei Shonagon as a blog. It works waaay too well.

Not recommending anything in particular, but you can chain together different tools to filter more completely than a single line of defense both against viruses and against spam.

IIRC, at MyCorp, Exchange servers are insulated from the outside by both PerlMX and Tumbleweed.

Aw, c'mon now, props to Larry Wall and the fellas.
Perl pushed the envelope on language design. Later efforts may have been less ideosyncratic, e.g. python, but, hey.
Perl6, if you've been following the summaries, P6 will raise the bar yet again.
I just wonder if this parrot chassis underneath will permit something as groovy as Boost.Python.

At least provide a link to clue him in. http://www.perl.com/language/misc/virus.html

Walks off to write an article about virii

There are no such things.

s/(.*?\s+)\(.*?\)/$1/g

This is trying to match something like adsfdfsdfs()ASDfasd#@$!@afd (adsfad@#$@!)
and replace it with
asdfa asdfa asdf adsfdfsdfs()ASDfasd#@$!@afd

or basically, get rid of things in parenthises that are after at least one white space.

so,
s/\s+\(.*?\)//g would work...

but still a lot of slashes

so try this
my $stuffInParen = qr| \(.*?\) |;
s/\s+ $stuffInParen //gx;

or even
my $stuffInParen = qr| \(.*?\) |;
my $whiteSpace = qr| \s+ |;

s/$whiteSpace $stuffInParen//gx;

now, you can look at the code and have a pretty good idea what it's doing. (even without comments). we're switching stuffInParens that follow whitespace with nothing. just because Perl gives you the flexability to write ugly code doesn't mean you should. if you are writing perl code and it looks ugly, you're doing it wrong. you should find another way to do it... with great power comes great responsability.

see http://www.perl.com/lpt/a/2003/06/06/regexps.html for more info.

What Larry has done with regexes for Perl6 is a work of pure genius. At the base level you can use them in much the same way as in the olden days (with a few minor changes in puctuation), ie same old line-noise. But it now allows you to do something very clever. You can give names to individual regexes: these are called rules; you can reference rules within other rules with angle brackets; rules can be grouped together into a grammar; grammars and rules are analogous to classes and methods; and yes, you can do inheritance with them. So someone writes a grammar for say parsing apache log lines and sticks it in a file somewhere; you can import that grammar, override the rule that recognises dates, and have a new grammar that recognises french day names say. Here's a simple example of a grammar:

grammar log_entry {
rule month {jan|feb|mar|....|dec};
rule year {\d{4}}
rule date {\d+-<month>-<year>}
rule ip {\d+\.\d+\.\d+\.\d+}
rule line { ^<date> <ip> .... }
}

Of course theres' a lot more to it than just that. See Larry's apocalyse 5 for more details.

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goat.cx. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.

Heh. Still, it's worth noting that this isn't new to Perl 6. Perl's always been a Chimera. Quoth the Perl man page (as it has as long as I can remember), "Perl combines (in the author's opinion, anyway) some of the best features of C, sed, awk, and sh, so people famil- iar with those languages should have little difficulty with it. (Language historians will also note some ves- tiges of csh, Pascal, and even BASIC-PLUS.)" As for why being a freakish blend and a giant mess is actually a feature, I suggest checking out Larry Wall's Second State of the Onion. (It's a long page, but the stuff on the advantages of complexity is all near the top.)

If you want the real scoop on the on-going planning of Perl 6, you might want to check out Larry Wall's Apocalypse articles: 1, 2, 3, 4, 5, 6. On the down side, they are dense. Very dense. For that reason, I actually recommend Daimon Conway's Exegesis articles: 2, 3, 4, 5, 6. They provide alot more context on what the changes actually mean to you and why they're good.

If you want the real scoop on the on-going planning of Perl 6, you might want to check out Larry Wall's Apocalypse articles: 1, 2, 3, 4, 5, 6. On the down side, they are dense. Very dense. For that reason, I actually recommend Daimon Conway's Exegesis articles: 2, 3, 4, 5, 6. They provide alot more context on what the changes actually mean to you and why they're good.

If you want the real scoop on the on-going planning of Perl 6, you might want to check out Larry Wall's Apocalypse articles: 1, 2, 3, 4, 5, 6. On the down side, they are dense. Very dense. For that reason, I actually recommend Daimon Conway's Exegesis articles: 2, 3, 4, 5, 6. They provide alot more context on what the changes actually mean to you and why they're good.

If you want the real scoop on the on-going planning of Perl 6, you might want to check out Larry Wall's Apocalypse articles: 1, 2, 3, 4, 5, 6. On the down side, they are dense. Very dense. For that reason, I actually recommend Daimon Conway's Exegesis articles: 2, 3, 4, 5, 6. They provide alot more context on what the changes actually mean to you and why they're good.

If you want the real scoop on the on-going planning of Perl 6, you might want to check out Larry Wall's Apocalypse articles: 1, 2, 3, 4, 5, 6. On the down side, they are dense. Very dense. For that reason, I actually recommend Daimon Conway's Exegesis articles: 2, 3, 4, 5, 6. They provide alot more context on what the changes actually mean to you and why they're good.

If you want the real scoop on the on-going planning of Perl 6, you might want to check out Larry Wall's Apocalypse articles: 1, 2, 3, 4, 5, 6. On the down side, they are dense. Very dense. For that reason, I actually recommend Daimon Conway's Exegesis articles: 2, 3, 4, 5, 6. They provide alot more context on what the changes actually mean to you and why they're good.

If you want the real scoop on the on-going planning of Perl 6, you might want to check out Larry Wall's Apocalypse articles: 1, 2, 3, 4, 5, 6. On the down side, they are dense. Very dense. For that reason, I actually recommend Daimon Conway's Exegesis articles: 2, 3, 4, 5, 6. They provide alot more context on what the changes actually mean to you and why they're good.

If you want the real scoop on the on-going planning of Perl 6, you might want to check out Larry Wall's Apocalypse articles: 1, 2, 3, 4, 5, 6. On the down side, they are dense. Very dense. For that reason, I actually recommend Daimon Conway's Exegesis articles: 2, 3, 4, 5, 6. They provide alot more context on what the changes actually mean to you and why they're good.

If you want the real scoop on the on-going planning of Perl 6, you might want to check out Larry Wall's Apocalypse articles: 1, 2, 3, 4, 5, 6. On the down side, they are dense. Very dense. For that reason, I actually recommend Daimon Conway's Exegesis articles: 2, 3, 4, 5, 6. They provide alot more context on what the changes actually mean to you and why they're good.

If you want the real scoop on the on-going planning of Perl 6, you might want to check out Larry Wall's Apocalypse articles: 1, 2, 3, 4, 5, 6. On the down side, they are dense. Very dense. For that reason, I actually recommend Daimon Conway's Exegesis articles: 2, 3, 4, 5, 6. They provide alot more context on what the changes actually mean to you and why they're good.

If you want the real scoop on the on-going planning of Perl 6, you might want to check out Larry Wall's Apocalypse articles: 1, 2, 3, 4, 5, 6. On the down side, they are dense. Very dense. For that reason, I actually recommend Daimon Conway's Exegesis articles: 2, 3, 4, 5, 6. They provide alot more context on what the changes actually mean to you and why they're good.

Disallowing patented code I see as reasonable, since I see that as one of the biggest potential future challenges the GPL will face - What happens when something like the Unisys mess happens, with code that has used the GPL for 10 years? Substantially violating the spirit of the GPL, I do not see as acceptible. Something like restricting it to non-commercial or non-military use gets a bit more messy, but the way I see it, letting someone use the GPL as the core of their license at least allows a stable underlying framework, and reduces the potential for having a hellish tangle of conflicting licenses (ie, would you rather read 27 pages of "Fred's semi-open license V3.1", or "GPL, with the exception that you can't use it for blah"?).

And what exactly is stopping you from doind this today? HINT: Mail::Sender module's man page:

COPYRIGHT

Copyright (c) 1997-2002 Jan Krynicky . All rights reserved.

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.* There is only one aditional condition, [sic] you may NOT use this module for SPAMing! NEVER! (see http://spam.abuse.net/ for definition) [emphasis added].

*Perl itself may be copied only under the terms of either the Artistic License or the GNU General Public License, which means that the effective license of Mail::Sender is either the Artistic License with the added restriction or the GPL with said restriction. This is a restriction on use, mind you, which means that the Mail::Sender's license is an EULA, so it's even much more than what you are complaining about. Now, you might say that spamming is illegal anyway, or if you know Jenda that he himself doesn't give a flying fuck about spamming and this is why this very module was born in the first place, but still this is a clear example that what you imply is impossible, is in fact not only possible, but also being used for years.

Of course I might have failed to understand your real concerns, in which case please clarify what is your real problem with the GNU General Public License. (Of course I assume you have read it.)

Speaking about the advertising clause of original BSD-style licenses, I believe that changing the GPL to make them GPL-compatible would be unwise at least. That would cause the same problems as invariant sections in works covered by GNU FDL, while targetting a much less important issue. I highly urge you to consider this.

HTH. HAND.

However, despite those examples, there is also Counter-proof Those going to show how useless the internet is as an information resource

The plural of "virus" isn't "virii." There is no such word. The plural of "virus" is "viruses."

Here's a good explanation from cdknow.com, quoted here in its entirety because the people who most need to read this won't click on a link.

The correct English plural of virus is viruses. Please consult any good dictionary before making up words.

For the purists, in Latin, there is a rarely-used plural form:

virus, viri (neuter)

(Forms: almost always restricted to nominative and accusative singular; generally singular in Lucretius, ablative singular in Lucretius)

The point of this is that even in Latin the form "viri" is rarely used. The singular form is used in most every instance. (This is from the Oxford Latin Dictionary.)

So, when considering the Latin: "virii" is incorrect and "viri" was almost never used.

Despite the fact there was little use for the plural form, there is another reason why "viri" was rarely used. The most common Latin word for "man" is "vir" with "viri" being its plural in the form used as the subject of a sentence. Thus, since "men" as the subject of a sentence would be used far more often than "venoms" (virus means venom) the "viri" word was most commonly seen as the plural of "man."

Bottom line: Don't try to make up words using a false Latin plural form. Since the word virus in its English form is now used then the English plural (viruses) should be used.

More plural-of-virus resources:

perl.com, the canonical and exhaustive source
Jonathan de Boyne Pollard's Frequently Given Answer

http://www.perl.com/language/misc/virus.html
http://homepages.tesco.net/~J.deBoynePollard/FGA/p lural-of-virus.html

The plural of "virus" isn't "virii." There is no such word. The plural of "virus" is "viruses."

Here's a good explanation from cdknow.com, quoted here in its entirety because the people who most need to read this won't click on a link.

The correct English plural of virus is viruses. Please consult any good dictionary before making up words.

For the purists, in Latin, there is a rarely-used plural form:

virus, viri (neuter)

(Forms: almost always restricted to nominative and accusative singular; generally singular in Lucretius, ablative singular in Lucretius)

The point of this is that even in Latin the form "viri" is rarely used. The singular form is used in most every instance. (This is from the Oxford Latin Dictionary.)

So, when considering the Latin: "virii" is incorrect and "viri" was almost never used.

Despite the fact there was little use for the plural form, there is another reason why "viri" was rarely used. The most common Latin word for "man" is "vir" with "viri" being its plural in the form used as the subject of a sentence. Thus, since "men" as the subject of a sentence would be used far more often than "venoms" (virus means venom) the "viri" word was most commonly seen as the plural of "man."

Bottom line: Don't try to make up words using a false Latin plural form. Since the word virus in its English form is now used then the English plural (viruses) should be used.

More plural-of-virus resources:

perl.com, the canonical and exhaustive source
Jonathan de Boyne Pollard's Frequently Given Answer

Show me a dictionary that lists "virii".

And it's not acceptable on linguistic grounds either.

I'll stop being an ass when you do.

Virus does indeed come from the Latin, probably (though not certainly) a 2nd-declension neuter noun. But one that has no plural, either recorded or supposed. Result: the English plural is 'viruses'.

My tips:

Clean up your desktop.

• If you have more than 5 files on your desktop, create a scratch folder (preferably on a RAMDISK). Create a single shortcut to that scratch folder.
• If you frequently need some of those files, create a second folder named today, frequently-used, or similar, and add a shortcut to it.
• Move frequently used application shortcuts into the quickbar. The quickbar is also a good place for applications that accept files via drag-and-drop. Drop an HTML file onto the shortcut to the currently-not-windows-standard-browser icon in the quickbar and the browser will start with the dropped file.
• Move less frequently used application shortcuts into the start menu (they probably are already there).
• Remove shortcuts from the desktop that you don't need. What was the last time you started Real Player, Quicktime or similar by doubleclicking the shortcut on the desktop instead of a media file?
• Organize your start menu. Rightclick it and choose "Explore"
• Use keyboard shortcuts for frequently used applications.

Several years ago, I found a tool called WinKey, allowing to create a huge ammount of keyboard shortcuts that do not interfer with application-specific hotkeys. Imagine a keyboard that has 80 or 100 extra buttons for applications. Weird? Useful! Just hold down the Windows key and type almost any other key to start one of your 50 most used applications.

My current shortcut mappings are:

Windows-A = ACDSee
Windows-C = cmd.exe (DOS-Box)
Windows-G = http://www.google.com/
Windows-I = Internet Explorer
Windows-N = better than Netscape: Mozilla (Windows-M is used to minimize all windows and can't be used)
Windows-Shift-N = the original Netscape 4.7 - less frequently used, so the shortcut is more complicated
Windows-O = Opera
Windows-P = Putty Menu (selfmade)
Windows-Q = Quirk for Ultraedit (Windows-U is used by usability tools and can't be used)
Windows-V = VNC viewer
Windows-W = WS_FTP
Windows-X = access the Exchange server: Mozilla Mail!

(You are not limited to letters: Numers, arrows and F-keys also work, and you can combine with Shift, Alt and Ctrl.)

And of course, I use some of the standard hardcoded shortcuts:

Windows-E = File Explorer
Windows-M = Minimize all Windows
Windows-Shift-M = undo Minimize
Windows-R = Run command
Windows-Break = Break Windows using the System Properties ;-)
Windows-F = Find files or folders

Less frequently used:

Windows-D = Show Desktop
Windows-Tab = Switch Tasks in the taskbar
Windows-F1 = Windows Help Windows-U = Utility Manager (Windows 2000) - starts Narrator and other usability tools (Winkey does not know this shortcut)

Executive summary: Click count reduction and mouse movement reduction by using short ways for frequently executed tasks. (This is very similar to what packers like winzip do. See also "poor Huffman coding" in Apocalypse 5.)

Tux2000

• From above website (definitely worth the read):
• • 
    Refactoring?
    In his book, Martin Fowler defines Refactoring as "the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure." In other words, you clean up your code but don't change what it does.
    
    Refactoring can be as simple as changing this code:
    
    $exclamation = 'I like '.$pastry.'!';
    
    
    To this:
    
    $exclamation = "I like $pastry!";
    
    
    Still does the same thing, but it's easier to read.
    
    It's important to note that I don't need to know anything about the contents of $pastry or how $exclamation is used. The change is completely self-contained and does not affect surrounding code or change what it does. This is Refactoring.
    

Wonder why it's easier to put a camel through a mobile phone than a snake.

Then, with more and more languages, especially ones with VMs, you get further and further away from the hardware. The end result: you lose performance. It does more and more for you, but at the expense of real optimizations, the kind that only you can do.

Now the zealots will come out and say, "Language X is better than language Y, see!" To me this argument is boring. I tend to use the appropriate tool for the job. So:

• Python for scripts, prototypes, proofs of concept, or components where performance generally is not an issue.
• For desktop apps, Visual Basic (yep, most IT apps are in VB). There is no justifiable reason for an IT department group to write a sales force reporting system in C++! If you want C++, go get a job at a software company. Stop wasting money and time making yourself feel like a hotshot. [I'd consider Kylix here if it was based on Basic. Why? Because honestly, Pascal is just about dead, and Basic is the king of the simple app. Let's just live with it and move on. I do want a cross-platform VB . . . ]
• For web apps, well, I stick around PHP/ASP.NET. Why? Portability! And moreover, the sticking point in a web-based app is not the UI layer; it's usually the underlying data extraction and formatting. Don't waste your time with lower level languages there. IMHO it's just not worth it. JSP and Java stuff, yuck! Too much time for too little bang.
• Java/C# (also consider mono/LISP for most production apps. Why? Portability! I want no vendor holding me by the balls. I want platform independence on the back end, and these are the few ways to achieve it. I'd include Haskell/OCAML here when appropriate. Perl? I'm loathe to use Perl as production, considering most Perl code cannot be understood 2 weeks after it's written. I'd rather take the hit in performance and be able to pass the code to someone else later.
• C++/C for components--just components--where performance is at an absolute premium or there exists some critical library that only has this kind of interface. But this step has to be justified by the team, with considerable explanation why a different architecture could not suffice. Otherwise, the team could waste time checking for dangling pointers when instead it could be doing other things, like finishing up other projects.
• Assembly? Only when there is not a C complier around. Embedded stuff. Nowadays, you just do not have the time to play.

Yes, my teams use many languages, but they also put their effort to where they get the biggest bang for the buck. And in any business approach, that's the key goal. You don't see carpenters use saws to hammer in nails or drive screws. Wise up!

What I hope is that Sun takes a good, long look at the only intermediate assembly that has been designed with language neutrality in mind, Parrot. While this article is over 2 years old, it's a decent starting point. Parrot has already been used to implement rudimentary versions of Perl 5, Perl 6, Python, Java, Scheme and a number of other languages. The proof of concept is done, and Sun could start with a wonderfully advanced next generation byte code language if they can avoid dismissing Parrot as, "a Perl thing" with their usual distain for things "not of Sun".... IBM on the other hand is usally more open to good ideas.

Nah. we put that in to not scare people. Parrot is, for all intents and purposes, completely independent from Perl 6 and has been for ages. (well before that article was written). While we're going to put in anything we need to make perl 6 run on parrot, the same can be said of anything we need to run Python and Ruby. (Which has already happened, FWIW) The only difference is that Matz and Guido haven't asked for anything yet...

Ummmm how does Parrot go at being compiled to real machine code, without that it's not even a contender in my book, the article you link to say it's for dynamic languages "we'd like Parrot to become a 'common language runtime' for dynamic languages", I personally would only be interested if it was for both dynamic and non-dynamic languages.

I wouldn't use it unless it could be used as a step in the process of compiling a C/C++ program, and produce code at least as fast as gcc, would. But if it can do that, then I would suggest that SUN just pitch in and help make Parrot the standard their looking for.

I really hope the author's smiley was to indicate that he understood that his string of buzzwords was meaningless.

What I hope is that Sun takes a good, long look at the only intermediate assembly that has been designed with language neutrality in mind, Parrot. While this article is over 2 years old, it's a decent starting point. Parrot has already been used to implement rudimentary versions of Perl 5, Perl 6, Python, Java, Scheme and a number of other languages. The proof of concept is done, and Sun could start with a wonderfully advanced next generation byte code language if they can avoid dismissing Parrot as, "a Perl thing" with their usual distain for things "not of Sun".... IBM on the other hand is usally more open to good ideas.

No, the plural is viruses not virii. Like you I made this mistake out of a mistaken confidence in my own superior education. Worse still I made it in a magazine article. Worse yet I'm not American which would be partial justification for being ill-informed & ill-educated.
Ouch. At least you are anonymous.
see; viruses definition

:-) Anyone knows who crafted that one?

Here is another great read, Larry on perl 6.

• #21: WWW::Mechanize 101
• #22: Scraping with WWW::Mechanize
• #36: Downloading Images from Webshots
• #44: Archiving Yahoo! Groups Messages with WWW::Yahoo::Groups (which uses Mech)
• #64: Super Author Searching
• #73: Scraping TV Listings

• WWW::Mechanize::Examples
  A random bunch of examples submitted by users, included with the Mechanize distribution.
• http://www.perl.com/pub/a/2003/01/22/mechanize.htm l
  Chris Ball's article about using WWW::Mechanize for scraping TV listings. (repurposed into hack #73 above)
• http://www.stonehenge.com/merlyn/LinuxMag/col47.ht ml
  Randal Schwartz's article on scraping Yahoo News for images.
• http://www.perladvent.org/2002/16th/
  WWW::Mechanize on the Perl Advent Calendar 2002, by Mark Fowler.

To be fair, the MusicBrainz article for perl.com (that, full disclosure time, I wrote) doesn't cover as much ground as the Developer Works article, which seems to be going through all the steps needed to write an autotagger in Perl.

However, I was a little dissapointed that Teodor didn't spell out more of his reasoning for his choice of modules. I covered the (then) available Perl mp3 modules for a talk at YAPC::Europe this summer, and if you're not sure which modules to use, I'd suggest having a look at the slides (80K PDF) and notes.

In any case, I look forward to the second part of the article, to see how the script shakes out in the end.

Identifying Music with MusicBrainz

Here's one such project in Perl. I've stolen quite a bit of code from it, whenever I only wanted a little piece of, e.g., uniq.

i didn't know kermit was scriptable. I like scriptable (Kermit scripting language is a programming language similar to Perl, but with different syntax ... predates perl) things.

It sounds lame because it got coopted by a bunch of script-kiddy lusers. But since I was using it way before all that, I'm grandfathered in, and anyone who doesn't like it can kindly kiss my ass :) 'Viruzes' sounds even worse because it calls forth those idiot preteens on Half Life who insist on pluralizing everything with a 'z', e.g. 'TURN ON UR SOUNDZ, N00B', etc.

Having said all that, virii is definitely, unquestionably wrong. And having said that, I still don't give a fuck (see above).

Seriously. For more information than you ever wanted to know about why "virii" is incorrect, please see here.

Thank you.

A nice explanation

Basically, virus might be either a second declension or fourth declension noun--the linguists aren't quite sure. It is neuter, though, as the ascusative form is the same as the nominative.

Normally, second declension nouns are made plural by adding "-i", to the root, which would produce "viri". But "virus" is neuter, which would imply "vira" as a plural.

However, second declension neuter nouns that in in "us" --such as "pelagus", and "vulgus", do not typically possess plural forms.

If it is fourth declension, the plural is virus, pronounced with a long "u" sound.

Of course, most people don't pronounce the "v" in its original latin voice, either. "Viruses" is concise, and appropriate for English. As scholars and pedants seem unable to agree on whether the declension is second or fourth, a wry individual might fairly claim that "viruses" is a a compromise, as "es" is the typical third declension ending for plural nominative forms..

Or as they say at What's the Plural of `Virus'?

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

Viva la prescience.

The plural of "virus" is neither "viri" nor "virii", nor even "vira" nor "virora". It is quite simply "viruses", irrespective of context. See here

From dictonary.com:

Q. What is the plural of virus?
A. Viruses.
It is not viri, or (which is worse) virii. True, the word comes directly from Latin, but not all Latin words ending in -us have -i as their plural. Besides, viri is the Latin word for 'men' (plural of vir, man, the root the English virile). There is in fact no written attestation of a Latin plural of virus.

If you would like to pursue the subject further, see the excellent article What's the Plural of `Virus'? at Perl.com. If you have some knowledge of linguistics and Latin, you might be interested in the morphological analysis of the word from the Perseus Project.

I use WebGUI from PlainBlack Software. It uses Perl/MySQL/Apache.

It is OpenSource, and very easy to use. It has WYSIWYG for those that don't know how to cut/paste. I suggest anyone looking at a CMS to take a look. It isn't perfect, but none really are.