Hmm, i'm confused here, and i might have made a mistake...

The last time i made a cpu switch like this was the jump from 16bit to 32bit, and from what i can remember, you can't run 32bit code on a 16bit OS.

I've installed Slack 10.1 (32bit) on this Mobile Athlon 64, and had a default 2.4.x kernel.. But i upgraded yesterday to 2.6.12.2, and switched the processor family to "Opteron/Athlon64/Hammer/K8". Does this mean now that my kernel is 64 bit? or my linux is a 64bit OS? Regardless of the apps still being 32bit... Or am i missing something big here... If so, then what would i need to do?

Because i keep downloading x86_64 packages from LP, and none of them seem to work.. they keep giving me errors such as .

And to be honest, i don't really like switching to Slamd64 because.. well, i don't trust or like them unofficial distros.. I'd rather fix the issue myself, and slowly upgrade the apps i use most.

Thanks.

The AMD64's support both 64bit code and 32bit. Your system and programs are 32bit (unless slackware release a 64bit version that I'm un-aware of). I'm assuming that when you compiled it, you would have copied arch/x86_64/boot/bzImage which would be a 64bit kernel (that was built from a 32bit gcc toolkit).

Most 64bit distro have two /lib directories. /lib is for 32bit code, and /lib64 for the 64bit code. It is possible that your problem lies with the system's libraries however that error wouldn't lead me to that. I'll assume that you've check to make sure /usr/bin/gimp does indeed exist.

There might be a more elegant answer than what I've given. The 64 bit platforms were just too many headaches for me, so I just sold mine.

Yep, Just what i also thought. So what i assumed i could do is compile the kernel, enabling 64 bit, and have "linux" as 64 bit. The system (Slack and the applications), i can slowly replace one by one when needed.

Erm, nope.. you've lost me there.. All i did was a typical
make && make modules_install && make install && reboot.

Gimp is installed, and the error happens with any other 64bit app i install. I didn't know about the /lib64 dir.. And ls / doesn't show me any. Hmm, how would i go in sorting that out?

hehe.. well headache or not, and i guarentee you its the 'headache' part, i'd love to make use of this processor.

Thanks.

To go from 32-bit to 64-bit is tricky. I got as far as my own toolchain and most of the raw packages before finding Slamd64, and frankly, it was the best thing I did for my sanity.

Anyway, there are 3 issues at work here. I will explain my experiences & understanding as best I can and go from there!

* The chip. AMD64 is a cunning architecture plan - instead of starting again from scratch and making a whole new CoolChip©, they've made an x86 instruction set extension (to support 64-bit), increased the size (and quantity) of the GPRs (general purpose registers) and thrown in some other bits & pieces for good measure. For a more detailed description of what's going on, and many other useful bits of info head over to arstechnica: http://arstechnica.com/cpu/03q1/x86-64/x86-64-1.html

AMD64 does not emulate 32-bit instructions, it actually parses them natively. This is important, because it means you can run 32-bit code under a 64-bit-native-kernel. So-called "compatibility" - confusion.

* The kernel. So you've got this 64-bit chip, and wanna run at least the kernel in 64-bit mode. Cool.

Nuh-uh. Not cool.

The definition of a "computer architecture" can be summed up by it's instruction set. Different instruction set, different architecture. Thus x86_64 is not i486. So, when you select make menuconfig and set your kernel to AMD64, you're just telling the kernel-config that you have a 64-bit processor and to enable some extra stuff (like the on-board AGP bridge) and probably a few code optimisations for i486.

*UNLESS*

You have a 64-bit compiler.

If you run make menuconfig with a 64-bit compiler, you'll find that your kernel is actually being compiled in 64-bit bytecode; otherwise you've just got a well-informed 32-bit kernel. Not the same as a 64-bit kernel

* The programs. Since AMD64s run 32-bit code natively, then you can (assuming you have the right libraries and such installed) just run your 32-bit apps in a 64-bit environment (ie: your kernel is 64bit). This is called a "bi-arch" system. As in, two-architectures. What you cannot do is run 64-bit apps in a 32-bit environment.

