Crashdamage

Really, the short answer to this is you need to get another IPS. Beg, plead, promise to do more chores, blackmail her - whatever it takes - but get mom to get rid of AOL. It has to be the worst ISP there is. Horrible even for Windoze users. Everything is non-standard proprietary crap. Look at it this way...AOL/Time-Warner merged into a single company long ago, right? But AOL is SOOO bad that Time-Warner Cable still offers Road Runner as the 'default' ISP for their cable 'Net service. If you insist, they'll sell and let you use AOL, but they'd much rather you didn't. Now, what does that tell you about AOL? And AOL wonders why they're bleeding subscribers like a stuck pig...

Well, of course the -12 version is newer than the -6 version. Download the one that matches the kernel you are using. Stay away from the 'stripped' versions. They seem to have stripped out a bit too much.

Exactly. So you did not compile it with gcc-3.4 on your system. And the Cooker kernel rpm you installed was probably compiled with gcc-4.0. Like I said: $ cat /proc/version ...will tell you for sure, if you are booted into that kernel. I don't use an Nvidia card and have never built and installed the driver. So I probably never should've answered your question in the first place. But I think installing the Nvidia driver requires compiling it on your system and inserting the resulting module. Now, you're right that there's probably no reason the Nvidia driver won't compile with gcc-4.0, but that's not what you're using on your system. Unless you are running a full Cooker installation, you have gcc-3.4, which comes with either 10.1 or LE2005. So compiling the driver with the gcc-3.4 version installed on your system results in a mismatch with your Cooker kernel, because it was compiled with gcc-4.0. In other words, the Nvidia driver and the kernel it is used with must be compiled with the same compiler (gcc) or at least compatible versions. And gcc-3.4 and gcc-4.0 are not cross-compatible. You have the 4 choices I discussed before, but maybe having 2 versions of gcc (option #2) installed and choosing which to use for a given job isn't as difficult as I was thinking. You might also want to check out this thread: https://mandrivausers.org/index.php?showtopic=26622 ...and ask rolf for more detailed guidance about how to go about doing it.

As you said, the Cooker kernel you installed was compiled with gcc-4.0. ($ cat /proc/version will tell you for sure.) If you have 10.1 or LE2005, your system has gcc-3.4 installed. So when you try to build and install the Nvidia driver on your system, it's built with gcc-3.4 and the gcc version mismatch with the Cooker kernel causes failure. There's seeral ways to make thi swork, none really easy: 1. Recompile the Cooker kernel on your system to get a gcc version match. 2. Install gcc-4.0, leave gcc-3.4, have 2 versions installed and figure out how to compile the Nvidia driver using gcc4.0. 3. Go to a full Cooker install so you gcc-4.0 as the default compiler, then compile nad install the Nvidia driver.. 4. Revert to a kernel compiled with gcc-3.4. #4 is easy, quick, and should be an effective fix for your problem. Do what you want, but I'd do #4 first, #1 second, #3 only if I'm feeling really adventurous, and try to forget I ever saw #2. It's possible, but can be messy and I can't recommend it. You should also be aware that gcc-4.0 seems to have some problems and is still being sorted out.

