This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!


64-bit Linux and BSD are maturing steadily

By Jem Matzan on April 04, 2005 (8:00:00 AM)

Share    Print    Comments   

Most top-tier hardware vendors are selling AMD64 workstation and server systems these days, including Hewlett Packard, Sun Microsystems, and, more recently, IBM. Oddly enough, most of them are shipping with 32-bit operating systems installed by default. While the AMD64 architecture can comfortably handle both 64-bit and 32-bit software -- even concurrently -- it seems a waste of its potential to disregard the best features of the architecture. While the theoretical speed advantage and expanded resources of 64-bit computing are enticing to those in need of maximum performance, the road to a perfect AMD64 desktop, workstation or server machine is long and treacherous. What operating system will you use? Is there enough 64-bit software available? In this article we'll explore some of the advantages and pitfalls of going totally 64-bit in a 32-bit world.

The AMD64 and EM64T instruction set architectures

AMD64, also called x86_64 in the Linux realm and EM64T (Extended Memory 64-bit Technology) by Intel, is basically the old x86 architecture (called "general purpose instructions") plus the old x87 floating point instructions (which are deprecated now but still used by some older 16- and 32-bit programs), 64-bit media instructions (a la MMX and 3DNow!) and these significant enhancements:

  • Increased number of general purpose registers
  • 64-bit addressing
  • 128-bit (SSE, SSE2) media instructions
  • Improved physical and virtual memory management

The AMD64 ISA includes twice as many general purpose registers as the old x86 design, and all of them are twice as wide due to the 64-bit addressing (as opposed to 32-bit). The instruction pointers (a pointer is a variable that contains an address rather than data) also increase from 32 to 64.

Having more and wider general purpose registers means that memory can be used much more efficiently and memory traffic can be minimized, which in turn allows compilers to compile programs to work much faster on your machine.

64-bit addressing means that the physical memory limitation rises to 1TB from 4GB. The processor can also work with longer instructions. To really notice this advantage, you have to stress the system to a degree that most desktop users don't with current software, but as desktop applications demand more from processing hardware, this advantage will become much more important. (The advantages to 64-bit addressing in a workstation or server machine are more obvious as they regularly deal with CPU-intensive work.)

128-bit media instructions refer specifically to Intel's SSE and SSE2 (Streaming SIMD -- Single Instruction Multiple-Data -- Extensions) technology. These instructions are very useful for working with large blocks of data, which benefits anyone who deals with a lot of scientific data or high-performance media (streaming high-resolution video, image processing, 3D rendering, and speech recognition) or anything that uses floating-point math. Previously the Athlon XP processor did not have SSE2, although it did have SSE functionality. Intel Pentium4 CPUs utilize both.

AMD64 deals with both physical and virtual memory in a much more sensible manner than x86, treating the entire virtual memory space as one unsegmented block and eliminating a lot of translation layers from the process of addressing physical memory. Previously x86 would segment virtual memory into small blocks for use with different programs and functions, but this ended up being inefficient and rarely used by the software. AMD64 eliminates that inefficiency by letting the software choose how it will handle virtual memory (which it does anyway, even if the virtual memory is segmented). This translates into lower latency and faster performance when dealing with both physical and virtual memory.

Performance and enhanced capabilities aside, the most valuable feature of the AMD64/EM64T is its ability to run 32-bit x86 binaries without a separate processor or operating system. This makes it much easier to slowly transition from a 32-bit to a 64-bit environment without having to change software applications. While AMD64 and EM64T processors are still very fast while in 32-bit mode, you won't be able to take advantage of any of the above-mentioned features and expanded resources (with the exception of the SSE and SSE2 instructions) if you're running a 32-bit operating system. Even if you're going to be running 32-bit binary programs, it pays to have a 64-bit operating system underneath them so that the rest of the system can run more efficiently. That's only the beginning, though -- the next step to maximum performance is to eliminate all 32-bit binaries from your system.

Operating systems

One great advantage to free software is its ability to be easily ported to new architectures. While at first it was difficult to find many programs that would compile for 64-bit, today you can have a complete desktop system that is entirely 64-bit without making too many sacrifices. Fedora Core, starting with version 3, offers a mostly 64-bit operating environment with the exceptions of programs which are not yet modified to compile for the AMD64 architecture. If you're not a Fedora Core fan, 64-bit editions of your preferred commercial distribution may be available, or you can compile it all yourself a la Gentoo Linux, FreeBSD, OpenBSD, or NetBSD.

