blackpage

gidday cewillis My first guess would be that some options in your /etc/fstab have gone amiss. Open the above file and check for some line like ... Code: /dev/dvd /mnt/dvd iso9660 noauto,user,ro 0 0 In brief: you can control access to a filesystem that gets statically mounted via the /etc/fstab file with a series of options. Commonly used are ... user (filesystem can be mounted by non-root users) uid=xxx (users-id (number) can mount the fs.) gid=xxx (group-id (number) that can can mount the fs.) Also an all-time favorite is the so called umask-option. "umask" appears in an fstab-line as this ... Code: /dev/dvd /mnt/dvd iso9660 noauto,umask=xxx,ro 0 0 ... and as you can see, it takes a numeric value as parameter (the "xxx" part). This number has to be specified in octal format (permittable digits range from "0" to "7"). The tricky bit is that umask is in fact the inverse of what you usually would use to give permissions with the "chmod" command. So where a ... Code: chmod 777 anyfile" ... would give all permissions to anybody for the file "anyfile" the umask section that does the same would look like that in /etc/fstab ... Code: /dev/dvd /mnt/dvd iso9660 noauto,umask=000,ro 0 0 But I won't go too much into detail. If you're keen to find out about all these fancy fstab- and mount-options just type "man mount" or "man fstab" and you will get more than you'd ever hoped for In the meantime just give it a go with a mount-lineup for the DVD in your /etc/fstab that looks like this ... /dev/dvd /mnt/dvd iso9660 noauto,user,ro 0 0 and you should be fine to go. If this fails add a "umask=000" after "users". hope this helps

heya jagat, what you are experiencing is just that the combination of resolution and refresh rate Fedora is attempting to use is too low for your monitor. I'm not quite sure how Fedora could come up with the values you posted but they're definitely improper. Also according to the posted specs, I'd recommend a resolution of 1024x768 at 85Hz refresh rate, which is a standardized VESA mode. The respective modeline for this resolution would be as follows ... Code: Modeline "1024x768@85" 94.5 1024 1072 1168 1376 768 769 772 808 +hsync +vsync Just bask in the beatuy of the numbers for the moment until some explanations as to where to insert this line are passed by this ... Step by step guide 1. Booting into console mode I'm not using Fedora so I'm not quite sure what you have to do bypass the startup of the GUI. So I hope some other Fedora users can toss a note about that. Anyway ... If there are no boot-aptions available (like by pressing F1 or something similar), let the screen go blank and immediately try ALT+F2. This should give you a shell login screen where you should log in as root. 2. Editing your X-configuration If you have managed to get into console mode type this command ... Code: emacs /etc/X11/XF86Config-4 (mind upper and lower case letters) 2.1 Finding out what monitor is used The above command will open the X-config-file in the editor. Scroll down until you see a line like this ... Code: Section "Screen" This is the place where you have to look for an entry called "Monitor". Usually this setting will be something like Monitor "Monitor0". If your "Screen" section mentions a different monitor than "Monitor0" than keep this respective identifier in mind. 2.2 Editing the "Monitor"-section Next thing to search for is a line that should read this ... Section "Monitor" Identifier "Monitor0" . . etc. EndSection The following is a listing of what you should add or what lines you should alter ... Code: HorizSync 30-71 # the HSync-range VertRefresh 50-160 # min. and max. refresh rate 2.2.1 Adding a suitable modeline Now, all you have to do is to extend the monitor section with the above modeline. You should have some modelines there already. In case you haven't just add something like this right above "EndSection" (keep all values up to "+vsync" in one line; just in case the HTML-renderer of this forum breaks it) ... Code: # mode 1024x768@85Modeline "1024x768@85" 94.5 1024 1072 1168 1376 768 769 772 808 +hsync +vsync 2.3 Activating the new mode After you have inserted the modeline into your Monitor-section, go back to the "Screen"-section and search for an entry like Subsection "Display" Depth 24 # or "Depth 16" or "Depth 8" Modes "640x480" # or whatever mode you are currently using EndSubsection Edit the "Subsections" so that your entries read something like this ... Code: Subsection "Display" Depth 24 Modes "1024x768@85"EndSubsection That should do the trick. Also make sure that under <Section "Screen"> you have an entry like "DefaultDepth 24". 2.4 Save the changes amd exit editor Press CTRL-X and S subsequently to save the changes and then press CTRL-X, C to exit emacs. Now you're back in the shell and should be able to reboot your puter with the "reboot" command. Hope that helps ps: if that little howto has tempted your "geeky" bits then lurk around here and twiddle your video-modes to kingdom come -> http://www.hut.fi/Misc/Electronics/faq/vga2rgb/calc.html