Nah, you're much closer than you think to figuring this out. Once the light goes on, you'll surprised just how easy it is. First, don't use the old 'rpm -ivh' etc. commands. They still have their place, but are basically outdated. You want to use urpmi (or the GUI version of it, the 'Software Manager' in Mandrake Control Center). Second - I'll say it again - go to the 'Easy-Urpmi' link at the top of this webpage. Follow the instructions - they're pretty simple. Pick online sources for your distro version. Add sources for 'main', 'updates', 'contrib', 'PLF free', 'PLF non-free', and the sources for the norlug and Thac's rpms. Resist the temptation to add Cooker. And a quick tip: the European mirrors are usually faster than the ones in the U.S. Now you're set to really go. At this point, you might as well eliminate your CDs as sources (easy to do from the Software Manager, just open the 'Media Manager' and uncheck the boxes for them). You can do that because because with online sources for urpmi setup, now when you go to install a package, urpmi will automagically go online, fetch the latest version available for your distro, grab any necessary dependencies (if any) and install everything in the proper order. It's VERY cool. So, now, installing ksokoban will only require choosing that package in the Software Manager, or better, as root in a terminal just type: # urpmi -v ksokoban (like rpm, -v for verbose is optional, but I like the extra info) Urpmi will do the rest - you won't even need to insert a CD if you removed them as sources. As for your original problems: You already proved yourself that the libqt3-devel packages DID come with your Power Pack and ARE installed with the '$ rpm -q' and '$ locate' commands I gave you. If you can't find a package in MCC, then I think that maybe you're searching in the wrong place. Think about it - are you looking for what's already installed in 'Remove' or 'Install'? Because if you look for an already-installed package in 'Install', of course it won't show up - it's already installed, right? You have to look in 'Remove' for it. And visa-versa of course. As for compiling, without more information like exact error messages, etc., I really can't help you sort out any further exactly why trying to compile ksokoban with './configure' is failing - I just don't have enough info. But don't worry about it for now, just let urpmi make things easy for you. Get used to installing ready-to-go packages first and enjoy 'til you grok all this a little more. Oh yeah - you asked about that last line about tarballs and checkinstall... Tarballs are much like .zip files. Tarballs of software are like .zip files of software, but not ready to install - they're raw source code. Think of them as like Windows software code, but not yet made ready for installation on a particular WinOS version, be it 98, Win2k, XP. Raw source code has to be compiled on and made ready to install on your OS version, which is actually what you're doing with the './compile' command. Put simply, if you don't know enough to compile software in Windows (and maybe you do, I don't know your experience), why would you try to compile software on another OS? But Linux n00bs see this stuff on the 'Net and think it's standard Linux procedure, I guess. So they try it even though it would scare the hell out of 'em (whether using Windows or Linux) if they knew what they're really doing. Checkinstall is just a little utility, included with your CDs, that makes rolling your own rpms from source code very easy (though they are basic, i.e. not really suitable for public consumption). In a nutshell, checkinstall replaces the standard Linux commands: ./configure make make install With: ./configure make checkinstall ...resulting in a reusable rpm. To learn more, as root, just # urpmi -v checkinstall ...then: $ man checkinstall ...or do some Googling. Let us know how this all works out for you. And don't drink a tarball - sounds nasty.

Hmmm...looking back over your 1st post, I may have misunderstood just what you meant by 'Do you have to be root to do programming?' Well, you don't have to be root to write something (to 'do programming'), but you do to compile and install, which is what I think you really mean. So, have you been doing './configure' as root or as a normal user? If as a user, do: ./configure make make install ...as root. But be aware that regardless of your distro or whether it uses rpms , debs, or whatever, it's always a bad idea to install from source except as a last resort. Whenever possible (which with Mandriva is almost always bcause so many packages are available) use your distro's package manager and install binary packages to avoid possible grief down the road. I never install anything except rpms. Even if something is only available in tarball form, you can use a handy, simple to use little utility called checkinstall to make you own rpms that can be easily installed over and over, and maybe more inmportantly, easily uninstalled.

On my 10.1 Power Pack system: $ rpm -q libqt3-devel libqt3-devel-3.3.3-27.1.101mdk $ locate libqt3-devel /usr/lib/menu/libqt3-devel-assistant /usr/lib/menu/libqt3-devel-designer /usr/lib/menu/libqt3-devel-linguist Clearly, they are. No, but you need rights to whatever directory you are using and to have any required software in your $PATH. Possibly. Check your $PATH and see. Ummm...Google? Or post back here with more details after you are sure you have the required stuff installed and in your path. BTW, if you don't want to fool with building it yourself anymore, there is a ksokoban MDK 10x rpm available from Thac's rpms. Configure your urpmi sources using the 'Easy-Urpmi' link at the top of any page in this forum, or you can download it here: http://rpm.pbone.net/index.php3/stat/4/idp...c.i586.rpm.html

It's kinda hard to really trash Linux, I've only had to do a full reinstall once in 4 years, and that was after screwing up my very first install. I ran one install (MDK 8.2) for almost 3 years through many changes and upgrades. But it sounds like you've trashed perl somehow. Simply put, this is bad. Like glib, perl is part of the basic underpinnings in Linux and runs many functions. Seems you managed to create a similar situation to in Windows where maybe you do something like click around on other functions while a program install or update is running and manage to trash a bunch of .dlls. Maybe someone else here can help, (I hope so) but I can only think of 2 ways outta this: 1. Put your install CD1 in and try to rescue the install. 2. Put you install CD1 in and start over with a fresh installation. I'd bite the bullet and just do option 2, after backing up, of course. And learn from your past mistakes. I hope you have a separate /home partition. If not, make one before you reinstall.

