Re: Reproducible, precompiled .o files: what say policy+gpl?
On Tue, Oct 19, 2004 at 04:59:37PM -0700, Josh Triplett wrote:
> > True enough, but as processors get faster, so does bandwidth.
> > I expect that ultimately, it will always need to be as fast as possible.
>
> Possibly; however, I think bandwidth grows far slower than CPU speed and
> overall system power. I do understand your concern, though.
According to a course taught by my supervisor, processor speed quadruples
every three years, as does link bandwidth. See
http://www.dvs1.informatik.tu-darmstadt.de/lectures/ws/db2/slides/db2-folien4x1.pdf
pages 7-9. I intend to find out his source for these slides b/c this is very
important to know.
Unfortunately, also according to those slides, installed bandwidth doubles
every 9 months. In other words, the actual bandwidth people see increases
2* faster than processors. So, if anything, I need to make my program even
faster in the coming years (until installation matches technology).
Then, of course, there's the whole scare about this 'leakage' issue that has
'halted Moore's law'. Certainly there has been quite a dip in processors
compared to projections from Moore's law lately... We'll see. However,
FFT/FGTs are perfectly parallelizable, so multiple cores are as good as a
clock speed increase.
Anyways, I would hardly take it for granted that processors grow faster.
Fortunately, I believe that bandwidth speeds depend on DSP speesd which
depends on processors. So, probably if processors slow then bandwidth will
also.
> > gcc-3.3 is not an issue; it ICEs.
> > gcc-3.4.2 is the version I was referring to.
>
> 1) Have you submitted a bug report on 3.3?
Why? They already fixed it in 3.4.
> 2) Have you tried 3.5? A great deal of work has gone into making 3.5
> far better at generating optimized code, particularly with vectorization
> and advanced instruction sets; much of this came about due to the
> merging of the tree-ssa branch. I don't know that it would be 2x
> faster, but I wouldn't be surprised if it was quite measurably faster.
I have not. I will do so, but now that I (last night) ironed out the last
bugs I need to do some quick measurements and writing to get this paper
done. I will let you know how gcc 3.5 works out afterwards though (probably
three weeks).
> > (PS. rsgt is not the final name)
> Heh; naming is tricky but fun. What does "rsgt" stand for?
Reed-Solomon Galois Transform -- the two important technologies I combine.
Since it means nothing to the people who would use it, it's bad.
> > For it to sit in contrib, would I have to include the source code in
> > contrib as well? Or would the fact that the source code was in main
> > already satisfy the GPL requirement of source availability?
>
> Packages in contrib must still be Free Software, which means they must
> have source available. I think this is a Policy problem, though I could
> be wrong. The only thing packages in contrib can do that packages in
> main can't is declare a Depends:, Build-Depends:, or Recommends:
> relationship with a non-main package; they must still follow Policy, and
> they must still be Free Software. I don't know that it is acceptable
> for the source to be in a separate source package.
Sounds like it's probably not. I will include it twice then.
> You should also talk with the Debian OpenOffice.org team about this;
> they were in discussion about how to provide the contrib
> openoffice.org-java package (built with a non-free JDK) without needing
> a separate (huge) source package in contrib.
My program is _much_ smaller than OO.
So, I expect if they were split at all on the issue, it means that a
package which is so much smaller should have source in both.
> As for the GPL issue, this is a difficult question: on the one hand, CD
> vendors and other distributors include contrib and non-free software at
> their own risk; on the other hand, the idea of the source package being
> available only in main is difficult. You would certainly be complying
> with the spirit of the GPL, but I don't know if you would be complying
> with the letter. GPL clause 3 is the relevant section; of that, Debian
> always ignores the "offer" option in GPL 3b and 3c, because 3b requires
> that the offer be "valid for at least three years" which Debian cannot
> guarantee, and 3c is only valid for non-commercial distribution. So
> looking at the rest of GPL clause 3:
>
> > 3. You may copy and distribute the Program (or a work based on it,
> > under Section 2) in object code or executable form under the terms of
> > Sections 1 and 2 above provided that you also do one of the following:
> >
> > a) Accompany it with the complete corresponding machine-readable
> > source code, which must be distributed under the terms of Sections
> > 1 and 2 above on a medium customarily used for software interchange; or,
> [snip 3b and 3c]
> [snip OS exception]
> >
> > If distribution of executable or object code is made by offering
> > access to copy from a designated place, then offering equivalent
> > access to copy the source code from the same place counts as
> > distribution of the source code, even though third parties are not
> > compelled to copy the source along with the object code.
>
> So the question is whether a source package in main "accompanies" a
> binary package in contrib, and/or whether "equivalent access" is
> offered. This is certainly questionable. It would also depend on
> mirroring; for example, if contrib were ever moved to a different server
> (which has been debated in the past), this would become clearly false.
>
> My advice would be this: unless the source is incredibly huge (such as
> with OO.o), then I don't think saving a few tens of MB is worth dealing
> with the questions and complexities this raises.
That's my conclusion too.
Thanks again!
--
Wesley W. Terpstra
Reply to: