Maxim Kammerer: > On Fri, Feb 22, 2013 at 6:58 PM, intrigeri <intrig...@boum.org> wrote: >> The remaining part of the problem will be solved by adding UEFI >> support [3] to Tails. We're currently making plans with Debian Live >> upstream so that this support is added there, and benefits all Debian >> Live systems. >> >> [3] https://tails.boum.org/todo/UEFI/ > > Don't you already regret basing Tails off a binary distro like Debian? > I mean, updating TODO lists once in a while and making “plans” sounds > fun and all, but not only are you completely dependent on an upstream > distro's features implementation cycle — you are missing the > opportunity to learn new things while implementing those features > yourself. I mean, Liberté was the first Linux distro to ship with a > UEFI Secure Boot-based trusted boot chain — do you think you will ever > be able to say something of the sort about Tails? Open Source > development is supposed to be exciting, not this… bureaucracy. >
As maintainer of Whonix, I also like this join this discussion. First of all, don't get this wrong. I still believe Debian was and still is the best choice from all possibilities. I must say, I am sometimes also disappointed by Debian bureaucracy. Two examples... 1) Tor Browser It can't make it's way into Debian due to "no code duplication policy". I couldn't agree less. This "no code duplication" may have been useful when when disk space was expensive 20 years ago or so. By blocking this due to politics, they increasing workload in a lot projects based on Debian. (#1 Tails specific Tor Browser patches, #2 Whonix Tor Browser download, #3 torbrowser-launcher) The answer for such cases is "merge your patches upstream" - yes, but if upstream isn't interested? Creating the patches in a way, that they won't duplicate code, is like "10 times" more effort - and might break if upstream changes something. Creating the patches is something the Tor Project with full time employees managed, but creating them in a way that upstream accepts them in a "if this mode"-approach is much more difficult. And their review process takes so long, that it can never be done. With this "no code duplication policy", Tor Browser, no matter how many users it will have, will never find it's way into Debian. (Unless, Mozilla somehow just starts to care.) 2) The MATE Desktop GNOME developers failed to make their users happy when they changed from GNOME 2 to GNOME 3. Many people prefer GNOME 2. Others created the MATE Desktop. It's a fine fork of GNOME 2. They where willing to offer Debian packages, actually they offer them in their own repository already. They just got them into a state, that many people like it. They didn't make their way into Debian, also because of the "no code duplication policy". There are other applications, which didn't make into Debian repository, because of that policy... In conclusion... I think the correct question to ask isn't "does it duplicate code?", but "won't it break something?", "is it well maintained?", "is upstream generally ready? (not too many bugs)". Having a policy is a fine thing. But after some time it should be re-checked if the original reasons for that policy still apply and if that policy is still worth to be enforced or if it does more damage than anything else. Sometimes it's better to start fresh. For example, Ubuntu started fresh and attracted more users than Debian. Or Chrome started fresh and attracted more users than Firefox. That goes for may projects. When they start, they are great, but overtime their own policy slows them down. _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
