Slashdot Mirror

Indeed, more details at

http://lists.debian.org/debian-devel-announce/2009/10/msg00000.html
http://lists.debian.org/debian-alpha/2009/07/msg00015.html
http://lists.debian.org/debian-alpha/2009/08/msg00005.html
http://lists.debian.org/debian-alpha/2009/10/msg00003.html
http://lists.debian.org/debian-alpha/2009/10/msg00004.html
http://lists.debian.org/debian-alpha/2009/10/msg00011.html

Indeed, more details at

http://lists.debian.org/debian-devel-announce/2009/10/msg00000.html
http://lists.debian.org/debian-alpha/2009/07/msg00015.html
http://lists.debian.org/debian-alpha/2009/08/msg00005.html
http://lists.debian.org/debian-alpha/2009/10/msg00003.html
http://lists.debian.org/debian-alpha/2009/10/msg00004.html
http://lists.debian.org/debian-alpha/2009/10/msg00011.html

Indeed, more details at

http://lists.debian.org/debian-devel-announce/2009/10/msg00000.html
http://lists.debian.org/debian-alpha/2009/07/msg00015.html
http://lists.debian.org/debian-alpha/2009/08/msg00005.html
http://lists.debian.org/debian-alpha/2009/10/msg00003.html
http://lists.debian.org/debian-alpha/2009/10/msg00004.html
http://lists.debian.org/debian-alpha/2009/10/msg00011.html

Indeed, more details at

http://lists.debian.org/debian-devel-announce/2009/10/msg00000.html
http://lists.debian.org/debian-alpha/2009/07/msg00015.html
http://lists.debian.org/debian-alpha/2009/08/msg00005.html
http://lists.debian.org/debian-alpha/2009/10/msg00003.html
http://lists.debian.org/debian-alpha/2009/10/msg00004.html
http://lists.debian.org/debian-alpha/2009/10/msg00011.html

Actually, alpha will be dropped in lenny+1:
http://release.debian.org/squeeze/arch_qualify.html

What on earth is debian 27?

Lenny is debian 5.0, and the next release, squeeze (6.0), lists ia-64 as not at risk (along with only i386 and amd64)
http://release.debian.org/squeeze/arch_qualify.html

Source link here, although your distro should have it in repo. It will take entire folders and turn them into a playlist, and it does it on the console, without the need for XULRunner. It's written in Python as well, so hacking it to support video players should be second nature for most of you.

There's a program that automates what you describe, and it's called "RSnapshot":
http://rsnapshot.org/

If you have a system that isn't always up you want something like this to launch it:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=27;filename=run-rsnapshot;att=1;bug=523923

Or at least link-posting. The link should of course be http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=python3&lang2=java

The question still remains, 10000X seems like a grave exaggeration. (Which is confirmed by http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=javaxint&lang2=java)

My point being that your assumption that JIT does THAT much of a difference is a bit flawed. CPython still is no match when comparing to JIT Java, of course, but the difference is roughly 30X, not 10000X.

Or at least link-posting. The link should of course be http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=python3&lang2=java

The question still remains, 10000X seems like a grave exaggeration. (Which is confirmed by http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=javaxint&lang2=java)

My point being that your assumption that JIT does THAT much of a difference is a bit flawed. CPython still is no match when comparing to JIT Java, of course, but the difference is roughly 30X, not 10000X.

You can run Java in a purely interpreted mode like Python does, pass the -Xint argument on the command line to the java instance. You'll notice it's 10000x slower than the optimized execution paths.

Then why isn't Python 10000x times slower than Java? http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=python3&lang2=javaxint

Did they consider using Debian along with the very well documented and reliable method to create local .deb files? They should maybe pin the kernel, but other than that...

Lookie here: http://wiki.debian.org/NvidiaGraphicsDrivers

Also, how does it differ between proprietary and open source then? If you're using some 10 years old version of your Linux OS and it doesn't support some feature that the newer OS/kernel versions have, you're not going to be able to install programs that require said feature.

If you have the source, you can port it to the newer version even if it's not profitable for the developer.

