Slashdot Mirror

Ubuntu (request for inclusion)

Debian (request for inclusion)

Alternative APT source maintained by Sam Vilain:
deb http://apt.utsl.gen.nz/debian <distname> all
# where <distname> is one of woody, sarge, sid, warty, hoary or breezy

or another APT source maintained by bougyman:
deb http://debian.bougyman.com/ unstable main

So [package uninstaller] on [OS] completely removes that package. Golf clap. A properly packaged (your words) application will work that way on any OS, not just Debian.

I love Debian, and have used it for years. It's great. However, the real admin nightmare comes when you decide you want some non-standard feature supported systemwide. On FreeBSD, for example, if I want LDAP support then I install the OpenLDAP client port (or let it get brought in as a dependency when I request LDAP support in some random program). Et voila, ports compiled from then on get LDAP support where appropriate. Gentoo fans: yeah, I know you have this too. Portage earns its name, I'll give you that.

Debian, on the other hand, requires you to hand-roll special locally-built versions of every application you want to have LDAP support - when a new version comes out, it's hand building time again. Yay! If LDAP is too common to be a good example, check out Kerberos. Debian/unstable has OpenSSH 4.2p1. Nice! If you want a version with Kerberos support, though, plan on rolling back to OpenSSH 3.8.1p1 and losing all of the other features you might have liked to use, or cranking up gcc and your beloved packaging tools.

As I said, I like Debian. Still, I can't pretend that it doesn't have several critical issues that make its administration a lot harder than need be. If the official packages cover all your needs, then it's a dream. If not, things get ugly quickly. You might not like the tradeoffs that FreeBSD and Gentoo have made, but they're there for a reason and are exactly what many of us want and need.

So [package uninstaller] on [OS] completely removes that package. Golf clap. A properly packaged (your words) application will work that way on any OS, not just Debian.

I love Debian, and have used it for years. It's great. However, the real admin nightmare comes when you decide you want some non-standard feature supported systemwide. On FreeBSD, for example, if I want LDAP support then I install the OpenLDAP client port (or let it get brought in as a dependency when I request LDAP support in some random program). Et voila, ports compiled from then on get LDAP support where appropriate. Gentoo fans: yeah, I know you have this too. Portage earns its name, I'll give you that.

Debian, on the other hand, requires you to hand-roll special locally-built versions of every application you want to have LDAP support - when a new version comes out, it's hand building time again. Yay! If LDAP is too common to be a good example, check out Kerberos. Debian/unstable has OpenSSH 4.2p1. Nice! If you want a version with Kerberos support, though, plan on rolling back to OpenSSH 3.8.1p1 and losing all of the other features you might have liked to use, or cranking up gcc and your beloved packaging tools.

As I said, I like Debian. Still, I can't pretend that it doesn't have several critical issues that make its administration a lot harder than need be. If the official packages cover all your needs, then it's a dream. If not, things get ugly quickly. You might not like the tradeoffs that FreeBSD and Gentoo have made, but they're there for a reason and are exactly what many of us want and need.

Yeah this brings us back to Bill Gates quotes paralleling my pr0n res hypothetical to be good enough to suit us (like the 640KB did), but, I mean, c'mon, won't that video quality suffice?

The answer is yes, until the market fully adopts 3D holograph pr0n that will require some more zeros and ones.

I mean, c'mon.

"Ctrl-z would get pressed, and 'reset' would get typed."

How naive, by then it could already be to late. Consider DSA 697-1: http://www.debian.org/security/2005/dsa-697

It's quiet shocking to find those kind of bugs in ancient programs. More info can be found for eg on http://www.digitaldefense.net/labs/papers/Termulat ion.txt

BTW a simple way to get headers:
lynx -head -dump URL
  or
the live http header plugin for Fire*
  or
(t)ethereal/tcpdump (keep it up to date for the same reason as above)

I personally prefer apt, since it's the system I know the most and have had the least problems with, and yum was a dog earlier (fedora core 1 & 2), but have heard that it's been improved a lot lately.

Generally, every distro have its standard way, some borrow from others (mostly apt), and some make their own. (fedora have yum, mandriva urpm, gentoo emerge, arch have pacman IIRC..) Just read up on your distro of choice and find out what package manager it use, and learn it.

Check http://www.debian.org/distrib/packages for a list of packages avaliable for the debian distribution. Unstable had over 14.000 packages (including meta-packages and differently compiled versions of same program) last time I checked.

