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

84 of 135 comments (clear)

  1. Re:anyone home? by RudeDude · · Score: 1

    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.

    --
    RudeDude
    Perl/Linux/PHP hacker
  2. 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.

    3. Re:Link is (was?) broken by wagnerrp · · Score: 1

      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.

    4. Re:Link is (was?) broken by martin-boundary · · Score: 1

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

    5. Re:Link is (was?) broken by wagnerrp · · Score: 1

      You are correct. It was intended as a joke.

  3. where is TFA? by Anonymous Coward · · Score: 2, Informative

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

    Anyway, here is the Debian announcement.

    1. Re:where is TFA? by dirtyhippie · · Score: 1

      The misleading summary helps, too.

  4. The original submission was a self-serv ad anyway. by gcnaddict · · Score: 1

    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/
  5. Wheezy F Baby... by Anonymous Coward · · Score: 2, Funny

    Is it powered by drugs and cough syrup?

  6. Re:Hope Ubuntu gets this change eventually by yincrash · · Score: 1

    This is in Natty. See Here

  7. Fat Binary or just some kind of FS organization? by ulzeraj · · Score: 1

    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.

  8. /lib64 is not enough by Anonymous Coward · · Score: 1

    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.

    1. Re:/lib64 is not enough by Anonymous Coward · · Score: 1

      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.

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

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

    4. 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.
    5. Re:/lib64 is not enough by Lennie · · Score: 2

      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
    6. Re:/lib64 is not enough by Anonymous Coward · · Score: 1

      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.

    7. Re:/lib64 is not enough by RobbieThe1st · · Score: 1

      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.

    8. Re:/lib64 is not enough by bill_mcgonigle · · Score: 1

      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.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  9. Correct Link by Frankie70 · · Score: 1

    Original submission had the link correctly. Timothy replaced it with a bad one.

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

    1. Re:Wheezy by commisaro · · Score: 2

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

  11. At Last! by Skewray · · Score: 1

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

  12. Great Idea by Murdoch5 · · Score: 1

    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.

    1. Re:Great Idea by Murdoch5 · · Score: 1

      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.

    2. Re:Great Idea by HarrySquatter · · Score: 1

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

    3. Re:Great Idea by Murdoch5 · · Score: 1

      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.

    4. Re:Great Idea by bgat · · Score: 2

      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.
    5. 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.
    6. Re:Great Idea by Murdoch5 · · Score: 1

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

  13. Re:Party like its 2004 by DemonGenius · · Score: 1

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

  14. So This Means...... by segedunum · · Score: 2

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

    1. Re:So This Means...... by mmj638 · · Score: 1

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

  15. When by phrostie · · Score: 1

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

    1. Re:When by macinnisrr · · Score: 1

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

    2. Re:When by the_B0fh · · Score: 2

      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.

  16. Multiarch FTW!! by Anonymous Coward · · Score: 1

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

    1. Re:Multiarch FTW!! by thomasdz · · Score: 1

      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!

      --
      Karma: Excellent. 15 moderator points expire sometime.
    2. Re:Multiarch FTW!! by SnarfQuest · · Score: 1

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

      --
      Who would win this election: Andrew Weiner vs Andrew Weiner's weiner.
  17. Re:What a joke by gmack · · Score: 2

    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?

  18. nice link by binford2k · · Score: 2

    did you accidentally the whole thing?

    1. Re:nice link by operator_error · · Score: 1

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

  19. Re:No more GNU/Linux by SnarfQuest · · Score: 1

    Don't you mean GNU/RMS?

    --
    Who would win this election: Andrew Weiner vs Andrew Weiner's weiner.
  20. Re:And before? by Lennie · · Score: 1

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

    --
    New things are always on the horizon
  21. Good for chinese MIPS processors by Blaskowicz · · Score: 1

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

  22. 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.
  23. Lil Wayne? by DJ+DeFi · · Score: 1

    Does this come bundled with his latest single?

    --
    You cannot warp because you are warp scrambled.
  24. The thing that's nice about this by bk2204 · · Score: 1

    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.

  25. a step in the wrong direction by Gravis+Zero · · Score: 1

    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.
    1. Re:a step in the wrong direction by RobbieThe1st · · Score: 1

      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.

    2. Re:a step in the wrong direction by yarnosh · · Score: 1

      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.

    3. Re:a step in the wrong direction by EsbenMoseHansen · · Score: 1

      Apple chose to bundle all supported (2) architectures in all packages. While wasteful, it was effective given the low number of supported architectures (2). Given that debian support quite a few architectures, that route really isn't feasible. Is it more clear now?

      --
      Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
    4. Re:a step in the wrong direction by yarnosh · · Score: 1

      Apple officially supported 4 architectures. PPC32, PPC64, and x86, x86_64. And you could even store binaries optimized for sub architectures (i.e. G3 vs. G4). All completely transparent to the user. No extra files. The reason this is made practical is the Mach-O binary format. It was trivial to build and distribute a universal binaries and libraries. This was baked in from the start. Something inherited from NeXT.

      Considering that we're mainly talking about running x86 binaries on x86_64 Linux machines, I don't see why it wasn't feasible for Debian to support that from the beginning. There'd be no point in installing ARM binaries on an x86 machine because you wouldn't be able to run them anyway. A "universal" install would be a neat trick though not terribly useful for the vast majority of people.

      Another neat thing about Apple's universal binary system is that it extends down to the boot level. You can actually boot a PPC Mac and an x86 Mac with the same Leopard disk. This is one of those things that keeps me coming back to OS X/Mac. The shit just works.

    5. Re:a step in the wrong direction by EsbenMoseHansen · · Score: 1

      Both solutions are transparent for the user --- it is only something that matters to packagers. Debians solution is also transparent for the developer, though Apple's (I guess) is not, but then, Apple does not have packagers.

      This idea (nicknamed "FAT elf") was considered and rejected across the board --- noone wanted it. While I am not an expert, it seems wasteful to me to load a bunch of architectures you won't ever need, and wasteful to install a bunch of libraries for architectures you don't use. Typically, only a very small part of your installation will actually need to be multiarch. Of course, if I were *also* selling hardware, I might be a bit more wasteful :)

      In principle, you could run an emulator to run binaries for other architectures with e.g. qemu. I gather that that is not immediately in scope, though.

      --
      Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
    6. Re:a step in the wrong direction by yarnosh · · Score: 1

      This idea (nicknamed "FAT elf") was considered and rejected across the board --- noone wanted it.

      Their loss because it could have made the current 32 to 64 bit transition a lot smoother had it been generally accepted and used. Think one kernel, at least 2 different architectures. Also, it would presumably extend down to the driver level too. You wouldn't even have to think about how many "bits" your system is. Everything would just work. The boot loader would pick the optimal arch and you'd be set. But I guess Linux users don't like things to be too easy. (I was a Linux user for many years, and this was actually the case in many ways).

      While I am not an expert, it seems wasteful to me to load a bunch of architectures you won't ever need,

      Define "load." It isn't l like you load all architectures into memory for all executables. They're just there if you need them. Also, I could be mistaken, but I believe the way OS X uses message passing, I don't think all shared libraries need to be multiarch. 32 bit programs can more smoothly interact with 64 bit programs/libraries.

      and wasteful to install a bunch of libraries for architectures you don't use. Typically, only a very small part of your installation will actually need to be multiarch. Of course, if I were *also* selling hardware, I might be a bit more wasteful :)

      Oh please. Disk space is dirt cheap. That's just an excuse for laziness on the part of developers, packagers, and distribution maintainers. Meanwhile, Linux users will continue to bitch and complain about things like Adobe Flash not working correctly due to architecture differences. Not properly handling multiarch has a a significant impact on user experience. Linux developers could learn from Apple. But instead, they insist on using Microsoft as the standard by which they measure themselves up to. And Microsoft has had their own 64bit transition problems. So sad. Bottom line is that Apple managed to not only seamlessly transition from 32bit to 64bit, but also from PPC to x86. You have to give them credit.

      Typically, only a very small part of your installation will actually need to be multiarch.

      Depends on how broadly you want to support 32 and 64 bit side by side. If you want to do it in the most transparent manner possible, you best make as much of the base system multiarch as possible. The problem with Linux is that there is no real "base" system. A Linux distribution is more or less one monolithic beast with every package tightly coupled with the next. It is kind all or nothing with Linux. Anyway, I'm just saying that this "multiarch" support by Debian seems like too little too late and others have done it much better. But if you just want to keep making excuses, whatever.

    7. Re:a step in the wrong direction by yarnosh · · Score: 1

      It is more important to make the transition from 32 bit to 64 bit as smooth and seamless as possible. For the most part, 64bit programs are not necessary. In many cases they're actually slower. As long as your kernel is 64 bit (can address all of your memory) and any memory intensive apps are 64bit, that's all you need. Everyone else can keep writing 32bit software and as long as your system handles it gracefully, it doesn't matter.

    8. Re:a step in the wrong direction by EsbenMoseHansen · · Score: 1

      Their loss because it could have made the current 32 to 64 bit transition a lot smoother had it been generally accepted and used. Think one kernel, at least 2 different architectures. Also, it would presumably extend down to the driver level too. You wouldn't even have to think about how many "bits" your system is. Everything would just work. The boot loader would pick the optimal arch and you'd be set. But I guess Linux users don't like things to be too easy. (I was a Linux user for many years, and this was actually the case in many ways).

      Everything did just work --- bugs excepted. And do. The problem this is going to solve is "how to handle N architectures on the same installation, dependencies and all. Of course, OS X doesn't handle automatic dependency resolution at all, does it? It relies on bundling instead, wasting resources left and right, if I recall correctly.

      While I am not an expert, it seems wasteful to me to load a bunch of architectures you won't ever need,

      Define "load." It isn't l like you load all architectures into memory for all executables. They're just there if you need them. Also, I could be mistaken, but I believe the way OS X uses message passing, I don't think all shared libraries need to be multiarch. 32 bit programs can more smoothly interact with 64 bit programs/libraries.

      You would be mistaken. Message passing in a architecture-independent way is expensive.

      and wasteful to install a bunch of libraries for architectures you don't use. Typically, only a very small part of your installation will actually need to be multiarch. Of course, if I were *also* selling hardware, I might be a bit more wasteful :)

      Oh please. Disk space is dirt cheap. That's just an excuse for laziness on the part of developers, packagers, and distribution maintainers.

      Oh please. Laziness is just stuffing in everything, that's the banal, ham-fisted solution. That you think that you always have enough disk space shows how little you understand of the range of computer hardware Debian supports. E.g, I have a server that only have 16Gb of hard disk space, and needs most of that space for data. I appreciate not having space wasted because the Debian developers chose the ham-fisted approach.

      Meanwhile, Linux users will continue to bitch and complain about things like Adobe Flash not working correctly due to architecture differences. Not properly handling multiarch has a a significant impact on user experience. Linux developers could learn from Apple. But instead, they insist on using Microsoft as the standard by which they measure themselves up to. And Microsoft has had their own 64bit transition problems. So sad.

      Obviously, you did not understand what the issue was. Running a 32-bit browser in a 64-bit environment was what flashusers did, but it is suboptimal for a number of reasons.

      Bottom line is that Apple managed to not only seamlessly transition from 32bit to 64bit, but also from PPC to x86. You have to give them credit.

      lol

      Typically, only a very small part of your installation will actually need to be multiarch.

      Depends on how broadly you want to support 32 and 64 bit side by side. If you want to do it in the most transparent manner possible, you best make as much of the base system multiarch as possible. The problem with Linux is that there is no real "base" system. A Linux distribution is more or less one monolithic beast with every package tightly coupled with the next. It is kind all or nothing with Linux.

      What are you talking about? Broadly support? Dependencies are (of course) resolved automatically. There is no "base system", no limit to the multi-arch support.

      Anyway, I'm just saying that this "multiarch" support by Debian seems l

      --
      Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
    9. Re:a step in the wrong direction by yarnosh · · Score: 1

      Everything did just work --- bugs excepted. And do. The problem this is going to solve is "how to handle N architectures on the same installation, dependencies and all.

      A problem that Apple solved years ago in a far more elegant way.

      Of course, OS X doesn't handle automatic dependency resolution at all, does it? It relies on bundling instead, wasting resources left and right, if I recall correctly.

      Bundling is one of the best parts of OS X, IMO. Who the hell cares if it wastes a bit of disk space? It WORKS. And it is totally hassle free. No installers. No package managers. You just copy the app to your desktop.. and run. Don't want it anymore? Delete it. Want to test two versions of the same software (one beta, perhaps) side by side? Keep both copies. You dont' have to worry about an installer or package manager trying to overwrite the old version. THAT is what computers should be like. OS X handles dependency resolution by making it a non-issue. Disk space is cheap as hell. I'll take a polished, hassle free user experience with some wasted disk space any day.

      Oh please. Laziness is just stuffing in everything, that's the banal, ham-fisted solution.

      Maybe, but it worked. As an OS X user, you never even had to know if your machine was 32 bit or 64 bit. Most people didn't even realize that the G5 was actually a 64bit CPU. It was that seamless. It is laughable that you can sit there and criticize how Apple handled it when Debian is only JUST NOW seriously addressing the general problem of managing multiple architectures.

      Sigh. What little you are talking about (a base set of libraries) have been working as long as I've used 64-bit.

      This thread is full of Linux users directly or indirectly complaining about how the transition to 64bit has been handled on LInux. Don't tell me it isn't a problem. I've dealt with it myself.

      This is about solving the general problem.

      What doublespeak is this?

    10. Re:a step in the wrong direction by EsbenMoseHansen · · Score: 1

      A problem that Apple solved years ago in a far more elegant way.

      No. The dependency problem was unsolved, and only a limited number of architectures. They build a mud hut and you claimed they solved the problem of building skyscrapers. Come on, this is simple facts!

      Of course, OS X doesn't handle automatic dependency resolution at all, does it? It relies on bundling instead, wasting resources left and right, if I recall correctly.

      Bundling is one of the best parts of OS X, IMO. Who the hell cares if it wastes a bit of disk space? It WORKS. And it is totally hassle free. No installers. No package managers. You just copy the app to your desktop.. and run. Don't want it anymore? Delete it. Want to test two versions of the same software (one beta, perhaps) side by side? Keep both copies. You dont' have to worry about an installer or package manager trying to overwrite the old version. THAT is what computers should be like. OS X handles dependency resolution by making it a non-issue. Disk space is cheap as hell. I'll take a polished, hassle free user experience with some wasted disk space any day.

      Bundles means multiple copies of shared libraries. This has 2 implication: 1. the libraries cannot share memory pages and 2. security updates are not applied across the board, meaning that security updates are cumbersome to apply. So it might look like a good idea to someone who doesn't know much about the subject, but it is in fact a rather bad idea. (But if you like it, I have seen a few distribution on package managers on Linux that does this. Not popular, though, for good reasons.)

      It is laughable that you can sit there and criticize how Apple handled it when Debian is only JUST NOW seriously addressing the general problem of managing multiple architectures.

      Sigh. As I said, it is a problem Apple has never handled. Why should they? You cannot install Apple on many architectures. The solution they chose was an interim solution, and as such the solution was rather crude. The specific problem of coexisting 32 and 64 bit has been working in Debian for many, many years.

      This thread is full of Linux users directly or indirectly complaining about how the transition to 64bit has been handled on LInux. Don't tell me it isn't a problem. I've dealt with it myself.

      I must have been lucky, then. I never had a problem, excepting bugs in software.

      --
      Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
    11. Re:a step in the wrong direction by yarnosh · · Score: 1

      Bundles means multiple copies of shared libraries. This has 2 implication: 1. the libraries cannot share memory pages and 2. security updates are not applied across the board, meaning that security updates are cumbersome to apply.

      Some shared libraries are copied, but since OS X is a predictable base system, you don't actually have to bundle most things. And the things you do bundle are likely not used by anthing else anyway. So they're non-issues. I used LInux for 10 years and I'll tell you, bundling eliminates so much hassle. Packages are fine for the base system, but user applications need to be much more flexible. Most Linux distributions are just big monolithic beasts where every damn application is tightly coupled with the next.

      So it might look like a good idea to someone who doesn't know much about the subject,

      LOL. Wow, dude. I'm a developer myself. I know what I'm taking about.

      but it is in fact a rather bad idea. (But if you like it, I have seen a few distribution on package managers on Linux that does this.

      Yea... not quite the same.

      Sigh. As I said, it is a problem Apple has never handled. Why should they? You cannot install Apple on many architectures. The solution they chose was an interim solution, and as such the solution was rather crude.

      Crude? What's crude about allowing multiple architectures to be bundled into a single file? It worked perfectly. How would it not work for architectures besides PPC and x86? You're blustering.

      The specific problem of coexisting 32 and 64 bit has been working in Debian for many, many years.

      It has worked, but not seamlessly or we wouldn't have so many LInux users complaining about things like Adobe Flash. And it doesn't work completely. Debian provides i386-libs, but if you happen to have a piece of software that needs a library not included in that rather limited set, you're SOL. You never even have to think about how many "bits" your system was on OS X. You never had to worry about whether Firefox was 32bit or 64bit. You simply cannot say that about LInux. I find it totally laughable that you can sit there and criticize how Apple handled things when your only complains are theoretical. In reality, everything worked out quite well.

    12. Re:a step in the wrong direction by EsbenMoseHansen · · Score: 1

      Some shared libraries are copied, but since OS X is a predictable base system, you don't actually have to bundle most things. And the things you do bundle are likely not used by anthing else anyway. So they're non-issues. I used LInux for 10 years and I'll tell you, bundling eliminates so much hassle. Packages are fine for the base system, but user applications need to be much more flexible. Most Linux distributions are just big monolithic beasts where every damn application is tightly coupled with the next.

      Only poor developers only depends on included shared libraries, and yes, the remaining libraries could be reused. You are just making excuses for a crude system.

      So it might look like a good idea to someone who doesn't know much about the subject,

      LOL. Wow, dude. I'm a developer myself. I know what I'm taking about.

      If you think that base and included libraries are sufficient for any real work, you are not a very good developer. You will be taking much longer, with a lot more bugs, than if you used existing libraries extensively.

      Yea... not quite the same.

      Since you cannot tell me what the difference is, exactly, I'll assume that yes, it is quite the same except for the cool-aid.

      Crude? What's crude about allowing multiple architectures to be bundled into a single file? It worked perfectly. How would it not work for architectures besides PPC and x86? You're blustering.

      I already went over why it is crude. It has at least 2 problems: Security, and resource waste. Problems solved for decades om linux

      The specific problem of coexisting 32 and 64 bit has been working in Debian for many, many years.

      It has worked, but not seamlessly or we wouldn't have so many LInux users complaining about things like Adobe Flash.

      Those complains were about Adobe not releasing 64-bit on linux before long after the other platforms. No distribution magic will cure that problem, and it would also have been a problem on OS X.

      And it doesn't work completely. Debian provides i386-libs, but if you happen to have a piece of software that needs a library not included in that rather limited set, you're SOL.

      Hardly. You have several options from there. Personally, being a developer, I maintain a complete 32-bit environment to reproduce those bugs that only shows up on 32-bit. This is very easy with the schroot package. Or if you prefer, you could install the missing libraries, and use the (crude) OS X solution, like you normally do with proprietary software (games, e.g.). That is outside the scope of package managers, though.

      You never even have to think about how many "bits" your system was on OS X. You never had to worry about whether Firefox was 32bit or 64bit. You simply cannot say that about LInux.

      You know, in our company we keep a wiki-page over which systems runs with 64-bit, and which with 32-bit. Because noone can remember, otherwise, and sometimes you need to know. As for how exposed this information is, that is a culture thing. Mac owners don't want to know, linux users do.

      I find it totally laughable that you can sit there and criticize how Apple handled things when your only complains are theoretical. In reality, everything worked out quite well.

      Resource wastage and security risks are real, but also something that is popular to ignore. I find it sad that you as a developer do not care about those things, but I suppose it is how it is these days.

      --
      Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
    13. Re:a step in the wrong direction by yarnosh · · Score: 1

      Only poor developers only depends on included shared libraries, and yes, the remaining libraries could be reused. You are just making excuses for a crude system.

      I'll take a system that puts user experience ahead of developmental purity, thanks. No excuses necessary.

      If you think that base and included libraries are sufficient for any real work, you are not a very good developer. You will be taking much longer, with a lot more bugs, than if you used existing libraries extensively.

      I'm sure it depends entirely on what I'm writing. Most software out there can rely on base and include libraries. And when they can't, they can just bundle what they need at very little real cost to the user. The trick is to provide a sufficiently robust base .Something that LInux has utterly failed to do. So it is understandable that you might not think much of "base" systems. On Linux you can't even rely on the user having certain GUI libraries installed beyond the basic X11 libraries. Aren't there like a half dozen different ways to play sound on Linux? It is is a disaster, if you ask me.

      I already went over why it is crude. It has at least 2 problems: Security, and resource waste. Problems solved for decades om linux

      Disk space is cheap and security hasn't been an issue. I don't see the problem.

      Hardly. You have several options from there. Personally, being a developer, I maintain a complete 32-bit environment to reproduce those bugs that only shows up on 32-bit. This is very easy with the schroot package.

      It might be "easy" to do, but the question is, should it even been an issue at all? I hear Linux appologists say "Oh, that's easy to fix, you just do this this and this.." That's all fine and good if you job is to develops software, but it doesn't really look good compared to a system where there was no problem to begin with.. at least as far as the end user is concerned.

      Oh, don't worry, I totally understand where you're coming from. I was like you for the longest time. I would make all kinds of excuses for Linux when people complained about the lack of commercial software or how complicated it was to do simple things like print (I realize it has gotten better). I'd just rattle off the "easy" commands to do it. And to me that was sufficient because I was a system administrator and part time programmer at the time. As long as things were straight forward enough to me, it didn't really matter that I was wasting my time doing it in the first place. In fact, I would go so far as to say that I got off on understanding what was going on and how to make things work. I like to solve problems, after all. But I gradually grew out of it though and it started to sink in that none of this was good for the USER. Sure, we could just train users to jump through all these "easy" hoops, or we can just make the shit work. Yeah, maybe we sometimes have to stray from what seems like the best technical solutions (i.e. waste some disk space by storing multiarch in everything or duplicate some shared libraries). But what's important is the user.

      Or if you prefer, you could install the missing libraries, and use the (crude) OS X solution, like you normally do with proprietary software (games, e.g.). That is outside the scope of package managers, though.

      That's just it though. Modern LInux distributions have invested so much in package management that they've basically created a system where anyone that deviates from the package managment is doing so at their own risk. That makes it very difficult to distribute proprietary software.

      You know, in our company we keep a wiki-page over which systems runs with 64-bit, and which with 32-bit. Because noone can remember, otherwise, and sometimes you need to know.

      Do you? I thnk that's my point. On PCs, you do need to know that information a lot more often tha

    14. Re:a step in the wrong direction by EsbenMoseHansen · · Score: 1

      Ok, I will try to restate the points you apparently cannot see.

      I'll take a system that puts user experience ahead of developmental purity, thanks. No excuses necessary.

      It is OS X that puts user experience over developer (OS X developer) convenience. Automatic dependency resolving is some work, which you sidestep by bundling. Bundling costs the user, in terms of security and in terms of performance (esp. less memory). That is why they have never been popular in the Linux world. Of course, both of these are sneaky problems, which only eats at you in tiny nipples.

      I'm sure it depends entirely on what I'm writing. Most software out there can rely on base and include libraries. And when they can't, they can just bundle what they need at very little real cost to the user. The trick is to provide a sufficiently robust base .Something that LInux has utterly failed to do. So it is understandable that you might not think much of "base" systems.

      If you have a huge base, you will be dragging along crap for a long time, because any library you put in the base has to be supported forever unless you want to break contract on that base. And any libraries accumulate cruft, stuff that wasn't designed as well as should be, or rested on assumptions that at no longer true. (e.g, who would have thought that users routinely had 2 or more sound cards on their desktop, or 2 graphics cards, just 10 years ago?) Not a good idea, tempting as it might be. Better to have a small base, an automatic, transparent dependency resolving (like Debian provides).

      On Linux you can't even rely on the user having certain GUI libraries installed beyond the basic X11 libraries. Aren't there like a half dozen different ways to play sound on Linux? It is is a disaster, if you ask me.

      Why should that matter? When I install say Krita, all the libraries I need are automatically installed if necessary, just as they are automatically updated if needed. I don't *care* what libraries people use to write their software, because I don't need to.

      I already went over why it is crude. It has at least 2 problems: Security, and resource waste. Problems solved for decades om linux

      Disk space is cheap and security hasn't been an issue. I don't see the problem.

      That would be because you do not know much about how shared libraries work. It is not only disk space that you waste, it is also memory. Oh yeah, sure, it is cheap also ;) Excuses upon excuses for a lazy, crude design.

      Oh, don't worry, I totally understand where you're coming from. I was like you for the longest time. I would make all kinds of excuses for Linux when people complained about the lack of commercial software

      You would be the one with the excuses for the primitive bundling technique, widespread in commercial software, also on linux. I am pointing out how the automatic dependency resolving is better, because it means applications use less memory, less disk space and are more secure, while being transparent or nearly so for the user.

      or how complicated it was to do simple things like print (I realize it has gotten better).

      shall I bring up the one button mouse, or the braindead no-eject-button on the diskette drive? Much the same age. Not only are they solved problems, they are also completely unrelated to installation of applications, which is what we were discussing. Why don't you just admit you were wrong? :)

      I'd just rattle off the "easy" commands to do it.

      I bet you would. Not something I have ever done. The shortcomings of linux are plenty, but that packaging system is a strength, not a weakness.

      And to me that was sufficient because I was a system administrator and part time programmer at the time.

      --
      Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
    15. Re:a step in the wrong direction by yarnosh · · Score: 1

      It is OS X that puts user experience over developer (OS X developer) convenience. Automatic dependency resolving is some work, which you sidestep by bundling. Bundling costs the user, in terms of security and in terms of performance (esp. less memory). That is why they have never been popular in the Linux world. Of course, both of these are sneaky problems, which only eats at you in tiny nipples.

      They've never been popular in the LInux world because Linux users have typically been willing to deal with the extra adminitrative overhead of package management and lack of proprietary software. But Linux users are not typical users and they never will be.

      If you have a huge base, you will be dragging along crap for a long time, because any library you put in the base has to be supported forever unless you want to break contract on that base. And any libraries accumulate cruft, stuff that wasn't designed as well as should be, or rested on assumptions that at no longer true.

      You don't need a "huge" base. You only needs a sufficiently robust base., which you have with OS X. You're speaking in purely theoretical terms. Open your eyes. OS X is a nice system to use and work wth.

      I have dozens of proprietary programs on this computer, mainly games. None seem to have a problem. The package management system doesn't get in the way, like you seem to think. It is very easy: You bundled all the shared libraries you need with you program, stuff in the some directory (./lib is popular), and add a LD_LIBRARY_PATH=./lib to the launcher. And no, this is not something the user does, it is something the developer does, just like the developer might create a deb package, or installshield package, or whatever OSX uses. See, it's all in your mind?

      Dozens, huh? And you're telling me the all just worked? Bullshit. Oh wait, I bet this is where you say something like "excluding bugs" or "I only had to do a few tweaks to make it work." Or some qualifier like that. You've never had to backport a program or fiddle with getting a package you want from one distribution to work on yours? I dealt with all of it on Linux and it SUCKED.

      The problem with bundling programs on Linux is that you have to bundle far more shared libraries than you would on OS X because a developer can't expect you to have anything but the most basic libraries like libc. So it is no wonder you have such a lower opinion of bundling. Your experience with it is on Linux, a system that doesn't explicitly support bundling.

      We need to know, so that we can tick off the checkbox that says "working in 32-bit". As an old sysadmin, I presume you are familiar with the fact that going from 64-bit to 32-bit can break stuff, just like the other way?

      On Linux, yes, but I never had a problem on OS X. That's what I'm trying to tell you.

      A harmless bug might suddenly not be so harmless when you change the word-length, you know? Had we used Macs, we would have to do the exact same thing. My point was that unless you actually query the system in some way, it's hard to tell. Seems very seamless to me.

      You just went over how you have to use schroot to setup a full 32bit environment and you're going to sit there and tell me that it is seamless? You're being dishonest. When I am developing for OS X, I don't have to maintain two different test enviornments. If I want to test 32bit on OS X, I output 32bit executable. If I want to test 64bit, I output 64bit. In most cases, there's no real need to even make a 64 bit version. I can, if I have reason to (like I actually might need 4+ GB of RAM), but for the most part I can ship a 32bit OS X application and nobody will really notice the difference.

      Do you seriously not get just how seamless 32/64bit is on OSX? I guess you wouldn't because it sounds lke you've never actually used OS X.

      That would be because you do not know muc

    16. Re:a step in the wrong direction by EsbenMoseHansen · · Score: 1

      They've never been popular in the LInux world because Linux users have typically been willing to deal with the extra adminitrative overhead of package management and lack of proprietary software. But Linux users are not typical users and they never will be.

      Again, what overhead? Lack proprietary software is, on the other hand, an issue, but it has nothing to do with Debian, but with the installed base. Max OS X is another that suffers from the latter, if to a lesser degree.

      You don't need a "huge" base. You only needs a sufficiently robust base., which you have with OS X. You're speaking in purely theoretical terms. Open your eyes. OS X is a nice system to use and work wth.

      You can chose between huge or constantly reinventing and reimplementing stuff. OS X does not satisfy my requirements for being highly productive (e.g, I need to have all the source code for the operating system and libraries I use available in a convenient way). If I were to use something else, it would be windows, because I like computer games. (Unfortunately, I have little time for those currently) . OS X is the worst of both worlds: Little proprietary software, and no sources.

      I have dozens of proprietary programs on this computer, mainly games.

      Dozens, huh? And you're telling me the all just worked? Bullshit. Oh wait, I bet this is where you say something like "excluding bugs" or "I only had to do a few tweaks to make it work." Or some qualifier like that. You've never had to backport a program or fiddle with getting a package you want from one distribution to work on yours? I dealt with all of it on Linux and it SUCKED.

      Yes, they all just worked. No fiddling, I have no time for that anymore. Why shouldn't they? If a program I bought didn't work, I would write the publisher and ask him to either fix it or refund me. What else can you do, whatever the system? And yeah, I gather you were burned once.

      The problem with bundling programs on Linux is that you have to bundle far more shared libraries than you would on OS X because a developer can't expect you to have anything but the most basic libraries like libc. So it is no wonder you have such a lower opinion of bundling. Your experience with it is on Linux, a system that doesn't explicitly support bundling.

      The LSB describes what is there, and the rest must be bundled. What does it matter if I have to bundle 6 libraries rather than 4? The work is pretty much the same. And as I demonstrated above, a huge base is not desirable. We can discuss where exactly the line should go, but I doubt there really is a perfect line.

      We need to know, so that we can tick off the checkbox that says "working in 32-bit". As an old sysadmin, I presume you are familiar with the fact that going from 64-bit to 32-bit can break stuff, just like the other way?

      On Linux, yes, but I never had a problem on OS X. That's what I'm trying to tell you.

      lol. I got to try that. "No dear customer we didn't test on 32-bit like you asked. Why? Oh, we use Macs, we don't need to test, you see. What? No money? Why not?

      A harmless bug might suddenly not be so harmless when you change the word-length, you know? Had we used Macs, we would have to do the exact same thing. My point was that unless you actually query the system in some way, it's hard to tell. Seems very seamless to me.

      You just went over how you have to use schroot to setup a full 32bit environment and you're going to sit there and tell me that it is seamless?

      I said, if you would listen, that I preferred to use a 32-bit schroot for testing that, because then I am sure it works the way I want to. It is very easy to setup and maintain such a schroot... one short line on the prompt, and voila. I could also, like I wrote, have done this inside m

      --
      Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
  26. 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.

    1. Re:More information. by martin-boundary · · Score: 2
      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.

    2. Re:More information. by cthulhu11 · · Score: 2

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

    3. Re:More information. by Trogre · · Score: 1

      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.

      This will also make 32-bit mplayer much easier to install on 64-bit machines, which is often needed due to binary-only win32 codecs.

      --
      "Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
    4. Re:More information. by domatic · · Score: 1

      It will also allow you to dist-upgrade from a x86 system to a x86_64 system if the CPU supports it. Right now it is possible to install a 64 bit kernel and some compatibility libs on a 32 bit system but this is really only good for running precompiled 64 bit binaries. Vice versa can be done on a 64 bit system.

      It doesn't allow for installing 64 bit debs. But if they can pull this off then I can upgrade from a machine that is 32 bit arch and make it a 64 bit arch.

    5. Re:More information. by godrik · · Score: 1

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

      Actually it does. They plan to couple multiarch with emulation solution such as qemu to run ARM binaries on x86 processors and vice versa. They also plan to let you run cross-OS binaries like run freebsd binaries on linux and vice versa.

  27. Re:The Premier Open Source Website by Captain+Splendid · · Score: 2

    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!
  28. I dont see powerPC listed by Osgeld · · Score: 1

    so that takes away about 90% of the coolness factor

  29. Not hot innovation by manu0601 · · Score: 1

    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.

  30. Disney by bill_mcgonigle · · Score: 2, Insightful

    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)
    1. Re:Disney by npsimons · · Score: 1

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

      Couple of things: Bruce Perens, who used to work at Pixar, and developed Electric Fence while there, was once a Debian Project Leader and started the convention of codenaming Debian releases to Toy Story characters. This was all before Disney bought Pixar. HTH.

    2. Re:Disney by bill_mcgonigle · · Score: 1

      Yeah, I understand Pixar used to be cool and hip. But Wheezy was named after Disney bought them out.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  31. Bad name for asthmatics by wdef · · Score: 1

    It's difficult for an asthmatic to even hear the word "wheezy" and not reach for an inhaler.

  32. Re:The Premier Open Source Website by DaVince21 · · Score: 1

    Is the Slashdot interface open-source, then?

    --
    I am not devoid of humor.
  33. Re:What a joke by KugelKurt · · Score: 1

    Which distribution is currently shipping cross-compile environments? Which distribution has a solution that extends beyond Intel's architecture?

    SUSE. It's called Open Build Service and exists since 5 or so years.