Quotes of the week [LWN.net]

Quotes of the week

Posted Jun 14, 2012 9:26 UTC (Thu) by jschrod (subscriber, #1646)
In reply to: Quotes of the week by juliank
Parent article: Quotes of the week

http://www.debian.org/News/2011/20110726b

Multi-arch support will appear in Wheezy, slated to be released in 2013. Or later, it wouldn't be the first time that Debian releases slip. So, no, Debian doesn't have multi-arch support yet.

Besides, Debian & proprietary software (and that's the main reason to use i386 userspace, in my experience) is hard to get into my customer's IT environments, too.

to post comments

Quotes of the week

Posted Jun 14, 2012 9:40 UTC (Thu) by cortana (subscriber, #24596) [Link] (1 responses)

I was told in this very forum that you can install the i386 port of Debian and then install the linux-image-{whatever}-amd64 package to get a 64-bit kernel. This has worked for donkeys years, though it will be obsoleted by multiarch.

Quotes of the week

Posted Jun 20, 2012 23:34 UTC (Wed) by BenHutchings (subscriber, #37955) [Link]

You can even choose it at installation time, in expert mode.

Quotes of the week

Posted Jun 14, 2012 12:45 UTC (Thu) by nevets (subscriber, #11875) [Link] (1 responses)

In 2005 when AMD came out with an affordable x86_64 processor, I bought one and built my main workstation with it. At the time, there was no x86_64 distros that I knew of, so I installed Debian testing i386 and did a cross compile to add a x86_64 kernel on it. It has worked flawlessly ever since.

I still have that system (I'm typing this on it), even though I've changed everything from the motherboard, RAM, CPU, Hard disks, and power-supply. But I've never reinstalled the system. (If you are wondering about how I did that and changed the HDs, I have a RAID 1 setup, and changing HDs is just a matter of swapping one at a time and doing a resync).

Today, I no longer do a cross compile to build my kernels for it. It handles building a x86_64 kernel just fine, even though my userspace is still i386. And yes, it comes with a x86_64 kernel:

Package: linux-image-3.2.0-2-amd64

I believe the 'Multi-arch' is to run both x86_64 and x86_32 userspace. But has nothing to do with the kernel (although you need an x86_64 kernel to run x86_64 userspace apps). But if you only have x86_32 userspace, then all you need is that linux-image and you're good to go. Debian has supported this for a while.

Quotes of the week

Posted Jun 14, 2012 19:07 UTC (Thu) by dlang (guest, #313) [Link]

> It has worked flawlessly ever since.

you are a little lucky.

there have been a handful of low-level interfaces that have had problems. I remember tripping over a iptables bug, and there was the recent automounter related issue.

in general it works, but it has not worked perfectly all along.

Quotes of the week

Posted Jun 14, 2012 19:06 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

keep in mind that multi-arch is not perfect.

I've run into problems with some libraries that don't work properly with multiarch (specifically installing the 32 bit aspell library removed the default library on ubuntu 11.04, causing the entire KDE desktop environment to be removed, not fun. Yes I did submit a ticket, no action in two months.)

Quotes of the week

Posted Jun 15, 2012 8:33 UTC (Fri) by fb (guest, #53265) [Link]

> causing the entire KDE desktop environment to be removed,

Sounds like a feature to me!
*ducks*

Quotes of the week

Posted Jun 15, 2012 19:45 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

That sounds like exactly the kind of problem that convinced Guillem Jover to block Ubuntu's version of multiarch and not accept it into Debian until all the kinks were worked out. Maybe he was onto something.

Quotes of the week

Posted Jun 15, 2012 19:53 UTC (Fri) by dlang (guest, #313) [Link]

the problem isn't in the mechanism, it's in how far it's been implemented.

apparently libaspell isn't multiarch (or at least it's not being installed appropriately if it is), so when you install the 32 bit version it uninstalls the 64 bit version that was already there.

blocking multiarch doesn't solve this problem, the same problem existed before multiarch, it's just that everyone knew not to try to do that (you only used 'special' 'prepared' libraries that were part of the ia32 package)

multiarch reduces the problem, but by making it work more of the time, you do run into the cases where it doesn't work.

If you try to block it until it's perfect, you will block it forever, because whenever you actually use something new, you find the corner cases.

multiarch works perfectly if you stick to doing only the things that you could do without it.