I primarily use Debian for servers because that is where it shines. But important server-related packages like vpopmail-bin are simply not getting updated:

In Debian UNSTABLE, vpopmail-bin last updated on 10 Jun 2004 with version 5.4.4. There are 6 (six) new upstream-stable releases of vpopmail-bin that are being ignored by the maintainer. In fact, this 273 days old bug report complains about 5 (five) upstream-stable releases being ignored by the maintainer in the UNSTABLE branch, Pawel Wiecek (coven@debian.org):

"http://bugs.debian.org/cgi-bin/bugreport.cgi?bug= 290245"

I wonder why Debian management doesn't implement automatic monitoring of package maintainers and their performance. In some cases, having no maintainer is probably better than having a bad maintainer. It shouldn't be hard to do given the infrastructure already in place. For example, the above maintainer's current status can be obtained by using a URL such as:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint =coven@debian.org

I'm seriously considering a switch to Ubuntu because of issues like this with more than one package that is important to me. I've never had any problems like this with FreeBSD but my hosting company only offers Linux distros (and great hosting companies are VERY hard to find so I'm not willing to switch just for that).

I get the sense that Ubuntu is more practical than Debian for people that need to get shit done without all the power trips or license discrimination (for example, intentionally handling non-GPL licensed projects improperly in hopes that people migrate to or even startup competing GPL projects regardless of technical merits).

I primarily use Debian for servers because that is where it shines. But important server-related packages like vpopmail-bin are simply not getting updated:

In Debian UNSTABLE, vpopmail-bin last updated on 10 Jun 2004 with version 5.4.4. There are 6 (six) new upstream-stable releases of vpopmail-bin that are being ignored by the maintainer. In fact, this 273 days old bug report complains about 5 (five) upstream-stable releases being ignored by the maintainer in the UNSTABLE branch, Pawel Wiecek (coven@debian.org):

"http://bugs.debian.org/cgi-bin/bugreport.cgi?bug= 290245"

I wonder why Debian management doesn't implement automatic monitoring of package maintainers and their performance. In some cases, having no maintainer is probably better than having a bad maintainer. It shouldn't be hard to do given the infrastructure already in place. For example, the above maintainer's current status can be obtained by using a URL such as:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint =coven@debian.org

I'm seriously considering a switch to Ubuntu because of issues like this with more than one package that is important to me. I've never had any problems like this with FreeBSD but my hosting company only offers Linux distros (and great hosting companies are VERY hard to find so I'm not willing to switch just for that).

I get the sense that Ubuntu is more practical than Debian for people that need to get shit done without all the power trips or license discrimination (for example, intentionally handling non-GPL licensed projects improperly in hopes that people migrate to or even startup competing GPL projects regardless of technical merits).

The icons are licensed under Creative Commons Share-Alike. The Creative Commons licenses don't meet Debian Free Software Guidelines, so would not be inlcuded in Debian.

See here for a summary of the problems with Creative Commons licenses:

http://people.debian.org/~evan/ccsummary.html

Most programmers I know aren't too keen on using their free time to discuss legalities and philosophies.

Indeed that is correct. But what most people fail to see are the people in open source. Philosophies and tools are all fine ... what really makes a difference is the way developers interact. Point out the way email address of individuals are present in manpages, in the source files ... or how one can simply join a mailing list and start contributing to a project pretty fast.

You could also include stuff about how a huge amount of importance is given to "Doing It Just Right" instead of simply "Getting It Done" ... that what gets you acceptance is quality code.

A good resource will be this dissertation that uses Debian as a case study: http://lists.debian.org/debian-project/2005/08/msg 00206.html

Mark Shuttleworth's page on the Ubuntu wiki is also a good starting point to try gaining an insight into "open source". https://wiki.ubuntu.com/MarkShuttleworth

> Novell had their own distro before acquiring SuSE

Sort of. From what I remember, Caldera OpenLinux was originally a research project in Novell. In those days there was talk about porting WABI (a comercial product like WINE but for Win16) and the commericial equivalent of DOSEMU (I forget it's name) to Linux. This would allow Novell to use Linux as a high powered replacement for Win 3.1. Those plans appeared to be mostly hype or were abandoned when Win95 introduced Win32 and Win16 became irrelevant. Anyway, Novell Founder, Ray Noorda left Novell with several Novell employees to start Caldera. At least according to the press releases at the time, the excuse was that he was frustrated with Novell's lack of interest in Linux.

Unfortunately most press was not online during the 1994 era so I can't find many online references to back this up (anyone?). Here are a few I could google:

http://www.ftlinuxcourse.com/FTLinuxCourse_Complet e-2004/FTLinuxCourse/en/net/chap5.html
http://lists.debian.org/debian-user/1996/11/msg010 67.html

Hmm there seems to be a bug at slashdot code. The urls are wrong, I'm previewing them for a second time and they are still wrong even when they are correct in this box. I can't even copy and paste them as text because the buggy algorithm makes them incorrect links again.

Go and compare for yourselves at The Computer Language Shootout Benchmarks
http://shootout.alioth.debian.org/

Except that this article is about people developing in Haskell - a language that's every bit as fun to use as Python (it even has optional syntactic whitespace), but compiles to native code (so it's faster) and infers types at compile-time (so it's robuster).

Except that this article is about people developing in Haskell - a language that's every bit as fun to use as Python (it even has optional syntactic whitespace), but compiles to native code (so it's faster) and infers types at compile-time (so it's robuster).

You're correct that (non-graphical) pure Java code is much faster than pure Python code, although Java typically uses 2-5x as much memory.

But you say that, "Python is provable slower than Perl... [for] the Sieve of Eratosthenes algorithm". I don't think you could have picked a worse example to support your claim; in the Shootout's Sieve test, Python is friggin' four times faster than Perl .

Circa 2000, it was true that Perl was significantly faster than Python, but not anymore. While the Perl interpreter stagnated due to the Perl 6 fiasco, the Python interpreter has closed the gap, and then some. Except for regular expression-heavy code and I/O-heavy code (which are Perl's specialty), Python is now faster across the board. Check the shootout if you don't believe me.

Don't get me wrong. I'm not claiming that Python is a speed demon (in fact, it has serious performance problems). But Perl is not faster anymore.

You're correct that (non-graphical) pure Java code is much faster than pure Python code, although Java typically uses 2-5x as much memory.

But you say that, "Python is provable slower than Perl... [for] the Sieve of Eratosthenes algorithm". I don't think you could have picked a worse example to support your claim; in the Shootout's Sieve test, Python is friggin' four times faster than Perl .

Circa 2000, it was true that Perl was significantly faster than Python, but not anymore. While the Perl interpreter stagnated due to the Perl 6 fiasco, the Python interpreter has closed the gap, and then some. Except for regular expression-heavy code and I/O-heavy code (which are Perl's specialty), Python is now faster across the board. Check the shootout if you don't believe me.

Don't get me wrong. I'm not claiming that Python is a speed demon (in fact, it has serious performance problems). But Perl is not faster anymore.

Odd, then, that NetBeans and Eclipse are still slower than a sedated elephant on my Athlon 64 3200+ with 512 MB RAM. My computer must be living in a time warp.

Or maybe the truth is that Java is "effectively sluggish, though not technically slow" because its runtime optimization techniques require such huge amounts of RAM.

Although I'm well aware of the limitations of the Great Computer Language Shootout as a tool for measuring a language's overall utility, it does tell the naked truth about performance. When I see an easy-to-use language whose design makes it easier to write reusable code than Java using somewhat less CPU time and typically FOUR TIMES less memory , it makes me suspect that well-intentioned Java apologists like you have never really attempted an objective evaluation of the performance compromises inherent in Java's design.

Odd, then, that NetBeans and Eclipse are still slower than a sedated elephant on my Athlon 64 3200+ with 512 MB RAM. My computer must be living in a time warp.

Or maybe the truth is that Java is "effectively sluggish, though not technically slow" because its runtime optimization techniques require such huge amounts of RAM.

Although I'm well aware of the limitations of the Great Computer Language Shootout as a tool for measuring a language's overall utility, it does tell the naked truth about performance. When I see an easy-to-use language whose design makes it easier to write reusable code than Java using somewhat less CPU time and typically FOUR TIMES less memory , it makes me suspect that well-intentioned Java apologists like you have never really attempted an objective evaluation of the performance compromises inherent in Java's design.

see http://shootout.alioth.debian.org/benchmark.php?te st=all&lang=all&sort=fullcpu

Question: IANAL, so I'm confused. That seems, to me, to be a wrong conclusion by the Debian people. I agree that the license fragments listed by them indicate that:

Basically, this means that if you implement any part of the new 1.2 API or Jini API, even from scratch, Sun will "own" your implementation and you will have to pay them for the right to use it. (source)

However, the license for the documentation of said interfaces states:

NOTICE; LIMITED LICENSE GRANTS: Sun Microsystems, Inc. ("Sun") hereby grants you a fully-paid, non-exclusive, non-transferable, worldwide, limited license (without the right to sublicense), under the Sun's applicable intellectual property rights to view, download, use and reproduce the Specification only for the purpose of internal evaluation, which shall be understood to include developing applications intended to run on an implementation of the Specification provided that such applications do not themselves implement any portion(s) of the Specification.

That seems, to me, to say that you can use the documentation to write an application that uses the specs. So Sun does not "own" any application that uses the spec to Java. Note that interfaces and classes designed to be implemented or subclassed in the Java sense of those words are being used as intended, so I think that "implements a spec" is different from implements in the Java sense. That is, implemening java.util.Iterator doesn't make your code an implementation of the spec.

Implementations of the spec, it seems to me, is software that runs applications that use the spec. Like a JVM and its associated classes/interfaces for instance. In those cases, the following holds:

Sun also grants you a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, limited license (without the right to sublicense) under any applicable copyrights or patent rights it may have in the Specification to create and/or distribute an Independent Implementation of the Specification that:

1. fully implements the Spec(s) including all its required interfaces and functionality;
2. does not modify, subset, superset or otherwise extend the Licensor Name Space, or include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required/authorized by the Specification or Specifications being implemented;
3. passes the TCK (including satisfying the requirements of the applicable TCK Users Guide) for such Specification.

(source)

That basically states, to me, that you can't implement a core class that deviates from its spec. Since the entire specification is a set of specs of individual classes, you can choose which classes you support (as long as they fulfill the contract specified by the docs). So in that way you are not allowed to intentionally write incompatible software.

I don't know if that is a good thing or not, but it doesn't seem as bad to me as what you and Debian are implying. However, I am probably wrong as IANAL and often get confused by this license stuff. Can anyone help me?

Why do people even bother with Mono?

That's no good either.

Now, a better comparision would be mono vs. jikes+sablevm, fastjar, sablevm and classpath-tools--but these tools are not capable of running most Java software.

I haven't seen a link on this story yet, so I guess I will point you guys to the http://shootout.alioth.debian.org/benchmark.php?te st=all&lang=java&lang2=csharp&sort=fullcpu.

Insofar as it is possible to come up with meaningful ways to compare the performances of "languages", where language encompasses a language, the libraries it uses, the compiler used for the benchmark in question, the libraries used and the VM the benchmark is run on (if any), and everythig else beneath it in the stack all the way down to the hardware, it seems that Java 1.4.2 w/hotspot performs most of the tasks slightly quicker than Mono.

details. I will not use java, for anything, so long as licenses like theirs are forced upon it. With java, you are always a second class citizen.

It seems like Mandriva have put out a fine operating system, but as an admin, it sucks to not have any kind of documentation or bug support. For example, both Debian and FreeBSD have extensive documentation easily accessable from their web sites. Where's the equivelant for Mandriva? Same goes with bug reporting; I'm not going to track down the links, but it's pretty trivial to submit bug reports for any of Ubuntu, Debian, FreeBSD, even RedHat, but I looked all up and down Mandriva's site and didn't see any kind of bug tracking system, not even a mailto: field.

So, like I said, as an IT admin, I'm not going to support an OS that isn't going to support me.

Linux clipboarding is leaps and bounds ahead of Windows. It's really only people who don't understand the Linux clipboard that complain about it.

This is actually one of the reasons I loathe using Windows now. I can't believe people would put up with its absolutely horrible cut 'n paste support.

A funny point of note is that I, like many people, complained about the Linux clipboard when I was going through the steps of switching away from Windows. It was foreign and didn't act as I expected a clipboard should. But that quickly faded away once I figured out how it works and realized how much better it is.

The only annoying thing is you can't cut and paste between X and pure console mode without using something like xclip. But since Windows can't even do pure console mode (while at the same time doing graphical mode) this isn't realy a point against Linux cut 'n paste.

Anyway... all you've got to do is wrap your head around the fact that X has two (or more) cut and paste modes (depending on what WM / desktop system you use). The standard mode allows selection of text and immediate pasting of text using the middle mouse button. This is so much more convenient than Windows cut 'n paste for most things!

The second mode is basically an exact copy of how Windows cut 'n paste works. Highlight, use the copy command, then use the paste command. This is useful for situations where you want to paste over some text that needs to be highlighted (which obviously thwarts the first cut 'n paste mode).

Also note that having two separate modes is also a god send. Sometimes it's very useful to have two selection buffers.

Some WM's have an implementation of their own cut 'n paste method too. KDE has klipper which is a great tool. It can be configured to work a number of different ways, but essentially it keeps a history of your copy commands so you have access to many of them at any given time.

It's been a long time since Windows had a leg up on Unix style clipboards.

I can't speak for OSX since I've never really used it, but I assume it has some handy things that are either on par with or better than a standard *nix/*BSD setup.

I must admit, it makes it look more like they're providing a serious product rather than something made by a group of hippies and slackers.

*dives under a table with his Powerbook*

If it is yast you like, consider looking at http://yast4debian.alioth.debian.org/. Will let you use yast on Debian without sacrificing yourself to the complete reinstalls that installing (and upgrading) SuSE entails.

So, given that it is the hacker who is demonized for costing businesses billions and not the shitty programming, Microsoft can actually get away with selling virus protection programs, directing people to partners' sites who sell anti virus ware, or in this case bundling it with their next OS and marketing the software with the edge of having this high security from the evil doers. The whole deal works out great for the chip makers, the programmers, earnings reports, and of course the gross domestic product. This is capitalism at its best my friends. One more thing I gotta say, get your net install iso of debian (i386 arch)here.

It makes more sense to create a program, we could call it Jigdo, that downloads the debs you want and constructs the iso on the client machine. ;)

> So a project which was getting very little contribution from the OSS community is going to be forked into a different project that will get all sorts of support from the OSS community?

Yup. Funny how that works. It happened that way with SourceForge/GForge. It sorta happened with NCSA httpd -> Apache. Probably a handful of other examples out there.

It'll probably evolve from the needs of the Debian package maintainer needing an "upstream" for security patches, etc. Or maybe Gentoo, Fedora, etc. You get the idea. I use Debian as an example because of they'll need something that continues to satisfy the DFSG. Thus, if Nessus is still going to remain, it'll eventually need to be updated.

> So a project which was getting very little contribution from the OSS community is going to be forked into a different project that will get all sorts of support from the OSS community?

Yup. Funny how that works. It happened that way with SourceForge/GForge. It sorta happened with NCSA httpd -> Apache. Probably a handful of other examples out there.

It'll probably evolve from the needs of the Debian package maintainer needing an "upstream" for security patches, etc. Or maybe Gentoo, Fedora, etc. You get the idea. I use Debian as an example because of they'll need something that continues to satisfy the DFSG. Thus, if Nessus is still going to remain, it'll eventually need to be updated.

Here.

ZTree Don't leave $HOME without it.

Well, it seems that would be don't leave %USERPROFILE% without it, since it's only for Windows (and OS/2).

And binary packages for Debian's Sarge release on x86 are available here.

An FTP servers domain name is as deeply associated with it as that of an HTTP server.

xclip

http://people.debian.org/~kims/xclip/

Do they have applied a discount for all the P2P users getting legit content from :

http://www.jamendo.com/
or
http://www.archive.org/audio/collection.php?collec tion=opensource_audio
or
http://www.legaltorrents.com/
or
http://bt.etree.org/
or
http://torrents.gentoo.org/
or
http://www.debian.org/CD/torrent-cd/
or ....

See a list of legitimate content at the end of this page :
http://en.wikipedia.org/wiki/BitTorrent

some people confuse. a freeware (not free software) auther claims
mailing list in Debian about debian.co.jp service.
(http://lists.debian.org/debian-japanese/2005/09/m sg00012.html)

and some people (hosting service) ask about debian.co.jp service,
I've tired to answer to thats question...

and I don't want them to steal efforts and results that made by
Debian guys in Japan. It affects debian guys motivations, I think.

Guess you haven't heard of Debian GNU/kFreeBSD?

http://www.debian.org/ports/freebsd/

Debian trully is amazing. A complete lack of focus yet dedication to perfection in everything. The really amazing part of it is that they achive a staggeringly close afliction to it. Supporting 11 architectures and 3 Kernels, Debian GNU/Linux GNU/kFreeBSD GNU/Hurd. There is even a port to the GNU environment on Windows, and working on one to OSX.

If Red Hat isn't any good, then it's a bad decision, not a Linux problem, per se. I have never run into an instability problem with Debian, but I have with Red Hat. Choosing the right distro is just as important as choosing the right software to run on it. Many people choose Red Hat because of the support, but for Debian you would buy it from a 3rd party (http://www.debian.org/consultants/). For Open Source this isn't a problem, whereas on Windows you know there are some things only MS can help you with.

It's not up to Stallman. Call it whatever you want. Your *BSD box has a lot of GNU stuff on it too ... call it GNU/BSD if you wish.

A potato by any other name would be just as potato-esque but if you insist on calling it a rose you confuse both cooks and florists.

GNU/BSD exists. GNU's opinion on that.

I voted last week using a piece of paper and a felt tipped pen. It worked well, I made my marks to indicate my votes, and the polling booth staff counted my votes after the poll closed. Simple, straightforward, no computers involved in the counting process to enable election fraud. Debian used to run Apache which displays the results on the WWW.

So could some kind soul please explain how and why using a complicated machine to record the voter's choice enhances democracy?

I'd challenge you to find me a set of API calls that can actually crash an out-of-the-box Win2k machine from "userland".

http://shootout.alioth.debian.org/benchmark.php?te st=hello&lang=java&id=0&sort=fullcpu

Need I say more?

Many thanks for taking the time to clarify some points.

No problem at all. The article has now fallen off the front page, so I'm not sure how many people are still reading this, but you deserve a response.

It's fairly easy to show people the fruits of desktop Linux - pop in just one Ubuntu (or Mepis or whatever) CD and leave an hour later with a machine humming away nicely and in the case of Ubuntu very good online user forums to help with the many questions. The user doesn't know it's all based on Debian and may never know. Debian will be mentioned, but probably not that visibly unless you dig around for it.

That's true, but it's not a problem trademark law can solve. Remember that a trademark only protects a mark (logo or word). We could slap all the acknowledgement requirements we like on our trademark license, but it's still easy to avoid them by simply not using the mark except buried in footnotes, as some derivative distributions do.

What you seem to be after is more like the BSD advertising clause, which the FLOSS community has more or less rejected as a bad idea.

I think the solution lies more in Debian advocates and evangelists spreading the word that these derivatives really are in fact derived from Debian. Trying to promulgate something really heavy-handed will probably fail, as RMS's attempt to get people to call their Linux-kernel-based OSes "GNU/Linux" largely has. It's hard to force people to use a label of your choosing, but you can try to educate the marketplace. The results are more difficult to measure, but that doesn't render the exercise worthless.

I wonder if it would make sense for the Debian website to have a "good neighbors" page that identifies derived distributions that prominently acknowledge their Debian heritage and cultivate a good relationship with us.

I don't know Ubuntu very much since I've been using Debian as my main OS for more than three years and never felt like switching. Anyway, if you want to try openoffice.org2 from experimental (I assume that should also work with Ubuntu, but not at all sure of that) :

Add to your /etc/apt/sources.list :

deb http://ftp.fr.debian.org/debian/ ../project/experimental main contrib non-free

deb-src http://ftp.fr.debian.org/debian/ ../project/experimental main contrib non-free

Then apt-get -t experimental install openoffice.org2 should do the trick

Check http://packages.debian.org/experimental/editors/op enoffice.org2 for more infos

I don't know Ubuntu very much since I've been using Debian as my main OS for more than three years and never felt like switching. Anyway, if you want to try openoffice.org2 from experimental (I assume that should also work with Ubuntu, but not at all sure of that) :

Add to your /etc/apt/sources.list :

deb http://ftp.fr.debian.org/debian/ ../project/experimental main contrib non-free

deb-src http://ftp.fr.debian.org/debian/ ../project/experimental main contrib non-free

Then apt-get -t experimental install openoffice.org2 should do the trick

Check http://packages.debian.org/experimental/editors/op enoffice.org2 for more infos

I don't know Ubuntu very much since I've been using Debian as my main OS for more than three years and never felt like switching. Anyway, if you want to try openoffice.org2 from experimental (I assume that should also work with Ubuntu, but not at all sure of that) :

Add to your /etc/apt/sources.list :

deb http://ftp.fr.debian.org/debian/ ../project/experimental main contrib non-free

deb-src http://ftp.fr.debian.org/debian/ ../project/experimental main contrib non-free

Then apt-get -t experimental install openoffice.org2 should do the trick

Check http://packages.debian.org/experimental/editors/op enoffice.org2 for more infos

Presumably one would download Debian ISOs from something like cdimage.debian.org. To poison that, one would have to hack Debian's servers, and at that point, your vulnerability isn't really in bittorrent, now is it?