Thanx DapperDan for the kind words. To be honest: A couple of months ago I did a lot of test-installs and with most of them I fooled around with the accounts as I never planned to use the setup "for real"; til one day when I had to do some tricky postgres-stored-procedure fun on a production machine. I knew I had already done that on one of the test machines, alas, I didn't recall the root-password So a little search on the net made me dig up the above procedure. Quite slick and precise. My thanx therefore goes out to the unknown author of this, from whom I shamelessly leeched the knowledge

gidday jarves You basically have to gain access to your machine somehow to alter the respective files. A pretty convenient way is to use the bootable installation CDs of some Linux distro and launch some "recovery console". If you can't see some comand like that you might try the ALT+F1..Fx keystroke to maybe get a clear console. Once you have managed to get into a shell you need to mount the partition that holds your /etc directory. To reset the root password open the file /etc/passwd and look for a line starting with ... root:x:......... Delete the "x" in this line as it tells that the password is shadowed. Save the file. Secondly open /etc/shadow and search for the entry for the user "root". This one usually looks like this ... root:$s0m3fR1g9InMD5h45H:<numbers>:<more numbers>:::: Delete all values (the stuff between the columns) so that you get a line like this ... root:::::::: Save the file, unmount the partitions and reboot. The root-account should not have set a password now, which you should change immediately again. hope that helps