You can use an old rpm command: $ rpm -ql <packagename> as for your request: $rpm -ql plugger That will give list of all the files installed by that package and their location. Usually, executables are in /usr/bin.

So did I. It's a definitely a DNS problem, but I couldn't get around it. For instance, http://64.233.167.147/ would bring up Google, but www.google.com would not. I had 'IPV6' disabled already, foolin' with it further did nothing. So I tried skipping my ISP's DNS server and setting up a different DNS server (tried MIT's and a couple of other university public servers) but still no go. I finally went back to the .rpm I was using.

Well, urpmi is VERY useful. In Easy-Urpmi, add 'Contrib', PLF 'Free' and 'Non-free', Norlug and Thac's sources, and of course the main and updates sources for 10.1. Then you should be able to automatically download and install at least very recent, and sometimes the newest, versions of almost anything you need by just su'ing to root and: # urpmi -v <packagename.> Add the Cooker sources at your own risk. That's beta stuff in testing for the next release and may or may not cause problems, though it's pretty cutting-edge. If Cooker still tempts you, be aware Cooker stuff may be particularly troublesome right now since while 10.1 and LE2005 are compiled with gcc3.4, the next release (Mandriva 2006) will be gcc4.0-based and more and more Cooker software is being compiled on gcc4.0 and so can possibly be problematic. Also, Mandriva is undergoing some significant changes while it integrates with Connectiva/Lycoris. Things should shake out better by the 2006 release.

Yeah, sounds like you've gotten into a lot of trouble here. If you keep messin' around, you will almost certainly break something(s). For starters, GLIBC is one of the basic underpinnings of Linux distros, and for all but the most experienced users should only be ugraded by upgrading the entire distro. Additionally, it sounds like you've installed at least some stuff without using urpmi, (the CLI equivilent of the MCC>Software Manager GUI, but more powerful) instead installing software from source tarballs. This is not good, because now urpmi has no idea what you've installed, so can no longer keep all the dependencies, library versions, etc. organized and compatible. The lesson to be learned is regardless of your distro or package type, it's always best to use the distro's installation tools and install packages intended for your distro. Source tarballs should only be used as a last resort. In this case, that means you should've installed The Gimp with urpmi, and if you had, urpmi would've taken care of all dependencies, etc. for you. As far as fixing things now, best bet is to uninstall everything you installed using: # ./configure # make # make install instead of the MCC Software Manager or: # urpmi -v <packagename>. Then go to the 'Easy-Urpmi' link at the top of this forums' page and follow the directions to setup online package sources and start using the real power of urpmi. You didn't say what version of MDK/MDV you're using, but once you get 'Easy urpmi' properly setup, it will, like I said, automagically fetch and install the latest available version of The Gimp, (which should be at the least fairly recent) any dependencies, and install everything for you in the proper order.

Maybe a dumb suggestion, but have you tried going into MCC>Network Config and unchecking the little box that tells MDK to set the hostname by DHCP?

You should be good to go, as long as your XP CD is SP1 or later, you didn't say. I understand early XP CDs, especially XP Home, can still be problematic. If you happen to have a Win2k Pro CD, you absolutely should use that. XP sucks large compared to Win2k anyway. Remember it must be Win2k SP4 for AutoCad. If you have an earlier version of Win2k, you can download and save SP4 and make your own Win2k SP4 CD with nLite (just Google for it). If you have an early XP CD, you should be able to do the same kinda thing for XP with nLite. Then install from the new CD or do like I did and just install directly from the HD with the Win2k SP4 ISO file you make. I hope you also have a fairly fast machine and 512MB or more of memory. W4L will crawl if you start getting into swap. Go to the link devries kindly provided in his reply and follow the instructions there carefully. You'll definetely need to install KQEMU acceleration. Do it as soon as you finish the initial W4L installation, *before* you start installing XP, any software, updates, etc. Use the latest Win4Lin Pro test version .rpm, Win4LinPro-6-1.2-02.i386.rpm. Don't worry, it's rock-stable, and among other improvements works out some kinks with installing XP. Available from: ftp://ftp.win4lin.com/pub/testing/pro/ If you have questions or problems, post back here or at the new Win4Lin Forum: http://www.win4lin.com/phpBB2/index.php?si...9eee35ff4dc5d27 Be sure to give complete details of your problems, if any. Let us know how Win4Lin Pro works for you. It's been working very well for me, very stable and trouble-free if not blazing quick, over probably hundreds of hours of use. Sorry I can't give you any W4L/AutoCad-specific tips, but you'll find out, I guess.

