Squeakfoundation May 2001

squeakfoundation@lists.squeakfoundation.org

29 participants
36 discussions

RE: [Squeakfoundation]Initial project - Squeak core
by Tim Rowledge 29 May '01

29 May '01

(I hope this gets through; I'm using a public library widoze machine in Poole,UK, wityh a truly awful screen, via internet exploder to the exobox exchange server. Talk about a change from my normal circumstances!) W.r.t using CVS & SF, and restricting myself to the VM code for now, I have to point out that if the VMMaker code is accepted as the tool for VM generation then the whole raft of arguments about the directory structure that plagued us last time it was tried ought to disappear. One of the key capabilities I tried to get into VMMaker was the use of a simple platform-code tree that should be easy to fit into anything like CVS. What I ended up with was a very simple tree for all the platforms (plus, most recently follwing some work wthin John McI) the 'Cross' platform for things like 'sq.h' & eventually the B3D 'faked' files. All the generated code is _only_ generated, never stored, thereby obviating a major source of confusion that cost a non-trivial amount of time at exobox. An example of the tree should be available on my webstie (don't take the actual contents as uptodate, just as a structural exemplar) at http://sumeru.stanford.edu/tim/SqFiles/deltas/platforms.sit - or something similar, just look at the directory and you'll work it out soon enough. tim

1 0

Initial projects - Web consolidation
by cg＠cdegroot.com 28 May '01

28 May '01

