From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1E2whK-0005Z4-4t for garchives@archives.gentoo.org; Wed, 10 Aug 2005 19:57:10 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j7AJt6ke006622; Wed, 10 Aug 2005 19:55:06 GMT Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j7AJt5Pn025089 for ; Wed, 10 Aug 2005 19:55:05 GMT Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E2wep-0006kB-Eb for gentoo-amd64@lists.gentoo.org; Wed, 10 Aug 2005 21:54:35 +0200 Received: from ip68-230-97-182.ph.ph.cox.net ([68.230.97.182]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Aug 2005 21:54:35 +0200 Received: from 1i5t5.duncan by ip68-230-97-182.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Aug 2005 21:54:35 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: Re: Re: Re: file type not allowed in /usr/lib Date: Wed, 10 Aug 2005 12:53:37 -0700 Organization: Sometimes Message-ID: References: <42F53B6D.1080908@burnieanglican.org.au> <42F66B78.1030708@gentoo.org> <42F7B071.7060603@gentoo.org> <42F9FD31.4050307@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-97-182.ph.ph.cox.net User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Sender: news X-Archives-Salt: e19e78f8-fb07-4865-ab09-d678b799b073 X-Archives-Hash: 52676a58be7f971dc0a9ee82605d920f Simon Stelling posted <42F9FD31.4050307@gentoo.org>, excerpted below, on Wed, 10 Aug 2005 15:12:17 +0200: > Well, the problem is, even if you have two different directories for each > bitness, the binaries will still collide, because of $PATH: How do you > decide whether you want the 32bit or 64bit player? There's no real > solution other than having suffixes like e.g. mplayer32 and mplayer64. You > could reset PATH each time you launch a binary of other bitness, but > that's just an ugly workaround and it may not always do what you want. So > you have to use suffixes. But then, you don't need two directories, as the > binaries won't collide anymore... Additionally, what do you do about > scripts? PATH doesn't work there, and so you'd have to first edit the > #!-line before executing it. As I've imagined it here, altho I admit there are likely huge holes in it that I'm not aware of given I haven't had to be concerned with the actual implementation process... $PATH would include $PREFDIR:$DEFAULTBIN:$SECONDARYBIN. $DEFAULTBIN would be the normal system default, presumably bin64. $PREFDIR would contain symlinks to individual executables in $SECONDARYBIN, where they are preferred over those in $DEFAULTBIN, allowing a system default, with individual application defaults differing from the system default, as necessary. In addition, $PREFDIR could contain suffixed or otherwise identified symlinks to both bitness versions specifically. Thus, applications could be referred to by general name to get the locally preferred default in $PREFDIR, suffixed name to get the specific bitness version, or by absolute path, getting the specific bitness version or the locally preferred default as specified in $PREFDIR, as desired/appropriate. There'd be a similar config dir setup, with a system default config, and a secondary config dir for those apps that are configured differently between the bitnesses. Again, a general symlink dir could be used to coordinate things, or compliant apps could do the usual mult-dir search until they found a config, searching first their specific bitness config-dir then the system default config-dir. Presumably, the suffixed symlinks would be created in $PREFDIR at installation. There's be a helper script similar to *-config that could be used to select between them, or the sysadmin could set the symlinks manually if desired. Each distribution could set up its own system, but again, LSB/FHS or the like standardization would be a pretty big benefit, here, such that at least the standard dir locations to search were agreed. Some distributions would then go with the more or less simple symlink infrastructure as outlined above, others may replace the symlinks with more complex wrapper scripts that would "do the right thing" for that specific distribution. I don't see scripts as being a huge problem, particularly if the dirs were standardized. Those scripts that needed specific bitness versions would call them, presumably by suffix; those that didn't would call the unsuffixed version, which would automatically find the appropriate default, either picking it up from $PREFDIR, or falling thru to the global system default in $DEFAULTBIN if a prefdir symlink or wrapper wasn't defined, presuming of course, that path was set appropriately. Where such path presumptions couldn't be relied upon, for security or other reasons, absolute paths could be used, using the already common in scripts if-executable type tests except in the case of the #! lines, which would still need tweaked by distributions or sysadmins in some instances. Like I said, there's probably huge holes in all that, due to the fact that I've never been in the position of someone having to worry about such implementation details at a distribution level... > On the other hand, multilib will never be a permanent solution, I see it > as a nice way to keep compatibility with old stuff, but as soon as > companies are starting to provide 64bit binaries, it will slowly > disappear from amd64's sight. > > So the final question is: Is it really worth the effort? Well... I suppose it depends on just how "slow" reality defines "slowly" to be. We have the precedent of the 16 -> 32-bit transition. I'm not familiar with *ix from back then, but know at least on the proprietaryware aka MS side, the practical transition took a decade or longer, and there are still 16-bit binaries in use today, altho very often run under software, if not hardware, emulation. Think about how long it was before 32-bit virtual 386 mode became common. Then consider how much more society depends on 32-bit x86 today, as compared to 16-bit x86 back then, and the fact that 32-bit is far closer to "good enough" for most folks using it today than 16-bit was back then -- the improvements are more incremental now, because the percentage improvement on the established base is smaller, even if the improvement in the absolute sense is the same or even greater. Given that, I think a decade is a realistic estimate. Admittedly, there are quite a few different factors this time around, the far higher degree of computer use in society, and the "good enough" factor, on the one hand, against the possible paradigm shift to FLOSS, and what that might mean to the whole debate, on the other. Still, a decade seems reasonable, and that's a /very/ long time, in computer evolution terms. Then there's the whole question as to where to start counting. Where is day zero in that decade? I'd contend that it's in the past, certainly, but do we call the introduction of the Opteron day zero, or do we call the introduction on the desktop, the Athlon 64, day zero, or do we call Intel's introduction day zero? Are we already a couple years into that decade, or only a few months? If it's a couple years, you are correct, by the time we get multilib fully implemented, we may have already passed the half-way mark, and the actual need for multilib, let alone multibin, will be on the decline. If day zero is taken to be when the Intel version actually became available on the streets, it's still fairly early in the game, yet, and it may well be worthwhile considering multibin, even now, particularly since the bulk switch from x86(32) definitely remains ahead, and if the decade timeline proves optimistic. Also throw into that the whole proprietary/open thing. Certainly, those with more freedom to modify the software they run, aren't going to be needing such drastic compatibility measures as those without. (It's for that reason that the entire debate is mostly an intellectual exercise, for me, as I personally come down far closer to the freedom end of things, than, say, those willing to run even proprietary video drivers and games, let alone entire proprietary OSs, and most of the apps on them.) So... I'm /definitely/ of the opinion that multilib is worthwhile. I think multibin /could///would/ have been as well, were the momentum for it at the same level as multilib is today. However, I think most will agree that it's definitely rather late to start worrying about multibin at this point, however nice it /might/ have been to have it. IOW, as a practical matter, I don't see multilib disappearing from sight any time soon. If anything, its importance is likely to increase DRAMATICALLY over the next few years (three at least), as the mainline x86 computing public switches over, bringing with them all that 32-bit binary-only cruft they'll invariably have. That is, after all, one of the big reasons x86_64 has become the success it has, even in the face of Intel's pushing ia64 as the "preferred" alternative. By 2008, multilib importance may begin to decrease, tho I don't see it dropping to something that can really be ignored (unless deliberately so), until 2010 at the earliest. Then again, what's this "Joe Blow" know? =8^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-amd64@gentoo.org mailing list