Crashdamage

Forget using KDE or Gnome on that old box. You're trying to run XP-class desktop environments on Win95-class hardware. How would you expect XP to run on that machine, if at all? Go with a lightweight window manger - there are plenty to choose from - Fluxbox, Windowmaker IceWM, etc. etc. Then be sure to disable unecessary services and minimize the number of things that load at boot. Properly setup, you should be able to run Linux faster than Win98.

Did you run it once as root, go to a (safe) webpage and close it? Moved files? I didn't say anything about moving files. What did you move? Sounds ok, you gave it the right path. I don't remember much about KDE desktop icons, but if the icon even tries to start Firefox then it should be working and it or the link you created are not the problem. Try 2 things. First, open a terminal and run Firefox manually from there, i.e. simply: $ firefox That may give some error messages that will give away what the problem is. Post any errors here. Second, run the Firefox profile manager as so: $ firefox -profilemanager Create a new profile named 'Test' or whatever and see if Firefox runs right using that new profile. For more details on managing profiles go here: http://www.mozilla.org/support/firefox/profile

Sycthe wrote: I assume you mean how to make symlinks to run Firefox, Thunderbird, etc, and that you know how to 'su' to root since you installed the Firefox tarball in /usr/local/firefox. This can be done from various GUI file managers if run as root (or Midnight Commander is very good for this kind of stuff) but it's pretty easy from a terminal, so I'll show you that method. Open a terminal and navigate to the directory where you want to create the symlink: $ cd /usr/local/bin Now 'su' to become root and make the link with the 'ln' command (the '-s' option specifies that it be a symlink, not a 'hard' link): # ln -s /usr/local/firefox/firefox That should do it. Hereafter, to launch Firefox from a desktop icon, hotkey, whatever, aim it at /usr/local/bin/firefox. Since it has been created as root, the link will work for all users.

Since you put Firefox in a global directory (/usr/local, same as I use) it should be run once as root. Just open it as root, go to any page and close it. Also, Firefox should really be run from a symlink, not directly from the executable script. To do it, I put a symlink in /usr/local/bin pointing to /usr/local/firefox/firefox. I also run Thunderbird, OpenOffice swriter, scalc - any stuff like that installed from website packages instead of MDV rpms - from symlinks in /usr/local/bin. You may also need to start a new profile, but I'm still using the same one I started with Firefox 0.9 and 1.5.0.1 runs fine.

Duh! I'm incredibly dense sometimes...there I go again, thining in Windoze-apeak, where standard user permissions do allow updating.

Hmmm...'Check for Updates' is there all right, but in both 1.5 and 1.5.0.1 it's grayed out on mine. Wassup with that? AFAIK I didn't think browser auto-updates had been enabled for Linux versions yet. It will update extensions but not the browser itself. Do you have some cool secret beta version not available to the general public or what?

Java 1.4.2 would work but is an old version. Go to the Sun website and download and install Java 1.5.0 from there. This page has links for downloading the self-extracting rpm package and instructions on how to install it: http://www.java.com/en/download/manual.jsp Be sure to uninstall the 1.4.2 package first. If you get stuck again post back here with any error messages.

I agree with ianw1974 that it's best, regardless of your distro, to install the standard Sun Java package. Links for downloading and installation instructions available here: http://www.java.com/en/download/manual.jsp I also agree that it's also best to install Firefox from the standard Mozilla.org package. It's very easy to do. You'll avoid any dependency problems by leaving the Mandriva Firefox rpm installed. By using the standard Mozilla Firefox package it's always easy to update to the latest release instead of having to wait for a distro-specific .rpm or .deb package. I just unpack the Firefox tarball into /usr/local, which makes a /usr/local/firefox directory with everything Firefox needs in it, create a symlink in /usr/local/bin to /usr/local/firefox/firefox, and run it from that link (it should be run from a symlink rather than the executable directly). Be sure to run Firefox one time as root (just open it and close) before running it as a normal user. Thereafter, to update Firefox, I simply rename the /usr/local/firefox folder to /usr/local/firefox.old, unpack the new version as before, copy over stuff in usr/local/firefox.old/plugins to usr/local/firefox/plugins and I'm good to go with the latest version. I just updated to Firefox 1.5.0.1 this way this morning. You can delete /usr/local/firefox.old, but I like to keep it around for a while 'til I'm sure the new version doesn't have issues. I install Java, Firefox, Thunderbird, Open Office and a few other apps from packages downloaded from the websites to make upgrading quick, easy and no waiting for distro packages. And urpmi will indeed handle dependencies for you. It's just like using apt-get, really. The GUI frontend for urpmi in Mandriva Control Center is nice, but like apt-get it's very easy and more powerful to use urpmi from the command line than from the GUI.