'lo again atcskyfox As I mentioned above Windows will refuse to format FAT32-partitions if they are larger than 32GB. The reason for this is that Windows is just a little bit ... well, stupid (to put it mildly). But anyway, you can use FDISK to partition the drive, that should be no problem. Just don't try to format under Windows (as it would not work anyway) and do the formatting (a) from either within the respective linux-installation routine (for example the MDK/Suse/Fedora partitioning dialogs that are displayed during setup) or ( with the tools you already have at hand thanx to your running Suse installation. As to your suggested partition layout: That looks fairly ok. A 70GB FAT32-partition is absolutely no prob, though be informed that you loose quite some storage space due to another MS-idiocy. FAT32 is a very "basic" filesystem that uses clusters. A cluster is the smallest allocation unit that the filesystem can address and it usually spans 2 sectors. Depending on the size of the partition those cluster sizes can be e.g. 1kB, 2kB, 4kB, 8kB or 16kB. With increasing partition sizes also the cluster size is increased. For a 70GB partition you will probably end up with 8kB. That means that even the smallest text-file that only contains a single character will yum up 8kB as this is the smallest allocation unit on the partition. Sidenote: This discrepancy between actual size and allocated size is also displayed if you right-click a file under Windows and select properties ("File size" and "Size on disk"). Don't let this disturb you too much as nowadays harddisks are cheap and enormous in size. So before you have filled up your current drive you have probably earned enough gough to slap in just onother 200GB drive have a nice day

gidday atcskyfox Holy moses, this thread is beginning to even confuse me But anyway ... according your last question as to how to boot from a secondary disk. The dual-HDD configuration you are suggesting is in fact pretty similar to the configs as I use them. Therefore I can give it away quite freely: You don't switch around in the BIOS at all as LILO, the reliable workhorse amongst the linux bootmanagers, handles all this fuss easily. In terms of a step by step guide this would go as follows ... Harddisk installation Leave your current XP-drive as it is and install the new drive. My tip, though, would be to attach the new drive as secondary master, as it can utilize a different IRQ and IDE controller than the primary master which usually results in smoother disk-to-disk-operations. Harddisk partitioning For the sake of a smooth data exchange I suggest that you split up your new drive as follows: Code: PARTITION .. SIZE ... TYPE ................... MOUNTPOINT1 .......... 1-2GB .. Linux Swap2 .......... 60 GB .. Linux (ext3 or reiser) . / 3 .......... 30 GB .. FAT32 (data exchange) .. /mnt/data4 .......... 28 GB .. FAT32 (mp3, vids etc.).. /mnt/media Alternatively you can also combine 3+4 to a single 60gig partition and format it as FAT32 with the Linux-partitioning tool (which will not complain). Don't bother, the wussy Windows will just be fine with this FAT-partition even if it's larger than 32GB. OS choice I don't want to intensify this issue any further, but be informed that I am a huge Mandrake (for desktops) and Debian (for servers) fan Though DapperDan and danleff clearly know what they are talking about when they recommend Fedora or Mepis (btw: visiting the Mepis site found me a bit confused due to the "blooming" Mepis distribution-schemes; pretty confusing). TIP: I usually leech a couple of distros, retire to my secret chambers and install different distros a whole weekend long, complie custom kernels, specific hardware drivers and applications that I need. The distro that doesn't bother me too much with any of those "libblahblahblah >= 1.2.3.4.5 required" messages wins. So the smoothest to install is the "linux of choice" for the next months, til the next versions of other distros are out. Therefore I'd say: If you have broadband just get Mandrake, Fedora, Mepis ... whatever distro: and install all of them; one after the other, always repartitioning your secondary drive (as an exercise just to get the knack). The one that suits you best and that supports your hardware best (watch your ATI and the A7N8X-GBit-LAN-chip) is the distro you should take. OS installation As you already have XP installed, all you have to do now is to go into the BIOS and make your system boot from your Linux installation-CD. Bootloader setup One of the final steps is to set up the bootloader, for many distros this will be "LILO". Also all distros that I know will ask you where to place the lilo-bootloader-code. Here you should choose your primary drive. LILO will then take over the boot process presenting you a menu containing all the operating systems found on your machine. The sweet thing about LILO is that it doesn't care where the operating systems reside (disk 1 or disk 2). It just needs to know the partitions, the rest is done via the bootsector-code from the primary harddisk. Well, that's about how things go in a dual boot environment. If you plan your steps carefully you should have no prob at all (apart from finding the right distro Hope that helps

heya riazmc, glad to hear the install worked. now let's tackle your other questions ... HDD access There are 2 ways to do that: (a) via the "mounts-control-panel" in drakconf or ( the manual way by editing the file "/etc/fstab" The easy way/Ad (a) Open your MDK control-center or type "drakconf" at the console and go to the section about mounting drives and partitions. This lets you add drives/partitions to the file "/etc/fstab" so that you can access those. Ad ( Of course you can also edit /etc/fstab manually, though I recommend a bit of reading about the options before you do that. Also you need to know the shortcuts (e.g. "hda1/hda2") and types for your partitions (ext2/ext3/reiser or vfat etc.) As a starting point you can try this link >>> http://gentoo-wiki.com/HOWTO_Mount_MS_Windows_partitions_(FAT,NTFS) <<< Go down to "Step 2" to have the options of an fstab-entry explained. Generally speaking: Using the word "HOWTO" in combination with some problem has saved plenty of linux-noobs a lot of time searching for the right answer on Google. So in your case try some searches with terms like "mount howto", "fstab howto" etc. The Looks of your GUI You can set this too from within drakconf. Just click the "Display" icon and choose your favorite window manager (KDE or GNOME). Can't give you no tipps about what's better as KDE vs. GNOME is a religious thing. I personally _HATE_ Gnome but that does not mean that KDE is so very much superior. I prefer KDE mainly because I don't want to have the "OK/CANCEL" buttons to have registered as "real estates" due to their enormous sizes and because of the "file open"-dialog, where GNOME manages it to drive me nuts by always starting in the home directory and not offering favorites or a "places sidebar" as KDE does. But that's totally up to your liking. Another word according the "noapic/nolapic"-thing. If you ever experience freezes or crashes whilst working with linux, then you should pass those parameters to LILO too. For this to do, open - once more - drakconf, click on "boot" and go into "advanced mode". This brings up a dialog where you can add the "nolapic"-parameter (the line should read something like "[blah] acpi=ht [blah]"; just add "nolapic" there). Have much fun with linux, dude

hi riazmc, occasionally it can lead to problems during the installation if you have set "ACPI" to "enabled" in your BIOS. So for a quick test, enter your mobo's BIOS (DEL or F1-key, whatever; should be displayed on screen), search for the ACPI entry and set it to "disabled". After you've done that boot from the CD, press F1 and enter the line linux noapic nolapic Maybe this helps, at least it only takes a minute to try it out. Good luck

gidday _zeppelin_ From your screenshot I take it that you also seem to have a folder without a name. As it is the highlighted folder in GTKSee the idea crossed my mind, that your GTK might eventually be screwed up color-wise. That's just a guess, but maybe if you could tell if the "missing" menu entries do something at all when you move the over them or even click them (highlighting or performing the action that is usually linked with the respective menu). If you don't get a menu-focus when moving the mouse over a missing entry then the problem most likely resides elsewhere. In case you do, the themes and color settings would be a good spot to check some things. good luck

howdy rafusewc I don't think it's really the c-compiler or its sources you are missing cause the compiler is a vital part of any *ix-system. Amongst the things you might need for a successful VmWare installation are ... (1) Perl and (2) The kernel sources Perl seems to be present on your system as as the installation script seems to run and furnish you with information. In many - if not all - cases the installer script will need to compile some interfaces for VMWare, which is why you need to have the kernel-sources installed. So the package you need is kernel-2.6.3-mdk-src (or whatever it is named for MDK 10; can't recall now as I'm tied to a Windows machine at the mo). After the installation the files from that package reside in /usr/src/linux (a sym-link usually) which is also where the VMWare installer expects them to be. Still though: you are being asked if this is the right path. hope that helps

gidday again, voltmer it looks as if the "google-izer" would brandmark your mobo as a "not so suitable peice of hardware for linux". Bad news on one side, I admit, but then again, there is some hope here ... http://www.fedorafaq.org/#installreboot hope this sheds some light, at least as it goes for Fedora good luck

gidday voltmer, from the details you posted here not much can be said about the true reason for this problem. Though there are some things that could maybe help in hunting down the reasons for your probs: a) APIC settings From what I gather, MDK seems to be unhappy with the interrupt assigment (obviously you don't even get a proper device-listing), so my first address would be the "APIC" settings (Advanced Programmable Interrupt Controller). You could use the MDK "installation"-proggie to check what parameters are passed to the kernel in your configuration. To do so, switch into "Advanced" mode while you are presented the "Boot parameters"-dialog (I apologize that I cannot provide the exact label-names as I get everything in German here). Alternatively (if you have access to the *X-filesystem, maybe by booting with an emergency CD like Knoppix) you could check "/etc/lilo.conf" to see if anything apic-related is appended to the kernel-parameters (entries as these could be of interest: "noapic" or "apic=ht"). Whatever you find, toggle or remove it temporarily and check the results. LAPIC settings Also the LAPIC-settings could be the cause for your struggles (Local Adv.Progr.Interr.Ctrl.). Check what your current LAPIC setting is (in the same line in lilo.conf as the APIC-parameter). If there isn't then I would suggest to append the "nolapic" parameter. I admit right away that the things get a bit vague from this point on, nevertheless it could be worth a try if anything else fails. c) BIOS settings Check if you have a setting in the BIOS labled "PNP OS". If so toggle it and give it a try. Upon failure, go back and search your BIOS for "PCI/IRQ" settings. If there is such a section try to assign the IRQs manually. Also have a look if you can maybe specifiy IRQs for the onboard devices (dunno what's onboard on your mobo; but I would guess at least the NIC, sound- and maybe the RAID ctrl. are). If your NIC or sound-card e.g are onboard you might want to give it a try with those devices disabled in the BIOS, just to see if maybe some IRQ daisy-chaining/-sharing fails. We occasionally have such issues here when onboard NICs and sound-chips collide with GFX-cards and/or RAID ctrls. that are assigned the same IRQs. Twiddling with the BIOS-IRQ-settings usually solves those issues (if the onboard components aren't replaced by standardized hardware anyway). Well, maybe you find something to at least check out in the above. Good luck.

Addendum .. Almost forgot to mention that many "make"-files contain compiler directives for optimizations ... so generally in most cases some form of optimization option is always given to the compiler regardless if you have set CFLAGS/CXXFLAGS or not. -fin-

'lo again anthonyi, re:CFLAGS/CXXFLAGS. That was in fact my bad there. It's basically not common to set those environment variables during OS installation, at least they are not set to anything very specific that one might consider "tweaked". As you use these flags to globally tweak the compiler optimizations to your needs and also to your machine's specs most OS installers - if they set the env-vars at all - will stick to rather basic CFLAGS-settings that would not compromise the stability of the app or the system. But you can of course add those entries to one of the files that define your environment. /etc/profile or /etc/bash_profile are such files where you can add the entries globally (= for all users). Other options would be the file .bashrc in your home directory. About what to set the CFLAGS/CXXFLAGS to I can only refer to Google. An example setting for a highly optimizing setting on an AthlonXP machine would look like this ... export CFLAGS="-march=athlon-xp -pipe -O3 -fomit-frame-pointer" export CXXFLAGS="${CFLAGS}" (last line means "use value of variable $CFLAGS") hope this helps

gidday anthonyi re "strip": In short, this little program deletes all symbols from executable files. What does this mean? During the development of an application you have to go through certain stages: a) Writing source code: In this step you write functions, declare variables and constants, create or import external modules and do a whole lot more stuff. Compiling: During this step the compiler program transforms the written source code into machine readable code (called "object code"). For the next step (linking, see below), and if you want to do some debugging later on, the compiler will add symbols and/or additional debugging information to the translated source code. E.g. if you declared some variable like "int a;", the additional debug info would read like this: "<a> is a 4 byte wide integer value to be found at memory address <module start address> + <offset of variable storage section> + <offset to a>". Of course, compilers and linkers (see ©) won't write stuff like that into any object code file. But what they actually write can be later be evaluated to the above. c) Linking/binding: After the steps (a) and ( you have a machine-readable thingie, but this is still no executable. For this to happen you will need to launch the linker. A linker (nomen est omen) "links" together all the pieces of object-code and creates program file that can be launched from the shell. "Relocatable" means that the operating system can load the program to any place in the memory and it will still work (that was not always the case, and programmers at my age will still remember the days of "absolute" start-code . The linker uses the additional infos from the compiler to achieve this. As you can see, a whole lot more is done in such a cycle than just to bring some code-lines into machine readable form. In the object code and also the final executable many symbols are still included. And this is where strip comes in ... Strip removes such additional information (e.g. line numbers, unnecessary relocation info etc.etc.) thus reducing the size of the binary file. And to answer another one of your questions in brief: No, you don't have to do a strip on every program you compile, unless the size of the executable would suggest it. Besides: The size of executables also depends on your optimization settings (e.g. "-O3", the best optimazation, or "-O1" for medium optimization; just check the CFLAGS/CXXFLAGS settings in your environment by doing an "env | sort" on the shell). Highly optimized binaries will always be noticably bigger than less optimized executables. It is also a thing which compiler you are using. The intel compilers for instance are legendary for their fast code, but also for their enormous executable-sizes if all optimizations are activated. hope this helps

