[arch-releng] dual arch CDs [was: A TODO draft for next installation media]
On Thu, Feb 11, 2010 at 1:29 PM, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
Is there an existing bug report on the dual architecture stuff?
I think that dual, will be for next release, there is nothing finished for that.
There is a report on it, but I don't know it offhand. The current idea I had was that we simply do all the massaging in the archiso hooks. That is, we create one CD with two different base images and two kernels. The menu items would indicate i686 or x86_64 kernels, and would choose the right aufs image for that architecture. Yes, this effectively doubles the size of these CDs, but I'm not too sure I want to ship the dual arch CDs regularly. What do you guys think?
Am 18.02.2010 00:13, schrieb Aaron Griffin:
There is a report on it, but I don't know it offhand. The current idea I had was that we simply do all the massaging in the archiso hooks. That is, we create one CD with two different base images and two kernels. The menu items would indicate i686 or x86_64 kernels, and would choose the right aufs image for that architecture.
Yes, this effectively doubles the size of these CDs, but I'm not too sure I want to ship the dual arch CDs regularly. What do you guys think?
For FrOSCon 2009, I created the CD by hand: I took initramfs images from both CDs (removed the legacy-ide one because space wasn't enough) and all squashfs images, manipulated isomounts and grub manually. I didn't need to modify anything but isomounts and grub for it to work! We should put -any packages into a separate squashfs to save some space, although I suspect with the addition of the lts kernel to core, it won't fit anymore. Another note: The squashfs author submitted lzma support to 2.6.33, but his pull thread was ignored and unanswered :(
On Thu, 18 Feb 2010 01:04:15 +0100 Thomas Bächler <thomas@archlinux.org> wrote:
Am 18.02.2010 00:13, schrieb Aaron Griffin:
There is a report on it, but I don't know it offhand. The current idea I had was that we simply do all the massaging in the archiso hooks. That is, we create one CD with two different base images and two kernels. The menu items would indicate i686 or x86_64 kernels, and would choose the right aufs image for that architecture.
Yes, this effectively doubles the size of these CDs, but I'm not too sure I want to ship the dual arch CDs regularly. What do you guys think?
For FrOSCon 2009, I created the CD by hand: I took initramfs images from both CDs (removed the legacy-ide one because space wasn't enough) and all squashfs images, manipulated isomounts and grub manually. I didn't need to modify anything but isomounts and grub for it to work!
I also find it better to keep as much the same and only differentiate where necessary (on a "higher level") the more stuff that both arches can share, the better.
We should put -any packages into a separate squashfs to save some space, although I suspect with the addition of the lts kernel to core, it won't fit anymore.
Either way, this approach should be more space efficient then Aarons proposal, right? Dieter
On Thu, Feb 18, 2010 at 6:55 AM, Dieter Plaetinck <dieter@plaetinck.be> wrote:
On Thu, 18 Feb 2010 01:04:15 +0100 Thomas Bächler <thomas@archlinux.org> wrote:
Am 18.02.2010 00:13, schrieb Aaron Griffin:
There is a report on it, but I don't know it offhand. The current idea I had was that we simply do all the massaging in the archiso hooks. That is, we create one CD with two different base images and two kernels. The menu items would indicate i686 or x86_64 kernels, and would choose the right aufs image for that architecture.
Yes, this effectively doubles the size of these CDs, but I'm not too sure I want to ship the dual arch CDs regularly. What do you guys think?
For FrOSCon 2009, I created the CD by hand: I took initramfs images from both CDs (removed the legacy-ide one because space wasn't enough) and all squashfs images, manipulated isomounts and grub manually. I didn't need to modify anything but isomounts and grub for it to work!
I also find it better to keep as much the same and only differentiate where necessary (on a "higher level") the more stuff that both arches can share, the better.
We should put -any packages into a separate squashfs to save some space, although I suspect with the addition of the lts kernel to core, it won't fit anymore.
Either way, this approach should be more space efficient then Aarons proposal, right?
Well... there's always the option of changing the kernel, but only use the 32bit userspace. I mean, all we really want is the installed system to vary, not the live one.
Am 18.02.2010 18:58, schrieb Aaron Griffin:
Either way, this approach should be more space efficient then Aarons proposal, right?
Well... there's always the option of changing the kernel, but only use the 32bit userspace. I mean, all we really want is the installed system to vary, not the live one.
I somehow dislike the idea. However, there's no technical reason not to do it: 1) 32 Bit pacman can install 64 Bit packages. 2) All post_install is done in chrooted with the 64 Bit userspace. 3) It also works as a rescue CD, as chrooting into a 64 Bit environment is always possible as long as a 64 Bit kernel is running. We could/should even make it possible to select (if a 64 Bit kernel was booted, which can be checked with uname -m) if we want to install a 32 or 64 Bit target system (we would have to generate the pacman config on the fly, should be easy). That would leave us with: - kernel x86_64 - initrd x86_64 - kernel i686 - initrd i686 - packages core-any - packages core-i686 - packages core-x86_64 - squashfs base system i686 - maybe overlay-any So we save squashfs base system x86_64.
On Thu, Feb 18, 2010 at 1:14 PM, Thomas Bächler <thomas@archlinux.org> wrote:
That would leave us with: - kernel x86_64 - initrd x86_64 - kernel i686 - initrd i686 - packages core-any - packages core-i686 - packages core-x86_64 - squashfs base system i686 - maybe overlay-any
All 3 of the "packages" things can go in one big directory anyway- the filenames are all unique since we put the architecture in the package filenames. That would make the mounting process a lot less complex as nothing would need to change between what kernel, processor, etc. you are booting up on or want to install. Only the installer would care. -Dan
On Thu, Feb 18, 2010 at 2:04 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Thu, Feb 18, 2010 at 1:14 PM, Thomas Bächler <thomas@archlinux.org> wrote:
That would leave us with: - kernel x86_64 - initrd x86_64 - kernel i686 - initrd i686 - packages core-any - packages core-i686 - packages core-x86_64 - squashfs base system i686 - maybe overlay-any
All 3 of the "packages" things can go in one big directory anyway- the filenames are all unique since we put the architecture in the package filenames. That would make the mounting process a lot less complex as nothing would need to change between what kernel, processor, etc. you are booting up on or want to install. Only the installer would care.
Eh, maybe not. We'd have two "core.db.tar.gz" files that'd overlap. It's doable, just a little more hairy than it seems. Something like core-i686.db.tar.gz and core-x86_64.db.tar.gz would need [core-*] sections in the pacman.conf
On Thu, Feb 18, 2010 at 2:16 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, Feb 18, 2010 at 2:04 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Thu, Feb 18, 2010 at 1:14 PM, Thomas Bächler <thomas@archlinux.org> wrote:
That would leave us with: - kernel x86_64 - initrd x86_64 - kernel i686 - initrd i686 - packages core-any - packages core-i686 - packages core-x86_64 - squashfs base system i686 - maybe overlay-any
All 3 of the "packages" things can go in one big directory anyway- the filenames are all unique since we put the architecture in the package filenames. That would make the mounting process a lot less complex as nothing would need to change between what kernel, processor, etc. you are booting up on or want to install. Only the installer would care.
Eh, maybe not. We'd have two "core.db.tar.gz" files that'd overlap. It's doable, just a little more hairy than it seems.
Something like core-i686.db.tar.gz and core-x86_64.db.tar.gz would need [core-*] sections in the pacman.conf
Oh man, I almost know the package manager. Whoops. Looking at it another way, just throw all the above in a single directory, and leave the "repo" bare with just the DB only. Use the single directory as a package cache and it will work (and should never actually have to download any packages). This also keeps the FTP install from needing to download packages that are on the CD. I'm sure we do something similar but this does reduce the complexity again. -Dan
On Thu, 18 Feb 2010 14:57:02 -0600 Dan McGee <dpmcgee@gmail.com> wrote:
Looking at it another way, just throw all the above in a single directory, and leave the "repo" bare with just the DB only. Use the single directory as a package cache and it will work (and should never actually have to download any packages). This also keeps the FTP install from needing to download packages that are on the CD. I'm sure we do something similar but this does reduce the complexity again.
-Dan
nice trick/hack. no catches? is this completely transparent? when installing packages, it won't try do copy packages to some other dir (and hence user more space after all) because the source is "only a cache" ? Dieter
Am 18.02.2010 21:04, schrieb Dan McGee:
On Thu, Feb 18, 2010 at 1:14 PM, Thomas Bächler <thomas@archlinux.org> wrote:
That would leave us with: - kernel x86_64 - initrd x86_64 - kernel i686 - initrd i686 - packages core-any - packages core-i686 - packages core-x86_64 - squashfs base system i686 - maybe overlay-any
All 3 of the "packages" things can go in one big directory anyway- the filenames are all unique since we put the architecture in the package filenames. That would make the mounting process a lot less complex as nothing would need to change between what kernel, processor, etc. you are booting up on or want to install. Only the installer would care.
I would create all those as squashfs images. After that, we can put them together for different ISOs, like core-i686, core-x86_64, core-any, netinstall-i686, netinstall-x86_64 - all by just modifying the isomounts file and (not) putting the appropriate squashfs images to the disc, no other remastering necessary.
On 02/18/2010 08:34 PM, Thomas Bächler wrote:
Am 18.02.2010 21:04, schrieb Dan McGee:
On Thu, Feb 18, 2010 at 1:14 PM, Thomas Bächler<thomas@archlinux.org> wrote:
That would leave us with: - kernel x86_64 - initrd x86_64 - kernel i686 - initrd i686 - packages core-any - packages core-i686 - packages core-x86_64 - squashfs base system i686 - maybe overlay-any
All 3 of the "packages" things can go in one big directory anyway- the filenames are all unique since we put the architecture in the package filenames. That would make the mounting process a lot less complex as nothing would need to change between what kernel, processor, etc. you are booting up on or want to install. Only the installer would care.
I would create all those as squashfs images. After that, we can put them together for different ISOs, like core-i686, core-x86_64, core-any, netinstall-i686, netinstall-x86_64 - all by just modifying the isomounts file and (not) putting the appropriate squashfs images to the disc, no other remastering necessary.
sounds good, but.... booting x86_64 kernel with i686 userspace, kernel modules are invalid, so maybe, should also add squashfs with only kernel modules, /lib/modules, whn booting x86_64 For overlay any, yes, but pacman.conf need to be parsed at startup, (current pacman does not support $arch in .conf). Since overlay is just 8KB, is not a space issue, can have for both archs with each pacman.conf. Another point, maybe can have a script that launch /sbin/init with linux32 wrapper, and using init=/the/script at kernel command line. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
On 02/18/2010 09:09 PM, Gerardo Exequiel Pozzi wrote:
On 02/18/2010 08:34 PM, Thomas Bächler wrote:
Am 18.02.2010 21:04, schrieb Dan McGee:
On Thu, Feb 18, 2010 at 1:14 PM, Thomas Bächler<thomas@archlinux.org> wrote:
That would leave us with: - kernel x86_64 - initrd x86_64 - kernel i686 - initrd i686 - packages core-any - packages core-i686 - packages core-x86_64 - squashfs base system i686 - maybe overlay-any All 3 of the "packages" things can go in one big directory anyway- the filenames are all unique since we put the architecture in the package filenames. That would make the mounting process a lot less complex as nothing would need to change between what kernel, processor, etc. you are booting up on or want to install. Only the installer would care. I would create all those as squashfs images. After that, we can put them together for different ISOs, like core-i686, core-x86_64, core-any, netinstall-i686, netinstall-x86_64 - all by just modifying the isomounts file and (not) putting the appropriate squashfs images to the disc, no other remastering necessary.
sounds good, but.... booting x86_64 kernel with i686 userspace, kernel modules are invalid, so maybe, should also add squashfs with only kernel modules, /lib/modules, whn booting x86_64
For overlay any, yes, but pacman.conf need to be parsed at startup, (current pacman does not support $arch in .conf). Since overlay is just 8KB, is not a space issue, can have for both archs with each pacman.conf.
Another point, maybe can have a script that launch /sbin/init with linux32 wrapper, and using init=/the/script at kernel command line.
Maybe can go all in one CD 700MB CD *.any packages in core-pkg are just about 4MB not much. One interesting thing: doing a comparation of /usr/share between two root-images shows that: usr/share/{man,info,doc,kbd} differs, but only because files are gz, or ps or html. usr/share/groff/*/font/*/DESC in i686 default paper is A4 in x86_64 is letter. From currents isos: 9.4M i686/boot (unused here: System26.map is about 1M) 211M i686/core-pkgs.sqfs 143M i686/root-image.sqfs 9.9M x86_64/boot (unused here: System26.map is about 1M) 224M x86_64/core-pkgs.sqfs 152M x86_64/root-image.sqfs 10+212+144+11+225+153 = 755M 90M work/iso/root-image.sqfs (i686) (no usr/share) 99M work/iso/root-image.sqfs (x86_64) (no usr/share) 54M work/iso/usrshare.sqfs 10+212+91+11+225+100+55 = 704 (ouch!) But removing (if not fit), manpages/infopages/docs (and not all are necessary to remove), will fit perfectly. ;) -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
On Thu, Feb 18, 2010 at 9:25 PM, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
On 02/18/2010 09:09 PM, Gerardo Exequiel Pozzi wrote:
On 02/18/2010 08:34 PM, Thomas Bächler wrote:
Am 18.02.2010 21:04, schrieb Dan McGee:
On Thu, Feb 18, 2010 at 1:14 PM, Thomas Bächler<thomas@archlinux.org> wrote:
That would leave us with: - kernel x86_64 - initrd x86_64 - kernel i686 - initrd i686 - packages core-any - packages core-i686 - packages core-x86_64 - squashfs base system i686 - maybe overlay-any
All 3 of the "packages" things can go in one big directory anyway- the filenames are all unique since we put the architecture in the package filenames. That would make the mounting process a lot less complex as nothing would need to change between what kernel, processor, etc. you are booting up on or want to install. Only the installer would care.
I would create all those as squashfs images. After that, we can put them together for different ISOs, like core-i686, core-x86_64, core-any, netinstall-i686, netinstall-x86_64 - all by just modifying the isomounts file and (not) putting the appropriate squashfs images to the disc, no other remastering necessary.
sounds good, but.... booting x86_64 kernel with i686 userspace, kernel modules are invalid, so maybe, should also add squashfs with only kernel modules, /lib/modules, whn booting x86_64
For overlay any, yes, but pacman.conf need to be parsed at startup, (current pacman does not support $arch in .conf). Since overlay is just 8KB, is not a space issue, can have for both archs with each pacman.conf.
Another point, maybe can have a script that launch /sbin/init with linux32 wrapper, and using init=/the/script at kernel command line.
Maybe can go all in one CD 700MB CD
*.any packages in core-pkg are just about 4MB not much.
One interesting thing: doing a comparation of /usr/share between two root-images shows that:
usr/share/{man,info,doc,kbd} differs, but only because files are gz, or ps or html. usr/share/groff/*/font/*/DESC in i686 default paper is A4 in x86_64 is letter.
From currents isos: 9.4M i686/boot (unused here: System26.map is about 1M) 211M i686/core-pkgs.sqfs 143M i686/root-image.sqfs 9.9M x86_64/boot (unused here: System26.map is about 1M) 224M x86_64/core-pkgs.sqfs 152M x86_64/root-image.sqfs
10+212+144+11+225+153 = 755M
90M work/iso/root-image.sqfs (i686) (no usr/share) 99M work/iso/root-image.sqfs (x86_64) (no usr/share) 54M work/iso/usrshare.sqfs
10+212+91+11+225+100+55 = 704 (ouch!)
But removing (if not fit), manpages/infopages/docs (and not all are necessary to remove), will fit perfectly. ;)
mkarchiso originally removed all the docs and info pages, IIRC. We removed that at some point, though
On Fri, 19 Feb 2010 16:15:12 -0600 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
mkarchiso originally removed all the docs and info pages, IIRC. We removed that at some point, though
the removal was removed? nice one.
Am 19.02.2010 01:09, schrieb Gerardo Exequiel Pozzi:
Another point, maybe can have a script that launch /sbin/init with linux32 wrapper, and using init=/the/script at kernel command line.
There's no need to do that, unless you want to build the kernel.
On 02/18/2010 09:09 PM, Gerardo Exequiel Pozzi wrote:
On 02/18/2010 08:34 PM, Thomas Bächler wrote:
Am 18.02.2010 21:04, schrieb Dan McGee:
On Thu, Feb 18, 2010 at 1:14 PM, Thomas Bächler<thomas@archlinux.org> wrote:
That would leave us with: - kernel x86_64 - initrd x86_64 - kernel i686 - initrd i686 - packages core-any - packages core-i686 - packages core-x86_64 - squashfs base system i686 - maybe overlay-any All 3 of the "packages" things can go in one big directory anyway- the filenames are all unique since we put the architecture in the package filenames. That would make the mounting process a lot less complex as nothing would need to change between what kernel, processor, etc. you are booting up on or want to install. Only the installer would care. I would create all those as squashfs images. After that, we can put them together for different ISOs, like core-i686, core-x86_64, core-any, netinstall-i686, netinstall-x86_64 - all by just modifying the isomounts file and (not) putting the appropriate squashfs images to the disc, no other remastering necessary.
sounds good, but.... booting x86_64 kernel with i686 userspace, kernel modules are invalid, so maybe, should also add squashfs with only kernel modules, /lib/modules, whn booting x86_64
Another problem here (I recent detected) when remounting / (aufs) won't work, ioctl32 emulation fail (seems that is not implemented) :: Mounting Root Read-only [FAIL] /sbin/mount.aufs:plink.c:223: AUFS_CTL_PLINK_MAINT: Invalid argument dmes: ioctl32(mount.aufs:1425): Unknown cmd fd(3) cmd(00004100){t:'A';sz:0} arg(00000002) on / ioctl32(mount.aufs:1433): Unknown cmd fd(4) cmd(00004100){t:'A';sz:0} arg(09f24b80) on / anyway is not an issue at least in this case. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
On Fri, 19 Feb 2010 00:34:57 +0100 Thomas Bächler <thomas@archlinux.org> wrote:
Am 18.02.2010 21:04, schrieb Dan McGee:
On Thu, Feb 18, 2010 at 1:14 PM, Thomas Bächler <thomas@archlinux.org> wrote:
That would leave us with: - kernel x86_64 - initrd x86_64 - kernel i686 - initrd i686 - packages core-any - packages core-i686 - packages core-x86_64 - squashfs base system i686 - maybe overlay-any
All 3 of the "packages" things can go in one big directory anyway- the filenames are all unique since we put the architecture in the package filenames. That would make the mounting process a lot less complex as nothing would need to change between what kernel, processor, etc. you are booting up on or want to install. Only the installer would care.
I would create all those as squashfs images. After that, we can put them together for different ISOs, like core-i686, core-x86_64, core-any, netinstall-i686, netinstall-x86_64 - all by just modifying the isomounts file and (not) putting the appropriate squashfs images to the disc, no other remastering necessary.
hmm. you lost me. why would we want this? isn't the point of creating dual arch images that you do not need separate arch-specific iso's anymore? also, to solve the ".db.tar.gz" overlap problem, isn't it possible with aufs to mount multiple folders over each other and define a preference in case filenames collide so that you get the correct .db.tar.gz? Dieter
Am 19.02.2010 09:23, schrieb Dieter Plaetinck:
I would create all those as squashfs images. After that, we can put them together for different ISOs, like core-i686, core-x86_64, core-any, netinstall-i686, netinstall-x86_64 - all by just modifying the isomounts file and (not) putting the appropriate squashfs images to the disc, no other remastering necessary.
hmm. you lost me. why would we want this? isn't the point of creating dual arch images that you do not need separate arch-specific iso's anymore?
People WILL complain about download size. Anyway, my point was to create a bunch of squashfs images and reuse them for whatever images we may want to generate.
Am Fri, 19 Feb 2010 09:23:06 +0100 schrieb Dieter Plaetinck <dieter@plaetinck.be>:
hmm. you lost me. why would we want this? isn't the point of creating dual arch images that you do not need separate arch-specific iso's anymore?
When reading this thread for a while I'm asking myself, what's wrong with the separate arch-specific iso's. I mean the user has to choose which arch he wants to install anyway. Are arch-specific iso's not more KISS? Greetings, Heiko
On 19.02.2010 12:08, Heiko Baums wrote:
Am Fri, 19 Feb 2010 09:23:06 +0100 schrieb Dieter Plaetinck <dieter@plaetinck.be>:
hmm. you lost me. why would we want this? isn't the point of creating dual arch images that you do not need separate arch-specific iso's anymore?
When reading this thread for a while I'm asking myself, what's wrong with the separate arch-specific iso's. I mean the user has to choose which arch he wants to install anyway.
Are arch-specific iso's not more KISS?
Greetings, Heiko
Having devices in my home of which only some are x86_64 capable, it definitely comes in handy to have a dual-arch CD instead of two separate CDs. In my eyes this keeps it simpler than juggling between multiple images and CDs. Also it gets simpler for the user on the download site as well as for the mirrors. Therefore, while the content of the images gets less simple, the user experience itself becomes simpler (as in improved) which is a win in my book. -- Sven-Hendrik
Am Fri, 19 Feb 2010 12:14:00 +0100 schrieb Sven-Hendrik Haase <sh@lutzhaase.com>:
Having devices in my home of which only some are x86_64 capable, it definitely comes in handy to have a dual-arch CD instead of two separate CDs. In my eyes this keeps it simpler than juggling between multiple images and CDs. Also it gets simpler for the user on the download site as well as for the mirrors. Therefore, while the content of the images gets less simple, the user experience itself becomes simpler (as in improved) which is a win in my book.
I, too, have to install Arch on both architectures but I hadn't had a problem with having two CDs. I rather find it easier. This way I know what arch I get when I choose the CD and don't need to care about the arch during installation. I also have to help people with installing Arch by telephone. This way I can send them the CD they need for their arch and have one important source of trouble less. And as Thomas has written, people who only need one arch "WILL (probably) complain about download size". i686 is, btw. only for older CPUs. As far as I know nowadays - since several years - only 64 bit CPUs are produced. At least that's what my computer dealer said. Greetings, Heiko
Am 19.02.2010 12:38, schrieb Heiko Baums:
I, too, have to install Arch on both architectures but I hadn't had a problem with having two CDs. I rather find it easier. This way I know what arch I get when I choose the CD and don't need to care about the arch during installation. I also have to help people with installing Arch by telephone. This way I can send them the CD they need for their arch and have one important source of trouble less.
No matter what we decide, generating the Dual-Arch CD is needed. So far, we always had to create these manually when we needed them: http://dev.archlinux.org/~thomas/cds_froscon/cd0809.jpg
i686 is, btw. only for older CPUs. As far as I know nowadays - since several years - only 64 bit CPUs are produced. At least that's what my computer dealer said.
There lots of Atom CPUs out there without 64 bit support. Also the Core Solo/Core Duo Laptop CPUs had no 64 bit (but now that I think about it, that was 2006).
Am Fri, 19 Feb 2010 13:11:44 +0100 schrieb Thomas Bächler <thomas@archlinux.org>:
No matter what we decide, generating the Dual-Arch CD is needed. So far, we always had to create these manually when we needed them: http://dev.archlinux.org/~thomas/cds_froscon/cd0809.jpg
Well, I wanted to come to FrOSCon but couldn't yet. So I didn't know these CDs. ;-)
There lots of Atom CPUs out there without 64 bit support. Also the Core Solo/Core Duo Laptop CPUs had no 64 bit (but now that I think about it, that was 2006).
I don't know much about the Atoms but the Core Solo/Core Duo are nowadays 64 bit as my computer dealer told me. That was what I asked him about. Or let me put it like this: I told him as a matter of course something about Single Core CPUs being 32 bit. He only looked at me aghast and told me that every CPU manufacturer only produces 64 bit CPUs since years. As far as I remember he told me, that it was indeed about 2005 or 2006 when the CPU manufacturers stopped producing 32 bit CPUs. Greetings, Heiko
Am Freitag, 19. Februar 2010 13:49:06 schrieb Heiko Baums:
as my computer dealer told me
Your dealer obviously has no idea what he is talking about. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am Fri, 19 Feb 2010 14:03:27 +0100 schrieb Pierre Schmitz <pierre@archlinux.de>:
Am Freitag, 19. Februar 2010 13:49:06 schrieb Heiko Baums:
as my computer dealer told me
Your dealer obviously has no idea what he is talking about.
I doubt that, but I can't verify it. He usually has a quite good knowledge. Greetings, Heiko
Am Freitag, 19. Februar 2010 14:08:10 schrieb Heiko Baums:
Your dealer obviously has no idea what he is talking about.
I doubt that, but I can't verify it. He usually has a quite good knowledge.
If in doubt see wikipedia or the intel homepage. Core Solo and Duo are 32 bit only. Core 2 Duo are x86_64. And only the very recent Atom cpus are. However: If I had to decide I would just provide one single iso including both arches instead of ten as we currently do. That would reduce traffic and make things easier (for users). If it does really matter if you download 300 or 600 MB you probably wont be happy with Arch anyway. (ok, there was some guy at pacman-dev who uses Arch with a 56K connection. But that shouldn't be the average user) -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am 19.02.2010 13:49, schrieb Heiko Baums:
I don't know much about the Atoms but the Core Solo/Core Duo are nowadays 64 bit as my computer dealer told me. That was what I asked him about. Or let me put it like this: I told him as a matter of course something about Single Core CPUs being 32 bit. He only looked at me aghast and told me that every CPU manufacturer only produces 64 bit CPUs since years. As far as I remember he told me, that it was indeed about 2005 or 2006 when the CPU manufacturers stopped producing 32 bit CPUs.
The Core CPU was introduced in 2005 and disappeared quickly after the introduction of the first mobile version of the Core 2 in fall 2006 (all dates from memory, no guarantee). Also, the Core 2 was never produced as a "Solo" variant. But I am pretty sure that the Atom is still manufactured as a 32 Bit CPU, at least some models.
Am Freitag, 19. Februar 2010 15:47:22 schrieb Thomas Bächler:
But I am pretty sure that the Atom is still manufactured as a 32 Bit CPU, at least some models.
Although this is going off-topic: This is true for at least the CPUs found in netbooks. The versions dedicated for small desktop devices (dual core atom etc.) support x86_64. The new Atom N450 which can be found in e.g. eeePC 1005PE is a x86_64 cpu though. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am Fri, 19 Feb 2010 13:11:44 +0100 schrieb Thomas Bächler <thomas@archlinux.org>:
There lots of Atom CPUs out there without 64 bit support. Also the Core Solo/Core Duo Laptop CPUs had no 64 bit (but now that I think about it, that was 2006).
Regarding the Atoms I just found this German article: http://www.pcwelt.de/intel_virtualnotebook/cpu/technik_trends/154029/intel_a... "Der x86-Prozessor beherrscht auch gängigen Funktionen wie die Befehlssatz-Erweiterung SSE3, unterstützt 32- und 64-Bit-Betriebssysteme und -Programme sowie die Virtualisierung in Hardware." And these specifications from Intel: http://ark.intel.com/Product.aspx?id=35641 "Instruction Set 64-bit" And here's a thread about Ubuntu on Atoms at linuxquestions.org: http://www.linuxquestions.org/questions/linux-hardware-18/intel-atom-330-ubu... So also at least the newer Atoms seem to be 64 bit CPUs. But I can't verify this. Greetings, Heiko
besides, why are we discussing new cpu's only? I'm using a 5 year old amd athlon pc and i like it just fine. I'm pretty sure there are more people who are happy with their old systems. 32bit is definitely not gone yet. not in a long shot. see how many people started complaining in april last year ;) Dieter
participants (8)
-
Aaron Griffin
-
Dan McGee
-
Dieter Plaetinck
-
Gerardo Exequiel Pozzi
-
Heiko Baums
-
Pierre Schmitz
-
Sven-Hendrik Haase
-
Thomas Bächler