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."
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.
Is it powered by drugs and cough syrup?
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.
So they are doing it in a stupid way to be different?
No, they're doing it a different way to solve a broader set of problems, as their rationale says. Feel free to debate whether the problems they claim to be solving are worth solving, or whether their solution is the right one for those problems, but don't claim they're just being stupid until you've read the rationale. (I don't have a dog in this fight; the OS I use and develop for/on uses fat binaries for the multi-architecture part of that. I'm just noting that there's a rationale to read before concluding that they're just being different to be different.)
.......that we're not going to get another Debian release for another fifty years?
(Disclaimer: I actually rather like Debian, even if the likes of Ubuntu have made it unfashionable)
Knowing the good people behind Debian, it'll be an absurdly over-engineered solution that will only be supported by software in the Debian repository. And it'll be rather poorly documented so figuring out exactly how it's been done will be an exercise in frustration. But once you've figured it out - and provided you're only using packages in the repository - it'll be beautifully elegant and work so nicely you'll wonder why nothing else works the same way.
No. Your reaction illustrates that you don't understand what you are talking about.
LSB says that /lib64 is where x86_64 libraries go on x86_32 machines, but says nothing about any other machine architectures and/or combinations. The problem itself is not x86/x86_64-specific, however, so the LSB-specified solution is incomplete.
The LSB is wrong. Debian is solving the problem correctly.
The fact that "something has worked just fine for Red Hat for years now" only reflects the fact that Red Hat doesn't focus anywhere other than x86. For that and several other reasons, Red Hat is a toy operating system as far as I'm concerned.
b.g.
It generalizes to cases larger than 64-bit vs. 32-bit. Big-endian vs. little-endian, hardware FPU vs. software FPU emulation, etc.
b.g.
It makes that possible, yes. Combine that with tools from the emdebian project, and you have one wicked embedded Linux development environment AND runtime platform. I for one am following this development closely; I have been using emdebian tools for almost two years now, having them supported in the mainline Debian installations via Multiarch is a huge step forward. Indescribably huge.
b.g.
32 vs 64 bit isn't the only reason to want something like this. What about systems that happen to provide support for another binary format with hardware translation?
did you accidentally the whole thing?
Actually, it hasn't worked fine. That is exactly why Debian want to change it.
You may not be a distribution developer, but the folks are Fedora/RedHat and Debian/Ubuntu and so on, so have to deal with it.
If something is easy for you, that doesn't mean they didn't spend a lot of time on it to make it so.
New things are always on the horizon
Uhm no, this is not bi-arch crap that keeps dragging us down -- as in, 32 bit libs on a 64 bit system. This is about having any library and any header co-installable with its versions from other architectures. Just think how much easier this makes cross-building things...
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
I asked a friend who's a core debian member. His answer - when someone gets interested in it.
So... you can be the guy in charge of wine for debian if you're interested.
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.
Faulty premise. You're assuming there's more than one monkey working on slashcode, when in fact it's just soulskill working on his lunchbreaks.
Linux, you magnificent bastard, I read the fucking manual!
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)