Greetings iano200, as mentioned above, there can be issues with dual-booting on XP-machines that you plan to embroider with a kernel 2.6 based linux (such as MDK10, Fedora Core 2 etc.). In the "worstest" case you cold even end up with a machine that will neither boot linux nor XP. To avoid any possible hassle and data loss, please, do as emphasized above: back up everything from your harddisk that is of any significance before you start the installation/re-paritioning. Secondly, perhaps you'd like to inform beforehand about what could happen and why it happens at all. The Internet is stuffed with good articles about the kernel 2.6/MBR issue (master boot record). For your convenience I'll add this link that you might want to follow ... Kernel 2.6/MBR problem description/solution: http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00908.html The other thing I'd like to mention is that you won't be able to do much with an NTFS-partition under linux. Reading data is possible but enabling write-support in the kernel is considered "experimental" (=dangerous), and this is not going to change any time soon as MS won't publish any details about "NTFS". Why they don't is one of the "4 big Microsnot"-questions (others are "Why can't IE do stylesheets properly?", "Will XP service pack 3 break the 1GB barrier?" and "Where do you want to go today?" In real life terms this means: You can copy some file over to a linux partition, edit the file, but you can't get it back to NTFS to further process the file under Windows. The solutions for this matter are: a) either set up a "file exchange server" (not really easy as you need a lot of extra hardware, even if it's old hardware) or somehow convert your drive to FAT32 which is a filesystem that both operating systems can read from and write to. As you can see it takes a bit of preperation and know-how to bring both worlds together. So if you ain't up to permanently use Linux on your machine you might consider all the above a bit bothersome. Anyway, whtever you do: backup your data (even if you stick with windows As an encouragement though, I'd like to add that I'm running a couple of dual-boot machines at the office (and also here at home). On all of them MDK10 and Win2k live in perfect harmony. The good thing here is that every OS has its own dedicated harddisk (with reiser fs on linux and fat32 for windows), so I never had to re-partition anything. regards

