adamw

RPM Pointers For Mandrake Happiness: use RPMs from the three main Mandrake sources - main, contrib and plf - WHENEVER POSSIBLE. Your first attempt to install any program should be: urpmi <programname> once you've set up correct mirrors for main, contrib and plf using the guide at http://easyurpmi.zarb.org/ If these sources do not contain a piece of software you need, or you REALLY REALLY REALLY REALLY NEED a newer version than they contain, build it from source following the instructions provided. ALWAYS install stuff built from source in /usr/local; never in /usr. Do not build a newer version from source unless you actually *need* something in that newer version. Never, ever, for any reason, download a random RPM package from some other distro, or some other version of Mandrake, and try to install it. Simple rules that will make things much easier :). You might want to try uninstalling that source-built version of lame and installing the one from plf instead. Or if you want to keep yours, adding this line: /usr/local/lib to /etc/ld.so.conf and then running 'ldconfig' might help.

you need to be root to run urpmi. To get ImageMagick, do 'urpmi ImageMagick' , as root. The graphical software installer, on the Mandrake menu somewhere, can do everything urpmi does - go ahead and use that if it feels more comfortable. Just search for ImageMagick, then install it - or digikam-plugins, or whatever package you want. You can fix the bootloader, no reinstall needed. You just need to configure it to point at your Ubuntu as well as MDK and Windows. I'm not great on bootloaders so I'll let someone else help you here, just posting early to make sure you don't go reinstalling yet :)

Hey, don't be embarrassed, you're not alone :). My current main system is an HTPC (Home Theatre PC) which also serves as an impromptu desktop, a bit of a jack of all trades. When I first built it I connected it direct to my TV (didn't have the money for a monitor). Couple of weeks ago I got around to buying a monitor. The nvidia drivers have lots of nice support for multiple displays, so I read through all the documentation, came up with an xorg.conf that should work fine, shut the system down, plugged the new monitor in and rebooted. I got weirdness. I footled. I read every bit of documentation I could find, every example file. About two minutes into this messing I had a situation where the monitor had perfect output but nothing was appearing on the TV, where the second half of the desktop should be. I tweaked, I twiddled, I prodded, I pulled, I redid everything from scratch. Nothing. It was at this point that I looked behind the machine and noticed I'd knocked out the s-video connector when plugging in the monitor. D'oh. I plugged it back in and rebooted. Bang, everything came up. I'd had the right configuration for hours...

dpi isn't really a 'set it to what you like' setting, it's a setting with a purpose and a definite way to get a correct value. Measure your physical screen horizontally in inches. Divide the result into your horizontal resolution (1024, for instance, if you use 1024x768 resolution). Voila, that's your correct dpi setting. Font sizes aren't really relative; each one has a 'correct' physical size. 12 point text should always be a certain real physical size; setting the correct dpi for your screen ensures that 12 point text on your monitor will be the 'correct' physical size. This is mostly important when it comes to printing, because printers always use the 'correct' size for fonts. If your screen dpi setting is correct, then when you print something out, all the text will be the exact same size on the page as it was on the screen. This is good. :)

There's also #mandrake on freenode (you can often find me hanging around there, if you want to talk to me for some bizarre reason :>)

mp3 decoding and mp3 encoding, in both hardware and software, are under patent by the Fraunhofer Institute, which enforces a licensing scheme for all four operations. Solely in the case of *decoding* mp3 in *software*, the institute has undertaken to turn a 'blind eye' to software which provides the function _free_ without paying them a license fee. This undertaking is not formal and is not written down anywhere; it's based entirely on trust. Most Linux distributions have decided to trust this undertaking and thus they provide MP3 decoding out of the box - Mandrake falls in this category. Red Hat / Fedora take a more conservative stance so they don't include it. Fraunhofer makes no such undertaking with regards to *encoding* software, and have undertaken to pursue anyone providing an mp3 encoder without paying a license fee. This is why you can only get the source code for lame from its official site, not binaries (source code is not subject to patent law, only compiled binaries are - this has in fact just struck me as an interesting point with regards to Linux, as it means you could never get the Linux kernel *proper* under any kind of patent infringement action, only distributors of compiled binary kernels...). As arTee says, you can get lame for Mandrake from PLF. If you live anywhere where software patents apply (e.g., the U.S.A.), it's technically illegal to use it without paying Fraunhofer a license fee. If you live anywhere else (e.g. Canada, Europe - yay Poland!), you're in the clear, they can't touch you. I don't believe any other major distro ships with mp3 encoding out of the box yet. Though it would make sense for Linspire to buy a license and trumpet this as a feature; they've been doing it a lot lately (see Windows Media playback).

the flat-out easiest way to simply resize an image isn't gimp. It's convert, which is part of ImageMagick. To resize blah.jpg to 800x600, do this: convert -scale 800x600 blah.jpg blah.jpg

That won't make a difference; the harddisks file is just a way of calling hdparm on boot. One thing to consider - maybe Linux can use DMA on this drive *now*, but was it able to use DMA on this drive two and half years ago, when the kernel used in MDK 8.2 was released?

