On Mar 25, 2008, Rahul Sundaram <sundaram@xxxxxxxxxxxxxxxxx> wrote: > Alexandre Oliva wrote: >> But this doesn't get me a kernel I can distribute today. Or a kernel >> I can use today. Or a kernel that could go in Fedora 9. > No, it wouldn't but we need to look at this from a long term > perspective as well. If we agree to introducing a variant today, what > have you planned to merge these changes upstream? No plan, just awareness that upstream isn't interested in hearing about this, especially from people like me, and realization that I'm unsuited to make the suggested changes. > Permanently carrying a variant doesn't look like a feasible solution > to me. Why do you think so? It's not like we don't maintain a number of patches ourselves. And we're not even talking about patches. We're talking about a bunch of 'rm -f's over upstream tarballs and 'sed "/x/,/y/d"' over upstream patches. Think IcedTea. And then, if the kernel is indeed headed to moving firmware out, then it's even more like IcedTea, because we'll eventually be able to discontinue the separate package, in a similar fashion to the decision to stop shipping non-smp kernels for x86_64. But then, one way or the other, unless there's commitment from upstream to not do this, we'd have to keep on monitoring the kernel to make sure new non-Free bits don't sneak in. And that's where most of the maintenance goes. Fortunately, I got this script that checks the entire linux-libre-2.6.24 tarball for non-Free blobs in just over 10 minutes on my 3-year-old notebook. But about 45 minutes for the linux-2.6.24 tarball, that contains a bunch of nasty blobs that trigger bad behavior from the regexps I've chosen; but I do have plans to improve that, check the TODO in http://www.fsfla.org/svn/fsfla/software/linux-libre/deblob-check Most of the maintenance would be just automated checking in this regard. And then, since I have this checking built into the kernel-libre package, at the time a patch is applied, all that it really takes is scanning new kernel major releases, with the wisdom from blobs that may have appeared in -rc and -git patches. No biggie. > Easier for you as the package maintainer but the overhead is not just > for the maintainer. A new kernel variant is a big deal for a > distribution and that is the reason you are seeing the opposition to > the path you are taking. I understand that. I wish it could just be accepted as a package like any other. I don't quite see why the fact that it's an alternate kernel is such a big deal. Considering the social and political issues, I don't see that this should be decided solely from a technical standpoint. >> And then, how would I post patches upstream that remove the offending >> bits from upstream without re-distributing the very offending bits I >> find it immoral to distribute in the first place? That's why won't >> even distribute a patch from original to modified sources: it contains >> the non-Free bits in /^-/ lines. That's a line I'm not willing to >> cross. > I don't understand this logic at all. If a piece of Free software has > some non-free bits, you wouldn't do a patch to remove it? Sure, that > patch would be in a form of a diff against the non-free code but I > can't imagine why that would be considered immoral. It would not only contain the entire piece of non-Free Software, making it trivial for someone to reverse the patch to add it back (that's why I distribute xdeltas for the tarballs and patches at http://www.lsd.ic.unicamp.br/~oliva/snapshots/linux-libre/). It's also that working to make it easier for people to use these firmwares, I'm working in favor of a social problem, and against the goals of Free Software movement. > Remember, Free software development originally happened on > proprietary systems before getting incrementally replaced by Free > software bits. Exactly. That software was being used to develop its own replacement. That's the only morally-acceptable reason to accept a non-Free Software license, because it's a use that puts an end to the long-term harm. So, show me someone who's using non-Free firmware to develop a replacement Free firmware, and I'll be happy to help them. But if someone were to ask me to help people accept and use non-Free firmware, which will in turn get more people into this trap, I'd respond "Thanks, but no, thanks." -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
