I get the feeling that Pardus gets quite a bit of attention in the technical Linux sites which may be a better indicator.

Talking of which, there's another on TechRadar which has just published brief reviews of several distros under a number of categories, and Pardus is included in the Easy to use section:
http://www.techradar.com/news/software/operating-systems/the-best-linux-distros-you-ve-never-heard-of-919411?artc_pg=1

There's a brief note (not much more than a repeat of the announcement) in Linux User & Developer:

http://www.linuxuser.co.uk/news/pardus-2011-release-candidate-is-out-now/

Although in principle you don't, there are things that run better if you have one even if they fit into real memory. I'm not sure why, maybe some pseudo-filesystems actually try to write into the swap space.

Swap size == Memory size is the "traditional" value (although in the 2.2 kernel era there was a time when swap <= memory was useless this is no longer true [nor was it for 2.0.x and I don't go back to the 1.x kernels]) however with the larger real memory available these days it's probably not necessary to have that much. I'd suggest that a 1Gb swap partition is a reasonable size (I've not had any issues with 1Gb on systems ranging from a netbook with 1Gb RAM all the way up to a 24Gb compute server).

Also remember Seymour Cray's reason for not putting virtual memory on his computers: "If you haven't got it you haven't got it".

Maybe, like Bourbaki he are 

At the risk of shutting the stable door after the horse has bolted, the export path should be the mount point not the device name. So if the partition /dev/sda7 is mounted as /data then the export line should be:

I don't see the lag in typing, either on the login screen nor on authorization boxes.

Not exactly, but one thing I did see (which could be interpreted this way) was that with the very long list of updates after an install of 2011 beta2 there was quite a long delay between clicking on the update button in the package manager and the authentication screen appearing and I clicked again thinking I'd either missed the button or moved the mouse during the click.

When I did this the authentication window appeared, and I entered the password; but a window appeared saying that I was not permitted to do the operation. The system went ahead and did the updates anyway, but the only progress indication was the network monitor plasmoid, and the only way out of the package manager was via window manager kill.

Well slightly bonkers it appears! The setting comes after the reboot (IMHO not very good).
But the installer did ask if i remembered my password before the reboot.

I'm just installing 2011 beta 2 64-bit version on a new machine and nowhere did it ask me to set a username & password or a root password! Actually I'm doing it a second time in case I missed something.

Am I going bonkers or is there a major problem?

I think I've now got enough evidence that the wireless issue is a Pardus bug, since it works as it should with another 2.6.36 based live CD (Chakra) that also has the kerrnel rfkill as a module.

Now reported as: http://bugs.pardus.org.tr/show_bug.cgi?id=15552

For 2011: the path is http://packages.pardus.org.tr/pardus/2011/stable/x86_64/... (or i686 for 32 bit).

Turns out that there are 2 problems:
1) The package database isn't correctly set up on the live media and
2) /usr is read-only

[I'm wondering if there is a regression in the kernel rfkill in 2.6.36, there were some comments to that effect in one of the Arch forums. I'd be surprised if the Pardus devs go to 2.6.37 before the release after nearly getting burned by a late kernel update last time round.]

Turns out that the touvchpad is toggled by Ctrl-Alt-T on Pardus, not sure how it overrides the FN-F1 as that is (according to the folks at Sytem76) a hardware switch that should work on any OS [even DOS].

The wireless is still a bit of a mystery. One test I'd like to try is to see if it needs rfkill which is not on the live image. Does anyone know if the following scheme would work?

• Download the pisi package for rfkill to a USB stick
• Boot from the live image
• Mount the USB stick with the rfkill package
• Go to a root console and run "pisi it /media/mpt/rfkill.pisi" (or wherever the stick is mounted).
  

What sort of system do you have? I've been having a  problem at a similar location (http://bugs.pardus.org.tr/show_bug.cgi?id=15207) with a VIA CPU machine (HP2133) and when I looked at /var/log/syslog

• it was complaining about the CPU not being supported, while it may well not be related it could be.
• Goto a console with Ctrl-Alt-F1 and then "tail -f /var/log/syslog"

Since the ftp download was stalling, here are the http URLS:
http://ftp.pardus.org.tr/pub/pardus/install/2011/Beta2/
and
http://ftp.pardus.org.tr/pub/pardus/live/2011/Beta2/

Partly solved: The setting for different activities for each desktop is in the pager widget, not the system settings nor the activities menu

• Right-click on the pager
• Select "Pager settings"
• Go to the Virtual desktops selector
• Select "Different widgets on each desktop"

Not that discoverable but it is there.