Well, actually I wouldn't if you setup online sources through 'easy urpmi'. Or unless you're on dial-up. Most urpmi functions are there in MCC's Software Managment, but not all of them, and urpmi is really very easy to use from a terminal anyway. Below I'm going to include a little tutorial on urpmi usage I wrote and post on Usenet now and then. It's gotten a good response there and sems to help new users out quite a bit. Hopefully it will kinda sum up the basics of urpmi for you here in one place. It's intended for raw n00bs, even newer than you, so you can just skip by parts you might already know like how to 'su' to root, but pay attention - don't skim it TOO fast... **Basic urpmi setup and usage** Urpmi will easily and automagically take care of finding, downloading and installing software and its dependencies, if any. The "Software Management" utility in Mandrake Control Center is a simple to use GUI frontend for urpmi, but it's also very easy to use urpmi from the command line. To set up your online sources for installing/updating software you need to know how to 'su' to root, which is very simple. Just open a terminal and do this: $ su Password: <type.your.root.password> # Note that the cursor changed from '$' to '#' indicating you now have 'root' administrator rights, so be careful! If you don't fully understand the 'su' process or root permissions some simple Googling will explain it. Now to setup your online software sources. Go here: http://easyurpmi.zarb.org/ Follow the directions to setup your online package sources. Choose them carefully, staying with sources for your particular Mandrake version. You'll probably want to add the main sources for your version, updates, the Contributors sources, the PLF repositories, and maybe a few others. Warning: Add the Cooker sources at your own risk. Cooker is beta stuff still in testing for the next release and may or may not cause you problems. When you've finished setting up your source mirrors you can start using the real power of urpmi. You can now install/uninstall a software package using your newly-setup online sources either by using the GUI installer in Mandrake Control Center, or better, manually from the command line. To install manually open a terminal and 'su' to root, then type: # urpmi -v <packagename> ('-v' for verbose output is optional, but I like the extra info it provides) Note that usually <packagename> can be just the 'simple' version. Using the email client Mutt for example, instead of typing the full package name: # urpmi -v mutt-1.5.6i-2mdk.i586.rpm Use: # urpmi -v mutt Then urpmi will automagically go to the 'Net sources you choose, find and download the latest available Mutt .rpm for your version of Mandrake, grab any other packages needed to resolve all dependencies and install everything in the correct order. If urpmi can't complete the install, either because all the required software isn't available on the source mirrors you choose or possibly some other conflict(s), it will stop the install process before actual changes are made and give you some info about the problem. Similarly, for packages you've downloaded and saved, just navigate to the directory where you saved them: # cd /mysaved/.rpm/is.here Then (for this, you may need to use the full packagename): # urpmi -v <packagename> Uninstalling a package is simply 'urpme' instead of 'urpmi'. Be aware that while using .rpms compiled for other versions of Mandrake or for other distros sometimes will work fine, they may not and the possibility for problems exists. Think of this as similar to installing Windows software where installing something on Win98 but meant for XP (or vice-versa) may not work. The software should be compiled for use with the distro and version it's installed on. So always try to use correct .rpms for your distro and version whenever possible, which in the case of Mandrake is almost always. If you must use a .rpm from another version or distro, it may or may not work. But unlike Windows, urpmi allows you to do a 'test' installation instead of having to just try it and see what happens. To do a test install, do this: # urpmi -v --test <packagename> This does a 'dry run' to check if the package(s) can be sucessfully installed but without actually changing anything on the system. If all is well, remove the '--test' switch to install normally. It's important to always install .rpms (.rpm), not from tarballs, when using any .rpm-based distro like RedHat, Suse or Mandrake. This is also true of '.deb' package based distros such as Debian or Ubuntu. Why? Because if you always install .rpm packages (or .debs), then Mandrake's urpmi (or Suse's YAST, Debian's apt or whatever package manager) is able to properly keep track of everything installed on your system and so keep everything correctly configured and updated. But if you install any packages from source tarballs no information about that package or the files it installed are entered into the urpmi database. You then have a situation where urpmi cannot properly keep things straight since it has no info about the installed tarballs or their contents. The chances of installing from tarballs breaking anything is fairly slight, but it can happen, so why risk it if you don't have to? Sometimes a particular piece or a newer version of software may only be available as a source tarball. No problem - it's still very easy make your own .rpms from source with a handy utility called checkinstall, included on the Mandrake CDs. In a nutshell, checkinstall makes a simple .rpm package by replacing the traditional compile and install commands: ./configure make make install With: ./configure make checkinstall I won't go into more detail about checkinstall here. Google for more info about it or install the checkinstall package and type: 'man checkinstall'. This should be enough to get you going. For more info, open a terminal and type 'man urpmi" or maybe do some Googling, particularly 'easy urpmi'. Lotsa info available.

