On Thu, Sep 24, 2009 at 17:14, Michael Stone <[email protected]> wrote: > Dear Sugar folks, > > I have avoided wading into this discussion for some time because I wanted to > see where it went without my interference. Therefore, before I say anything > else, thanks for the entertaining show. :) > > Next, here are some thoughts for you, based on my own work, uses of Sugar, and > past conversations with other principals.
Awesome post, thanks a lot. Regards, Tomeu > Regards, > > Michael > > -------------------------------------------------------------------------------- > > Dan wrote: > >> It will affect packaging and distribution. My suggested model (as >> employed all over the open source world) is that the developers would >> release source distributions and let distributions do the packaging >> and distribution. > > My suggested model, employed all over the real open source world, is that > people write web pages (the most popular kind of open source software!), > publish them at URLs, and feed those URLs to interpreters. > > Only people with unusual quality or distribution requirements "release" or > "package" their web pages. Most people just write them and fix problems that > people yell about. > > Consequently, I want to make using activities more like web pages. That's why > I > work on rainbow and on networking design. > > NB: ZeroInstall, which was mentioned earlier in this thread by Ben, sure seems > to me like it comes from the kind of world that I want to live in, even if > Bernie isn't so sure because the "page" he tried to visit contained an broken > link. Remember, the web used to be that way too! > >> Even though a Sugar system with distro-installed packages is crippled >> (activities cannot be erased or updated through any realistic means), > > Then we should not rely on distros for dealing with activities. (They're > absolutely a great thing to build Sugar Platforms out of; they're just not so > useful for this other crazy thing we want to do. This is fine. Browsers are > also an absolutely great thing which is not right tool, today, for the > activities problem.) > >>> But we also have activity authors that don't want to go through the >>> hassle of learning git :/ >> >> This is getting completely ridiculous. So how do they manage the >> versions and releases of their packages? > > They don't. In my opinion, ideally, they click a URL and the software they > clicked runs most of the time. They don't care what version is underneath. If > they want to change it, they hit view source and edit. If they want to share > it, they share the URL, however they like. > > If they want to merge their changes with those of other people or if they want > their software to run on the computers of people with wildly different setups, > then, eventually, they learn more about the art of building portable software. > > The point is that none of version control, packaging, releases, and so on are > necessary for having fun writing software or for learning; they're just useful > for engineering. > >> Do these get put on a.sl.o? > > Probably not. Many of the people doing the work won't even have internet > access, though they will have local networks. Take Peru as a simple example. > >> If so how do we verify the source code and whether it can be >> distributed? > > We don't and we can't. But other people can and will anyway. > >> How do we verify any binary content they might include? > > We don't and we can't. But people will happily use it anyway. > >> What they do privately is their own business but if it appears on >> a.sl.o it needs to be verify able and trackable. > > Sure. Ben's point is that supporting this "personal hacking" is A PRIMARY USE > CASE. If we're not doing it, we should give up and go home. > > However, take heart: there is a DIFFERENT primary use case; namely, supporting > distro-based engineering efforts useful to deployments, which is quite > amenable > to the sort of solution you're comfortable with. > > I believe that these are compatible points of view as soon as we admit that > different mechanisms are needed for the differing use cases. What's the > problem > here? > >> There needs to be a minimum set of requirements. > > Your set of "minimum requirements" is a good set of requirements for > engineering a great distro like Fedora, but that's not the only thing we're > doing here. In particular, your "minimum requirements" violates Sugar's design > goal of "low floor, high ceiling." Them's the breaks. > >>> And even worse, we want people who are not yet able to create >>> activities from scratch to do simple modifications to existing >>> activities and redistribute them. >> >> That's fine. Its open source and it then becomes their problem but it >> shouldn't be a central issue what they want to do with modified >> activities. > > It's a central issue because, as Ben explained, supporting it is a fundamental > principle of our work. Consequently, we're allowed to solve other parts of our > problem in different ways, but not in ways that are incompatible with it. > >> The activities hosted on a.sl.o should meet a minimum >> requirement. Otherwise we get into a situation where there's no >> guarantee of the Activity whether that been the source or the >> stability of it. > > Please read Stuart Cheshire's "law of networkdynamics": > > http://www.stuartcheshire.org/rants/Networkdynamics.html > > It explains better than I ever can why we don't want such a guarantee in the > world at large. *Perhaps*, a.sl.o is the right place for that guarantee to > exist in the small. Maybe a subsection of a.sl.o would be better, just like > Ubuntu divides things up into "components": > > http://www.ubuntu.com/community/ubuntustory/components > > -------------------------------------------------------------------------------- > > Lastly, about the idea of shipping everything in Python, or Java, or > Smalltalk: > > Give up -- this works for mobile phones, not for "things to think with"! > > Programming languages are prime examples of "things to think with". We're > trying to provide people with lots of these, and with the best ones that we > can > find, remember? > _______________________________________________ > IAEP -- It's An Education Project (not a laptop project!) > [email protected] > http://lists.sugarlabs.org/listinfo/iaep > -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning _______________________________________________ Sugar-devel mailing list [email protected] http://lists.sugarlabs.org/listinfo/sugar-devel