Red Hat and Mandrake both offer AMD64 editions of their commercial distributions. Mandrakelinux 10.1 for x86_64 is $45US more than the x86 Powerpack edition that it was based on. Novell used to offer their AMD64 edition of SUSE Linux Professional at a higher price, but starting with version 9.1, the AMD64 and x86 editions are packaged together in the same box. That means that for SUSE users switching from 32-bit to 64-bit is as easy as reinstalling the distribution.

As we mentioned, there are a few programs that will not properly compile or run in 64-bit mode. Fortunately, with each successive distribution release, more is made 64-bit.

"There are parts bound to remain 32-bit, namely bootloaders -- e.g. lilo, grub," says Mandrake spokesperson Gwenole Beauchesne. "Besides, is still 32-bit as it's not fully 64-bit clean yet. The rest default to 64-bit packages.

"Note that we also provide a lot of 32-bit library packages to retain compatibility for users willing to use 32-bit programs. Generally, that's proprietary applications that are not ported to x86-64 yet. Finally, exclusively for Mandrakelinux 10.2 and next distributions, we also provide 32-bit packages useful for development of 32-bit applications from an x86-64 system. Compared to our competitors, our solution does not require you to install a 32-bit chroot, neither need repackaged files, nor manually fiddling with 32-bit libraries or headers. So far, it has been verified to let you build a 32-bit evolution2 package from an x86-64 system as simply as linux32 rpm --rebuild <evolution>.src.rpm."

The BSDs can be compiled entirely for 64-bit, although we had some significant problems with stability in testing FreeBSD 5.3 for AMD64. We had frequent crashes and data loss, DHCP and other network problems with SysKonnect/Yukon-based LAN cards, and found the 32-bit binary compatibility layer to be nonexistent. The entire system was 64-bit, but it never seemed to work reliably on two test systems (Asus K8V Deluxe with an Athlon 64 3200+, and an MSI K8T Neo2-FIR with an Athlon 64 4000+). The final nail in the coffin was that there were so few programs in the Ports tree that would properly compile, and some were limited to the x86 arch but would compile perfectly for AMD64 by editing that port's makefile. Finding programs was a matter of trial and error -- and sometimes a little configuration hacking.

OpenBSD is also compiled top to bottom for 64-bit (with the necessary exception of the boot code, which does not affect system performance), and nearly all of the programs in the Ports tree compile for 64-bit without any problems. A complete list of precompiled 64-bit OpenBSD packages can be found here.

OpenBSD project leader Theo de Raadt says the OpenBSD Ports tree is thoroughly tested; that "it is not a matter of trial and error. In our Ports tree development processes, something has to compile fully to be enabled on an architecture. The Ports tree is compiled continually on as many architectures as possible to spot flaws like this. Actual tested-to-run-perfectly is a little bit behind this, since 64-bit bugs do tend to lurk in hidden areas, many programmers out there still are not aware of how to code carefully for 64-bit machines."

OpenBSD's AMD64 package builder Peter Valchev added, "You can expect most things to work. Out of about 3000 ports in our tree right now, there are less than 20 that are broken (don't build), which is less than 1%. And fixing these is a matter of completely rewriting portions of the program in order to get it to build (often due to complete assumptions of 'all the world is i386' on the part of the programmers), and infeasible for us to do. The reason for the breakage being so minimal is not an accident -- the OpenBSD Ports contributors strive for quality as a primary goal. There are, of course, 64-bit runtime bugs that appear in programs due to careless programming combined with the fact that other operating systems ship 32-bit binaries, so their users don't run into issues, and programs never get fixed! That's completely the wrong approach -- instead we suffer from the odd bug that bites us, but pretty much all of the known issues are continuously being fixed by volunteers."

Drivers and programs

In our several months of *BSD and GNU/Linux 64-bit testing, we didn't run across any trouble with getting drivers to work. Nvidia has provided a working, up-to-date 64-bit binary driver for Linux for more than a year, but ATI only released theirs this past January. It's not without its problems, and seems to be no better off than the 32-bit version was in terms of performance and stability. These exceptions aside, you may be stuck with a 32-bit operating system if you have hardware that only has binary proprietary drivers available. Other proprietary drivers -- however rare they may be these days -- may not be compiled for 64-bit in the near future. Unlike userland software applications, it is not possible to use a 32-bit binary driver with a 64-bit kernel.