Win4Lin is not difficult to install, but more info is needed first. 1. What is your distro? 2. What version of Win4Lin are you installing? 3. What version of Windows are you installing? 4. Do you have a Win4Lin license already? You said you wanted ro run Autocad 2006. I've never used Autocad under Win4Lin so I'm not familiar with any details about it, but a quick check on their website indicated there's a few points to consider: Autocad 2006 apparently does not require friggin' DirectX, which is good for several reasons. But it's not Win9x-compatible, it only works with Win2k Pro SP4 or Win XP. So Win4Lin9x will not work for you since it's for Win95/98/ME. Win4LinPro does run Win2k SP4 or WinXP, but not at the blazing fast speeds that Win4Lin9x runs Win9x. Win4Lin9x has been around for years and is a mature product, but Win4LinPro was just released about 3 months ago and is only at v1.1. It has a lot of promise and some major advantages over Win4Lin9x and VMware, but just isn't at a high performance level yet. For comparison, at present Win4LinPro is about as fast as VMware and Win2k/XP (but cheaper), which is to say it's useable - I use it every day - but not like native Windows. Also, to get reasonable speed with Win4LinPro, it's best to install the KQEMU accelerator module. (Don't worry, it's very easy.)

Again, you're not quite clear. Just what do you mean by "control console rpm"??? Usually "console" refers to a terminal window, but I get the feeling that in this case you really mean the Software Manager in Mandrake Control Center, which is just a GUI frontend for urpmi. Anyway, you probably have 2 instances or urpmi running at once - one from the GUI in in Software Manager, another in a terminal (the '# urpmi -v xsane'). One has nothing to do with running the other, except you can't do both at once. As root simply type: # killall urpmi That should do it. If not, post the *actual* error message here so we can better tell what's going wrong. If you want more detailed instructions on how to use urpmi, just ask.

Not sure what you mean by "doesn't seem to be all there"... Try installing the xsane package, either by Mandrake Control Center > Software Management > Install or in a terminal: # urpmi -v xsane If that doesn't get you going, post your problem and/or error mesages back here. Not a good idea to install from tarballs except as a last choice. The same is true of any package management system, not just .rpms. Use MCC or urmpi and install from .rpms.

That's it exactly. The latest MDV Firefox rpm is actually 1.0.2, but with the security patches for 1.0.4 included, so for all practical purposes it's just as good as installing the latest version from the Firefox website. This was discussed in another thread here somewhere.