Slackware is a mono-arch system. That is, you compile everything as 32-bit. You install only 32bit packages. Debian Pure64 aims to be a mono-arch system. Everything is compiled as 64-bit and your native install is 64-bit. *However*, because the AMD64 is a bi-arch chip, you can run 32-bit apps in a chroot (change-root) environment. You fool your native bash-prompt into thinking it's in a 32-bit environment, and then you run the 32bit app. Instead of having /lib and /lib64 (for example) you have /lib (for your native 64-bit libraries) and you have /32bit-environment-directory/lib (for your 32-bit libs) and so on.

Both SuSE and Slamd64 are bi-arch systems (probably Fedora, too, idk tbh) which have store 64-bit libraries in /lib64 (/usr/lib64 etc etc) and 32-bit libraries in /lib . Running native 32-bit apps is no harder than on a 32-bit system.

So, hopefully you've a better idea of what's going on now - let's deal with some more specific issues and try to debunk some of those myths you have!

Almost, but not quite. You see, unless you have a 64-bit compiler (or actually in your case, a 64-bit cross-compiler), your kernel WILL be 32-bit. Well-informed 32-bit, but 32-bit nonetheless.

Currently when you make your kernel, you copy the kernel out of /my/kernel/source/arch/i386/boot/bzImage and put it into /boot/vmlinuz. I think the kernel script does that for you, infact. You cannot build a 64-bit kernel with a 32-bit toolchain (referred to above as a "32bit gcc toolkit", the toolchain is the combination of binutils, gcc and glibc. For a kernel build you don't need a fully-featured gcc and if memory serves, only a raw glibc, but binutils is essential).

You've installed a 64-bit compiled Gimp, probably made using Slamd64 as a base. Bash is telling you your kernel doesn't recognise the 64-bit instructions that you're trying to give it. You can check what sort of files you've got by using the command: "file"

I suspect copy-pasting those commands will return you lots of sym-link information, but if you locate an actual file (not a symlink) then it will say something like: "32 bit binary executable, stripped" or similar. (Play with it on libraries, too, they can be 32 or 64 bit)

The next problem is drivers. If you have a 64-bit kernel with a 32-bit Xorg, and you want to run your fancy GLX drivers compiled from nVidia/aTi/etc then you're going to have problems. You see, the 32-bit Xorg will be expecting a 32-bit driver; but you don't have a 32-bit kernel, so your toolchain (assuming it's a bi-arch 64-bit toolchain) will not compile you a 32-bit driver: it will give you a 64-bit one.

And that's only the easy end of the problem

You will find that to upgrade one step at a time is going to be difficult if you want your machine usable in between those stages. Like I said, I managed to get as far as making packages for a hacked 64-bit Slackware, so I can give you some advice on making the toolchains, but unless you have near-infinite patience and a lot of spare time, I would recommend you just try Slamd64 before you dismiss it with "another unofficial distro".

A pleasure enlightening you, as always, xushi =)

- Piete.

normally a
should show you the installed kernel-version.
For example a SuSE 9.3 64bit:

Linux 2.6.11.4-21.7-smp #1 SMP Thu Jun 2 14:23:14 UTC 2005 x86_64 x86_64 x86_64 GNU/Linux

lol... very well said piete and musicman_ace.

Well, i guess i'm down to 2 types of questions really...

1) Being "Slackware". I don't suppose i can take the toolchain, kernel, xorg, and other packages from Slamd64, stick them here in Slack 10.1, and expect it to work.. can i?

2) Just incase i did, I didn't mean to offend with the "unofficial distro" remark.. Is it really that worth it? Does it look
- Stable, as slackware is
- Rapid development and updates
- It will last
Does it have the same Slack community (i.e., this one).. I mean can i come here with certain problems and ask?

And shouldn't PV really be focusing on a 64bit transformation of slackware ?

Thanks all.

EDIT
======
And i probably know the answer, but i just want to hear it ) lol
How's the speed/performance increase going?

I don't profess to knowing everything there is to know about Slamd64 - only what I've gleamed from an email or two to Fred Emmott and some other messageboard posts. So, please don't take any of this for gospel, and do some extra research on your own. I'm bias, because I like Slamd64. I think if you're prepared to try it, you can come to your own decision.

