Simon Stelling posted <[EMAIL PROTECTED]>, excerpted below, on Mon, 08 Aug 2005 21:20:17 +0200:
> Duncan wrote: >>>Just a personal note on this: What's the point in repeating everything? >>>You only bore people with it. I think we can assume that the original >>>poster either gets it the first time, or he'll surely ask again and >>>give details about what he didn't understand. >> >> OK, first, the tone here and below seems to indicate I offended you in >> some way. Let me unconditionally state at the outset, that such was in >> no way the intent. > > First, I didn't really want to offend you, although I have to admit that > a few statements were rather harsh. I didn't feel offended, and I know > you didn't want to say my answer was incompetent. However, if I *were* > the questioner, I'd feel offended, since I don't need everything > explained twice, and if I don't get it, I ask further questions. > Generally explaining it a second time somehow implies that I didn't get > it the first time, but perhaps that's just me. Hmm... Maybe it's because I've been quite active on USENET (and public mailing lists like this one, now) for some time, but to me, that's just the nature of the medium. Two or sometimes five or ten replies all stating the same thing or sometimes wildly different things <g>, just comes with the territory. Sometimes folks build on what others have said, sometimes they disagree and say why, sometimes the posts don't have any relation but say essentially the same thing, because neither poster saw the other's post before they posted. IMO, it's one of the strengths of the medium that each poster says it his own way, most rather briefly, some (like myself) taking hundreds of lines to explain (their view of) why things work as they do, the implications, and some of the exceptions to watch out for and what to do to avoid or work around them, all to the Nth degree! <g> Basically, it allows the original poster (aka OP) to pick and choose the replies that meet their needs. If they want a quick solution, the five line "do this" is perfect! If they want to know the background and what to do to prevent the issue again, and/or how to fix similar but not identical issues, without having to post another query, the next time, then the 200-liners <g> come in handy. So... yes, occasionally someone gets offended. However, once they understand the medium, they generally don't any more, and, as always with the medium, for those seriously offended, there's always the kill file/filter option, the exercise of which does not require notice or reason be given. >> [W]hat about binary only installers? > > Judging from my experience, the opposite is the case: Most of the > hardcoded programs just install to /usr/lib without bothering about > their bitness, so it'd be better to set lib = 64bit as a > longterm-solution, assuming that amd64 will (at least partly) replace > x86. Also, most of the "hardcoded programs" aren't closed source but > open source apps. Also, once these hardcoded paths are made suitable, > it's quite easy to do the same with the next version: Just bump the > ebuild. There are *very* few configure scripts which try to find out the > correct place for libraries theirselves, and in most of these very few > cases, they're broken anyway, as the just grep uname -a for Athlon64 or > Opteron, which then would break 32bit. Hmm.. surprised me on the hardcoding being mostly open source... I guess it makes sense, tho, as the OS folks figure it's open, so folks can change it if need be, while the closed source folks don't /want/ folks examining their stuff, so have reason to make it configurable. However, the real point is dealt with below... >>>>mostly duplicated common code, it's ALWAYS more efficient to keep in >>>>line with the rest of the community, so the maintenance and further >>>>development > > 'more efficient' is a synonym to 'better', for me, as I consider > efficiency a 'good' thing. If you mean it's more comfortable, you're > right, but then this questions pops up: Do we want to make good > applications, or comfortable ones? (Comfortable to the developer, not > the user of course.) Ah... I see your viewpoint, now! It never occurred to me... I was using "efficient" as in "getting as far as possible using the least amount of work and resources possible". Thus, "efficiency" is usually thought of as having a good effect, but is actually neutral, in that something can be "ruthlessly efficient", or "an efficient killing machine", or the like, in which case the effect can be bad, depending of course on one's viewpoint, whether one is doing the killing or being killed (or watching it occur, with approval or disapproval), in the case of the "efficient killing machine", for instance. Thus, here, I was saying it's "less work and requires less resources" to go with the community common standard. That's ALWAYS the case. Whether it's actually worth spending the extra work and resources, therefore, depends on just what value is assigned to the proposed difference from standard, in question. >> Because there's an unavoidable cost involved with being different, do >> it where it's worth the trouble, don't do it where it's not. > > Sure, if that's the point you made, I absolutely agree, I just don't > think such a self-evident statement is even worth to mention, so I > thought you wanted to state something different. The trouble is... what's self-evident to one person, isn't always so evident to another! I've unfortunately had to find this out the hard way on more than /one/ occasion! <g> Anyway, here, the context was in how that forms the unifying force that keeps (GNU/)Linux from fragmenting into incompatibility, as proprietary Unix did, and how that forms a counter-balance to the forces of fragmentation. The argument is quite familiar to those who've been around open source for some time, certainly, but evidently, it isn't quite self-evident to everyone, as the question of fragmentation does continue to come up. > So the ultimate goal shouldn't be to adore a certain standard but to > make the tool as flexible as possible, e.g. by providing Makefiles where > you just can reset LIBDIR if you don't the default. If every tool would > be that flexible, we wouldn't need to bother about FH standards at all. It /would/ be nice... [snipping a section I entirely agree with, post was getting too long...] >>>Where do you get this information from? We (read: we, the Gentoo/AMD64 >>>developer team) never published such a roadmap, nor do we have one >>>ourselves. Please, don't cook up a story just to enlarge your >>>pen^W^W^Wmails. >> >> OK, it's quite apparent you have a personal problem with my style, and >> possibly with the fact that I paralleled your post, tho I really don't >> know why that should be a problem at all. Perhaps that part should be >> taken to private mail, if you wish to continue the discussion. > > Not at all. The "enlarge your pen^W" shouldn't offend you, it was meant > as a joke, critisizing the massive amount of spam we all get with this > topic, not you :D Sorry if it looked like a diparaging remark, that > really wasn't my intention. OK, got it! The case of the missing smiley chalked up another victim, here, I must admit! (See next for content comment.) >> The key is, it's my speculation, and the phrasing I chose /should/ have >> made that quite apparent. [snip] > > It rather looked like an official roadmap coming from a dev to me, but > in that case, I just got it completely wrong. I apologize. > >> Assuming that we agree on the current status, and that nothing has >> changed from previous plans (and of course that I understood said plans >> correctly), what's the next reasonable step in the process? [snip] > > What you stated above was correct, but given the fact that many users > think much of you, i find it risky to issue a complete roadmap with more > or less precise dates for each step. The main problem I saw here were > users coming to us in 2007 and asking why the hell we didn't finish the > whole thing. OK, it's clearer now what you were referring to, and indeed, I agree, I could have been clearer in specifically stating it was NOT a devs roadmap. I'll plead the "I'm still learning" excuse, here. You make a decent point. I've been personally in the process of coming to terms with what it might mean for me to be a Gentoo AT, and the implications that should/will have for my posting. I've been a user, only a user, if perhaps a somewhat influential one, in 100% of my USENET and mailing list rolls, for as long as I've had such rolls. As such, I've not had the responsibility of representing someone else, and could speak my mind, because it was /only/ me I was representing. I take seriously the advice in the AT guide, and have been considering the implications that will have on my posting style, as well as whether I'll choose to post with my Gentoo identity (once I get it, let me be absolutely clear lest anyone be in any way confused, I don't have it nor do I claim to have it yet) as part of my regular sig, only some of the time, or if I'll only use it with the devs and on bugzilla. Quite apart from AT, however, it just happens to fit in there too, you are correct in that it would have been possible, indeed, preferable, that I made it a bit more clear that the "we" I mentioned several times was NOT "we" as in Gentoo-amd64 devs, but "we" as in the commonality of Gentoo-amd64 users AND devs -- and that I was speaking as the "user" side of that "we". Specifically in this "roadmap", while I DID mention "I expect", and "possible" and other such qualifiers, I COULD and SHOULD have also specifically stated this was NOT a devs provided roadmap. Again, I'm still learning, but you've persuaded me. =8^) > Well, your not just a random guy like Joe Blow, you're a much > appreciated user with a lot of knowledge, and that gives you power as > well as responsibility. Aye. Sometimes I'd rather be just a Joe Blow! <g> >>>>However, that's really only half the issue. The other half is >>>>portage, which currently can't track 32-bit dependencies separate from >>>>its 64-bit dependencies. >>> >>>You can take comfort with the fact that even if portage already had >>>this functionality, there wouldn't be real multilib now. >> >> Somewhat of an enigmatic comment. There are a number of ways it could >> be taken. >> [snip speculation that proved /not/ to be the case, thankfully! <g>] > > Heh, that really made me laugh. We're not going back, everything is > going on as planned. The problem I had in mind when writing the above > statement is following: > > Let's say we have appfoo (yes, again :D), which needs various > X11-libraries, as it has a GUI. We want appfoo to be compiled 32bit, but > the huge majority is 64bit, and of course xorg-x11 is 64bit too. Now, > where we want to install appfoo as a 32bit binary with the portage able > to track 32bit dependencies, it will install xorg-x11 32bit, because we > need the libraries in that packages 32bit. But then, the install routine > would overwrite the xorg binary and we'd end up with a 32bit xorg, which > we don't want. To solve this issue, we have the following options: > > a) Split up libraries and binaries into seperate packages. This is what > currently happens to X, thanks to spyderous. See eradicator's thoughts > on this [2]. > > b) Implement a filter to just install the shared objects. This has the > advantage that we don't have to split up a huge amount of packages and > keep closer to upstream, which is generally a good idea. However, there > are still unresolved issues: Portage would need another addition, > something like a 'only libs' flag, and personally, I don't like that > idea so much, as it looks a bit untidy. Also, you need e.g. headers the > first time you install a certain library, so things are getting > complicated. > > In addition, there is still the unresolved issue about the -config > scripts in /usr/bin, which would get overwritten everytime you install > the same lib with another bitness. Unfortunately we can't just copy a > solution from another (binary-based) distro, as they don't have this > problem. Also, the universally beloved FHS doesn't give us an answer to > this problem. A really easy solution would be to just create /usr/bin64, > similiar to /usr/lib and /usr/lib64, but we all know this would lead to > a massive amount of time-consuming work, and as you said in your > original mail, it's simply not worth the effort. Of course it wouldn't > be a problem at all if all applications would have a more flexible build > system, as I stated above. > > All in all, I'm sure we will have a fully multilib-capable system in the > end, but I'm rather pessimistic about the time schedule. Very, /very/ good point. It's one I'd thought of, but not really in this context, and certainly not with all the implications, so there's some rather new info for me here. That's what I was hoping for! =8^) So, rather than the two aspects I had outlined, there are /three/, and when I said that was only half, it was only a third. MORE challenges to work thru! As an aside, I'd often wondered at the implications of having a "multibin", similar to "multilib", and why, with all the work going into multilib, nobody seemed to be doing anything with multibin. I had wondered why having a 64-bit mplayer for most stuff, and a 32-bit mplayer, for 32-bit-only binary-only codecs, wasn't as reasonable a solution as it seemed to be for libraries. Your comments just touch on that, but it's the first time I've seen /any/ sort of comments on the subject, from anyone who'd be in a position to know the issues involved, from any of the distributions. > [1] http://dev.gentoo.org/~plasmaroo/devmanual/archs/amd64/#libdir-links > [2] > http://ramblings.hudscabin.com/blogs/index.php/2005/05/02/multilib_and_toolchain_thoughts I'll probably go over these tonight, after work. (I /did/ see and read with interest the thread on dev about modular xorg, tho I haven't gotten to the that link either, to see how it's comming along.) Thanks for the additional links to read thru! ... Anyway, /very/ glad to get this whole thing straightened out, again. I must admit, I refreshed the group this morning with a bit of trepidation. Feels good to be at peace with my world, once again! =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 -- [email protected] mailing list
