adamw

erp, I did mean kernel 2.6 from 10.0, sorry. :). kernel 2.4 I don't play with anymore, it's odd it should break things so badly though. You should be able to fix it with a boot disk at least, I keep a copy of Move handy for emergencies. Boot Move, go to a terminal, mount your / partition in for instance /mnt/root , do 'chroot /mnt/root', then run lilo, see if that fixes it. none of the kernel changes between CE and OE seem remotely likely to affect this issue so I'd imagine you'd have the same problem with OE, unfortunately.

apart from the Neuros (I guess that's too big for you), there's the iRiver players - http://www.iriveramerica.com/ . They're a little pricey, though.

I use dcgui (the kde one) - ugly, but it works. There's another one called dcgui for GTK, which is much prettier, but doesn't actually seem to work. I just use the stock bittorrent for torrents, it's not fancy but I don't need it to be.

An alternative that's popular with Linux geeks is the DI Neuros - http://www.neurosaudio.com/ . It's impressively ugly and rather large, but it has excellent sound quality, comes in a range of capacities (and you can take it apart and put your own disk in it quite easily, so it can effectively be any capacity in which 2.5" disk drives are generally available) and a boatload of features. It can play MP3, WMA, Vorbis and .wav, and can record from a built-in or external mic to WAV or MP3 at a variety of bitrates. It can broadcast over FM and it has some basic DJ features. DI are a very clued-in company - their support is legendary, the forums for the device are very active and full of DI employees, and the player is as open as any MP3 player around - the firmware and the DI-written sync software have both been open sourced, and the hardware specs are freely available. There are several good third-party sync tools and a third-party firmware - see http://neurosdbm.sf.net/ and http://neuros-firmware.sf.net/ . And last but not least it's very cheap, $200 for a 20GB model. (That was half the price of an iPod, when I bought mine). If you can cope with the ugly factor and the size (it's not huge, but there's no room for anything else in your jean pockets), it's a fantastic player, and thanks to the heavy development work it only gets better with time.

The kde3.3 RPMs wouldn't go into the main tree of 10.1OE. That tree is already determined and frozen in stone (and on the mirrors) and it contains kde 3.2. Some may wind up in the 10.1CE tree, I suppose, or they may be stuck in some special directory somewhere. (There's nothing to *stop* a mirror maintainer grabbing the packages off the Club image and putting them in a dedicated directory right now, actually). But they wouldn't go in main. Weren't there four CDs for the public release of 10.0? I don't remember, I never download the things...

It's always that flippin' noapic :D. This will probably improve to some extent with 10.2; the kernel is being patched so apic won't be enabled if it's turned off in the BIOS. This should mean a lot more machines with broken APIC support will work without having to pass the noapic option explicitly. So yay for that. :)

It's possible it's just some kind of issue with the SATA driver, of course. You could try reverting to the *kernel* from 10.0, without reverting the entire distribution, and see if that works. Just find the 10.0 kernel RPM from a mirror and install it. Crossing versions like this isn't usually recommended but for a kernel, oddly, it's fairly safe, as kernels install in parallel and if there's a problem you can just reboot in the other. So grab the 10.0 kernel RPM, install it, reboot and pick that kernel; see if it's any faster.

Damn - there's really not much in there to help :(. The bunch of fd0 errors at the end is normal given you just tried several operations on the floppy drive; if they appeared even when you *don't* try and do anything to the floppy drive, I'd be worried. I can tell from that output you do have an SATA hard disk, so your hdparm output is normal. Only other thing I can think of is to run top and see if any process is taking an abnormal amount of resources...

hanez: the fd0 errors appear to indicate it's trying to do something to a floppy drive. Do you have one in your system? Does it work? Are there lots of this error or just three? The stuff about sda1 is normal. From the hdparm output I see you're using SATA. I think the results in this case are normal, though for an IDE disk, they'd be wrong. At least, I also have SATA and I have the same settings, and my disk performance is excellent. Hmm...this is looking tricky to diagnose :\

durvish: since 10.0 this isn't needed either, urpmi does it automatically. If there are updated versions of perl-URPM or urpmi packages, those (plus anything that depnds on them, like rpmdrake) are installed first, then the --auto-select operation is restarted.

