You are not logged in.
It was a long time since I last made a post. I'm a little curious, I've always tried to be on the edge of technology, but so far I haven't tried arch 64 (thanks to my now ancient laptop:p). My question is twofold.
What are the major limitations to x64? Which programs won't run and what drivers haven't been ported yet? Isn't it possible to compile a list of what doesn't work instead of what does work. At least I know it would be tedious to first research whether all desired programs/drivers are actually offered to the x64 architecture before making the conversion. Perhaps such a list could be comprised into a wiki article here on arch, allowing the users interested in trying x64 to immediately discover which software is not supported. [ If such a thing already exist, I've clearly not done my homework and deserve some official flaming here ]
Secondly, what's really the deal about the lacking x64 support from software vendors? As an application developer, I've yet to come by a situation where a few minor adjustements to the code and a recompile couldn't easily offer both x86 and x64 compatible binaries? Especially considering that you basically cannot purchase anything less than a two-way symmetric multiprocessor machine.
After some considering, a new question arose. Since most modern architecture offers support for both 32-bit and 64-bit instructions (Intel Itanium aside), what stops me from running 32-bit applications on the 64-bit operating system, given that any library dependecies are also duplicated (one for each architecture).... Well, except for the obvious that Arch doesn't play nice with multiple versions of the same program. That being said, end of rant (EOR).
Last edited by toxic (2009-04-04 22:54:38)
Offline
What are the major limitations to x64? Which programs won't run and what drivers haven't been ported yet? Isn't it possible to compile a list of what doesn't work instead of what does work. At least I know it would be tedious to first research whether all desired programs/drivers are actually offered to the x64 architecture before making the conversion. Perhaps such a list could be comprised into a wiki article here on arch, allowing the users interested in trying x64 to immediately discover which software is not supported. [ If such a thing already exist, I've clearly not done my homework and deserve some official flaming here
Check the wiki. There is a section on what doesn't work yet. The last hurdle for me was Flash Player and now I don't really miss anything. Some binary only software like games doesn't run but there are solutions for those cases.
Secondly, what's really the deal about the lacking x64 support from software vendors? As an application developer, I've yet to come by a situation where a few minor adjustements to the code and a recompile couldn't easily offer both x86 and x64 compatible binaries? Especially considering that you basically cannot purchase anything less than a two-way symmetric multiprocessor machine.
It depends how well the application has been written in regards to portability. With 32 bit OSs still being the norm I have lost count of the source code I have had trouble recompiling on X86_64 because of little issues with developers assuming things like sizeof(int) == sizeof(int*).
Offline
After some considering, a new question arose. Since most modern architecture offers support for both 32-bit and 64-bit instructions (Intel Itanium aside), what stops me from running 32-bit applications on the 64-bit operating system, given that any library dependecies are also duplicated (one for each architecture).... Well, except for the obvious that Arch doesn't play nice with multiple versions of the same program. That being said, end of rant (EOR).
As I understand it, nothing. Arch has a nice multilib support in aur. But I only use it for wine at present.
I trust Microsoft about as far as I can comfortably spit a dead rat.
Cinnamon is a wonderful desktop
"Faith is the substance of things hoped for, the evidence of things not seen."
Offline
FLASH: http://bbs.archlinux.org/viewtopic.php?id=67005
Not directly related to arch at all, but Flash is a hugh issue for some. Some have this problem as decsribed in my post while others have no issues at all. Not quite sure what the problem is but its hit or miss for now.
Other than that I am happy with my Arch64
Arch64, AMD64, LXDE
Offline
Is funny, I have had flash crash my browser on i686, but on x86_64, I don't think I remember once.
I am sure there is something those who are working have in common vs those who are not working, just no one has been able to figure it out yet
Last edited by banshee28 (2009-04-05 00:51:44)
Arch64, AMD64, LXDE
Offline
I used to have flash issues when using 32bit flash with nspluginwrapper. flashplayer.bin would lockup a couple of times a day and need to be killed.
Since installing the native 64 bit flash player I haven't had one issue.
One thing I am doing different is to use the download direct from adobe and just dropping the libflashplayer.so into my ~/.mozilla/plugins directory. Can't recall why I did this but I think I had trouble getting the ABS version to work at the time. Back then it wasn't in extra. Don't think I'll change to the repo version unless I start having issues myself.
Offline
I reinstalled i686 to x86_64, and up to now everything is fine except browser pdf reader plugin.
Archlinux x86_64 on Thinkpad T400
Intel X4500MHD / ATI HD3470 Graphics, 2G RAM, 160G HD
Offline
I used to have flash issues when using 32bit flash with nspluginwrapper. flashplayer.bin would lockup a couple of times a day and need to be killed.
Since installing the native 64 bit flash player I haven't had one issue.
One thing I am doing different is to use the download direct from adobe and just dropping the libflashplayer.so into my ~/.mozilla/plugins directory. Can't recall why I did this but I think I had trouble getting the ABS version to work at the time. Back then it wasn't in extra. Don't think I'll change to the repo version unless I start having issues myself.
I tried to copy the libflashplayer.so file also and remove the older flash, but it did not change anything.
Arch64, AMD64, LXDE
Offline
I tried to copy the libflashplayer.so file also and remove the older flash, but it did not change anything.
I just checked mine and it isn't the latest version so I downloaded the latest from adobe and will try that one out as well. Haven't restarted firefox yet though. Like you mentioned, there is probably a reason this effects some and not others. Just a matter of working it out.
Offline
hi..
I would like to try out Arch64. I have a few doubts however. If I need to use a 32-bit windows app that has no linux version (runs fine under wine in 32-bit arch), will I still be able to use it under wine in arch-64...?
Will using multi-lib be like installing all the 32-bit libraries again...? I mean just having an entire arch-32 system alongside an arch-64 system....?
It takes a very unusual mind to undertake the analysis of the obvious - A N Whitehead
Offline
hi..
I would like to try out Arch64. I have a few doubts however. If I need to use a 32-bit windows app that has no linux version (runs fine under wine in 32-bit arch), will I still be able to use it under wine in arch-64...?
You must have missed this
Check the wiki.
and
As I understand it, nothing. Arch has a nice multilib support in aur. But I only use it for wine at present.
Will using multi-lib be like installing all the 32-bit libraries again...? I mean just having an entire arch-32 system alongside an arch-64 system....?
No, what you are describing is a chroot. In a multilib system only those libraries that are needed for specific applications you want to run are installed.
I trust Microsoft about as far as I can comfortably spit a dead rat.
Cinnamon is a wonderful desktop
"Faith is the substance of things hoped for, the evidence of things not seen."
Offline
I took the plunge...!
That windows software works as fine as it did on arch32 bit wine.
As far as my needs are concerned 64 bit arch works as well as 32 bit arch did..!
Thanks Kilz.
It takes a very unusual mind to undertake the analysis of the obvious - A N Whitehead
Offline
It always amazes me how far ahead this distribution really is. I must say it was a rather excellent wiki page already. To bad it seems so easy to merge into x64; where are those good old manually-apply-hack days I've grown so fond with over the years. Gone I say, gone!
Offline
Versus 32, the only real difficulty I experienced with 64 was with ALSA. Eventually gave up and went with OSS.
Arch Linux + sway
Debian Testing + GNOME/sway
NetBSD 64-bit + Xfce
Offline
3D in lib32 WINE does not work for me (nvidia binary driver). Just light gray pixels where there should be stuff being rendered.
Edit: lib32-nvidia-utils was installed. I was not aware that there was a nice big lib32 group. I installed them all, and now only it 'pretty much works'
I was unable to get Qdu working in x64 (IMO, it's the only app better than good ol' xdiskusage, which worked fine)
...and that's it. Also, some apps, like Firefox, that I didn't expect to be, are much faster.
Last edited by cerbie (2009-04-24 11:42:29)
"If the data structure can't be explained on a beer coaster, it's too complex." - Felix von Leitner
Offline
Never had a problem with ALSA on 64-bit. Not played around with WINE too much, but plan to.
Matt
"It is very difficult to educate the educated."
Offline
3D in lib32 WINE does not work for me (nvidia binary driver). Just light gray pixels where there should be stuff being rendered.
I was unable to get Qdu working in x64 (IMO, it's the only app better than good ol' xdiskusage, which worked fine)...and that's it. Also, some apps, like Firefox, that I didn't expect to be, are much faster.
yaourt -S lib32-nvidia-utils
(assuming you have yaourt and installed wine via bin32-wine)
Offline
Well multilib ./scare
Just make a 32bit chroot (described on the wiki http://wiki.archlinux.org/index.php/Arc … it_system)
It's really sweet and if you wanna startup wine etc that way i can guarantee you'll learn a thing or two about chroot and schroot.
Then you can have all your main stuff in a pure 64bit enviroment and be sure that you are only using 64bit stuff unless you explicilty don't. And if problem araise( for instance, a program doesn't exist in the repo for 64bit) just jump into the 32bit enviroment and install it there. Laters you can seamingless access the 32bit program from your 64bit enviroment with schroot
Just be sure when you are accessing the aur with yaourt that the pkgbuild supports 64bit, otherwise jump into the 32bit enviroment... if you need that particular software
This way it get's really easy to monitor the progress on the 64bit side of Linux, and imo... least messy... But's that's only cause learned how to use chroot and schroot now... In the begging it didn't feel particulary sweet
Last edited by jumzi (2009-04-12 19:16:50)
Offline
My major thing for wanting x64 systems is my RAM. 32-bit systems can only support up to 4gb total memory and that could be a problem for some. Likewise, 64-bit systems support up to 16 exabytes of total memory (read that on some computer wiki). Now, I've run 8gb of RAM on my main system and 4gb on my laptop. My server is super old and only has 2gb of RAM on it.
For applications I haven't ran into any problems with 32-bit apps on a 64-bit system. There is a program or two here and there that won't run on my system, but I'm sure if I spent enough time looking for a replacement I could find one to run on a 64-bit system. But so far, no problems what so ever and I even think 64-bit systems are faster to a degree, but that's just my opinion.
Offline