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."

10 of 135 comments (clear)

  1. Link is (was?) broken by lnunes · · Score: 5, Informative

    Read about it here: http://wiki.debian.org/Multiarch

    1. Re:Link is (was?) broken by mkkohls · · Score: 5, Funny

      Read about it here: http://wiki.debian.org/Multiarch

      The link wasn't forgotten. It's Debian and as such the community is supposed to provide the links.

    2. Re:Link is (was?) broken by tanderson92 · · Score: 3, Informative

      Wait isn't that what Gentoo was doing since well, forever?

      Not really, Gentoo has native multilib support, not native multiarch support. And as I understand it, Debian's multiarch support is much more integrated than Gentoo's crossdev efforts at multiarch.

  2. Wheezy by Frankie70 · · Score: 3, Funny

    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.

  3. Re:/lib64 is not enough by Guy+Harris · · Score: 4, Interesting

    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.)

  4. Re:/lib64 is not enough by jimicus · · Score: 3, Insightful

    (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.

  5. Re:/lib64 is not enough by bgat · · Score: 4, Interesting

    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.
  6. Re:Great Idea by bgat · · Score: 3, Interesting

    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.
  7. Re:Party like its 2004 by KiloByte · · Score: 3, Informative

    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.
  8. More information. by mmj638 · · Score: 4, Informative

    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.