Firstly: Good work there, taeuler. Especially as one of biggest advantages of gentoo - the excellent manuals - can occasionally turn out to be almost a drawback as their are extraordinarily lengthy. So a straightforward quick-setup guide might indeed be what some folks are looking for. Secondly, and also as an addition to the "In the Clear"-thread, I'd like to throw in some teasers for those who fancy some Gentoo-ish experience: As I said, we tested a few distros a couple of months ago on various machines. Amongst those machines were also two of our old dual-p3/500 on ASUS P2B-DS boards (1gig RAM, 4 x Seag. Barr. SCSI HDDs RAID 0+1, on DAC 960s RAID ctrl., Rage 3D gfx). To our pleasure these machines under Gentoo felt like a "Ferrari on speed" again and handled even heavy loads with a certain "grandezza" In a nutshell: A stage 1-install of Gentoo can indeed deliver you some amazing extra power. In fact, so much extra power that we've kept those old servers as fallback machines. So if you have some old hardware and some spare time to really go for a "stage 1" install, I can only say "Do it!" regards ps: Might also mention the installation time, to give you a clue All in all: ~2-3 days, including X, a full KDE, a full GNOME, Postgres, Apache, PHP, Gimp and what the smeg else Maybe a waste of time, as X has never been launched again after the tests