neddie wrote: SOS mentions 2005LE rpms - he mentions that he no longer hosts them on his site. He (Hawkwind) and Thac are more concerned with the newest stuff, usually for the newest OS version. We're not talkin' Debian Stable here... You're right, you shouldn't compare Linux to a pay-to-play OS. Once an application's out, yeah, you can BUY it, but that doesn't always mean it will work. And it sometimes will break other things already installed. I've been toasted in DLL hell too many times. That's no solution. Debian has the same problems any other distro does. Apt-get works basically the same way urpmi does and is prone to the same type of problems. To update Debian to a newer version or an application to a version available only in say, unstable (aka Cooker) you have to setup the Debian unstable sources to get the app and any dependencies. Basically, it's just as I described doing with urpmi, with the same risks. Well, yeah. It's a big job, and that's why it's hard to keep doing packages of new apps for old OS versions. But I've managed to install almost anything with a bit of effort. I've only resorted to using Checkinstall a few times, and '--force' only once - and the installations instructions stated to do so. But I admit, not using KDE or KDE apps or much GUI stuff in general really simplifies keeping my system current. daniewicz said: I'm with you, to a point. I'll use 10.1 until I can't use what I need anymore or I get new hardware and need to reload the OS. I don't want or need to update any more than that. Consider Windows and how often M$ offers a new OS. Anyone here think we'll ever see M$ go to a 6 month release cycle? 1 year? Even at their pace, it's stil best to skip some releases (ME, XP, Vista). At my business all the desktops run Win2kPro SP4 and will 'til hell freezes over if possible, 'cause that's the closest thing to a real OS M$ has made or will offer for the forseeable future. If it ain't broke don't fix it. But given the speed of development in Linux my feeling is the yearly cycle between new releases is about right. Those who want 3 or 6 month releases can get the Club versions. Those like us can skip a few releases. Something for everyone!

Recent versions of Inscape and Digikam are available: Inkscape 0.42 for 10.2 (2005LE): http://rpms.mandrivaclub.com/rpms/mandriva...02mdk.i586.html Inkscape 0.43 for 2006 (Cooker package, use at your own risk, try with '--test'' first): http://rpms.mandrivaclub.com/rpms/mandriva...-2mdk.i586.html Digikam 0.8.0 for 2006 (try with '--test' first): http://rpms.mandrivaclub.com/rpms/mandriva...60mdk.i586.html Digikam 0.8.1 (Cooker - careful!): http://rpms.mandrivaclub.com/rpms/mandriva...-1mdk.i586.html There's more packages available elsewhere, I'm sure. If you're not a Club member, check Seer of Souls or Thac's rpms. I realize the packages above aren't 'official 10.2' rpms, but maybe you can still urpmi these packages in. Just download the rpms and try it with 'urpmi -v --test'. Urpmi will still try to satisfy dependencies using the sources you have set up. If it can't, (very likely, in this particular case) you may need to setup 2006 and/or Cooker depositories temporarily if 'urpmi -v --test' replies that you need a lot of stuff from those depositories, (it probably will) otherwise it's simpler to just get what you need manually. But be sure to disable them again once you do the installs of Digikam and Inkscape. Using 'non-native' depositories carries a risk of course, but the '--test' switch **should** keep you out of trouble. It has for me so far. At least with Linux you CAN do a test install - in Windoze, you just have to install new software and see what else it breaks when it overwrites those older DLLs with new versions. I really don't understand your complaint though. Software installation in Linux is so simple. Almost anything you need is just 'urpmi <packagename>' or 'apt-get <ackagename>' away. Even cheating a little installing packages from other versions, etc. is usually pretty easy. It happens you picked a particularly tough upgrade with Digikam. And anyway, do you really expect Mandriva or anyone else to keep re-compiling the latest stuff for your earlier system? You saw for yourself that it sometimes is a pretty tall order, with lots of other stuff needing upgrades to make it work (especially anything KDE-dependent like Digikam). Mandriva (or any distro) has got their hands full getting thousand of apps to play nice together for the next release. That's OK with me - I can take care of the rest myself. Like I said before, I upgrade stuff as I need to. That's why my sig says 'Modified Mandriva 10.1' and will for a long time. I only reinstall the OS about every 3 years. The only way to get 'one-stop shopping' is to go to CompUSA and load up your credit card with Windoze software - and hope for the best. Then pay again when the new versions of what you just bought are released. And again. And again.