Fedora Core and Gentoo are the only community-developed GNU/Linux systems we tested that can be completely 64-bit, with the aforementioned exception of the boot code. Debian has an AMD64 edition, but it is still in the beta stage.

Like FreeBSD's Ports, Gentoo's Portage tree is hit-and-miss with programs that are able to compile and run. While you can get a 64-bit Mozilla, the MPlayer plug-in package is still masked and marked as unstable. There are many similar examples of masked packages, like and the Azureus BitTorrent client. Fortunately, most of the masked programs have 32-bit binary builds available in Portage, so you don't have to go without them.

The biggest hassle we had was with Web browsers and word processors. 1.1 would compile partway, but not all the way. AbiWord 2.2.3 (the latest edition available in Portage) would do nothing but crash every time we tried to open a file. The eventual solution was to use a 32-bit binary from Portage; we're hoping that the upcoming version 2.0 is a bit more portable.

Mozilla and Firefox will compile for AMD64, but Opera has no plans to ever offer a 64-bit binary of their Qt-based proprietary browser. While we had some trouble with Mozilla's long-term stability (over time, it would crash at random), and Firefox crashed left and right, our biggest challenge was in getting the plug-ins to work. The Java Runtime Environment is now available for Linux/AMD64, so we installed that from Portage and made sure that the plug-in was copied to the correct location. Both Mozilla and Firefox would detect it in the about:plugins screen, but only 64-bit Mozilla could use it. The MPlayer plug-in, unmasked manually, would work well in 64-bit Mozilla, but was not detected by 32-bit Firefox. Opera would detect our 32-bit binary Acrobat Reader plug-in, but neither Mozilla nor Firefox would. Flash worked in Opera and 32-bit Firefox, but not 64-bit Mozilla. After days of searching for answers and fiddling with 32-bit binaries and 64-bit compiles of both browsers, we determined that it was necessary to have both a 64-bit Mozilla and a 32-bit Firefox to use all of the usual browser plug-ins with 64-bit Gentoo.

While many packages are masked in Gentoo, some of them may work perfectly or partially. There's a rather large thread on the Gentoo forums where AMD64 users discuss masked programs that seem to work well.

Not all proprietary software is 32-bit. Epic released Unreal Tournament 2004 last year with both 32-bit and 64-bit AMD64 Linux binaries. After extensive testing of both editions, we can say for certain that they work rather nicely.

The challenge and the compromise

While the road to a completely 64-bit operating environment with an AMD64 or EM64T processor is almost comfortable enough to travel, there are still some roadblocks here and there. Most of them have workarounds, and you're going to either spend more time or more money to get a working 64-bit environment.

Fedora Core 3 (and the upcoming 4) is a good, safe bet for those who want to go 64-bit with as little cost and hassle as possible. Novell, Mandrake, and Red Hat have mostly 64-bit versions of their desktop, workstation, server, and corporate distributions, if that's the route you prefer. Gentoo Linux requires more time and tinkering to get things working properly in 64-bit mode, but for those of us who enjoy that sort of thing, that only makes Gentoo more appealing. The BSDs are also an option for the more technically-minded 64-bit enthusiast.

There's no doubt that the AMD64 architecture has come of age in the free software world. While proprietary software companies only seem to see the expense of porting their x86 code and supporting yet another version of their software, open source projects see it as a challenge to develop better programs. It may not be perfect yet, and depending on your needs you may have to make some minor sacrifices to go totally 64-bit -- or you'll have to use a handful of 32-bit binaries for the time being -- but it's there and it works.

Share    Print    Comments   


on 64-bit Linux and BSD are maturing steadily

Note: Comments are owned by the poster. We are not responsible for their content.

FC3/x86_64 and gcc/g77