Actually, it would be better to add an extra line underneath: input/js*:root:root:0644 Technical info: Linux's devices system involves a directory called /dev which contains a file for each device attached to the system. Originally, this was 'static' - the files were created and deleted and changed 'manually' with mknod. You change the devices, you (or some hardware detection program included with your distribution) has to create new /dev entries. Most distros shipped with a laundry load of common ones to make sure most hardware works, which was ugly as hell. The old alternative to this was devfs. The newest one, which Mandrake now uses by default, is called udev. udev is spiffy. It runs outside the kernel space and watches the kernel for hardware change notifications. udev creates a /dev tree with only the devices that actually make sense for the stuff in your system; when hardware is added or removed, udev sees this and adds or removes the appropriate /dev entries. Obviously this whole thing is a bit of a black art, what with the vagaries of PC hardware configuration. The file in question here is one udev reads to let you tell it what permissions to use for some devices, if the ones it picks aren't good. The particular LINE in question: input/*:root:root:0600 tells it that, whenever it creates a device in the /dev/input directory (that's the input/* part), it should be owned by user root and group root (the root:root part), with the permissions 0600 - that is, readable and writeable by the owner (root - this is the 6), with no permissions for either group or anyone else (the second number shows the permissions for the group, the third number the permissions for everyone else). The rationale for this is above; if anyone but root can read the file, that potentially allows one user on a system to monitor the keystrokes of another, as /dev/input contains the keyboard device file. For your average home system this is no big deal, so the suggested fix is fine. It's just more elegant to use really good security, though, so if you add the line I suggested, the keyboard (and mouse, and anything else that isn't a joystick) devices will still get 0600 permissions, while joysticks *alone* will get 0644 permissions. This means root - the owner - can read and write, and the group (root) and everyone else can read but not write (this is what 4 means). So every user on the system can use the joystick, which is the point of the exercise. An even more elegant option is this: input/js*:root:games:0640 This would create all joystick devices owned by user root and group games, with root having full access, anyone in the 'games' group being able to read, and no-one else having any access. Then you can add any user who should be allowed to use the joystick to the games group, and leave any user who shouldn't be allowed to out of it. I just picked the name 'games' on the spot, as I'm not at a Mandrake box - there's a pre-existing group on Mandrake systems which is perfect, but I can't remember the name of it. This is the setup I use on my Mandrake box. For a single-user desktop this is all overkill. But it's really useful to know, and it's a good way to understand the point of the permissions system and how it can be used on big systems with *lots* of users. Plus now you know what udev does!

btw, anything you can modify through this program you can modify in other ways too; either by editing xorg.conf or, in the case of the varying GL settings, passing environment variables.

It has nothing at all to do with your fonts. As long as your display is working, that setting doesn't really matter; the nvidia driver allows you to tell it manually what displays you have connected to it in case you have a complex setup that it doesn't detect properly. It probably detects your LCD as a CRT because it's connected by a standard monitor cable. As far as the nvidia driver is concerned, anything connected by the standard VGA output is a CRT, anything connected by a TV-out connector (composite or s-video) is a TV, and anything connected by a DVI-out connector is an LCD. If you have an LCD that connects by the normal analogue VGA connector, nvidia reckons it's a CRT. As I mentioned this really makes no difference to the display itself, it's just nvidia's naming convention. (If you ever start messing with multiple displays, you need to know this stuff, as when editing the config file you use these names - LCD, CRT, TV - to identify the display whose settings you're changing. If you have a single output, they're completely irrelevant). That was rambling and badly organised, but I hope you got the gist :). Basically - it doesn't matter and it's not causing your font problem.

Yes. Cooler compatibility goes by CPU socket. The XP 2200+ is a Socket A CPU so any Socket A cooler is good. The '3200+ and above' is just a bit of marketing foam to make it clear the cooler can (allegedly) handle high end processors. That cooler looks rather heavy, though; if you're going to be moving the system around a lot you might want to find a lighter one. If it's gonna sit still, no big deal.

For those (like me) who have zero coding / scripting ability, the single most useful little 'scripting'-type thing you can learn is this generic command: for i in `ls -1`; do something $i; done You can put any command in between the ` `, and you can use any command after "do". So this lets you specify a set of 'things' to do something to, and then do anything to that set of 'things'. Here's a simple example I use quite often: for i in `ls -1 *.jpg`; do convert -scale 800x600 $i $i; done This scales every jpg in a given directory down to 800x600. Fast, no mess. (BTW, the -1 option for ls makes each result print out on a single line, instead of printing as many columns as will fit on the screen. It's necessary to make the for loop process the name correctly.) There's all sorts of things you can do with this simple template, just add ingenuity :)

If I understand the end of the first post correctly, does this mean the ATI driver is hardcoded to read something from /etc/X11/XF86Config ? If so, a more elegant solution under 10.0 up would be: # cd /etc/X11 # ln -s xorg.conf XF86Config xorg.conf is the true config file for x.org. XF86Config-4, since we switched to xorg, is just a symlink to xorg.conf. Creating a symlink is more elegant because now the file the ATI driver reads will always be in sync with the actual file X uses, rather than being a copy of it made at one specific point in time.

fearby: X.Org's configuration file is perfectly compatible with XFree's, so it ought to work. MDK sets XFConfig-4 (erp, or whatever it's called, I forgot already) to be a symlink to xorg.conf , so even if it tries to modify the wrong config file, it should be OK.

Just noticed the list of languages doesn't include the native word for Japanese; that would be 'nihongo'. Though any Japanese person who could read it in the Roman alphabet can probably understand the word 'Japanese' too :)

If you're going to use one system purely as a server, you can probably keep it and get it to a state sufficiently unobtrusive that your wife won't know it exists. One of the great things about Linux is reliability - if you set it up as a simple webserver and make sure it doesn't get hit by any power problems, you can just leave it sitting there till kingdom come (or the hardware fails) and it will work fine. So keep the third box, get it all working, then unplug and dispose of (or put away) all the peripherals - keyboard, monitor, whatever else. you don't need them. All you need is the box and its network connection. If you need to tweak anything on it, just ssh into it from either of your other machines. This is called headless operation, and it's a common state for servers - if a machine is a server it doesn't need to be a classic desktop PC sitting on a desk with a monitor and a keyboard, you can stick it in a cupboard and forget about it.

It's borked because Cooker has been updated to a new, non-ABI-compatible version of Perl. This is why we tell people not to use Cooker repositories in the first place...sigh. It looks like you still didn't try just plain rpm yet. Try uninstall the urpmi and perl-URPM packages with rpm -e --nodeps , then reinstall 10.1 version packages. I think those are the only two that should need to be changed, but I'll check tonight when I'm on my mdk box. If that doesn't work, frankly, the two fastest and most pain-free solutions are 1: update everything to Cooker and use it (current Cooker has lots of nice new stuff and isn't very broken!) or 2: reinstall. There *are* ways to fix this, but they're hideously ugly and time-consuming and just doing a reinstall while preserving your home partition (you DO have a separate home partition, right?) will be much easier.

What are you trying to install via the package manager? The only thing you should need to install is the package called 'gnome2'. That pulls in everything necessary. Then you should have an option to start GNOME instead of KDE on the normal login screen. If you have autologin set, you'll have to turn it off in MCC, then login to GNOME and turn it back on again.

another thing to add to this thread is epsxe, a great free playstation emulator (unfortunately not open source) which can be found at http://www.epsxe.com/ . Go to http://www.ngemu.com/ to download Linux plugins for it - I'd recommend Pete's OpenGL gfx and OSS audio plugins, and the padjoy 0.8 gamepad plugin. I'm having an absolute blast playing through Chrono Cross on my HTPC at gorgeous 800x600 resolution - looks way better than the PSX ever made it! And it even runs acceptably in low resolution on my PII/400 laptop. nice stuff.

Hmm, well, I didn't see an official freeze for 10.1 OE announcement on the mailing list, so it may not have been finished off yet. Cooker sometimes does go pretty quiet on the weekends. We'll find out soon, anyway...

well, that's not a change to k3b, that's a change to cdrecord. Most distros patch cdrecord now (you'll see a very similar message on MDK's cdrecord in any version from I think 9.2 onwards) in order to have DVD support. This functionality isn't in stock cdrecord, hence the message. I guess SuSE must've done something to k3b if k3bsetup doesn't exist, though...or maybe it's just in a separate package under SuSE? Maybe you could look in the SuSE package management tool for an actual k3bsetup package or something?

yep - it's a good idea to exercise caution when doing this. remember these tools can only understand the rpm database, so if you installed something because you needed it for something you installed *not as an rpm* - say something you built from source or installed from a non-rpm installer - then remember not to uninstall it just because no rpm package requires it :)

there's actually two ways to put an icon down there; there's the Panel Notification Area, which is unified across GNOME and KDE, and the concept of a panel applet. The concept of the notification area is that it's an assigned space for applications to *temporarily* pop up icons when they want to notify you of something. Supposedly, if something wants to live on the panel permanently, it should be written as a panel applet, which is an actual separate "item" on the panel. (In practice, the Panel Notification Area application *itself* is a panel applet. I hope I'm not losing people here. :>) the problem with this is that the Notification Area works under KDE and GNOME, while you can't currently write a genuine panel applet which will actually work as a panel applet in both (or you can, but you need to write two entirely different chunks of code, you can't use the same code for both DEs). So what several apps do is cheerfully abuse the concept of the Notification Area and use it to function as panel applets - i.e., they stick an icon in there *all the time*. That's not what the notification area is meant to be for, but since it works on both KDE and GNOME (and other DE's - it's a freedesktop.org standard), it's subject to such usage. This is how gaim works (and also the Mandrake alert_applet and net_applet). Hopefully, freedesktop will get around to standardising panel applets, and the notification area can go back to being used for what it's supposed to be used for. thus endeth the lesson...:)

can you have a look at the output mplayer gives when you try to play such a file and post anything that looks relevant here? mplayer's output is very helpful in looking at this kind of problem.