It should, but I would strongly advise making a backup just in case anything goes wrong. There might be issues with ownership and group,  I don't know enough about PClos to know how it handles users & groups.

That depends -- scripts should be just fine, c & fortran code will probably be OK, c++ might need to be recompiled & relinked depending on whether your previous distro had similar versions of the c++ libraries. (Of course if your previous distro was 64-bit then any compiled code will need recompiling).

I use Konqueror as my main browser on some machines and these are just a few thoughts:

Good:

• Integration with file-management
• Support for other protocols (FTP, SFTP...)
• Handling of links to movies, images etc.

Bad:

• Flash plugin -- inclined to go into a "runaway" 100% CPU state
• Recognition by web sites (not really konqueror's fault but many site including gmail go to a minimal version or refuse to work). You can tell it to lie to the site but do so at your own risk.

Another concern is the state of future support, KDE now defaults to the Dolphin file manager over konqueror, and it looks likely that the WebKit-based rekonq will become the preferred browser, the current version (which is not the one in Pardus) is getting quite usable though there are rough edges. [As a personal aside here: I think that the integration of file manager & browser was a good thing and that KDE is going the wrong way in separating them].

That certainly works a lot better than qemu, thanks for the pointer.

(As regards the resolution with the Nvidia drivers, all I know is that I had the same issue with at least 4 distros.)

There is a virtualbox package in the main repository for 2009.2, which I have installed but:
1) I couldn't find an option to install from an ISO on disk,
2) I've not had a chance to mess with it since fixing the bad memory, that was causing both virtualbox & qemu to crash during installations.

I'll give it another go over the weekend.

[As for the Nvidia drivers and the FX5200, as I recall the proprietary driver works at 1680x1050 over VGA but not DVI, and the VGA quality on that monitor is significantly less crisp than the DVI. The resolution issue was discussed somewhere, probably in the Ubuntu forums.]

There's a short article/review of Pardus 2009.2 in Linux Journal
http://www.linuxjournal.com/content/spotlight-linux-pardus-linux-20092

I've just installed qemu and qtemu on my Pardus box, and then used it to install xubuntu (maverick) as a virtual machine.

Though it worked (apart from the fact I could only get Lilo to work), it is incredibly slow (1 hour+ and it hasn't finished booting & logging in). My first guess is that the problem might be that the video card/monitor combination that I have (Nvidia 5200, 1680x1050 screen) needs the nouveau driver (Nvidia 173 won't go above 1600 in the X direction with the digital output).

Can anyone confirm/deny this?

System:  Athlon Xp 2600+, 3Gb Ram, IDE disks
Virtual image has 20GB disk, uses 1Gb ram.

That flags a supposed spelling error. If your language settings are not for English, then most English words will be flagged.

My concern there is whether trying the flgrx (hope I got that right) driver has screwed the "card" -- it was giving the right resolution before, and further checking says that the current version is only for r500 and above.

I've been trying to get Pardus up and running on an ASUS Pundit P1-PH1 with Intel P4 3GHz processor and Radeon graphics, and the X configuration has been driving me nuts. The worst is it's inconsistent.

The relevant lines from lspci -v are:
The monitor is a 1680x1050 ASUS LCD.

The first problem's not a Pardus one: No matter what I try I can't get anything out of the DVI output.

When I installed the 2009.2 Beta, things were OK (but slow, glxgears gave 1-200 fps) until I tried installing and enabling the fglrx driver, at which point I lost X altogether. After a number of unsuccessful attempts to fix it, I reinstalled with the final release and then the "fun" started.

The first few attempts X remained resolutely unavailable.
Eventually I was able to get X started but only 1024x768 resolution (stretched to fill the screen).
I tried telling it the capability of the monitor, and desired resolution, but it remained 1024x768 in "system settings".
Tried specifying alternative drivers (ati, radeon, radeonhd) with no success.
Returned to default (F4 - probe again on the boot screen) and respecified the monitor & resolution.
This time it came up with 1400x1050, not stretched but with big black bands at each side (and vertically displaced) [I have attached the current xorg.conf renamed as xorg.txt].

Has anybody else had any success with this piece of junk, or is it only fit to throw off a high cliff (no tall buildings round here).


James

I was able to install it from the repositories (I didn't actually notice if it was contrib or testing) yesterday [Friday evening US Mountain time zone].
I've had better results with the Pardus build than the Ubuntu one which kept handing when pressing "back" on pages within the BBC News site.

One thing no-one seems to have commented on yet: The boot screen colour is getting close to the Pardus colour!

Actually the new (K)ubuntu boot screen lacks a proper progress monitor unlike the old one, the Pardus screen and many others.

I forget the  exact timeline now, but I think that the RC came out with the problem kernel, and there was then a fairly frantic exchange as it became clear that the problem was on pretty mainstream hardware. If you really want to check it out look for bug 11939 http://bugs.pardus.org.tr/show_bug.cgi?id=11939. In essence the devs produced a number of test kernels to try to isolate the problem (these were only installed by a small number of users [2 or 3 as I recall]) and the version numbers of these were then reused in the actual release and the version that was released re-used the version number of one of the tests that didn't work (and I had left that lying around).

I've managed to figure this one out. The good news is it's unlikely to affect anybody else to the extent of unbootability:
The rescue system creates a menu.lst entry not for the latest kernel it finds on the disk, but rather for the one matching the 2009.1 original release. However on my system  that was one of the test kernels generated to track down a major kernel bug

•   just before the 2009.1 release (for the release the developers reset the build numbers). Moral: don't leave defective development kernels lying around!
• Unable to boot AMD Athlon XP CPUs.

Not good so far.
1) The 2009 CD left the boot list unchanged (and failed to exit properly -- python syntax error).
2) After renaming menu.lst & grub.conf 2009 left grub with nothing.
3) 2009.1 produced a new boot menu but the Pardus entry won't boot (I've not yet had a chance to investigate properly what it's done as the machine has now decided that it won't boot from CD [any CD so it's not just a marginal burn])

I'll probably have to wait for the weekend to see if it's just a loose IDE cable or a failed drive.

On my "test-bed" machine, I have 3 different distros installed. Originally Chakra (Arch), Mandriva and Pardus.  I then replaced Mandriva with Sidux, and that replaced grub with grub2. At this stage no major problem, it detected Chakra & Pardus (though Sidux became the default boot).

However following the recent Pardus kernel update, things start to come unravelled:
Not unexpectedly, the grub2 loader from Sidux didn't spot the update. So I figured: "try to install grub from Pardus", but grub-install still only has the older Pardus kernel listed (and still lists the Mandriva boot options).

Is there a way to get menu.lst to update (other than entering all the details manually via the system settings) to include the latest Pardus kernel (even if I have to manually add the Sidux one).