With that said, here are some things for you to chew over.

In doing so, you'd end up with Slamd64 ... it'd be no different than just installing Slamd64, but it would be a lot harder!

Fred Emmott (the Slamd64 d00d) basically took Slack 10.1, recompiled it for the x86_64 architecture and whacked it back on an installable disk. He replaced/upgraded a few packages to provide better x86_64 support, and added an extra category "C" for compatibility libraries. A lot of what you regard as "Slackware" will be identical. The bootup scripts, pkgtool, the locations of stuff ... it's all the same, just the programs are likely a little newer and 64-bit.

No offence taken =)

Depends on what you want. 64-bit runs faster on compiles and the 64-bit kernel definitly boots faster (in my twisted mind, anyway). The other programs *probably* run quicker, but, frankly, you won't see it unless you're doing hardcore computation (since obviously a 64bit FP calculation can be done easier with 64bit registers): so video encoding & imaging (fourier transform, cosine transform, etc) and ... other stuff that I can't think of right now.

I'm a born tinkerer, so I found having a new architecture to play with amazingly stimulating and I wouldn't give it up for the world: but for anyone who wants to just load 'n' go, then 64bit really isn't that well supported yet. Give it another 2 - 3 years and perhaps it will have matured, but at the moment, it's too new & too many things are likely to cause problems.

In short: you will gain performance, but probably won't notice it for daily use.

Because of the newer hardware, it is currently not as fundamentally stable as Slackware. x86_64 architecture is still a fundamentally unstable beast compared to the years of burn in on x86 machines. So, many of the programs that are being released with code optimisations (or even just x86_64 in the configure files) are newer and therefore less tested. If you are going to run Slamd64 on a server that needs to be up for 3 years with low maintenance, you probably need something else ...

... if you're going to run Slamd64 for a week non-stop with some gaming involved and some hardcore animé watching, then you will be glad of the extra power provided for mplayer for your sweet, sweet videos (except the WMV/RM/QT which don't have 64-bit versions yet) and will revel in the fact that your box is running to capacity with coolness installed.

I'm fairly certain it follows the development of Slackware, but I think this is something you might want to ask the d00ds at Slamd64 themselves. Just discovered this regarding Slamd64 packages, which might put your fears to rest:

http://forums.slamd64.com/viewtopic.php?t=25

From the 3rd post in:

[quote]- It will last/quote]
As long as Slackware is being updated, Slamd64 will be updated - to my knowledge. Even if Slamd64 stops, but Slackware continues - you can use the slack.Build scripts to make proper 64-bit packages of Slackware stuff, and then just upgradepkg with them =)

I would be willing to bet 90% of your problems (of anyone's problems) will be generic slackware related. That is to say, most Slackware users will be able to help you so long as you bear in mind the differences between Slackware/Slamd64. And you've always got me to lecture you should you need it

Board looks to have recently gone up: http://forums.slamd64.com/index.php
I only joined today =)

This is something that got hammered out *a lot* before I started playing with 64-bit Slackware, but I'm having problems finding those discussion threads now. I think Pat has no intention of moving to x86_64 until the architecture has matured (I know it's what I'd do), but I can't presume to speak for him.

Just fishing around the linuxquestions site I dug out this thread:
http://www.linuxquestions.org/questi...t=slack+64+pat

Which seems to indicate that Pat was working with Fred to release Slamd64. It'll never be official (Slamd64, I mean) since it isn't an exact duplicate of Slackware (see the aforementioned package change issue).

*whew*

Basically, if you've got time, whack it on your box and try it. If you don't like, don't use it =)

-- end essay --

- Piete.

lol.. you sure do like to point out everything and completly satisfy a user.. don't you

Well thanks. I'm satisfied now. And i'll give it a try. Especially now that i know Pat won't be releasing Slack 64 for atleast another year or two.. And its better than switching over to a completly different distro.

* downloads the ISOs. See you on the other side.

