LinuxMCE Forums

General => Users => Topic started by: Hugolp on March 25, 2007, 07:58:47 am

Title: AMD64
Post by: Hugolp on March 25, 2007, 07:58:47 am
I have tried to install linuxmce now that the download page is up and running, and it keeps on saying only 386i. Are the amd64 users out of linuxmce? Is there any amd64 support planned for the future?

If I install linuxmce core in a intel computer will I be able to run the front-end from my amd64? Or even that way it is imposible?


Title: Re: AMD64
Post by: intrinsic on March 25, 2007, 08:20:58 am
Are you installing over 64-bit Ubuntu?

AFAICT all the LinuxMCE packages are 32-bit only so they probably won't play nice with a 64-bit base system, either install 32-bit Ubuntu (likelihood is you won't notice any difference anyway.), or you can install your core on a different machine and if you network boot your MD it'll run in 32-bit mode.

When the source tree becomes available it should be possible to compile against the amd64 arch.

Title: Re: AMD64
Post by: kir on March 25, 2007, 08:26:33 am
As far as I know, original PlutoHome system from which LMCE was recently forked supports only i386 arch, so LMCE got the same properties... Note that this doesn't mean that you can't run LMCE on your AMD64 CPU-powered box - this is all about the version of Ubuntu, not CPU name. So, if you have Ubuntu with i386 architecture - you can install LMCE. I also hope the AMD64-arch version of LinuxMCE will appear soon, but have no idea when it happen  :)
Title: Re: AMD64
Post by: Hugolp on March 25, 2007, 08:29:18 am
Ok. Thanks. I didnt think about Ubuntu version of course.


EDIT: Now I go and look for the ubuntu 32 bit version, and guess what? is down... its just getting very funny with servers failings this weekend. I bet you the next server I need will go down as soon as I know I need something from it XD
Title: Re: AMD64
Post by: jeff_rigby on September 19, 2007, 03:09:51 pm
OK...I'll sound petty but I'm 56 and have been involved in computers since 1985.  The I386 is a I286 with memory management and the ability to address memory above the I286 16 bit limit of 64K, that thousands not millions.  It is a 16 bit cpu not 32 bit and certainly not 64 bit.

That we have been stuck with I386 as a common denominator I blame on IBM, Microsoft and Intel.  IBM tried to correct their mistake in choosing Intel (8088 16/8) over Motorola (68000 32/16) for their PC when they bought a large share of Intel stock to push the Pentium processor out the door, the first true 32 bit processor out of Intel.  Motorola at the time this happened had already run thru the 68000 (32/16), 68030 (32/32) and 68040 (32/32 with memory management) and had a line of support chips for industrial applications like 100 million 16 bit samples/sec DSPs.  What did we get with the Pentium, very fast math but extremely slow real world abilities as it was a RISC and memory was slow at that time. 

Current CPUs now have more instructions in them so that they can handle multi-media.  So we now have a hybrid RISC/CISC.  with extremely large cache on chip, possibly the best of both worlds.  But many of these advanced features are not being used because we still have that crippled common denominator I386 as the standard.

I am not criticizing the developers of Linuxmce for using the common denominator as this makes sense considering their limited numbers and the work involved in development.  That they have said there will eventually be compiled 64 bit versions of kubuntu and linuxmce is farsighted of them.


Title: Re: AMD64
Post by: colinjones on September 19, 2007, 11:19:14 pm
jeff_rigby - I agree with your sentiment, although it does seem to be a bit of a random rant... :) but I note there is nothing RISC about "i386" architecture, and the working definitions of RISC/CISC are somewhat meaningless these days anyway. The only RISC i386 Intel chip was the Pentium Pro where Intel slapped a hardware virutalisation engine on top of a RISC processor to make it code compatible with i386, then realised their mistake in that it was insanely expensive and kludged down the speed benefits of RISC so much that they never went back to that method. By that stage the ideals of 1 instruction per cycle were starting to be achieved by technologies such as superpipelining, branch prediction, out of order execution, multipath execution pipelines, and as you say, caches... shame really!

But I'm not sure that it is fair to say that the developers have chosen the "common denominator" - the ideals of open source projects are that they make the code hardware independant, as Linux base is already. The only problem here is that the people that have done the REALLY heavy lifting for LinuxMCE (Plutohome and Paul) have had reasons of either focusing on their own product or personal bandwidth to deal with that have slowed the process of the actual source code tree being made available. As soon as it is available, like any other open source product you can compile it for anything you please! And from monitoring the developers forum, it sounds like they are getting themselves organised to achieve this....