Ooo...sounds like a viral disease... Hard to say just what will happen now, but I have a positive feeling about this. Mandriva has to grow to survive against the Big Guys. And there is sure to be more consolidation in LinuxLand. And badly needed, too. Nothing wrong with having plentyof choices, but having soooo many distros just makes Linux seem more complicated than it is to n00bs. RedHat, Suse and some others are going off in the wrong direction - very heavily patched kernels, XML config files, etc., etc. It's not good, and while Mandriva is less guilty, they have a bit of the same kinda stuff going on, particularly with kernels. Hopefully, as they grow they will stay reasonably true to 'true' Linux, as they have so far, at least for the most part. Linux needs to standardize, settle on one package format, (I say .rpm wins in the end, and it won't even be close) standard file locations, etc. 'Til it does, n00bs will continue to be highly confused (as I was) and Linux will be too difficult for companies, even those who would like to get really serious about writing and selling commercial Linux software, to deal with. A conversation I had with a developer at Symantec made that clear. We can have all the distros we want, but they gotta standardize package installation. For sure, I'm gonna stay with 10.1 for quite a while, 'til all this combining of distros shakes out quite a bit.

Not sure if anyone here can help, but here's my situation: I have both Win4Lin9x (Win98) and Win4Lin Pro (Win2k) installed on my 10.1 box. W4L9x requires a W4L-patched kernel. W4LPro does not, it will install with any 2.6 kernel, but runs much better when used with kqemu acceleration, which requires loading a kqemu kernel module. Now, I've installed and used kqemu with Win4LinPro since the combination was first introduced with no problems at all. But I just upgraded the kernel on my Mandrake 10.1 box and can't get the kqemu module to install now. I know why, but I don't know the best way around the problem. Up to now, I've been using Buchan Milne's W4L-enabled kernel package for the stock 10.1 kernel I got from Contrib: kernel-win4lin-2.6.8.1.12mdk-3-11mdk.i586.rpm ...and had installed the matching kernel-source (required to build the kqemu module). I ran a handy script for building and loading the kqemu module that Leo Reiter at Win4Lin provided that makes it easy. That done, all was nice, I could run either version of W4L, or even both at once. The kqemu module even survived reboots. Then, for various reasons that don't matter here, I installed a new kernel package from Cooker: kernel-multimedia-2.6.11-9.mm.2mdk-1-1mdk.i586.rpm ...and the Win4Lin-patched kernel to run my Win4Lin5x installation: kernel-multimedia-win4lin-2.6.11-9.mm.2mdk-1-1mdk.i586.rpm ...and the matching kernel-source package so I could re-do the kqemu module: kernel-multimedia-source-2.6.11-9.mm.2mdk.i586.rpm Everything installed fine. Rebooted into the new kernel, everything seems ok. Win4Lin9x works, etc, etc. But now when I run Leo's kqemu install script, I get this result: # /opt/win4linpro/bin/build_kqemu.sh /tmp/kqemu-0.6.2-1.tar.gz Building KQEMU module in /root/tmp/.build_kqemu-11564 Please see the file /tmp/build-kqemu.log in case of error make -C "/lib/modules/2.6.11-9.mm.2mdk/build" SUBDIRS=`pwd` modules make[1]: Entering directory `/usr/src/linux-2.6.11-9.mm.2mdk' CC [M] /root/tmp/.build_kqemu-11564/kqemu/kmod.o cp /root/tmp/.build_kqemu-11564/kqemu/kqemu-mod-i386.o /root/tmp/.build_kqemu-11564/kqemu/kqemu-mod.o LD [M] /root/tmp/.build_kqemu-11564/kqemu/kqemu.o Building modules, stage 2. MODPOST Warning: could not find /root/tmp/.build_kqemu-11564/kqemu/.kqemu-mod.o.cmd for /root/tmp/.build_kqemu-11564/kqemu/kqemu-mod.o CC /root/tmp/.build_kqemu-11564/kqemu/kqemu.mod.o LD [M] /root/tmp/.build_kqemu-11564/kqemu/kqemu.ko make[1]: Leaving directory `/usr/src/linux-2.6.11-9.mm.2mdk' Installing KQEMU module in /lib/modules/2.6.11-9.mm.2mdk/misc Loading KQEMU module FATAL: Error inserting kqemu (/lib/modules/2.6.11-9.mm.2mdk/misc/kqemu.ko): Invalid module format As you can see, all goes well until the module is loaded. This 'invalid module format' thing had me baffled for a bit , but then Leo at Win4Lin clued me in that my problem with installing the kqemu module is apparently due to a gcc mismatch because I have gcc-3.4.1-4 on my 10.1 system, but the W4L-enabled Cooker kernel package I installed was compiled with gcc-4.0.0-3: $ cat /proc/version Linux version 2.6.11-9.mm.2mdk (svetljo@n2.mandrakesoft.com) (gcc version 4.0.0 (4.0.0-3mdk for Mandriva Linux release 2006.0)) #2 Sat May 28 03:05:09 CEST 2005 Now when I compile kqemu on my system, the gcc-version mismatch with the new kernel package stops installation of the kqemu module. So it seems I have 2 choices if I want to run the latest Mandriva multimedia kernels with W4L 9x and W4L Pro: !. Recompile the kernel on my system so the gcc versions match. 2. Install gcc-4.0.0-3 on my gcc-3.4.1-4 system and have 2 gcc versions installed, and use gcc-4.0.0-3 to compile kqemu. I've never done that, but I understand having 2 versions of gcc installed can be messy. Updating my distro version wouldn't help since the latest stable release, Mandriva LE2005, comes with gcc-3.4.3-7. I'd have to go to a Cooker install to get gcc-4.0.0-3. Ugh. I have no need/desire to update the entire distro anyway. Of course I know I can still run the 2.6.8. kernel, but I'd really like to keep the 2.6.11-multimedia version and I have no other problems running it. But Win4Lin Pro runs like crap in molasses without kqemu loaded. Any other ideas? If not, any help on how best to do either Option 1 or Option 2 would be appreciated. I'm still a raw n00b at kernel compiles.

