-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Nov 07, 2008 at 02:56:44PM -0800, Alan Kay wrote: >Sure, I completely agree. And now is a chance to apply the idea that >via the Internet "the whole world" is the pool of resources for making >and taking care of open and free software.
In a sense I believe that is happening already today: When end-users experience one system (or distribution) as unreliable and switch t another, they implicitly "vote" for that oyher system, and "advertise" it through their social network. >Seems as though no simple group can handle the scaling implied by >having the whole world supply software, even if only one approach is >used. And currently several groups work together: Upstream authors of software do their own balancing beteen quality checks and adding new features. Distributors may have different balancing, or might sometimes patch in features not yet (and maybe never) accepted by the original authors. End-users are free to grab directly from upstream or use any of the many distributors. When Debian, arguably the largest and most flexible FLOSS software distributor, decides to not distribute Squeak, it is not a signal that Squeak is bad or inferior. It is a signal that Squeak and Debian do not fit together. Either we leave it at that (Debian and MS Excel also do not fit together), or we adjust one or both of them if we see enough benefit for them fitting together. Just because Debian is large does not mean the whole FLOSS community ought to obey whatever Debian decides as their playground (including DFSG). It is opposite: Debian is big _because_ a lot of software happens to fit (or can be convinced to adjust to fit) the DSFG, and a lot of volunteers find it interesting to do the work. Work that at least in the past was often duplication of work already done for Redhat. Seems to me it scales well. :-) >As Jecel pointed out, it is highly unlikely that any distribution group >is really looking at any appreciable fraction of the lines of code they >are distributing, nor could any such group really handle most bugs >(whether dealing with security issues or not). This is in part because >most software systems have real problems even being written and >debugged (even understood) by their inventors and programmers. >Distributors of such software are going to have even more problems >understanding and fixing, if they try. Distributors are sometimes able to spot flaws missed upstream, because they are looking from a different angle: Instead of actually understanding in detail each code piece, they do pattern recognition. In 20.000+ software packages built on 10+ hardware architectures, some patterns emerge about classic typos or misconceptions - about the hardware, about the location of libraries, about use cases, about tmpfile handling, whatever. Many upstream developers deal with each of these issues once, and might not be the most clever guys at all parts of their own code. Distributors can help pass on knowledge between upstreams, through pattern recognition. Personally, I experienced this recently while initially packaging a large Perl-based project, and also engaging with upstream in design decisions (like how to split code into modules, when to do a release, and stuff like that). I consider myself a lousy programmer - I can stitch together code made by others, but can only very slowly and clumsily write code on my own from scratch. Still we found that my insight from packaging 50+ packages for Debian already, some of them Perl-based, some of them completely different, that my ability to recognize patterns in the code - in the directory tree structure, in the versioning, the naming, the documentation style, the communication style, and a bunch of other stuff - was valuable for the project and noticable helped improve it. I even discovered a few bugs (to my own surprise). :-) >Part of the honest worry about these issues comes from very good >reasons not to just trust everyone. But it also seems that e.g. Debian >needs to widen its circle of trust to include experts in wider >varieties of programming. There are plenty of trustworthy Smalltalkers >and Squeakers, and there is absolutely no reason that some should not >be on call to deal with perceived problems. Depending on interpretation, I think we all agree on that. Including the Debian ftpmasters. Debian in reality trusts all upstreams. And ideally discuss any changes, including security fixes, with upstream authors. At the same time, Debian in theory trusts no upstreams: Each Debian package maintainer is expected to understand the maintained package(s) well enough to ensure that the code is reliable. Yes, it is often an impossible task. But still a sane goal, as long as not blindly assumed working in reality. If you mean that Debian ought to trust upstream to fix bugs and take care of security issues _instead_ of its own package maintainers, then I disagree: I believe *both* upstream and the distribution-specific routines should be applied in parallel. Some bugs and flaws can even be caused by the context of the distribution, so impossible for upstream to spot. An obvious example is a makefile generating a private key for strong encryption, and the packaging routines then distributing same pre-compiled private key to all systems worldwide. In theory upstream authors should have distinguished the "configure", "build" and "install" phases, but reality is much more complex. There are many more ways than even using makefiles. As you would know - snapshotting your live "world" and distributing that as "source"... :-) >Very best wishes, And same to you. Nice discussion! - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkU3jEACgkQn7DbMsAkQLjnngCeOPFI+qHq/tKe2skMPWSVn+aF Q34An0IIx7eJFFBJ5ZMj0FsGv1vwJlzW =FfXo -----END PGP SIGNATURE----- _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
