Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×

Debian to Run on AMD64 198

dark-br writes to tell us TechWorld is reporting that the next Debian release will be able to run native on AMD64 processors for the first time. From the article: "The GNU/Linux 4.0 operating system, also known as "Etch," is planned for release in December, the group said. It will also have new security features, including encryption and digital signatures to ensure that downloaded packages are validated."
This discussion has been archived. No new comments can be posted.

Debian to Run on AMD64

Comments Filter:
  • Very good news! (Score:4, Interesting)

    by QuantumFTL ( 197300 ) * on Wednesday July 26, 2006 @12:28AM (#15781906)
    This is great news! I do contracting work for Maas Digital [maasdigital.com], and we have a 30-CPU renderfarm running a weird combination of Debian-32 and Red Hat 64 bit binary overlays. This should simplify things immensely!

    At my other job (lylix.net [lylix.net]), we had to move away from Debian to Gentoo for this reason (among others), so it's good to see it finally being
  • by MarkByers ( 770551 ) on Wednesday July 26, 2006 @12:32AM (#15781925) Homepage Journal
    Stupid question: What does the 4.0 mean?
  • by WasterDave ( 20047 ) <(davep) (at) (zedkep.com)> on Wednesday July 26, 2006 @12:32AM (#15781926)
    More to the point it will be using 2.6.17 as the boot kernel. In other words, transparent support for SATA chipsets and (therefore) the ability to create a bootable raid set straight from the iso.

    It might not sound like a big deal, but it's the only reason I'm using etch right now.

    Dave
    • Don't forget 2.6.17 added Secure Digital Host Controller Interface drivers. I've been waiting for the built in card reader in my laptop to have some out of the box support.

      Although I'll still be waiting for the fingerprint scanner and PAM biometric modules to be added as an install time option in a major distro.... Baby Steps...

    • You're right. It doesn't sound like a big deal.
  • by SFSouthpaw ( 797536 ) on Wednesday July 26, 2006 @12:35AM (#15781935) Homepage
    I'm just etching to try this out.

    *joke rimshot*

  • by Depili ( 749436 ) on Wednesday July 26, 2006 @12:41AM (#15781944)

    The slashdot summary is almost the whole article text from a ad-ridden page.

    And nothing screams "hey, we want your traffic for free!" more than the submit to digg and submit to slashdot links bellow the small article...

  • by Anonymous Coward
    I've been running Debian on an AMD 64bit notebook from Fujitsu (the FMV-BIBLO NB80JN) since about a week after the notebook was released (more than 2 years ago). It was crummy at first, plenty of odd software that didn't really run well or at all, but now the only things that don't run in 64 bit mode are the software that doesn't run in 64 bit mode on any system, like OpenOffice and Wine. To tell the truth I haven't attempted to use OO.o and Wine on this box for well over a year, so that may be different as
  • by Mr.Ned ( 79679 ) on Wednesday July 26, 2006 @12:44AM (#15781954)
    http://www.debian.org/News/2005/20050811 [debian.org]

    Although Sarge (the current Debian stable) was not released with AMD64 support, it was added as an official, fully-supported architecture two months after the release -- way back in August of last year. TechWorld didn't read the recent news announcment correctly.
  • I guess the submitter of the article didn't know that the people who ask the "does it run linux?"-question are actually joking...
  • My main machine at home is an AMD-64 machine running Debian unstable. Debian has been running on AMD-64 for some time now, but there's never been an official release with it as yet.

    The mailing list for the AMD-64 port was created on May 25, 2003.
  • by Advocadus Diaboli ( 323784 ) on Wednesday July 26, 2006 @01:43AM (#15782118)
    Running Debian/Sarge for i386 architecture on an AMD64 machine I wonder which steps I need to do if I want to change to AMD64 architecture with the new stable release in December. I guess apt won't have the arch-update command, but does it mean "reinstallation" or is there some smart strategy to migrate from i386 to x86_64?
    • by fluch ( 126140 )
      Try this (just a rough idea): 1) tar /etc together. 2) get the list off all installed packages with "dpkg --get-selection" 3) Make a fresh but basic amd64 architecture install 4) "dpkg --set-selections" 5) tell the system to install those packages (I guess it was "apt-get dselect-upgrade" or something like this) 6) overwrite /etc with the original content 7) fix any minor issue. 8) profit?
      You seem to have a fast processor, so it shouldn't take long time.
      I hope you have your /home directory on a seperate pa
    • by Anonymous Coward on Wednesday July 26, 2006 @02:26AM (#15782218)
      You have to reinstall but that can be done quite easily (make a backup though):
      - save the output of dpkg --get-selections
      - save the output of debconf-get-selections
      - save the important parts of /etc you want to keep
      - save other directories (e.g. /home, parts of /var, etc)
      - do a minimal amd64 install
      - restore the saved parts of /etc, /home, /var and others
      - debconf-set-selections saved.debconf-get-selections
      - dpkg --set-selections saved.dpkg-get-selections
      - apt-get dselect-upgrade

      You might need to do some more minor tweaking and be sure to read the release notes though.
      • I don't think debconf-get-selections is installed by default, since it is part of the debconf-utils package (at least on my Sarge installation. You would need to install debconf-utils first before running depconf-get-selections:

        # apt-get install debconf-utils
  • But wasent this mensioned in the previous article annoncing next version of Debian?

    The Debian project confirms December 2006 as the date for the next release of its distribution [CC] which will be named Debian GNU/Linux 4.0 alias 'etch'. This will be the first official release to include the AMD64 architecture.

    dark-br writes to tell us TechWorld is reporting that the next Debian release will be able to run native on AMD64 [CC] processors for the first time. From the article: "The GNU/Linux 4.0 operatin

  • Seeing I've been running it on my AMD64 system for what seems like an eternity... :)
  • Debian ports (Score:2, Informative)

    by xsuchy ( 963813 )
    Do you know, that Debian has 8 ports (additionally to 10 main official ports), which has not been released officially, because they have compiled only e.g. 90% of packages (from 15 000 packages). You usually do not need any package from missing 10 %.
  • Old news (Score:2, Informative)

    by Klaidas ( 981300 )
    This is old news/dupe: Debian told that on their announcement about 4.0 ( http://www.debian.org/News/2006/20060724 [debian.org] ), to which slashdot has linked in a previous article (http://linux.slashdot.org/article.pl?sid=06/07/24 /1830228 [slashdot.org] )
  • by glwtta ( 532858 )
    The summary is wrong. It's not misleading, or sensationalist, or vague - just plain wrong.

    It's wrong in such a way that it causes half the comments to be explanations of why it's wrong (the other half are about how the poster dumped Debian long ago, and no one cool uses it anyway, and how they love Ubuntu/Gentoo/Vista/MacOS 9 etc., and besides Debian is teh sux).

    I mean, what the fuck, ScuttleMonkey?
  • Not a big deal (Score:4, Interesting)

    by Rorian ( 88503 ) <james...fysh@@@gmail...com> on Wednesday July 26, 2006 @03:30AM (#15782384) Homepage Journal
    First, this is just an announcement that 64bit support will be included in a stable branch, and secondly.. how many people truly benefit from 64bit?

    Not to be negative, but I'm yet to see any benchmarks showing a marked improvement (for general PC usage) from going 32bit to 64bit. All it really does is let you use more RAM (REALLY not useful for the average desktop user at this time) and perform 64 bit calculations natively (really only useful for scientific applications, certainly useless for desktop users 99.99% of the time).

    On the downside, binaries become larger (64bit addresses instead of 32bit) and old binaries may have to be emulated (if using a 64bit-only CPU).

    Still, I guess it'll excite some desktop users, wanting the "full functionality" from their brand new 64bit dual-core system. Personally, I only went to a x86-64 chip recently because it was the best price/performance chip I could find - 64bit processing had and continues to have no positive influence on my computing experience.

    P.S. Sorry to be so negative, but I'm sick of hearing all this phwoar! stuff about 64bit, when it really isn't that exciting. Guess I haven't had my morning coffee yet..
    • Re:Not a big deal (Score:3, Interesting)

      by dargaud ( 518470 )
      I deal with large to very large images all the time. The virtual mem for my graphic app is often between 1 and 2 Gb and would like to get rid of this 2Gb practical limitation from both Windows and Linux. I've tried both Ubuntu64 and XP64 and had to get rid of them because of missing crucial drivers. Right now I'm playing with VMware to see if I can get everything working together. I imagine video enthusiasts will need a lot more mem for their work than I do.
      To give you an idea, a 5400dpi scan at 16bits tak
    • Apparently you've not seen the difference between 32-bit games and 64-bit games. Try UT2K4 with it's 64-bit Linux version and compare to the 32-bit version (Hell, try it in both Windows 32/64 and Linux 32/64.) I will bet you money you'll notice a massive difference, such as the number of objects rendered onscreen without much lag (Shadow Ops comes to mind, here, mainly.)
    • There have been several sites that have shown the benefits of 64-bit vs. 32-bit on x86. Even a simple test rendering with povray [povray.org] can illustrate this (these are my results using the benchmark scene):

      sempron 32-bit kernel, 32-bit povray, sse2, gcc 3.4
      Time For Parse: 0 hours 0 minutes 3.0 seconds (3 seconds)
      Time For Photon: 0 hours 0 minutes 53.0 seconds (53 seconds)
      Time For Trace: 0 hours 33 minutes 45.0 seconds (2025 seconds)
      Total Time: 0 hours 34 minutes 41.0 seconds (2081 seconds)

      sempron
    • Re:Not a big deal (Score:4, Interesting)

      by macshit ( 157376 ) <snogglethorpeNO@SPAMgmail.com> on Wednesday July 26, 2006 @08:30AM (#15783423) Homepage
      Apparently one of the biggest advantages of the amd64 architecture (aka x86-64) is not the 64-bitness at all (though there are some everyday benefits to that too -- e.g., visiting 1GB files in Emacs :-), but that in 64-bit mode it has more registers (not just wider ones), which allows the compiler to generate better code than it can for the anemic normal x86 architecture.
    • P.S. Sorry to be so negative, but I'm sick of hearing all this phwoar! stuff about 64bit, when it really isn't that exciting. Guess I haven't had my morning coffee yet..
      I bet you're one of these wankers that isn't using IPv6 yet, because NAT is "good enough", and it will be a little bit hard to learn a new protocol.
      Fuck off back to the dark ages, why don't you. Typewriter, ROT13 and carrier pigeons should sort you fine.
    • Re:Not a big deal (Score:3, Informative)

      by Wiz ( 6870 )
      Too many people this mistake, they just see 64-bit and think about the memory. Most of your points are valid, and are problems with running a 64-bit OS. However, you also fail to mention any benefits it provides. The most important being double the number of registers in 64-bit mode! This often makes up for the other problems with 64-bit.

      http://en.wikipedia.org/wiki/Amd64#Architectural_f eatures [wikipedia.org]
  • debian clusters (Score:3, Interesting)

    by rucs_hack ( 784150 ) on Wednesday July 26, 2006 @04:32AM (#15782527)
    I've been running a debian MPI cluster for, ooh, two years now.

    Ok, it wasn't simple getting everything to work, as it wasn't in the stable release, but I got there in the end.

    In all that time it hasn't had any problems, nd only needed rebooting when the mchines were moved once.
  • by ajs318 ( 655362 ) <.sd_resp2. .at. .earthshod.co.uk.> on Wednesday July 26, 2006 @04:33AM (#15782532)
    Many "64-bit" GNU/Linux distributions are actually partly-32-bit. There are directories /lib and /lib64 {with analogues in /usr and /usr/local} for 32- and 64-bit libraries. An application may be compiled as 32-bit and use the 32-bit libraries in /lib, or as 64-bit and use the 64-bit libraries in /lib64. You can tell whether a binary is 32- or 64-bit by doing ldd on it; if the hex numbers are 16 digits long, then it is 64-bit.

    Debian 64-bit is designed from the outset with all 64-bit libraries. /lib64 is just a symbolic link to /lib. This is both Pure and Beautiful. If you want to run 32-bit software, the recommended method is to set up a chroot environment in which to do so. The thinking is simple: software which is "i-tal" can just be recompiled 64-bit native {except OpenOffice, which demonstrates some very dubious programming techniques based around the assumption that the word length and addressing space are exactly 32 bits. OpenOffice of course began life as StarOffice, a closed-source project, and shows just what sort of bad code people will write if they don't expect anyone else ever to see it. Apparently, removal of "embarrassing" code was what delayed OpenSolaris for so long, and look what they left in! How naïve would one have to be to believe that "choosing a suitable licence" is what's really holding up OpenJava?} and software which isn't "i-tal" can go and fuck itself.

    Ubuntu have just added 32-bit libraries, to enable 32-bit applications such as OpenOffice to run. I believe they are also using a 32-bit Firefox, to allow non-free plugins such as Flash to work. It's neither Pure nor Beautiful, but it gets half the job done. Personally, I'd like to see Ubuntu play a bit faster and a bit looser with some of the closed-source stuff: maybe actually reverse-engineer it for the benefit of the whole community, rather than just kowtow to obnoxious licence agreements.
    • You can tell whether a binary is 32- or 64-bit by doing ldd on it; if the hex numbers are 16 digits long, then it is 64-bit.

      Or you could just use any half-recent version of file(1):

      $ file /bin/cat
      /bin/cat: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), for GNU/Linux 2.6.0, stripped
      $ file /chroot/deb32/bin/cat
      /chroot/deb32/bin/cat: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses

      • In ubuntu you don't even have to worry about it, just install programs with the lovely parameter --force-architecture and just run the fucking program! 32-bit Wine runs just fine like that on 64-bit Ubuntu. Don't people read the linux forums anymore, FFS? It even works with an old 16-bit software guitar tuner designed to run under Linux.
    • In real life things that are "Pure nor Beautiful" die fast.
    • Ubuntu 6.06 LTS installed 64-bit firefox by default, which disallowed me from using flash. I had to go through a procedure (found off ubuntuforums.org) to install 32-bit firefox (involved editing some Pango-related file)
  • the next Debian release will be able to run native on AMD64 processors for the first time

    Great news! I had better clear off that Gentoo distribution I have been running on it for 2 years.

  • Old "news" (Score:4, Insightful)

    by mxs ( 42717 ) on Wednesday July 26, 2006 @08:36AM (#15783491)
    The "will support" part is outdated. I have been running debian on amd64 for months. Even sarge has amd64 support.

    http://www.debian.org/ports/amd64/ [debian.org]

    The only difference is, really, that amd64 is on the official main mirrors for etch (and by that, I mean it has been for months).

    It runs great.
  • I'm already running ubuntu on amd64; i wonder if this is an example of code crossing over from ubuntu to debian?
  • Let me start off by saying what many others have been saying here, but is worthy of my saying "Hear Ye!" - Debian Stable really is a good idea. There are machines that I maintain which are remote, and crashing them would be a really bad idea. They run just fine as they are, and in fact if it weren't for the need for security updates I would never update the software. That is what STABLE means! Not only is it thoroughly tested, but unless there's a really good reason to update the package, the maintainers DO

"To take a significant step forward, you must make a series of finite improvements." -- Donald J. Atwood, General Motors

Working...