Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Debian Wheezy To Have Multi-Architecture Support

timothy posted more than 3 years ago | from the install-whereever dept.

Debian 135

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

Sorry! There are no comments related to the filter you selected.

anyone home? (0)

Anonymous Coward | more than 3 years ago | (#36913522)

i tagged it as typo, but the link is still broken

Re:anyone home? (1)

RudeDude (672) | more than 3 years ago | (#36913558)

I tried to tag it as "badlink" and by accident ended up with multiple incorrect tags that I can't delete. What a winning interface.

Re:anyone home? (1)

MichaelKristopeit421 (2018882) | more than 3 years ago | (#36913712)

slashdot = stagnated

Re:anyone home? (0)

Anonymous Coward | more than 3 years ago | (#36913860)

Seconded

The Premier Open Source Website (0)

Anonymous Coward | more than 3 years ago | (#36913992)

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???

Re:The Premier Open Source Website (2)

Captain Splendid (673276) | more than 3 years ago | (#36916486)

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.

percussion (0)

Anonymous Coward | more than 3 years ago | (#36913550)

that that

that that

that that
that
that that

Link is (was?) broken (5, Informative)

lnunes (1897628) | more than 3 years ago | (#36913560)

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

Re:Link is (was?) broken (5, Funny)

mkkohls (2386704) | more than 3 years ago | (#36913636)

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

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

Re:Link is (was?) broken (0)

Anonymous Coward | more than 3 years ago | (#36913746)

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

Re:Link is (was?) broken (3, Informative)

tanderson92 (1636327) | more than 3 years ago | (#36914076)

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.

Re:Link is (was?) broken (1)

wagnerrp (1305589) | more than 3 years ago | (#36916274)

The AC was referring to the fact that Gentoo just gives you the source, and makes you compile your own binaries. In effect, their 'packages' run on every arch, just with a bit of delay.

Re:Link is (was?) broken (1)

martin-boundary (547041) | more than 3 years ago | (#36916864)

That's not multi-arch though, because you compile the package for the arch that hosts the compiler only.

Re:Link is (was?) broken (1)

wagnerrp (1305589) | more than 3 years ago | (#36917162)

You are correct. It was intended as a joke.

where is TFA? (2, Informative)

Anonymous Coward | more than 3 years ago | (#36913574)

I guess the best way to prevent people from reading TFA is to not post a proper link...

Anyway, here is the Debian announcement. [debian.org]

Re:where is TFA? (1)

dirtyhippie (259852) | more than 3 years ago | (#36913686)

The misleading summary helps, too.

Hope Ubuntu gets this change eventually (0)

Anonymous Coward | more than 3 years ago | (#36913602)

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.

Re:Hope Ubuntu gets this change eventually (1)

yincrash (854885) | more than 3 years ago | (#36913678)

This is in Natty. See Here [ubuntu.com]

What a joke (0)

Anonymous Coward | more than 3 years ago | (#36913792)

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 [debian.org] , 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.

Re:What a joke (2)

gmack (197796) | more than 3 years ago | (#36914354)

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?

Re:What a joke (0)

Anonymous Coward | more than 3 years ago | (#36914660)

I think you need to re-read the FHS.

Well, lib has the 32 bit libraries as usual and lib64 has the 64bit libs. It's the same in either case.

No it isn't. */lib without a qualifier should contain the native libraries. For a 64bit userland, that means lib is 64bit and you need a separate place for 32bit. I suggest you start complaining about how this is a technical solution for an organizational problem if you're of the bickering kind, but at least stop being disinformed.

And you don't even need to invent lib32.

Because all 32-bit environments are equal? 32bit kfreebsd is the same as 32bit linux? 32bit x86 is the same as 32bit arm?

But that solution isn't complicated enough, and is already used by other distributions, so fuck that, let's invent something else.

There is no solution used by other distributions, just band-aids and stopgaps. Which distribution is currently shipping cross-compile environments? Which distribution has a solution that extends beyond Intel's architecture?

It's even stupider than the FatELF idea of combining 50 different binaries into the same file

FatELF was just stillborn, not misconceived. It will be revived once heterogeneous computing gets a little more mainstream. We're almost at the point where programs will be needing a platform-wide solution for delivering OpenCL-kernels.

Re:What a joke (1)

chronokitsune3233 (2170390) | more than 3 years ago | (#36917172)

Actually the FHS states specifically for AMD64, PPC64, s390x and sparc64 that native (64-bit) libraries go in /lib64 while 32-bit (31-bit for s390) libraries go in /lib because the number of 32-bit binaries/libraries are expected to far outweigh the number of 64-bit binaries/libraries. It also states specifically for IA-64 that native (64-bit) libraries go in /lib as it reflects the deprecation of 32-bit binaries (and libraries) on that architecture.(source) [pathname.com] For any other architecture, 64-bit or not, /lib32 and /lib64 might coexist with /lib being a symlink to one of them.(source) [pathname.com] I presume that */lib and */libXX would be expected to be similar to /lib and /libXX. After all, who wants 64-bit binaries in /lib and 32-bit binaries in /lib32 but 64-bit libraries in /usr/lib64 and 32-bit libraries in /lib? However, the last version of the FHS was completed in 2004. Some deviation should be expected, especially when you consider how many 64-bit distros are in use compared to back then. It has been seven years after all. Time for a new FHS version? :)

The original submission was a self-serv ad anyway. (1)

gcnaddict (841664) | more than 3 years ago | (#36913646)

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.

Wheezy F Baby... (2, Funny)

Anonymous Coward | more than 3 years ago | (#36913666)

Is it powered by drugs and cough syrup?

Party like its 2004 (0)

HarrySquatter (1698416) | more than 3 years ago | (#36913708)

Woot! Only 7 years late to the party Debian.

Re:Party like its 2004 (1)

DemonGenius (2247652) | more than 3 years ago | (#36913978)

Better late than never I suppose. This is good news nonetheless, makes it easier for us Debian/Ubuntu fans to use a 64bit OS. Score one more point for the Linux world!

...*Ahem*, I mean GNU/Linux world, there, happy RMS? :)

Re:Party like its 2004 (3, Informative)

KiloByte (825081) | more than 3 years ago | (#36915338)

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

Re:Party like its 2004 (0)

Anonymous Coward | more than 3 years ago | (#36916126)

Hmm? Nobody else is multiarch yet. Biarch and other such crap, maybe. Real multiarch? None.

Fat Binary or just some kind of FS organization? (1)

ulzeraj (1009869) | more than 3 years ago | (#36913720)

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.

Re:Fat Binary or just some kind of FS organization (0)

HarrySquatter (1698416) | more than 3 years ago | (#36913770)

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.

/lib64 is not enough (1)

Anonymous Coward | more than 3 years ago | (#36913836)

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.

Re:/lib64 is not enough (-1)

HarrySquatter (1698416) | more than 3 years ago | (#36913884)

So they are doing it in a stupid way to be different? Go Debian! Yeah, let's not follow something that has worked just fine for Red Hat for years now. Let's be incompatible to be incompatible!

Re:/lib64 is not enough (0)

Anonymous Coward | more than 3 years ago | (#36913954)

This is Debian. Clearly, anyone else doing anything different are the incompatible problems and are thus diluting the name of The One True Linux. Retroactively, if need be. That is the Debian Way. That is all that needs to be known. Thank you for your time. The Debian Way is good. The Debian Way is right. Remember to curse the heathen Ubuntu users who fell to the power of the Dark One on the way out, citizen.

Re:/lib64 is not enough (1)

Anonymous Coward | more than 3 years ago | (#36913966)

Ah, so you're retarded, gotcha.

Hint: RedHat solved a very narrow problem with x64/x86 only. Debian's solution is far more general. But, of course, you'd have to actually read the fucking article to understand that... assuming, of course, you're capable of reading and comprehending it, which, judging by your comment, seems unlikely.

Re:/lib64 is not enough (-1, Troll)

HarrySquatter (1698416) | more than 3 years ago | (#36913990)

Yes, Debian has constructed a far more complicated and overengineered solution that will most likely be far more painful of a transition than it needs to be. Woot!

Re:/lib64 is not enough (0)

Anonymous Coward | more than 3 years ago | (#36915340)

I'm running a debian/unstable system that's already begun to be multiarch (that's right, packages can move piecemeal to the new system). The only glitch so far has been with a nonfree package, the fglrx driver, and that was sorted in a couple of days (and not just for fglrx), now you just use update-alternatives group glx to choose which OpenGL implementation to enable.

Re:/lib64 is not enough (0)

Anonymous Coward | more than 3 years ago | (#36917696)

I see you've mastered the art known as Shatner Comma.

Re:/lib64 is not enough (4, Interesting)

Guy Harris (3803) | more than 3 years ago | (#36913980)

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 [debian.org] 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.)

Re:/lib64 is not enough (0)

Anonymous Coward | more than 3 years ago | (#36917914)

There is one particular case where support for more than two architectures would be useful: HJ Lu has been developing an x86 architecture variant for 64-bit code with 32-bit pointers, in order to get extra performance for some applications.

The issue is that some applications store so many pointers in memory that their performance is determined by how many pointers you can fit in the caches. Similar solutions have proved to give a performance boost on Sparc and MIPS, so you can expect an even larger performance boost on x86, where 64-bit mode doubles the number of general-purpose registers.

Re:/lib64 is not enough (0)

Anonymous Coward | more than 3 years ago | (#36914004)

Debian is building a solution that should in principle allow libraries of arbitrary architectures to be installed in parallel on a single system. The x86/AMD64 issue is just a single case of this problem. Also, the problem is mostly how to get different Debian packages to interact with each other, i.e., how to correctly resolve dependencies. Not this oversimplification of just where to put the library files themselves in filesystem (which has been solved for quite a while).

Re:/lib64 is not enough (3, Insightful)

jimicus (737525) | more than 3 years ago | (#36914218)

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

Re:/lib64 is not enough (4, Interesting)

bgat (123664) | more than 3 years ago | (#36914258)

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.

Re:/lib64 is not enough (1)

Anonymous Coward | more than 3 years ago | (#36914926)

Red Hat is a toy for targeting architectures that are actually relevant? That doesn't make Red Hat a toy OS; it makes Red Hat a distribution built by a company that needs to keep the lights on and pay its employees.

Re:/lib64 is not enough (1)

RobbieThe1st (1977364) | more than 3 years ago | (#36916948)

And it seems to me that Debian can simply make a symlink from the new x86_64 directory to /lib64 for compatibility's sake, if it's ever needed.

Seems like a great addition for compiling for ARM on amd64 or any other combination you can think of.

Re:/lib64 is not enough (1)

bill_mcgonigle (4333) | more than 3 years ago | (#36917294)

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.

Even at that, one of the hardest linux sysadmin things I've done has been to upgrade live systems from i686 to x86_64, allowing for only one quick reboot. Having proper coexistence would make this task much more straightforward.

I like Fedora-derived distributions, but Debian is making an improvement here. I hope Fedora follows suit.

Re:/lib64 is not enough (2)

Lennie (16154) | more than 3 years ago | (#36914670)

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.

And before? (0)

Anonymous Coward | more than 3 years ago | (#36913828)

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

Re:And before? (1)

Lennie (16154) | more than 3 years ago | (#36914690)

They do, but their are not happy with the way it is handled now in Linux distributions. They want to improve it.

Correct Link (1)

Frankie70 (803801) | more than 3 years ago | (#36913838)

Original submission [slashdot.org] had the link correctly. Timothy replaced it with a bad one.

Wheezy (3, Funny)

Frankie70 (803801) | more than 3 years ago | (#36913878)

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.

Re:Wheezy (2)

commisaro (1007549) | more than 3 years ago | (#36913944)

Clearly I'm not the only one who read the whole summary in auto-tune.

No more GNU/Linux (0)

Anonymous Coward | more than 3 years ago | (#36913902)

It will become glibc-linux plus a truckload of other stuff. RMS will be spinning in his grave!

Re:No more GNU/Linux (1)

SnarfQuest (469614) | more than 3 years ago | (#36914676)

Don't you mean GNU/RMS?

At Last! (1)

Skewray (896393) | more than 3 years ago | (#36913914)

Now I can play those Mac games! Debian so rocks! Or is that not what they meant?

Great Idea (1)

Murdoch5 (1563847) | more than 3 years ago | (#36913930)

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.

Re:Great Idea (1)

Murdoch5 (1563847) | more than 3 years ago | (#36913940)

I should explain, x86 because I run all 64bit Desktops and x86_64 AND x86 aren't always directly compatible even with kernel support. I usually end up running a chroot for i386.

Re:Great Idea (1)

HarrySquatter (1698416) | more than 3 years ago | (#36913950)

This is about having both 64-bit and 32-bit libs on the system at once and implementing the filesystem paths to support this.

Re:Great Idea (1)

Murdoch5 (1563847) | more than 3 years ago | (#36914022)

There are a lot of times when multi-libs don't work well. Hence running a chroot i386 environment. I'm not saying it's not possible, I know it is but the success rate has always been poor.

Re:Great Idea (0)

Anonymous Coward | more than 3 years ago | (#36915266)

That's mostly because of issues this long-planned full "multi-arch" support fixes though. Really, it mostly comes down to having /usr/lib/i386-linux-gnu/ and /usr/lib/x86_64-linux-gnu/ instead of just /usr/lib/, but agreeing on all the details has apparently taken quite a long time.

Re:Great Idea (2)

bgat (123664) | more than 3 years ago | (#36914288)

It generalizes to cases larger than 64-bit vs. 32-bit. Big-endian vs. little-endian, hardware FPU vs. software FPU emulation, etc.

Re:Great Idea (0)

Anonymous Coward | more than 3 years ago | (#36914078)

That's possible already. Qemu can provide seamless execution of foreign binary formats, provided enough userland libraries are present in the emulated binary format to satisfy dependencies. I've built software for both PPC and Arm that way, just to try it out. It's not mature yet, but it's interesting stuff. It works best if the foreign architecture's in a chroot. Check out debootstrap-qemu.

Re:Great Idea (3, Interesting)

bgat (123664) | more than 3 years ago | (#36914304)

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.

Re:Great Idea (1)

Murdoch5 (1563847) | more than 3 years ago | (#36914432)

+5, ya I can't wait, this will be a very nice system.

COLLEGE BOY BLOWS IRAQI SNIPER WHILE GIRLFRIEND SL (-1)

Anonymous Coward | more than 3 years ago | (#36914026)

PITTSBURGH, U.S.A. — When I was a sophomore in college I got a job bussing tables at a Syrian restaurant. One of the cooks was named Hannad and he was from Iraq. He scared the shit out of me. He was built like a brick shithouse, with crude tattoos lining his hands and powerful arms. He had a handsome but rough face and he was missing some of his teeth.

He made no effort to hide his dislike of me. Every time I came back into the kitchen he would fix me with this intense, hostile gaze. He told people that he’d been a sniper in the Iraqi Army. I had no doubt that he’d killed — you could see it in his eyes — and I was this skinny white gay boy who’d never done anything worse than shoplifting. I dreaded every encounter with him.

I worked there for over a year and eventually I became a waiter, which meant a lot more interaction with Hannad, and I guess we reached a sort of truce. He wasn’t my friend but he wasn’t set on intimidating me anymore, either.

Then one night I was out at the bar with some friends when I spotted him off in the corner. Feeling bold cause I was buzzed, I walked over to him and said hi. We started having an actual conversation, and I realized, as it got later and we got drunker, that he was flirting with me. He pointed to a girl in a red dress, said something about the color red, then showed me, by lowering the waistband of his nylon pants, that he was wearing red underwear. It was a pretty obvious overture and it made me half hard. When the bar let out he said, ‘You come with me.’

I thought we’d go back to his place but instead he took me to a diner, like we were on some weird date. He said that there were Iraqi men who performed songs about loving young boys. I was twenty-one at the time but I had a boyish, innocent look, and I guess he responded to that.

We went back to his apartment and ended up on his bed. I rubbed his soft dick through the crotch of his nylon pants. As he got erect he kissed me roughly. He was all brute strength, throwing me back on the bed and holding me down while he took off his clothes. He took out his cock, which wasn’t anything spectacular but it was hard. I blew him for a while and then he wanted to fuck me. I wasn’t used to getting fucked, but I was too afraid to say no to him. So I let him hold me back on the bed and toss my legs over my head. He did not take his time — it hurt like hell! He was rough and unforgiving and after awhile I had to make him stop. I finished by sucking him off and letting him cum all over my face.

After that night, we got along famously. He drafted me as his workout partner and I joined his gym. After my first weight-lifting lesson we went back to his place and sat on the couch, pleasantly tired and weak-muscled. He put on some porn, and eventually I reached over to feel his erect cock. I took it out — it was dank and sweaty — and leaned over to blow him. I had more fun this time, I felt more relaxed with him. I held on to his balls — he wouldn’t let me get anywhere near his ass — and sucked his little cock for all it was worth. He blew a load in my mouth and all the while a cheesy studio portrait of him and his girlfriend beamed down at us from the mantle.

The next time we’d been out drinking and had gone back to his place even though his girlfriend was home. He had a couch and a TV set up in the basement and I got on my knees before him there, sucked his cock and swallowed down his cum while his girlfriend slept upstairs.

One time I was with him when he fucked a girl. He wanted me to join in but I just wasn’t into it. I got behind him and watched him fuck. He had his boxer shorts on but I pulled them down so I could look at his muscled ass. He hated that! He pulled them up but I just pulled them back down, watching his firm butt thrusting while I jacked off and came into my hand.

He fucked me once more, this time after a party at his apartment where the only guests were me and his extremely drunk straight friend. After his friend passed out Hannad took me into the bedroom and bent me over. I was more into the idea of getting fucked than I had been the first time, but I still couldn’t take it for very long. I was (and still am) a lousy bottom, it just took me a while to realize it.

Through it all we became genuine friends. He told me sad stories about Iraq, like how they used to drug him when he was in Saddam’s army to make him a better killer. He’d come to America when the U.S. Army recruited him after the first Gulf War and he missed Iraq badly. I was with him in the weeks leading up to 2003 invasion of Iraq and he was visibly, understandably perturbed. I lost contact with him when I changed jobs. Last I heard he made it back to Iraq, and I sure hope he’s okay. Underneath all his aggression he was a genuinely sweet guy who’d been through enough.

So This Means...... (2)

segedunum (883035) | more than 3 years ago | (#36914166)

.......that we're not going to get another Debian release for another fifty years?

Re:So This Means...... (1)

mmj638 (905944) | more than 3 years ago | (#36916234)

Multiarch is not going to delay a Debian release. If it could, it would have done so already. Multiarch has been a release goal in some form for years now, but Lenny and Squeeze (2 last releases) went ahead as normal without it, simply because it wasn't ready.

Debian releases will continue to be approximately 2 years apart.

Debian is experimenting with timed freezes, which means the release schedule should be more predictable (although the time between the freeze and the release will still work according to the "when it's ready" principle).

When (1)

phrostie (121428) | more than 3 years ago | (#36914174)

at the risk of feeding trolls, when will they update Wine?

Re:When (0)

Anonymous Coward | more than 3 years ago | (#36914478)

My guess: either upstream will simplify their build procedures (gecko has been the major stumbling point, but Wine is very good at embedding specific versions of free libraries too), or someone submits a wine build for non-free. Both will happen sooner than going through the hassle of building wine within the DFSG.

Although the current multi-arch support will go a long ways towards simplifying the build procedure, Wine simply does not have the relevance to spend my time on it, and I guess most DDs feel the same. The added value of Wine has been on a constant decline.

Re:When (0)

Anonymous Coward | more than 3 years ago | (#36917408)

In the time it took you to whine about how difficult it is to package wine, you could have packaged wine.

Re:When (0)

Anonymous Coward | more than 3 years ago | (#36918916)

I lack reading comprehension.

Re:When (1)

macinnisrr (1103805) | more than 3 years ago | (#36914526)

I assume you mean "when will Debian update WINE?", because a new version of WINE just came out last week.

Re:When (0)

Anonymous Coward | more than 3 years ago | (#36915628)

I got fed up waiting for Wine updates too. Put

deb http://ppa.launchpad.net/ubuntu-wine/ppa/ubuntu lucid main

into your /etc/apt/sources.list.

I guess they are good for something, huh?

Re:When (2)

the_B0fh (208483) | more than 3 years ago | (#36915904)

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.

Multiarch FTW!! (1)

Anonymous Coward | more than 3 years ago | (#36914242)

So you can run STABLE on both a TOPS-20 *AND* an 80286!!! :D

Re:Multiarch FTW!! (1)

thomasdz (178114) | more than 3 years ago | (#36914348)

So you can run STABLE on both a TOPS-20 *AND* an 80286!!! :D

I would so mod you up if I had mod points!

Re:Multiarch FTW!! (1)

SnarfQuest (469614) | more than 3 years ago | (#36914638)

Can't wait to be able run my PDP-8 software through a pipe!

nice link (2)

binford2k (142561) | more than 3 years ago | (#36914452)

did you accidentally the whole thing?

Re:nice link (1)

operator_error (1363139) | more than 3 years ago | (#36914700)

I clicked it and now I cannot see. (Maybe my eyes are bleeding too!)

Welcome to the past... (0)

Anonymous Coward | more than 3 years ago | (#36915194)

Didn't Solaris sort this out over a decade ago?

Good for chinese MIPS processors (1)

Blaskowicz (634489) | more than 3 years ago | (#36915294)

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

Lil Wayne? (1)

DJ DeFi (1344863) | more than 3 years ago | (#36915486)

Does this come bundled with his latest single?

in jail (0)

Anonymous Coward | more than 3 years ago | (#36915662)

Free Wheezy!

The thing that's nice about this (1)

bk2204 (310841) | more than 3 years ago | (#36915828)

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.

a step in the wrong direction (1)

Gravis Zero (934156) | more than 3 years ago | (#36916194)

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!

Re:a step in the wrong direction (1)

RobbieThe1st (1977364) | more than 3 years ago | (#36917078)

Um... Incase you don't realize it, that's the way it currently is: With my x86_64 system, and the ia32-libs package(and a couple of others), I can(and do) run 32-bit excecutables. On windows, you've got the same thing.
Thing is, x86 isn't gone. All desktop processors may be x86_64, but we've got lots of low powered chips that are 32 bit, and will continue to be so for the forseeable future.
We also have ARM chips taking center stage, and being able to seamlessly install and run x86 software on ARM and vice-versa(thanks to qemu) will be a major boon.

As far as companies being lazy? Um... That's not exactly new, this won't change anything. I don't see the issue.

Re:a step in the wrong direction (1)

yarnosh (2055818) | more than 3 years ago | (#36917886)

Or look at OS X where none of this shit even matters. Hell, even running two completely different architectures of the same machine was transparent to the user. 32bit vs. 64bit hardly mattered at all.

More information. (4, Informative)

mmj638 (905944) | more than 3 years ago | (#36916396)

The summary is terrible. And not just the invalid link.

Here's a more informative link [debian.org] 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.

Re:More information. (2)

martin-boundary (547041) | more than 3 years ago | (#36917100)

You can already run Windows code on Debian. What this should do (among lots of other things) is make the operating system more hardware agnostic. Imagine a single installed system on a portable hard drive. You plug the drive into an x86 and it's your trusted Debian system. Next, you take the drive out and go plug it into your ARM based smartphone while you're on the plane. Same OS, different hardware. Next, your old x64 breaks and you buy a replacement x128, and you just swap the hard drives. If you're a sysadmin, you might create a single trusted OS image and not care what hardware mix the company currently has.

Etc.

Re:More information. (0)

Anonymous Coward | more than 3 years ago | (#36917680)

Multiarch is not gonna let you run ARM binaries on an Intel chip or anything like that

Sure it wil, with a little help from QemuUserEmulation [debian.org] . The Debian wiki mentions other cases:

- i386 on ia64 (hardware emulation)
- arm on any (via qemu)
- s390 on any (via Hercules)
- ia64 on i386 (via ski)

the second one is obviously interesting - transparently cross-building (to arm) and testing on your desktop is going to make a few people happy, I think. And I can see them running three or more flavours on one machine (amd64, i386, armel, ...)

nor will it let you run Windows code on Debian

Again, multiarch will help Wine to do that too - right now we need ia32-libs and lib32XXX for Wine. So yes, Debian multiarch on its own isn't enoght but it does help with the necessary emulators and/or runtimes to make it quite transparent.

Re:More information. (0)

Anonymous Coward | more than 3 years ago | (#36918480)

Multiarch is not gonna let you run ARM binaries on an Intel chip or anything like that

It will not be the /only/ requirement for doing so but with the combination of qemu usermode emulation it makes it much easier!

Without multiarch you are able to apt-get qemu-user binfmt-support, put the shared libraries of your foreign architecture into /etc/qemu-binfmt// and then run any foreign ELF binary as if it were native: ./foobar. The linux binfmt mechanism would automagically figure out what kind of binary it is and transparently call qemu-arm or others to execute the foreign binary in user mode without having to emulate a full machine.

You can even download a foreign root filesystem, apt-get qemu-user-static and then cp /usr/bin/qemu-arm-static /your/foreign/rootfs and then chroot into it and use it as if it were a native root filesystem. Qemu usermode emulation rules - no need to emulate a full machine anymore. It is much faster this way.

But a downside was that you had to have /etc/qemu-binfmt// filled with the correct shared libraries. If you are working with different debian versions (requiring different shared library versions) or different debian architectures that map to the same qemu architecture (debian arm, armel, armhf all map to qemu arm) then you always had to change the content of /etc/qemu-binfmt// which was tedious.

But with multiarch you would just have all your foreign arm/armel/armhf/whatever libraries apt-getted normally and put into /usr/lib/arm-linux-gnueabi/whatver and could execute every foreign ELF binary magically using qemu user mode emulation withouth the hassle of /etc/qemu-binfmt/foo

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

no.

It is put into /lib/ and /usr/lib/ where is --. So this might be x86_64-linux-gnu or arm-linux-gnueabi. This allows you to not only have shared libraries for different cpu's installed but also for different ABIs - which is for example important for arm where there is oabi, eabi and now armhf.

Re:More information. (2)

cthulhu11 (842924) | more than 3 years ago | (#36918558)

Huh? RHEL already does this. I had to install 32-bit libs for HP's utils, eg. hpacucli and hponcfg.

Well then... (0)

Anonymous Coward | more than 3 years ago | (#36916706)

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.

I dont see powerPC listed (1)

Osgeld (1900440) | more than 3 years ago | (#36916950)

so that takes away about 90% of the coolness factor

Re:I dont see powerPC listed (0)

Anonymous Coward | more than 3 years ago | (#36917728)

TheCaseForMultiarch [debian.org] mentions ppc64 + ppc. They actually mention a whole bunch of other scenarios, examples:

32/64 Architectures
- i386 / x86_64
- ppc / ppc64
- mips / mips64

Mixed instruction sets
- i386 on ia64 (hardware emulation)
- arm on any (via qemu user emulation)
- s390 on any (via Hercules)
- ia64 on i386 (via ski)

Mixed OS environment (Running binaries from one OS on another via a compatibility layer)
- Linux/i386 on FreeBSD/i386
- Solaris/sparc on Linux/sparc
- Wine/DosEmu on Linux

Quite flexible and impressive I think.

Not hot innovation (1)

manu0601 (2221348) | more than 3 years ago | (#36917168)

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.

Disney (2, Insightful)

bill_mcgonigle (4333) | more than 3 years ago | (#36917330)

After all Disney has done for cultural freedom, it's nice to see Debian is still honoring their properties with its OS names.

yu0 Fail It (-1)

Anonymous Coward | more than 3 years ago | (#36917804)

to the original FreeBSD be3ause diseases. The

Waste of time (0)

Anonymous Coward | more than 3 years ago | (#36918812)

they should just concentrate on a pure 64-bit system and drop 32-bit completely.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?