Weekly Edition
Return to the Front page
| |||||||||||||
The end of the multiarch era?
Your editor, having a distinct masochistic streak, runs several different
computers, each with a different Linux distribution. For added pain, most
of them run the bleeding-edge, development version of their particular
distribution. As a result, surprises
are, well, not particularly surprising. Even so, your editor's x86-64
system running Fedora development (the distribution formerly known as
"Rawhide") managed to raise some eyebrows recently - and the news was not
all bad.
One of the endearing features of Fedora Development on x86-64 is that the chances of running "yum update" successfully at any given time tend to be less than 50% - especially if the system has any packages from Extras installed. Between dependency hassles and travel, this particular system had not been updated in some time. Your editor finally broke down, deleted a few packages which were blocking the update, and set off on what looked like a plausible attempt to catch up to the leading edge. After a quick check of the current backups, your editor fired off the "yum update" command. After thinking at length and forcing every other process out to swap in the way only yum can do, the word came back: the system could be updated, at the cost of downloading some 420 packages. Installing that many potentially unstable packages onto an important system requires a significant girding of loins - a state of preparedness which can be difficult to maintain while waiting for all those packages to download from the (not particularly speedy) mirror network. Once that process completed, yum had another long think, then announced a file conflict: /usr/bin/oowriter from openoffice.org-writer-2.0.3-7 conflicted with the same file in openoffice.org-writer-2.0.3-5. Yum, of course, refused to update the system. That much is understandable, but its subsequent decision to delete all 420 downloaded (but uninstalled) packages can only be seen as gratuitous and mean-spirited. To the uninitiated, it would appear that yum is complaining about a package conflicting with itself. Experienced Fedora x86-64 users, however, recognize the problem immediately: the x86-64 and i386 versions of the same package are refusing to play well together. This was, thus, your editor's introduction to the good news portion of this exercise: Fedora Development now has a native 64-bit version of OpenOffice.org. All that was necessary was to manually clear out the old, 32-bit version and rerun the update (in the process re-downloading all 420 packages). Some quick tests show that the 64-bit OpenOffice.org appears to work, and your editor can now begin the task of cleaning out the vast pile of 32-bit libraries that OpenOffice.org traditionally dragged onto the system with it. While a full assessment is yet to be made, it is your editor's opinion that OpenOffice.org was the last 32-bit application running on this 64-bit system. That means that the whole multi-architecture support infrastructure needed to run 32-bit programs can now go away, and it will not be a moment too soon. Multiple architecture support seems like a nice idea. With a bit of work, a system can transparently run binaries compiled for a different architecture. That can be good for system migrations, and it can make it easier to grab precompiled (or proprietary) applications from elsewhere and quickly make use of them. It allowed your editor to run OpenOffice.org even though that application was not able to build and run properly on your editor's system. But multiple-architecture support can be an administrative nightmare. Keeping multiple versions of the same package synchronized can be a challenge, and, if the package creators are not careful, they will not mix well together. It is amazing how many libraries must be dragged along for both architectures; the inevitable crufting up of the system happens much more quickly. Your editor never asked to have two versions of MySQL, CUPS, gphoto, GTK2, PAM, etc., but they showed up anyway. And one can only hope that whoever came up with /lib64 has had the opportunity to spend much time in a solitary cell with a bunch of applications using old configure scripts. In a world where applications cannot be rebuilt, multiarch support might be a life saver. But, in a free software environment, we should not need it. We can build our programs to run on the target's native architecture, and need not saddle ourselves with the overhead and hassles of multiarch support. Your editor is looking forward to cleaning up the some 140 i386 packages still on this system - they should not be needed anymore. (Log in to post comments)
The end of the multiarch era? Posted Jul 13, 2006 2:57 UTC (Thu) by loening (guest, #174) [Link] Any comments on an x86_64 compatible flash plugin?
I'm currently running i386 Firefox (on an x86_64 Fedora system). This is because there are certain web sites (e.g. the Daily Show) that regretably require Flash... and Macromedia currently only has a i386 Firefox plugin.
Will x86_64 Firefox be extended to allow running i386 plugins? Is there a free software version of Flash that's worth trying?
nspluginwrapper Posted Jul 13, 2006 6:04 UTC (Thu) by AnswerGuy (guest, #1256) [Link] You might want to try: NSPluginWrapper which is, a wrapper that can run 32-bit processes under your 64-bit Netscape/Mozilla (or Firefox, of course).
Jim Dennis
Misguided Posted Jul 13, 2006 3:20 UTC (Thu) by elanthis (guest, #6227) [Link] The author essentially is complaining "Fedora's pathetic RPM 'support' of multi-arch blows chunks" and thus he concludes that multi-arch is doomed.
Excellent logic there.
The problem really is Fedora and RPM. Multi-arch support there is based solely off of a coincidental feature of RPM to allow multiple copies of the same package to be installed at the same time. A small hack allows two copies of the same package but with different architectures to be installed and to not cause file conflicts. However, when the packages are not *perfectly* in sync, this small hack fails, RPM tries to install both packages, but file conflicts ensure.
This is stupid.
A proper multi-arch system would not blindly repackage every single piece of software for both architectures as two monolithic packages. An intelligently designed system would split arch-independent files into their own packages/components. Thus, for example, install AppFoo would entail installing appfoo-bin.x86 and appfoo-common.all. Want to install the AMD64 version, too? Install appfoo-bin.amd64, which would not have any file conflicts with appfoo-bin.amd64. They are entirely two separate packages and do not really on any hacks.
Now, let's not also get into the absurdity of *having* AppFoo for both x86 and AMD64. What exactly is the purpose of having two copies of an application installed? Nothing. Only things which *need* multiple archs should have multi-arch packages. That would essentially be frameworks and libraries. It makes sense to have an x86 and AMD64 version of libpng, but not OpenOffice.org. At least for your average work station. It turns out there *is* a use for having both archs for an application installed.
The author also ignores the fact that multi-arch is useful far beyond simply AMD64 machines. Imagine, for example, having a server which exports NFS-mounted file systems to thin clients. Some of the thin clients are x86 machines, some of them are ARM machine, some of them are PPC, etc. You *could* setup multiple NFS mounts and go through all the pain of keeping the package selection and configuration in sync. You could also just install a multi-arch system. One copy of every config file, one master package list, but binaries for all requires archs are installed. The different architectures' NFS mounts differ only in the symlinks pointing to the proper arch-dependent directories.
Getting back to average workstations, multi-arch is still useful, at least for frameworks and libraries. So all of your open source apps are now 64-bit clean, hmm? Good for you. For many of the rest of us, this isn't the case. I still have several open source apps that aren't 64-bit clean and are way too complicated for me to fix. I still have a number of x86-only closed-source apps (oh the horror!) that I am either stuck with (i.e., at work, there are proprietary apps for which no open source equivalent exists) or that I greatly desire (like games; which, frankly, I'd sooner replace my OS to play rather than dump them so that I can hold up some ethical feel-good mantra that doesn't let me do anything particularly entertaining or useful with my $3,000 chunk of hardware).
Finally, even if within the next year all the x86-only apps anyone ever needs get ported to AMD64, what happens when the next architecture switch happens? Another 5 years of slow, painful migration? With a proper multi-arch system in place, that can be made as painless as the Mac switchover from PPC to x86. Heck, maybe even *more* painless.
Multi-arch isn't going anywhere. There is an era beginning, if anything, not ending. Just because Fedora sucks rocks at multi-arch doesn't mean that multi-arch is dead, is unfeasible, or not useful. It just means Fedora sucks. Let some of the competing, much better thought out alternatives rise up. Then consider whether multi-arch is a goner or not.
Misguided Posted Jul 13, 2006 7:24 UTC (Thu) by evgeny (guest, #774) [Link] > Imagine, for example, having a server which exports NFS-mounted file systems to thin clients.
I have this all the time; why does the server need to know anything about what it NFS-exports?!
> So all of your open source apps are now 64-bit clean, hmm?
Well, of course not right now; but that was the Jon's assertion that the amount of free software that doesn't compile on any reasonable arch should be decreasing with time (and it is; OO is one of the last dinosaurs). The very idea of multiarch is because there are CPUs supporting more than one target instructions; in turn, this happened mostly because of the vast amount of closed-source software which the chipmakers wanted to support.
> Just because Fedora sucks rocks at multi-arch doesn't mean that multi-arch is dead, is unfeasible, or not useful. Let some of the competing, much better thought out alternatives rise up.
Of course, Gentoo rules here (IMHO, it does also in any other comparison with FC).
Misguided - NOT! Posted Jul 18, 2006 16:43 UTC (Tue) by hazelsct (guest, #3659) [Link] > > Imagine, for example, having a server which exports NFS-mounted file systems to thin clients.
> I have this all the time; why does the server need to know anything about what it NFS-exports?!
So that one can use a package manager on the PPC server to install the amd64 and ARM packages and serve them all up to the various clients properly. Imagine being able to "apt-get update && apt-get dist-upgrade" and have all three arches upgrade at once.
(Can't do it in a chroot because the binaries won't run -- not to mention the wasted space of the duplicated -common packages.)
Misguided - NOT! Posted Jul 18, 2006 17:27 UTC (Tue) by evgeny (guest, #774) [Link] > So that one can use a package manager on the PPC server to install the amd64 and ARM packages and serve them all up to the various clients properly.
There is no reason why a package manager shouldn't be able to deal with packages for another arch; this has nothing to do with the multiarch OS support. Did you mean perhaps the multiarch support for your favorite package manager?
> Imagine being able to "apt-get update && apt-get dist-upgrade" and have all three arches upgrade at once.
Heh, you've got quite a bit of imagination... Not to mention many technical details why it'd never work correctly (at least with the current apt), are you serious you want to have the _same_ OS on the server and clients?! And what about _several_ different thin client images? (In my case, a RH-7.3 box simultaneously serves releases of Slackware, Ubuntu, and Knoppix thin clients; users tend to be picky about their favorite distro...).
> (Can't do it in a chroot because the binaries won't run
There is no need to use chroot for that. Just give one NFS client (e.g. your own workstation) a temporary r/w acces and do all the upgrades from it.
> -- not to mention the wasted space of the duplicated -common packages.)
So now you're talking about NFS-exporting the root file system of the server?!
C'mon, NFS has a notorious track record of security holes (and is inherently insecure anyway). And, 90% of the client disk space would be due to the GUI apps which shouldn't be installed on the server.
Misguided Posted Jul 13, 2006 8:25 UTC (Thu) by nim-nim (subscriber, #34454) [Link] I'm afraid what's pathetic there is your misunderstanding of how multiarch works in Fedora, and before FUD-ing on another distro you could had least have taken the time to check what you were writing.
Hint: Fedora does indeed behave like you write it should, hand has from the first day.
Misguided Posted Jul 13, 2006 11:42 UTC (Thu) by paulj (subscriber, #341) [Link] I'm afraid what's pathetic there is your misunderstanding of how multiarch works in Fedora I'll back up his understanding over yours actually. He's 100% right in that RPM will allow "multiple copies of the same package to be installed at the same time ... and to not cause file conflicts.", just go and try it. It's a really *evil* quick hack to allow bad packages to still be installed, but at the cost of allowing bad packages to go unfixed for multi-arch problems (and hence leading to the problems below). That hack is the reason why RPM and multi-arch sucks so badly. Now, the packagers may well do (indeed, have done) their best to split RPMs into arch-dependent and binary parts, however at the base level RPM will *not* complain if the packagers get it wrong and multiple ARCHes of a package try to install the same file, RPM just silently clobbers the file. The rare times that happens these days, it likely won't actually be an arch-specific file, so it won't matter much (except when you erase the rpm, bye-bye file - even though it should remain installed), but when it is an arch-dependent file, things just got broken. If it happens with a critical binary, your system might be hosed (rare, but still it makes rpm very dangerous on multi-arch IMHO). The only work-around I know is to use exclusively use apt-rpm, which seems to implement its own file-conflict checking /before/ handing off to rpm/librpm, hence detecting such conflicts before allowing RPM to potentially run amok. Yum relies totally on librpm for conflict resolution (is what was told to me anyway on the fedora lists), hence provides no protection - packaging errors will clobber things. Multi-arch isn't voodoo, IRIX inst handled it fine years ago - not by splitting up arches, but by allowing one package to provide files for multiple arches (you could, if desired, specify which arches you wanted, either specifically when installing a package or generally via configuration variables) - but not the same filename, hence file conflicts couldn't occur. I suspect I'll get flamed mightily, particularly for the apt vs yum comment.
Misguided Posted Jul 13, 2006 13:30 UTC (Thu) by nim-nim (subscriber, #34454) [Link] To make it quick because I have other things to do :
- rpm will allow multiple package to own the same file without conflicts if the file checksums match (so multiple packages owning the same file is not an indication of packagers not having made the effort to put in common what could be - it means sharing is transparent to the user)
- Fedora will not install by default duplicate versions of everything under the Sun, if an i386 package is installed that's because the user asked to install an i386 app needing this package once upon a time
- rpm will silently clobber binaries in /usr/bin and friends (this is the only exception to the rules above), because multilib support is here for libs and the user does not need two versions of the same executable installed. While an x86_64 lib can only link to other x86_64 libs, executable calls to not care which arch the executable was build for
- Fedora dumped apt precisely because it did its own dep resolution different from the core system package manager, and differences in resolution rules caused much grief to users.
It certainly is possible to pour a lot of energy in making a more aesthetically pleasing system with no added benefits to the end users
Misguided Posted Jul 13, 2006 16:12 UTC (Thu) by incase (subscriber, #37115) [Link] > To make it quick because I have other things to do :
> - rpm will allow multiple package to own the same file without conflicts
However, this is precisely the problem with RPM and file conflicts. In the original article, the i386 version of OOo conflicted with the AMD64 version because they contained different versions of the same file (or at least that seems to be the reason here).
> - Fedora will not install by default duplicate versions of everything
True. However:
> - rpm will silently clobber binaries in /usr/bin and friends(this is the
This sounds to me (i.e. I haven't checked wether this is true, but from all I know about RPM, it should be) as if RPM doesn't make any difference between dependencies on a package libX containing libraries, which obviously need to be of the same arch as the package depending on it and a dependency on package Y for which only the outside behaviour (network, commandline, pipes, but not DLL loading/calls) matters. Which means that a package A of arch i386 depending on mysql-server will pull in the i386 version of mysql-server even though the AMD64 version of mysql-server is already installed. If that is true, I wouldn't call that true multiarch support.
cu,
Misguided Posted Jul 13, 2006 18:16 UTC (Thu) by nim-nim (subscriber, #34454) [Link] > However, this is precisely the problem with RPM and file conflicts. In the > original article, the i386 version of OOo conflicted with the AMD64> version because they contained different versions of the same file (or at > least that seems to be the reason here).
The article says the error message was:
/usr/bin/oowriter from openoffice.org-writer-2.0.3-7 conflicted with the same file in openoffice.org-writer-2.0.3-5.
so the i386 and x86_64 packages weren't at the same patch version, and yum correctly refused to install two different states of the distro at once on the same system (ie the mirrors the poster used where in the middle of a sync and not in consistent state - happens very often on the devel branch)
Had the poster waited some time for the mirror sync to finish he wouldn't have had any error
> Which means that a package A of arch i386 depending on mysql-server will
if you have the i386 package installed it will update it to i386, if you have x86_64 it will update it to x86_64, if you have both it will update both
What won't happen is two mysqld executables on the system, and rpm will only install the x86_64 file if both packages are installed.
As I wrote, nothing to see there, Fedora multilib support works, and the original comment is pure FUD.
Misguided Posted Jul 14, 2006 12:14 UTC (Fri) by incase (subscriber, #37115) [Link] > The article says the error message was:
> /usr/bin/oowriter from openoffice.org-writer-2.0.3-7 conflicted with the
> so the i386 and x86_64 packages weren't at the same patch version, and yum
While this is true for the case the original poster described, it isn't always the case. I've seen files conflicting between different packages (i.e. from different source), which were playing along nicely before.
> Had the poster waited some time for the mirror sync to finish he wouldn't
Yeah, possibly. However, if this happens, the mirrors are obviously not working correctly. The correct way to mirror is:
>> Which means that a package A of arch i386 depending on mysql-server will
> if you have the i386 package installed it will update it to i386, if you
I sure hope that this is the case.
> What won't happen is two mysqld executables on the system, and rpm will
Ah yes, and what happens in the case I described? Will rpm fullfil the mysql dependency of the i386 package by the x86_64 mysql package? Or to take a different example:
Package A contains a binary perl module, and thus depends on perl from the same architecture. Now let's say that it only exists for i386 (because the code is not 64bit clean or whatever). Package B is available for all arches (i.e. is arch-independent) but depends on A. The system is x86_64 and has the x86_64 perl package installed with various addon modules (binary and arch-indep ones). If I want to install B, what happens? Does rpm replace the whole perl tree including all those binary modules with the i386 version? Does it install a second perl binary? Or does it refuse to do anything?
> As I wrote, nothing to see there, Fedora multilib support works, and the
You repeated that, yet you didn't explain how it works even though I asked.
Regards,
Misguided Posted Jul 14, 2006 13:00 UTC (Fri) by nim-nim (subscriber, #34454) [Link] > While this is true for the case the original poster described, it isn't> always the case. I've seen files conflicting between different packages > (i.e. from different source), which were playing along nicely before.
so what? broken packages happen (especially 3rd-party broken packages) and rpm correctly protects you from then
> Yeah, possibly. However, if this happens, the mirrors are obviously not
To have a lot of mirrors you have to accept most of them will only use rsync/http sync/ftp sync to get your files
> Ah yes, and what happens in the case I described ?
rpm will install the packages you give it on the CLI is they are consistent. Both arches if you ask it to install both, single arch otherwise.
When resolving deps, yum follows this algorithm
yum will *never* remove a full arch tree of already installed packages like apt likes to do. It will add a new arch tree if necessary, and warn about conflicts if needed.
This is all rpm and yum multilib 101, I have the distinct feeling you are trying to make me lose my time and temper till you can declare Fedora+rpm+yum is terminally broken, dist foo is way better. So this is my final message on the subject. You want to know more, ask on Fedora lists or install Fedora on a partition.
Misguided Posted Jul 16, 2006 19:45 UTC (Sun) by komarek (guest, #7295) [Link] > So all of your open source apps are now 64-bit clean, hmm?
I've never even seen a 32-bit clean system, so I'm not sure this is the right question. A more useful question might be "So now all you open source apps run tolerably well when compiled for 64-bit architectures, hmm?" The only problem I see with this question is that it drains the vitriol.
ANSI C89 all the way! Or C99 if you like to live on the edge.
-Paul
Misguided Posted Jul 20, 2006 15:19 UTC (Thu) by renox (subscriber, #23785) [Link] >what happens when the next architecture switch happens?
If we look at the history, x86-64 seems to be the 'last' architecture for a long time..
The end of the multiarch era? Posted Jul 13, 2006 4:13 UTC (Thu) by skvidal (subscriber, #3094) [Link] Quote:Yum, of course, refused to update the system. That much is understandable, but its subsequent decision to delete all 420 downloaded (but uninstalled) packages can only be seen as gratuitous and mean-spirited. End Quote.
Or you could just call it a bug rather than attributing it to some kind of malice. Read the docs for this feature. It's called 'keepcache' and was specifically mentioned in the fedora core 5 release notes. It was added in yum 2.6.X in order to keep people's /var/ partitions from filling up. We've got a bug report open about in some situations it clearing the cache even if the packages did not successfully install. However, we've not been able to replicate it which makes fixing it difficult.
If you do not want i386/i686 packages then simply add:
to your yum.conf under [main]
and if you want to remove all the i386 or i686 packages from your system run:
yum remove \*.i386 \*.i686
and that will do it.
I realize this was an editorial but your snarky and caustic tone isn't terribly helpful. I can't help but notice a complete absence of bug reports from you on the problems you've experienced and yet you've found time to be hateful on your website. That's unfortunate.
-sv
The end of the multiarch era? Posted Jul 13, 2006 4:51 UTC (Thu) by charris (subscriber, #13263) [Link] ...and yet you've found time to be hateful on your website.Geez, lighten up, skvidal. Hateful, hateful? Are you going to stamp your little foot, slam the door, and burst into tears? I thought it was funny.
bug reports and editorials Posted Jul 13, 2006 6:27 UTC (Thu) by pjm (subscriber, #2080) [Link] I think it reasonable to ask people to file bug reports about things they don't like before complaining so publicly.
bug reports and editorials Posted Jul 13, 2006 8:21 UTC (Thu) by drag (subscriber, #31333) [Link] It's just a article. People are allowed to bitch and moan if they feel like it and there isn't any single thing wrong with it as long as they aren't being slanderous.
Obviously the guy isn't that pissed about it or he would of stopped using the software all together.
Plus it WAS funny. Made me laugh.
Remember (even if you have to say it to yourself over and over again to remind yourself):
ALL SOFTWARE SUCKS.
bug reports and editorials Posted Jul 13, 2006 18:21 UTC (Thu) by pimlott (guest, #1535) [Link] Or as the prophet sayest, "Thou shalt know by your heart that all software sucks."
The end of the multiarch era? Posted Jul 13, 2006 5:02 UTC (Thu) by pimlott (guest, #1535) [Link] I realize this was an editorial but your snarky and caustic tone isn't terribly helpful.But terribly entertaining. That counts for something, right? Seriously, there's nothing to gain by getting defensive or self-righteous about problem reports, no matter their shortcomings in tone or content. If Jon had this problem, there are probably a hundred users with worse experiences who got too frustrated or overwhelmed to say anything. Swallow your pride and thank him for the feedback.
The end of the multiarch era? Posted Jul 20, 2006 17:16 UTC (Thu) by rvfh (subscriber, #31018) [Link] AND he made it very clear that he was running a cutting edge development version, so bugs are not only excusable, they're expected!
The end of the multiarch era? Posted Jul 13, 2006 5:40 UTC (Thu) by Los__D (guest, #15263) [Link] I realize this was an editorial but your snarky and caustic tone isn't terribly helpful. But very, very funny.
Survey Says! .... Posted Jul 13, 2006 6:19 UTC (Thu) by AnswerGuy (guest, #1256) [Link] It was the funniest line in the whole article. My came in to see what I was chuckling about and I read the hole lead in and she's laughing now. (Personally I think it's pretty bone headed to default to empty a cache when a process is quitting due to an error. The most common usage scenarios would entail attempting to fix the error and re-run the process, DUH! If I was implementing something like this I'd make the configuration take a list of flags, percentages, and numeric values (all optional). So you could say: Clean-up: on success; 15%: 800M which would mean: "clean up only if the whole process was successfull (the RPMs are all installed now), or the file systems has less then 15% or 800MiB of free space available (in case I had some real need to build ISO images under that fs that I feel are more pressing than the risk to my cache). Other flags might be: obsolete, never, always (obsolete meaning that we clear the cache of any files for which we've already got an updated version). (Some peope might question why I'd have a percentage and a number --- answer is I might want to have a config that I can use across lots of hosts and I may not want to have to do funning template perl -pi -e 's/..../.../;' stuff to fiddle with calculated sizes).
JimD
The end of the multiarch era? Posted Jul 13, 2006 10:15 UTC (Thu) by brwk (guest, #6849) [Link] While I understand Seth's angst at the negative comments against yum, I think it's one of those difficult situations where the software author has gone a good job and it is the software distribution's defaults that causes a problem in specific cases.
In our environment we have a locally grown RPM (which works on RHEL, SuSE and FC), that tweeks litterally dozens of config files to change all manner of things from /etc/yum.conf, /etc/nsswitch.conf, /etc/yum.repos.d, /etc/X11/gdm.conf and so on. However, this has been grown over the last fifteen years by a team that has over a hundred man years experience in managing Unix/Linux systems. It seems to me that there needs to be a mid-point between the "one size fits all" of a distribution default and the "ultra-tailored" environment that experienced sysadmins can create. Maybe a number of "system profiles" that can be selected: "low intervention" (ie cleans up as much as possible), "well resourced" (ie caches can be kept around, etc) and "paranoid" (ie keeps everything for rollback, etc).
Regards, Bevis.
The end of the multiarch era? Posted Jul 13, 2006 13:08 UTC (Thu) by corbet (editor, #1) [Link] Whoa, Seth, sorry you took it so personally. Certainly wasn't my intent. A couple of things:1) I'm running development distributions; I expect strange things to happen every now and then. One can only laugh at them, that's what I tried to do. 2) I do get onto the fedora-test list occasionally when things go really wrong. I have also occasionally put things into bugzilla. I have certainly posted about the challenges of keeping multiarch systems current in the past (though not recently). Believe it or not, this article was not an attack on Fedora - it was a discussion of how it's getting better.
The end of the multiarch era? Posted Jul 13, 2006 14:58 UTC (Thu) by cventers (subscriber, #31465) [Link] 25 comments, many of them firey :)
That's how you know you've written a good article.
PS: I think Multiarch support is important. But good article! :)
The end of the multiarch era? Posted Jul 13, 2006 20:32 UTC (Thu) by dmantione (guest, #4640) [Link] If a president holds a speech that it would be a good idea to disband thearmy that will cause a lot of discussion. However, that does not mean it is necessarily a good speech.
Which reinforces only Posted Jul 18, 2006 4:19 UTC (Tue) by xoddam (subscriber, #2322) [Link] that there is a difference between an editor and a Commander in Chief.Powerful interests don't need to 'hold speeches' when they 0wn the network media and the voting machines.
The end of the multiarch era? Posted Jul 13, 2006 5:29 UTC (Thu) by xorbe (subscriber, #3165) [Link] > That much is understandable, but its subsequent decision> to delete all 420 downloaded (but uninstalled) packages > can only be seen as gratuitous and mean-spirited.
Hahaha! Sorry... I got tired of the Mandrake tool doing
The end of the multiarch era? Posted Jul 13, 2006 9:28 UTC (Thu) by dale77 (guest, #1490) [Link] Nice article, particularly that mean-spirited view of yum.
I too hope multiarch will go west, although I currently run 32bit soft on
The end of the multiarch era? Posted Jul 13, 2006 10:32 UTC (Thu) by nix (subscriber, #2304) [Link] Multiarch may be unnecessary (in the long run) on x86-64, but it will always be needed on other platforms, on which the common case is to keep things 32-bit because the only difference between 64-bitness and 32-bitness on those platforms is alignment constraints, accessible address space, and the sizes of pointer and integral types. Going 64-bit thus has disadvantages (reduced speed and more cache misses, increased memory usage and disk space consumption) that more than counter the advantages.
Ones which spring immediately to mind include MIPS64 and SPARC64. On such platforms, the only stuff which tends to be 64-bit is kernel code and things which truly benefit (mathematical stuff, stuff which needs huge address spaces like perhaps image processing software, and things which really benefit from the extra size of words, like Emacs). Everything else is left 32-bit. (As others have commented, though, the only things which ever need two copies of themselves installed are *libraries* and in rare circumstances a few header files; the rest should have only one arch's version installed.)
So multiarch continues to be useful.
The end of the multiarch era? Posted Jul 13, 2006 11:56 UTC (Thu) by dmantione (guest, #4640) [Link] I couldn't disagree more with the author. Of course his reasoning is afallacy, but apparently the author disagrees with backwards compatibility regardless wether RPM works correctly. All Linux users befefit greatly because of the backward compatibility of the kernel. You can simply upgrade your kernel without fear of breaking your system. No such compatibility exists for many user space applications. I'm quite sure most readers here have seen the famous glibc missing symbol messages. Sure, recompiling is a possibility for open source applications. I'm quite confident few people have systems where they compiled all applications themselves. Nor do I have the idea that people desire to recompile all their application when they upgrade a library. Lastly /lib64 was a very smart choice. It is mandated by the x86_64 ABI http://www.x86-64.org/documentation/abi-0.96.pdf, so complain to the authors about it. /lib64 is based two ideas: * It must be possible to install 32-bit RPMs on both i386 and x86_64 systems without change. * Source code can be changed to use /lib64, binaries cannot. So, to allow existing rpms to install on x86_64 systems, they should be able to find their libraries in /lib. This does not just benefit developers of closed source software, but also any open source project that distributes binaries. Try our Free Pascal i386 RPM and note that just magically works on your Linux system, regardless which libc you use or wether you use i386 on x86_64: ftp://ftp.freepascal.org/pub/fpc/dist/i386-linux-2.0.2/rp... That is how software is supposed to work. Besides multiarch not just benefits the user who wants to use software, but also the developer who wants to support both 32 and 64 bit. I wish multiarch a long and healthy future.
The end of the multiarch era? Posted Jul 13, 2006 13:09 UTC (Thu) by kleptog (subscriber, #1183) [Link] All Linux users befefit greatly because of the backward compatibility of the kernel. You can simply upgrade your kernel without fear of breaking your system. No such compatibility exists for many user space applications. I'm quite sure most readers here have seen the famous glibc missing symbol messages. Sorry? The backward compatability of glibc is leagues ahead of the kernel's. Yes, back in 2.4 you could (and I did) upgrade without care, but these days you have to remember to upgrade hotplug, sorry, udev and any of the other programs that need simultaneous upgrades.OTOH, glibc has backward compatability going back several versions. There are multiple versions of fdopen for example, to make sure programs get exactly the version they compiled with. The kernel doesn't even try to provide that kind of compatability. Lastly /lib64 was a very smart choice. The biggest problem with /lib64 is that people, rather than looking at how other archtectures had been doing it for years, went off and invented their own inflexible system. They even ignored existing solutions, see /usr/lib/i[3456]86 for storing libraries optimised for specific CPUs. /lib64 is bi-arch, not multiarch. It will hopefully go the way of the dodo to make place for true multiarch.In that I agree with you, multiarch is the way of the future. We're just not there yet.
The end of the multiarch era? Posted Jul 13, 2006 14:09 UTC (Thu) by dmantione (guest, #4640) [Link] No, we've had a lot more breakage trouble with Glibc than with thekernel. Glibc breaks compatibility within minor versions. An example of such breakage: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90002 It is true that glibc has backwards compatibility functionality inside, and things seem to be improving, but for Free Pascal we have had to stay away from it, it was simply impossible to support multiple distributions when we had libc dependencies. Note that on Darwin & Solaris we do use libc, and as of yet we never had any breakage.
The end of the multiarch era? Posted Jul 13, 2006 18:11 UTC (Thu) by kleptog (subscriber, #1183) [Link] I think you're comparing apples to oranges here. You're comparing a bug in glibc (which was fixed) to the fact that the kernel breaks backward compatability permanently in "minor" releases. devfs was removed in 2.6.13. Systems using udev won't work with kernel versions older than 2.6.15. In the middle is hotplug.
Having the same userspace work for all versions of 2.6 kernels is just about impossible.
The end of the multiarch era? Posted Jul 13, 2006 19:11 UTC (Thu) by dmantione (guest, #4640) [Link] It was not fixed, you are confusing the _res issue with the errno issue.The 1.0.10 compiler from 2003 still works on modern kernels, so we can test: daniel@laptop:~> cat test.pas program test; uses inet; begin end. daniel@laptop:~> rpm -q -a|grep glibc glibc-2.3.3-118 glibc-locale-2.3.3-118 glibc-devel-2.3.3-118 daniel@laptop:~> /usr/local/lib/fpc/1.0.10/ppc386 -n -Fu/usr/local/lib/fpc/1.0.10/units/linux/* test /usr/local/lib/fpc/1.0.10/units/linux/inet/inet.o(.text+0x3a2): In function `_INET$$_$$_THOST_$$_NAMELOOKUP$STRING': : undefined reference to `h_errno' /usr/local/lib/fpc/1.0.10/units/linux/inet/inet.o(.text+0x40d): In function `_INET$$_$$_THOST_$$_ADDRESSLOOKUP$THOSTADDR': : undefined reference to `h_errno' /usr/local/lib/fpc/1.0.10/units/linux/inet/inet.o(.text+0x742): In function `_INET$$_$$_TNET_$$_NAMELOOKUP$STRING': : undefined reference to `h_errno' /usr/local/lib/fpc/1.0.10/units/linux/inet/inet.o(.text+0x79a): In function `_INET$$_$$_TNET_$$_ADDRESSLOOKUP$LONGINT': : undefined reference to `h_errno' /usr/local/lib/fpc/1.0.10/units/linux/inet/inet.o(.text+0xa6c): In function `_INET$$_$$_TSERVICE_$$_NAMELOOKUP$STRING$STRING': : undefined reference to `h_errno' /usr/local/lib/fpc/1.0.10/units/linux/inet/inet.o(.text+0xb37): more undefined references to `h_errno' follow test.pas(7) Error: Error while linking daniel@laptop:~> The issue was solved in the modern compilers by coding a netdb package in Pascal, and it never gave us trouble ever again. I think you are right about the kernel versus its system tools. However, for applications the kernel has remained remarkably compatible. We recently discovered that we were still using a system call that was replaced by a more advanced one in kernel 2.0 (we are one of the older free software projects), it still worked.
The end of the multiarch era? Posted Jul 13, 2006 13:57 UTC (Thu) by wookey (subscriber, #5501) [Link] Lastly /lib64 was a very smart choice.Sorry - that's not true. It's a very limiting choice. It assumes there is only one case where you might want more than one arch present - mixing 32 bit and 64 bit binaries of the same(ish) CPU architecture. The multi-arch concept is much more widely useful than that, as a couple of people have mentioned above, and described in some detail at http://lackof.org/taggart/hacking/multiarch/. It can help with things like cross-building (somewhere to put target-system binaries (e.g. ARM) needed during the build process which you are going to run using an emulator such as QEMU. Mixing glibc and uclibc, mixing big-endian and little endian code, mxing OS stuff (having some windows programs installed on your linux system), etc. A properly-designed multi-arch system make all sorts of interesting things possible. Debian is implementing a scheme which allows arbitrary mixes of architectures:
The end of the multiarch era? Posted Jul 13, 2006 14:14 UTC (Thu) by dmantione (guest, #4640) [Link] Sure, you can generalize that /lib64 can be improved to randomarchitectures. It is even a good idea. In the meantime, Debian (and derivates) is one of the few x86_64 distribution that cannot flawlessly run x86 binaries. In typical Debian style, it will take years to develop. Considering this, /lib64 was a good choice.
Just use Smart Posted Jul 13, 2006 13:46 UTC (Thu) by jnelson (subscriber, #6693) [Link] Just use Smart referenced here:http://labix.org/smart (it's home) and here: http://fedoranews.org/blog/?p=573
Smart has vastly better multi-arch support and has better dependency resolution algorithms.
I use smart on SuSE after having experimented with apt (terrible multi-arch support) and yum (all of the problems you describe above).
Just use Smart Posted Jul 20, 2006 8:47 UTC (Thu) by quintesse (subscriber, #14569) [Link] Agreed, smart is really good at solving strange dependencies and has so far not given me any problems. The only things that I can see wrong with it are:
- occasional cyclic upgrades/downgrades where running smart multiple times will first upgrade a package and then downgrade it again, ad infinitum
- SLOW for large upgrades, forget about upgrading from FC5 to FC6 using smart
NB: For upgrades like that the advise seems to be: apt-get dist-upgrade and smart afterwards to fix any problems. And if you tried to do it using yum, well the mess is entirely your own fault.
The end of the multiarch era? Posted Jul 13, 2006 18:59 UTC (Thu) by lindahl (subscriber, #15266) [Link] Multiarch isn't going away. In 64-bit systems, it's frequently the case that a 32-bit executable can be much faster. Why? Programs that use a lot of pointers.
PathScale's compiler, for example, is ~ 2x faster on x86-64 as a 32-bit app. And there are 4 parts of the SPECint benchmark suite which are generally faster as 32-bit on x86-64. On other architectures, a much larger proportion of programs are faster as 32-bit apps, since x86-64 has more registers for 64-bit apps, but other architectures generally don't.
-- greg
The end of the multiarch era? Posted Jul 13, 2006 21:43 UTC (Thu) by garloff (subscriber, #319) [Link] I agree with the editor that having OO.o finally work on x86-64 isreally good news.
But it's strange to read that multiarch support is a pain for him.
I really never had such trouble. If I compile code myself (which I
Biarch is working and works well. It allows you to run apps that for
The end of the multiarch era? Posted Jul 14, 2006 7:22 UTC (Fri) by ymmv (subscriber, #4375) [Link] Multiarch packaging has been a failure even since the double arch Solaris.The worst was when patches were available for one arch (32bit), and the supposed to be there sparcv9 binaries were not included in the patch.
Your operating environnement was working nicely, but your 64bit application refused to load and run.
Suppose also you have to package some low level library for Solaris (or any other double arch OS): you have to compile it twice, test it twice, with different directory schemes, and then package. A real mess :(
Tru64/Digital Unix/OSF/1 approach of having everything 64bit was much more simple to administer, at the expense of some memory and disk to hold these 64bit binaries. Peanuts nowadays.
So please, keep these free and open OS as mono-architecture.
The end of the multiarch era? Posted Jul 14, 2006 11:53 UTC (Fri) by nix (subscriber, #2304) [Link] All SPARC64 OSes are biarch at least, sorry (even if the 64-bit part is just the kernel, it is still there, and it is often a bit more than that).
The end of the multiarch era? Posted Jul 19, 2006 16:02 UTC (Wed) by kolyshkin (subscriber, #34342) [Link] Looks like nobody gave the answer on "downloading all the files again" problem. To keep the packages after downloading them, just add "keepcache=1" to [main] section of /etc/yum.conf file.
Still, I agree it would be much better to remove the packages only if installation succeds, not in any case.
The end of the multiarch era? Posted Dec 3, 2006 17:59 UTC (Sun) by Aukcje (guest, #41946) [Link] I'm currently running i386 Firefox (on an x86_64 Fedora system).Thanks Aukcje
The end of the multiarch era? Posted Jun 8, 2007 12:47 UTC (Fri) by cooles (guest, #45682) [Link] Thanks for very needed for me informations! Really thanks
|
|||||||||||||