@DepperDan ... greetings at first, and also right from the beginning I'd like to point out that it was never my intention to point at jimf43 or anybody else in a bad mood. But I'm not sure if I would subscribe to the point that I maybe misunderstood the point of the originating posting including the "sublime accusation" some distro is about to be "bullied" here Basically I reduce it - and maybe this is a wrong thing to do, I admit that - to the point that Mandrake 10 at the moment is a very, very popular distro. This goes hand in hand with other factors, like e.g. a very positive echo in the media over here in Europe. With a backup like that a whole lot more people will d/l and install the distro and consequently a whole lot more people will run into trouble doing so, if they don't prepare. Lemme explain with an example: Throughout the tests I've mentioned in my post we also had a look at Knoppix 3.3 and 3.4. v3.3 would install fine with the included but didn't show all the drive volumes on some machines. Knoppix 3.4 had a HD-install script aboard, that would only work if you d/led some extra libs. Don't get me wrong now: I'm not trying to put Knoppix down for the benefit of Mandrake. But Knoppix - at the times then - was hot as Mandrake is hot now (and has been the last months). And whenever something's hot on the market the developers will try to satisfy the demands and consequently knit the package with a too hot needle. In the case of Mandrake it was indeed what the MDK-team did to the kernel 2.6. I can wholeheartedly agree with you on that aspect, cause the MDK kernel has so many 3rd party addons and whatnotelse patched into it that propably not even Linus would recognize it anymore @jimf43 ... well, I dunno if it's the truth from my point of view, but I can assure you it does not hurt But I'm certainly not above to admit that you have shared knowledge way above average, from what I can see. But lemme straighten the following out: IE and Windows had a rather bad time the last months. Security issue here, security issue there, security issues everywhere. Due to this, and with some Linux distro-Live CD being on almost every cover CD of all the very popular magazines, Linux has got almost a jump start (at least here in Europe). Since May the percentage of e.g. Firefox has increased around 12%-15%, and OS-wise Linux-usage has increased around 4%-5% compared to Jan-Apr. (from our web logs, overall: ~250k unique visitors in that timespan). So couldn't it be that we just witness the very first and tender beginnings of what we had always been waiting for: Linux oozing into the desktop market (veeeery slowly though)?. I personally think that times will get even more tense in the near future. Cause every million of new Linux users will also mean a couple of thousand more noobs coming here asking questions. Those won't be too much questions about Gentoo or Slackware, cause folks who do those distros usually know what they're gonna dance with. it will be the popular distros like MDK, Suse, Fedora etc. That is -as it goes for such active members like you are- indeed taxing. On the other hand, it's also good sign of the times, ain't it. @both of you: have a nice sunday ps: I will of course gladly help out here if there is anything to contribute, just as I did in the few months that I -gladly- take the time to stop by here