Hmmmm, I've yet to try out slamd64 on my 3200+.......Maybe something to do today, besides clean up the house. I sure would like it for 64-bit mplayer. Is encoding *that* much faster? Cause I got about 300+ hours of anime, simpsons, family guy, ATHF, Ren&Stimpy, King of the Hill, and other stuff that I want to encode all of them. Plus I'll have 3 boxen dedicated to it.

I'd love to encode.. or to be more precise, rip and copy my DVDs (legally.). I have some very rare and expensive DVDs that i don't want to scratch, let alone even open...

But i could never really perfect the encoding and transcoding in linux.. even the guides in LQ weren't that perfect, didn't produce a perfect disk, or didnt rip properly sometimes..

But anyway, in answer to your question, from what i read, yes you'll get a big difference. But you'd better hear it from a person who'se actually tried it.

Anyway, i got all my configs and home folder backed up.. its just a matter of reinstalling and sticking them back in. Shouldn't take more than an hour. If the worst happens, a simple reinstall of Slack and recopy of the configs over should bring everything back to normal.

/me wonders if still have left over partition or did he kill it when install 10.1?

Its not very hard. This is what I used for Ghost in the Shell: Stand Alone Complex:

mencoder -ovc xvid -oac copy -xvidencopts pass=1 SAC1-001.vob -o /dev/null -ofps 24
mencoder -oac mp3lame -lameopts vbr=3:br=128:vol=5 -ovc xvid -xvidencopts pass=2:bitrate=700 SAC1-001.vob -o SAC_ep1.divx


There's also a "cartoon" flag that since cartoons are less quality and not very "action" intesive usually it helps with size of files. quite handy.


holy crap I didn't know doing "/me" like irc worked in here! wow thats sweet.

Oh and you can rip and copy your dvd's legally. You're can make at least 2 backups. Its in the law.

/me ponders

Maybe I won't be installing today. The torrent is 2G's. Hope it's one DVD iso image. Probably not so lucky though. This plus my soon to be shipped WD 10,000rpm sata drive would be screaming fast. I suppose I could start my server and laptop encoding stuff while I wait.

The torrent comprises of a folder with the 4 iso CDs. You can opt not to download the other three with Azureus.. but i tried the torrent and the speed is horrible.

I downloaded it from the belgian mirror. 250k/sec speeds. Unfortunately i only have 1 empty CD here..

I guess its slightly different depending on which country you're in.. But i don't care anyway. I just want it to work

Ok... all i can say is, GOD DAMN! It took 7 installations for me to barely make it through. I keep getting segmentation faults in the installation.

The first time, it asked me which partition i wanted to use, but it got screwed up there, and showed me in the summary,
(IN USE) / Default
/hda3 /home
/hda1 /

hda1 is / but it listed it twice. Installed everything in less than 5 minuts, said it was finished, then gave me a seg fault saying it couldn't find any linux partitions...

the next few were random seg faults here and there. I decided to delete my partition and create a new one, but that didn't help. Afterwards i went for a bare minimum installation, it installed one or two apps, then gave an error saying my partition is full.. its a 20 gig partition..

so i deleted it again, and started over, but with REALLY bare minimum... Just A, L and a few more things to keep it alive.. and it finally went through.

Other than the seg faults, there are a few minor issues with the installer.. Firstly, i think cfdisk is different there.. The partition type #83 is stated as "swap / Solaris". I never saw that before. Incidently, when you add a swap in the setup, it also says swap/solaris.

when booting from the cd or after lilo into the OS, the laptop's lcd's brightness is reverted back to its lowest brightness.. (annoying)

when formatting, ext2 now is highlited as the default FS of choice.. afaik, it used to be the bottom one.

the installer states that elvis is required.. i dont recall that being a required package.

lynx isn't there anymore.

ppp and either bind or dns give errors when installing, but are too quick for me to read..


But i'm impressed.. its very, very fast now, and i'm gonna see if its stable or not. I thought maby my problems were because of a faulty cd or bad iso.. but i just used pkgtool to install most of the missing packages, and it did so without a problem.

And sorry if any of this might look really weird. I'm on links at the moment.. X is giving me font errors..

anyway.. brb soon.