Quotes of the week [LWN.net]

Quotes of the week

Posted Jun 14, 2012 8:01 UTC (Thu) by drago01 (subscriber, #50715)
In reply to: Quotes of the week by jschrod
Parent article: Quotes of the week

And the reason for wanting a i386 userspace is ... ?
Any sane distribution can run i386 binaries just fine on x86_64.

to post comments

Quotes of the week

Posted Jun 14, 2012 8:25 UTC (Thu) by gevaerts (subscriber, #21521) [Link] (1 responses)

Yes, exactly. That's what "a i386 userspace" *means*

Quotes of the week

Posted Jun 17, 2012 8:30 UTC (Sun) by drago01 (subscriber, #50715) [Link]

No he means *only* i386 userspace binaries and libs.
I am saying you can just have an x86_64 userspace and still being able to install i686 libs where needed to run the i386/i386 binaries.

Quotes of the week

Posted Jun 14, 2012 9:37 UTC (Thu) by jschrod (subscriber, #1646) [Link] (7 responses)

> And the reason for wanting a i386 userspace is ... ?

Proprietary programs that are only available in i386 versions.
Or, compliance processes with red tape, needed to approve the architectures switch for an approved installation.
Or, customers with years-old installations, that don't fuzz up the money for the switch project and the associated test costs. (I have one of those customers quite right now.)

> Any sane distribution can run i386 binaries just fine on x86_64.

That's not my experience. Quite often, proper distribution-supported packages (i.e., not roll-your-own installations) for i386 shared libraries in x86_64 base installations are missing. I.e., one has a 32bit program, and no vendor-supported package is available with its needed libraries that can be installed.

And that's because the base install with a 64bit kernel installs 64bit userspace as well. With that come 64bit shared libs packages. Sometimes the distribution offers parallel installs of 32bit shared libs packages. (E.g., -32bit packages from openSUSE. But even there not all shared libs are made available for parallel installs. And no luck at all on RHEL.) Replacing the installed 64bit shared libs packages with their 32bit versions conflicts often with the 64bit userspace that got installed initially.

Of course, I can run my own installation and reconfigure the distribution completely. But that was actually exactly the point that I want to make: I have to do that and it's not readily available. And that's the reason why there is no uptake of the demand that Steven made.

Quotes of the week

Posted Jun 14, 2012 13:14 UTC (Thu) by nevets (subscriber, #11875) [Link] (2 responses)

You missed my point. I never said that the system should be a x86_64 base, only the kernel. And *that* works just fine on i386 installations.

I've been running an i386 userspace system on an x86_64 kernel since 2005. Never had any issues with it.

Debian today now even supplies a 64bit kernel with its i386 distribution. Although, I think you still need to install the i386 kernel first, and then upgrade to the 64bit kernel after install. The package is:

linux-image-amd64

Quotes of the week

Posted Jun 14, 2012 16:45 UTC (Thu) by jschrod (subscriber, #1646) [Link] (1 responses)

You are right. I didn't know about the linux-image-amd64 package.
So, Debian has the ability to install a 64bit kernel on a 32bit system.

According to http://packages.ubuntu.com/search?suite=precise&arch=..., Ubuntu has no such package.

I know that RHEL 6 and its derivates have no such package, and neither does SLE nor openSUSE. I assume that Fedora has none either.

I'd say, even with this correction, my original statement stands: If one looks at the major distributions, one sees the reason why not more people use such an installation.

Quotes of the week

Posted Jun 14, 2012 16:56 UTC (Thu) by nevets (subscriber, #11875) [Link]

Which gives more reason to add that message.

It will give the major distros more incentive to make their i386 userspace include a x86_64 kernel. Otherwise the kernel will keep calling their users idiots ;-)

Quotes of the week

Posted Jun 14, 2012 22:27 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (2 responses)

> And no luck at all on RHEL.

Hmm? I have i686 and x86_64 packages installed at the same time on Fedora and I remember RHEL 5 being the same. I haven't played with RHEL 6 enough to remember.

Quotes of the week

Posted Jun 14, 2012 23:50 UTC (Thu) by jschrod (subscriber, #1646) [Link] (1 responses)

On an x86_64 system, you can install i686 packages. But then you have already base x86_64 userland packages installed, especially those with shared libs. Additional package installations will cause conflicts with those base-installed packages.

On an i686 installation, no x86_64 kernel package is available, like it is in Debian. "yum list 'kernel*'" tells so.

Of course, you can always create your own completely-self-made-up package list and use Anaconda or AutoYast or such. But this is what I called "roll-your-own installation" above, then you create a spin. It is not an installation mode that is supported by a distribution out-of-the box -- which is what I was asking for.

I don't deny that it ain't possible; after all, one can also always roll one's own kernel and install that. I hinted to the fact that such an installation mode is not widespread because it is *not a mode commonly offered by distributions*.

Quotes of the week

Posted Jun 17, 2012 8:29 UTC (Sun) by drago01 (subscriber, #50715) [Link]

> On an x86_64 system, you can install i686 packages. But then you have already base x86_64 userland packages installed, especially those with shared libs. Additional package installations will cause conflicts with those base-installed packages.

That's just not true.
You can install those just fine ... they won't conflict because the shared libraries go into different directories (lib vs lib64). Which is the whole point of multilib. Binaries in both packages won't conflict either because rpm has a concept of "coloring" which means if you install foo.i686 and foo.x86_64 and both ship /usr/bin/foo it *wont* conflict. /usr/bin/foo will just be the x86_64 one.

Name examples of what you mean. You might just have hit some kind of packing bug for a specific library but they are designed to not conflict and it works fine for me here.

Quotes of the week

Posted Jun 17, 2012 8:33 UTC (Sun) by drago01 (subscriber, #50715) [Link]

> Proprietary programs that are only available in i386 versions.

That does not mean that you need a i386 userspace for them. Multilib works just fine in that case.

> That's not my experience. Quite often, proper distribution-supported packages (i.e., not roll-your-own installations) for i386 shared libraries in x86_64 base installations are missing. I.e., one has a 32bit program, and no vendor-supported package is available with its needed libraries that can be installed.

Not sure what distribution you are referring to but at least on fedora every lib shipped does have a installable i686 counterpart in the repos. So for every libfoo.x86_64 there is libfoo.i686 ...

> And no luck at all on RHEL.

What does that mean? Just install libfoo.i686 (you can do that for every library shipped assuming they are doing the same as fedora which I have no reason to doubt).

The reason:

Posted Jun 14, 2012 9:44 UTC (Thu) by NAR (subscriber, #1313) [Link] (4 responses)

I've recently installed 64 bit Debian. Then I had to reinstall the 32 bit version, because it turned out that the lgrind package is only packaged for i386: http://packages.debian.org/testing/tex/lgrind

The reason:

Posted Jun 14, 2012 10:18 UTC (Thu) by przemoc (guest, #67594) [Link] (3 responses)

This is strange. Quick check (possibly inaccurate) shows that it's not a x86-specific package.

$ cat /etc/debian_version
wheezy/sid
$ uname -m
x86_64
$ apt-get source lgrind
...
$ ( cd lgrind-3.67/ && dpkg-buildpackage -b -us -uc )
...
$ dpkg -I lgrind_3.67-3_amd64.deb
...
Package: lgrind
Version: 3.67-3
Architecture: amd64
...
$ sudo dpkg -i lgrind_3.67-3_amd64.deb
...
$ lgrind
lgrind -- general purpose "pretty printer" for use with LaTeX.
usage: lgrind [options] <name> ...
...

BTW what was the tag for using fixed-size font in HTML comments at LWN.net? <code>, <samp> and <tt> seem unsupported...

The reason:

Posted Jun 14, 2012 12:19 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

You want <pre>, I think.

The reason:

Posted Jun 14, 2012 12:45 UTC (Thu) by przemoc (guest, #67594) [Link]

You're right. I tried <pre> at the beginning, but there is this ridiculous requirement of dealing by hand with & and other stuff in HTML that I went with other tags before carefully reading the note. There is also an old <xmp> tag, treating everything in it as-is, but it's not universally supported.

Having Markdown as a third option for format would be really nice in such cases. The only problem is indentation that is tiring unless you have a vi/xclip+sed/etc. close. The solution is a fenced code blocks (~~~) extension, available in many implementations.

But it's OT here, sorry.

The reason:

Posted Jun 14, 2012 12:25 UTC (Thu) by cortana (subscriber, #24596) [Link]

AFAIK packages in non-free are not auto-built by default. So a lack of an officially-build amd64 instance of this package probably just means that the maintainer didn't go through the steps to request that it by autobuilt.

On the other hand, now that multiarch is present in testing/unstable:

$ dpkg-architecture -qDEB_HOST_ARCH
amd64

# apt-get install lgrind
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Recommended packages:
  tetex-bin:i386
The following NEW packages will be installed:
  lgrind:i386
0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
Need to get 81.8 kB of archives.
After this operation, 250 kB of additional disk space will be used.
Get:1 http://ftp.uk.debian.org/debian/ wheezy/non-free lgrind i386 3.67-3 [81.8 kB]
Fetched 81.8 kB in 0s (303 kB/s)
Selecting previously unselected package lgrind.
(Reading database ... 447986 files and directories currently installed.)
Unpacking lgrind (from .../lgrind_3.67-3_i386.deb) ...
Processing triggers for man-db ...
Processing triggers for doc-base ...
Processing 1 added doc-base file...
Registering documents with scrollkeeper...
Setting up lgrind (3.67-3) ...
texhash: Updating /usr/local/share/texmf/ls-R... 
texhash: Updating /var/lib/texmf/ls-R-TEXLIVEMAIN... 
texhash: Updating /var/lib/texmf/ls-R-TEXLIVEDIST... 
texhash: Updating /var/lib/texmf/ls-R-TEXMFMAIN... 
texhash: Updating /var/lib/texmf/ls-R... 
texhash: Done.
W: Operation was interrupted before it could finish

$ ldd /usr/bin/lgrind
	linux-gate.so.1 =>  (0xf77d4000)
	libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xf764d000)
	/lib/ld-linux.so.2 (0xf77d5000)

Not too impressive since I already had libc6:i386 installed, and lgrind has no other dependencies, but you can see how multiarch nicely makes obsolete the old biarch problems that jschrod lists in a post above.

Quotes of the week

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

> And the reason for wanting a i386 userspace is ... ?

I like it because it keeps evolution, firefox and chrome all limited to 3Gigs of RAM. I have two boxes I use (one is very work specific, the other is personal, although I use it for most my upstream work as well). My work box is a true x86_64 install base. My personal box is i386 userspace running a x86_64 kernel. Both have 8Gigs of RAM.

My i386 box never has issues with fire-fox, chrome or evolution taking up all my memory. When they get too big, the worse that happens is that they crash and I just restart them.

On my x86_64 box, these apps take over all RAM and it's not till I notice the slow down before I restart them.

Both these boxes run 24/7 so a daily shutdown is not there to clean things up.

Quotes of the week

Posted Jun 14, 2012 15:39 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (3 responses)

> I like it because it keeps evolution, firefox and chrome all limited to 3Gigs of RAM.

You can limit the virtual address space of specific programs or sessions with ulimit -v, while still benefiting from x86_64 everywhere else. Even better, with ulimit you can choose _any_ limit, not just 3 GiB.

Quotes of the week

Posted Jun 14, 2012 16:22 UTC (Thu) by nevets (subscriber, #11875) [Link] (2 responses)

I was waiting for someone to reply about ulimit. I'm just too lazy to implement a limit on my x86_64 boxes, that I just wait till the system slows down and restart instead.

Also, i386 does have the added benefit that these tools have smaller pointers and do not take up as much memory to begin with.

Quotes of the week

Posted Jun 15, 2012 10:29 UTC (Fri) by jengelh (subscriber, #33263) [Link] (1 responses)

>Also, i386 does have the added benefit that these tools have smaller pointers and do not take up as much memory to begin with.

i386 is hardly a benefit - it has much less registers and you don't have the guaranteed SSE2 availability.

The cake seems to reside near x32 [64-bit instruction set, but with ILP32] instead. (But hey, that's what people already do (mostly - save for a gcc issue) on sparc64 and ppc64 for years, have the x86 folks been sleeping?)

Quotes of the week

Posted Jun 15, 2012 23:06 UTC (Fri) by faramir (subscriber, #2327) [Link]

You are talking (probably) about execution time/memory bandwidth. He is talking about total memory footprint. Which matters more is going to depend on the context.