Posted by: Carlie J. Coats, Jr., Ph.D. on April 04, 2005 07:40 PM
One annoying problem with the version of gcc
shipped with Fedora Core 3 for X86_64 is its
propensity to fail when used with longstanding
(and what should be relatively safe" flags


You wind up with error messages something like
<TT>error: unable to find a register to spill in class `AREG'
...confused by earlier errors, bailing out</TT>

It's not the more-complex routines that are
causing this compiler failure, either...
It's a pain to have to go back and re-compile
manually fifty routines out of a thousand, or
else forego for a package the substantial optimization
afforded by using the full-strength instruction
scheduler<nobr> <wbr></nobr>;-(


Kanotix 64

Posted by: Anonymous Coward on April 05, 2005 12:12 AM
No Debian?

Kanotix 64 is the best 64-bit linux option available for the home/desktop user.
<a href="" title=""></a>


Try debian!

Posted by: Anonymous Coward on April 05, 2005 12:36 AM
I use Debian amd64 everyday and run abiword,firefox,blender,gimp and even 64bit cinelerra without trouble. Piotr


Re:Try debian!

Posted by: Anonymous Coward on April 05, 2005 11:37 PM

I use Suse 9.2, and I found only a major problem with the 2.6.8 series kernel, which had a problem with a device driver (sata_sis). So I had to downgrade to 2.6.5, but here I found huge problems with samba/cifs, which sometimes crashed the whole network.

Eventually I tried out the 2.6.11 kernel from the update site of SuSE/Novell, and magically all the problems with the driver disappeared, along with the ones with samba/cifs, which now seems rock solid. And the performances... Gee! -What a piece of cake in a pretty standard machine, apart RAM and CPU!


What a moronic article

Posted by: Anonymous Coward on April 05, 2005 01:07 AM
The FreeBSD 5.3 part is redicolous.
If you can't handle your computer and OS, don't blame it on the operating system...
FreeBSD on AMD64 is rock stable. Go figure.


Re:What a moronic article

Posted by: Anonymous Coward on April 05, 2005 03:47 AM
I tried FreeBSD 5.3 recently, hoping to try out the much-ballyhooed GBDE disk encryption driver. Unfortunately FreeBSD would crash instantly when trying to write data to a GBDE encrypted partition.

I'm sure FreeBSD 4.x is much more stable, but its a joke to call FreeBSD 5.x "rock solid."


Re:What a moronic article

Posted by: Anonymous Coward on April 05, 2005 06:54 AM
At least part of the problems the author cites on FreeBSD are not AMD64 specific. I too had stability problems running with a Yukon Gigabit Ethernet chipset on FreeBSD 5.3Beta or 5.2.1 (in my case, a P4 at 2.4 GHz system)... the machine didn't crash, but the NIC would stop responding. A ifconfig down followed by ifconfig up (issued from the console) would fix things again. And this only occured during large data transfers (FTP, scp)... interactive ssh sessions wouldn't cause problems. Fedora Core 3 on the same system seems to be rock solid.



Posted by: Anonymous Coward on April 05, 2005 07:07 AM
I'm running FreeBSD-5 on amd64 for a longer period of time. I've got no crashes at all.

Of course, I have 32-bit compatibility layer (for both: FreeBSD and its 64 bits Linux emulation).

I don't understand the part about ports, either. I've got full working environment (KDE3.4, Gnome 2.10 and XFCE4.2.1 together with all my development utils and productivity suites like evolution and openoffice).

Please get your system working. This is really emerassing!


Lilo works fine on 64 bit

Posted by: Anonymous Coward on April 05, 2005 01:30 AM
I run a complete 64 bit system, including lilo. I
have also put this onto a boot CD.

I was going to compile a 32 bit glibc, but have not
needed it yet. Running KDE and firefox, and mail,
xchat, news and stuff are great.

Chris Lingard chris AT stockwith DOT co DOT uk


Re:Lilo works fine on 64 bit

Posted by: Anonymous Coward on April 06, 2005 04:20 AM
lilo CANNOT be 64bit. its a limitation of the bios.

the cpu starts in 32-bit mode, does the bios dance in 32bit, passes off to the bootloader in 32bit, and the very first part of the kernel is in 32bit. the kernel throws a flag, and the cpu jumps to 64bit.


64-bit linux

Posted by: segphault on April 05, 2005 06:00 AM
I've been thinking about building an amd 64-bit system, and wondering about software support. Thanks for the thorough and informative article!


What about Ubuntu?

Posted by: Anonymous Coward on April 05, 2005 07:59 AM
Ubuntu is a tops distro based on Debian, it's got an x86_64 port. The (about-to-be-released) 5.04 release is rocking along here.

check it out at
<a href="" title=""></a>

you can even get free CDs mailed out to you
<a href="" title=""></a>


About FreeBSD..

Posted by: PeterWemm on April 05, 2005 09:27 AM
Well, formal releases of FreeBSD/amd64 have all been Jinxed. We've managed to get a stinker series of problems in every release so far. 5.3 suffers from the Syskonnect/Marvell driver nightmare as well as a couple of other serious bugs that affect machines with more than 4GB of ram.

To top it off, FreeBSD 5.3/i386 added thread-local-storage right at the last minute that wasn't compatable with FreeBSD/amd64's 32 bit environment. So as a result, 5.3-amd64 cannot run 5.3-i386 binaries. How's that for bad timing?

Most of the syskonnect/marvell driver problems are specific to particular versions of the silicon. If the reviewer had run with different hardware, their stability results would have been significantly better. I personally use (older revision) syskonnect/marvell network hardware on all of my development and desktop machines.

Some of the problems that the reviewers ran into was because of the design. We implemented FreeBSD/amd64 primarily as a 64 bit platform with 32 bit support as a distinct second priority. We were thinking of how the world would be looking in 1, 2, 5 or even 10 years. We knew about Intel's 64 bit contingency plans for years, and we knew that the writing was on the wall for 32 bit silicon. We didn't want to be stuck with decisions that resulted from temporary expediency for 32 bit coexistence. We figured that within a few years, 32 bit compatability wouldn't be much of a factor - at least in unix environments where FreeBSD tends to get used a lot. We didn't want to be stuck with 64 bit as an add-on, instead of as the primary mode of operation. I guess time will tell if we made the right choice.

But don't dismiss the 32 bit environment entirely. We have some FreeBSD 4.x i386 environment on FreeBSD/amd64 machines at work, in a production environment, to stress test it and make sure we catch problems. (And yes, we are finding plenty!). This is maturing quite quickly.

We made a bunch of other decisions that we knew were going to be painful to start with, but were going to pay off over time. For example, we use a 64 bit time_t throughout the system, both in the kernel and userland. Our libc time code is good for a few trillion years, y2038 isn't going to be a factor for us.

Anyway, we took some brave decisions that we knew were going to hurt us in the short term, but with the hope that we'd end up with a cleaner system in the end.


Re:About FreeBSD..

Posted by: PeterWemm on April 05, 2005 09:39 AM
Whoops, one followup comment I need to make.

In all cases, the RELENG_5 (so called) "5-stable" branch has been more robust and solid than the last few actual formal amd64 releases. Given how new the amd64 port is, I usually tell people to install the most recent release and immediately update it to the top of the 'stable' branch.

For example, all the known 5.3-release syskonnect/marvell/8gb/32bit-emulation problems are fixed in 5-stable. Sure, there are still going to be problems, but we've fixed all the known ones that people keep running into. We can help people who are running the latest "stable" code much more effectively than people running older releases. Things are still moving very quickly compared to the other more mature platforms that we support.

Again, this statement applies to the FreeBSD/amd64 releases - not FreeBSD in general - because of the simple fact that there are more people running i386 snapshots/betas/rc's than there are people running the amd64 snapshots/betas/rc's.


Re:About FreeBSD..

Posted by: Jem Matzan on April 05, 2005 10:26 AM
The big problems I had were the Syskonnect/Yukon driver and dhclient on my K8V Deluxe board. They were fixed for a while, then somehow went back to not working. I also had a lot of lockups and crashes that appeared to be related to GEOM, causing me to switch to Gentoo until I was sure it was safe to use FreeBSD/AMD64 again. I switched to an MSI K8T Neo2-FIR on the same FreeBSD installation (5.3-RELEASE) and the boot process would not complete, even in single user mode. A fresh installation yielded no better results. I'm now on a dual Opteron system and haven't tried out FreeBSD since I switched to it. I figure I'll wait for 5.4-RC1 before I gave these systems another shot. I'll be reviewing 5.4-RELEASE when it becomes available.



Re:About FreeBSD..

Posted by: PeterWemm on April 05, 2005 10:29 AM
I guess that means we'd better make sure it's good this time, huh?<nobr> <wbr></nobr>:)


Re:About FreeBSD..

Posted by: Jem Matzan on April 05, 2005 10:42 AM
Well, if not, there's always the next release after that. If you'd like, I can send you the 5.4-RELEASE review before we publish it so you can check it for errors or omissions. Or if you'd like to do an interview for a sidebar to the review, we can do that too.



Re:About FreeBSD..

Posted by: Anonymous Coward on April 05, 2005 07:55 PM
I've got FreeBSD-STABLE on amd64, too.

One difference is that I have a Gigabyte mainboard.
Works great, no problems at all.


Intel, AMD and Win-64...

Posted by: Anonymous Coward on April 05, 2005 01:30 PM
Oddly enough, the AMD-64 chips have been out for some time. But now that Intel is finally starting to ship their 64-bit Xeons, MS announces that Win-64 will come to market in short order.



ph mem

Posted by: Anonymous Coward on April 05, 2005 01:37 PM
"64-bit addressing means that the physical memory limitation rises to 1TB from 4GB."

only 1TB? that looks wrong to me. Do people just decide to pull shit from their asses when they write articles?


Re:ph mem

Posted by: Anonymous Coward on April 05, 2005 04:14 PM
I suspect this number comes from the fact that current generation AMD Opteron processors have 40-bit physical addressing, which gives you up to 1Tb of memory. This, AFAIK, can be easily extended on future generations if the need arises. The ISA itself supports larger addresses.


Re:ph mem

Posted by: Anonymous Coward on April 05, 2005 04:18 PM
Hey dumbass, maybe you'd better do a Google search before you make a "oh! look at me! eyum smerter than the author!" comment. 1 TB is the 64-bit physical memory limit, just like he said.



Posted by: Anonymous Coward on April 06, 2005 01:30 AM
You left out what must be the prime example of a 64-bit OS running on the 64-bit AMD hardware. That is Solaris 10.If you install Gnome or KDE and the full suite of GNU tools on Solaris you can't tell it from Linux until you look closly and Solaris is now being open sourced. Sun had a long time to get Solaris working on 64 it machines as it's been on SPARC for years. I'm currently shoping for a new computer. I'm looking for a dual AMD Opteron system and Sun is actully beating others on price so Solaris is not unreasonable.



Posted by: Jem Matzan on April 06, 2005 01:54 AM
I considered including 64-bit Windows 2003 and XP (I'm pretty sure they're mostly 32-bit outside of the kernel), but my focus is really open source operating systems. Solaris is not open source, and it was supposed to have been released under an open license before now. Aside from that, I have been unable to get any kind of network connection on Solaris thus far on four machines -- I'm sure I'm doing something wrong with the network or driver setup, but I haven't dedicated any time to researching the problem yet. When Solaris 10 is open source, I'll include it in articles like these.

Sun told me at the Solaris launch that much of the userland will be 32-bit in 64-bit Solaris because they didn't see a need to spend time and money on making "Trivial" programs 64-bit clean.




Posted by: Anonymous Coward on April 08, 2005 12:11 AM
"The BSDs are also an option for the more technically-minded 64-bit enthusiast."

What's the point in this statement? Why the more technichally-minded should choose the BSD's? This could be true in the early days of Linux.


this is FUD

Posted by: Anonymous Coward on April 09, 2005 11:55 AM
Given the author's older anti-FreeBSD ranting on some other site, and the lack of depth (or clue) in the analysis, I am forced to conclude that this is nothing but FUD, full of sound and fury, generated by a blowhard.

I am running a number of FreeBSD 5.3 boxes 24/7, and they have been rock fucking solid. Mkay? Now, some of that hardware was runnning OpenBSD earlier, and suffered from a few lockups. Coincidence? Bad luck? Maybe, maybe not.

Although I am a huge fan of OpenBSD and their crusade to reign in the exploding complexity of open-source services by rolling their own, so far my own stability score card is in favor of FreeBSD.


64 bit has been useable on servers for years

Posted by: Anonymous Coward on April 12, 2005 05:54 PM
I have been running 64 bit linux on my Alpha at home since 1998. I have tried RedHat, Mandrake and most recently Gentoo.
Back when I used it as a desktop machine life was sometimes a little difficult, but with perseverence I managed tasks like web browsing and sound editing. These days it runs as a server and life is much easier. Functioning applications include:

  - courier IMAP server

  - bittorrent

  - privoxy

  - mldonkey

  - ffmpeg

  - ntpd
Life can still be a bit tricky. Currently, I can read from but not write to samba and getting the mythtv backend to work is proving a challenge.
In summary, I would suggest that making Linux work on these 'johny come lately' 64 bit platforms from Intel and AMD has been made a lot easier because of folks who have spent the last decade getting it to work on other 64 bit platforms.


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya