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. 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!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep