Smalltalk Web Host Opens

Smalltalk Web Host Opens

The World's First Commercial Smalltalk Web Host:
 
    - 60,000 word learners blog with screenshots and Hello World
    - choose your own domain name unlike http://www.seasidehosting.st
    - better server uptime than http://www.squeak.org
    - email support 9-5 M-F Eastern Standard Time
    - host a regular site (Perl/PHP) and incorporate as much Smalltalk as
you like
    - $29.99 CAD per month

http://www.seasideparasol.com


"Possibly, it wasn't simply arrogance, though the PARC researchers did see
themselves as the Davids who were busy slaying the Goliath of corporate
time-sharing computing. It was, rather, something deeper, something that was
probably just a function of human nature. It was a pattern that had already
been repeated a number of times in computing history and would ultimately be
repeated many more times. Even with a strong intellectual grasp of the
consequences of Moore's Law, it has proven almost impossible for the members
of any given generation of computing technology to accept the fact that it
will be cannibalized by an upcoming generation. Many of the PARC researchers
were aware of the computing hobbyist movement, but because the tiny little
machines could hardly do anything they were easy to ignore or dismiss as
toys. Later, Alan Kay took pleasure in poking fun at the Homebrewers by
saying that the hobbyists actually enjoyed their machines more when they
were broken, because then they could actually do something with them."

John Markoff   "What The Dormouse Said", (2005), page 251

Chris Cunnington
Toronto

At 09:17 AM 12/11/2006, Chris Cunnington wrote:

"Possibly, it wasn't simply arrogance, though the PARC researchers did see
themselves as the Davids who were busy slaying the Goliath of corporate
time-sharing computing. It was, rather, something deeper, something that was
probably just a function of human nature. It was a pattern that had already
been repeated a number of times in computing history and would ultimately be
repeated many more times. Even with a strong intellectual grasp of the
consequences of Moore's Law, it has proven almost impossible for the members
of any given generation of computing technology to accept the fact that it
will be cannibalized by an upcoming generation. Many of the PARC researchers
were aware of the computing hobbyist movement, but because the tiny little
machines could hardly do anything they were easy to ignore or dismiss as
toys. Later, Alan Kay took pleasure in poking fun at the Homebrewers by
saying that the hobbyists actually enjoyed their machines more when they
were broken, because then they could actually do something with them."

John Markoff   "What The Dormouse Said", (2005), page 251

I don't think it was arrogance (I hope not). What was done at PARC used Moore's Law to justify going all out for what was really going to happen. The 8-bit micros were not strong enough in any dimension except cost in the 70s for "inventing the future". This is why e.g. the last few decades looks very much like PARC (bit-mapped screen, overlapping window GUI, mouse, Ethernet, Laserprinters, Internet, object-oriented programming, etc.) , and not like 8-bit micros.

The hobbyists were partly a wave of pop-culture desire for participation in what they correctly sensed was something that was going to be big and central. As with many things in pop-cultures, they wanted to do something now, whereas the PARC cum ARPA cultures wanted to work on what was really going to happen (especially if it could be invented early enough). The development of the Internet vs. the tinkering approach that was taken with the web (that ignored Engelbart, etc.) is a parallel story.

There's nothing wrong with tinkering if the limited results are allowed to grow in powerful ways (or can be discarded when not good enough). But if the results set bad too-early defacto standards (as so many of these have over the last 25 years) then they start to create a huge barrier to real progress (as indeed we have today).

Cheers,

Alan

>     - choose your own domain name unlike http://www.seasidehosting.st

Since you directly compare it I have to correct you: Choosing your own
domain name has always been possible on seasidehosting.st (see for
example http://swiki.gsug.org/), you just had to ask us to tweak the
model as there was no user-interface. I quickly threw in a few
Magritte descriptions and now everybody can define an additional
host-alias to his account from the user-interface. For free of course.

Have fun,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

2006/12/11, Lukas Renggli <[hidden email]>:
> >     - choose your own domain name unlike http://www.seasidehosting.st
>
> Since you directly compare it I have to correct you: Choosing your own
> domain name has always been possible on seasidehosting.st (see for
> example http://swiki.gsug.org/), you just had to ask us to tweak the
> model as there was no user-interface. I quickly threw in a few
> Magritte descriptions and now everybody can define an additional
> host-alias to his account from the user-interface. For free of course.

And 256 MB of RAM, not 32 ;)

Cheers
Philippe

Philippe Marschall wrote:
> And 256 MB of RAM, not 32 ;)