There's a little misinformation running around in this thread. I've used Win4Lin for a long time and know a little bit about it, so allow me to try and clear it up a bit.. For home use there are 3 versions of Win4Lin: Win4Lin Home for Win95/98/ME $29.99 Win4Lin 9x for Win 95/98/ME $89.99 Win4Lin Pro for Win2k/XP $119.99 Win4lin Home and 9x are basically the same. You might say the Home version is a kinda Win4Lin Lite. It supports less memory than 9x and networking is more limited, but the price is right if it fits your needs. These are the versions that require a Win4Lin-patched kernel. A 2.4 or 2.6 kernel will work. I've used Win4Lin 9x for over 3 years, since version 3 (it's on v5 now) on Mandrake 8.0, literally thousands of hours of use, and it's simply terrific. It's been around for many years and all that development shows. VERY fast, (boots Win98SE in about 10 sec) totally stable (Win98 has never crashed under W4L, I ain't lyin'), and will install and run just about anything that does not require hardware DirectX. It almost makes Windoze9x seem like a real OS. Even does cool stuff like copy/paste between Win/Linux. An impressive piece of software. Win4Lin Pro requires no kernel mods whatsoever, unlike W4L Home/9x or VMware. It will install fine with your stock Mandrake/Mandriva kernel or any other kernel you might be using, no matter, but stay with a 2.6 version. Presently I'm using it with a Win4Lin-enabled 2.6.11-muiltimedia kernel from Cooker on Mandrake 10.1. Using a W4L-patched kernel, I can run either Win4Lin 9x or Pro, or even both simultaneously. I didn't get in on beta testing for W4L Pro, but I've been using it since the the day v1.0 was released, about 3 months ago (at v1.0.2 now). It's totally stable, but not nearly as fast or capable as Win4Lin 9x. It's usable, but only about as fast as VMware (i.e. slow) and software installation is still hit & miss. Like W4L 9x, does not yet support DirectX.. W4L Pro has a long ways to go to rival Win4Lin 9x for speed, but then nothing else can match W4L 9x either, and improvements have already been made with more in the works. I feel pretty good about the long-term future of W4L Pro development and I intend to keep using it. Hint: If you want to try W4L Pro, I highly recommend using it with kqemu acceleration - post here if you want to know how. A little more should be said about Win4Lin-patched kernels. This is really not difficult to deal with. Some distros, like Xandros and some others come with a W4L-enabled kernel already installed by default, so there's nothing to do. Just install W4L and Windows and go. For those running Mandriva, Fedora or other distros that need a patched kernel installed, there are 3 ways to do it: 1. You can use the Win4Lin GUI installer to install a Win4Lin-enable kernel. This is click-click easy, but installs a Win4Lin-patched generic kernel. These are tested and should not cause problems, but since many distros these days use heavily-patched kernels (including the likes of Suse, Mandriva, Fedora - Fedora kernels in particular are a mess of patches) this is not a perfect solution. 2. Download a kernel patch from the Win4Lin website and follow their instructions to patch your own. Fairly simple. Most Linux users ahould have no trouble. 3. For Mandriva, you can download a pre-patched kernel rpm and install it with urpmi. This is very simple to do and trouble-free. These kernels are exact replacements for the Mandrake/Mandriva kernels - no changes at all except for the added patch. Most of these kernels are kindly complied by Buchan Milne and available from Contrib or Cooker and a couple of other places. Some are supplied by the Mandriva Team, like the Cooker kernel I'm using right now. Either way, these kernels even add an entry to your bootloader for you. I'm sure someone is doing pre-compiled kernels for at least some other distros, too. Win4Lin is also well-known for terrific customer support, the best I've ever seen from any software company. Main website: http://www.win4lin.com/ The brand-new W4L Forum: http://www.win4lin.com/phpBB2/index.php?si...9eee35ff4dc5d27 W4L mailing list: win4lin-users@netraverse.com

