Re: [gentoo-dev] IBM article of interest ?
080716 Josh Saddler wrote: Philip Webb wrote: I'm not sure whether anyone among Gentoo officials cares about this, but IBM has an article http://www.ibm.com/developerworks/linux/library/l-awk1.html whose byline is very misleading may infringe on Gentoo's IP. I have submitted a comment to IBM via their form. Uh, this article really *was* written by drobbins some time ago. It's okay. It's all perfectly legal; in fact, check out http://www.gentoo.org/doc/en/articles/ Yes, it looks as if someone at IBM simply copied it from there, where it is indeed marked updated. I and some other folks GuideXMLified the original developerWorks articles and republished them on gentoo.org with permission, eg the URL you posted: http://www.gentoo.org/doc/en/articles/l-awk1.xml Yes, that's it. No need for the alarm, folks. Simmahdownah. There remains an error in the IBM page above the Gentoo doc version, ie the URL given for 'Gentoo Technologies Inc' is 'www.gentoo.org'. Whether the author still maintains GTI in New Mexico isn't clear (there's another 'GTI' in Blacksburg VA , which makes databases etc), but even if so, its Internet site is not the same as Gentoo Foundation's: this needs to be corrected by the maintainer of Gentoo docs by IBM. One would also assume that the author has a more direct e-address than the forwarding address at Gentoo still given in the article the personal details seem to be 8 years old (eg new baby): those also would better be updated or deleted. In contrast with traditional printed media -- press or advertising -- the Internet is often less precise therefore can be seriously misleading: there is a lot of out-of-date information lying around no-one to take responsibility for it. So no alarm, but cause for a couple of updates when time permits. -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] IBM article of interest ?
Philip Webb wrote: 080716 Josh Saddler wrote: Philip Webb wrote: I'm not sure whether anyone among Gentoo officials cares about this, but IBM has an article http://www.ibm.com/developerworks/linux/library/l-awk1.html whose byline is very misleading may infringe on Gentoo's IP. I have submitted a comment to IBM via their form. Uh, this article really *was* written by drobbins some time ago. It's okay. It's all perfectly legal; in fact, check out http://www.gentoo.org/doc/en/articles/ Yes, it looks as if someone at IBM simply copied it from there, where it is indeed marked updated. Perhaps you misunderstand -- the articles originally were written *for developerWorks*, not for Gentoo. That's where they first appeared 7 or 8 years ago. There remains an error in the IBM page above the Gentoo doc version, ie the URL given for 'Gentoo Technologies Inc' is 'www.gentoo.org'. Whether the author still maintains GTI in New Mexico isn't clear (there's another 'GTI' in Blacksburg VA , which makes databases etc), but even if so, its Internet site is not the same as Gentoo Foundation's: this needs to be corrected by the maintainer of Gentoo docs by IBM. One would also assume that the author has a more direct e-address than the forwarding address at Gentoo still given in the article the personal details seem to be 8 years old (eg new baby): those also would better be updated or deleted. In contrast with traditional printed media -- press or advertising -- the Internet is often less precise therefore can be seriously misleading: there is a lot of out-of-date information lying around no-one to take responsibility for it. Nothing about the article really needs to be updated, either on the Gentoo side or the IBM side. If you look through the CVS log, about the only changes we made were a few typo fixes or adding GuideXML code to stuff that wasn't so well highlighted in the original. That's it. Nothing more needs to be done -- these articles are snapshots of how things used to be. We don't need to wipe out everything that's old, do we? Why not leave the information there so people can get some history? What if people don't want more recent information shared, and don't want a new email for all to see? Seriously, nothing needs to be done on the IBM side, nor on ours. It's not an issue. There's no infringement anywhere, so please just let it go. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] IBM article of interest ?
Josh Saddler wrote: Yes, it looks as if someone at IBM simply copied it from there, where it is indeed marked updated. Perhaps you misunderstand -- the articles originally were written *for developerWorks*, not for Gentoo. That's where they first appeared 7 or 8 years ago. And that's also why Philip should thank IBM instead of pestering them :). Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] IBM article of interest ?
080717 Josh Saddler wrote: Philip Webb wrote: There remains an error in the IBM page above the Gentoo doc version, ie the URL given for 'Gentoo Technologies Inc' is 'www.gentoo.org'. Whether the author still maintains GTI in New Mexico isn't clear (there's another 'GTI' in Blacksburg VA , which makes databases etc), but even if so, its Internet site is not the same as Gentoo Foundation's: this needs to be corrected by the maintainer of Gentoo docs by IBM. One would also assume that the author has a more direct e-address than the forwarding address at Gentoo still given in the article the personal details seem to be 8 years old (eg new baby): those also would better be updated or deleted. In contrast with traditional printed media -- press or advertising -- the Internet is often less precise therefore can be seriously misleading: there is a lot of out-of-date information lying around no-one to take responsibility for it. these articles are snapshots of how things used to be. We don't need to wipe out everything that's old, do we? Why not leave the information there so people can get some history? Neither an e-mail address nor an Internet URL is some history: they are a means of contacting a person a link to a site as such they should be upto-date or deleted. What if people don't want more recent information shared and don't want a new email for all to see? In that case, as I said in my previous message, they should be deleted. Seriously, nothing needs to be done on the IBM side, nor on ours. It's not an issue. please just let it go. Well, I have much more important things to do today (smile), but you are missing the point. Any newspaper or magazine editor knows that when they reprint an article, some details may need updating or at least a clear disclaimer needs adding to warn readers that This article was first published in 2000 is reprinted as was. In the current case neither IBM nor Gentoo docs has done either. -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] IBM article of interest ?
Philip Webb wrote: Neither an e-mail address nor an Internet URL is some history: they are a means of contacting a person a link to a site as such they should be upto-date or deleted. Daniel Robbins founded Gentoo. His mail is still valid and will remain so. but you are missing the point. Any newspaper or magazine editor knows that when they reprint an article, some details may need updating or at least a clear disclaimer needs adding to warn readers that This article was first published in 2000 is reprinted as was. In the current case neither IBM nor Gentoo docs has done either. Do you happen to know of any Internet news portal that adds a note hey Philip, this article is older than two days, it might not be accurate anymore? Anyway, perhaps you should read the articles more carefully: Disclaimer : The original version of this article was first published on IBM developerWorks, and is property of Westtech Information Services. This document is an updated version of the original article, and contains various improvements made by the Gentoo Linux Documentation team. This document is not actively maintained. [1] 01 Dec 2000 Updated 03 Jul 2008 [2] *Nothing* needs changing. Better stick to the more important things. Cheers, -jkt [1] http://www.gentoo.org/doc/en/articles/l-awk1.xml [2] http://www.ibm.com/developerworks/linux/library/l-awk1.html -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
Marius Mauch wrote: The eclass also contains it's own implementation of unpack (renamed to unpack2) and src_unpack so the logic which tools/packages are used for unpacking can be maintained in a single place instead of being splitted between the package manager and the tree. Marius, these look like nice functions. A couple of questions: 1) Since it requires altering an ebuild to use these features (i.e. no automatic), what is the advantage over just including the dep the usual way? 2) The name unpack2 is intended to be temporary, right? ;) I'd guess that after this functionality is integrated into portage, there would be no need for the extra unpack func. But then we'd probably have to keep unpack2 for a long time as an alias. Any way to avoid that? 3) Same would go for the needed call for unpack_update_depend, correct? I.e. it would not be needed after portage has this functionality (and at that point, the unpack and dep code would be unified cleanly). So this function would then become a stub, correct? The only thing here is that ebuilds could linger for some time without being cleaned up. -Joe -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] IBM article of interest ?
080717 Jan Kundrát wrote: 01 Dec 2000 Updated 03 Jul 2008 [2] [2] http://www.ibm.com/developerworks/linux/library/l-awk1.html The '03 Jul 2008' has been added since I sent my comment to them yesterday ! However, the incorrect URL for Gentoo Technologies -- www.gentoo.org -- is still there, probably because I didn't mention it in my comment, so I'll try sending them another. *Nothing* needs changing. Better stick to the more important things. Yes, where professional standards peer review mean something (wry smile). -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] IBM article of interest ?
Philip Webb wrote: 080717 Jan Kundr�t wrote: 01 Dec 2000 Updated 03 Jul 2008 [2] [2] http://www.ibm.com/developerworks/linux/library/l-awk1.html The '03 Jul 2008' has been added since I sent my comment to them yesterday ! However, the incorrect URL for Gentoo Technologies -- www.gentoo.org -- is still there, probably because I didn't mention it in my comment, so I'll try sending them another. I don't know all the details or the 'proper' way to handle what you are doing. But I wanted to say thanks for spending time on this. -Jeremy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] IBM article of interest ?
080717 Jeremy Olexa wrote: Philip Webb wrote: [2] http://www.ibm.com/developerworks/linux/library/l-awk1.html '03 Jul 2008' has been added since I sent my comment to them yesterday ! However, the incorrect URL for Gentoo Technologies -- www.gentoo.org -- is still there, probably because I didn't mention it in my comment, so I'll try sending them another. I don't know all the details or the 'proper' way to handle what you are doing. But I wanted to say thanks for spending time on this. Thanks (big smile) ! It's good to have a bit of encouragement. There's really no more to say here: my initial message was about IBM I reacted as might any casual reader of their page, wondering why they were including 8-year-old information re its author. I did not remember that it was also included in Gentoo docs, but now do. It's clear to me by now that Gentoo does the correct sensible thing: reproduce the original as it was in 2000 with a prominent disclaimer. It's IBM which is not doing that needs prodding: I've sent another comment. -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
On Thu, 17 Jul 2008 07:00:32 -0500 Joe Peterson [EMAIL PROTECTED] wrote: Marius Mauch wrote: The eclass also contains it's own implementation of unpack (renamed to unpack2) and src_unpack so the logic which tools/packages are used for unpacking can be maintained in a single place instead of being splitted between the package manager and the tree. Marius, these look like nice functions. A couple of questions: 1) Since it requires altering an ebuild to use these features (i.e. no automatic), what is the advantage over just including the dep the usual way? You wouldn't have to maintain the relevant deps, e.g. when you change SRC_URI, when the unpack implementation changes (e.g. adding support for new unpackers) or keeping the conditionals in sync with SRC_URI. 2) The name unpack2 is intended to be temporary, right? ;) I'd guess that after this functionality is integrated into portage, there would be no need for the extra unpack func. But then we'd probably have to keep unpack2 for a long time as an alias. Any way to avoid that? Well, it can't be named unpack to avoid conflicts with the internal portage function. If this functionality would be added on the PM side then there would be no more need for the eclass (you wouldn't want to use both implementations at the same time), and it would be opt-in via a new EAPI, so you'd have to change the ebuilds anyway to benefit from it. So I don't see a need to have a unpack2 alias outside the eclass. 3) Same would go for the needed call for unpack_update_depend, correct? I.e. it would not be needed after portage has this functionality (and at that point, the unpack and dep code would be unified cleanly). So this function would then become a stub, correct? The only thing here is that ebuilds could linger for some time without being cleaned up. See above. Marius -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] ICC Profile
The intel C Compiler (icc) has an ebuild for gentoo and the wiki has a script to integrate it with portage. This script works will in terms of building binaries, however when mixed with gcc environments there are massive linking issues. I propose that an ICC profile is made which contains specific versions and default flags for people who want to build a mixed icc-gcc environment. ICC is much faster than GCC and although not free, offers a free non-commercial license. I would be very interested in this project and more than willing to help to the best of my abilities. I've already been trying to maintain a mixed environment with some luck, while there have been a lot of problems using dynamically linked libraries (ld from intel and ld from gcc don't always get along), my system is substatially faster. The kernel obviously will still be built under gcc as well as bash (unless intel helps submit patches to make the code work with their compiler). There are many tools icc ! has to offer for vectorization. If these were streamlined into Gentoo with a fetch restriction for ICC, a bootsrapping boot disk could be made and result in a very fast distribution. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] ICC Profile
Adam Stylinski wrote: The intel C Compiler (icc) icc, xlc, llvm, sunstudio could be interesting fields of discovery. Which are the pitfalls of using icc? lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] ICC Profile
On Fri, 18 Jul 2008 11:34:11 +0900 Luca Barbato [EMAIL PROTECTED] wrote: Adam Stylinski wrote: The intel C Compiler (icc) icc, xlc, llvm, sunstudio could be interesting fields of discovery. Which are the pitfalls of using icc? lu If I recall correctly, needing some packages compiled with ICC flags set one way, and needing others compiled with the same flag set the oter way. Can it compile a kernel yet? Rob. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] ICC Profile
There are very few pitfalls, none of which I see as real killers. These include: 1.) Closed source compiler: Yes this stands against what we believe, and yes by closing their source they're protecting the trade secrets of their architecture. It also could be more difficult to debug, although that's highly unlikely, they have the idb (intel debugger) which works very much like gdb. 2.) Linking issues: So far it's pretty versatile, but it doesn't always cooperate with gcc compiled apps. It may be a good strategy to make the troublesome apps which won't compile with ICC compile with ICC. Pro's: 1.) Bloody fast machine code. Intel obfuscates their architecture but they give back to the community as much as possible to make their hardware marketable toward the open source sysadmin, developer, etc etc. Their drivers are open and they develop for the kernel constantly. This cooperation leads me to believe that they would assist a team of developers in making 100% icc compatible code. 2.) Bloody fast compilation time. In my experience the compiler works much faster even with heavy optimization. 3.) Takes full advantage of SSE enabled hardware. SIMD instructions are quite useful, code is extremely vectorized. 4.) will project gentoo toward the power user more, helps the gentoo image, and overall will make linux a more professional operating system (and a quite competitive alternative to something like a SPARC+Solaris configuration). This would also make cluster farms and science application more respectful toward the gentoo community. The academic and research world already uses ICC to compile their apps for the sake of speed. The interprocedural optimizations for both the fortran and c/c++ compilers make it a must. 5.) It's free, albeit a commercial product. As gentoo is entirely non-profit, there is no restriction when it comes to licensing. The binaries won't be sold for the intel-compiled livecd, and the compiler itself with a fetch restriction allows the user to legally register for their free non-commercial license. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] ICC Profile
There is some record of a version of the kernel being compiled with some patches involved. It's probably possible, I'd imagine. Though, this is not necessary for the first builds. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] ICC Profile
Oh yes, and we can also take advantage of the free support that intel offers for all users: http://www.intel.com/support/performancetools/sb/CS-017156.htm Not to mention they have forums filled with intel developers/experts which we can get involved. I'm sure intel would benefit from this and be more than excited to collaborate: http://softwarecommunity.intel.com/isn/Community/en-US/forums/default.aspx -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] ICC Profile
On 14:23 Thu 17 Jul , Adam Stylinski wrote:
The intel C Compiler (icc) has an ebuild for gentoo and the wiki has a
script to integrate it with portage. This script works will in terms
of building binaries, however when mixed with gcc environments there
are massive linking issues. I propose that an ICC profile is made
which contains specific versions and default flags for people who want
to build a mixed icc-gcc environment. ICC is much faster than GCC and
although not free, offers a free non-commercial license. I would be
very interested in this project and more than willing to help to the
best of my abilities. I've already been trying to maintain a mixed
environment with some luck, while there have been a lot of problems
using dynamically linked libraries (ld from intel and ld from gcc
don't always get along), my system is substatially faster. The kernel
obviously will still be built under gcc as well as bash (unless intel
helps submit patches to make the code work with their compiler).
There are many tools icc has to offer for vectorization. If these
were streamlined into Gentoo with a fetch restriction for ICC, a
bootsrapping boot disk could be made and result in a very fast
distribution. -- gentoo-dev@lists.gentoo.org mailing list
Adam,
I've already got a mixed system that works reasonably well. I use
/etc/portage/env/ to control which packages build with icc and
icc-specific CFLAGS by having /etc/portage/env/$CATEGORY/$PN be symlinks
to /etc/portage/env/env.icc with these contents:
echo * Exporting: Intel compilers in $EBUILD_PHASE
CC=icc
CXX=icc
FC=ifort
F77=ifort
FFLAGS=-openmp -parallel -ipo -xO -O2 -no-prec-div
FCFLAGS=${FFLAGS}
export CC CXX FC F77 FFLAGS FCFLAGS
Is what you're proposing here an improvement over something like the
above setup? If so, could you explain how?
--
Thanks,
Donnie
Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
pgpRKtYUHvEJk.pgp
Description: PGP signature
Re: [gentoo-dev] ICC Profile
On 23:24 Thu 17 Jul , Adam Stylinski wrote: There are very few pitfalls, none of which I see as real killers. These include: 1.) Closed source compiler: Yes this stands against what we believe, and yes by closing their source they're protecting the trade secrets of their architecture. It also could be more difficult to debug, although that's highly unlikely, they have the idb (intel debugger) which works very much like gdb. Doesn't really matter, although we could never move to it as the default without violating our social contract. 2.) Linking issues: So far it's pretty versatile, but it doesn't always cooperate with gcc compiled apps. It may be a good strategy to make the troublesome apps which won't compile with ICC compile with ICC. Pretty sure you didn't mean ICC twice here, but sure. Pro's: 1.) Bloody fast machine code. Intel obfuscates their architecture but they give back to the community as much as possible to make their hardware marketable toward the open source sysadmin, developer, etc etc. Their drivers are open and they develop for the kernel constantly. This cooperation leads me to believe that they would assist a team of developers in making 100% icc compatible code. OK. This involves upstream projects more than us, though. 2.) Bloody fast compilation time. In my experience the compiler works much faster even with heavy optimization. 3.) Takes full advantage of SSE enabled hardware. SIMD instructions are quite useful, code is extremely vectorized. Sure, sure, speed is nice. 4.) will project gentoo toward the power user more, helps the gentoo image, and overall will make linux a more professional operating system (and a quite competitive alternative to something like a SPARC+Solaris configuration). I don't buy any parts of this argument, although the rest of your email is pretty good. This would also make cluster farms and science application more respectful toward the gentoo community. The academic and research world already uses ICC to compile their apps for the sake of speed. The interprocedural optimizations for both the fortran and c/c++ compilers make it a must. Yes, ICC is nice. And people can already use it easily within Gentoo for performance-critical apps. 5.) It's free, albeit a commercial product. As gentoo is entirely non-profit, there is no restriction when it comes to licensing. The binaries won't be sold for the intel-compiled livecd, and the compiler itself with a fetch restriction allows the user to legally register for their free non-commercial license. OK, so we can't sell icc-compiled software in our Gentoo store, so the releases would always remain built with gcc. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpyuC3bLpdh5.pgp Description: PGP signature