neddie wrote: Possibly, but probably not. No big deal, you can still update stuff, as I already discribed. You can load 2006 be able to urpmi the latest and greatest, but no matter whether you use Suse, Mandriva - whatever - some stuff is always gonna be an old version as soon as a distro's released. And sometimes the latest isn't the greatest anyway. You won't know 'til you try it. Might go smooth. Don't forget about Checkinstall. Can't help you there. I don't even have Kate or KDE installed.

Hey, the OO.org rpm is called: desktop-integration/openoffice.org-mandriva-menus-2.0.0-3.noarch.rpm So, I figured it did what it said, 'desktop-integration'. I didn't catch the little 'mandriva-menus' disclaimer at the end. My bad. But I shouldn't have opened my mouth I guess, since I've never used it. Don't need desktop-integration.

In the standard Open Office package downloadable from OO.org, there's a rpm included to install to get desktop integration for Mandriva and other distros. Just install that rpm after unpacking the tarball and installing OO.org. I update my system with later verisons of software all the time. Later rpms will often work on earlier distro versions, but some care is needed. My system now is based on 10.1, but it's really a mismash of 10.1, 2005LE, 2006, a few generic rpms or from other distros like Fedora and software I've downloaded directly from project websites, such as Firefox 1.5, Thunderbird 1.5, OO.org 2.0, Bastille, Portsentry, etc. etc. But I avoid Cooker stuff when possible. What I do to keep from trashing things is when installing something not compiled specifically for 10.1 is to do a test install first: # urpmi -v --test <packagename> Most times if anything will break or installation is just not possible that will tell you. The '-v' option will give you more info to help resolve any problems. As for installing from source, it's far better to learn to use Checkinstall (included with your CDs) than install directly from source. Checkinstall is a very handy little utility that will easily make a reusable rpm from a tarball and install it. That way, your rpm database stays correct, you now have a rpm you can reinstall if need be, and uninstalling the software is far easier. Basically, Checkinstall simply replaces the usual commands: # ./configure # make # make install ...with: # ./configure # make # checkinstall Keep in mind that does not make a rpm suitable for distribution to others, it's a very simple rpm. But it's fine for your own use.

Install and configure Portsentry: http://sourceforge.net/projects/sentrytools/ Nice tool for blocking port scans.

