Quotes of the week
"Idiot! Why the f*ck are you running i386 on your nice shiny new x86_64 machine, with Umpteen Gigs of RAM. Boot a x86_64 kernel for Christ sake and get your full potential. Your i386 userspace will still work just fine on it. You're like one of those 75 year old retirees that can finally buy a Porsche just to drive it 10 miles per hour below the speed limit with a line of cars behind them!"
Posted Jun 14, 2012 4:48 UTC (Thu)
by thedevil (guest, #32913)
[Link] (2 responses)
Because I build my own kernels, one of my 3 machines is *not* an x86_64, and I want to only build one kernel per release.
Posted Jun 14, 2012 15:16 UTC (Thu)
by nevets (subscriber, #11875)
[Link] (1 responses)
I would suggest setting up distcc or icecream (you have 3 machines) and build a x86_64 kernel as well for the x86_64 machines. It makes the build go much faster. And you wont even need to do anything special as the userspace is all i386 anyway. But if the boxes are not all the same distro, you can use my guide to build your own gcc's for distcc kernel compiling:
http://rostedt.homelinux.com/distcc/
It's a little out of date, but should still be useful to help you set up.
Posted Jun 16, 2012 23:53 UTC (Sat)
by giraffedata (guest, #1954)
[Link]
Sure, that's reasonable. It's like having a 10G disk drive and a 15G disk drive and not using 5G of the larger drive so you can use them as a mirrored pair.
I too maintain a single kernel binary that I run on lots of systems. Many of them even access the same actual file, over the network. Some are capable of running 32 or 64 bit and others only 32 bit. The extra speed I'd get out of the 64 bit machines, in my case, would not justify the extra maintenance effort of having two kernels.
And note that there's no hypocrisy here. I never intended to have full x86_64 speed when I acquired the x86_64 machines; That feature is just an unwanted by-product.
Posted Jun 14, 2012 7:44 UTC (Thu)
by jschrod (subscriber, #1646)
[Link] (34 responses)
Which major distribution offers an installation mode with x86_64 kernel and full i386 userspace?
When Steven Rostedt answers that question, he might get a glimp of one of the reasons. But that would have needed to acknowledge that distributions form the installation experience for majority of Linux users, not availability of technology.
Posted Jun 14, 2012 8:01 UTC (Thu)
by drago01 (subscriber, #50715)
[Link] (20 responses)
Posted Jun 14, 2012 8:25 UTC (Thu)
by gevaerts (subscriber, #21521)
[Link] (1 responses)
Posted Jun 17, 2012 8:30 UTC (Sun)
by drago01 (subscriber, #50715)
[Link]
Posted Jun 14, 2012 9:37 UTC (Thu)
by jschrod (subscriber, #1646)
[Link] (7 responses)
Proprietary programs that are only available in i386 versions.
> 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.
Posted Jun 14, 2012 13:14 UTC (Thu)
by nevets (subscriber, #11875)
[Link] (2 responses)
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
Posted Jun 14, 2012 16:45 UTC (Thu)
by jschrod (subscriber, #1646)
[Link] (1 responses)
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.
Posted Jun 14, 2012 16:56 UTC (Thu)
by nevets (subscriber, #11875)
[Link]
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 ;-)
Posted Jun 14, 2012 22:27 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
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.
Posted Jun 14, 2012 23:50 UTC (Thu)
by jschrod (subscriber, #1646)
[Link] (1 responses)
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*.
Posted Jun 17, 2012 8:29 UTC (Sun)
by drago01 (subscriber, #50715)
[Link]
That's just not true.
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.
Posted Jun 17, 2012 8:33 UTC (Sun)
by drago01 (subscriber, #50715)
[Link]
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).
Posted Jun 14, 2012 9:44 UTC (Thu)
by NAR (subscriber, #1313)
[Link] (4 responses)
Posted Jun 14, 2012 10:18 UTC (Thu)
by przemoc (guest, #67594)
[Link] (3 responses)
$ cat /etc/debian_version
BTW what was the tag for using fixed-size font in HTML comments at LWN.net? <code>, <samp> and <tt> seem unsupported...
Posted Jun 14, 2012 12:19 UTC (Thu)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Jun 14, 2012 12:45 UTC (Thu)
by przemoc (guest, #67594)
[Link]
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.
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:
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.
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.
Posted Jun 14, 2012 15:39 UTC (Thu)
by nybble41 (subscriber, #55106)
[Link] (3 responses)
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.
Posted Jun 14, 2012 16:22 UTC (Thu)
by nevets (subscriber, #11875)
[Link] (2 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.
Posted Jun 15, 2012 10:29 UTC (Fri)
by jengelh (guest, #33263)
[Link] (1 responses)
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?)
Posted Jun 15, 2012 23:06 UTC (Fri)
by faramir (subscriber, #2327)
[Link]
Posted Jun 14, 2012 8:25 UTC (Thu)
by juliank (guest, #45896)
[Link] (9 responses)
Debian does.
Posted Jun 14, 2012 9:26 UTC (Thu)
by jschrod (subscriber, #1646)
[Link] (8 responses)
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.
Posted Jun 14, 2012 9:40 UTC (Thu)
by cortana (subscriber, #24596)
[Link] (1 responses)
Posted Jun 20, 2012 23:34 UTC (Wed)
by BenHutchings (subscriber, #37955)
[Link]
Posted Jun 14, 2012 12:45 UTC (Thu)
by nevets (subscriber, #11875)
[Link] (1 responses)
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.
Posted Jun 14, 2012 19:07 UTC (Thu)
by dlang (guest, #313)
[Link]
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.
Posted Jun 14, 2012 19:06 UTC (Thu)
by dlang (guest, #313)
[Link] (3 responses)
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.)
Posted Jun 15, 2012 8:33 UTC (Fri)
by fb (guest, #53265)
[Link]
Sounds like a feature to me!
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.
Posted Jun 15, 2012 19:53 UTC (Fri)
by dlang (guest, #313)
[Link]
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.
Posted Jun 14, 2012 8:54 UTC (Thu)
by rvfh (guest, #31018)
[Link] (1 responses)
And a path from a 32-bit install (which pre-dates Flash's 64-bit support) to a 64-bit kernel or better, a full 64-bit userspace?
Or can I just replace the kernel with some dpkg -i <shiny 64-bit kernel>.deb and off I go?
Posted Jun 14, 2012 9:41 UTC (Thu)
by cortana (subscriber, #24596)
[Link]
Pretty much. Note how that package is available for i386 as well as amd64.
Posted Jun 15, 2012 5:40 UTC (Fri)
by rganesan (guest, #1182)
[Link]
Posted Jun 14, 2012 9:33 UTC (Thu)
by Felix.Braun (guest, #3032)
[Link] (13 responses)
Posted Jun 14, 2012 12:12 UTC (Thu)
by richmoore (guest, #53133)
[Link] (3 responses)
Posted Jun 14, 2012 13:08 UTC (Thu)
by k3ninho (subscriber, #50375)
[Link] (2 responses)
Posted Jun 14, 2012 21:44 UTC (Thu)
by ballombe (subscriber, #9523)
[Link] (1 responses)
Posted Jun 15, 2012 23:18 UTC (Fri)
by faramir (subscriber, #2327)
[Link]
1. syscalls probably won't be faster.
Even with those issues, I would still be happy to stop using a PAE kernel if I could retain my x86 user space. Unfortunately, I don't run Debian and it appears that is the only distribution that supports this out of the box.
Posted Jun 14, 2012 12:32 UTC (Thu)
by nevets (subscriber, #11875)
[Link] (8 responses)
Also the kernel needs to create a page descriptor for every page of RAM. This page table must always be present and takes up that 885 megs. When you have a lot of RAM, this table grows, but the total access does not. It's like raising taxes on people on social security or other fixed income.
All kernel related operations take place in that 885 megs. Even if you have 2Gigs or 4Gigs of RAM, the kernel does not use any more. If the kernel needs to do any operations on the memory outside this range, (besides copy_from_user) it must map that page into its own address space (where the extra 100 megs are used for). This slows down the kernel and the system in general.
For systems with 2, 4, or possibly even 8Gigs, the kernel is still remarkably efficient in doing this, but it still has its cost. When you go above 8gigs, now you are just asking for trouble. I may have been a bit extreme when saying anything over 1Gig should produce that message. But it definitely should say it for over 8G (and possible just over 4).
Read Documentation/vm/highmem.txt for more information.
Posted Jun 14, 2012 13:02 UTC (Thu)
by nevets (subscriber, #11875)
[Link]
> This page table must always be present and takes up that 885 megs
I meant to say "takes up part of that 885 megs", the way I wrote it, it looks like it takes it all up. But with a big enough amount of RAM, it could.
Posted Jun 14, 2012 13:14 UTC (Thu)
by PaXTeam (guest, #24616)
[Link] (6 responses)
Posted Jun 14, 2012 14:19 UTC (Thu)
by nevets (subscriber, #11875)
[Link] (5 responses)
If you're going to modify the kernel, might as well just install x86_64 instead.
> an area where amd64 is worse is security due to the lack of segmentation, the baby went with the bathwater unfortunately
Bah! Linux never bother with much of the segmentation crap that i386 uses to begin with. Sure, it separates userspace from kernel space, but it does nothing to protect one task from another. Page tables are used for that purpose.
Show me one security errata that was the result of removing segmentation from x86. And I mean for Linux.
Posted Jun 14, 2012 15:39 UTC (Thu)
by PaXTeam (guest, #24616)
[Link] (4 responses)
it's an existing kernel config option, nothing needs to be modified.
> Linux never bother with much of the segmentation crap that i386 uses to begin with.
pre 2.0 (iirc) task switching? set_fs()? TLS? ;)
> Sure, it separates userspace from kernel space,
nope, (vanilla) linux uses flat segments, there's no separation at the segment level.
> but it does nothing to protect one task from another. Page tables are used for that purpose.
true but what's that matter here? ;)
> Show me one security errata that was the result of removing segmentation from x86. And I mean for Linux.
every single kernel-dereferences-unintended-userland-pointer bug (something that UDEREF in PaX protects against if you want to see how it's done properly). and asking for actual security errata when the declared policy from high up is to actively suppress them is... too funny if it wasn't so sad at the same time :P. in any case, http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+ker... should get you started.
Posted Jun 14, 2012 16:11 UTC (Thu)
by nevets (subscriber, #11875)
[Link] (3 responses)
> it's an existing kernel config option, nothing needs to be modified.
Modifying config options does modify the kernel. Do you need to recompile?
> pre 2.0 (iirc) task switching? set_fs()? TLS? ;)
I started working with 2.0, so I should never had said 'never' ;-)
Yeah, I knew about TLS, that's why I said 'much of segmentation', instead of saying 'any of segmentation'.
> nope, (vanilla) linux uses flat segments, there's no separation at the segment level.
Ah sorry, was thinking that it did. It's been a while since I've actually worked with segments. I know the kernel was not limited against accessing userspace, but I was thinking that userspace had the added protection of segments to protect against accessing the kernel.
> when the declared policy from high up is to actively suppress them is... too funny if it wasn't so sad at the same time
Are you saying that since Linux uses a flat segment space that the bugs happen for both i386 and x86_64?
Posted Jun 14, 2012 16:23 UTC (Thu)
by PaXTeam (guest, #24616)
[Link] (2 responses)
i think for most people (esp. kernel devs) modify = patch, and not 'reconfigure'. but for all i care, i got the point across :).
> but I was thinking that userspace had the added protection of segments to protect against accessing the kernel.
even if the default segments were set up this way, there's modify_ldt and TLS to get around them.
> Are you saying that since Linux uses a flat segment space that the bugs happen for both i386 and x86_64?
yes (if 'happen' = 'are exploitable'). UDEREF on i386 uses segmentation to prevent exactly this class of bugs from becoming exploitable beyond DoS.
Posted Jun 14, 2012 16:38 UTC (Thu)
by nevets (subscriber, #11875)
[Link] (1 responses)
Which goes back to my original point. Why run vanilla Linux i386 on x86_64. It's better to just run x86_64 kernel with a i386 userspace, then an i386 kernel if you have extended RAM.
Posted Jun 14, 2012 18:11 UTC (Thu)
by PaXTeam (guest, #24616)
[Link]
Quotes of the week
Quotes of the week
32 bit kernel on 64 bit CPU
So you cripple your other two machines to satisfy one?
Quotes of the week
Quotes of the week
Any sane distribution can run i386 binaries just fine on x86_64.
Quotes of the week
Quotes of the week
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
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.)
Quotes of the week
Quotes of the week
So, Debian has the ability to install a 64bit kernel on a 32bit system.
Quotes of the week
Quotes of the week
Quotes of the week
Quotes of the week
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.
Quotes of the week
The reason:
The reason:
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> ...
...
The reason:
The reason:
The reason:
$ 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)
Quotes of the week
Quotes of the week
Quotes of the week
Quotes of the week
Quotes of the week
Quotes of the week
> mode with x86_64 kernel and full i386 userspace?
Quotes of the week
Quotes of the week
Quotes of the week
Quotes of the week
Quotes of the week
Quotes of the week
Quotes of the week
*ducks*
Quotes of the week
Quotes of the week
Quotes of the week
Quotes of the week
Debian does. I am really pissed debian derivatives like Ubuntu/Mint etc don't.
Quotes of the week
lftp ftp.debian.org:/debian/pool/main/l/linux-2.6> ls linux-image*amd64*i386.deb
-rw-rw-r-- 1 1176 1176 28704056 Nov 03 2011 linux-image-2.6.32-5-amd64_2.6.32-39_i386.deb
-rw-rw-r-- 1 1176 1176 28769240 May 06 09:17 linux-image-2.6.32-5-amd64_2.6.32-45_i386.deb
-rw-rw-r-- 1 1176 1176 23154160 Jun 01 22:48 linux-image-3.2.0-2-amd64_3.2.19-1_i386.deb
-rw-rw-r-- 1 1176 1176 23208626 May 18 17:32 linux-image-3.3.0-trunk-amd64_3.3.6-1~experimental.1_i386.deb
-rw-rw-r-- 1 1176 1176 23391324 Jun 06 18:18 linux-image-3.4-trunk-amd64_3.4.1-1~experimental.1_i386.deb
Quotes of the week
Quotes of the week
Quotes of the week
Quotes of the week
Quotes of the week
2. there certainly won't be more registers for user space apps.
3. multiprecision arithmetic is rare no matter what.
Quotes of the week
Quotes of the week
Quotes of the week
Quotes of the week
Quotes of the week
Quotes of the week
Quotes of the week
Quotes of the week
Quotes of the week