In defense of Mandrake Last things first: The very best about Linux is that everybody has the freedom of choice. The freedom to choose and also to dismiss any distro in case it doesn't fulfill the expectations of the respective user. It feels very uncomfortable to read that some knowledgable folks here tend to exclude MDK from their attention on this forum. I came here a few months back cause I needed to ask a question concerning the usage of MDK in a desktop environment. And I was helped, and I was helped maybe because this forum back then still was "linuxcompatible.org", and not "fedoracompatible.org" nor "mepiscompatible.org" nor "anyotherspiffydistrocompatible.org". I'm following the threads here too and from what I can see it's the users of "special" hardware who usually have a bad time. This mostly means "wireless", or "mobility", or "freaky soundcard", or "notebook" in general. I'm not joining the choir who so steadily claims "get the f*** informed before you buy hardware". But hardware incompatability is a term every wanna-be linux-user should get familiar with when he/she plans to make a step towards this OS. Here is how things turn out from my point of view, and just to fill you in: I run a company that deals with network related software and multimedia-content development. And wouldn't you know it, we have issues almost every week with some pieces and bits of hardware - inhouse and with our customers' machines - not being properly supported by whatever OS we use. Now, would anybody say Windows XP is a crap OS because you can't get drivers for (let's say) the Emagic Audiowerks8 sound card that would allow you to further use the sound-recording software you paid a fortune for? Would anybody say XP's a bad OS just because in the past certain nVidia drivers would not let you view DVDs on TV-out with WinDVD? I doubt that, and if you have to, you can say XP's a crappy OS for this and that reason, but not because some hardware or software manufacturer is unwilling to provide decent hardware, drivers or applications. Would it be legitimate to say any linux distro is not worth the effort cause some gfx-card vendor decides to twiddle around with their GPUs til they can't recognize them themselves? As it goes for this matter it is -e.g.- ATI and their "Mobility" nightmares who are unable to provide hardware you can rely upon to 100%, but it's certainly not linux that lacks anything. So what exactly is Mandrake to be blamed for? Why not blame manufacturers for patching together something that is unsatisfactorily tested and far from being flawless but yet and still selling it as the "notebook of the year"? And in further defense of Mandrake, especially MDK10: We have always used linux servers, all right. Suse in the beginning and ever since a few years or so our choice was Debian. This year we made the step to also migrate to linux on the desktops where this was possible. Many distros have been tested thoroughly, amongst those Suse, Knoppix, Debian, Fedora, Gentoo and Mandrake. None of the above was perfect, and none of the above was really bad. But counting the score after the tests, where our focus was on aspects that deal with the demands of a productivity environment (installation and stability of software like Audacity, Gimp, Blender, VMWare, OpenOffice, Eclipse, KDevelop etc.) Mandrake was in the lead. And it was not the slightest margin at which MDK made it. Now, 20-something desktops run under MDK without the slightest problems, most of them with dual-head setups, in a gigabit-lan environment, pushing some SMP file- and database-servers, and also some load-balanced inter/intranet servers of which most -by now- are also migrated to MDK - again, without the slightest sign of problems. So for all I know is: Our MDK-puters run, and therefore we have been lucky. Not lucky to have chosen maybe the right OS, but lucky to have chosen the right hardware. Other puters won't run under Mandrake. Users of those maybe had no luck. But with MDK they still have a top-notch linux OS, they only have unreliable hardware. regards

Howdy deathrail, as said above, da GIMP is really the thing to look for under X. The only recommendation I would add is to immediately upgrade to GIMP 2.0.1/2, 'cause as far as I remember MDK 10 comes with GIMP 1.x which just can't cope with version 2.0+. Still though, if you need some CMYK-capable program (e.g. for print-jobs etc.) then GIMP will not satisfy your expectations. In this case you better try to get Photoshop running under X (Wine?, or VMWare as I do here). Also I'd like to point you to this link -> http://www.linuxcompatible.org/thread26991-1.html ... a quick-install-guide I wrote a couple of months ago and which should give you a quick overview what you might need to download and install prior to/along with GIMP. Furthermore - and just in case you're after some vector-graphics proggie too which is well worth a look - you might want to read up on a thing called SODIPODI > http://www.sodipodi.com/ <. It isn't quite Corel or Freehand, but still nice. hope that helps

