blackpage

howdy gwitty, a response to your question is probably twofolded ... You are thinking about advancing in the right direction, driven by your security concerns. Things will probably only get worse in the future on the Windows-side of the internet. So any decision towards using Linux to harden your gateway/router/mailserver-machine is more than just agreeable. On the other hand ... You are about to enter the Linux-domain from the "server-side", and this can give you a lot of headaches if you lack a certain amount of necessary endurance as DapperDan has already mentioned. As none of the progs you've mentioned is available under Linux you may want to take a brief look at what it would take (software- and effort-wise) to ensure the same functionality on your Desktop-machine as you now have ... Firewall Every contemporary Linux comes with a FW-module built into the "kernel" (the system-nucleus, so to say). This FW's called "iptables" and is one spifftastomatic, a**kickin' piece of security-software. There's literally no TCP/IP-issue that you could not catch with a specific IPTABLES-rule. Many distros access IPTABLES through GUI-frontends that let you define those rules more easily (Smoothwall has been mentioned, and there are many more frontends, like FireStarter or Firewall-Builder). INet-Connection Sharing (NAT) This specific thing is also handled by iptables (the NAT-capabilities of this module respectively). Many of the above mentioned GUI-frontends will aid you in defining the needed filter-rules for this. Many more things from this field can be achieved with iptables or additional apps. If you want to e.g. add a proxie too you may want to check out Squid, to just name a polular one. Email-Stuff This will be by far the most trickiest thing to set up. I dunno due to what Linux-tradition this is, but setting up a spam- and virus-filtering, mail-forwarding server can drive you nuts. Most distros come with the "regular" mail-mangling-progs like sendmail/fetchmail. I cannot really recommend the sendmail/fetchmail-couple for two reasons: (a) The sometimes really hideous config-file structure and ( the security issues that sendmail has. Of course, the basic sendmail/fetchmail-couple will not filter anything (but it would forward mails to the right accounts, given that a lot of things are set up properly (like aliases, permissions etc.)). To make spam- and virus-filtering happen you have to "daisy-chain" multiple apps. You will need an MTA (Mail Transport Agent) like EXIM or QMAIL, a spamfilter (is there anything else but SPAMASSASIN? and a virus-filter (e.g CLAMAV which we use for our mail-servers). As you can see there are a lot of apps and things involved and most definitely an even basic setup with minimum-functionality will take you up to several days if you haven't laid hands on Linux so far. But the gain is indeed immense: If you decide to go all the way and maybe even tweak/harden your box you will have a halluva bullet-proof and reliable machine that will let you forget about things like "reboot" and which will be "99% immortal" (unless you pull the plug) hope this helps

correction/addendum: oops, I say, to my surprise i had to find out that my MDK10 here ignores an "init 3". So to log into the system and into a console you might want to disable the "auto boot-into-gui"-mode. You can do this via "Configure your computer" from the DrakMenu. As I have a german version here, I have prepared a screenie to show you what switches to set: http://lepschi.source.at/disable-auto-gui.jpg But before you do so, you might want to ask yourself some cruical questions: (a) Can you handle a non-KDE/GNOME editor like emacs, as you need to make changes to your XF86Config-4 file? (eg. in emacs: "CTRL-X/S = save, CTRL-X/C = quit") ( Have you made a backup of your original XF86Config-4 file that you can restore from within command-shell to ensure you can get back to KDE/GNOME in case something goes wrong? (backup: "root@machine# cp /etc/X11/XF86Config-4 /etc/X11/XF86Config-4-save" restore: "root@machine# cp /etc/X11/XF86Config-4-save /etc/X11/XF86Config-4") after all, we would not want you to get lost somewhere on the command line cu

gidday, re: no permission ... nod, as stated above you need to be root to compile and install the NVIDIA-driver. For this you have to leave your graphical environment (KDE/GNOME ...) by opening a console under KDE e.g and typing "init 3". If it gives you a "permission denied", just make yourself root in the console by typing "su" and entering the root password. After that you can surely "init 3" to shut down the gui. After that, change to the directory you d/l the NVIDIA driver to and run the bin-file by typing "./NVIDIA-etc-etc.bin" cu

heya soulnothing, all you need to install are the source files for the kernel. You can do this in the package manager (rpmdrake). just enter the word "kernel" and click "search" and you should be presented with a list of found packages. From those install "kernel-source-2.6.3-4mdk". The rest should be handled by the PackageManager. hope this helps

... in reply to DapperDan gidday, hmm, so far I haven't seen some nagging from MDK10 about CD4. But ... this may come from the fact I have immediately copied all 3 Community-CDs to harddisk and disabled all of the default CD-entries in the RPM-package-sources, using only the RPM-archives on harddisk. Not sure, though, as MDK10 only puts 3 CD-entries into the default package-manager.

hi there, as far as I know CD4 of the Mandrake distro is only available in the "commercial" version which is sold (check the MDK-website for ordering info). on a sidenote: this doesn't hinder you to install MDK10 with just the first 3 CDs, so the MDK-community distro is in no way crippled or anything. During installation, just click on "Cancel" when you're asked for CD4. cu

'lo again ... let's rock ... @TwinView .. "first i want to know if linux handles dual monitor support i got a nvidia 5200 plus 128mb card that allows for it but i cant figure it out" Yup, Linux (and therfore MDK10) handles TwinView/DualMonitor setups beautifully. We have a bit of luck as I run several ATIs and GF5200 in such a setup. To make the whole thing work, a procedure like this is recommended ... 1: Download NVIDIA-drivers Fetch the proprietary drivers from NVIDIA's website. Choose "Graphics driver" -> "GeForce" -> "Linux IA32". Latest package is "v1.0-5336". 2: Install the NVIDIA-drivers a: Before you can install the drivers you have to make sure the kernel-sources are installed and in place. The NVIDIA-installer expects the kernel-sources in "/usr/src/linux", and that's the place where they should be if you've installed the Mandrake kernel-source-RPM (you can do that e.g. in DrakConf). b: Leave any graphical environment like KDE or GNOME and switch to a root-console (e.g. with "user@mybox>init 3"), changing to the directory you have d/l the drivers into. Launch the installer by typing ... root@mybox>./NVIDIA-Linux-x86-1.0-5336-pkg1.mun The installer will then ask about the ususal license agreement and whether it should try to d/l a suitable driver-module from nvidia.com, and finally (in case it can't find a suitable one) if it should compile a module. Confirm all of those with "OK"/"ACCEPT" and let the installer do its job (compile). After the driver is built, proceed to step 3 ... 3: Editing XF86Config-4 Open the X-config file (root@mybox>emacs /etc/X11/XF86Config-4). This is where you will bring the new driver to life. Firstly -as described in the rather lengthy but detailled NVIDIA-README (in "/usr/share/doc/NVIDIA_GLX-1.0" I think) - disable the stuff that doesn't go well with the new driver: Disable the modules "dri" and "GLcore" (e.g. by commenting out the respective lines in XF86Config-4) Secondly you need to change the current GFX-card-driver to the newly compiled one. Search for driver entry "nv" and change it to "nvidia" 4: Setting up TwinView/ServerLayout Let me get a bit detalled here to explain how NVIDIA handles that thing: ... Normally XFree86 puts together the entries in XF86Config-4 to set up a coherent basis for a graphical-environment. E.g. like this .. "ServerLayout" --> uses some >> "Screen" On the machines here, the "ServerLayout"-section of XF86Config-4 looks like this ... ####################################### ### SERVER LAYOUT ####################################### Section "ServerLayout" ....Identifier "Twin" ....Screen "screen1" ....InputDevice "Mouse1" "CorePointer" ....InputDevice "Keyboard1" "CoreKeyboard" ....#Option "blank time" "10" ....#Option "off time" "20" EndSection (I apologize for the dots As you can see, the layout utilizes a device called "screen1", so the next thing to do is to create and adapt this suitable TwinView-device "screen1" ... 4.1: Setting up TwinView-device "screen1" Search for a line labled »Section "Screen"« (or create a new section) and edit it to look similar to this one ... ##### SCREEN LEFT ##################### Section "Screen" ....Identifier "screen1" ....Device "TwinView" ....Monitor "monitor1" ....DefaultColorDepth..24 ....# only modes 8+24 ....Subsection "Display" ........Depth 8 ........Modes "1440@85" ....EndSubsection ....Subsection "Display" ........Depth 24 ........Modes "1440@85" ....EndSubsection EndSection The above section "defines" the properties and parameters for your left screen. The first thing that is of interest is the line »Device "TwinView"«. This tells us that the "screen1" is operated by the device "TwinView" (the gfx-card). Let's have a look at how this gfx-card is defined in XF86Config-4 ... 4.2: Setting up the GFX-card-device "TwinView" The section where "TwinView" is defined is one you have to manually add to your X-config-file ... so add something like this ... ####################################### ## TWIN VIEW DEVICE ####################################### Section "Device" ....Identifier "TwinView" ....VendorName "nvidia" ....Driver "nvidia" ....BusID "PCI:2:0:0" ....Option "NvAGP" "1" ....Option "DPMS" ....Option "RenderAccel" "1" ....Option "CursorShadow" "0" ....Option "TwinView" ....Option "ConnectedMonitor" "crt,crt" ....Option "TwinViewOrientation" "RightOf" ....Option "SecondMonitorHorizSync" "30-90" ....Option "SecondMonitorVertRefresh" "60-140" ....Option "MetaModes" "1440_85,1440_75;1400x1050,1400x1050;" EndSection Here we come to the heart of the whole setup ... It's the place where you have to insert your compiled driver (»Driver "nvidia"«) and where you add a lot of NVIDIA-specific options, that define the TwinView-setup. Let's check those out ... Option "TwinView" this enables the TwinView-mode Option "ConnectedMonitor" "crt,crt" This tells the Nvidia-driver what display types are attached to the gfx-card Option "TwinViewOrientation" "RightOf" This tells the driver where the 2nd monitor is placed (in our case: monitor 1 is the primary monitor, connected to the VGA-plug, and right of it is the 2ndary monitor, attached to the DVI-plug) Option "SecondMonitorHorizSync" "30-90" This defines the 2ndary monitor's capabilities. Adjust these values to make them fit your monitor-specs. Option "SecondMonitorVertRefresh" "60-140" see above ... Option "MetaModes" "1440_85,1440_75;1400x1050,1400x1050;" This is a cruical thing! MetaModes define the resolutions that are to be used simultaneously. You can define multiple meta-modes and seperate each mode-definition with a semicolon (";"). One mode entry can consist of up to two resolution-modes for the left and the right monitor ... Example ... Option "MetaModes" "1440_85,1440_75" this tells the driver that the left monitor uses a mode defined in the modeline "1440_85". It furthermore tells the driver to apply mode "1440_75" to the right monitor when the left monitor uses the mode "1440_85" You can skip entries in the modeline, or use different modes within a MetaMode-line like this ... Option "MetaModes" "1440_85," in this case the left monitor will still use 1440_85 but the right screen will be set to the best possiblee mode the driver can make up. You can read all about MetaModes in the above mentioned NVIDIA-readme. 4.3: Setting up the monitor for "TwinView" When we defined the "screen1"-device (under paragraph »4.1: Setting up TwinView-device "screen1"«) there was alse an entry about what monitor-device this screen should utilize. The respective line in »Section "Screen"« was Monitor "monitor1". So the only thing that's left is to define this "monitor1"-device. Add/edit this in your XF86Config-4-file ... ####################################### ### MONITORS ####################################### Section "Monitor" ....Identifier "monitor1" ....HorizSync 30-98 ....VertRefresh 50-160 ....# 1440 x 1080 @ 85.08 Hz Vertical 96.39 kHz Horizontal ....Modeline "1440_85" 189.71 1440 1544 1704 1968 1080 1081 1084 1134 +hsync +vsync ....Modeline "1440_75" 176.00 1440 1560 1720 1968 1080 1081 1084 1133 +hsync +vsync EndSection The important thing here is that you not only have to define the modes for the left monitor, you also have to add the modes for the right monitor if you want to use them in the "MetaModes"-line. Don't forget this when you define the monitor-modes here. Well, that's about it. Sounds way more complex than it actually is. If you need a "real-world"-XF86Config-4 then grab one of mine from this here http://lepschi.source.at/xf86config-twinview-example.txt Hope this helps cu

howdy, I can pretty much subscribe to the aforementioned. Wine's a nice thing, but it also has it's limits. I played around with it on 3 machines and found a few issues ... a: Performance Win-apps in a wine-environment do run, but don't expect a performance that would justify any production means. Running word/excel etc. may be ok, but the real biggies like PhotoShop or FlashMX (tested with PShop5.5, FlashMX) "sprinkle" along like frozen honey. b: Display issues On 2 machines the apps didn't show their toolbar icons. Whereas this is maybe bearable for something like Editplus, it is to be considered a major drawback for apps like FlashMX. c: Stability issues (I'd like to add at this point that I most probably didn't take the time to tweak Wine to utmost stability, so the encountered issues might have been easily my fault One machine did't like Wine at all. Every launched app crashed either immediately or when some action was performed in the Win-app. The other machines showed more respect and ran the apps at least for some time. But crashes were a very popular phenomenon during the tests (info/tested apps: Ediplus, Source-Insight, PhotoShop, FlashMX, MS-Office-apps and the Windows 2000 pro board-tools like Explorer, CharMap, Calc etc. the latter ones ran somewhat fine). I really don't want an impression to come along that I like to bash Wine - not at all! In fact, I do applaud the efforts of the dev-crew and I'm sure the product is on the right track. But as we were searching for a royally stable crossover-solution for our production-departments we had to divert from it and instead we purchased VMWare4. That's a completeley different thing, but at that, a wonderful one! Drawback is that VMWare is not the cheapest software to add to your portfolio, but in the last 2 weeks it has proven worth every single cent. cu

gidday soulnothing, I have a couple of ATIs and GF5200-machines running with TwinView. So help is on its way. Will post you a link to one of my XF86Config-4 that should demonstrate how to set up TwinView with them 5200-cards. Just lemme get to the office cu

addendum @OO-fonts ... gidday, just had some maintenance to do and booted into the standard MDK10 configuration as it is installed "out of the box" (original kernel 2.6.3, KDE 3.2 etc.). To my surprise the appearance of OOffice and fonts therein is much worse than in my usual environment >> compiled Kernel 2.6.5, compiled KDE 3.2.1, compiled Qt 3.3.latest. To be precise: OOWrite looks more like Xemacs As a quickshot I'd "blame" the lib-paths (which point to the newly compiled libs/binaries first in the std-working-env) for being responsible for the improved font-rendering. Might peek into that matter over the weekend to maybe find out what causes this improvement. cu

hi there, I was a bit distracted by the way some fonts looked in some applications under MDK10. After some playing and fooling around I (sort of accidentally) stumbled across the "gnome-config"-tool. I didn't think the influence of the settings there would affect the looks of my GUI much (KDE-user), but the gnome-conf-tool proofed otherwise. Maybe you check that out and divert into the "Fonts" section and have a look at the advanced settings. In my case fonts have been set to be smoothed "Black $ White" (hence no font-aa at all). So maybe this is worth a try. On a sidenote: Some other GTK-based proggies (e.g. Scintilla/SciTE) can be improved muchly by putting an exclamation mark in front of the font name. Rumour has it the font-display is "piped" through "Pango" this way. hope this helps

hey there, Firstly: Unlpug network-cable/connection to internet IN CASE PROB COMES FROM XP: in addition to what SoulNothing and DapperDan have already mentioned: I'd also blame XP first, so you should tell your friend to firstly close the "usual entrances". You haven't specified how your friend is connected to the internet, but in case this connection is established via a network-card (NIC), make sure that "File and Printer Sharing" is disabled in the respective NIC's properties (Control Panel -> Network -> the NIC in question -> Properties). I don't know XP, and if the built-in "firewall" closes these ports automatically, but it should be worth a look. Also I'd recommend a profound check of XP to see if there's any malware working in the background (a virus scanner should be at hand, and also tools like "HijackThis" have proven valuable). Besides P2P, and the things my co-posters have mentioned, disable all RDP-features (remote desktop) that might be running. These are "Netmeeting" or "VNC", just to name 2 popular ones. IN CASE PROB COMES FROM MDK: (pretty unikely) Dunno what packages your friend has chosen during installation, but you can use the drakconf-application to see what daemons/services are started at boottime, and which might allow remote access. Look out for stuff like "TightVNC", "OpenSSH" (sshd), "ProFTP" or "Apache" (the latter ones are of minor concern). You can check these settings in Drakconf under "System" -> "Services" (or similar; got a german version here). Also in Drakconf you can bring up the MDK-firewall (shorewall). Could be a good idea to use this easy-to-configure tool for a start in tightening and hardening your friend's machine. Hopefully you/your friend can get this fixed ... and: as it is so important these days: get some firewall solution as mentioned by SN & DD. For the XP-side I'd also recommend a view on the Kerio-products which are quite flexible (still though, I miss my favourite ... "where art though, AtGuard" . If you want to peek into a really semi-professional solution, take a look at WinRoute. For two years now we use this solution as (a) NAT-Router and Firewall for a parts of our internal network, and what can I say - it's kick-ass (btw. runs under W2K/P66/120MB RAM; so it's not as "hungry" as one might think). hope this helps

gidday there, it looks to me as if you are missing some necessary headers or "#includes". Unfortunately I have completely diverted from C++-programming, but as far as I can remember ostream should be declared in either "ostream"/"ostream.h"/"ostream.hh" or "stdio.h". So my best guess would be to check the source-files if all included headers are in place and match the needed version of the compiler. sorry that I can't spew out anything more specific

greetings, I don't know what RedHat exactly does to initiate the firewall, and moreover _what_ firewall it is using. But in case it's iptables then you could "search" along the bootup sequence and find out what firewall script is used to fire up iptables. Start to look for files in the "rcX.d"-directories (whatever your regular runlevel is, normallly "3"->"rc3.d" and check for files like "S99iptables" or whatever; that's under MDK here). Doing so you will find out which file is passed to iptables, containing the firewall rules.. Once you've found it, it should be easy to add 2 apropriate rules (outgoing, incoming) for uncommon ports. If the script's somewhat reasonable it should have the port-familes specified in groups anyway (like $UNPRIVELEGDED=1023:65535, $SSH_PORT=22 or something like that). In case there is no rule set for NFS (in case NFS is handeled by another "top-level"-gouverning rule) you can still launch some tool like "Firewall Builder" or the aforementioned "Firestarter" (not tested this one though) and examine the structure of their ruleset. hope this helps

@danleff before I get accused of hijacking this thread lemme just say thanx a million for the URL you posted. I followed another tut which stated it should all be done from the /usr/src directory. Could have thought of changing to the right directories myself, doh thanx again.

hey there, In reply to your questions ... a quick foreword Devices in Windows Windows presents devices to the user as an actual "mirror" of the hardware it has found being attached to the computer. That means the master-drive on IDE1 will always be enumerated as "C:", the 1st drive attached to the floppy-controller will be "A:" and so forth. If I recall correctly, this "A:,B:,C: ..."-scheme comes from something we dinosaurs call "CP/M", a forefather of what has become known (and feared as "MS DOS". At this point you can pin down the fact that this method is limited and unflexible (you only have the letters "A"- to "Z" and up til Windows NT, for example, it was not possible to assign the slave-drive on IDE-1 the letter "D:" as "D:" was reserved for the master on the IDE-2-channel ... and so on). Devices under Linux (and any other "*X"-system Whereas Windows sees every device as "hardware", Linux sees (almost) everything as a file and so handles the attached devices from a more abstract point of view. The primary IDE-channel, for example, is represented by something that (in most cases) has the name "/dev/hda". And the file "/dev/hda" is consequently a "viewport" or "shortcut" to a specific piece of hardware, in our case: the IDE-1 HDD-controller interface. The Linux filesystem As laid out above, there is no "A/B/C/D"-limitation under an *X-system. And as everything under Linux is furthermore a "file" there is consequently just the need for a single filesystem that doesn't have to be split into anything like "C:" or "D:" ... Mount-points This filesystem in Linux starts at location "/" (slash or "root") and everything we need in order to work with attached devices unfolds at certain points within the hierarchy of this root. The "mount-point" for the above mentioned "hardware-viewports", for example, reside in the "/dev"-directory and the place where all the fancy config-stuff lives is "mounted" in "/etc" ... and so on. Mounting Harddisks, harddisk-partitions and generally any form of "filesystems" are usually mounted through the "/mnt"-directory. In simple terms you just need to create a subdirectory and make some hardware "speak" through it. This is done via the "mount"-command ... mount -t vfat /dev/hda1 /mnt/windrive_c In regular language this reads like this ... "Dear Linux, include ("mount") the contents of the device that you find through the pointer in "/dev/hda1" in your global filesystem. The contents are of type ("-t") "Windows95/FAT32" ("vfat") and I would like to browse the content through the viewport at "/mnt/windrive_c)." At this point you can celarly see that Linux doesn't care _where_ you mount your drives and partitions. To include your "D:"-drive, for example, you could go either for something short and easily accessable like ... mount -t vfat /dev/hdb1 /d or you could mount the same partition under ... mount -t vfat /dev/hdb1 /linux_documents_and_settings/my_mountpoints/boy_i_really_like_typing No matter where you mount it, it will still be just some specific spot under the initial "/"-filesystem. Conclusion Speaking in "hardware"-terms, a drive with e.g. 2 partitions has 2 independant data-storage-areas which Windows would refer to with different drive-letters. Linux summarizes everything under the slash (/) at certain (mount-)points as there is only one coherent filesystem. So no matter how many drives, partitions etc. you mount in Linux .. all you get is one "huge" filesystem, and this is also all you need cu p.s.: definitely have to compile less stuff in the background! my postings get lengthy

Greetings, just can throw in some vague assumptions and thoughts: Try to obtain a "cross-reference"-OS. Something like Knoppix 3.2/3 which boots from the CD and check if you have the same errors occuring. Knoppix has quite neat hardware-detection and chances are good that it could lead you to some settings for lilo.conf/whatever.conf that might help you solve your issues. I've been fiddling here with MDK10 for a week now or so and as a quick shot I'd recommend a "nolapic"-appendage in lilo.conf in all cases. I tried varies settings there, but running the system without "nolapic" resulted in similar freezes as you described (though - just guessing here as I don't even know what chipset your mobo features). Having "apic=ht" in the append-line and keeping normal "apic" as it is showed no side effects so far. hope this helps p.s. just for fun, and while I'm at it: how the smeg do you patch a kernel when you do "patch -p0 < patchfile" and all you get is "file to patch?" - cy

Good evening folks, spent some time last weekend installing and checking out the brandnew and shiny GIMP2. You probably have already heard that the gimp-crew has stitched together something quite amazing with this quantum-leap-release. To put it in a nutshell: Gimp 2.0 kicks botty! Unfortunately the installation-procedure for the average linux-noob could get a little tricky. To limit headaches to a reasonable level ... here's a quick guideline to get the GIMP up and running on a linux-machine. Be warned though that it will take some time as you will compile <exaggeration> roughly 1.73 Whateverbytes</exaggeration> ============================== 1. Leeching the stuff ============================== Check the official download page over at http://www.gimp.org/downloads/ and choose an apropriate mirror. ============================== 2. Packages you will need ============================== It could be that you can skip one or the other package in case you have an up-to-date GNOME-machine or whatever. In my case (fresh MDK10 installation) it turned out that I needed the following ... 2.1 GTK v2.4 and supplementary stuff These are ... - glib-2.4.0.tar.bz2 - gtk+-2.4.0.tar.bz2 - atk-1.6.0.tar.bz2 - pango-1.4.0.tar.bz2 Also from the "<your_mirror>/<some_path>/gimp/gtk/v2.4"-directory get all the stuff from the dependencies-folder, which are ... - jpegsrc.v6b.tar.gz - libpng-1.2.5.tar.gz - pkgconfig-0.15.0.tar.gz - tiff-v3.6.1.tar.gz 2.2 Freetype I also sucked these two (dunno if those are mandatory, but it cant be bad if you have it on your machine in case some configure-pass demands it) ... - freetype-2.1.7 (or the freetype package from ... <mirror_server>/<path>/gimp/plug-ins/v2.0/freetype) 2.3 Additional stuff For your work later on with the GIMP it could be that you might want one/all of these add-ons - GIMP help-files (v2.0 help-fiels are still very incomplete) - gimp-print-package (which is rather heavy (~5MB) and was therefore skipped as I print images from other apps anyway) and last but not least ... 2.3 The Gimp .. in an incarnation of your liking. I picked - gimp-2.0.0.tar.bz2 ============================== 3. Installation ============================== Before you begin, meditate and tell yourself the following over and over again ... I will launch every "./configure" with the parameter "--prefix=/usr" Having said this, begin compiling and installing the packages in the following order ... 3.1 atk-1.6.0 Change to atk-dir and launch the following commands root@somehost atk-xxx: ./configure --prefix=/usr followed by ... root@somehost atk-xxx: make followed by ... root@somehost atk-xxx: make install If you want to save diskspace you can add a final root@somehost atk-xxx: make clean 3.2 freetype-2.1.7 ... is the next to compile/install. The command sequence is ... (A) "./configure --prefix=/usr", ("make", © "make install" ... and optional (D) "make clean" 3.2 Dependencies Go into the "dependencies"-folder and perform these tasks ... - pkg-config-0.15.0 commands: (A)->(->©->(D) see above - jpeg-6b ... commands: (A)->(->©->(D) - libpng-1.2.5 ... commands: (->©->(D) no "configure"! - tiff-3.6.1 ... commands: (A)->(->©->(D) 3.3 The heavy stuff Continue with these packages in the following order ... - glib-2.4.0 ... commands: (A)->(->©->(D) - pango-1.4.0 ... commands: (A)->(->©->(D) - gtk+-2.4.0 ... commands: (A)->(->©->(D) 3.4 The GIMPster And last but not least compile the GIMP itself. If you have skipped the gimp-print package then call "configure like this" - ./configure --prefix=/usr --disable-print If you have d/l it then you have to compile and install it prior to GIMP. Whatever way .. carry on with the usual "make", "make install" and "make clean". After this you should be able to behold the magnificence of this outstanding image manipulation-proggy. 4. Optional tasks for single-user-machines If you're on a single user machine you can link your personal "brushes", "gradients", "pattern"-folders to the global ones if you like. To do that ... root@machine /:cd ~/.gimp-2.0 (change to gimp-folder in your home-dir and perform something like this ... rm -f brushes; ln -s /usr/share/gimp/2.0/brushes brushes; rm -f fonts; ln -s /usr/share/gimp/2.0/fonts fonts and so on ... The folders that could be linked are ... gfig, gflare, gimpressionist, gradients, palettes, patterns and scripts. Just to be on the safe side: This is really optional and should not be done in multiuser-environments, but if case you want your stuff concentrated ... Well, hope I haven't got anything hideously wrong and that this sheds some light for GIMP-newcomers as this outstanding program is just too .. erm ... outstanding to not get it up and running evening

Success (at last)!! Greetings comrades, after intensive investigation and (almost neverending) trial-and-error sessions with MDK10 and the Radeon9600 my desktop crate is finally set up the way I intended it. I apoloigze for this posting in advance as it could get a bit lengthy, but I've spent quite some time to fix this issue, and I thought giving away a more detailled description including approaches that did not result in success might be helpful for other hardware-noobs like me. Also forgive my some occasional typos as it's late already here ... So here's a log of my activies (including "go's" and "no-go's"). ====== NO_GO: ====== Kernel 2.6.4 with "everything built in but the kitchen-sink" (phrase courtesy of J.Mullins - SOF II I compiled and tried this kernel version with all ATI-relevant things built in - these were: nForce/2-, agpgart/nvidia-agp. This lead to a very compact kernel that limited "lsmod"-output to just 2 lines ... the codepage-modules. In this setup, running the ATI-rpm produces fatal errors upon final module insertion ("permission denied"). Consequently a manual "modprobe" <fglrx.ko> produced the same result. That lead me back to the kernel MDK-10 2.6.3mdk-kernel, as delivered "fresh out of the box". >>>> On a sidenote: If you are using USB-stuff you should stick with the MDK-kernel as it seems to be patched to supports "supermount" which 2.6.4 doesn't unless you apply the appropriate patch. <<< ====== GO: ====== I booted into the standard MDK-installation as it has been installed in the first place by MDK10 and performed these tasks on the command line (so there, no "X") ... STEP 1: Prepare the setup root@machine ati_drv: rpm -Ui --force fglrx-4.3.0-3.7.6.i386.rpm (this extracts installs the sources into the proper locations) STEP 2: Build the core-module root@machine ati_drv: cd /lib/modules/fglrx/build_mod (change to dir. to build the driver-module) (optional) ... perform a ... root@machine build_mod: chmod a+x make.sh (to make the script executable if necessary. For some peculiar reason the make-files here only had the "r"-attr. for owner set) STEP 2.1: Built it root@machine build_mod: ./make.sh (this builds the core-driver-module) STEP 3: Install the driver-module root@machine build_mod: cd .. (go up one directory, this should bring you to /lib/modules/fglrx) (optional) ... perform the "chmod a+x"-command on "make_install.sh"-file if needed (see above) STEP 3.1: Perform the installation root@machine fglrx: ./make_install.sh (this builds the core-driver-module) If everything goes well up to this point, the fglrx-directory should contain a symbolic link like this ... fglrx.ko -> /lib/modules/fglrx/fglrx.2.6.3-4mdk-SMP.ko STEP 4: Checking the loaded AGP-modules Type ... root@machine fglrx: lsmod to check if any AGP-relevant modules are loaded. In my case none was loaded so I inserted the one for my mobo (A7N8X-X, nForce2-chipset) ... root@machine fglrx: modprobe nvidia-agp A second "lsmod" should now list "agpgart" which is used by "nvidia-agp". To make these settings permanent I added this line to "/etc/modprobe.conf" ... install fglrx /sbin/modprobe --ignore-install fglrx && { /sbin/modprobe nvidia-agp; /bin/true; } To be honest, I have no idea if this is a cruical thing or not, but it worked here, so I thought I just mention it Inserting the ATI-driver-module finally braught this result [tt] fglrx 204228 172 nvidia-agp 7388 1 agpgart 31016 2 nvidia-agp [/tt] STEP 5: Running fglrxconfig Now it's time to run the ATI-XF86Config-tool ... type ... root@machine fglrx: fglrxconfig and follow the steps. IMPORTANT: When getting asked whether or not to use an external AGP-module, type Y. For me this was the cruical part as the fglrxconfig-tool has "[n]" preselected and the description is a fair bit misleading, insinuating that the "internal" AGP-module would be the right thing to do (which it wasn't here). Well, before I get sued by the linuxcompatible-folks for being a forum-post-hog I call it quits at this point. Thanx again to all the folks here who replied and to the forum-crew for providing this platform. evening

Evening again @DapperDan: thanx a lot anyway for taking the time to post an answer. I'm still tracking the issue and will post some fix (in case I can find one @danleff: thx to you too for the hints. Indeed, the sound issue was caused by not having tagged the i810 driver, as I have found out from various sources on the net. According the hardware detection of MDK10: Well, the folks have hammered together a quite tasty bit of software there. Apart from the ATI frivers everything just goes peachy. Today I also installed MDK10 on a second box, same mobo but this time with a GF5200 TwinView card. And what can I say - all went super-well (still have to set up TwinView, but anyway). So all I can say is: MDK 10 eases (almost) any pain that might have come across with the cursed A7N8X-board. IMPORTANT: I'm strictly into software-development, so I have no all too fancy hardware attached to my boxes apart from the inevitable USB-sticks/digicams etc. But still, no wireless thingies, no VidGrabbers etc.etc. But as far as it goes for server-stuff and hardcore-development purposes (CVS, apache and the usual suspects) MDK10 and this board perform a nicely balanced duette. cu