On 2008-04-07 15:31:53 -0300, tim Rowledge <[hidden email]> said:
> A key problem with funding is the sheer amount one would need to > achieve very much; if we postulate a dozen people (say 10 that do > development work, a manager/leader and an admin) you would have to > budget around $1.2M a year; increasing steadily as the USD sinks into > the mire. As Edgar said, here in Argentina (or other third world places), the same amount of work (and with the same quality) is cheaper. A short calculous with the same team description would represent a budget around 300 thousand dollars here. And that with very decent salaries (according with Argentina standards) I think is something to have in mind: soon or later we will have to do the work that no body else wants to do. Cheers, Esteban |
> A short calculous with the same team description would represent a budget
> around 300 thousand dollars here. And that with very decent salaries > (according with Argentina standards) > I think is something to have in mind: soon or later we will have to do the > work that no body else wants to do. > maybe indians ? ;-) |
In reply to this post by Stephen Pair
On 7-Apr-08, at 12:00 PM, Stephen Pair wrote:
|
Well that seems reasonable first world rates. Recall Tim and I just
came off the Sophie project where we had a budget in those figures, don't forget all the stuff that has to be done, documentation, art work, mantis, VM work, image cleanup, releases etc etc etc. Well let alone website, advertising, trade shows etc.... Today there are 4,099 entries in Mantis on Sophie, yet it's a *much* smaller scope than Squeak. So if one had *real* feature, problem, etc tracking for Squeak how big do you think the mountain would be. On Apr 7, 2008, at 12:50 PM, tim Rowledge wrote: > > On 7-Apr-08, at 12:00 PM, Stephen Pair wrote: >> On Mon, Apr 7, 2008 at 2:31 PM, tim Rowledge <[hidden email]> >> wrote: >> A key problem with funding is the sheer amount one would need to >> achieve very much; if we postulate a dozen people (say 10 that do >> development work, a manager/leader and an admin) you would have to >> budget around $1.2M a year; increasing steadily as the USD sinks >> into the mire. >> >> Are planning a mission to the moon? There are many things that >> could be accomplished with a lot less. > > What, you think I'm not worth 100K a year? > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Strange OpCodes: DNPG: Do Not Pass Go > > > -- = = = ======================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== |
On 7-Apr-08, at 1:03 PM, John M McIntosh wrote: > Well that seems reasonable first world rates. Recall Tim and I just > came off the Sophie project where we had a budget in those figures, ... and also don't forget that that level was *very* much reduced because we wanted to work on something useful as opposed to merely commercial. > > don't forget all the stuff that has to be done, documentation, art > work, mantis, VM work, image cleanup, releases etc etc etc. Well > let alone website, advertising, trade shows etc.... Exactly. Actual programming work is probably less than 20% of the real total. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Programmers do it bit by bit. |
On Apr 7, 2008, at 1:07 PM, tim Rowledge wrote: > > On 7-Apr-08, at 1:03 PM, John M McIntosh wrote: > >> Well that seems reasonable first world rates. Recall Tim and I just >> came off the Sophie project where we had a budget in those figures, > > ... and also don't forget that that level was *very* much reduced > because we wanted to work on something useful as opposed to merely > commercial. Ya, did Tim mention the source code was all released under a BSD license? http://sophieproject.org/about/license Mmm lots there, really excellent typography, cairo interface, FFI to clipboard, quicktime, etc... -- = = = ======================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== |
In reply to this post by cedreek
Not funny.
Andres. cdrick wrote: >> A short calculous with the same team description would represent a budget >> around 300 thousand dollars here. And that with very decent salaries >> (according with Argentina standards) >> I think is something to have in mind: soon or later we will have to do the >> work that no body else wants to do. >> >> > > maybe indians ? ;-) > > > |
In reply to this post by johnmci
John M McIntosh wrote:
> > On Apr 7, 2008, at 1:07 PM, tim Rowledge wrote: > >> >> On 7-Apr-08, at 1:03 PM, John M McIntosh wrote: >> >>> Well that seems reasonable first world rates. Recall Tim and I just >>> came off the Sophie project where we had a budget in those figures, >> >> ... and also don't forget that that level was *very* much reduced >> because we wanted to work on something useful as opposed to merely >> commercial. > > Ya, did Tim mention the source code was all released under a BSD > license? http://sophieproject.org/about/license > > Mmm lots there, really excellent typography, cairo interface, FFI to > clipboard, quicktime, etc... Karl |
In reply to this post by timrowledge
On Mon, Apr 7, 2008 at 3:50 PM, tim Rowledge <[hidden email]> wrote:
Heh...not exactly what I meant. I meant, you could do useful things on the scale of a few weeks and one or two people. - Stephen |
>> On Mon, Apr 7, 2008 at 2:31 PM, tim Rowledge <[hidden email]>
>> wrote: >> A key problem with funding is the sheer amount one would need to >> achieve very much; if we postulate a dozen people (say 10 that do >> development work, a manager/leader and an admin) you would have to >> budget around $1.2M a year; increasing steadily as the USD sinks >> into the mire. >> >> Are planning a mission to the moon? There are many things that >> could be accomplished with a lot less. > What, you think I'm not worth 100K a year? > > Heh...not exactly what I meant. I meant, you could do useful > things on the scale of a few weeks and one or two people. > > - Stephen You could also pay for people to work in countries where the US Dollar (assuming that is the currency of choice for raising the funds) still has some weight and get more bang for your buck. :-) l8r Sean |
In reply to this post by keith1y
When going through the Installer sequence at <http://installer.pbwiki.com/> loading into
sq3.10-7159dev08.04.1, Do this - 1. LevelPlayingField Skip this - 1. Tidy - Cosmetic tidy up Skip this - 2. Clean - Remove packages which can be loaded again Do this - 3. Packages - Install "Sake" and Package Maps for your version Do MinorFixes only - 4. Latest - MinorFixes, MajorFixes and PackageUpgrades Do MinorFixesUnstable - 5. LatestUnstable - MinorFixesUnstable, MajorFixesUnstable and PackageUpgradesUnstable While doing MinorFixesUnstable, all seems ok until " http://bugs.squeak.org/view.php?id=6890 " Installer mantis ensureFix: '0006890: PluggableListMorph is slow'. After I install 6890, the System Browser scrollbars no longer work, they extend the full length. The scroll arrows appear to work however. Ken G. Brown --- In [hidden email], Keith Hodges <keith_hodges@...> wrote: > > The way ahead for 3.10.... > > 3.10 is out and has been announced as released. I myself was > disappointed that the final 3.10 did not contain a couple of fixes that > I regarded as essential. Having come to terms with the fact that I was > never going to get the 3.10 team to see my point of view, I started LPF. > > I myself aim to use 3.10 + LPF + Clean + Latest, as the basis for the > production images that I am using. At present I am using 3.10 + LPF + > LatestUnstable. > > So I think that the way ahead for 3.10 is for the community to join in > contributing to LPF scripts designed to be run in a fresh 3.10 image so > that the combination of "3.10 + LPF + Tidy + Clean + Latest + Welcome" > will produce what we are looking for, and that can be released later as > 3.11 or 3.10.1 > > best regards > > Keith > |
In reply to this post by Karl-19
Ah the short answer is 0% dependent on Tweak to shouldn't be....
Go look at MCHttpRepository location: 'http://source.impara.de/Rome' user: '' password: '' well and no-doubt you need to pickup the Sophie-Renderer Sophie-Pages etc SophieTextDisplayObject is asked to render on renderOn: which invokes renderer renderText: self which does the hard work of drawing the bits. Well and lots more layers about this... On Apr 7, 2008, at 1:43 PM, karl wrote: > John M McIntosh wrote: >> >> On Apr 7, 2008, at 1:07 PM, tim Rowledge wrote: >> >>> >>> On 7-Apr-08, at 1:03 PM, John M McIntosh wrote: >>> >>>> Well that seems reasonable first world rates. Recall Tim and I >>>> just came off the Sophie project where we had a budget in those >>>> figures, >>> >>> ... and also don't forget that that level was *very* much reduced >>> because we wanted to work on something useful as opposed to merely >>> commercial. >> >> Ya, did Tim mention the source code was all released under a BSD >> license? http://sophieproject.org/about/license >> >> Mmm lots there, really excellent typography, cairo interface, FFI >> to clipboard, quicktime, etc... > The typography is really nice. How dependent is that on Tweak ? > > Karl > -- = = = ======================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== |
In reply to this post by Andreas Wacknitz
Andreas Wacknitz wrote:
And many of the newcomers get alienated by many aspects of Squeak:Long time lurker here, Short answer: (For those who don't want to read the post) Newcomers are turned off by seemingly irreducible complexity of the system; Squeak need continual refactoring. Long answer: My two cents as a "newcomer" to Squeak would be that all of these are real problems. Every year or so I evaluate Squeak, as well as commercial smalltalks as part of my consulting business. To give you an idea of where I'm coming from, our business helps startups identify new technologies and design platform architectures for "emerging markets". Our customers range from 2 guys in a garage to large multinational entertainment conglomerates. My typical project last about 4 months, and in the past 4 years, I've built systems using Javascript, Common Lisp, Perl, Python, PHP, Objective-C, C, C++, Java, Forth, Postscript, Ruby, Smalltalk, Ocaml, SML NJ, Lua, and Haskell. These applications have been running on everything from 100 node clusters to cellphones. I've wanted to use Squeak on several occasions but ran into trouble quickly enough to have to switch gears. This year's evaluation ran into some issues: 1.) Image stability issues (or why does my image keep curling up into fetal position and crying)
Assume for a second that I can convince a client that they don't need to worry about supporting the product, because that's the service I'm selling them. My biggest hurdle to using Squeak in a production environment isn't image management (it is easily scriptable), and it isn't version control (MC is wonderful), and it isn't the development tools (hey they're the selling point). My biggest problem isn't finding other programmers to train, or training them (I take it as a given that even experienced programmers need constant training). My biggest problem is that it is too complex, and too difficult to reduce that complexity without breaking things. When you build a project on top of Squeak, it is common practice to assume that Squeak is a layer of irreducible complexity, on top of which you are adding more complexity. Design decisions within that body of code, determine the applicability of every design decision you make about your actual application. And as soon as you are attempting to do something that is non-trivial for Squeak, you find yourself in a strange sea where dragons lurk behind every wave. Part of this problem is a historical accident, the smalltalk community in general relies heavily upon a shared cultural memory, as images beget images and layers of cruft get lost among the cobwebs. But a large part of this problem is a forgetfullness, where design decisions were made in a context, and as the context changed so too should have the design, but with the WHY lost, the change doesn't happen. Squeak needs a continuous refactoring. Odds are Alan Kay's goal of a 20k LOC system could be beaten easily by 10k if this were done. A newcomer to Squeak looks at the incomprehensible class listings and asks herself "Do I really need this particular piece of junk", looks for an answer to "Why is this here", and is frustrated because often the answer to those questions has been forgotten (or is only held in someone else's head). Upgrading feel like Russian roulette because it is difficult to know how the changes will effect the system. And experimentation with making fundamental changes is equally frustrating as doing an engine change on car running down 101 during rush hour. From this perspective and experience Craig Latta's Spoon is an easier sell than a full Squeak release. The reason is simple, its a programmer's mantra: Less Code, Fewer Bugs, Lower cost. Those are my 2 cents, lurking mode on. Dave |
In reply to this post by johnmci
John M McIntosh wrote:
> Ya, did Tim mention the source code was all released under a BSD > license? http://sophieproject.org/about/license > > Mmm lots there, really excellent typography, cairo interface, FFI to > clipboard, quicktime, etc... Which bits exactly are covered by the license? Cheers, - Andreas |
In reply to this post by David Goehrig
Working mode off.
Chatting mode on. In short, the main issue is lack of modularity. As you may know this is one of the primary concerns of current board & release team. We have to deal with this, and deal nicely. Otherwise squeak will be buried under cruft of 'irreducible complexity'. Smalltalk, by its nature does not defines a high-level abstractions which can be called 'module' or 'package'. In many other languages this concept included as basic one, while in Squeak we stick with an image-based concept, where image is a big monster with untamed complexity, where changing any piece of code could lead into breakage in unpredictable place(s), because everything is late bound. I'm aware of at least two of module-based solutions for Squeak: - Spoon by Craig Latta - Namespaces by Michael van Der Gulik , as part of his SecureSqueak project Both systems currently in development. And almost 99% it is solo development by their authors. Both systems having own pros and cons , and it's hard to decide (as for me), which is better for the future of Squeak. Why we don't see these systems already employed? Currently we have so-called 'status-quo'. I think , the main problem is more social than lack of manpower or funding: There is no high pressure from squeak community (and nobody having an ultimate power to force it) to abandon obsolete concepts, sacrifice ST-80 compatibility (partly) and move forward with system based on better design & modularity. Chatting mode off. Working mode on. -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by David Goehrig
On Apr 7, 2008, at 5:15 PM, David J. Goehrig wrote:
> When you build a project on top of Squeak, it is common practice to > assume that Squeak is a layer of irreducible complexity, on top of > which you are adding more complexity. Design decisions within that > body of code, determine the applicability of every design decision > you make about your actual application. And as soon as you are > attempting to do something that is non-trivial for Squeak, you find > yourself in a strange sea where dragons lurk behind every wave. (snip) > A newcomer to Squeak looks at the incomprehensible class listings > and asks herself "Do I really need this particular piece of junk", > looks for an answer to "Why is this here", and is frustrated > because often the answer to those questions has been forgotten (or > is only held in someone else's head). Upgrading feel like Russian > roulette because it is difficult to know how the changes will > effect the system. And experimentation with making fundamental > changes is equally frustrating as doing an engine change on car > running down 101 during rush hour. From this perspective and > experience Craig Latta's Spoon is an easier sell than a full Squeak > release. The reason is simple, its a programmer's mantra: Less > Code, Fewer Bugs, Lower cost. For what it's worth, as a long time lurker and essentially a non-user myself with a background in "traditional" languages, these two passages nearly completely nailed how I feel about Squeak and the idea of using Squeak as it exists now. I couldn't have said it better myself - and I've tried. :-) l8r Sean |
In reply to this post by Igor Stasenko
On Apr 7, 2008, at 6:19 PM, Igor Stasenko wrote:
> I think , the main problem is more social than lack of manpower or > funding: There is no high pressure from squeak community (and nobody > having an ultimate power to force it) to abandon obsolete concepts, > sacrifice ST-80 compatibility (partly) and move forward with system > based on better design & modularity. That's an interesting observation. A lot of the popular scripting languages that move forward in sudden bursts are the ones with de- facto heads of state such as Larry Wall or Guido von Rossum. These are people who are in a position to announce to the entire community that the next version is going down such-and-such path and that is simply the way it is because their language is defined by their personality, to some extent. As an outsider, I see Squeak seeming to be trying to function under an ideal democratic model where there's really no leadership at all. Unfortunately, you can't please everyone all the time and expect any changes to occur. Historically, you often need a single or small group of focused radicals in a position of power to effect change - for better or worse. The board could be that group of radicals by doing things like getting together and redefining what "Squeak" actually means. What it includes in an image. What it looks like. How you use it. They can do this by refusing any and all changes that do not further that new definition and by providing a quick path to remove code but a slow one to add it. Actions like that could cause tensions and ultimately Squeak may fork - or a new board gets elected - but maybe that's okay, too. They will have tried. The board could take the initiative and fork themselves starting a "Squeak Classic" branch and redefining what "Squeak" means now and into the future as the "main" branch without having to hurt too many people's feelings along the way. l8r Sean |
I think there is a bit of a logical problem here ins that if the
system *didn't* have 'all that junk' the immediate result would be complaints that 'it doesn't have all that useful stuff like other systems'. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim "Both.." said Pooh, as the guillotine came down |
In reply to this post by Sean Heber
>>>>> "Sean" == Sean Heber <[hidden email]> writes:
Sean> Historically, you often need a single or small group of focused radicals Sean> in a position of power to effect change - for better or worse. The Sean> board could be that group of radicals by doing things like getting Sean> together and redefining what "Squeak" actually means. What it includes Sean> in an image. What it looks like. How you use it. Oddly enough, that's my vision for the SqF board as well. And I'm on it. I believe there needs to be a clear focus, and I'll be working to ensure that the board provides the focus. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! |
In reply to this post by Andreas.Raab
Ah a license question.
Well I'm not a lawyer, however my understanding is below, I'm sure others will comment. Sophie loads onto a base 3.8.x squeak image (license for that is?) comes from I think the iSqueak repository. then we load stuff from source.impara.de/iSqueak (license?) ask impara source.impara.de/Tweak (license?) ask impara source.impara.de/freetype (license?) ask impara source.impara.de/Rome (license?) ask impara source.impara.de/Grit (license?) ask impara I also have stuff from http://www.squeaksource.com/XMLSupport.html (license?) ask Michael http://www.squeaksource.com/ToolBuilder.html (license?) For source.sophieproject.org/Sophie any category starting with Sophie- is clearly written for Sophie thus under the Sophie license. In theory all code in there should be under the Sophie license however there *could* be some contamination when you consider we modify or add to existing classes found in the base squeak and from other repositories on impara.de Say for example overrides or mod to the base URI class in Squeak, what license does that method have then? Other categories XUL not sure (ask impara) Although since it starts at XUL-be.2 in the repository I'm sure it's Sophie-License. System-ClipBoard-Extended Sophie License System-ClipBoard-Extended-Plugin Sophie License S3* Sophie License. Network-MIME Sophie License Files-Locations Sophie License These are overrides and additional code to stuff in Tweak, Squeak and EToys. Multilingual Sophie License for the overrides and additions, code base Squeak Scripting Sophie License for the overrides and additions, code base Tweak Multilingual-Display Sophie License for the overrides and additions, code base Squeak Multilingual-Scanning Sophie License for the overrides and additions, code base Squeak Network-URI Sophie License for the overrides and additions, code base Squeak Sophie-Movie Sophie License, but contains OGG code from the EToys OLPC project, (code base OLPC EToys). Any macintosh C source code I wrote for Sophie would be under the MIT license. Anyone of course relying on this should do their own audit of course. On Apr 7, 2008, at 3:25 PM, Andreas Raab wrote: > John M McIntosh wrote: >> Ya, did Tim mention the source code was all released under a BSD >> license? http://sophieproject.org/about/license >> Mmm lots there, really excellent typography, cairo interface, FFI >> to clipboard, quicktime, etc... > > Which bits exactly are covered by the license? > > Cheers, > - Andreas -- = = = ======================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== |
Free forum by Nabble | Edit this page |