There seem to be over 200 sites listed on
seasidehosting.st. So:

200 * 256MB is 50GB of RAM.

I don't know what virtual hosting mechanism
underlies the two sites, but I think there
is an "apples to oranges" comparision here.

Anyways, the main difference is that one is
an ESUG/netstyle.ch funded public service
meant to promote Seaside/Squeak/Smalltalk.
Whereas, this new offering is targeted toward
commericial use - something that is not allowed
on seasidehosting.

IMHO, the addition of seasideparasol.com should
be seen, not as a competitor, but as the *success*
of seasidehosting.st in promoting Seaside.

2006/12/12, Yanni Chiu <[hidden email]>:
> Philippe Marschall wrote:
> > And 256 MB of RAM, not 32 ;)
>
> There seem to be over 200 sites listed on
> seasidehosting.st. So:
>
> 200 * 256MB is 50GB of RAM.

http://lists.squeakfoundation.org/pipermail/seaside/2006-February/006884.html

> I don't know what virtual hosting mechanism
> underlies the two sites, but I think there
> is an "apples to oranges" comparision here.

That has been discussed on the seaside mailinglist too. It uses a
technique similar to DabbleDB.
Honestly I don't see how you get anywhere with 32 MB and Squeak/Seaside.

Philippe

Hi,

As an ESUG board member, I'm happy to see that our initiative with  
netstyle.ch had inspired others.
I hope we'll have even more Smalltalk web hosting providers.

Go Smalltalk, Go Squeak!
Noury
Le 11 déc. 06 à 18:17, Chris Cunnington a écrit :

------------------------------------------------------------------
Dr. Noury Bouraqadi - Enseignant/Chercheur
ARMINES - Ecole des Mines de Douai - Dept. I.A.
http://csl.ensm-douai.fr/noury

European Smalltalk Users Group Board
http://www.esug.org

Squeak: a Free Smalltalk
http://www.squeak.org
------------------------------------------------------------------

>> I don't know what virtual hosting mechanism
>> underlies the two sites, but I think there
>> is an "apples to oranges" comparision here.
>
> That has been discussed on the seaside mailinglist too. It uses a
> technique similar to DabbleDB.
> Honestly I don't see how you get anywhere with 32 MB and Squeak/Seaside.
same, and especially, I found the demo very slow (counter, multi) on
firefox from linux and windows...

just to give an idea, I have a server for 30€/month
(www.dedibox.fr or www.dediboxinternational.com (same but more
expensive...))
-160Gb HD
-1go Ram
-up/dw unlimited
-the proc is non standard though (VIA C7 2Gh with material ssl...)
...
-but of course no support, ... etc...

So, of course, I'm not asking for same characteristics for
seasideparasol, but at least decent RAM and HD, especially if targeted
to be multi web paradgm (php, pearl...) and also, a good quality of
service of the connection...

So more thant a critic, I'd like to have information on performance
(QoS) with seaside... compared maybe to others servers-side application
framework (php , java...). I'm too newbie to know that and I'd like to
see what people thinks...

On the server I mentionned, using a debian, I notice that only hitting a
seaside app. led to 50-60% proc use. Is it normal ? In this case, how
many simultaneaous connection could It support ?

On windows (dual core), around 20-30%... I juste closed opened
Transcripts and cleaned a bit the image... I know there are better
optimisation. Bur according to your experience, with a prepared
production image, what could we expect as QoS ? when do we need to load
balance, how to ? etc ...

I think this is a very important information especially for people who
want to enter production. What do do ? what not to do ?
For instance, at the last smalltalk party in Paris, I met a  guy who
developped in Seaside and who was encountering problem of image frozen
when load testing (under Linux).

Thanks for any information

Cédrick


ps: I also noticed that using firefox on linux, was far slower than
using firefox on windows (for the rendering)... which is why I came back
to windows... (anyway, it's more a problem with Linuw I guess than with
squeak).

But the wording was funny in the ad on one point:  Can you have a web site
in pure smalltalk, or is it just for content?  I mean, I don't want to have
to dink around with PHP or especially perl.  Yuck.

