Well I've got the Athlon 64 up and running, as I mentioned previously, and pretty much I need another hard drive (getting kinda small), and could use newer RAM. Being a university student, who's financial aid has run out, and being in my last semester at one of the colleges leaves money quite tight however.

Anyhow, giving:

- My mobo that wouldn't work with Linux has been upgraded

- Linux support, though it might still have a ways to go (to have the same level of compatibility one might find with Windows) has come a long way in 5 or so years

- After several years on a computer networking major (and having now taken all the classes that would amount to a Linux certification); I'd feel more confident doing some things today, then I had several years ago

I'm sorta toying with the idea of switching. On the other hand, I haven't seen Longhorn (or Vista now), and might decide to upgrade from XP. Hmm...

Anyhow, I decided to take a look, and see if things could be made to work. As such, I'm pulling the ISO's for slamd64, which is a port of Slackware, but recompiled with x86-64 support

I'm keeping the Windows install on my primary hard drive, though moved my data to it. My secondary hard drive is ready to be formatted so it can dual boot; assuming this mobo doesn't give the same issues with Linux as my nForce 1 board did.

So I figure I'll need to set this up, then grab the nForce Linux drivers for the nForce 3 Ultra chipset, and then the Radeon drivers from ATI's site for my graphics card, and then apply them.

Of course, however one of the first things to test for those of us here (who game that is), is something like transgaming...as for the forseeable future people would still need to be able to run Windows games (and apps, though mostly games) under Linux.

Has someone compiled transgaming before to know if there's anything else I'll need to do after this to get things running? And plz don't say compile GTK+ as I had to do that for a class project so I could install ettercap to test the honey pot I'm making; and I still haven't got around the problems with it (though I did get passed the glib version x detected, but version y present) only to get Pango compilation probs...

I don't use any of the nforce linux drivers for my nforce3 board. Most of it is now supported in the kernel. "Forcedeth" works for nvnet. SysKonnects built-in sk8lin driver works for the marvell yukon net. i810 still works for realtek audio and I think there's another on the list that will work fine. Sata and IDE are supported also.

With transgaming, I've only installed binaries of cedega after 3.x so I don't know if you'll run into anything compiling from source.

Thanks. I guess the question then would be if there would be an appreciable performance improvement getting the nVidia drivers then. I will need to get the ATI drivers for sure, the generic radeon drivers in the kernel stuck me with 1024x768, or at most 1196x768 with 55 hz refresh (yuck, the blury/fuzzy look gives me eye pains and a headache at 55 Hz refresh). I know my monitor (and also the Radeon 9600) can support 1280x1024 x 32 bit color at 75 Hz refresh (and Linux is only using 24-bit, aka no Alpha channel), as that's what I have it set to in Windows. The monitor can support 1600x1200 at 60 Hz, but again I don't like the refresh so low. I'm gathering the ATI specific drivers will fix my available resolution/refresh settings.

Anyhow, I did get it installed (the base OS, not anything compiled on it yet). A few issues I had noticed thus far, and things some others might run into, so it might be worth mentioning.

- The default driver (and Slackware, which Slamd64 is a port of, over to the Athlon 64 instruction set) by default installs the basic IDE kernel. As I have SCSI drives, this doesn't work, and cfdisk fails with a fatal error. Going back in and selecting the adaptec kernel (my card is an Adaptec 29160 Ultra 160 SCSI card) fixes this. Some reading I have done suggests people with a SATA drive (and those installing from a USB CD drive) will also need another kernel, though some might want to research that before going ahead if they have this...

Hitting F2 gives a list of kernels one can check against to see what looks more appropriate. In my case at least, the correct kernel wasn't auto-detected.

- The first time I went through setup, it never asked me for menus beyond the first series of apps. Also when done, the lilo.conf file wasn't properly written to the MBR, and I was warned of this. Without rebooting, I restarted setup again, and this time all went as expected, it did ask me for the other packages, and did install Lilo correctly. As I selected the same exact options, don't ask me what was going on.

BTW, I do have Linux installed on a second hard drive, aka

/dev/sdb

