[IAEP] squeak/etoys accepted as free software... (was Re: Sugar on Ubuntu - Summary

Matthew Fulmer tapplek at gmail.com
Fri Nov 7 19:50:54 EST 2008


On Sat, Nov 08, 2008 at 01:32:49AM +0100, Jonas Smedegaard wrote:
> >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"... :-)

Patches can be applied to an image quite easily from the command
line:

squeak upstream.image mypatch.cs

This is also automatable from within squeak as well. The oldest
and most reliable method is the squeak update stream, which
applies a linear stream of patches to get from minor version to
minor version.

a .cs file (changeset) can run any squeak code to patch the
image in any way possible, usually by changing the loaded code.

-- 
Matthew Fulmer -- http://mtfulmer.wordpress.com/


More information about the IAEP mailing list