×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

AMD64 Surpasses i386 As Debian's Most Popular Architecture

Unknown Lamer posted about a year and a half ago | from the big-versus-little-endians dept.

Debian 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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

216 comments

Not surprising... (3, Insightful)

jaymz666 (34050) | about a year and a half ago | (#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... (4, Interesting)

bill_mcgonigle (4333) | about a year and a half ago | (#41234529)

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.

Re:Not surprising... (3, Insightful)

jellomizer (103300) | about a year and a half ago | (#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.

Re:Not surprising... (1)

Anonymous Coward | about a year and a half ago | (#41234937)

Meanwhile, in real life, Ubuntu Server is actually a server.

Re:Not surprising... (1)

MightyMartian (840721) | about a year and a half ago | (#41235797)

I still favor Debian over Ubuntu on the server. I had sOme odd problems with Apache on Ubuntu a few years ago that clearly camfrom some of the install options. Moving to Debian seemed to sort it out.

Re:Not surprising... (1)

YoopDaDum (1998474) | about a year and a half ago | (#41235207)

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 ok to start (with some limitations). Then grabbing a more recent kernel from backport, or maybe testing/unstable, was always enough to have perfect support in my limited experience.
And then I can benefit from a very stable distribution, where the package maintainers have a personal interest in their own packages. And from my admittedly limited experience outside Debian this makes a difference. I've been frustrated with some commercial distros I tried long ago with some packages that were half-broken. I'd rather have to fiddle a bit at first, but then be able to depend on good packages than having a nice install with bad surprises later on.
That's not applicable to all, and to each their own, but if you are a bit linux savvy you may want to try it.

As a side note, I've recently I've seen people lamenting the lack of stability on linux compared to other OSs (can't remember if it was /. or HN...). They always compared fast moving linux distros to slowly moving other OSs. Well, if you want stability with linux pick a slow moving linux distro! For professional use I've found you don't need a bleeding edge distro, and neither for personal use as far as I'm concerned. Every person will likely need a few different bleeding edge tools for sure, but that's easy to handle (backport, side installs...).

Re:Not surprising... (1)

Mordok-DestroyerOfWo (1000167) | about a year and a half ago | (#41235257)

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.

Re:Not surprising... (4, Informative)

xaxa (988988) | about a year and a half ago | (#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... (1)

jawtheshark (198669) | about a year and a half ago | (#41235557)

I'm not 100% sure, because I haven't installed using optical media in ages. Ubuntu doesn't enable the popularity contest by default, nor does it ask. If you want it, you have to enable it on purpose (the way your did, or using the GUI, somewhere in Update Manager Settings).

If you use PXE install (or alternate install using the CD, which is basically the same), I think it asks you. Debian definitely asks, regardless of installation method... well, ok, not if you use debootstrap. PXE isn't already very common for the normal mortal, so I'd expect debootstrap to be used even less ;-)

For the record, if it asks me and it's one of my personal machines, I enable popularity-contest. I should check my debootstrap created machines, though... I don't think I did it there.

Ah, and do keep in mind how the Ubuntu website directs you to what you have to download. If you "don't know for sure", it directs you to the i686 version. So, someone trying Linux with not too much knowledge about computers will use the i686 version. At least, last time I checked the Ubuntu website, it was that way.

Re:Not surprising... (1)

aliquis (678370) | about a year and a half ago | (#41235823)

Many distributions recommend ix86 for whatever reason.

Can someone who is experienced with binary distributions tell me whatever the binaries are still compiled to take advantage of newer processors (like more registers) and just using a least common instruction set or whatever they won't use whatever they could had used on newer processors except doing 64 bit instructions?

Re:Not surprising... (4, Interesting)

danomac (1032160) | about a year and a half ago | (#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.

Re:Not surprising... (2)

Nursie (632944) | about a year and a half ago | (#41235169)

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.

Re:Not surprising... (2)

jawtheshark (198669) | about a year and a half ago | (#41235451)

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 internet devices" (Z). I'm sure you can get them, but it's much much harder. Interestingly these Atoms are those that support hardware virtualization, which I always found odd. The first Atom desktop CPU to support hardware virtualization is the D2700, which is a very recent one. (Do note, software-only virtualization works. I have a Windows XP VM in VirtualBox on my 330-based Linux desktop)

So, I don't find it all that surprising that most Atom CPUs you encounter are 64-bit enabled.

Re:Not surprising... (1)

jellomizer (103300) | about a year and a half ago | (#41234537)

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 bit OS's and got very little of this you cant run this 32bit app in your 64bit OS. Now Linux is a lot better then Windows but still, they just didn't quite think threw the process.

Re:Not surprising... (2)

vlm (69642) | about a year and a half ago | (#41234813)

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.

Re:Not surprising... (1)

Joce640k (829181) | about a year and a half ago | (#41234819)

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...)

Re:Not surprising... (2)

Lumpy (12016) | about a year and a half ago | (#41234851)

"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.

Re:Not surprising... (1)

Joce640k (829181) | about a year and a half ago | (#41235467)

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

Re:Not surprising... (2)

washu_k (1628007) | about a year and a half ago | (#41235515)

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.

Re:Not surprising... (2)

HAKdragon (193605) | about a year and a half ago | (#41235147)

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 install this by default (a la SUSE) or at least prompt during the install).

Re:Not surprising... (1)

jaymz666 (34050) | about a year and a half ago | (#41235373)

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.

Re:Not surprising... (1)

MightyMartian (840721) | about a year and a half ago | (#41235739)

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.

Very slow news day (0)

Anonymous Coward | about a year and a half ago | (#41234481)

what an utterly pointless tidbit of information.

Re:Very slow news day (1)

jellomizer (103300) | about a year and a half ago | (#41234629)

Why? If you are writing software, you now know that we crossed a point where 64bit is more common then you will make your programs take more advantage of the 64bit systems.

Most people design software for last generations systems, because that is where we will have most people using it. Knowing that 64bit is becoming the majority that means we can take more advantage of the new system.

Re:Very slow news day (2)

bluefoxlucid (723572) | about a year and a half ago | (#41234815)

you mean not confusing long int with int in C programs? Which, by the way, is WRONG, but works on i386 because sizeof(long) = sizeof(int) whereas sizeof(int) may be sizeof(uint32) while sizeof(long) is sizeof(uint64) on amd64. In C, long long >= long >= int >= short >= char. On one platform long > int, and on another long = int.

Here's a tip: say what you god damn mean; if you want a long int, declare a long int instead of just an int. If you want a short int, declare a short int instead of just an int. If you declare just an int, declare just an int everywhere where that interface is going to come into play.

Programmers do a lot of allocating something big and shoving it into something generic, and it works because the generic thing is also big. But then they change platforms and the generic thing is now big but the big thing is now HUGE, and they put something HUGE in the big thing and then copy that into the generic thing and lose half of their storage space and get weird values out and the program doesn't work. Programmers think the computer should understand what they mean, not what they say, especially when it's "always been that way before." Like being in the midwest and asking for a coke, and you get a pepsi--because coke means soda. Go out east coast and ask for a coke and they're like... we have pepsi, is that ok? People are like, what? Yes that's what I said, what the hell? Programmers have this happen on computers and don't know why it breaks.

Re:Very slow news day (2)

tepples (727027) | about a year and a half ago | (#41234823)

you now know that we crossed a point where 64bit is more common then you will make your programs take more advantage of the 64bit systems.

What is the practical advantage of 64-bit code for processes whose working set is far smaller than 2 GB? Do the extra architectural registers in x86-64 really make that much difference in practice?

Re:Very slow news day (2)

Circuit Breaker (114482) | about a year and a half ago | (#41235179)

> Do the extra architectural registers in x86-64 really make that much difference in practice?

For tight computations, they do. Most people run memory and i/o bound loads, so the memory overhead (64-bit pointers instead of 32-bit pointers) tend to cancel that out, and you only see modest speed gains.

And the 2GB limit of addressable memory is much more than a working set limit; it's easy to hit a fragmentation limit if you "only" need 1.5GB with some workloads. And the ability to mmap() every file and let the OS handle caching etc for me is also something I miss when I need to do 32 bit work.

Wow! (0)

Cute Fuzzy Bunny (2234232) | about a year and a half ago | (#41234493)

Simple news is so....simple! Last year the most common 10 year old computer was a 386. This year the most common 10 year old computer is an AMD sled?

Really eye opening. Was some AMD fanboy trying to make a point or did someone post this pre-coffee?

Re:Wow! (0)

Anonymous Coward | about a year and a half ago | (#41234505)

I don't think i386 and AMD64 mean what you think they mean...

Re:Wow! (4, Informative)

AliasMarlowe (1042386) | about a year and a half ago | (#41234667)

You should check up on PAE kernels [wikimedia.org].

Microsoft's flawed implementation (or lack of implementation) of PAE modes means that 32bit Windows can access and manage only 4GB of address space in total, even on a 64bit processor. Linux, BSD, and others implemented PAE correctly, and 32bit Linux can access and manage 64GB of RAM on a 64bit machine. Since it is rare for a single process to require more than 4GB of its own address space, there is not much reason to migrate from i386 to amd64 on Linux. On 32bit Windows, however, the total address space of all processes including the base OS and hardware I/O space cannot exceed 4GB. Hence the rapid shift from 32bit to 64bit in Windows, but the much more leisurely migration on Linux and BSD.

PAE has worked fine on Windows Server (4, Informative)

tepples (727027) | about a year and a half ago | (#41234881)

Microsoft's flawed implementation (or lack of implementation) of PAE modes

PAE has worked fine on Windows Server [microsoft.com]. Microsoft just disables PAE on 32-bit client operating systems because developers of drivers for desktop PC peripherals have been even slower to make their drivers PAE-clean.

Re:PAE has worked fine on Windows Server (0)

Anonymous Coward | about a year and a half ago | (#41235033)

In other words, the vast majority of windows installations don't support PAE, right?

Just want to make sure here, since regular desktops now have more than 4 GB of RAM.

Re:PAE has worked fine on Windows Server (0)

Anonymous Coward | about a year and a half ago | (#41235115)

What kind of new computer with more than 4GB of ram isn't running a 64 bit os? GET THE FUCK OUT OF HERE WITH YOUR BULLSHIT

Re:PAE has worked fine on Windows Server (3, Insightful)

Anonymous Coward | about a year and a half ago | (#41235679)

Yeah

This is actually an example of Linus being right to push for drivers to be source code which lives in his kernel repository, not binaries you get on a CD with the product.

When Linux went 64-bit, Linux developers went through the drivers and replaced stuff that said "Yeah, I can just use any hardware address, I have 32-bit DMA" with code saying "Is this address suitable for 32-bit DMA? If not, I will use a bounce buffer like shitty ISA drivers used to". They ripped out any code that crammed hardware addresses into a 32-bit integer, and so on.

Then when new drivers were submitted they rejected ones that showed no sign the author had done the same work.

So for end users the effect was that most drivers just worked, and of course because it's Free Software any which somehow didn't could be fixed quickly. Whereas over in Windows land it's ten years since 64-bit went widespread and they're still having this problem.

Re:Wow! (1)

jellomizer (103300) | about a year and a half ago | (#41234687)

i386 and AMD64 are architecture not the manufacturer.

Intel Architecture won the i386 so AMD back in the days kept compatibility for that design.
AMD Architecture win the AMD64 (for 64bit vs the Intel Itainium) so future versions of Intel chips were compatible with the AMD64 architecture.

Last Year 10 year old computers were 32bit CPUs this years 10 year old computers are now 64bit.

Re:Wow! (4, Informative)

gman003 (1693318) | about a year and a half ago | (#41234941)

It's really just that naming is a mess.

The 32-bit architecture is known, variously, as "x86", "x86-32", "x32", "i386", "i686", or "IA-32".

The 64-bit architecture is known, variously, as "x64", "x86-64", "Intel 64", "IA-32e" ("IA-64" was taken by Itanium), "AMD64", "EM64T", and I think VIA has their own name for it.

Intel, obviously, uses the term "Intel 64" in marketing, "IA-32e" in technical writing. AMD obviously uses "AMD64", but as they were the first, many open-source projects were started under that name, and the term remains in use for historical purposes. Proprietary software tends to use the vendor-neutral "x64", while technical literature tends to use the more precise "x86-64" (as it is, after all, not the only 64-bit architecture around).

Re:Wow! (-1)

Anonymous Coward | about a year and a half ago | (#41234751)

While your base assumptions are wrong I do think this is a case of fanbois at the helm. They want to have another reason to get Teh Linux!!!onehundredeleven!!! in the headlines.

Re:Wow! (0)

Anonymous Coward | about a year and a half ago | (#41234985)

Well, that IS why I have been reading slashdot since it was called "chips and dips": because it's geared towards linux, and it has discussions about linux that I can learn from. (I come here to learn, as strange as that may sound.) Linux belongs in the headlines here, as much as windows belongs in the headlines over at c/net. There's nothing wrong with that.

You're new to this stuff, aren't you?

Re:Wow! (-1)

Anonymous Coward | about a year and a half ago | (#41235719)

Please. There's nothing to learn here unless you want to learn how to goosestep.
 
I can see the neckbeards are out in full force today.

Re:Wow! (-1)

Anonymous Coward | about a year and a half ago | (#41235921)

I'll be the first to admit that slashdot has become a far cry from what it was 10 years ago. Today it is overrun by teenagers whose primary agenda is "look at me". There is still much to be learned here if you stick to the technical stories -- where the "look at me" crowd actually realizes they are in over their heads. (Ring a bell?)

Re:Wow! (4, Informative)

ThePhilips (752041) | about a year and a half ago | (#41234903)

Was some AMD fanboy trying to make a point or did someone post this pre-coffee?

Debian gave moniker "AMD64" to the Intel/x64 systems to honor the facts that (1) AMD had introduce it and (2) without AMD we would never had the affordable 64-bit systems. (Intel's version of the 64-bit future was the IA-64. [wikipedia.org])

Similar sentiment btw was shared by Linux kernel folks, but they decided (== Linus decided) in the end to use vendor-neutral 'x86-64' moniker.

I love you! (0)

Anonymous Coward | about a year and a half ago | (#41234923)


 

Re:Wow! (1)

tqk (413719) | about a year and a half ago | (#41234949)

Was some AMD fanboy trying to make a point ...

Plausible. I know I was a bit disgusted in recent days when some $SHITHEAD was lambasting Linux users for not supporting AMD when the latter went out of their way to accommodate us. I haven't bought an Intel CPU since Randall Schwartz was railroaded by Intel's stupidity. I only go AMD and ATI, and that's been the case for more than a decade.

About time. (0)

Anonymous Coward | about a year and a half ago | (#41234495)

Who owns a system that still cannot run 64bit software?

I was really surprised that windows 8 will still be published in a 32bit flavor. Considering the only semi-recent x86 line to not support 64bit is some of the older atoms, why did they bother to keep it around? Maybe it has something to do with ARM and winRT, which is pretty much 32bit only.

Aside from the above mentioned atom CPUs (And perhaps intel's new phone oriented SoC designed to compete with ARM SoCs of the same nature), you'd have to have an older P4 based system to not enjoy a 64bit OS (P4s got 64bit about half-way through through the product line's lifetime).. And P4s are starting to look pretty damn long in the tooth.

Re:About time. (1)

fast turtle (1118037) | about a year and a half ago | (#41234641)

5yr old laptop with a turion processor? sure it might be 64bit capable but with less then 1GB of memory, is it even possible to run a 64bit OS on it? How bout a 700MHz Celeron (P3 era) that still runs WinMe? Hell the unit is still capable of everything asked of it today, which is office tasks - Word Processing, Email and Power Point. It's even used for some game play (games that don't install or run on Win7).

I Find it funny that people demand the latest greatest hardware when something like this old system still works and the really nice thing is, it uses a meager 60 watts of power. In fact, we're considering repurposing the thing to replace the home router due to the better memory (512M) and faster CPU compared to many of the routers you get today. Hell based on the specs, it's as good as a $2k Cisco unit though w/o the Cisco label or OS on it. Can I Sell it for that if repurposed as a proper router?

Re:About time. (0)

jellomizer (103300) | about a year and a half ago | (#41234715)

Windows flopped in making a 64bit OS that was good at 32bit binary compatible... Well to be a bit fair. the 32bit OS still runs some old 16bit programs while the 64bit OS will no longer run 16bit programs.

If you have that old program made for Windows 3.1 then you still need a 32bit OS.

Run the 16-bit applications in a real emulator (1)

tepples (727027) | about a year and a half ago | (#41234931)

If you have that old program made for Windows 3.1 then you still need a 32bit OS.

Then run the 32-bit operating system in a virtual machine on the 64-bit operating system, such as the XP Mode powered by Windows Virtual PC that is available to all Windows 7 Professional users, or run the 16-bit applications in Windows 3.1 in a real emulator such as DOSBox.

Re:Run the 16-bit applications in a real emulator (2)

tlhIngan (30335) | about a year and a half ago | (#41235917)

Then run the 32-bit operating system in a virtual machine on the 64-bit operating system, such as the XP Mode powered by Windows Virtual PC that is available to all Windows 7 Professional users, or run the 16-bit applications in Windows 3.1 in a real emulator such as DOSBox.

Once a processor is in x64 mode, it cannot run real mode/16-bit code at all. Even virtualized. It's just physically incapable of it.

The only way to run 16-bit code is to emulate it because the CPU will only take in 32-bit instructions in 32-bit compatibility mode.

Some virtualization software do have software emulators so they don't have to bother virtualizing 16-bit modes (VirtualBox does - in order to run the loaders of most OSes - the virtualization only takes over once the CPU is switched into 32 bit mode or better).

Windows has an interesting problem - because of the limitation of 64-bit mode, you'd think Microsoft would eliminate all the deprecated API calls for 64-bit Windows (but keep them around in the 32-bit libraries because theres enough legacy software out there that uses them). Calls like OpenFile(). But they didn't - their reasoning is purely developer convenience - you recompile your app for 64-bit windows without having to change many lines of code...

Re:About time. (4, Insightful)

Rockoon (1252108) | about a year and a half ago | (#41235609)

You do know that no 64-bit OS can run 16-bit applications without a virtual machine emulation on AMD64, right?

Once the processor is in 64-bit mode it cannot get back to 16-bit mode without a processor reset. Not even Linux can thunk from 64-bit back to 16-bit, because the processor architecture makes that impossible.

Your suggestion that "windows flopped" due to this is horse shit.

Re:About time. (1)

jones_supa (887896) | about a year and a half ago | (#41234845)

In my head I ran various scenarios in which a fresh 32-bit OS would be needed (older hardware, 16-bit apps, 32-bit drivers)...but in all those special cases you could just run Windows 7. I just can't see why they are putting resources to maintain a niche 32-bit flavor of Windows 8!

Re:About time. (0)

Anonymous Coward | about a year and a half ago | (#41234877)

Who owns a system that still cannot run 64bit software?

I have both an ARM11 and an ARM8 system in my pants pockets right now. The ARM8 SoC was manufactured in 2012.

Re:About time. (4, Insightful)

Lumpy (12016) | about a year and a half ago | (#41234887)

"Who owns a system that still cannot run 64bit software?"

I have plenty of them. Two routers that are still 32 bit only. I have several embedded PC104 industrial computers that are running robotics that are 32 bit only.

you know, those of us doing REAL work with computers. We need the older 32 bit Linux OS builds.

Re:About time. (0)

tepples (727027) | about a year and a half ago | (#41234989)

Who owns a system that still cannot run 64bit software?

My NES runs only 8-bit software. I still own my NES. I still play my NES. I still write programs for my NES. But I am still an edge case.

Re:About time. (1)

xaxa (988988) | about a year and a half ago | (#41235007)

My webserver runs on a 32-bit machine. I can't remember how old it is -- probably about 10 years (the processor is an AMD Athlon 1.4GHz).

It runs my website fine, and the website for a community group, and hold all my photos, and my parent's photos, and a backup of my desktop PC -- hosting for 70GB of photos wouldn't be cheap.

(My offline backup PC boots up once a month to back up the webserver. That also has Debian, and is even older -- an 800MHz CPU, I think.)

Re:About time. (1)

jonadab (583620) | about a year and a half ago | (#41235159)

> Who owns a system that still cannot run 64bit software?

I've got one that I use regularly, but I'm really only using it as a router, so I'm not sure that counts.

If you count systems that I don't turn on on a regular basis but which are still in working order if I should happen to want them for any reason, then I've got several, including a MicroVax 3100-40 and an old ITT XTRA (though, the hard drive in that one died years ago, so to use it I'd have to find a bootable 360K floppy that's still readable).

Re:About time. (1)

jawtheshark (198669) | about a year and a half ago | (#41235819)

I do... I have a laptop which I got from a friend of my sister. It had a cracked screen, I replaced it. The CPU is a Core Duo... Not 64-bit. From online reviews, I date it around mid 2007. (Fujitsu-Siemens Lifebook S7110, yes there are Core 2 Duo models, but mine isn't) It supports up to 4GB RAM (never tried, I only had 2x1GB modules lying around, which I used to upgrade from the 2x512MB modules) and runs both Windows XP Pro (license sticker included) and Ubuntu 12.04 LTS i686 just fine.

Now, granted, another of my laptops, also a Fujitsu-Siemens (Amilo Pa1510) is AMD Turion based and can run 64-bit. Alas, that one doesn't run Ubuntu 12.04 LTS fine, because the graphic chipset (ATI X1100) isn't supported well in the open source drivers and ATI dropped support from the proprietary ones :-(. So, on the road, I take the S7110....

That said, from approximately mid-2008, I expect everything to be 64-bit. However, 5-year old gear can be perfectly usable.

Talking about Debian and AMD64 (2)

thms (1339227) | about a year and a half ago | (#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?

Re:Talking about Debian and AMD64 (3, Interesting)

Carewolf (581105) | about a year and a half ago | (#41234597)

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.

Re:Talking about Debian and AMD64 (1)

bluefoxlucid (723572) | about a year and a half ago | (#41234981)

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 maybe Wine could do it IF it were possible--the only way to do it on current processors is across a context switch (so into kernel or into another process via IPC and a protocol), but a generic C program written in 1995 hooked to 64-bit libc wouldn't handle it. Maybe if 64-bit libc was aware of 32-bit programs and did translation (like the kernel), but that's a hell of a lot of code support and again you don't have the processor support for it (won't call 32-bit code from 64-bit in the same process).

On the 386, you could mark code pages as 16 bit and it would execute that code as 16 bit 286 code; this doesn't happen in long mode, you can't mark pages as 32-bit. It will go across a context switch, but the kernel implementation for this is a prime example of why not to bother: separate entry point that does translation, and then the exit point has to verify that all values being returned to user space are within the storage space of the 32 bit API (i.e. a uint16 is going to be 16 bits either way, but an int that's 32 bits on 32bit and 64 bits on 64 bit better store a meaningful 32 bit value), and if not then stuff has to be moved around (i.e. anything above 4GB in RAM has to be moved down, in the worst case) or handles have to be changed/mapped/etc. The kernel has to be able to handle not breaking things for 32-bit programs. Imagine implementing this in a C library... or, just recompile to 64-bit.

Re:Talking about Debian and AMD64 (0)

Anonymous Coward | about a year and a half ago | (#41235233)

ia32-libs is not multiarch (but it has been working for ages). I would not really say that multiarch in Debian is working, since every major package I have tried to use bumps up against some problem that prevents it from being installed. Wine multiarch does not because ia32-lib-gtk is broken (its critical dependency ia32-lib-gtk-i386 is stuck in the ftp-master NEW queue. Zsnes:i386 does not actually work, because it depends on libao:386 which conflicts with libao:amd64 (i.e., it is not yet multiarch-ified). Nvidia drivers (32-bit compatibility) don't work either, they again depend on something that isn't yet multiarch.

Re:Talking about Debian and AMD64 (0)

Anonymous Coward | about a year and a half ago | (#41234677)

This has worked in gentoo for a long time now. Although on my amd64 machine the 32bit libraries are binary installs, not source installs like the 64bit packages.

Re:Talking about Debian and AMD64 (1)

CronoCloud (590650) | about a year and a half ago | (#41235847)

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.

Nokia will PAY you to get its new phone (-1)

Anonymous Coward | about a year and a half ago | (#41234527)

Something about that from the Nokia webcast and the heavy-set, yet handsome, Finnish women who surprising talks an awful lot like someone from Microsoft - really, really boring. But if I get paid to get a Nokia, by golly geewhiz, I think I am a convert.

First Post, yeah! (-1)

Anonymous Coward | about a year and a half ago | (#41234571)

Oh, darn. Should have used AMD64 Debian instead of i386.

m68k support? (1)

Hadlock (143607) | about a year and a half ago | (#41234615)

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...

Re:m68k support? (0)

Anonymous Coward | about a year and a half ago | (#41234765)

Or is there another popular 68k platform I'm forgetting...

The Sinclair QL uses an 68008 CPU...

Personal anecdote time! (0)

Anonymous Coward | about a year and a half ago | (#41234625)

I have a Debian installation running on my very modern main desktop. I run i386.

The installation has been migrated through several hardware configurations (3 major changes and some incremental) for 7 years now. This has resulted in minimum maintenance time. When the installation took place, I had a P4.

I believe I tried a run-time upgrade to amd64 once in 2006 with new hardware. I also think I spent several hours to reverse it. Multiarch is something I'm looking forward to, and it seems to be developing quickly, but I just don't have a reason to upgrade right now.

Debian i386 - stable as a rock, and with PAE definitely good enough on my Core 2 Duo with 8GB RAM. On a new installation (such as my newer laptop), I'd without a doubt go amd64. It is the modern way.

Field and Vanilla (1)

puddingebola (2036796) | about a year and a half ago | (#41234665)

The most common wallpaper image on Debian desktops is of a green field. The most popular flavor of ice cream is vanilla. Thank you.

Maybe now Canonical will finally recommend 64-bit (1)

JOrgePeixoto (853808) | about a year and a half ago | (#41234691)

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 microcode, and the other half do not implement i386 at all; then, get rid of i386.

Re:Maybe now Canonical will finally recommend 64-b (1)

tepples (727027) | about a year and a half ago | (#41235043)

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.

Re:Maybe now Canonical will finally recommend 64-b (1)

0racle (667029) | about a year and a half ago | (#41235335)

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.

Easier to tell CD-R than x86-64 from outside (1)

tepples (727027) | about a year and a half ago | (#41235597)

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], though it's slightly harder to find than buying CDs.

Re:Maybe now Canonical will finally recommend 64-b (1)

gman003 (1693318) | about a year and a half ago | (#41235045)

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 asking for trouble. And if you've gone through the work of making an x32 "emulator" or whatever, why use it on only some cores? People specifically looking for 32-bit support will ignore your product; people who don't care about 32-bit support won't get anything out of having half the cores support it "for reals".

Third, they can't remove x86-32 completely. They can't even remove x86-16 completely - every processor on the shelf right now turns on in 16-bit mode. Either the BIOS/EFI runs some commands to set it into 32-bit and then 64-bit mode, or the bootloader does.

Re:Maybe now Canonical will finally recommend 64-b (0)

Anonymous Coward | about a year and a half ago | (#41235195)

Not any time soon. Also more than likely the x86 instructions are translated into 64 bit uops anyway. They translate them anyway so what is one translation vs another... Negligible. Also remember those CPUs still probably support 8bit/16bit operations. You probably could get the cpu to act like a super powerful 80186. While the desktop/server market is huge for them. They also have a huge other market they want to support. Never mind taking it in the shorts in a bunch of benchmarks...

Most modern x86 style cpus have long been translators anyway. All the way back to the first 686. The atom processor is a sort of throwback but they are moving it to a 686 style in the next gen or two.

Also these days 40-50% of the cpu die is cache. They would just use the 'saved space' for some other instruction or to make an existing one run faster. The instruction decoder part is actually about 1/4th the cpu (or core these days). The memory controller is probably bigger.

They are getting close to SoC with these things. Next up is probably the bridge chip and all of its legacy I/O. At that point they will just add memory as that is all that is left to integrate in. Then it will just be a matter of density of the memory. At that point the CPU/GPU becomes a negligible part of the die.

Not a huge surprise. (2)

PhotoJim (813785) | about a year and a half ago | (#41234789)

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.

Re:Not a huge surprise. (4, Interesting)

cryptizard (2629853) | about a year and a half ago | (#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.

Re:Not a huge surprise. (1)

somenickname (1270442) | about a year and a half ago | (#41235511)

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.

Re:Not a huge surprise. (0)

Anonymous Coward | about a year and a half ago | (#41235667)

When running in long mode, you have access to additional CPU registers. You will most definitely see speedups even if you don't have >4GB RAM.

I wonder... (1)

fuzzyfuzzyfungus (1223518) | about a year and a half ago | (#41234859)

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 debian, and it isn't wildly uncommon to find debian or variants in various other not-exactly-hidden-but-fairly-quiet locations. I assume that those generally don't participate in popularity-contest. Individual desktop users, by contrast, probably participate more frequently. Any other speculation on who might be overcounted and who might be undercounted?

Re:I wonder... (0)

Anonymous Coward | about a year and a half ago | (#41235669)

Servers are probably vastly undercounted, many server admins are paranoid about stuff like that.

Stock Price (1)

superid (46543) | about a year and a half ago | (#41234911)

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.

The actual advantage is dubious, though! (0, Troll)

aglider (2435074) | about a year and a half ago | (#41234963)

While a lot of people thinks that a 64bit CPU deserves a 64bit OS for the sake of speed, it seems it's not so clear that it'd be a good move.
First, you need to have at least a single thread that requires more than 4GB RAM at once.
Say after me: "a single thread that requires more than 4GB RAM at once".
Probably an heavy loaded DB (to load a lot of indices in RAM) or a computer graphics imagery application or some other application with very very large data set to be worked on at once. Not impossible, but not so widespread. Maybe very large Java application can swallow all that RAM.
For a general understanding of CPU horsepower, give a look to a very simple observation (I wouldn't call it a real TEST) you can find in Linux from Scratch documentation [linuxfromscratch.org]

a 64-bit build is only 4% faster and is 9% larger than the 32-bit build

This also means that you have (more or less) 9% more chances that your code won't fit into the CPU cache, making that 4% extra speed less effective. And that you'll need (more or less) 9% more RAM to execute 64bit programs.
So, in my extremely humble opinion, unless you are running an heavy duty, heavy loaded server, you won't benefit that much from a 64bit OS on a 64bit6 CPU.

Re:The actual advantage is dubious, though! (0)

Anonymous Coward | about a year and a half ago | (#41235279)

You forget that more comes with the change from IA32 to AMD64 than an increase in the size of pointers. You also get access to twice the number of GPRs and twice the number of SSE registers. It really is quite an upgrade and is faster for almost every task. The increased address space size isn't everything.

Re:The actual advantage is dubious, though! (0)

Anonymous Coward | about a year and a half ago | (#41235321)

This also means that you have (more or less) 9% more chances that your code won't fit into the CPU cache, making that 4% extra speed less effective.

One assumes the 4% speed up was measured on a real machine, so the 9% increase in speed (and no that doesn't directly translate into a 9% higher chance of a cache-miss...) into account already.

Also I'm guessing that the LFS documentation hasn't ever been updated since that measurement was done some time ago, so the differences are likely larger now.

Re:The actual post is dubious, though! (0)

Anonymous Coward | about a year and a half ago | (#41235403)

you need to have at least a single process that requires more than 4GB RAM at once.

FTFY.

Say after me: "a single process that requires more than 4GB RAM at once, including kernel space, which can leave 3GB or even 2GB to the process".

FTFY.

a 64-bit build is only 4% faster and is 9% larger than the 32-bit build

This also means that you have (more or less) 9% more chances that your code won't fit into the CPU cache, making that 4% extra speed less effective.

No - isn't that already taken into account in the 4% number?

    And that you'll need (more or less) 9% more RAM to execute 64bit programs.

No - is most of the memory consumed by the binary, or the data structures it creates once loaded?

So, in my extremely humble opinion

No - not humble enough.

SOMEONE ON THE INTERNET IS WRONG.

Re:The actual advantage is dubious, though! (1)

Nimey (114278) | about a year and a half ago | (#41235421)

On the Windows side I think it'll be Real Soon Now that AAA games start shipping with 64-bit executables so they can use all that RAM, especially when XP stops being supported.

Re:size lies (5, Informative)

Chemisor (97276) | about a year and a half ago | (#41235613)

Stop spreading FUD. 64 bit executables have smaller code. The larger executable size is due not to the increase in code size but to the unwind tables. On i386 executables are typically compiled with the frame pointer model, where functions store the current frame address (the start point for local variables) on the stack. On x86_64 the normal method is to let the compiler figure out where the local variables are based on the stack pointer. This way there is at least one memory access removed.

Omitting frame pointers incurs the cost of emitting a table of function information to allow C++ exceptions to walk back up the stack. This information is stored in the .ehframe section of the executable and only needs to be loaded when the application throws an exception. This section is not part of the working set. It is also not used by pure C programs. So, although the executable size is larger on x86_64, the extra space it is consuming is on the disk, not your CPU cache.

Yes, you always benefit from building everything for x86_64 if your OS is x86_64. And unless you are running some application where benchmarks definitively show a performance decrease in the 64 bit version, there is no reason whatsoever to run 32 bit any more. Drivers are no longer a problem. So stop spreading FUD!

Re:The actual advantage is dubious, though! (1)

Anonymous Coward | about a year and a half ago | (#41235795)

Bullshit. Benchmark CPU-intensive code compiled for 32bit and 64bit and you'll see the 64bit version is, on average, much, much faster. There's absolutely no reason to refuse to use some features of your CPU.

Re:The actual advantage is dubious, though! (1)

danomac (1032160) | about a year and a half ago | (#41235833)

Maybe very large Java application can swallow all that RAM.

In my experience with Java apps, you don't need a large app to take a few GB of RAM. Small ones most defintely can! I was using a Java-powered DLNA server and was surprised to see it try to use over 2 GB of RAM!

Not AMD specific (1)

michaelmalak (91262) | about a year and a half ago | (#41234979)

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.

More interesting (3, Interesting)

Anonymous Coward | about a year and a half ago | (#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.

misconceptions (0)

Anonymous Coward | about a year and a half ago | (#41235485)

I wonder how many people with intel 64bit CPUs assume that AMD64 is only for AMD cpus, and then download the i386 version. http://www.debian.org/CD/http-ftp/ does not make it particularly clear for none CPU nerds. maybe the different architectures could be labelled with descriptive names, rather than the short names. The ubuntu download page is simpler, offering a choice only between 32bit and 64bit, though it unfortunately still recommends 32bit. Fedora also just lists them as 32 and 64 bit.

Still running 32-bit (1)

Tarlus (1000874) | about a year and a half ago | (#41235619)

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!

I'm not re-installing... (1)

agw (6387) | about a year and a half ago | (#41235671)

I'm not re-installing to upgrade to amd64. As long as there is PAE, I'll stay with my x86 installation.

I re-installed my desktop end of 1996 and have only done in-place updates/upgrades since then.

Or maybe there is a way to do an in-place upgrade to amd64 or a mixture.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...