Slashdot Mirror
Debian to Run on AMD64
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."
Debian has always been more towards the stability end of the stability/feature curve. For many folks running a production server, being on the bleeding edge is very undesireable.
I for one hope that Debian never "catches up" to Ubuntu, because while Ubuntu is fantastic for desktop linux users, it's not clear that it can provide the stability needed for some production servers the way that Debian Stable does.
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
I write a blog now, you should be afraid.
There have been 64bit debian packages for some time now, they just haven't been on the stable branch.
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 well. So I suspect Debian has supported AMD64 for quite a bit now, they are just now happy enough with the support level they are making an "official" release.
It means that the person who wrote the story doesn't know what he's talking about. It's "Debian GNU/Linux 4.0" (or "Debian 4.0") -- 4.0 is the version of the Debian release, and not the Linux release.
To get something done, a committee should consist of no more than three persons, two of them absent.
No, you have that backwards. Ubuntu takes their stuff out of Debian unstable which *has* had a Pure 64bit verion out for quite a long time. If you would of RTFA first instead of jumping on your Debian trolling bandwaggon you'd see that this is an announcement of moving that into stable.
Your hair look like poop, Bob! - Wanker.
You know they've *had* 64bit support for quite a long time, this is just an announcement of it going into the stable branch.
Your hair look like poop, Bob! - Wanker.
Debian has had AMD64 support for a long time in Sid and in Etch as testing.
This is only news because when Etch moves to stable it will be the first Debian release with official support for it. Nothing new here just the normal process.
Sarge has amd64 since r1 -- it just didn't make it into r0, even though not-officially-blessed packages were provided since the day r0 was released, including official security support. The unofficial sarge-amd64 just didn't get official until a point release.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Isn't EM64T exactly AMD64 under a different "hey-look-our-competitors-totally-didn't-invent-th is" name?
I believe Debian refers to "AMD64" because they (AMD) invented the technology, some work to port Debian into AMD64 began and then (much later) Intel released EM64T... So the name stuck. The official name should be x86_64.
"This will be the first official release to include the AMD64 architecture."
Anyone can "stand up for what they believe", but it takes a very brave individual to change what they believe. - Loundry
Granted, Sarge using a 2.4 kernel as default for the installer wasn't sharp. You *can* boot with a 2.6 kernel very easily by entering "linux26" at the boot screen instead of just hitting enter. That get's you up and running on the majority of "Modern" stuff.
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? /home directory on a seperate partition, that makes things a lot easier. :-) ;-)
You seem to have a fast processor, so it shouldn't take long time.
I hope you have your
I have moved my system a few times from one harddrive to another using this procedure and it worked quite well.
And don't forget: 0) backup your data before beginning (but I guess to mention this on slashdot gets moderated "-1 redundant"
You have to reinstall but that can be done quite easily (make a backup though): /etc you want to keep /home, parts of /var, etc) /etc, /home, /var and others
- save the output of dpkg --get-selections
- save the output of debconf-get-selections
- save the important parts of
- save other directories (e.g.
- do a minimal amd64 install
- restore the saved parts of
- 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.
Don't run Debian unstable. Run Debian testing instead. Debian testing is very stable and is as current as Ubuntu. In practice, you will probably have less bad surprises with Debian testing than with Ubuntu with universe + multiverse enabled. I am running several servers on Debian testing (i386 and AMD64) and I never had any problems with it. I also tried Debian unstable for a while, but went back to testing quickly because it was not stable enough.
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 %.
This is old news/dupe: Debian told that on their announcement about 4.0 ( http://www.debian.org/News/2006/20060724 ), to which slashdot has linked in a previous article (http://linux.slashdot.org/article.pl?sid=06/07/24 /1830228 )
I've been running 64-bit Debian on the AMD64
since March. The guy who wrote this story appears
to be unaware of facts.
What Debian mean by "stable" and "unstable" has about as much to do with how likely the software is to fall over, as what RMS means by "Free software" has to do with how much it costs. Stable or Unstable refer to the distribution, not the packages within it.
Debian Stable {each release is codenamed after a character from the movie Toy Story} is a release that stays, well, stable. It contains software that has been proven ultra-reliable on a dozen different architectures; and, as far as possible, nothing will adversely affect the operation of anything else. Security patches get backported in, but the main requirement is that nothing should change too much as long as Debian Stable is current. Doing a simple apt-get update && apt-get upgrade will never break anything if you are running Stable. When a new Stable is released, it invariably includes automated migration tools to deal with new configuration file formats &c. These run transparently as part of the upgrade process, ensuring as smooth a transition as possible.
Debian Unstable {aka SID, for "Still In Development" and also named after the destructive neighbour} is a release that is constantly changing. It is the combination of packages that is unstable, not the software itself: Unstable contains software that is believed to be mostly reliable on at least some of a dozen different architectures. However, due to the fact that the packages in Unstable are updated one-by-one rather than all at a time, there is the possibility of incompatibilities creeping in: one piece of software can affect another. It's also possible that APIs and configuration file formats may change.
Somewhere between lies Debian Testing. Once a package has proved its worth in Unstable, it moves to Testing -- but not until. If necessary, packages may remain absent altogether from Testing while compatibility issues are resolved (in which case, you will have to get the Stable or Unstable source code and build that; one or the other usually works). Eventually, Testing will be used to create a new Stable.
Debian Unstable or Testing are the best releases to use for desktops. Stable is really only for servers in co-lo, where you cannot get physical access to the machine to reboot it if it goes Tango Uniform. Thanks to Debian's rigid enforcement of the Free Software Guidelines (which went on to become the Open Source Definition), it's also very easy to keep everything "i-tal" on a Debian system.
Je fume. Tu fumes. Nous fûmes!
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.
/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.
Debian 64-bit is designed from the outset with all 64-bit libraries.
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.
Je fume. Tu fumes. Nous fûmes!
Unfortunately you can't mix 32-bit and 64-bit programs and libs, or so it seems. For example, I can't play windows codecs using a 64-bit MPlayer because Wine doesn't yet support running win32 code in a 64-bit executable/library. So you have to use a completely 32-bit MPlayer + libavcodec + libwine if you want to use the Win32 WMV or Quicktime codecs. Or at least that was the case a few months ago when I spent a few days wrestling with compiling Wine and the other libs trying to get it all to work. In the end I installed a 32-bit chroot environment and run 32-bit MPlayer from there.
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
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 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 64-bit kernel, 32-bit povray, gcc 3.4
Parse Time: 0 hours 0 minutes 2 seconds (2 seconds)
Photon Time: 0 hours 0 minutes 49 seconds (49 seconds)
Render Time: 0 hours 35 minutes 50 seconds (2150 seconds)
Total Time: 0 hours 36 minutes 41 seconds (2201 seconds)
sempron 64-bit kernel, 64-bit povray gcc 3.4
Parse Time: 0 hours 0 minutes 1 seconds (1 seconds)
Photon Time: 0 hours 0 minutes 41 seconds (41 seconds)
Render Time: 0 hours 28 minutes 45 seconds (1725 seconds)
Total Time: 0 hours 29 minutes 27 seconds (1767 seconds)
No, the article is incorrect, because it leaves out the "Debian" from the name, and just says "GNU/Linux 4.0" instead of "Debian GNU/Linux 4.0".
To get something done, a committee should consist of no more than three persons, two of them absent.
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.
f eatures
http://en.wikipedia.org/wiki/Amd64#Architectural_