You can get it, it's part of the lame-development package. Install the package: lame-devel-3.xx.x(whatever-your-version-is). You didn't say what version of Mandriva you're using, but taking a guess it's 10.1 and you're a Club member try here: http://rpms.mandrivaclub.com/rpms/mandriva...1mcnl.i586.html If not a Club member, maybe here: http://rpm.pbone.net/index.php3/stat/4/idp...f.i586.rpm.html

I listen to streams using xmms. They run constantly while I work. Using xmms is just about like the old Winamp, even uses Winamp skins. If you can use Winamp, you can use xmms. I have Firefox setup to use xmms as the default audio player and I can just click on the little 'speaker' (listen) icon on the Live365 site and open it in xmms, just like with Winamp or Winshaft Media Player in Windoze. You can also find streams other places besides Live365. I listen mostly to mp3 streams, 128k or better when possible. A few faves: Radio Paradise http://207.200.96.226:8048 (playing now...) Radio Wazee http://66.209.68.166:8020 Paradynamic Roadhouse - Drink or Die! http://205.188.234.38:8014 ABS Bluescast http://66.0.192.157:8000 ...and a bunch of others. In the xmms Playlist window, just click on the '+File' button, choose '+URL' and put the URL in and go... With xmms or Streamtuner you can make playlists of stations to load so you don't have to go to Live365 first at all, just click on the station name in your playlist. Or play mp3, wave, etc. files off your HD or audio CDs. Streamtuner is nice too, but xmms is simpler and does all I need. I use Streamripper if I want to save a stream to disk.

Aussie John: With all respect, I never said I *needed* a large separate /var because of so many logs - I said, basically, that I thought a separate /var was a good idea. Size is up to the user. My /var is fairly large mainly because I have 2 full Win4Lin installations - but never mind that... Fortunately, I haven't personally had a non-separate /var directory fill up my / partition, but I *have* seen it happen. Or possibly a very small problem causing mammoth file generation. Either way, once / is full you would have a non-bootable system giving kernel-panic errors. Keep in mind I'm not talking about what's absolutely necessary on a healthy system, but rather about good prevention practices and simplifying recovery should problems arise. Do a little Googling about Linux or Unix file system partitioning and you'll find some users making a very good case for even more partitions than I recommended. I would if I could remember where I read it, but I fried far too many brain cells in my younger days to remember where. Several places. Again, Google should help you out and you're as capable of using it as I am. ALL file systems fragment, some just fragment less and/or in less destructive ways. As they reach nearly full, fragmentation occurs at a faster rate. I'm certainly not a file system expert, and that goes way off-topic for this thread anyway (we're far enough off now) but some basic study of file systems will make it clear why this is (must be) so, and why FAT32 is worse in this regard than NTFS, which is worse than ext3, etc. etc.. But if you doubt it, you don't have to take my word for it - go ahead and fill a test partition up and see what happens... Oh, there has. One very old one for ext2 is defrag-0.70 and I'm sure there must be others. Nobody bothers with Linux/Unix defrag utilities 'cause there just ain't a real need under normal use. If the rare occurance happens that a defrag is needed, my understanding is most sys admins just copy files to a new partition rather than run a defrag utility. That's what I'd do. Awww....'cmon, gimme a break A.J....