_________________________________________________________________
Stay up-to-date with your friends through the Windows Live Spaces friends
list.
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk

2006/12/12, Cédrick Béler <[hidden email]>: What do you mean, would you like to have better logging and profiling like
- time used to process callbacks
- time used to render
- memory usage
- number of session
- memory use of sessions
- ...


Or general answers like: a seaside session uses x MB of RAM and Squeak
on a Y GHz CPU supports Z concurrent users?

> On the server I mentionned, using a debian, I notice that only hitting a
> seaside app. led to 50-60% proc use. Is it normal ?

Continuous or just a spike to answer the request? The later is normal,
the former not.

> In this case, how
> many simultaneaous connection could It support ?

This is so much application and dependent there can not be a general
answer to that.

> On windows (dual core), around 20-30%... I juste closed opened
> Transcripts and cleaned a bit the image... I know there are better
> optimisation. Bur according to your experience, with a prepared
> production image, what could we expect as QoS ? when do we need to load
> balance, how to ? etc ...

Our general experience is that the persistence is what limits you.
This depends on so many factors that only you can answer this.

Squeak does not care about dual cores or SMP and it is good that way.

> I think this is a very important information especially for people who
> want to enter production. What do do ? what not to do ?
> For instance, at the last smalltalk party in Paris, I met a  guy who
> developped in Seaside and who was encountering problem of image frozen
> when load testing (under Linux).

This is common for some applications. There are two problems here:
- One is that the vm hits the memory limit (128 MB per default).
Symptom: image is frozen at 100% CPU. You can try to play around with
the -memory and -mmap parameters. That might make it to appear less
often.
- The other is that gui is frozen. Symptom: image is frozen at 0% CPU.
Suspending and resuming the UI with the screenshot application several
times might make the ui reacting again until it freezes the next time.

As a general solution to any kind of problem: ask on squeak-dev or the
seaside mailing list.

Philippe

>
> IMHO, the addition of seasideparasol.com should
> be seen, not as a competitor, but as the *success*
> of seasidehosting.st in promoting Seaside.

I totally agree. And ESUG is really happy to see that happening!
Long life to chris.

Stef
>
>
>

Hi and Thanks Philippe ;)
yes that would be cool ;)
>
> Or general answers like: a seaside session uses x MB of RAM and Squeak
> on a Y GHz CPU supports Z concurrent users?
but yes this is exactly the kind of information I'd like to have. I
imagine it's very dependent of the application itself, but at least
having a general idea for a generic application (sushi store ?)... and
also to have comparison data (if possible) of similar app in say php,
just to compare (even if speculative).  same order ? php with mysql for
a simple registration app would be able to serve 100 simultaneous
connections whereas squeak seaside 10 if DBR or 20 if ...

I don't want precise figure but general ones... according to your
experiences...
>
>> On the server I mentionned, using a debian, I notice that only hitting a
>> seaside app. led to 50-60% proc use. Is it normal ?
>
> Continuous or just a spike to answer the request? The later is normal,
> the former not.
just a spike... so  it's ok, but under linux, it takes longer...  but
it's maybe related to the fact firefox(linux) takes more time to render...
> Our general experience is that the persistence is what limits you.
ok. What about persistance in the image ? faster ? probably requires
more RAM to run squeak ?

If using a database, it's probably better to serve it from another
server if possible ?

> This is common for some applications. There are two problems here:
> - One is that the vm hits the memory limit (128 MB per default).
> Symptom: image is frozen at 100% CPU. You can try to play around with
> the -memory and -mmap parameters. That might make it to appear less
> often.
I read a post in squeak dev saying that the processor wasn't of first
importance, but more the RAM...
On a 1Gb server, you'll put -memory 1Gb   or less ?
> - The other is that gui is frozen. Symptom: image is frozen at 0% CPU.
> Suspending and resuming the UI with the screenshot application several
> times might make the ui reacting again until it freezes the next time.
I had a similar problem before probably due to Comet. Since the priority
has been changed, I didn't have this problem anymore ;)


Thanks

Cédrick

ps: I think it would be nice to have somewhere in seaside.st the process
to enter production (prepared image, known vm that works well, ...) as
well as advices... (persistance,  session management, limits...) ;)