I think I need to go away more often - the surge in traffic is simply incredible :-) Anyway, Paul gave a nice summary of a nice chat, and we really got some stuff cooking. There are too many mails to answer, so I'll just stick with the "concrete projects" bit. To Andreas' list: first, we need to consolidate web/net presence of Squeak and make the administration process transparant, so people who want to do something can find who's in charge of a certain section. Needed: - www.squeak.org "front page". Check. - swiki.squeak.org - is there a need to move this out from the current place or can we just make the appropriate DNS change? - ftp.squeak.org - central download repository. I'll be happy to set that up. - lists.squeak.org - mailing lists. [Cc'ing to Dan as domain contact - Dan, does Gisol provide flexible enough DNS for this or does this need to go to SqF-controlled nameservers?] -- Cees de Groot http://www.cdegroot.com <cg(a)cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B

3 3

About Macs and SF
by G�ran Hultgren 28 May '01

28 May '01

Hi! SF has some good docs, for example about the mac: http://sourceforge.net/docman/display_doc.php?docid=2973&group_id=1 regards, G�ran ===== G�ran Hultgren, goran.hultgren(a)bluefish.se icq#:6136722, GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/

1 0

Re: [Squeakfoundation]Initial project - Squeak core
by danielv＠netvision.net.il 28 May '01

28 May '01

Hi Joseph, hi everyone else at StSq - I am very interested in StSq. I have what idea of the work could be gleaned passively. I understand you're in a non-expansion mode at this time, so I am loath to rush you with individual inquiries, assuming you'll release when you're comfortable. In short, I care, I'll wait, I think your work can actually solve some of the problems that trouble this forum. I would like to know if you think my proposal for Debian style updating (multiple update streams, one for each package, SUnit tests control what goes into an update stream), would be feasible given the toolset you're creating, or what else might be needed. But it's your right to choose your forums, so that's my last cross-post. Joseph Pelrine <jpelrine(a)acm.org> wrote: > Göran > > I don't think that it would be a good idea to merge this list with the > StableSqueak one. There's a lot of talk here about things that really don't > interest me (in fact, I'm probably going to unsubscribe today), written by > people who (as you can see from your answers below) have no real idea or > interest in our work. > > Just my SFR 3 (about 2 cents). > Joseph > > At 08:37 28.05.2001 , Göran" Hultgren wrote: > >Hi foundation fellows! > >

1 0

RE: [Squeakfoundation]Initial project - Squeak core
by Raab, Andreas 28 May '01

28 May '01

Göran, > > #1: Who has write access to what area? [Ian's main point] > > So... what was the problem? I mean - couldn't that have been > resolved? Most OSS projects has one or a few with write access > and everyone else just sends patches. If Ian wanted write access > to himself then I would personally gladly had given him that, > but then I would of course also... what's the word... "expected" > him to tend the sources somewhat regularly. ;-) You know what I > mean. I know what you mean :-) Incidentally, I *think* that the problem was a more psychological one. Since I don't want to second-guess Ian (anyone who's interested can ask him) let's just say that for me one of the problems was with the specific SF setup - e.g., I simply do not want any write access to anything outside the Win32 area. It's just bad. I'm sure this can be solved (although I am uncertain if that can be solved with a single SF project). > > #2: How do non-Unix people use it? [My main point] > > Could you do a short recap on what the problem was? I mean, > we are talking about the C-source right? Or are we talking > about the rest of the VM? Is it a problem with CVS-clients? We're talking clients. I installed SSH and I installed CVS and I installed some weird Win32 frontend and it was just a pain in the [insert your least favourite body part here]. And I'm not even sure if there is that much support for Macs. Of course, I've heard rumors that there's soon going to be a way of doing this stuff transparently from Squeak ... now we're talking (heh, heh ;-) Cheers, - Andreas

2 1

Re: [Squeakfoundation]Initial project - Squeak core
by Raab, Andreas 28 May '01

28 May '01

Göran, [btw, it's a shame that I have to copy umlauts to get them right ;-] > There is one that was setup for the VM I think. I believe > Stefan Rudlof did that a while ago and there was some heated > discussion about it involving Andreas Raab and Ian Piumarta > I believe - can't remember the issues though - but it sort > of didn't catch on since Andreas and Ian did not > really "support" it. (My memory may not server me right...) No, you're quite right (although one could argue that the project didn't catch on because the people involved didn't support it either - at least not in the long-term sense that is necessary). There were two issues that were never really solved: #1: Who has write access to what area? [Ian's main point] #2: How do non-Unix people use it? [My main point] Mind you, #2 really means how to use it daily. It's not done by saying "there is mumble-CVS". I know. Contrary to many other people I have tried ;-) Cheers, - Andreas

2 1

SqF purpose: supporting the Squeak community?
by Paul Fernhout 27 May '01

27 May '01

All- On reflection, as I try to reconcile Andreas Raab's perspective with my own perspective, I wonder if we are both looking at the Squeak Foundation statement of purpose through the wrong end of the telescope. That is, we are both looking inwards to discussing purposes and projects to support "Squeak the artifact" as opposed to looking outwards to purposes and projects to support "Squeak the community". The two are naturally related, but the choice of perspective might have a profound influence on how we all think about the Squeak Foundation, as well as how the Squeak Foundation carries out its operations and sets its priorities. We could switch the SqF purpose to a "community" focused one about "supporting Squeak community processes" instead of a "code" or "content" focused one about "supporting Squeak technical artifact handling". Such a shift in focus might allow the Squeak Foundation to better view and handle issues related to conflicts between pink plane (present) and blue plane (future) Squeak activities. Perhaps one of the reasons we have not been thinking this way so far is that many generous individuals in the Squeak community have on their own (or through allied institutions) already created and maintained mailing lists, Wikis, and Web servers related to Squeak. They have done this so well, and for so long, and with such enthusiasm, that we have come to take for granted the fundamental community infrastructure behind the Squeak phenomena. The social and technical infrastructure underlying the Squeak community has become invisible (except perhaps to the actual providers of it). Yet, there still remain rough edges, for example with the Wiki technical infrastructure as Simon Michael pointed out on 25 May 2001. This example shows the potential benefit of an organization dedicated to among other things ensuring reliable community services (with more resources at its disposal than that of, say, an individual at a university). This would be especially true if the Squeak community should suddenly grow immensely in response to a sudden breakthrough release or even just experience sustained exponential growth through word of mouth. How would this shift in perspective change the wording of the purpose? Here is the current purpose showing an artifact focus: : The Squeak Foundation's purpose is: : To assist in the evolution of Squeak into its ultimate expression : as an exquisite personal and collaborative computing environment : that is open, well supported, and freely available : across the great majority of modern platforms and operating systems. Here is a purpose with more of a community focus: : The Squeak Foundation's purpose is: : To support the vitality and evolution of a chaordic community : creating, maintaining, enhancing, discussing, and using : an exquisite personal and collaborative computing ecosystem : of tools, components, infrastructure, knowledge, and content : derived from or inspired by Squeak or Dynabook technology : which are open, well supported, and freely available : and make use of ever increasing computing power for humane ends. For me, this purpose passes the test of: 'If we could achieve that, my life would have meaning.' http://www.chaordic.org/what_des.html Of course, this purpose isn't exactly achievable because it is more a process of ongoing activity than a realizable goal. But that's a minor quibble, and for me it defines a direction worth striving towards. As a shorthand, one can abbreviate this entire purpose in casual conversation as: "To support the Squeak community and its computing ecosystem." However, I think the longer formal definition is needed for detailed long-range decision making, and should be part of a related non-profit's legal charter. One could think of SqF as the VM underlying the Squeak community. Note that under this new purpose, the Squeak Foundation itself might not be chaordic at first even if it supports chaordic processes in the larger Squeak community (although I think it should be nonetheless, to preserve accountability to the community). It also presumes -- I think correctly -- that what is going on already with the Squeak mailing list community and current development processes is to a large extent chaordic in the way it is self-organizing. Also note the principles discussed on the list before could remain pretty much as they are now. I added the last clause in the purpose in part related to the recent comment I made on the Squeak list about Squeak file seek primitives needing to support 64 bit offsets, given IBM's announcement of 400GB desktop drives likely in the next couple of years. Moore's law and related trends mean computers at the same cost will be about 1000x faster and bigger for the same cost in somewhat over ten years, and about 1,000,000X faster in about twenty to thirty years. Alan Kay's Dynabook concept was in part envisioned assuming this trend. Ten to twenty years is easily the lifetime of any foundation, and I think the exponential aspect of the current computer technology situation should be explicitly taken into account in our plans. I wanted to include the terms "humane ends" http://www.cogsci.princeton.edu/cgi-bin/webwn/?stage=1&word=humane http://www.context.org/ICLIB/DEFS/hsc.htm and Alan Kay's "Dynabook technology" http://dmoz.org/Computers/History/Pioneers/Kay,_Alan/ because, for me, this purpose then also takes on some aspects of Doug Englebart's Augment vision to improve humanity's ability to collaborate using computers [to solve pressing world problems] http://www.bootstrap.org/ as well as including some aspects from the Theodore Sturgeon short story "The Skills of Xanadu". I'd put Doug Englebart's "Augment" in explicitly in the purpose as in "Squeak, Dynabook, or Augment technology" if it would fly with people on this list. Augment-like technology is implicit in where the Squeak community is heading now with Nebraska. I feel the Augment collaboration ideal will only grow in prominence in Squeak as time goes by. When asked recently how the web could be made better, Alan Kay cited Doug Engelbart's 1968 Augment work, so I think there is some synergy there as Squeak moves into supplying more web services. In a way, all the concrete SqF projects Andreas Raab outlined on 25 May 2001 from faqs to web indexes are in effect collaborative Augment type projects. Kay, Engelbart, Sturgeon (and others like Vannevar Bush http://www.theatlantic.com/unbound/flashbks/computer/bushf.htm or Ted Nelson) http://www.sfc.keio.ac.jp/~ted/ all had key visions of a hopeful future using computing around the 1950s and 1960s. A missing piece of these visions was the free software (Richard Stallman) http://www.fsf.org/ or open source models (Eric Raymond). http://www.opensource.org/ Free implementations of the still relevant parts of these visions done using Squeak can help steer computing to what I feel is the better end of the possible spectrum -- as far as helping humanity survive with style the upcoming "Singularity" related to the exponential growth of computing capacity foreseen by Vernor Vinge. http://www.extropy.org/eo/articles/vi.html http://www.kurzweilai.net/meme/memelist.html?m=1 http://www.kurzweilai.net/meme/frame.html?main=/articles/art0134.html What sorts of concrete projects would fit under this purpose? Certainly all the ones Andreas listed, as well as any of the other ones mentioned so far on this list. In short, anything that would benefit the Squeak community would be possible, which would in many cases include projects directly benefiting the development of Squeak related artifacts. These projects could include: * coordinating one or more mainline Squeak releases, * strategic investments to get over hurdles hindering collaboration (whether involving handling licenses, underwriting development, or managing complexity), * rewriting a license for a version of Squeak without fonts, * negotiating with Apple for an alternate base license if desired, * serving as a single point of contact for organizations outside the community (like foundations or businesses) wishing to support the grassroots Squeak community, * creating and organizing educational materials about Squeak, * supporting talks and conferences to promote Squeak usage, * helping catalog orphaned projects and passing them onto new maintainers, * creating mini-Faqs like Andreas suggested and distributing them on a regular basis, * providing free web hosting and mailing lists related to community projects (like SourceForge but for Squeak and running on Squeak), * creating or fostering self-organizing indexes of what is out there in the Squeak ecosystem and presenting these catalogs both within and without the community, * giving SqueakC a home if Disney is ever foolish enough to let them go, and * setting up community accepted processes to "bless" versions of various Squeak artifacts as they are collaboratively developed and released. Fundraising might then commence related to supporting such projects (although many of these could be done without funds by individuals willing to volunteer time or resources as they do now). Naturally, the Squeak Foundation might then undertake to raise significant funds from a variety of sources and spend them for targeted development, integration, or testing to support certain goals for subcommunities (say business Squeakers). As long as this funding was done in the light of supporting the community (say to overcome specific hurdles holding the community back), aspects of fairness related to keeping voluntary efforts going would be considered in the funding decisions as a matter of course -- since the fundamental purpose of a chaordic organization needs to be kept uppermost in mind in planning activities. The assurance that the Squeak Foundation would always put the interests of the Squeak community foremost would address a major concern related to the potential negative effects of such funding on volunteerism. (Not to say there might not still be significant negative effects from funding, but hopefully the community benefits would outweigh them.) To summarize, a purpose oriented around supporting a "community" rather than a "code base" permits more room for managing conflicting priorities related to using Squeak for: * educating creative children, * empowering individuals to be productive and creative, * helping groups to work together to solve complex problems, * making shippable applications, * creating embedded systems, * providing commercial web application services, * implementing in-house IT solutions, * exploring the frontiers of object computing, and finally * mitigating as best as possible any negative effects of the exponential growth of computing. All in all I feel this community perspective is more sustainable in the long run for supporting the common goals that have brought us all together to the Squeak mailing list. I also think the community perspective is an easier short run sell to everyone on the list. -Paul Fernhout Kurtz-Fernhout Software ========================================================= Developers of custom software and educational simulations Creators of the Garden with Insight(TM) garden simulator http://www.kurtz-fernhout.com

1 4

About the structure SqF might create
by danielv＠netvision.net.il 27 May '01

27 May '01

Hi all, I just now read the archives (very interesting, looks like something important is starting here). This is what I imagine happening now, from everything I've heard here, and what I have been missing so far - * A few people take on the task of organizing the real squeak.org. By "the real", I mean that like SqC has mentioned, Squeak programmers are one of 3 audiences. And just like kids, or any audience, they (we) deserve a coherent view on Squeak. Handhelds.org is a good example of a site that combines a fixed part and a wiki part pretty seamlessly, and I think that's a bit like what we want to look like. This task has lots of subgoals, but at the end, a programmer should start from http://www.squeak.org and be presented with all the glory of technical Squeak, including learning resources, upto-date downloads, and links to the authoritative SqD's. * After SqSt is unveiled (and I second the proposal I believe I read about showing something even if it's status is officially "read only"), we'll all break our heads on what the release process might change into - depending on what new modularity we get. DanI made a proposal about this - if I understand it correctly, it puts SqF where SqC is now, in the sense of giving the rythm for releases. I hope we can do something more ambitious. The Debian project has a cool technology where packages get updates published on various servers, and people can query many servers at once to decide what updates they want. This is very similar to what we already have in update servers, except we have only one live stream. If we can indeed split the image into loadable packages, we could have an update stream for each package, and each with it's own rythm, the Debian way. I think one other positive influence dying to get into Squeak is the practice of SUnit tests. SqF needs a way to keep packages from stagnating or quietly drifting into incompatibility, and SUnit looks like a great tool. If we decide the stable packages must have SUnit tests, theres a role here for someone in SqF to coordinate the planning and tracking of creating tests so that we get good coverage. It can be SqF policy to check submitted code doesn't break the package it's intended for, or any packages it should play nice with. If SqF does nothing except make all Squeak technical info readily accessible from a single site, and give us a framework where various SqD's can maintain and advance the packages they're interested in without stepping on one anothers toes, I'll be utterly delighted with it. What do you think? Daniel

1 0

RE: [Squeakfoundation]Concrete SqF projects
by Raab, Andreas 26 May '01

26 May '01

Paul, > With the exception of the mini-faq, one question to think about is why > haven't these consolidation and organization projects > happened already? I think there are various reasons for this. You name complexity but my feeling about this may not even be the primary issue here. The most important issues are in my understanding: * Presence and Advocacy While I may set up a site listing all the information people would feel pretty annoyed after a while if I'd post the same information every week, saying "this piece of information is available here". If ten people start doing this you see nothing but those kinds of messages. The SqF could present that information in a single post, not only presenting the information but also give it particular weight (hey, this is coming from SqF - must be useful). * Credibility I, on my own, may be a good writer (frankly, I'm not but that's another matter) but being a good writer doesn't give you any credibility with all of us geeks. I am certain that we could find a number of people on the Squeak mailing list who are excellent in varying areas but may not have the track record in Squeak that either they or others may find necessary to consider doing the things they're really good at. The SqF can change this by approaching these people, putting its weight behind the effort, coordinating between different types of people. I for myself would certainly write a different reply to a person that is known to be the "FAQ maintainer" than I would to some random person just dropping me a note. * Lack of organizational structure I recall a sort of "package listing" for Squeak waaaayyyy back by some guy in the Netherlands (can't even recall his name - this was sometime in '97 or so). But at some point he had to drop out of Squeak business for a number of reasons and wanted to hand this over. Where could he go?! If there had been an SqF which could have decided that this effort is worth to keep up it could have tried to continue this effort. Same for me - I *really* want to hand over the WinCE stuff but where can I go?! How do we make this public (so people stop bothering me about this stuff ;-) how do we give the person taking on this task some initial credibility ("yeah, but that is not the *official* VM"). Incidentally, I know that for instance Michael has considered making some sort of package repository available. Mike, why don't you tell us why you haven't done it in the end?! With respect to complexity, I think the key issue is to understand that we're mainly talking about an organizational issue here. I disagree with your trampoline metaphor because it's just not like that for any of the tasks that I've mentioned we would need a brilliant Smalltalk programmer with at least twenty years of experience who knows the guts of the Squeak garbage collector in and out. What we *do* need are a couple of people dedicating one hour of their time per week to browsing through the messages and (for the case of an FAQ) write a couple of messages along the lines of "Hey, I've seen that question, do you think it's worthwhile to put in the FAQ?! If so, what would be a good place, a good question and the appropriate answer?" and upon response copy it into the right place. These people need a place to meet, a place where they can get help, where they can get credibility from - in short they need something like SqF, which organizes these things more effectively than Squeak Central has done. > And reiterating the comment Cees made to me about duplication > of effort (posted earlier) there is no reason we can not have > many people organizing lists, many people making lists and tools, > and many people making tools, all without much coordination. The > marketplace of the web will decide among the successes by whose > work gets used and linked to. I am uncertain how to interpret this statement. Do you mean the SqF should *not* aim at being the primary place for people to go when they have questions about Squeak?! In this case I disagree strongly. I consider a well-chosen and very visible presence of SqF on the web as crucial for success. > Tim's suggestion is the path between and does seem the best of both > worlds, and again shows why he would be a good choice for "benevolent > dictator for life". I need to say a word about this. In your recent messages you've been repeatedly advocating Tim as "dictator for life". Besides the phrase (being a German has its side effects - our last dictator wasn't such a success so I'd rather opt out of this) I don't like it because it focuses too much on one single person. It's not that I don't like Tim - we've done a couple of cool things together and I highly value his work, his personality and his sense of humor. But at this point I don't like focusing only on one single person unless there are no alternatives. So how about Cees, how about you or any other who would be willing to take the job? Please let's see the options first before focusing. [BTW, I'd personally think about one of those guys involved with Stable Squeak - they've shown that they can pull off something, that they can manage a variety of people working in different places and times. So, John, are you available?!] Cheers, - Andreas

4 7

Notes on a NYC SqF-related meeting (Cees, Paul)
by Paul Fernhout 26 May '01

26 May '01

Cees de Groot was in New York for an IBM Linux tour (mentioned previously on the list) and he and I had a chance to meet in person and talk for a couple of hours on Squeak Foundation related topics. Cees (pronounced "Case") has been involved with Linux since 1993. I was fascinated by his insights stemming from that experience related to open source community success. While he cautions that every development group is different with different needs for their particular system, there may be much in the Linux model we can learn from for use as appropriate for Squeak. Here are some (incomplete) notes from that conversation. Some of this has been discussed before on the Squeak list, but I think it will be nice to have it in one place. Cees, please correct me if I got anything substantially wrong. === squeak on a mainframe? === At the beginning we talked some about the IBM Linux tour Cees had been on, which included discussing Linux on IBM mainframes. Cees suggested that by looking at the lowermost Linux interface to the IBM zSeries, it might be possible to make a port of Squeak running more-or-less native on an IBM mainframe. Wow! For anyone interested, I just discovered this article which discusses how you can get free access to Linux on an IBM Mainframe, which might get one started: http://linuxtoday.com/news_story.php3?ltsn=2001-05-23-002-20-PS === bless you :-) === Linux divides roughly into kernel, libraries, and configurations. A benevolent dictator "blesses" kernel releases at some point. Others can create and maintain specific libraries and packages they are interested in, and bless those (with ones being close to the kernel perhaps requiring delegated authority from the benevolent dictator). Then, special interests can create their own configurations by choosing from versions of the kernel and libraries/packages to meet specific needs (business, research, gaming, embedded, etc.) and bless those configurations (like, say, RedHat does). Putting this in a Squeak framework, we might have a VM blessed by, say, Tim Rowlege (as benevolent dictator for life), various base classes or applications handled by others interested in them (some key ones delegated by Tim), and then configuration maps (maybe like ENVY) maintained by the business Squeak interests, the research Squeak interests, the embedded interests, the PDA interests, the protoype-based Squeak interests, the education interests, and so on. We discussed ENVY some, and my hypothesis that the people who like ENVY used it without security turned on, and the people who hate ENVY used it with security enabled. The Linux process involves development, testing, and then "blessing" by a recognized authority (possibly a benevolent dictator). If the blessed code has problems, the authorities status and credibility declines (perhaps eventually to the point where such blessing means nothing). If the blessed code is solid, the authorities credibility is maintained or increases. What is going on here is in part using somewhat informal social processes to create some sort of engineering discipline. The blessing process creates confidence. Cees pointed to some examples where code still existed and might be developed, but without and active "blessing" authority, the code was not picked up. (Unfortunately, this has happened with some private Squeak code or small projects developed in various ways which never get "blessed"). Obviously, the current authority for "blessing" Squeak code is SqueakC. So, it might make sense for SqueakC to "bless" an image for the Squeak Foundation to use as a starting point, passing on some of the flame as it were. === even and odd === In Linux, odd numbered releases are experimental, even numbered releases are supposed to be stable. Almost anything can be added to an odd numbered release for the first 70% or so of its time span. After that point, the release becomes more conservative. Even numbered releases get primarily only bug fixes (and occasionally backports of new features, but this is controversial because of testing and stability issues). The idea is that even numbered releases have a high friction for changes; odd numbered releases for most of the time have low resistance to change (although in the last 30% of the process they will start removing unstable features). === marketing to IT decision makers === An important aspect of the Squeak foundation should be marketing Squeak. Cees gave me a copy of LinuxUser magazine: http://www.linuxuser.co.uk What is interesting about this is that unlike your typical linux magazine designed to be fun to read for techies, this magazine is designed to be for managers (IT decision makers). So, it focuses on how Linux is being used, how it will save money, what options are available. For example, on the cover there is a picture of a burning five pounds note with the text "Money to burn? Can you afford not to deploy Linux?" It would nice to see someday: "Money to burn? Can you afford not to have your programmers work in Squeak?" === participants & infrastructure === We talked at length about group process related issues. These included some issues already in the "Restless" and other threads. The chaordic process can be a difficult one, but we feel we are making progress by having a purpose and the start of some principles. We still need to address participants, such as for example if groups like Cincom will participate, and if they will donate technology (like StORE, which Cees likes). We talked briefly about what might be sensible relationships between a Squeak Foundation and Smalltalk vendors (such as growing the pie, AIX vs. Linux in 1993 vs. now, upgrade paths, etc.). [Naturally, I tried to plug the Pointrel Data Repository System for Squeak http://sourceforge.net/projects/pointrel/ as potentially filling the StORE niche, although admittedly that code is not yet tested enough to be given a high level of confidence, and it also is limited by Squeak's ability to truncate files (and perhaps reliably flush/sync). I also raised the issue of peer-to-peer Squeak distribution of the codebase in addition to relying on a server.] Cees said Squeak CVS has worked well for him. SourceForge (which implies CVS right now) could be strongly considered as an initial starting point for Squeak Foundation activity support because it is there, it is free, and it has some credibility. It might make sense to have several projects on SourceForge related to different interests -- and they might even have different licenses depending on the participants in the various projects. The fact that the image cannot be built from scratch from text files (yet) is a difficulty in the SourceForge/CVS direction, although it can be worked around somewhat by checking in binary files. Personally, I would rate building the image from text as a very high priority for complexity management. Cees pointed out that the much of the Linux community has a certain expectation for how to, in a few shell commands, download a current released set of files from CVS, build it, and then run it. There would be great value in terms of leveraging the Linux community expertise if the VM (and image) building process following that model. === thinking about things Java may do right and wrong === An interesting thing to think about is the Java model in the sense that Java scales from a MicroEdition for embedded devices to an Enterprise Edition, each managed more or less by distinct groups, but presumably there is some common VM code in there. We chatted some about Alan Kay's comment on the difference between standards as specifications (e.g. Java) and standards as open-source implementations (e.g. CPython). === education and business motivations === We also discussed Alan Kay's comment that doing stuff to make kid's use of computers better is an easy sell, compared to doing stuff to make adult's computer experience easier, since adults are trained by school and on-the-job to "keep a stiff upper lip" and accept distress and discomfort, but it would be a rare person to say children's software should be allowed to cause kids stress or discomfort. Cees is interested in Squeak from two very different perspectives (which I think have been mentioned before on the list). One is for use in business related to web hosting (where he currently uses Python). The other is as a parent wanting educational toys and tools for children. This creates both business and charitable considerations for involvement in Squeak. The two motivations, which each by itself may not always be enough, can together sometimes produce some synergy leading to action. This might be something to consider further from a Squeak marketing point of view. === the Squeak ecosystem === We discussed how the metaphor of the "Squeak ecosystem" as a set of related projects and modules of multiple versions is a powerful one. We both think it makes sense for the Squeak Foundation membership to work in terms of strengthening this ecosystem of components, however they are put together by the end user. For one example, we discussed briefly the possibility of decoupling the VM's lowest platform specific layer from a Smalltalk specific approach to make a cross-platform base which could be available to other languages (either through a VM or as just straight C calls). While such a refactoring doesn't support Squeak Smalltalk directly, it might indirectly expand the entire Squeak ecosystem -- if Python or Perl or C/C++ developers were to use it and then help maintain it for their own purposes. For another example, relying on a configuration map to select a variety of compatible component versions out of the larger ecosystem helps pink plane and blue plane interest groups to more easily coexist (since they just maintain different configuration files). It might be nice at some point in the future to revisit the purpose statement with the ecosystem metaphor in mind (although not now as we don't want to slow things down). This ecosystem metaphor was one reason behind Cees picking the NAMA principles (related to enhancing a natural ecosystem) as a place to start from. == conclusion === All in all, it was a pleasure and a great learning experience for me. -Paul Fernhout Kurtz-Fernhout Software ========================================================= Developers of custom software and educational simulations Creators of the Garden with Insight(TM) garden simulator http://www.kurtz-fernhout.com

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Squeakfoundation May 2001