scarecrow

Yes, it was on Archlinux. I do believe it was something wrong in the SVN revision I pulled out, as Arch may be cryptic for a GUI fan, but when coming to compiling from source, it's absolutely top notch. I have used a premade build script, from Arch AUR repository, but I'vew scrutinized the script and fould nothing wrong with it.

LXDE is most probably easier to use for the average Joe, but it's neither that lightweight, nor equally stable to IceWM. IMO this is a dubious decision... but anyway, since the only real dependencies of LXDE are GTK+ and python, it should work right-out of the box.

KDE 4.2.X is fairly stable- no kdeinit errors and plasma crashes anymore. You can log in to the backup desktop environment (IceWM, as suggested above), and from there call the control center (mcc) and perform a system upgrade. This may solve the problem. In short, I agree with almost everything to Arctic, except the buggy nature of KDE4, which is no more much of an issue.

Fedora devs will ***ALWAYS*** make weird decisions, simply because Fedora is really avantguard distro.

Oh yes, it's obvious it's not your decision. After all, I realized it while trying to build the latest one from svn (the CLI version, as the GTK one has many Gnome dependencies- I wanted to use the experimental QT4 QUI, which has only phonon as KDE4 dependency). I cannot say much, as the included ffmpeg failed to build- I may try again with a later SVN revision, but still, this may be OK for windows or (less so) OSX, but it's definitly ODD for a Linux app.

Yes, the patch takes care of the problem with your revision of the ALC889A codec. However, this isn't included in the latest alsa 1.0.20... you have to pick from 1. waiting for alsa 1.0.21 2. building yourself alsa from git Both these solutions may break PulseAudio, unless you rebuild that one as well, I have to warn you. The final fix, according to the alsa mailing list, will be when kernel 2.6.31 is out, which will take a few weeks (2.6.30 stable was released fairly recently). Regards.

You have to enable PAE in your BIOS. This will, most of the times, decrease the system performance, so (IMHO) you should do better leaving things as-they-are.

Just realized that this program is linked statically to every needed multimedia library, instead of using the existing shared ones. Why? This isn't the right way to build a Linux application!

You will need the Linuxant driver, which, sadly enough, is capped at 14.4 kbps. The fullefatured driver costs money.

The problem was recently rectified by Alsa devs: http://mailman.alsa-project.org/pipermail/...May/017393.html But, before fixing anything we should first know the revision of the ALC889A chip. Which is the output of the command head /proc/asound/card0/codec#0 in a console?

Well, this log ***SHOULD*** be readable by root, only. Anyway, KDE4 has KSystemLog (part of kdeadmin) to view all systam logs, but again you have to use either kdesu, or (if installed) kdesudo to access these logs.

Maybe their logic is that Gnome/Canonical have picked the most sexy system sounds for ya, and they won't let you ruin their masterpiece with ugly noises? :D Actually, the Gnome ***VISIBLE*** settings are lacking in so many ways, that this one has never bothered me that much...

Give Puppy another try, and at some point try from a console modprobe yenta_socket If your PCMCIA card is detected after that, then you can preload that module (which is the standard one for PCMCIA stuff and 2.6.X kernels).

A Pentium I with 148 MB should run the current Mandriva (the kernel is i586 optimized, if I'm not mistaken-so it should work, while i686 should not) and a light DE (XFCE4 or LXDE) rather decently- no real multitasking, OpenOffice should be rather too heavy, but most things, including firefox, gimp, geeqie, mplayer... should run at tolerable speeds. Mandrake 9.2 is running kernel 2.4.XX, which is, errr, old. Another idea could be Puppy Linux- great performance on old hardware, quite easy to set up, and rather pretty and fullfeatured (from gui, not cli) for such a minimalistic distro. The only pain should be localization, esp. for eastern locales, which is not exactly trivial in Puppy.

Base is the platform of the suite, and required by the other components. The rest are independent of each other.

Perhaps stopping the network service first, or switching to a newer, fully HAL managed system. 9.2 was a good release, but rather too archaic under the current standards.

Just for the record, Go-OO 3.1.0 is official, and it does work quite well (have not tested yet its mono integration).

Unfortunately, the only driver which used to work and provide hardware-accelerated 3D on ATi cards is no longer working with the new xorg-server 1.6.X There has been limited success with new catalyst releases, but overall, the results are far from satisfactory. This is neither Mandriva's, nor xorg'd fault. Simply anough, and unfortunately enough, the ATi devs have proved themselves unable to maintain a reliable 3D-enforced driver up to now.

Canon printers are currently supported (most of them, anyway) by the Gutenprint drivers. The only issue is that the Gutenprint drivers are capped at 600 dpi, so they aren't good enough for photo printing. Nevertheless, if you are sure about your printer's abilities, you can touch a source file and build a ppd for your Canon with just the right printer characteristics. These of course are far from simple, even for experienced Linux users. The easy way is called Turboprint, but this isn't a free solution (or even a cheap one).

Things are simple:If you want 3D and you have an ATi card, then... use windows. :P Unfortunately, this is the case: ATi devs have proved themselves being amateur coders, at the very best.

Could well be, but richard-qt has an nvidia gpu, so it's another case. @ richard-qt: any messages worth talking about at /var/log/everything.log and/or /var/log/Xorg0.log ?

I'd be utterly surprised if you didn't, as Mandy 2008.1 does not have xorg 1.5.x and input hotplugging... so a usable xorg.conf is mandatory, unless of course you're using a DE like XFCE4, which can also run (with quite some limitations) on framebuffer.

alt+ctrl+backspace does not work by default with xorg 1.6.0 To make it working again (with the newest versions of xorg) see here: http://wiki.archlinux.org/index.php/Xorg#C...oesn.27t_exit_X (and yes, it applies for pretty much any distribution with the latest xorg). IMHO this new policy is just ridiculous: why kill one of the most useful features of xorg because an Ubuntu noob may press alt+ctrl+backspace by accident?

Did you consider using static IP's at your LAN instead of DHCP? It would be much easier to set, especially if your Linux installation is using iptables, or any other firewall.

Oh... then I may suspect the way xorg is built? But no, xorg is not kernel dependent in any way. What do you get as /etc/xorg.conf after running # nvidia-xconfig --composite