My 5 year-old Maxtor 20G: # hdparm -iv /dev/hda /dev/hda: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 39703/16/63, sectors = 40020624, start = 0 Model=Maxtor 52049H4, FwRev=DAC10SC0, SerialNo=K40QS1HC Config={ Fixed } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=40020624 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 AdvancedPM=yes: disabled (255) WriteCache=enabled Drive conforms to: ATA/ATAPI-6 T13 1410D revision 0: * signifies the current active mode [root@tim tim]# hdparm -Tt /dev/hda /dev/hda: Timing buffer-cache reads: 1468 MB in 2.00 seconds = 732.28 MB/sec Timing buffered disk reads: 86 MB in 3.03 seconds = 28.42 MB/sec Note that buffer-cache read is pretty fair for an old drive, but buffered disk read is not so hot, only a little better than hane's notebook drive. This is no surprise with a HD this old, and no surprise either for a notebook HD, partially because of their slow 5400rpm speed. Even so, this Linux box is fairly quick. My nearly identical office workstation, running Win2kPro with the usual Windoze speed tips applied, has nothing on this Linux box for speed. That's even though the Win box has a newer, faster HD than my home Linux box, the main difference between the two. Either box 'feels' good. IOW, I'm not convinced hane's perceived slowness is HD-related. Running in umda2 seems outa whack, but his drive appears not to have support for umda5. Nor have I seen convincing evidence to make me think Linux is 'slower' then Win. With any OS, some users just seem to have speed problems. But it seems to me regardless of OS (Win viruli, etc. aside) to usually be something in the configuration. The question is what, and I can't guess beyond what's already been covered here. So, all I can offer hanes is the usual - keep pokin' around, disable all you can, try another Window manager, etc. Maybe try running Memtest86.

Works fine for me with Links or Firefox. linux_learner, you may have a problem at your end. DNS resolving, maybe?

Gowator said: Links2 does. Install it, type 'links -g' and you will see the fastest graphical browser on the planet, I believe. I usually use it in text mode though.

...or Links2 - which I use most of the time (like now)? As for apt vs urpmi - I really don't have a preference, one doesn't seem any better than the other, as far as the system itself goes anyway. Either one just does what it's told by the packagers. I got into one heckuva mess with apt-get futzin' up stuff a while back, much worse than installing an unwanted Firefox package. On the other hand, I installed htop on this box the other day with urpmi, supposedly successfully, but it has a problem. OK, I admit to cheating, not using a 10.1 package for htop (there is none), but still... Stuff happens. Not gonna win 'em all with apt or urpmi.

one2one wrote: I understand your frustration. We all had to learn to fly. Coverup gave good instructions that do work, but to a n00b it might as well be Greek. Instead of trying to explain the commands coverup gave and what your misunderstandings are, I suggest you learn the basics of using Midnight Commander for file copy/move, changing permissions, creating symlinks, etc, etc. until you get more familiar with the Linux command line. It should already be installed, just type 'mc' in a terminal and play around with it a bit, it's pretty simple to understand. Of course most GUI file managers like Konqueror or XFE will do such stuff with a Windoze Explorer-style GUI, but MC is more versatile and has the advantage that since it's a text-based GUI, it will run even if you hose your system and can't get X to run. So once you learn basic MC use you always have a familiar interface for file manipulation to fall back on in good times or bad. Also does cool stuff like let you look into rpms or tarballs and much more. A great tool for n00bs or power users. That said, remember to do a couple of things. First, after moving /firefox into /usr/local, make a symlink in /usr/local/bin or /usr/bin to the Firefox executable. This is done because Firefox should be started by calling the symlink, not the executable itself directly. It's easy to do that with MC or you can do it easily from a terminal with these commands (as root): # cd /usr/bin (or /usr/local/bin) That puts you in the directory you want to create the symlink in. Now create the link (edit this line to suit if your directories are different): #ln -s /usr/local/firefox/firefox Now you should be able to run Firefox by calling the symlink by either typing 'firefox' in a terminal or creating a icon aimed at it. Second, run Firefox from a terminal **as root** once before any users try it, so as to create the base files it needs. What I do is since Mandriva rpms install stuff in /usr/lib and executables in /usr/bin, I install Firefox, Thunderbird, etc. packages that I get directly from their site into /usr/local/bin. That keeps them separated from the Mandriva-installed stuff, avoids any conflicts and it's, well just easy that way to install/upgrade/uninstall. Then I put the symlinks I create to run those apps in /usr/local/bin for consistency. Easy to remeber that way. Hope this helps...

