Date: Thu, 18 Mar 2004 22:58:33 -0600 (CST) From: "Paul Seniura" <pdseniura@techie.com> To: "Brooks Davis" <brooks@one-eyed-alien.net> Cc: freebsd-ports@freebsd.org Subject: Re: I believe lang/icc* are not open-source nor 'free', right? Message-ID: <20040319045833.ED0D811E771@scifi.homeip.net> In-Reply-To: <20040319020843.GA14259@Odin.AC.HMC.Edu> References: <200403122136.i2CLaCm9096276@repoman.freebsd.org> <20040318213442.D38635C35@techpc04.okladot.state.ok.us> <p0602043abc7fca5da6c6@[128.113.24.47]> <20040319015159.0B9C011E734@scifi.homeip.net> <20040319020843.GA14259@Odin.AC.HMC.Edu>
next in thread | previous in thread | raw e-mail | index | archive | help
>On Thu, Mar 18, 2004 at 07:51:59PM -0600, Paul Seniura wrote: >> >> The discussions on cvs-src list were almost making me >> panic, so I had to say something quick from another >> perspective. My previous msg has header lines pointing to >> the beginning of that thread, starting with the commits to >> allow building kernel with icc. Seems the other >> respondents here haven't taken time to read them to >> understand where I'm coming from. They are/were actually >> considering publicly distributing kernels built with icc -- >> something we are not privvy to use, as I understand the >> license, and so must be clearly marked. > Then Brooks Davis wrote: >I believe you seriously misunderstand the license. Anyone who holds a >commercial license may produce binaries that may be used in any way >they wish. Thus if the FreeBSD project used its commercial license >for icc to produce kernel snapshots or ports or whatever, those products >may be redistribued and used by anyone. Well, firstly the cvs-src@ discussion had mentioned having a NON-commercial FREE license granted by Intel after having asked them, pointedly, for the sake of the o.s. as a project. And later it was an UNlimited license mentioned. It's clear now that was for distributing what icc puts out and only that. It's not a license so I can have and use icc at work in a legal way (at home here I have OSX+XCode on G4, and I'd say even icc has some work cut out for it ;) . And someone on cvs-src@ actually said "icc is free". See it for yourself here: <http://docs.freebsd.org/cgi/getmsg.cgi?fetch=984937+0+current/cvs-src>; Someone should correct that line "icc is free". Because it isn't. I am now corrected. Thank you. I'm still at square one, tho. It still doesn't help anything I'm doing, from my perspective as a system programmer. Clearly I'm not going to be allowed to use FBSD's keycode to use icc anywhere, it's not that kind of unlimited license. But there's another angle sort-of mentioned in the URL above. I'm sure this kind of thing has been discussed countless times. It'll do my mental state some good to spout it off anyway. ;) Just about all of icc is designed to tweak IA32+s, right? So to show off the speed of FreeBSD, let's say re@ builds CD ISOs with icc tweaked for P3+s, and later the public pkgs are built with icc similarly tweaked, then perhaps a two-tier downloadable library ensues. Right now, 'Free'BSD is created and maintained with 'free' and open-source tools. Using icc, it becomes a conglomeration of mixed licensed materials -- we cannot say to the world that 'Free'BSD was built in that manner. Let users recompile with icc as their choice, but do not publish CDs or publicly available pkgs with icc, else the non-profit org might be liable for falsely describing the products. ...so much for that idea... Closer to home, I have another problem with icc-built modules: Much of our state govmt agency's machines probably cannot run them: we have older P3s "or less" -- and no money to upgrade, so the politicians here say. To steer around ACPI and other problems that won't be fixed by IBM & Intel & Compaq & Delll etc. due to the hardware's age, and for other reasons, we will need to build custom kernels. On top of that, the pkgs (prebuilt binary 'ready to run' is how I explain it to the locals) often enough don't have the knobs (compiled-in features) we'd like to have enabled. What's more, sometimes the publicly available pkgs as they stand today don't work on the Puny Pentium2 I and others are forced to use. Not until after I have recompiled them with CPUTYPE=p2 and turning OFF the knobs for SSE "and higher" functions did the o.s. and ports start acting predictably. (Yes my upper-eschelons know about it but have their hands tied -- no money for upgrading <sigh>.) In fact now I am seeing the same bugs as others see while following CTM src-cur and ports-cur, which lets me relax somewhat and keep more of my hair. ;) Yes recompiling with the 'dumber' tweaks really did make that kind of difference. Today/currently I am experimenting with -O2 (mentioned the other day on another list) -- but the public pkgs and GENERIC don't have that setting, for the most part. OTOH, allowing mplayer to use its original author's -O3 setting made a *huge* difference For The Better on the Puny Pentium2 -- it's actually usable now. Same goes for KDE and its millions of modules with -O2. But what about the public pkgs. Because of these -O tests on 'dumber' Ps, I have been on record on this list for wanting FBSD maintainers to stop editting the CFLAGS from the original author's settings. They likely have tested it with gcc on i386, we use gcc on i386, so the original settings ought to stay put. OTOH with icc, _more_ logic might need to be added to the FBSD Makefiles, because the original authors probably will not have tested their apps with icc. Oy vey. There used to be a requirement that libs & apps had to be compiled similarly. There were a bunch of 'gotchyas' with the interplay of different compilers or even different levels of the same(-flavored) compiler (gcc32, gcc33) or even different options of the same compiler used for different modules that had to call each other (or something like that ;) . After all this, the msg at the above URL totally agrees with me in that "we" will not be able to experience any of the benefits allocated to icc or other such "closed" tools. Bottom line: the net/tn3270 port I am trying to fix (I volunteered to be its maintainer, look at its Makefile) can only be tested with the tools I am allowed to use. I use gcc33 with p2 & dumber tweaks at work and I use Apple's gcc33/XCode usually with -mcpu=7450 at home. I do intend on making sure these two platforms (lil & big endians) can use this emulator, and other platforms should then be covered. Having to add _more_ #ifdefs on behalf of _more_ different _compilers_ is out of my hands. I cannot show TPTB at work "the best of breed". I have to show them how things look & act on a Puny Pentium2 (with items I've bought, to boot, so FBSD would at least support them). IMO it'd be better time spent in getting gcc up to par. ;) And the GNU teams ought to look at the diffs coming from Apple & IBM (G4/G5) and OpenDarwin on i386, and others, to get gcc in _really_ good shape for _all_ platforms. (I'm sure the GNU ppl are swamped, it'll take time.) Keep our tools free & open, and updatable/fixable by our own hands, quicker, easier, better... There... my mental state is all better now... -- thx, Paul Seniura.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040319045833.ED0D811E771>