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."
This is great news! I do contracting work for Maas Digital, 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), we had to move away from Debian to Gentoo for this reason (among others), so it's good to see it finally being
Stupid question: What does the 4.0 mean?
I'll probably be modded down for this...
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.
*joke rimshot*
---southpaw
There have been 64bit debian packages for some time now, they just haven't been on the stable branch.
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...
Exactly. The whole idea of different distributions is that they address different market segments. People who complain that other distributions aren't more like their favourite distribution are completely missing the point.
http://www.debian.org/News/2005/20050811
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.
Perhaps you'd like to name drop a few more companies while you're at it!
READY.
PRINT ""+-0
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.
Parent will burn some Karma, so I'll join.
... ar Stable. The packages are all so old (3 or 4 years at least) that many of them are no longer usable. And I'm not talking about ... vim ... for vim it does not make a difference. I'm talking about thinks like OpenOffice 1.1.3 ... that does not even support ODF so I cannot even open my documents made years ago. The same thing holds for a lot of programs (things like browsers, instant messagers, gnuplot, many kde programs, etc.). So what I (and lots of my collegues) do is to install the new versions from source in my home directory. And because all libraries are very old ... ar. stable my home directory has about 3GB now. I would even use a Live DVD of some decent distribution if I was allowed to do so.
What he says is totally true. I have the pleasure to be a student in a university that uses Debian Obsolete
So Debian planning to catch up a little is great news. However, many of you don't realize how far behind they are.
If you don't fail at least 90 percent of the time, you're not aiming high enough. (Alan Kay)
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?
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?
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.
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..
Will program for karma.
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!
I run Debian unstable on my home computers and Debian stable on my servers. That way I get lots of experience reparing debian, while having very reliable servers. It works quite well, in that every time another stable release is made, I already know the ins and outs of it and I'm ready to fix it in the freak chance that it would break.
Never eat more than you can lift -- Miss Piggy
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!
I was waiting for someone to use the same old tag... Oh... Debians so fucking old.. Why would anyone use something so old??? Dude... get with it. Being old doesn't mean you're wrinkly and saggy. Being old means you have wisdom and experience.
Back in the heady days of Linux Kernal 2.0 every version of the kernel (or anything else for that matter) had significant advances in capabilities and hardware support. If you purchased a digital camera that didn't work today, wait maybe a month and it will be. That was my experience with a Kodak DC220 camera. It took something like 4 to 6 weeks for the support needed to crystalize. Any one can come up with more examples. I have many myself. The point is that there was a respectable probability that your recent hardware purchase would not work out of the box but would either by compiling the latest binaries of the kernel and 12 libraries or waiting a month.
Speed things up to 2006. The type of support advancement that is required to support newer hardware is much slower today than it was then. Today there is a better than average chance anything you buy will work out of the box with linux. The need to keep up on the cutting edge of software is not nearly as strong as it was 6 years ago.
You might argue that not having SATA support in the default kernel is significant but it's hard to find a computer that doesn't support EIDE hard drives. It's also reasonably sane to build a RAID system with a boot EIDE and a RAID STAT data set instead of trying to put everything on one RAID system.
I recently spent a day installing Debian for an AMD64 machine that was fricking HUGE. It completely fell on it's ass when it came time to support the video card. It turns out that the video card problem wasn't the fault of Debian but NVidia. No drivers available for AMD64 for that newer card completely roasted the installation. I accidentally picked up the 32-bit version of the card and also affected teh NVidia drivers for the network connections. So when I toasted the video, I also toasted all the network connectivity.
In the past year, I have had MORE problems with proprietary drivers of this nature (NVidia video in particular) in their inconsistent support. But it's the price I pay for choosing their product. Some of this is Debian licensing, some of it is definitly not.
While it can be argued that Debian is slower on it's releases, this commitment to a December 2006 release is pretty fast compared to past cycles. And those who use Debian choose a system stability over system candy. You have no idea how fun it is when a routine security patch and upgrade happens to upgrade a whole bunch of really important stuff like DNS/DHCP on your SuSE box and you realize you've just crashed your entire home network. Add to that the wife and kids are all working on term papers due within the next week. Your life isn't worth much then.
I'll take stability every time.
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/
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.