Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Debian

AMD64 Surpasses i386 As Debian's Most Popular Architecture 216

An anonymous reader writes with a quick note about the changing tides of computer architecture. From the article: "Bill Allombert announced [yesterday] via the Debian-devel mailing list that the X86_64 version of Debian has now surpassed all of the other supported architectures by a narrow margin. The most surprising part of this announcement however, and accompanying info-graphics provided on the Debian Popularity Contest page, is that this was not already true."
This discussion has been archived. No new comments can be posted.

AMD64 Surpasses i386 As Debian's Most Popular Architecture

Comments Filter:
  • Not surprising... (Score:4, Insightful)

    by jaymz666 ( 34050 ) on Wednesday September 05, 2012 @09:28AM (#41234423)

    considering lots of people use older machines to install Linux on to breathe life into them, to act as servers, etc.

    • Re:Not surprising... (Score:5, Interesting)

      by bill_mcgonigle ( 4333 ) * on Wednesday September 05, 2012 @09:39AM (#41234529) Homepage Journal

      And Debian, no less. You don't pick Debian for 'new hotness'.

      I still carry i386 minimal install CD's with me, but it's been feeling odd lately to have to use them on servers. Even some of my Atom machines can handle the AMD64 instruction set. It looks like i386 (especially -proper not i586+MMX) is destined to become a 2nd-rung arch along with MIPS, PPC, etc. At the same time kernel ARM support (e.g. OMAP) is really starting to mature. It looks like the two dominant arches the not-too-distant future will be ARM and AMD64.

      • by jellomizer ( 103300 ) on Wednesday September 05, 2012 @09:43AM (#41234587)

        I actually choose Debian for servers, the biggest and fastest servers I can get my hand on. Debian isn't a desktop distribution, you got Ubuntu for that. But for a server you want a small and fast OS, You don't care much about X the server should be able to run by itself for weeks at a time and casual maintenance.

        • Debian isn't a desktop distribution, you got Ubuntu for that.

          In a professional context Debian is a perfectly fine workstation desktop distribution. With the longer cycles and better linux support of professional hardware I've never seen big issues, except maybe using a newer kernel for a brand new model. Which is no big deal to handle in a professional context. I've seen Debian deployed on hundreds of workstations with no problem.

          Even for home use I stick to Debian. Yes, the out of the box support is not as good as a recent Ubuntu. But the stock stable is usually

          • Seconded. I have been using Debian for a long time, mostly because its installation is a lot more modular than other distros and because you can find .debs pretty much anywhere. Though I have been thinking of moving to Mint on my next PC (probably Debian Edition, though). Debian stable is also great for installing on the machines of senior family members. Other than the outdated version of Firefox, they're fine. So I just install a recent version Opera or Chrome and they're good to go for a year or so (gett

        • I've been using Wheezy for the past several months for my work workstation as well as my home. No complaints and no problems. Personally, I can do without the hand-holding that Canonical has wanted to do lately. I'm not a fan of Unity and will continue to use KDE until something better comes out.
        • "You don't care much about X the server should be able to run by itself for weeks at a time and casual maintenance."

          You are thinking of Windows. With Linux you can expect years not weeks.

      • Re:Not surprising... (Score:5, Informative)

        by xaxa ( 988988 ) on Wednesday September 05, 2012 @10:03AM (#41234883)

        And Debian, no less. You don't pick Debian for 'new hotness'.

        Ubuntu has less amd64 installs than i386: http://popcon.ubuntu.com/ [ubuntu.com]

        sudo dpkg-reconfigure popularity-contest and "Yes" to join the contest (mine was disabled for some reason).

        • Re:Not surprising... (Score:5, Interesting)

          by danomac ( 1032160 ) on Wednesday September 05, 2012 @11:07AM (#41235709)

          On Ubuntu's download page [ubuntu.com] it doesn't recommend using amd64, it recommends x86.

          That's probably why Ubuntu shows less amd64 installs than x86. They could get with the times and recommend amd64 -- my 6 (or was it 7?) year old laptop even supports the amd64 instruction set.

      • by Nursie ( 632944 )

        Stable, sure. But with testing or unstable you get a fantastic OS that does have a lot of the new hotness. I've been running testing as my business desktop in a large corporate for some years now.

      • The only Atom CPUs, intended for netbook or desktop usage, that are not 64-bit enabled are the two "original" netbook Atoms, being the N270 and N280. Ever since the Atom 230 and the Atom 330 (the only two without a letter designating their usage), all Atoms are 64-bit provided they are for netbook or desktop usage, which means their model number is prefixed with N or D.

        It is true that the Atoms with model numbers prefixed with E or Z are 32-bit, but those are for embedded application (E) or "mobile interne

      • You should pick Debian for 'new hotness'.

        You also will if you're running the Debian version named Sid.

        That is in fact the version used by Mint and Ubuntu when they roll their distributions.

        So, it is in fact both hotter and cooler.

        Still read this http://raphaelhertzog.com/2010/12/20/5-reasons-why-debian-unstable-does-not-deserve-its-name/ [raphaelhertzog.com]

      • You don't pick Debian for 'new hotness'.

        I beg to differ. Sid is very current, and unlike Ubuntu (which is forked from Sid) it is continously updated.

        Disclaimer: mostly running preinstalled Ubuntu these days. Server runs Debian Testing, gradually migrating laptops and workstations from Ubuntu to Debian.

    • Also considering putting Linux on a newer system is often hit or miss in terms of compatibility.

      But 64bit CPU's like the Intel Core 2 have been out past the 5 year mark. So when they re-purpose their old systems they are now 64 bit, and for those people who use Linux on new gear are getting new PC's and almost all of them are now 64bit.

      I do find it funny how Windows and Linux, were not as graceful from the 32bit conversion to 64bit like Apple and Sun Microsystems. Both Apple and Sun released 64 bit and 32

      • by vlm ( 69642 )

        I do find it funny how Windows and Linux, were not as graceful from the 32bit conversion to 64bit like Apple and Sun Microsystems.

        I think you might not know about the alpha linux port in the mid 90s. 64 bit native kernel is not much of an issue. How the distros handle multi-arch, now that has been recently exciting.

        • by Bert64 ( 520050 )

          I was a heavy user of linux/alpha, even still have several boxes here...

          Alpha never had a multi-arch problem, it was pure 64bit from the start and not extended to 64bit later. I was also a fairly heavy Sparc user, and the state of 64bit linux/sparc support was quite poor... We had a 64bit kernel, but the userland was all 32bit and you needed a separate sparc64 compiler to build the kernel.

      • Both Apple and Sun released 64 bit and 32 bit OS's and got very little of this you cant run this 32bit app in your 64bit OS.

        Um, neither did Windows. I don't think I've seen a 32-bit app that won't run on 64 bit Windows.

        (Drivers are another matter...)

        • by Lumpy ( 12016 )

          "I don't think I've seen a 32-bit app that won't run on 64 bit Windows."

          I have plenty here. Old apps for programming older integration software, Car ECM programming, etc.... All fail under Windows X86. I have a old laptop with windows 2000 installed on it for using these programs.

          • Probably something to do with file permissions, lazy programmers writing files where they shouldn't. Have you tried running them in compatibility mode?

          • Are you sure they are 32 bit and not 16 bit, ie Windows 3.X apps? Lots of old apps are 16 bit and many older 32 bit Windows programs have 16 bit installers. 64 bit Windows tries to work around the 16 bit installer problem, but it's not perfect.
          • I remember running across some software by Sage that would only run in a 32bit environment, and some version of UPS worldship.
      • I haven't seen 64-bit versions of Windows (Vista and 7) having any problem running 32-bit applications. What I have noticed is that a number of older applications utilize 16-bit installers which 64-bit versions of Windows won't run, but many times those will lay down 32-bit executables and libraries that the OS handles fine.

        As an aside, I run the 64-bit version of Debian at home and I haven't had any issue running 32-bit applicaitons, assuming ia32-libs is installed (Wouldn't be a bad idea to inst

      • by jaymz666 ( 34050 )

        I have a couple of installs that are 32 bit, one that has been upgraded from a 333 MHz Mobile Pentium II (Thinkpad) to a Core 2 E7400, upgraded from Potato through squeeze. Only using 3GB of RAM so I haven't gone through the motions to move it to 64 bit yet.

      • by Bert64 ( 520050 )

        Windows has no problem running 32bit apps on 64bit hosts, although 64bit windows came years later than 64bit linux...

        Drivers ofcourse are a problem on windows, a lot of older hardware has no 64bit drivers and likely never will because the manufacturers have long since abandoned the hardware.

        64bit linux has no problems running 32bit binaries either, however since most applications can easily be recompiled as 64bit native, the necessary libraries required for compatibility with 32bit applications are often no

    • I built some custo routers based on Via's Cyrix CPUs (Pentium 4 equivalents) earlier this year and greatly appreciated x86 Debian. There are still a lot of 32 bit processors out there, even in newer equipment.

    • Thing is, the last x86 worth a crap was the Pentium III, and that's a bit long in the tooth these days. The power consumption was great for its day (especially the mobile edition) but today it's a voracious consumer of watts compared to any of these tiny ARM-based machines. Pentium IV machines just aren't even worth running any more. Almost everything newer is 64 bit, except Atoms. But most netbooks don't have a lot of I/O, and no PC card or ExpressCard slot, so no way to get any. Most mobile P3 laptops hav

  • by thms ( 1339227 ) on Wednesday September 05, 2012 @09:38AM (#41234521)

    How far is multiarch support, i.e. being able to install 32 and 64 bit packages along side each other, and that not just on the Intel architecture but any CPUs which support both 32 and 64bits?

    Have any other distros pulled this off?

    • by Carewolf ( 581105 ) on Wednesday September 05, 2012 @09:43AM (#41234597) Homepage

      How far is multiarch support, i.e. being able to install 32 and 64 bit packages along side each other, and that not just on the Intel architecture but any CPUs which support both 32 and 64bits?

      It has started to actually work this year in Debian and *buntu distributions (on Debian use testing or unstable). Though you should be warned: You will likely end up with duplicates of all major libraries.

      • Are you kidding? It's worked for me for ages, running Wine for several releases (just recently started getting 64 bit wine, which is annoying). Yes you get duplicates of major libraries, because the processor won't run in protected/long mode both, won't switch between them without magic, and you need application-level translation to use a 32-bit library from a 64-bit code base and vice versa.

        You need application-level translation that's fully aware of the implications between 32 and 64 bit, which means

    • Yellow Dog Linux for PPC. Some of the binaries are 64 bit, some are 32. Using rpmbuild to build your own rpm's makes a ppc64 one by default, but tarball source compiles are 32-bit by default.

  • m68k, as in Motorolla 68000 support? The same chip that went in to pretty much every mac until the power macs were released in 1992 or so? I've heard of m68 linux, but their repos hadn't been updated since 2003 or so. Or is there another popular 68k platform I'm forgetting...

    • m68k linux requires a PMMU so even many of the descendants of the 68000 won't run Linux, including some macs with 68040 processors because they used the 68040LC.

    • by Bert64 ( 520050 )

      I played with m68k linux on an amiga fairly recently, and there does seem to be some active development going on...

  • Maybe now Canonical will finally recommend 64-bit. Not only because of this, but also because Ubuntu 12.10 uses Unity3D over LLVMpipe on computers without hardware 3D, and LLVMpipe is much more efficient on AMD64.

    Going slightly off-topic, can Intel and AMD start deprecating i386, to save transistors? They could do it on stages.
    First, release CPUs where half of the cores implement i386 on microcode, and the other half implement i386 in full speed; then, release CPUs where half of the cores implement i386 in

    • by tepples ( 727027 )

      Maybe now Canonical will finally recommend 64-bit.

      How is the web site supposed to know whether the computer on which the install disc will be run supports 64-bit? If it suggests 64-bit by default, people will complain that the install disc does not boot and that they wasted 700 MB of their monthly cap.

      • by 0racle ( 667029 )
        Perhaps Canonical should recommend by default that you buy CD's from them since they can't know that you have a CD burner in your computer. Or floppies since they can't know if you have a CD drive in the machine you'll be trying to install on. Or just recommend that they'll sell you a whole new computer since they can't know if what you're going to try to install on will even run it.
        • Canonical should recommend by default that you buy CD's from them

          They provide that as an option [canonical.com] on the Ubuntu Desktop landing page [ubuntu.com].

          since they can't know that you have a CD burner in your computer.

          If a novice is trying to decide whether to download or buy, it's easy to tell whether or not the optical drive can burn CDs by looking for the CD-RW, DVD-RW, or DVD+RW logo on the disc tray. And even if not, a CD image can be turned into a bootable USB image; at least one of my machines got Ubuntu through UNetbootin. How can a novice easily determine whether a PC has a 64-bit CPU without opening the case?

          Or just recommend that they'll sell you a whole new computer

          They provide that as an option [ubuntu.com], thou

          • by 0racle ( 667029 )

            They provide that [cd's] as an option

            By Default?

            They provide that [buying computers] as an option

            Again, By Default?

            How can a novice easily determine whether a PC has a 64-bit CPU without opening the case?

            The same way games require a DirectX 9 compatible sound card. The same way that the gas station makes sure you put the right type of fuel in their car. By requiring the user to take some responsibility for their own stuff.

            The whole point of this is what Canonical offers as a default setting. If most use

    • Going slightly off-topic, can Intel and AMD start deprecating i386, to save transistors? They could do it on stages.
      First, release CPUs where half of the cores implement i386 on microcode, and the other half implement i386 in full speed; then, release CPUs where half of the cores implement i386 in microcode, and the other half do not implement i386 at all; then, get rid of i386.

      That's a horrible idea, for several reasons.

      First, they already implement it "in microcode". They implement 16-bit and 64-bit in microcode as well - no modern (ie. post-2000) processor actually implements x86 in hardware. They all implement some secret RISC-like internal architecture, and translate x86 code into that on-the-fly. Gives you the benefits of CISC and the benefits of RISC, with relatively few drawbacks.

      Second, you don't want to have different core implementations on different cores. That's just

  • by PhotoJim ( 813785 ) <jim@[ ]tojim.ca ['pho' in gap]> on Wednesday September 05, 2012 @09:58AM (#41234789) Homepage

    This isn't the most massive surprise. I run 32-bit Linux on 64-bit processors in some cases. If the machine has 4 GB or less RAM (and in some cases, 64-bit machines have a maximum RAM capacity of 4 GB anyway), then there is no point in running a 64-bit distribution. Executable files are slightly larger and there is no speed gain.

    Of course, if you have a 64-bit CPU and your machine has or can accept more than 4 GB RAM (and in the latter case, you plan to expand it to 8 GB or more at some point), it makes sense to start with 64-bit installs at the beginning. Yes, you could use a 32-bit install with a PAE kernel but it seems more sensible to me in that case to just use 64-bit Linux to begin with.

    Also, the points made above that Debian is not bleeding edge and that people often run Linux on older hardware are absolutely valid.

    I'm not the most current person, but my most modern two machines are an i7 and a Core 2 Quad. The latter is maxed out at 4 GB and so runs a 32-bit distro. The i7 has 8 GB so it runs a 64-bit. The server is an old PIII that is doing just fine on 32-bit, and the netbook is an N270 Atom so again, 32-bit.

    • by cryptizard ( 2629853 ) on Wednesday September 05, 2012 @10:42AM (#41235345)

      Executable files are slightly larger and there is no speed gain.

      That depends on what applications you are running. Things that are math heavy can run significantly faster in 64-bit mode. As an example, RSA requires modular exponentiation of very large numbers. Algorithms to do this are comprised of a number of multiplications of equally large numbers. Since these numbers are on the order of 2048 bits, they need to be chunked into machine size blocks in order to actually do the multiplication. Having a 64-bit integer size already gives you at least a 2x speedup here because you have half as many blocks. Multiplication algorithms are also not quite linear (close to n log(n)) so it really gives you a bit more speed than that.

    • Even if you are running a 32-bit OS on a machine with 4GB of RAM, you'll need to use a PAE kernel to take advantage of all the RAM. Some of the 4GB address space (usually around 400-500MB) will be reserved for things like PCI-Express so, 10% or more of your RAM is likely to be unaddressable for applications by a non-PAE kernel. This isn't an issue when you get down to 3GB or less though.

    • Estimates for performance improvements just from not having to deal with x86 range from 5 to 15%, so if you have any CPU-bound tasks you may well notice a significant difference. As well, data-shoveling tasks benefit from the increased word size.

  • The figures discussed in TFA are from popularity-contest. Debian gives you the option of whether or not to participate in that. If you do, certain information(including architecture) is sent back to the mothership. If not, it isn't.

    I wonder how representative popularity-contest users are of debian users in general, and (to the degree that they aren't) what causes the non-representative behavior?

    I know, just by way of example, that HP ships a bunch of thin clients based on their somewhat butchered version of

  • And AMD stock slips below $4 per share losing about half of its value in the last year. I've always been an AMD fan but never an ATi fan and I don't think they ever recovered after that tragic acquisition.

  • Although Debian and the chart refer to AMD64, it's really generic x86 64-bit support, not AMD-specific. I.e. even though there are differences [wikipedia.org] between AMD 64 and Intel 64, Debian AMD64 will run on both. It would have been clearer had it been named x86-64, and indeed it used to be until it was changed [debian.org] with some tortured logic and desire to give AMD credit for being first with 64-bit extensions rather than have clarity of names and purpose.
    • Yeah, and that would be favoring Intel over AMD.

      Why? Because Intel's supposed to be the "default" and AMD is only just "compatible" with it?

      In fact, AMD's the one who created AMD64, and Intel licensed it from them.

  • More interesting (Score:3, Interesting)

    by Anonymous Coward on Wednesday September 05, 2012 @10:44AM (#41235381)

    What I found more interesting is, if you look at the graphs, i386 installs are not decreasing. The rise of 64-bit installs appears to be coming either from new users or from other architectures. The level of i386 installs has remained fairly constant for the past several years. This suggests to me that people are no abandoning 32-bit builds.

  • My little headless Debian box has been running the same i386 installation since 2006, which is just as well since it's a 32-bit CPU. It's also just as well, since it usually never uses more than about 85 MB of memory. Viva la Debian!

  • amusing 64 bit PC computing only recently popular on desktop, and 64 bit clean also only recent in the realm of x86-64. I've been on 64 bit unix desktops since the mid 90s....

  • I run both 32-bit and 64-bit Debian systems and a couple of times in the last year I've encountered a problem with Large File Support on 32-bit. Not in core libs or apps but in libdca-utils (DTS audio decoder & tools) and normalize-audio (audio file volume normalizer). I reported the bugs and both are now fixed but it does show that even on a machine that doesn't have >4GB RAM it may be a good idea to run 64-bit if the hardware supports it and you expect to work with large files.

  • Really sorry. It's still x86. I downloaded several million AMD64 business card cd's last month for various personal reasons. Didn't mean to skew the statistics.
  • Am I reading that graph right that X86-64 is rising about as fast as ARM is falling? Most of the graph lines are holding fairly steady, with X86-64 rising and another brownish line (ARM? I'm having trouble reading the legend) falling at about the same rate. Considering that the Y-axis is marked in powers of 2 per increment I'm probably mis-interpreting this. On the other hand, it's certainly not stealing share from 32-bit X86. Hopefully it represents a bunch of new installs, and the year of the Linux d

Avoid strange women and temporary variables.

Working...