Thanks, do nothing, just wait and see until SqueakSource turns completely unusable.
I don't know if people won't noticed or don't want to admit it, but SqueakSource is down very often lately..
2011/2/21 Fabrizio Perin fabrizio.perin@gmail.com:
SqueakSource is up and running. I did restart it at 15:55 GTM+1 so i don't know how i can help you.
2011/2/21 Hernán Morales Durand hernan.morales@gmail.com
SqueakSource is down again. I'm tired of this situation, there is any alternative "free" repository? Cheers,
-- Hernán Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.
On 21 February 2011 16:31, Hernán Morales Durand hernan.morales@gmail.com wrote:
Thanks, do nothing, just wait and see until SqueakSource turns completely unusable.
I don't know if people won't noticed or don't want to admit it, but SqueakSource is down very often lately..
Which is a good sign, because it indicating that there are a lot of activity comparing to couple years before :)
I don't know, maybe we should test-drive the different (newer) VM+image combinations for it? Is it possible?
2011/2/21 Fabrizio Perin fabrizio.perin@gmail.com:
SqueakSource is up and running. I did restart it at 15:55 GTM+1 so i don't know how i can help you.
2011/2/21 Hernán Morales Durand hernan.morales@gmail.com
SqueakSource is down again. I'm tired of this situation, there is any alternative "free" repository? Cheers,
-- Hernán Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.
On 2011/02/21 15:31, Hernán Morales Durand wrote:
Thanks, do nothing, just wait and see until SqueakSource turns completely unusable.
Maybe cut out the sarcasm. You waited an entire 29 minutes to complain that volunteers who might not be in your timezone aren't responding quickly enough for your tastes.
By the way, it looks rather unbroken from here.
frank
You're right, we should continue expecting a human-robot volunteer to press the button every time the machine is broken, and that's very kind attitude.
Hernán
2011/2/21 Frank Shearar frank.shearar@angband.za.org:
On 2011/02/21 15:31, Hernán Morales Durand wrote:
Thanks, do nothing, just wait and see until SqueakSource turns completely unusable.
Maybe cut out the sarcasm. You waited an entire 29 minutes to complain that volunteers who might not be in your timezone aren't responding quickly enough for your tastes.
By the way, it looks rather unbroken from here.
frank
But the problem is that we have no alternatives, and if we want some, we have to build them :). It's not just about complaining and waiting for the others to solve our problems.
On Mon, Feb 21, 2011 at 3:00 PM, Hernán Morales Durand < hernan.morales@gmail.com> wrote:
You're right, we should continue expecting a human-robot volunteer to press the button every time the machine is broken, and that's very kind attitude.
Hernán
2011/2/21 Frank Shearar frank.shearar@angband.za.org:
On 2011/02/21 15:31, Hernán Morales Durand wrote:
Thanks, do nothing, just wait and see until SqueakSource turns completely unusable.
Maybe cut out the sarcasm. You waited an entire 29 minutes to complain
that
volunteers who might not be in your timezone aren't responding quickly enough for your tastes.
By the way, it looks rather unbroken from here.
frank
Discussing alternatives is a start for a solution, and as I've seen from the posts above we have alternatives, we do not have consensus.
2011/2/21 Guillermo Polito guillermopolito@gmail.com:
But the problem is that we have no alternatives, and if we want some, we have to build them :). It's not just about complaining and waiting for the others to solve our problems.
On Mon, Feb 21, 2011 at 3:00 PM, Hernán Morales Durand hernan.morales@gmail.com wrote:
You're right, we should continue expecting a human-robot volunteer to press the button every time the machine is broken, and that's very kind attitude.
Hernán
2011/2/21 Frank Shearar frank.shearar@angband.za.org:
On 2011/02/21 15:31, Hernán Morales Durand wrote:
Thanks, do nothing, just wait and see until SqueakSource turns completely unusable.
Maybe cut out the sarcasm. You waited an entire 29 minutes to complain that volunteers who might not be in your timezone aren't responding quickly enough for your tastes.
By the way, it looks rather unbroken from here.
frank
Hi,
at HPI, we have a SqueakSource with a GemStone backend. The only downtimes we experienced were due to necessary maintenance.
Best,
Michael
Am 21.02.2011 um 19:21 schrieb Hernán Morales Durand hernan.morales@gmail.com:
Discussing alternatives is a start for a solution, and as I've seen from the posts above we have alternatives, we do not have consensus.
2011/2/21 Guillermo Polito guillermopolito@gmail.com:
But the problem is that we have no alternatives, and if we want some, we have to build them :). It's not just about complaining and waiting for the others to solve our problems.
On Mon, Feb 21, 2011 at 3:00 PM, Hernán Morales Durand hernan.morales@gmail.com wrote:
You're right, we should continue expecting a human-robot volunteer to press the button every time the machine is broken, and that's very kind attitude.
Hernán
2011/2/21 Frank Shearar frank.shearar@angband.za.org:
On 2011/02/21 15:31, Hernán Morales Durand wrote:
Thanks, do nothing, just wait and see until SqueakSource turns completely unusable.
Maybe cut out the sarcasm. You waited an entire 29 minutes to complain that volunteers who might not be in your timezone aren't responding quickly enough for your tastes.
By the way, it looks rather unbroken from here.
frank
-- Hernán Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.
El lun, 21-02-2011 a las 19:25 +0100, Michael Haupt escribió:
Hi,
at HPI, we have a SqueakSource with a GemStone backend. The only downtimes we experienced were due to necessary maintenance.
I think the number of users that hit squeaksource.com vs HPS's own everyday is a key factor in the perceived performance and net uptime of each installation.
Cheers.
Michael
Am 21.02.2011 um 19:21 schrieb Hernán Morales Durand hernan.morales@gmail.com:
Discussing alternatives is a start for a solution, and as I've seen from the posts above we have alternatives, we do not have consensus.
2011/2/21 Guillermo Polito guillermopolito@gmail.com:
But the problem is that we have no alternatives, and if we want some, we have to build them :). It's not just about complaining and waiting for the others to solve our problems.
On Mon, Feb 21, 2011 at 3:00 PM, Hernán Morales Durand hernan.morales@gmail.com wrote:
You're right, we should continue expecting a human-robot volunteer to press the button every time the machine is broken, and that's very kind attitude.
Hernán
2011/2/21 Frank Shearar frank.shearar@angband.za.org:
On 2011/02/21 15:31, Hernán Morales Durand wrote:
Thanks, do nothing, just wait and see until SqueakSource turns completely unusable.
Maybe cut out the sarcasm. You waited an entire 29 minutes to complain that volunteers who might not be in your timezone aren't responding quickly enough for your tastes.
By the way, it looks rather unbroken from here.
frank
-- Hernán Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.
Hi,
Am 21.02.2011 um 19:31 schrieb Miguel Cobá miguel.coba@gmail.com:
at HPI, we have a SqueakSource with a GemStone backend. The only downtimes we experienced were due to necessary maintenance.
I think the number of users that hit squeaksource.com vs HPS's own everyday is a key factor in the perceived performance and net uptime of each installation.
Those SqueakSource standstills *never* occurred after we transitioned to the now-running installation. Before switching, we often experienced standstills as well. That's two simple facts, and the number of users does not play a role in this observation.
I do not know the precise number of accesses per day, but around the end of the semester, when students are supposed to deliver their projects, it gets "hot". (I believe that, this term, we had some 80 students in 16 teams.)
No freezes.
Best,
Michael
On 2/21/2011 1:31 PM, Miguel Cobá wrote:
El lun, 21-02-2011 a las 19:25 +0100, Michael Haupt escribió:
Hi,
at HPI, we have a SqueakSource with a GemStone backend. The only downtimes we experienced were due to necessary maintenance.
I think the number of users that hit squeaksource.com vs HPS's own everyday is a key factor in the perceived performance and net uptime of each installation.
It's not. We used SS at Teleplace at first and it died every other day due to heavy commit/update frequency. When we switched to Gemstone we never had these problems again. The problem with SS is that it has very poor concurrency control. It just trips over its own feet when several people commit and update at the same time. I was actually looking at fixing these problems at first only to realize that SS was clearly designed as a single-user system with very little thoughts being put into where and how concurrency plays a role in various operations.
When we switched to Gemsource, these problems went away (though I'm not fully sure why). But they did get replaced with others, most notably the problem of our entire source code being locked in a system that we would be unable to access if our license ever expires. And although we had a sweet deal with Gemstone, due to the sweetness of the deal this happened every six months and a couple of times in critical release situations. After it happened once too many it was deemed to be no longer acceptable and we switched to a simple WebDAV based repository. Which has served us well.
Cheers, - Andreas
On Mon, Feb 21, 2011 at 11:49 AM, Andreas Raab andreas.raab@gmx.de wrote:
On 2/21/2011 1:31 PM, Miguel Cobá wrote:
El lun, 21-02-2011 a las 19:25 +0100, Michael Haupt escribió:
Hi,
at HPI, we have a SqueakSource with a GemStone backend. The only downtimes we experienced were due to necessary maintenance.
I think the number of users that hit squeaksource.com vs HPS's own everyday is a key factor in the perceived performance and net uptime of each installation.
It's not. We used SS at Teleplace at first and it died every other day due to heavy commit/update frequency. When we switched to Gemstone we never had these problems again. The problem with SS is that it has very poor concurrency control. It just trips over its own feet when several people commit and update at the same time. I was actually looking at fixing these problems at first only to realize that SS was clearly designed as a single-user system with very little thoughts being put into where and how concurrency plays a role in various operations.
When we switched to Gemsource, these problems went away (though I'm not fully sure why). But they did get replaced with others, most notably the problem of our entire source code being locked in a system that we would be unable to access if our license ever expires. And although we had a sweet deal with Gemstone, due to the sweetness of the deal this happened every six months and a couple of times in critical release situations. After it happened once too many it was deemed to be no longer acceptable and we switched to a simple WebDAV based repository. Which has served us well.
Doesn't the change to licensing of GemStone/S change things? http://www.gemstone.com/products/gemstone. Now GemStone/S is free up to 16GB. Dale, Martin, care to comment?
Cheers,
- Andreas
Oooh. WebDAV. Nice, familiar, term. We could also throw in rsync and get read only mirrors:)
On Mon, Feb 21, 2011 at 11:49 AM, Andreas Raab andreas.raab@gmx.de wrote:
On 2/21/2011 1:31 PM, Miguel Cobá wrote:
El lun, 21-02-2011 a las 19:25 +0100, Michael Haupt escribió:
Hi,
at HPI, we have a SqueakSource with a GemStone backend. The only downtimes we experienced were due to necessary maintenance.
I think the number of users that hit squeaksource.com vs HPS's own everyday is a key factor in the perceived performance and net uptime of each installation.
It's not. We used SS at Teleplace at first and it died every other day due to heavy commit/update frequency. When we switched to Gemstone we never had these problems again. The problem with SS is that it has very poor concurrency control. It just trips over its own feet when several people commit and update at the same time. I was actually looking at fixing these problems at first only to realize that SS was clearly designed as a single-user system with very little thoughts being put into where and how concurrency plays a role in various operations.
When we switched to Gemsource, these problems went away (though I'm not fully sure why). But they did get replaced with others, most notably the problem of our entire source code being locked in a system that we would be unable to access if our license ever expires. And although we had a sweet deal with Gemstone, due to the sweetness of the deal this happened every six months and a couple of times in critical release situations. After it happened once too many it was deemed to be no longer acceptable and we switched to a simple WebDAV based repository. Which has served us well.
Cheers,
- Andreas
On Tue, Feb 22, 2011 at 6:54 AM, Casey Ransberger casey.obrien.r@gmail.comwrote:
Oooh. WebDAV. Nice, familiar, term. We could also throw in rsync and get read only mirrors:)
And are there any plans to realize WebDav server protocol just in Smalltalk for the new Andreas's WebServer or Kom? Swazoo/Aida, seems to be has just an unfinished and not working WebDav port from it's VisualWorks brother.
Nikolay
On Mon, Feb 21, 2011 at 11:49 AM, Andreas Raab andreas.raab@gmx.dewrote:
On 2/21/2011 1:31 PM, Miguel Cobá wrote:
El lun, 21-02-2011 a las 19:25 +0100, Michael Haupt escribió:
Hi,
at HPI, we have a SqueakSource with a GemStone backend. The only downtimes we experienced were due to necessary maintenance.
I think the number of users that hit squeaksource.com vs HPS's own everyday is a key factor in the perceived performance and net uptime of each installation.
It's not. We used SS at Teleplace at first and it died every other day due to heavy commit/update frequency. When we switched to Gemstone we never had these problems again. The problem with SS is that it has very poor concurrency control. It just trips over its own feet when several people commit and update at the same time. I was actually looking at fixing these problems at first only to realize that SS was clearly designed as a single-user system with very little thoughts being put into where and how concurrency plays a role in various operations.
When we switched to Gemsource, these problems went away (though I'm not fully sure why). But they did get replaced with others, most notably the problem of our entire source code being locked in a system that we would be unable to access if our license ever expires. And although we had a sweet deal with Gemstone, due to the sweetness of the deal this happened every six months and a couple of times in critical release situations. After it happened once too many it was deemed to be no longer acceptable and we switched to a simple WebDAV based repository. Which has served us well.
Cheers,
- Andreas
-- Casey Ransberger
On 02/21/2011 11:49 AM, Andreas Raab wrote:
On 2/21/2011 1:31 PM, Miguel Cobá wrote:
El lun, 21-02-2011 a las 19:25 +0100, Michael Haupt escribió:
Hi,
at HPI, we have a SqueakSource with a GemStone backend. The only downtimes we experienced were due to necessary maintenance.
I think the number of users that hit squeaksource.com vs HPS's own everyday is a key factor in the perceived performance and net uptime of each installation.
It's not. We used SS at Teleplace at first and it died every other day due to heavy commit/update frequency. When we switched to Gemstone we never had these problems again. The problem with SS is that it has very poor concurrency control. It just trips over its own feet when several people commit and update at the same time. I was actually looking at fixing these problems at first only to realize that SS was clearly designed as a single-user system with very little thoughts being put into where and how concurrency plays a role in various operations.
When we switched to Gemsource, these problems went away (though I'm not fully sure why). But they did get replaced with others, most notably the problem of our entire source code being locked in a system that we would be unable to access if our license ever expires. And although we had a sweet deal with Gemstone, due to the sweetness of the deal this happened every six months and a couple of times in critical release situations. After it happened once too many it was deemed to be no longer acceptable and we switched to a simple WebDAV based repository. Which has served us well.
Cheers, - Andreas
Andreas,
The SqueakSource problem is due to basically three things:
1. issues with concurrent access to the file system 2. reliance on old (buggy) Squeak vm
With GemStone all of the mcz files are stored as objects in the repository and we've had decades of experience persisting objects to our repository so the two SqueakSource problems don't exist in GemStone.
At the time that you started using GemStone our license terms were more strict ... Since ESUG2010 your requirements would fit within the standard license terms ...
Dale
Am 2011-02-21 um 19:25 schrieb Michael Haupt:
Hi,
at HPI, we have a SqueakSource with a GemStone backend. The only downtimes we experienced were due to necessary maintenance.
… and I'm working on bringing that to Seaside 3. When my examinations are over, I will release my results of that projects :). It's almost done™.
So Long, -Tobias
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Casey Ransberger -
Dale Henrichs -
Eliot Miranda -
Frank Shearar -
Guillermo Polito -
Hernán Morales Durand -
Igor Stasenko -
Michael Haupt -
Miguel Cobá -
Nikolay Suslov -
Tobias Pape