however the boot drive (which has both DR-Dos and winXP on it is

/dev/sda

That might have something to do with the glitch, unknown.

- Ironically, the built in gigabit ethernet adapter on the MSI Neo 2-F here works fine under Slamd64, but for whatever reason Windows XP Pro wouldn't play with this, even with all drivers installed, and device manager saying all was well. This confirms it's not the mobo, but something with XP, don't know what. Anyhow, unless I switch it to the other adapter, it seems for now I'll have to move the NIC cable between the integrated NIC, and the PCI NIC I added when winXP wouldn't play with it, unless I switch Linux to the add in card.

- A bug that is mentioned in the slamd64 forums, I very much am seeing here. It has to do with shuting X Windows down (I don't have problems starting it by issuing a startx at the command prompt, as some others have), the computer goes to a black screen and locks up, requiring I hit the reset button. This of course isn't good, as without a proper shutdown the file system could get potentially corrupted.

As an interum fix, I should be able to (and can test) switching to another terminal (ctrl + alt, or was it shift + alt, and one of the function keys), and then issue a shutdown from there I suppose. Don't think it should matter too much that X is running when doing a shutdown -r now, as it should just get the kill signal with everything else. Haven't tested though.

One other note for some who might try an x86-64 version of Linux. On the browser, some are indicating that one will need to have 2 copies of their web browser, as some plugins (Macromedia Flash for instance) won't play with a 64-bit browser. For that one will need to compile a second 32-bit counterpart, where those plugins are needed. Wine is apperently the same way. And to do that, one will have had to make sure to select the backward compatible, 32-bit libraries for gcc, and issue a -m32 compiler switch (I guess during config) when compiling something for that. I haven't messed with any of this yet.

Well, after messing with this, searching for much of a day around the Internet trying to find an answer, and having asked on a coupla forums; I'm gathering this isn't too much of a go right now. Unless one has the pre-compiled binaries, which in the case of transgaming requires a subscription.

I did get the Slackware binaries to WineHQ installed, however some games, I can neither invoke from my winXP partition or install seperate. On the upside, Solitare from the Windows directory will load.

I suppose for the time being, one (unless they can get the binaries) might need to install a 32-bit Linux. Shame sort of, as

- This x86-64 install is quite fast for what I can do on it. Hell, I've even seen some BOINC WUs (though that's a pre-compiled 32-bit ap) complete in like 10 minutes

- The answer to this would be so easy if one knew what to pass to the compiler. The problem isn't that 32-bit binaries won't work, it's that this program needs to be compiled as one, Slamd64 does include the 32-bit libraries for compiling such apps, but gcc isn't getting the needed info to go use them.

Unfortuantely, as it's a new port, I guess much info isn't out there yet on this... From the end of the devs, the solution would be so easy, even if they didn't want to switch the app to 64-bit (as it'd be supporting win32 apps). Include something in their configuration script, so when the source is being pre-compiled, upon detecting an Athlon 64 with an x86-64 supporting OS, it provides a handling routine to the compiler's pre-processor telling it which headers to link up to, etc...

If the compiler was told what to do (instead of getting "unknown architecture" in the source, it could proceed from there...) In cases where the 32-bit libraries might not also be present (though several Linux 64 distros have included them), there could be a note in the README or install.txt file "you'll need to get packages X, Y, and Z, and do this, then come back..." Athlon 64s won't be going away anytime soon, and should Intel make a move to 64-bit as well at some time...

I ran Gentoo compiled for AMD64 for a while, and in the long run it was just not worth it. Some programs will not compile on AMD64 yet, no win32codecs for mplayer/xine worked and so on. When 64-bit CPUs become more common, I'll probably reinstall the 64-bit version of Gentoo. Until then I'm running good old 32-bit. (And to be honest, I didn't notice any difference in speed what so ever)

__________________
"Never bump a baby carriage out of a crosswalk unless the kid's really asking for it."

I'm currently running x86_64 gentoo as main OS, and haven't had any problems. Using only 64bit firefox as I haven't found any real need for flash etc. though I have 32bit firefox installed just in case. And all video/audio files that would require win32codecs I just re-encode to xvid/mp3 with 32bit mencoder (avail from portage). As for compiling 32bit apps, gentoo still (I think) recommends 32bit chroot environment, however I have not doen so as all 32bit apps that I really need are avail from portage as is. I'm not familiar with slakware but you should be able to setup 32bit chroot with it too. I'm bit pro-gentoo and would recommend it to anyone that knows more about linux. It takes lot more work to set up but in turn you can customize it entirely to your needs.