Once you've got the various circular build-dependencies in the base system resolved, it shouldn't be too bad. Debian has come on tremendously here since the last stable release, with build-deps in many more packages, 'apt-get build-dep', pbuilder, and even a packaged version of sbuild (only in incoming at the moment), so I'd say the sort of thing you're looking for isn't too far off.
Whoever wrote dselect had no clue. apt and dpkg didn't exist.
dpkg was written before dselect.
I don't think Debian has ever been a "Windoze SuX!!!!" club. If anything, my experience has been the opposite. I suspect you just ran into the minority of assholes and missed out on the much larger friendly side of the community. Reading comp.os.linux.setup, for instance, turns up assholes using pretty much any distribution.
(BTW, has ESR ever been heavily involved in Debian? I thought he couldn't stand it.)
Re:My opinion: no one do any changing
on
The LDP and Debian
·
· Score: 1
There's a lot more time left than just one day until the Debian doc-linux packages freeze for woody, so don't put yourself through a coronary or anything. But then again, you'll probably see my post on ldp-discuss long before you see this...
The initial estimates may have been harsh anyway. There are lots of things called the LDPL in David's database, and some are DFSG-free and some aren't. I'm working to categorize them more carefully.
I'm sorry you think Debian (or anyone) is blackmailing you. That's not the way I've seen the last week's developments at all. I'm not getting paid for any of this either.
In reality, we aren't going to release without packages like Apache. Somebody needed to fix them to avoid holding up the release, that's all, and the freeze update was written to kick developers into doing that.:) The Apache packages are just fine now.
The "offending docs" will be moved to non-free, as you say.
Re:Is/will it be on the distribution CDs?
on
The LDP and Debian
·
· Score: 1
Depends where you get the CDs. Many Debian CD sets include non-free, depending on the distributor, so just ask them and you shouldn't have a problem.
In fact, it did require altering all those packages, and it was a royal pain. We're still not quite there.
This particular change can be made fairly easily, because it only affects a few packages.
Re:My opinion? You and David Merrill are fools
on
The LDP and Debian
·
· Score: 1
Well, maybe. To some extent Debian's reputation is our own worst enemy: if we interpret a licence strictly, people call us zealots, while if we treat one loosely they call us hypocrites.
I'll admit I thought for a few moments about sweeping it under the carpet for a while. On the other hand, I was pretty surprised to find out that there were some HOWTOs that I couldn't, say, modify for my local system and give to my friends, or that I couldn't change for Debian if a user reported a bug and I couldn't contact the original author (although all the HOWTOs in Debian are currently identical to the ones the LDP produces, and I'd like to keep it that way). If I was surprised as the maintainer, I wanted to let users know, too, and once that happened there would certainly be somebody who complained until doc-linux was split into free and non-free anyway.
Yeah, it'll be a good deal of work for me, but that's nothing new, and David's been working his butt off contacting authors. I think it had to happen sooner or later.
And really, while it's a shame, it isn't a disaster. If you don't object to non-free packages, 'apt-get install doc-linux-non-free-html doc-linux-non-free-text' after the split happens. If you're one of the types who doesn't want non-free anywhere near their system (which doesn't include me, as it happens), then you probably won't mind much.
You could be right, and maybe the move will turn out to be impractical after all. Time will tell. I'll try to keep things as smooth as possible.
"Debian fanatics"? No ... Here are the facts.
on
The LDP and Debian
·
· Score: 5, Informative
I'm the maintainer of the Debian packages containing the English-language HOWTOs distributed by the Linux Documentation Project.
A few days ago, during a discussion we were having about other things, David Merrill brought it to my attention that many of the LDP documents didn't belong in our main distribution. With the evidence in front of me, it was hard for me not to agree, and, once I knew of the problem, I felt bound to do something about it.
The timing, of course, was unfortunate, coming as it did so close to the woody freeze. Yes, I should have noticed it earlier, but to be honest I've been kind of busy writing code and fixing bugs in the three months or so since I've been working on Debian's HOWTO packages. I certainly wouldn't have planned it this way; the situation now leaves me with less than three weeks to implement a bunch of code to parse the LDP database and to split the packages up, which is definitely not something I enjoy doing at the end of a release cycle, so we aren't doing this for our own amusement.
Personally, I am extremely disappointed that much of the doc-linux packages will have to become doc-linux-non-free-html and doc-linux-non-free-text. I didn't become the doc-linux maintainer with the intention of removing documentation from the standard installation! I'll be doing my best to ensure that any documents that we start being able to distribute in main are moved back into main as soon as possible, including submitting updates for point releases of woody and persuading the release manager to include them. I'll also be checking by hand as many of the documents in non-free as I can just in case they really are free. The two days mentioned in the story, incidentally, are when the relevant part of the freeze starts, not when it ends, so the notice that's been given to authors isn't quite so ridiculously short as it sounds. Any documents that get relicensed in the next month and a bit will be included in main for woody, and it wouldn't surprise me if that deadline could be allowed to slip a bit.
I find it fascinating that lots of people seem to think that Debian is somehow beating its chest, stirring trouble, or being generally obnoxious. This is simply not true. First of all, we're reacting to concerns from the LDP, and secondly all the conversations I've had with LDP people, especially David Merrill, have been very civil and friendly. (Incidentally, David, if you're reading this, I owe you a drink of your choice.)
If you'd like to see where this discussion started, try the thread about this on debian-legal. Although David's original mail to me wasn't sent to that mailing list, I think the linked article quotes everything important.
I wish David and the LDP volunteers all the best, and I dearly hope that the current situation will be temporary.
No, not always. But it's damn close, and everything I care about works (if it's not in sync, I file a bug, and uninstallability bugs are release-critical).
The next release candidate is being automatically managed to try to get everything in sync. You're going to want (lies, damn lies, and...) statistics, so: at the moment, out of a total of 35493 binary packages across six architectures that have made it into testing, there are 443 packages which are uninstallable due to dependencies (a few more might fail due to errors in the maintainer scripts and such, but as a rule they shouldn't make it into testing either), and that will decrease during the upcoming freeze. I reckon 98.75% isn't too bad in a distribution we haven't even released yet, and the stats for i386 are running at more like 99.7% just now.
I run unstable, which isn't quite that good and nobody should claim it is, but all the same I'm not disappointed very often when I expect things to work.
In fact, if a library's just designed for use with one program, chances are it won't go through all the rigmarole of doing interface versioning and so on properly. Putting it directly in a system library directory would then be a bug, so distributions should - and usually do - do the right thing and put them somewhere private.
You're confused about how symbol versioning works (as are a lot of people complaining about this, it seems). glibc has it arranged so that it can change its API without it breaking things.
You change the major version number of a library (or, more accurately, its SONAME) when you make changes that break programs properly linked against older versions of the library. But when you install a new version of libc6, programs linked against the old version continue to work! So they have backward compatibility, and don't have to change their soname. Sure, if you link a program against the newer libc6, people will need a comparable version of that library to run it, but they can upgrade the library and not break everything else on their system. This was not the case between libc5 and libc6, which was why the soname had to change.
(Oh yeah, and before everyone jumps in with libc6-2.0 to libc6-2.1, sure, that caused a few problems, but only because a minority of people linked against libc6-2.0 in weird undocumented ways. In 2.1, the glibc people closed that so that this problem couldn't happen in future.)
If you still don't understand library versioning, and care enough to want to find out, the libtool documentation has some notes on how it works. If you don't believe me about libc6, try objdump -p/lib/libc.so.6 and look for the "Version definitions" section. That lists all the interfaces it supports.
Forgetting about GNU/* for a moment, Solaris is still on major version 1 of its libc: it has (or at least claims to have) never broken backward compatibility.
The GPL, IIRC (I'm not a license guru), mandates that if you use GPL code in your code you must GPL the entire thing (if this is not what the GPL says, then I am sorry for making the incorrect assumption).
Almost. If you link GPL code with yours, it must be possible to distribute the whole under the GPL. This means that your code must be licensed in such a way that it can be relicensed under the GPL. If you want to put the portions of the code you wrote under the BSD licence (minus the advertising clause), then that meets this restriction, as do public domain, the Perl licence (dual GPL + Artistic) and several others.
This is quite an important distinction if you don't like the GPL but need to use a GPL library. It's also good for those of us who do like the GPL and want to use BSD-without-advertising-clause libraries.
The maintainer of the installation routine doesn't care for suggestions on improvement either. Maybe he sees Progeny coming and knows he'll soon be obsolete.
I imagine he sees Debian's new debconf-based installer coming. boot-floppies (the old installer) is really just in maintenance mode for the woody release and is due to be replaced, so there's limited point in making lots of design-level improvements now.
The DPL doesn't have any authority in making decisions about maintainership, so that won't arise. It's up to individual package maintainers who succeeds them, or, if they just orphan the package, anybody who wants it can work on it.
Ben does maintain a number of core packages (glibc, pam, etc.), but he puts a lot of work into them and I'm guessing he won't be needing a successor in the near future.
The only situation where the DPL can actually appoint people is the small number of delegates who exist. Where people are competent enough for those roles, though, one vote in a long-past election is unlikely to make a great deal of difference.
I can believe the Linux/Windows thing. If a developer only runs Linux, then, sure, it's nice to have the program run on Windows too - I'd hope that my current Perl project could run happily enough on Windows, given a little tweaking - but it means that the developer is then at least half-expected to support it. Perhaps it would be worth saying that you'll be willing to continue supporting the program under Windows for future releases.
Sometimes the time delay can be surprising. I pinged the trn4 developer for a while, and then after several months he moved everything onto sourceforge and gave me write access.:) It's depressingly easy for the busier of developers to get behind on their mail.
But yes, feedback is fantastic, and I do try to spend some time responding to it whenever I can.
Fair point. I should have said that it's what GNU want to use to provide the functions of a Unix kernel. I'm in good company, though; it's very frequently called "the GNU kernel" even by FSF people.
Since HURD is a mutually recursive acronym, it's quite hard to say the entire phrase.:)
It's the GNU kernel, which has been in development for well over a decade, based on the Mach microkernel. And yeah, it's still not ready for prime-time, although you can install Debian's unstable distribution for it. The Kernel Cousin project has a section for its Debian mailing list.
In case you didn't know, 1.3.13 was rolled earlier this week, and then dumped and replaced by 1.3.14 when some build problems on NetWare were found. So it's not like there's all that much difference between the two versions.
Re:I'm a Maths Graduate but ...
on
Does P = NP?
·
· Score: 1
It's computable, it just grows faster than any function of that form. Think of it as something similar to the way exponential functions are computable but still grow faster than any polynomial function. It's just a lot harder to imagine.
On computability, it gets amusing when you have problems you can't solve even given a machine that solves the halting problem...
Unfortunately, quantum computers only help you with a single exponential factor. You still won't be able to solve double-exponential problems (those with a lower bound of 2^(2^n)) in polynomial time with them, so they aren't omnipotent.
Re:I'm a Maths Graduate but ...
on
Does P = NP?
·
· Score: 1
Yes, there are. To say that a problem is solvable in NP-time is equivalent to saying that its solution is verifiable in polynomial time, and that's not true for all problems. IIRC double-exponential-time problems tend to fall into this category.
There are problems that can be solved but not in any time bounded by O(2^(2^(2^(...^n)))), that is not exponential, double-exponential, triple-exponential, or anything like that. They're known as nonelementary problems (understatement of the year). I imagine those are always outside NP, but I don't have the references to hand at the moment.
At school, the friends I had were pretty much limited to people who lived in the same city as me, and not a lot of those people were compatible enough with me for friendships to form. Geography is a pretty useless way to pick your friends.
University meant that I started meeting people who made far more sense to me and I to them. Still, I met most people at parties or because they were living near me or that sort of thing; not bad, but still a bit random.
Of the friends I've met online (by way of Usenet), there are several I count among my closest friends. I think we know each other much better than I know most people I met through more "normal" means because we actually had to talk to become friends rather than just getting drunk together at a party. I've met most of those friends in real life, too, and I'm much closer friends with them because of it, but without our "virtual community" we'd never have met in the first place.
I don't think it's any accident that that community of ours has seen a lot of friendships spill over into real-life romances. A space where people select whom to talk to by the interests they already know they have, rather than by picking someone who looks friendly and hoping they're a bit like you, is much more likely to come up with people who get on with each other. If you want the human relationships to develop, then eventually I think you have to meet each other in real life; perhaps our community has been so successful because we try to meet up regularly, as far as geography allows. But the virtual community is still there as a backdrop and as a way in which new people can join the group.
At least in places, online communities are very much alive and well.
I was on their MSDN list for a while (until I just completely lost interest in it a couple of years ago), and it took me quite a while to get myself off it. In the end I just applied my standard tactic with mailing lists: filter it off to a newsgroup, where I can either read it or else unsubscribe and forget about it.
"virii" would be the plural of "virius", which doesn't exist. The only Latin plural of "virus" that makes sense in Latin is also "virus". If you don't want to be confusing, just say "viruses" like a halfway normal English speaker.
Not something I normally bother being pedantic about, but when people try to argue that it's right...
Slashdot Mirror
Once you've got the various circular build-dependencies in the base system resolved, it shouldn't be too bad. Debian has come on tremendously here since the last stable release, with build-deps in many more packages, 'apt-get build-dep', pbuilder, and even a packaged version of sbuild (only in incoming at the moment), so I'd say the sort of thing you're looking for isn't too far off.
dpkg was written before dselect.
I don't think Debian has ever been a "Windoze SuX!!!!" club. If anything, my experience has been the opposite. I suspect you just ran into the minority of assholes and missed out on the much larger friendly side of the community. Reading comp.os.linux.setup, for instance, turns up assholes using pretty much any distribution.
(BTW, has ESR ever been heavily involved in Debian? I thought he couldn't stand it.)
There's a lot more time left than just one day until the Debian doc-linux packages freeze for woody, so don't put yourself through a coronary or anything. But then again, you'll probably see my post on ldp-discuss long before you see this ...
The initial estimates may have been harsh anyway. There are lots of things called the LDPL in David's database, and some are DFSG-free and some aren't. I'm working to categorize them more carefully.
I'm sorry you think Debian (or anyone) is blackmailing you. That's not the way I've seen the last week's developments at all. I'm not getting paid for any of this either.
In reality, we aren't going to release without packages like Apache. Somebody needed to fix them to avoid holding up the release, that's all, and the freeze update was written to kick developers into doing that. :) The Apache packages are just fine now.
The "offending docs" will be moved to non-free, as you say.
Depends where you get the CDs. Many Debian CD sets include non-free, depending on the distributor, so just ask them and you shouldn't have a problem.
In fact, it did require altering all those packages, and it was a royal pain. We're still not quite there.
This particular change can be made fairly easily, because it only affects a few packages.
Well, maybe. To some extent Debian's reputation is our own worst enemy: if we interpret a licence strictly, people call us zealots, while if we treat one loosely they call us hypocrites.
I'll admit I thought for a few moments about sweeping it under the carpet for a while. On the other hand, I was pretty surprised to find out that there were some HOWTOs that I couldn't, say, modify for my local system and give to my friends, or that I couldn't change for Debian if a user reported a bug and I couldn't contact the original author (although all the HOWTOs in Debian are currently identical to the ones the LDP produces, and I'd like to keep it that way). If I was surprised as the maintainer, I wanted to let users know, too, and once that happened there would certainly be somebody who complained until doc-linux was split into free and non-free anyway.
Yeah, it'll be a good deal of work for me, but that's nothing new, and David's been working his butt off contacting authors. I think it had to happen sooner or later.
And really, while it's a shame, it isn't a disaster. If you don't object to non-free packages, 'apt-get install doc-linux-non-free-html doc-linux-non-free-text' after the split happens. If you're one of the types who doesn't want non-free anywhere near their system (which doesn't include me, as it happens), then you probably won't mind much.
You could be right, and maybe the move will turn out to be impractical after all. Time will tell. I'll try to keep things as smooth as possible.
I'm the maintainer of the Debian packages containing the English-language HOWTOs distributed by the Linux Documentation Project.
A few days ago, during a discussion we were having about other things, David Merrill brought it to my attention that many of the LDP documents didn't belong in our main distribution. With the evidence in front of me, it was hard for me not to agree, and, once I knew of the problem, I felt bound to do something about it.
The timing, of course, was unfortunate, coming as it did so close to the woody freeze. Yes, I should have noticed it earlier, but to be honest I've been kind of busy writing code and fixing bugs in the three months or so since I've been working on Debian's HOWTO packages. I certainly wouldn't have planned it this way; the situation now leaves me with less than three weeks to implement a bunch of code to parse the LDP database and to split the packages up, which is definitely not something I enjoy doing at the end of a release cycle, so we aren't doing this for our own amusement.
Personally, I am extremely disappointed that much of the doc-linux packages will have to become doc-linux-non-free-html and doc-linux-non-free-text. I didn't become the doc-linux maintainer with the intention of removing documentation from the standard installation! I'll be doing my best to ensure that any documents that we start being able to distribute in main are moved back into main as soon as possible, including submitting updates for point releases of woody and persuading the release manager to include them. I'll also be checking by hand as many of the documents in non-free as I can just in case they really are free. The two days mentioned in the story, incidentally, are when the relevant part of the freeze starts, not when it ends, so the notice that's been given to authors isn't quite so ridiculously short as it sounds. Any documents that get relicensed in the next month and a bit will be included in main for woody, and it wouldn't surprise me if that deadline could be allowed to slip a bit.
I find it fascinating that lots of people seem to think that Debian is somehow beating its chest, stirring trouble, or being generally obnoxious. This is simply not true. First of all, we're reacting to concerns from the LDP, and secondly all the conversations I've had with LDP people, especially David Merrill, have been very civil and friendly. (Incidentally, David, if you're reading this, I owe you a drink of your choice.)
If you'd like to see where this discussion started, try the thread about this on debian-legal. Although David's original mail to me wasn't sent to that mailing list, I think the linked article quotes everything important.
I wish David and the LDP volunteers all the best, and I dearly hope that the current situation will be temporary.
No, not always. But it's damn close, and everything I care about works (if it's not in sync, I file a bug, and uninstallability bugs are release-critical).
The next release candidate is being automatically managed to try to get everything in sync. You're going to want (lies, damn lies, and ...) statistics, so: at the moment, out of a total of 35493 binary packages across six architectures that have made it into testing, there are 443 packages which are uninstallable due to dependencies (a few more might fail due to errors in the maintainer scripts and such, but as a rule they shouldn't make it into testing either), and that will decrease during the upcoming freeze. I reckon 98.75% isn't too bad in a distribution we haven't even released yet, and the stats for i386 are running at more like 99.7% just now.
I run unstable, which isn't quite that good and nobody should claim it is, but all the same I'm not disappointed very often when I expect things to work.
In fact, if a library's just designed for use with one program, chances are it won't go through all the rigmarole of doing interface versioning and so on properly. Putting it directly in a system library directory would then be a bug, so distributions should - and usually do - do the right thing and put them somewhere private.
Debian has an equivs package that gives you a handy way to fool the packaging system if need be.
You're confused about how symbol versioning works (as are a lot of people complaining about this, it seems). glibc has it arranged so that it can change its API without it breaking things.
You change the major version number of a library (or, more accurately, its SONAME) when you make changes that break programs properly linked against older versions of the library. But when you install a new version of libc6, programs linked against the old version continue to work! So they have backward compatibility, and don't have to change their soname. Sure, if you link a program against the newer libc6, people will need a comparable version of that library to run it, but they can upgrade the library and not break everything else on their system. This was not the case between libc5 and libc6, which was why the soname had to change.
(Oh yeah, and before everyone jumps in with libc6-2.0 to libc6-2.1, sure, that caused a few problems, but only because a minority of people linked against libc6-2.0 in weird undocumented ways. In 2.1, the glibc people closed that so that this problem couldn't happen in future.)
If you still don't understand library versioning, and care enough to want to find out, the libtool documentation has some notes on how it works. If you don't believe me about libc6, try objdump -p /lib/libc.so.6 and look for the "Version definitions" section. That lists all the interfaces it supports.
Forgetting about GNU/* for a moment, Solaris is still on major version 1 of its libc: it has (or at least claims to have) never broken backward compatibility.
Almost. If you link GPL code with yours, it must be possible to distribute the whole under the GPL. This means that your code must be licensed in such a way that it can be relicensed under the GPL. If you want to put the portions of the code you wrote under the BSD licence (minus the advertising clause), then that meets this restriction, as do public domain, the Perl licence (dual GPL + Artistic) and several others.
This is quite an important distinction if you don't like the GPL but need to use a GPL library. It's also good for those of us who do like the GPL and want to use BSD-without-advertising-clause libraries.
I imagine he sees Debian's new debconf-based installer coming. boot-floppies (the old installer) is really just in maintenance mode for the woody release and is due to be replaced, so there's limited point in making lots of design-level improvements now.
The DPL doesn't have any authority in making decisions about maintainership, so that won't arise. It's up to individual package maintainers who succeeds them, or, if they just orphan the package, anybody who wants it can work on it.
Ben does maintain a number of core packages (glibc, pam, etc.), but he puts a lot of work into them and I'm guessing he won't be needing a successor in the near future.
The only situation where the DPL can actually appoint people is the small number of delegates who exist. Where people are competent enough for those roles, though, one vote in a long-past election is unlikely to make a great deal of difference.
I can believe the Linux/Windows thing. If a developer only runs Linux, then, sure, it's nice to have the program run on Windows too - I'd hope that my current Perl project could run happily enough on Windows, given a little tweaking - but it means that the developer is then at least half-expected to support it. Perhaps it would be worth saying that you'll be willing to continue supporting the program under Windows for future releases.
Sometimes the time delay can be surprising. I pinged the trn4 developer for a while, and then after several months he moved everything onto sourceforge and gave me write access. :) It's depressingly easy for the busier of developers to get behind on their mail.
But yes, feedback is fantastic, and I do try to spend some time responding to it whenever I can.
Fair point. I should have said that it's what GNU want to use to provide the functions of a Unix kernel. I'm in good company, though; it's very frequently called "the GNU kernel" even by FSF people.
Since HURD is a mutually recursive acronym, it's quite hard to say the entire phrase. :)
It's the GNU kernel, which has been in development for well over a decade, based on the Mach microkernel. And yeah, it's still not ready for prime-time, although you can install Debian's unstable distribution for it. The Kernel Cousin project has a section for its Debian mailing list.
In case you didn't know, 1.3.13 was rolled earlier this week, and then dumped and replaced by 1.3.14 when some build problems on NetWare were found. So it's not like there's all that much difference between the two versions.
It's computable, it just grows faster than any function of that form. Think of it as something similar to the way exponential functions are computable but still grow faster than any polynomial function. It's just a lot harder to imagine.
On computability, it gets amusing when you have problems you can't solve even given a machine that solves the halting problem ...
Unfortunately, quantum computers only help you with a single exponential factor. You still won't be able to solve double-exponential problems (those with a lower bound of 2^(2^n)) in polynomial time with them, so they aren't omnipotent.
Yes, there are. To say that a problem is solvable in NP-time is equivalent to saying that its solution is verifiable in polynomial time, and that's not true for all problems. IIRC double-exponential-time problems tend to fall into this category.
There are problems that can be solved but not in any time bounded by O(2^(2^(2^(...^n)))), that is not exponential, double-exponential, triple-exponential, or anything like that. They're known as nonelementary problems (understatement of the year). I imagine those are always outside NP, but I don't have the references to hand at the moment.
Absolutely - to me, it's a natural progression.
At school, the friends I had were pretty much limited to people who lived in the same city as me, and not a lot of those people were compatible enough with me for friendships to form. Geography is a pretty useless way to pick your friends.
University meant that I started meeting people who made far more sense to me and I to them. Still, I met most people at parties or because they were living near me or that sort of thing; not bad, but still a bit random.
Of the friends I've met online (by way of Usenet), there are several I count among my closest friends. I think we know each other much better than I know most people I met through more "normal" means because we actually had to talk to become friends rather than just getting drunk together at a party. I've met most of those friends in real life, too, and I'm much closer friends with them because of it, but without our "virtual community" we'd never have met in the first place.
I don't think it's any accident that that community of ours has seen a lot of friendships spill over into real-life romances. A space where people select whom to talk to by the interests they already know they have, rather than by picking someone who looks friendly and hoping they're a bit like you, is much more likely to come up with people who get on with each other. If you want the human relationships to develop, then eventually I think you have to meet each other in real life; perhaps our community has been so successful because we try to meet up regularly, as far as geography allows. But the virtual community is still there as a backdrop and as a way in which new people can join the group.
At least in places, online communities are very much alive and well.
I was on their MSDN list for a while (until I just completely lost interest in it a couple of years ago), and it took me quite a while to get myself off it. In the end I just applied my standard tactic with mailing lists: filter it off to a newsgroup, where I can either read it or else unsubscribe and forget about it.
"virii" would be the plural of "virius", which doesn't exist. The only Latin plural of "virus" that makes sense in Latin is also "virus". If you don't want to be confusing, just say "viruses" like a halfway normal English speaker.
Not something I normally bother being pedantic about, but when people try to argue that it's right ...