Liquid: that's because the mirrors carry the official main and contrib trees, and the KDE in the official tree is 3.2. The status of the 3.3 on CD4 is basically that it's a 'bonus'; it's not part of the main tree and it's not supported. If a fourth CD is shipped with the free download version I expect the bonus KDE 3.3 packages will be in there. Don't update *anything* from 10.1 to Cooker unless you're going to update everything. Really. I mean it. Cooker moved to a non-backwards compatible version of perl last week so trying to selectively update 10.1 from Cooker (which is never supported or recommended anyway) is definitely not going to be pretty.

It shouldn't need to download everything again - urpmi used to, but it's much more sane now. It generally downloads small clumps of packages and installs them (up to around 10.0 it would download *everything* then install them all in one big lump, which was fun when updating from one version to another via urpmi, or when Cooker had just had a perl update, or something) and if for some reason it downloads a package and can't install it it keeps it in /var/cache/urpmi/rpms and reads it from there next time instead of attempting to download it again. Partial downloads are also saved. there's nothing wrong with adding jpackage and plf, you'll probably find them useful. jpackage contains open-source Java software (which isn't put into main or contrib as most of it needs the non-free JRE to work). plf contains open source software with some kind of legal problem; patent infringement, or DMCA / EUCD infringement, or whatever. Officially, it's an unofficial source. Unofficially, it's an official source. Got it? :)

hanez: sounds like some kind of disk access problem. Could you run dmesg while doing something disk intensive and see if there's any obvious errors? Also, check your hdparm settings: install the hdparm package, if you don't have it, and then do: hdparm /dev/hda (where /dev/hda is the disk you want to check). Make sure 32-bit mode transfers and DMA are turned on for all your drives.

aru: yep, that's a good alternative. I generally don't like to keep the large versions, but if you do, yours is a nice way. I included the 'ls' to indicate that the first part of this template can include a command, and by implication it can be *any* command. I wasn't trying to use the most efficient method of this particular operation, I was trying to illustrate a *general* template that you can use to do lots of things. I'm sorry I couldn't come up with an example that really *needed* to use a command, but my brain was tired. :)

Nope, installing from source can't possibly break anything fundamental to the system. As I explained, that's the advantage of building from source :). If you screw up, just make uninstall, or remove everything audacity put in /usr/local/bin and /usr/local/lib manually. It's not like WIndows, where when you install something it hides bits of itself all over the system; building from source you can see exactly what goes where and if you remove it all, it's *gone*.

can I have my offerings now? Only I'm a bit strapped for cash. Rents are high in Valhalla, you've no idea.

Well, since you obviously didn't know this, you obviously *did* need it. Now you know the truth and will no longer (unintentionally, of course) write misleading comments. All contributing to the general good of the universe.

All depends on what you run on them. Stick fluxbox on with all GTK 1.2 (or better fltk or something) apps and it'll fly. People don't like the ugly, though :). I'm surprised you can't get font rendering that you like, though. Are you using the Windows fonts? Windows fonts with no AA at 75dpi should look identical to Windows really...

cannonfodder: thanks to the joy of case sensitivity, that wouldn't actually work; the package is called ImageMagick, so a search for image won't pick it up. MDK is trying to convert all packagenames to all lower case, but it's not quite done yet.

