Slashdot Mirror
Debian Wheezy To Have Multi-Architecture Support
dkd903 writes "Debian has announced they are introducing support for multiarch in Debian Wheezy. Multiarch support means a Debian system will be able to install and run applications built for a different target system."
i tagged it as typo, but the link is still broken
that that
that that
that that
that
that that
Read about it here: http://wiki.debian.org/Multiarch
I guess the best way to prevent people from reading TFA is to not post a proper link...
Anyway, here is the Debian announcement.
It's annoying when I want to run some 32-bit binary that depends on a few libs missing from my system, and I often can't install them from the package manager. The Ubuntu 64-bit repositories have a few common 32-bit libraries in distinct "64-bit" packages, but it's not handled as nicely as Fedora does it, which lets you see and install just about any 32-bit rpm packages on a 64-bit machine easily and properly.
When the href is finally added, can we please make sure it's to the debian release rather than the link provided in the submission? Slashvertisements are depressing.
Viable Slashdot alternatives: https://pipedot.org/ and http://soylentnews.org/
Is it powered by drugs and cough syrup?
Woot! Only 7 years late to the party Debian.
Not sure about what they mean with multi arch. Should it be like Mac OS X and its use of fat Mach-o binaries? I think something alike can be implemented on Linux through the use of FatELF. That is, the same binary can run on every supported arch.
It means they are finally supporting the part of LSB that defines /lib64 for x86_64 libraries which has been part of the standard for like 7 years now.
The proposed solution appears to be needlessly more complicated than how Fedora handles it, for minimal benefit. It looks like they just want to be different. From TheCaseForMultiarch, they say they didn't adopt the lib and lib64 system because it would have been too much work changing their package management tools (remember RPM dependency hell, and how apt is so much better?).
We have both the case of a mostly 32bit system with some 64bit libs/binaries and a mostly 64 bit system with some 32bit libs/binaries. Ideally they would be treated the same. So what goes in /lib? It may need to exist for legacy reasons, should it be a symlink to /lib32 or /lib64?
Well, lib has the 32 bit libraries as usual and lib64 has the 64bit libs. It's the same in either case. And you don't even need to invent lib32. But that solution isn't complicated enough, and is already used by other distributions, so fuck that, let's invent something else.
It's even stupider than the FatELF idea of combining 50 different binaries into the same file.
Wait a minute... They didn't support i386 binaries on x64 before? O_o
I thought that it will support PPC binaries on x64 or something...
No, they are explicitly *not* doing that. /lib64 is a narrow solution to the more general problem of multi-architecture support.
The new approach here is to put e.g. Linux/amd64 libraries in /usr/lib/lx86_64-unknown-linux-gnu/. The hope is that a future revision of the FHS will incorporate this.
Original submission had the link correctly. Timothy replaced it with a bad one.
Looks like Wheezy will finally get a piece of the pie.
I bet it took a whole lot of trying just to get up that hill.
Now that they are up in the big leagues, they will get their turn to bat.
And I don't think there is anything wrong with that.
It will become glibc-linux plus a truckload of other stuff. RMS will be spinning in his grave!
Now I can play those Mac games! Debian so rocks! Or is that not what they meant?
I actually really like this idea. I do a lot of embedded development and it would be AMAZING to be able to compile ARM or run an ARM directly, or not just ARM but even x86.
This is the quality you come to expect from the wonderful world of open source!
Cathedral and the Bazaar
Millions of eyes
Blah,blah,blah...
PS. Did you submit a patch???
.......that we're not going to get another Debian release for another fifty years?
at the risk of feeding trolls, when will they update Wine?
So you can run STABLE on both a TOPS-20 *AND* an 80286!!! :D
did you accidentally the whole thing?
Didn't Solaris sort this out over a decade ago?
although the feature is still vaporware, chinese Loongson 3 CPU stand to benefit from this as they feature hardware-assisted x86 emulation (using QEMU on the process). it's broken on the loongson 3A, but hopefully will work on 3B and up.
comments about /lib32, /lib64 miss some of the point, here we would want to run most things on MIPS 64, and some stuff, maybe windows games through wine, on i386 arch. that's potentially two arch with both 32bit and 64bit variants. another case would be running on a 32bit ARM CPU and run 32bit x86 software through emulation.
in general terms, debian run on a lot of architectures anyway, so supporting only two sub-archs as on other distros doesn't cut it :)
Does this come bundled with his latest single?
You cannot warp because you are warp scrambled.
Free Wheezy!
is that it allows the package manager to co-install packages of two different architectures in certain cases. This means that you can install a 32-bit Firefox (if you have some proprietary plugin) and have the rest of the system be 64-bit. Or you can install most of the packages from the armel port (ARM EABI soft-float) and install floating-point intensive ones from the armhf port (ARM EABI hard-float).
Previously, in order to install any meaningful amount of i386 software on an amd64 system, you had to install a package called ia32-libs, and if it didn't have the library you needed, you were SOL. Now you can install i386 libraries in parallel.
This is how it works in theory. Not all packages will be updated to be multiarch aware immediately, so YMMV.
Unfortunately, this is deceptively bad.
The point isnt to support lots of platforms, it's to allow x86 run on x86_64 platforms. In theory it's fantastic but the reality is that this will enable people to be lazy in that they will only release a build for x86 and just ignore all about 64-bit platforms because they can. While it would be great, not every Linux application or game is open source. Why make a 64-bit build when it can cause incompatibility because of bad coding practices? Even with open source, developers on a 32-bit systems will feel no need for 64-bit binary packages if their 32-bit stuff works on everything.
This is enabling people to release for ONLY the x86 platform. Will companies release for x86_64 if you demand it? YES! It happened with Flash and companies are realizing that a ton of people use 64-bit.
Look at Windows, there are a TON of new applications that are released only as a 32-bit build.
x86 is obsolete, we are in a 64-bit world now. Stop letting people hold us back!
Anons need not reply. Questions end with a question mark.
The summary is terrible. And not just the invalid link.
Here's a more informative link than the one posted by lnunes.
Multiarch is not gonna let you run ARM binaries on an Intel chip or anything like that - nor will it let you run Windows code on Debian. What it will do, however, is let you run x86 compiled binaries on an x64 system. It will also allow for things like mixing armhf and armel code on modern ARM, but for the most part, running 32-bit x86 code on 64-bit x64 (amd64) systems will be the benefit most of us will get.
How will we benefit? You'll be able to run binary-only x86 code on your x64 system. This means Adobe Flash and Skype. Any open source code is fine, because it can be compiled for your own architecture - but for binary-only proprietary software, it may not be available for your architecture.
"But this is already possible" you may be thinking. It is, but it's a nasty kludge at the moment. These packages, when installed on 64-bit systems, depend on 32-bit versions of several system libraries, which are separate packages. There's a series of kludges to make them work, and it's not very flexible.
The heart of multiarch support is a re-designed file system layout which accounts for the architecture of any binaries. So instead of putting some binary libraries in /lib/, it puts it in /lib/amd64/ or /lib/i386/. This is the first step for allowing the same package to be installed for different architectures. Then, dpkg will have to be modified to track packages from more than one architecture on the one system.
But can the kernel run on multiple different architectures simultaneously? I heard another kernel that goes by the name of NT can. Now that might sound like a odd option to build in, but consider ARM and x86 in the same machine, optimized for power usage, especially if intel can't get their shit together on the very low end. Just thinking out loud here, and rather off-topic.
so that takes away about 90% of the coolness factor
This multiarch support is no hot innovation. For years, NetBSD has been able to cross-build the entire system and offer 32 bit binary compatibility on 64 bit architectures.
After all Disney has done for cultural freedom, it's nice to see Debian is still honoring their properties with its OS names.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
they should just concentrate on a pure 64-bit system and drop 32-bit completely.
Oops, actually we are in the 2010s already..
I just want to let all of you know that Qemu has been doing for all the various architectures just fine. I am native DEC Alpha environment of Linux, using Qemu to introduce a x86-Linux build environment to run Wine-x86, and then running another emulator in Wine just so I can get through to some actual user-land.
Feels good man, since 1997, and Debian is slow to catch-up as usual.
It's difficult for an asthmatic to even hear the word "wheezy" and not reach for an inhaler.
How different is Multiarch from the OSF's Architecture Neutral Distribution Format (ANDF) and Java's Bytecode? This thing sounds great - assuming it actually works
nothing