For example, the free drivers for the ATI cards based on the Mach64 chip (released in '92) are still supported in current Debian.

It's in the repositories, like everything else.

Oh come on, Python was designed as a teaching language and in my experience students find it much easier to learn than Pascal (and it's much less limiting once you get past the basics).

As far as speed is concerned, according to the Programming Language Game Pascal is at best 60x faster than Python, and these sorts of competitions usually give you a few orders of magnitude in margin - the idea is to make sure your solution is in the right complexity class, not to try and enforce the most efficient possible solution.

This is very disingenuous. The upgrade guide contains all possible contigency plans incase you have altered system files, or have chosen not to upgrade the kernel etc.

For example look at the debian lenny upgrade notes. They are way longer but generally debian based distros are considered some of the best for upgrades.

It's amazing no one's mentioned TuxType so far. Just do 10-15 minutes every day as a rule, and you'll improve your technique in no time.

Even though I know how to touch type, I find that my technique deteriorates, and using Tux Typing for a week or so refreshes my skills, especially if I know I have a lot of typing to do for a given project.

sudo apt-get install tuxtype (or click here from FF to install).

Windows/Mac/BSD/RPM here.

Nobody's going to guess a 2048-bit RSA key.

http://ftp.de.debian.org/debian/pool/main/o/openssh-blacklist/openssh-blacklist_0.4.1.tar.gz

If the 2048 RSA key is one of these they probably will, get it, especially if they have a million chances.

This is a trivial problem when the company can just use something like http://packages.debian.org/lenny/alien to convert their RPMs to DEBs, and then release it as a "BETA" or they can go the extra mile and hire another QA guy.

Are you using the 64-bit flash plugin? Ubuntu has inexplicably ignored it in favour of the unstable nspluginwrapper option, despite the vast difference in user experience. Their rationale is something about it not being supported by Adobe. On the other hand, the 32 and 64 bit players have had version parity whenever I've checked, and there is a fairly large stream of comments on the relevant bug that confirm that the 64-bit plugin works much more reliably. If you're using 64-bit Ubuntu and the default flash package, it is definitely worth your time to install the 64-bit version from someone's PPA (or from here).

As for Moonlight, it's just a token to answer to naysayers who complain that Silverlight isn't cross-platform. Their website seems to want to confirm this with a headline of "Watch the Olympics on Linux with our 3.0 preview". I tried to use it to stream Olympics coverage from ctv.ca, and it didn't work in any sense of the word (and yes, I've seen it work fine on Windows, which is how I knew to go to CTV in the first place).

The unix shell is much better at interacting linguistically with a user than a browser with a bolted on keyword system. Use the right tool for the job, like Surfraw.

there are TONS of mission critical servers out there running Debian, CentOS, FreeBSD, OpenBSD and other "there is no company you can blame and/or sue" operating systems

Absolutely false inaccurate information, at least for Debian.

As per

http://www.debian.org/consultants/

"811 Debian consultants listed in 64 countries worldwide."

Now, you can hire a consultant whom might actually moonlight as a debian developer, perhaps even the maintainer of something that is critical to you. And, as a private citizen or at least small consulting company, you could sue them when/if they screw up.

On the other hand, if you think you you can sue microsoft, and win, next time exchange falls over, you are in for a BIG surprise.

I wonder what Debian GNU/kFreeBSD would be considered.

Maybe it is this bug ... if I ever had had faith in Adobe, it would have been gone by now.

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

How's the PowerPC Linux port of Flash coming, Adobe? right...

The amd64, armel, hppa, i386, ia64, mips, mipsel, powerpc, s390 and sparc ports all seem to be coming along...

Oh wait, you wanted _Adobe_ to do something about it? I'm pretty sure they fired the only developer who understood their codebase years ago.

Open source doesn't mean the software is FREE, it just means it is open source.

The Open Source Definition, for what it's worth, was originally based word-for-word on the Debian Free Software Guidelines.

Techonologically, a lot of software just inst available as open source.

I'm aware that video games are in this situation, but this article is about the public sector. Could you describe a couple genres of software used by the public sector that have no Free equivalent? Even electronic medical record software is free software, thanks to VistA CPRS developed by the U.S. Department of Veterans Affairs.

So for a long term saving, it's often cheaper to stay with what you've got

Until it's end-of-lifed. Migration costs from Microsoft Office 2003 to Microsoft Office 2007 aren't necessarily less than to OpenOffice.org unless employees need, for example, the Access component.

You can also repair the computers by installing software that's free, technically superior and reasonably more secure than Windows.

You can download yours from: http://www.ubuntu.com/ http://www.debian.org/ http://freebsd.org/ and so on.

Never say never... Admittedly this battle ended about a decade ago. Not sure how/why SF caught up with the 90s and had their little fit.

http://www.debian.org/legal/cryptoinmain

...so I will be happy to load Debian on any ARM netbook.

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

For me the challenge is that there are not any mainstream manufacturers that have one available yet here in the US for me to try.

I plan on using it as a fun web surfing and email system. Maybe open office,evince for the ocassional attachment. ...Hopefully soon?

Debian GNU/Linux on ARM

Current Status:

Debian fully supports a port to little-endian ARM. As of our latest release, Debian GNU/Linux 5.0.3, the following ARM sub-architectures are fully supported:

        * footbridge: we fully support Netwinder machines and Simtec's CATS evaluation board
        * iop32x: we support some IOP32x based Network Attached Storage (NAS) devices, such as the Thecus N2100 and GLAN Tank
        * ixp4xx: we support the popular Linksys NSLU2 device.
        * orion5x: we support Marvell's new Orion platform and we have specific support for a number of devices, including the QNAP Turbo Station (TS-109, TS-209, TS-409) and HP mv2120.

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

You can use Stable and a backported kernel.

The Debian actual release is Stable. Everything else is not supported; Testing is not a "newer version", it's more like a development tree (well, less than Unstable, but even so).

Ubuntu simply had a different philosophy than Debian; they are willing to risk some stability (compared to Stable, not Testing!) for newer packages.

But using Squeeze now is ok - it'll probably go "freeze" in March, and then be released, so it's almost Stable. But remember to keep "squeeze" and not "testing" in sources.list when the release happens, or else you'll use the "new" testing, which will start to receives packages from Unstable.

I feel Google works significantly better for Ubuntu than for Debian: there's just a much bigger community out there it seems, to me.

Google does kind of work though for Debian I think.

For the installation process, I used debootstrap from my Ubuntu into a new partition, since I don't have a dvd or cd drive... so I can't tell you how well the 'official' installer works.

I think debootstrap was fairly painless for me. These were the instructions I followed:

installing debian using debootstrap.

Generally, I feel if you have a cd player and lack masochistic tendencies that using the official installer is most likely going to be an order of magnitude easier than using debootstrap :-P

Then again, it may have gone something like this:

• Mozilla: Listen carefully, Debian. Mozilla controls everything it rests its eyes upon. It holds a trademark so massive it shakes the ground with its registration, so vast it drinks the coke machine dry. All the God-King Mozilla requires is this: a simple offering of signing an agreement. A token of Debian's submission to the trademark on the Firefox name.
• Debian: Submission. Well, that's a bit of a problem. See, rumor has it that signing an agreement with Mozilla means that we would no longer be able to make changes to the version of Firefox we distribute and that clearly violates both our Social Contract and the Free Software Guidelines.
• Debian: And of course Debian... has its reputation to consider.

But I wasn't there so I don't know either. It's entirely possible that the whole event was just a simple adjustment meant to reconcile two conflicting requirements -- That Debian software remain unquestionably Free and that the Mozilla group retain control over the Firefox, Thunderbird, SeaMonkey and SunBird trademarks so as to ensure the high quality of software distributed under their names. But then it wouldn't be nearly as exciting to watch and people would get bored.

It's much more fun to imagine that license discussions were conducted while all parties had their shirts off and were threatening one another with giant Q-Tips while the Star Trek fight music played in the background.

http://freshmeat.net/articles/red-hat-updated-lynx-package-corrects-a-security-flaw-2
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510348

So I suppose there is no chance of running Etch on it?

Billions lost on failed UK IT projects by the 'adults' with developers receiving very fat paycheques shows it guarantees neither success of the project nor accountability within it.

Yeah, don't even get me started on such "adult" software as VxWorks, where $30k will get you "oops, we released a version of our compiler and stdc library that didn't close a C namespace in a header, thereby breaking any C++ code you include it in." Stuff *beginners* would be chided for. Stuff that would have *easily* been caught by unit or regression tests, which scares me further still because it means they probably don't have them.

Here's a hint to all the FOSS haters: most FOSS is not developed by inexperienced "gee, let's see what I can do with a computer!" types, even the unpaid stuff. The large majority of FOSS (especially the large successful projects) is developed by people who develop software for a living. The only difference between them and other paid programmers is that instead of having a hobby like golf or fantasy football, they go home and work on software that scratches a personal itch (assuming they aren't getting paid to work on it already). Now, let's just think about this: which software would you trust more: something written by someone who is just there to punch the clock and spends his breaks thinking about Paris Hilton, or someone who loves making software so much they can't keep their hands off a keyboard for more than a few hours? You can scream "boring nerd with no life" all you want, but the simple fact that most FOSS developers are professional coders, added to the fact that they work on software more than other devs, plus the fact that they decided to share the fruits of (some) of their labors with the world puts their software head and shoulders above most "paycheck only" software.

BTW, many FOSS coders I know of have other hobbies (and families); it just seems like they are able to pack so much more into a day than most people, it amazes me. Maybe they code faster; they are, by definition good coders, otherwise I probably wouldn't have heard of them. Or maybe they just don't waste so much time on things like TV. But just jump on Planet Debian and you will find scuba divers, cyclists, hikers, runners, community activists, etc, etc . . .

Also, I'm not slagging _all_ non-FOSS coders (technically, I am currently one . . . ). It just seems that where the source isn't available, and people aren't scratching their own itches that software generally sucks more.

but other than a gui I see no outstanding advantage over the FBSD package system

As a gauge of relative activity level in each package system:

The weekly list of UPDATED (and possibly NEW) BSD packages at

http://www.freshports.org/ports-new.php?interval=week

is roughly equal in size to the weekly list of NEW Debian packages at

http://packages.debian.org/unstable/main/newpkg

So, each week, there is about as much new stuff added to Debian as there is updated preexisting stuff in BSD.

Why use freebsd with GNU apps, when you can just run freebsd?

Then you'd be stuck with freebsd apps instead of GNU apps.

If you have a mighty herd of servers, desktops, and kiosks, all sharing various automation scripts, supporting both freebsd and GNU command line apps could be a pain, due to subtle differences in command line options, etc. Its possible to create a blizzard of "if then" to work around, but why bother.

But I am missing the improvement for Debian here.

Overall, none really. The way ports work on Debian, is if enough people volunteer to maintain a port, and they are successful, then we have a new port. Heck, that is the way everything works in the Debian project, if something meets a certain standard of excellence, its in, no matter if its a package, docs, artwork, shared VCS, human language translation, a network service, a mirror, or in this case, a port. Debian is thankfully not a deletionist stronghold like that dumpy embarrassment known as wikipedia.

This link provides a one page summary of each attempted Debian port, successful and ... not so successful :

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

Why use freebsd with GNU apps, when you can just run freebsd? And why freebsd and not lets say, openbsd or netbsd?

They actually have a NetBSD port as well as a Hurd port. They also have a nifty why NetBSD section. There doesn't seem to be a similar page for kFreeBSD, but I assume the reasons are similar.

Why use freebsd with GNU apps, when you can just run freebsd? And why freebsd and not lets say, openbsd or netbsd?

They actually have a NetBSD port as well as a Hurd port. They also have a nifty why NetBSD section. There doesn't seem to be a similar page for kFreeBSD, but I assume the reasons are similar.

Why use freebsd with GNU apps, when you can just run freebsd? And why freebsd and not lets say, openbsd or netbsd?

They actually have a NetBSD port as well as a Hurd port. They also have a nifty why NetBSD section. There doesn't seem to be a similar page for kFreeBSD, but I assume the reasons are similar.

From what I've seen, and I did look into the matter a great deal, mp3 decoding (playing) hasn't really been an issue, either because Franhougher (I don't remember how to spell it) doesn't bother to sue anyone who makes software mp3 players or their claimed patent on it doesn't exist / isn't valid.

The problem is with mp3 encoders. Sometime around the late 1990s the company started suing open source developers until they stopped making any encoders. The only project which survived was GNU Lame, but apparently only because they had the legal backing and they declared their program for "educational and research" purposes.

This is why Ogg Vorbis gained traction. Open source developers didn't have to worry about being sued when using this format. Also note mpeg 4 video may have similar problems. The group which handles licensing (I believe called MPEG-LA) has repeatedly said they want to charge per file created, not just per encoder.

It could get really expensive if they decide to do this. This is also why Ogg Theora is important. Not necessarily to get everyone to use it, but for an alternative in case you can't afford or don't want to pay license fees. Some video game companies use ogg vorbis because there is some high flat fee for the license of games. I think it was $30,000(US)/game when I checked. Not a small amount at any rate.

If you need to encode for your mp3 devices, from what I understand (IANAL) the patent for mpeg layer 2 has run out, so you don't have to worry about royalties. The project toolame encodes layer 2. I know it is on debian and the source should be easy to find. It is older codec, so doesn't compress as well.

But then from my observations in sound and compression, mp3s are inferior to ogg vorbis. mp3 is just used because every device supports it and everyone is used to it. Some company (same one?) came out with a "mp3 pro" format, but no one used it and no one cared. Probably for the same reason as vorbis, but also because it required licensing fees as well.

So I am not really sure anyone will notice or care about any issues with layer 2 anyway. I notice a little, but only because I try to get my files really small (below 64kbps if possible)

I wish this functionality was built into the OS, rather than having to do it manually (for example, a way to disallow internet access during installation) -- but at least it's doable on Android. I don't think any other phone platforms give this level of permission separation or control. I'm not so sure that app review would really fix the overall problem; it might catch the obviously-malicious phishing apps like in this story, but I bet that the app auditors' opinion on what is a privacy violation differs greatly from my own.

Maybe you're thinking of http://wiki.laptop.org/go/Rainbow, which implements http://wiki.laptop.org/go/OLPC_Bitfrost, which does exactly what you're describing. It's currently in Debian ( http://packages.debian.org/unstable/main/rainbow ) and Fedora ( http://ppc.koji.fedoraproject.org/koji/packageinfo?packageID=7262 ).

Then the people grabbing the binaries will get a trojan (assuming they have permission to execute the binary, which 99% of normal Linux PCs do allow).

We discussed it last month.

However, most people download all their software from a signed software repository (maintained by Ubuntu, Debian, Red Hat etc) which should go a long way to prevent this. The package manager verifies the signatures of the files downloaded (preventing a mirror maintainer changing the files), so you are putting your trust in the repository maintainers. Hence, Debian (for example) has some strict requirements before giving people access -- I would think someone having verified your ID would be a strong deterrent, as (I think) anything you sign for release would be linked to that ID.

Actually, Debian as always had leaders. Right now it's Steve McIntyre.

And Debian now has a release cycle:

The Debian project has decided to adopt a new policy of time-based development freezes for future releases, on a two-year cycle. Freezes will from now on happen in the December of every odd year, which means that releases will from now on happen sometime in the first half of every even year. To that effect the next freeze will happen in December 2009, with a release expected in spring 2010. The project chose December as a suitable freeze date since spring releases proved successful for the releases of Debian GNU/Linux 4.0 (codenamed "Etch") and Debian GNU/Linux 5.0 ("Lenny").

http://www.debian.org/News/2009/20090729

Actually, Debian as always had leaders. Right now it's Steve McIntyre.

And Debian now has a release cycle:

The Debian project has decided to adopt a new policy of time-based development freezes for future releases, on a two-year cycle. Freezes will from now on happen in the December of every odd year, which means that releases will from now on happen sometime in the first half of every even year. To that effect the next freeze will happen in December 2009, with a release expected in spring 2010. The project chose December as a suitable freeze date since spring releases proved successful for the releases of Debian GNU/Linux 4.0 (codenamed "Etch") and Debian GNU/Linux 5.0 ("Lenny").

http://www.debian.org/News/2009/20090729

toncho/~ sudo apt-get install spamassassin
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
    libmail-dkim-perl
Recommended packages:
    re2c
The following packages will be upgraded:
    spamassassin
1 upgraded, 0 newly installed, 0 to remove and 1086 not upgraded.
Need to get 1097kB of archives.
After this operation, 0B of additional disk space will be used.
Get:1 http://ftp.us.debian.org/ unstable/main spamassassin 3.2.5-7 [1097kB]
Fetched 1097kB in 13s (84.2kB/s)
Reading changelogs... Done
apt-listchanges: Mailing root: apt-listchanges: news for toncho.dhh.gt.org
(Reading database ... 163295 files and directories currently installed.)
Preparing to replace spamassassin 3.2.5-6 (using .../spamassassin_3.2.5-7_all.deb) ...
Stopping SpamAssassin Mail Filter Daemon: spamd.
Unpacking replacement spamassassin ...
Setting up spamassassin (3.2.5-7) ...
Starting SpamAssassin Mail Filter Daemon: spamd.

Here is the apt-listchanges message:

spamassassin (3.2.5-7) unstable; urgency=high

      This version of SpamAssassin fixes a bug which caused mails sent
      in 2010 to be flagged as suspiciously spammy. If upgrading to this
      version, you are recommended to update any per-user caches previously
      created by sa-compile, and to check mail already in your spam folder
      for false positives more carefully than usual.

  -- Joey Hess Fri, 01 Jan 2010 12:03:40 -0500

spamassassin:
    Installed: 3.2.5-6
    Candidate: 3.2.5-6
    Version table:
  *** 3.2.5-6 0
                701 http://ftp.us.debian.org/ testing/main Packages
                  70 http://ftp.us.debian.org/ unstable/main Packages
                100 /var/lib/dpkg/status

apt-get updated 30 seconds ago.

spamassassin:
    Installed: 3.2.5-6
    Candidate: 3.2.5-6
    Version table:
  *** 3.2.5-6 0
                701 http://ftp.us.debian.org/ testing/main Packages
                  70 http://ftp.us.debian.org/ unstable/main Packages
                100 /var/lib/dpkg/status

apt-get updated 30 seconds ago.

Ruby and Python are languages.

With defacto reference implementations whereby when someone mentions that language they specifically mean the reference implementation. I guess since Ruby is coming from such a performance deficit that general rule is thrown out the window; but that's news to the world. Made yet odder is the fact you specifically compared JRuby to CPython to claim superiority. Again, something is amiss. But then again, I previously explained all this.

Jython is one of the slower Python implementation

I decided to look based on your insistence. It does appear I may have had smoke blown at me many a time about Jython's performance; but most of the benchmarks I found were fairly old (a year or more). I did find mention that Sun was actively working to bolster Jython's performance from again, over a year ago. Regardless, I'll back off my assertion here as I couldn't find anything to bolster my position. It appears you're right.

But, I did find something which is very contrary to your other assertions and my own expectations. In the benchmarks I found, cpython was generally a lot faster than ruby 1.9 in 60% of the benchmarks. Based on comments, that shouldn't come as a surprise, but the smaller gap compared to previously ruby versions is still noteworthy. In 30% of the benchmarks, ruby 1.9 was on par with cpython. And in only 10% of the benchmarks was ruby 1.9 faster than cpython. In short, while cpython was faster than ruby 1.9, it looks like its performance, like python, is good enough for all but those who have an axe to grind.

But more interestingly, it appears JRuby is actually a very mixed bag. In the benchmarks, cpython was a lot faster (33%-89%) than jruby in 36% of the benchmarks. Furthermore, cpython was as fast as jruby in a different 36%. Meaning, 73% of the benchmarks place cpython on par or better than jruby. In only 27% of the benchmarks was jruby faster than cpython, and in those benchmarks, jruby was considerably faster; 2x-3x than that of cpython.

To summarize cpython vs jruby, cpython is faster based on the sum of the benchmarks; cpython's 73% vs jruby's 63%, whereby the percent represents the percent of benchmarks which are faster or on par with the other. In other words, based on these benchmarks, ranked by performance you have cpython, jruby, and ruby 1.9, which isn't exactly as you've advertised and is even a surprising departure from my own expectations. It appears from a performance perspective, cpython vs rjuby performance is highly subjective based on the actual project and likely, its not accurate to claim jruby is faster than cpython.

Disappointingly, they do not provide benchmarks for jython or psyco.

As for psyco and my own experience, for two of my own projects (heavy network servers with cached and lightly accessed db backend via sqlalchemy), psyco resulted in a performance boost of 1.6 and 2.1 over that of stock cpython (version 2.5.something at the time. I forget exact version). Granted, the performance boost psyco provides is significantly affected by the project implementation. Having said that, with the addition of psyco to a python project, it would not be much of a stretch to anticipate cpython+psyco to be considerably faster than jruby, on average.

At the end of the day, I really did not desire to go down the performance comparison path, but I'm actually glad I did as I find these results rather surprising and interesting.

Cited benchmarks