Ironfighter wrote: You can just go through all the security stuff in MCC, there's quite a bit there. But instead, for a very long time I've used Bastille to configure system security. Walks you through a kind of 'check list' of security stuff that might be much like what you're asking for. I also use it to setup firewalling instead of Guarddog, Shorewall, etc. Makes NAT, IP masq, etc. easy. Bastille's a terrific tool, oddly not included in Mandriva but available here: http://www.bastille-linux.org/ You might also want to check into Portsentry. Formerly by Pisonic, now bought out by Cisco. Also oddly not included with Mandriva, but still open-source and available here, along with other parts of the sentrytools package: http://sourceforge.net/projects/sentrytools/ I install Bastille and Portsentry on every Linux installation I do. Should be in the distro IMHO - they used to be. Be aware that I've installed them on most versions of Mandrake/Mandriva from 8.0 to 10.2, but haven't tried yet on 2006.

Gowator said: AFAIK a functional Gecko rendering engine is still not available as a stand-alone application. Debian (and other distros) have some Gecko-associated development packages and stuff like 'gecko-sdk' and 'gecko-sharp', but they don't eliminate the need for Firefox or other Gecko-based product to be installed. I didn't Google around or anything before posting though, so I suppose that situation may have changed since last I heard. If so, then I'm an idiot... Solarian wrote: Good question for the Avidemux developers. I've never used it so I have no idea. HTML help pages maybe? Some option like conversion > or < HTML? Seems there's a lot of stuff that depends on Gecko for odd reasons.

It's not a Mandriva thing, it's not a laziness thing. Basically, there are several apps that depend on the Gecko rendering engine used in Mozilla or Firefox. If you install any of those apps needing Gecko, Firefox is installed as a dependency-resolver. This is out of the control of Mandriva or any other distro. It's only under the control of those who write the apps dependent on Gecko, which are then passed along by (insert your distro here) for our use, and Mozilla.org. The only ways this can be solved is to either: A. Don't write apps dependent on Gecko. B. Don't include apps dependent on Gecko in the distro (which would tick some people off - why isn't xxx.app in the repositories??) ...or: C. Get Mozilla.org to get it together and separate Gecko itself from Firefox so the whole browser dosen't have to be installed to satisfy dependencies. I get around the whole problem by not needing anything dependent on Gecko and installing Firefox from the Mozilla.org package instead of a Mandriva rpm. So, not **everything** is Mandriva's fault...now Kat on the other hand...uugggghhhh!

Click on the 'Easy-Urpmi' link on the top right of any page in this forum. Follow the directions carefully, and be sure to add the sources for 2005LE main, contrib, plf-free, plf-nonfree and updates. When you have your online sources properly setup try installing XMAME again. It should work by simply opening a terminal, 'su' to become root, and typing: # urpmi -v XMAME With that command, urpmi will automagically download the latest available version of XMAME for 2005LE, grab any other packages like Mesa necessary to satify dependencies and install everything in the proper order. Post back here if you have any questions or problems. Be sure to include any error messages.

Sure you can. Most distros, including Mandriva should have no problem. Just be careful when you go through the partioning steps.

Per said: I thought so too and it would regenerate as needed, but after a little more checking into this I certaily wouldn't delete anything in /sys for space. Sorry to steer you wrong, polemicz. daneiwicz said: On my system /sys/devices/pci0000:00/0000:00:00.0/resource0 is 262144K. Apparently, that's normal. You couldn't open it with Kwrite 'cause it's not a normal file, rather some code repeated over and over. Open it in Midnight Commander, vi, vim, etc. Well, you may not have any USB *devices* but unless you have no USB inputs you of course still have USB ports and controllers for those ports. I don't see how it could be related to this problem anyway. I'll shut up now and let someone who know much more about all this help you out.