Howdy szfszm, Unfortunately I neither run the specified RedHat OS nor do I have any Mobily-variants amongst my ATI-boards. Nevertheless, here are a few things, to be considered "2 cents" When you d/l the driver packages from the ATI-site, did you check for the proper XFree-version? I don't know how old your RH-distro is, so maybe it uses a stable but old XFree86 version (prior to 4.3.x). libGL.so.1 is one of the standard OpenGL-libs that are part of XFree/Mesa, and from the error message you posted it seems that the ATI driver is unhappy with the version of this library. To really narrow down the possible errors it would be fine if you could post _what_ symbol exactly is missing. This way one could determnine what libGLU-version is required. As some really vague shots I'm adding some hints to what possibly could fix your problem: * installing a recent version of Mesa/libGLU via RPM-sources * upgrading XFree86 (in case it _is_ out of date; I would avoid that if anyhow possible good luck with this

Greetings I just had some sort of odd experience while trying to get ATI's 3.7.0-drivers to work under kernel 2.6.7. Here are the bothersome and significant lines that "/lib/modules/fglrx/make.sh" produce ... /lib/modules/fglrx/build_mod/2.6.x/agpgart_be.c: In function `agp_generic_alloc_page': /lib/modules/fglrx/build_mod/2.6.x/agpgart_be.c:1405: structure has no member named `count' /lib/modules/fglrx/build_mod/2.6.x/agpgart_be.c: In function `ali_alloc_page': /lib/modules/fglrx/build_mod/2.6.x/agpgart_be.c:4416: structure has no member named `count' Looks like the 3.7-driver doesn't go too well with kernel version 2.6.7. I went back to the standard setup afterwards (ATI3.7 under kernel2.6.5) which works like a dream. If any of you guys/girls are just as curious as me as it goes for kernel-testing then you might want to check out this link that is said to solve the driver-issue ... http://kerneltrap.org/node/view/3298 Be informed, though, that I hadn't have the time yet to verify the patch featured on this page. Also, as soon as time will allow, I will check the new kernel against the nVidia-drivers on some other boxes. Til then .. have a luverly day and weekend

Thanx DepperDan, fortunately I was only peeking into the whole thing (ATI+k2.6.7) out of curiosity and to find out if there might be any probs with those drivers/kernel versions in case a system-upgrade is immiment. So these incompatabilities do not bother me too much at the moment, especially as the standard setup (ATI3.7+k2.6.5) works perfectly. As far as it goes for the fundamental windowing server: The test-boxes used were running under Mandrake 10 and Suse 9 (see detailed specs below) which both came with the XFree-server (recent Suse already comes with X.Org, me thinks). But another box for XOrg-testing is already set up, so - even if it sounds peculiar - I'm sort of "hoping" and expecting to encounter some problems that can be solved in some joint effort After all, XFree will be history in many future distros and so it's a good idea to peek into XOrg right away. by specs/test machines: basic: AMD Athlon XP 2800, Asus A7N8X (box 1), Asus A7V600, VIA chipset with GBit-LAN (box 2), 512MB RAM, DAC960 SCSI-RAID, Adaptec 2940UW SCSI, Radeon 9600pro (box 1), Geforce 4MX (box 2) storage subsystem: 4xSeagate SCSI 10k (30gig) drives as RAID 0+1 array as boot/system drive, Seagate 120GB IDE (data storage) operating systems: box 1 - Mandrake 10 Community running kernel 2.6.5 and KDE 3.2.2 box 2 - Suse 9 running kernel 2.6.5 and KDE 3.x (dunno exactly)

Good evening, folks I have used Mandrake 9.1/2 with Nvidia-GFX-cards and varous mobos for quite some time, and no hardware-setup gave me any trouble. Couple of weeks ago I upgraded my machine ... here are the current specs: ASUS A7N8X-X board (yeah, the doomed one :)/XP3200/1.5GB Ram/Radeon 9600Pro. To honor this setup I thought about checking out Mandrake 10. It's all quite fine - apart from 2 things: A: Gfx-Issue No matter how I twiddle the beast, the ATI drivers won't load and I'm stuck with Mesa 3D. The kernel sources are of course installed, the fglrx-rpm installs nicely, it also compiles nicely, it inserts the driver/necessary modules without any error message but still - fireglrxinfo states that Mesa's used. I even launched "make.sh" and "make_install.sh" as described (even though it seems to me the RPM handles all that in the first place anyway). The result is always the same: no errors, but also no fglrx (even though it is mentioned in XF86Config-4). My questions therefore are: -) Could it be related to some agpgart-thing, is there some other agp-module to insert (nvidia-agp? ati-agp?)? Cause lsmod doesn't list any of these, just the standard agpgart. -) Could it be related with the version of Mandrake (leeched from the Internet for testing)? I think I saw something during the installation procedure that mentioned that only "commercial" version has support for newer hardware (including Radeons). B: Sound thing/hisses and clicks After installion the sound system hisses and clicks like crazy. Turning down the AC97-volume slider fixed this, still .. anybody had similar effects? A great load of "thanx" in advance for taking the time read or even answer this bp p.s: the standard "radeon"-driver works nicely in 1600x1200@80 - nicely but slowly

howdy ... according the question in the first post: just jump to http://java.sun.com/j2se/1.4.2/download.html and grab the J2SE v 1.4.2_04 JRE package. This should be a binary installer that will give you the Java-StandardEdition VM. ad posting #2: I don't know LimeWire, but as it is Java based there might be a chance that you can add a commandline parameter that tells the app where to find the virtual machine - something like this e.g. ... user@machine$ limewire -vm /usr/java/j2sdk1.5.0/jre/bin If LimeWire is somewhat similar in its startup-procedure to other Java-apps (like "Eclipse" e.g.) it should tell where it was searching for the virtual-machine files. good luck with this