You weren't exactly using it wrong, no - you probably just didn't know there are more comprehensive official urpmi sources available online. Trying to use urpmi on a single package you downloaded from somewhere is pointless. that's not what it's meant for. Go to http://easyurpmi.zarb.org/ , read and follow the instructions, and then urpmi will be a whole lot more useful for you. The whole 'dependency hell' thing is exactly the reason I suggest installing from source for anything that does not have a Mandrake package. Stuff you build from source will never replace something in the main system and it completely misses the RPM database so it can't screw that up. If you ensure everything built from source goes to /usr/local it is completely separated from the base Mandrake system; if the worst comes to the worst you simply rm -rf /usr/local and you're right back to a standard Mandrake setup. That's impossible when you start installing random RPMs. Additionally, since /usr/local is designated as a place for non-system files, the Mandrake tools will always ignore it; doing an upgrade install will simply leave it completely alone, so IT can't mess up the upgrade and the upgrade can't break IT. I follow my own rules exactly and I keep the source to everything I build from source in my /home/adamw/source tree. That way I know exactly what I have installed from source and if an update to the basesystem upgrades something that makes a source-built program not work I simply rebuild and reinstall it. Painless and safe. So follow my rules for your situation. You have a slightly old Audacity from the Mandrake package, so you followed rule 1. Great. Now - do you *really need* the new version or do you just figure 'it's a new version so I should have it'? This is bad thinking on Linux. Read the changelog and determine if there's something you actually need. If you really need the new version here is what you DO NOT DO: go to the audacity home page, download an RPM that looks like it might work (a Fedora one, or even one that says it's for Mandrake; those types of packages will generally *install* and *work* ok, but they pollute your rpm database and can screw up updates. They're best avoided.) Here is what you DO do: download the source tarball. Untar it into your home directory. READ THE DOCUMENTATION and follow its instructions. If it says it needs a certain thing to build - let's say it needs Bobbity - then what you will need is the Mandrake bobbity -devel package. Fire up rpmdrake and search for bobbity, or just use urpmq. You will see a package named something like: libbobbity0-devel install it. Always read documentation, it's there for a reason. Once you have installed all the -devel packages that the documentation indicates you need, do the build process. In most cases this is: ./configure make (become root) make install Very likely, the first few times you do this, you'll get errors caused by some other development packages not being installed. A lot of software doesn't bother to list the build dependencies it needs, or if it does list them, some are missed or skipped out. Don't panic. Look through the errors; try and find the *first* error message, all later ones are consequences of the first and can often be misleading (they often look much worse than the actual problem is). From the error message you can usually work out what -devel package is missing, go ahead and install it, and restart the build process. Once you've done this a few times you'll start building up an installed base of many common -devel packages and it won't happen anywhere like as often. 99% of Linux software is well-behaved and installs into /usr/local by default. If you're very unlucky you MAY find something that's been really, really badly written to install itself into /usr. I always keep an eye on the output of the 'make install' stage to check this. If you find such a piece of software, again, DON'T PANIC. Immediately run make uninstall and check the documentation for instructions on how to install into /usr/local instead. Usually, the --prefix= parameter for the configure script is what you need to use, e.g.: ./configure --prefix=/usr/local Some very safety-minded individuals do this every time they build anything. I'm too lazy :). /usr/local/bin is in the default path, so once something is installed there, you're mostly ready to run it right away. Anything built from source will not appear on the Mandrake menu; add it with menudrake or just make yourself a launcher or something. The only other thing - ld.so.conf specifies which directories the system looks in to load libraries. /usr/local/lib isn't listed there by default; source-built packages put their libraries here, so if you build a library from source, you need this line for the system to find it. ldconfig rebuilds the system's list of available libraries from the ld.so.conf file. This all looks horribly long and complicated. It honestly isn't. I worked it all out mostly for myself, through trial and error, within a month of starting to use Linux. It's a very simple to use and reliable process which will keep your installation functioning perfectly and will make sure you never have any problems using *correct* packages and Mandrake updates. Just resist the temptation to use random packages. Resist! :)

CNR is something Network Riser. It's not something you're ever likely to use. A few years ago several OEMs started using a custom socket to install network cards and modems in, for some reason - no idea why they couldn't just use a PCI slot. IIRC electrically it's just a backwards PCI slot or something. Anyway, not something you need to worry about, just a useless slot. (It's almost impossible to buy cards for it on the public market).

btw, have you checked if your speakers can do it for you? mine can. saves hassle. :)

hanez: press esc during boot to see the messages of what's actually happening, and let us know which stages it seems to hang up on. There's also the spiffy new boot analyser one of the Fedora geeks wrote that we've been playing with on the Cooker list. So far we've found several logjams in the boot process, most of which are down to udev. It's a bit technical to use though, you have to hack around the init scripts. jagibbs: I think Office loads bits of itself into memory on bootup, stealthily. so it's probably actually using more memory than it's telling you. Can't vouch for this, though. Anyway, you've got 1.5GB, who the hell cares? :) If you don't want 'blurry' fonts I guess you don't like anti-aliasing. Try this: create a file called .fonts.conf in your home directory. Put this into it: <match target="font" > <test compare="more" name="pixelsize" qual="any" > <double>6</double> </test> <test compare="less" name="pixelsize" qual="any" > <double>20</double> </test> <edit mode="assign" name="antialias" > <bool>false</bool> </edit> </match> </fontconfig> That will disable AA for fonts between 6 and 20pts in size. After you create the file, restart KDE.

it does work. It's slow, though, and not *everything* works. But if you just *have* to try out OS X, this is the way...

that will work just fine. however, installing mandrake is perfectly safe, it will never harm your windows setup. If you install with the Windows drives connected, Linux will install its own bootloader which will let you pick between Windows and Mandrake on boot.