[IAEP] squeak/etoys accepted as free software... (was Re: Sugar on Ubuntu - Summary
dr at jones.dk
Fri Nov 7 19:32:49 EST 2008
-----BEGIN PGP SIGNED MESSAGE-----
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
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
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
>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 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 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)
-----END PGP SIGNATURE-----
More information about the IAEP