Critical issues for Dr. Geo on P6
Locked
12
12
Re: Critical issues for Dr. Geo on P6
 
|
Changing too many things at once is indeed annoying. Now, I am ready to live with that but at one point, I think that we will have to move to something like I see done in other fast evolving ecosystems. In Hadoop for example, Hortonworks (a distribution) moved to a set of slow evolving substrate that is stable and know to stay stable for a long period (HDFS, YARN) and a set fast moving releases for projects that do build on top (Spark). Holding back on the new things makes you feel like you use a tool of the past. Living on the bleeding edge is not doable because you need to solve too many non business centric issues. There needs to be a combination. As far as I am concerned, I worked in 3.0 a lot, skipped the whole 4.0 ship, embarked on the 5.0 and, albeit if I did a bit on 6.0, I may not develop production code on it at the moment. 7.0 looks okay but there are lot of changing things there, so, that is also too much for me. 6.1 can lure me in with Iceberg and 64-bit UFFI and fast inspectors on large collections. I need a platform I can understand and build upon. There needs to be a semblance of LTS in this. Maybe a 6.1, 6.2, 6.3 story and a 7.x line with boostrap magic and what not. 6.x is a great platform and has a lot going for it if stable enough. I have projects coming my way and using Pharo is an option. Now, I need something that is not going to shift under my feet. Especially if I want to embark crew along. Phil On Fri, Jul 28, 2017 at 11:00 AM, Serge Stinckwich <[hidden email]> wrote:
|
Re: Critical issues for Dr. Geo on P6
|
|
> On 28 Jul 2017, at 15:13, [hidden email] wrote: > > Changing too many things at once is indeed annoying. > > Now, I am ready to live with that but at one point, I think that we will have to move to something like I see done in other fast evolving ecosystems. > > In Hadoop for example, Hortonworks (a distribution) moved to a set of slow evolving substrate that is stable and know to stay stable for a long period (HDFS, YARN) and a set fast moving releases for projects that do build on top (Spark). > > Holding back on the new things makes you feel like you use a tool of the past. Living on the bleeding edge is not doable because you need to solve too many non business centric issues. > > There needs to be a combination. > > As far as I am concerned, I worked in 3.0 a lot, skipped the whole 4.0 ship, embarked on the 5.0 and, albeit if I did a bit on 6.0, I may not develop production code on it at the moment. 7.0 looks okay but there are lot of changing things there, so, that is also too much for me. > > 6.1 can lure me in with Iceberg and 64-bit UFFI and fast inspectors on large collections. I need a platform I can understand and build upon. > > There needs to be a semblance of LTS in this. But even the LTS concept does not solve all problems. Every 2 years there is a new LTS, which is supported for 5 years. But in most projects (the same happened here), you are lazy and wait 5 years until you *have* to upgrade. And by then the difference between what you started with (say 12.04) and the current stable (say 16.04) can already be huge (remember, you skipped one LTS release) and the next one is already coming (18.04). Change is unavoidable, it is not just part of life, it *is* life. > Maybe a 6.1, 6.2, 6.3 story and a 7.x line with boostrap magic and what not. > > 6.x is a great platform and has a lot going for it if stable enough. > > I have projects coming my way and using Pharo is an option. Now, I need something that is not going to shift under my feet. > > Especially if I want to embark crew along. > > Phil > > On Fri, Jul 28, 2017 at 11:00 AM, Serge Stinckwich <[hidden email]> wrote: > > > On Fri, Jul 28, 2017 at 9:34 AM, Hilaire <[hidden email]> wrote: > I don't share your enthusiasm. > > I once set up a satisfactory build environment for DrGeo, based on P3. As long as I stay with P3, I can concentrate on DrGeo code: write the code, then fire up a build script to deploy the application. Now porting to P6 is a pain: the infrastructure to deploy a desktop application has not evolve since P3, I have to build again a deployment environment from scratch (VM support, shrinked/built image, I don't know the promise of minimal image build up is not palpable for me). > > Now If I have to spend days on that, I am not sure I will do it again, I can't compete against other geometry application if I have to fight against pharo too. What I want is to concentrate working on DrGeo not Pharo, sorry to make it explicit but I can't much offer to do both. > > > I have sometimes the same concerns with Pharo or some tools of the Pharo ecosystem. I know that we are trying to do our best and regarding the number of core developers we have already an incredible platform. But sometimes, you need to very simple updates and because of subtle problems with VM/configurations/CI/ etc ... this is not that simple and we need to spend times on boring stuff. > > There is no simple solution. > > One solution might be that the core developers only focus on core Pharo functionalities but I think this is somewhat difficult, because most of the dev are from RMOD. RMOD is a research unit and could not spend all his money/effort on an engineering process. > > Another solution is to grow our community. More people, more companies to sustain more engineers through the consortium. The more people we are able to attract, the more people will help to develop working solutions for problems like deployment or to have bug-fixing intermediate releases. > > This is why we all need in the community to do as much as possible advertisements: lectures at universities, talk to your colleague about Pharo, do demos in companies, at open-source forums, use Twitter do talk about Pharo ecosystem, the software you are developing with Pharo. > Don't hide problems but talk about our nice platform and our community. > > We have done this with Stephane in the early days of Pharo at open-source forums in France and I remember that you come in the community after we meet you in one of these forums :-) > So DrGeo2 exists because of this kind of advertisement. > > Regards, > > -- > Serge Stinckwich > UCN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > |
Re: Critical issues for Dr. Geo on P6
|
In reply to this post by philippeback
Changes is ok.
What annoying is announced new feature of P6, but not palpable for common mortal as me (whose main occupation is teaching to teenagers and programming a hobby): * Pharo can now be bootstrapped from source code managed by Git Will a new Pharo user entering Pharo programming get any chance to understand or use it? I don't and it is frustrating. Hilaire Le 28/07/2017 à 15:13, [hidden email] a écrit : > Changing too many things at once is indeed annoying. > -- Dr. Geo http://drgeo.eu |
Re: Critical issues for Dr. Geo on P6
|
|
In reply to this post by SergeStinckwich
Serge,
The only reason I decided to port DrGeo from Squeak to Pharo is because the project wanted to be business centric with features evolution. Changes was not annoying me, it is one reason I decided to switch to Pharo. But still after many years, I find Pharo frustrating for one willing to develop and deploy a desktop application. Hilaire Le 28/07/2017 à 11:00, Serge Stinckwich a écrit : > We have done this with Stephane in the early days of Pharo at > open-source forums in France and I remember that you come in the > community after we meet you in one of these forums :-) > So DrGeo2 exists because of this kind of advertisement. > -- Dr. Geo http://drgeo.eu |
Re: Critical issues for Dr. Geo on P6
|
|
The main problem is DrGeo is one a few software in the community to be deployed as a desktop app.
All the others are dev software (Calypso, Roassal, MOOSE) or web-based app that don't need specific work for deployment. I need to deployed simulation engines that we are building with my team outside the community to people who are not CS experts, so I guess I will need something similar to DrGeo or use a web app. Envoyé de mon iPhone > Le 28 juil. 2017 à 18:43, Hilaire <[hidden email]> a écrit : > > Serge, > > The only reason I decided to port DrGeo from Squeak to Pharo is because the project wanted to be business centric with features evolution. Changes was not annoying me, it is one reason I decided to switch to Pharo. But still after many years, I find Pharo frustrating for one willing to develop and deploy a desktop application. > > Hilaire > >> Le 28/07/2017 à 11:00, Serge Stinckwich a écrit : >> We have done this with Stephane in the early days of Pharo at open-source forums in France and I remember that you come in the community after we meet you in one of these forums :-) >> So DrGeo2 exists because of this kind of advertisement. >> > > -- > Dr. Geo > http://drgeo.eu > > > |
Re: Critical issues for Dr. Geo on P6
|
|
In reply to this post by Sven Van Caekenberghe-2
On Fri, Jul 28, 2017 at 3:25 PM, Sven Van Caekenberghe <[hidden email]> wrote:
You are a Ubuntu user. I am a CentOS|RHEL user. There support is 10 years. Check this: https://wiki.centos.org/About/Product Official party line here: https://access.redhat.com/support/policy/updates/errata TL;DR: CentOS6: until 2020 for maintenance updates CentOS7, until 2024 for maintenance updates. Using the recent/latest is possible with e.g. * Software Collections https://www.softwarecollections.org/en/ * LXC If one needs a 4.x kernel that is doable too via elrepo. But there is a lot of backport happening by RedHat. There is a reason these guys are making gobs of money: they support business. Frankly I wouldn't touch Ubuntu with a 10 feet pole anymore now that I have 100+ servers running CentOS under management.
To be frank 14.04 is the only decent release I know. All of the other ones have issues of one kind or another.
Sure. But change is to be managed and the business is what makes money. So, not catering to business needs is a losing proposition. There is this business by Clement and Esteban that apparently will come to life at one point. I guess business forces may have more impact at that time frame. Wait and see. Phil
|
Re: Critical issues for Dr. Geo on P6
|
|
In reply to this post by philippeback
We understand that perfectly. Now for us we get money now and may be
not the same in the future. Then there are the things that - must be done and consume a lot: 64bits, uFFI, - super important to do git - also super important: cleaning and improving the system. So we pay attention for backward compatibilities but we cannot cover everything. Stef On Fri, Jul 28, 2017 at 3:13 PM, [hidden email] <[hidden email]> wrote: > Changing too many things at once is indeed annoying. > > Now, I am ready to live with that but at one point, I think that we will > have to move to something like I see done in other fast evolving ecosystems. > > In Hadoop for example, Hortonworks (a distribution) moved to a set of slow > evolving substrate that is stable and know to stay stable for a long period > (HDFS, YARN) and a set fast moving releases for projects that do build on > top (Spark). > > Holding back on the new things makes you feel like you use a tool of the > past. Living on the bleeding edge is not doable because you need to solve > too many non business centric issues. > > There needs to be a combination. > > As far as I am concerned, I worked in 3.0 a lot, skipped the whole 4.0 ship, > embarked on the 5.0 and, albeit if I did a bit on 6.0, I may not develop > production code on it at the moment. 7.0 looks okay but there are lot of > changing things there, so, that is also too much for me. > > 6.1 can lure me in with Iceberg and 64-bit UFFI and fast inspectors on large > collections. I need a platform I can understand and build upon. > > There needs to be a semblance of LTS in this. > > Maybe a 6.1, 6.2, 6.3 story and a 7.x line with boostrap magic and what not. > > 6.x is a great platform and has a lot going for it if stable enough. > > I have projects coming my way and using Pharo is an option. Now, I need > something that is not going to shift under my feet. > > Especially if I want to embark crew along. > > Phil > > On Fri, Jul 28, 2017 at 11:00 AM, Serge Stinckwich > <[hidden email]> wrote: >> >> >> >> On Fri, Jul 28, 2017 at 9:34 AM, Hilaire <[hidden email]> wrote: >>> >>> I don't share your enthusiasm. >>> >>> I once set up a satisfactory build environment for DrGeo, based on P3. As >>> long as I stay with P3, I can concentrate on DrGeo code: write the code, >>> then fire up a build script to deploy the application. Now porting to P6 is >>> a pain: the infrastructure to deploy a desktop application has not evolve >>> since P3, I have to build again a deployment environment from scratch (VM >>> support, shrinked/built image, I don't know the promise of minimal image >>> build up is not palpable for me). >>> >>> Now If I have to spend days on that, I am not sure I will do it again, I >>> can't compete against other geometry application if I have to fight against >>> pharo too. What I want is to concentrate working on DrGeo not Pharo, sorry >>> to make it explicit but I can't much offer to do both. >> >> >> I have sometimes the same concerns with Pharo or some tools of the Pharo >> ecosystem. I know that we are trying to do our best and regarding the number >> of core developers we have already an incredible platform. But sometimes, >> you need to very simple updates and because of subtle problems with >> VM/configurations/CI/ etc ... this is not that simple and we need to spend >> times on boring stuff. >> >> There is no simple solution. >> >> One solution might be that the core developers only focus on core Pharo >> functionalities but I think this is somewhat difficult, because most of the >> dev are from RMOD. RMOD is a research unit and could not spend all his >> money/effort on an engineering process. >> >> Another solution is to grow our community. More people, more companies to >> sustain more engineers through the consortium. The more people we are able >> to attract, the more people will help to develop working solutions for >> problems like deployment or to have bug-fixing intermediate releases. >> >> This is why we all need in the community to do as much as possible >> advertisements: lectures at universities, talk to your colleague about >> Pharo, do demos in companies, at open-source forums, use Twitter do talk >> about Pharo ecosystem, the software you are developing with Pharo. >> Don't hide problems but talk about our nice platform and our community. >> >> We have done this with Stephane in the early days of Pharo at open-source >> forums in France and I remember that you come in the community after we meet >> you in one of these forums :-) >> So DrGeo2 exists because of this kind of advertisement. >> >> Regards, >> >> -- >> Serge Stinckwich >> UCN & UMI UMMISCO 209 (IRD/UPMC) >> Every DSL ends up being Smalltalk >> http://www.doesnotunderstand.org/ > > |
Re: Critical issues for Dr. Geo on P6
|
|
In reply to this post by Sven Van Caekenberghe-2
+ 100
On Fri, Jul 28, 2017 at 3:25 PM, Sven Van Caekenberghe <[hidden email]> wrote: > >> On 28 Jul 2017, at 15:13, [hidden email] wrote: >> >> Changing too many things at once is indeed annoying. >> >> Now, I am ready to live with that but at one point, I think that we will have to move to something like I see done in other fast evolving ecosystems. >> >> In Hadoop for example, Hortonworks (a distribution) moved to a set of slow evolving substrate that is stable and know to stay stable for a long period (HDFS, YARN) and a set fast moving releases for projects that do build on top (Spark). >> >> Holding back on the new things makes you feel like you use a tool of the past. Living on the bleeding edge is not doable because you need to solve too many non business centric issues. >> >> There needs to be a combination. >> >> As far as I am concerned, I worked in 3.0 a lot, skipped the whole 4.0 ship, embarked on the 5.0 and, albeit if I did a bit on 6.0, I may not develop production code on it at the moment. 7.0 looks okay but there are lot of changing things there, so, that is also too much for me. >> >> 6.1 can lure me in with Iceberg and 64-bit UFFI and fast inspectors on large collections. I need a platform I can understand and build upon. >> >> There needs to be a semblance of LTS in this. > > But even the LTS concept does not solve all problems. > > Every 2 years there is a new LTS, which is supported for 5 years. > > But in most projects (the same happened here), you are lazy and wait 5 years until you *have* to upgrade. > > And by then the difference between what you started with (say 12.04) and the current stable (say 16.04) can already be huge (remember, you skipped one LTS release) and the next one is already coming (18.04). > > Change is unavoidable, it is not just part of life, it *is* life. > >> Maybe a 6.1, 6.2, 6.3 story and a 7.x line with boostrap magic and what not. >> >> 6.x is a great platform and has a lot going for it if stable enough. >> >> I have projects coming my way and using Pharo is an option. Now, I need something that is not going to shift under my feet. >> >> Especially if I want to embark crew along. >> >> Phil >> >> On Fri, Jul 28, 2017 at 11:00 AM, Serge Stinckwich <[hidden email]> wrote: >> >> >> On Fri, Jul 28, 2017 at 9:34 AM, Hilaire <[hidden email]> wrote: >> I don't share your enthusiasm. >> >> I once set up a satisfactory build environment for DrGeo, based on P3. As long as I stay with P3, I can concentrate on DrGeo code: write the code, then fire up a build script to deploy the application. Now porting to P6 is a pain: the infrastructure to deploy a desktop application has not evolve since P3, I have to build again a deployment environment from scratch (VM support, shrinked/built image, I don't know the promise of minimal image build up is not palpable for me). >> >> Now If I have to spend days on that, I am not sure I will do it again, I can't compete against other geometry application if I have to fight against pharo too. What I want is to concentrate working on DrGeo not Pharo, sorry to make it explicit but I can't much offer to do both. >> >> >> I have sometimes the same concerns with Pharo or some tools of the Pharo ecosystem. I know that we are trying to do our best and regarding the number of core developers we have already an incredible platform. But sometimes, you need to very simple updates and because of subtle problems with VM/configurations/CI/ etc ... this is not that simple and we need to spend times on boring stuff. >> >> There is no simple solution. >> >> One solution might be that the core developers only focus on core Pharo functionalities but I think this is somewhat difficult, because most of the dev are from RMOD. RMOD is a research unit and could not spend all his money/effort on an engineering process. >> >> Another solution is to grow our community. More people, more companies to sustain more engineers through the consortium. The more people we are able to attract, the more people will help to develop working solutions for problems like deployment or to have bug-fixing intermediate releases. >> >> This is why we all need in the community to do as much as possible advertisements: lectures at universities, talk to your colleague about Pharo, do demos in companies, at open-source forums, use Twitter do talk about Pharo ecosystem, the software you are developing with Pharo. >> Don't hide problems but talk about our nice platform and our community. >> >> We have done this with Stephane in the early days of Pharo at open-source forums in France and I remember that you come in the community after we meet you in one of these forums :-) >> So DrGeo2 exists because of this kind of advertisement. >> >> Regards, >> >> -- >> Serge Stinckwich >> UCN & UMI UMMISCO 209 (IRD/UPMC) >> Every DSL ends up being Smalltalk >> http://www.doesnotunderstand.org/ >> > > |
Re: Critical issues for Dr. Geo on P6
|
|
Hilaire
We were discussing this with Esteban and he will do a stab at making sure that we can deploy desktop applications much easier with Pharo. Because we need it. Esteban deployed several desktop apps in the past and we should leverage this knowledge. I also wants to write this in a forthcoming tutorial. Stef On Sun, Jul 30, 2017 at 4:20 PM, Stephane Ducasse <[hidden email]> wrote: > + 100 > > On Fri, Jul 28, 2017 at 3:25 PM, Sven Van Caekenberghe <[hidden email]> wrote: >> >>> On 28 Jul 2017, at 15:13, [hidden email] wrote: >>> >>> Changing too many things at once is indeed annoying. >>> >>> Now, I am ready to live with that but at one point, I think that we will have to move to something like I see done in other fast evolving ecosystems. >>> >>> In Hadoop for example, Hortonworks (a distribution) moved to a set of slow evolving substrate that is stable and know to stay stable for a long period (HDFS, YARN) and a set fast moving releases for projects that do build on top (Spark). >>> >>> Holding back on the new things makes you feel like you use a tool of the past. Living on the bleeding edge is not doable because you need to solve too many non business centric issues. >>> >>> There needs to be a combination. >>> >>> As far as I am concerned, I worked in 3.0 a lot, skipped the whole 4.0 ship, embarked on the 5.0 and, albeit if I did a bit on 6.0, I may not develop production code on it at the moment. 7.0 looks okay but there are lot of changing things there, so, that is also too much for me. >>> >>> 6.1 can lure me in with Iceberg and 64-bit UFFI and fast inspectors on large collections. I need a platform I can understand and build upon. >>> >>> There needs to be a semblance of LTS in this. >> >> But even the LTS concept does not solve all problems. >> >> Every 2 years there is a new LTS, which is supported for 5 years. >> >> But in most projects (the same happened here), you are lazy and wait 5 years until you *have* to upgrade. >> >> And by then the difference between what you started with (say 12.04) and the current stable (say 16.04) can already be huge (remember, you skipped one LTS release) and the next one is already coming (18.04). >> >> Change is unavoidable, it is not just part of life, it *is* life. >> >>> Maybe a 6.1, 6.2, 6.3 story and a 7.x line with boostrap magic and what not. >>> >>> 6.x is a great platform and has a lot going for it if stable enough. >>> >>> I have projects coming my way and using Pharo is an option. Now, I need something that is not going to shift under my feet. >>> >>> Especially if I want to embark crew along. >>> >>> Phil >>> >>> On Fri, Jul 28, 2017 at 11:00 AM, Serge Stinckwich <[hidden email]> wrote: >>> >>> >>> On Fri, Jul 28, 2017 at 9:34 AM, Hilaire <[hidden email]> wrote: >>> I don't share your enthusiasm. >>> >>> I once set up a satisfactory build environment for DrGeo, based on P3. As long as I stay with P3, I can concentrate on DrGeo code: write the code, then fire up a build script to deploy the application. Now porting to P6 is a pain: the infrastructure to deploy a desktop application has not evolve since P3, I have to build again a deployment environment from scratch (VM support, shrinked/built image, I don't know the promise of minimal image build up is not palpable for me). >>> >>> Now If I have to spend days on that, I am not sure I will do it again, I can't compete against other geometry application if I have to fight against pharo too. What I want is to concentrate working on DrGeo not Pharo, sorry to make it explicit but I can't much offer to do both. >>> >>> >>> I have sometimes the same concerns with Pharo or some tools of the Pharo ecosystem. I know that we are trying to do our best and regarding the number of core developers we have already an incredible platform. But sometimes, you need to very simple updates and because of subtle problems with VM/configurations/CI/ etc ... this is not that simple and we need to spend times on boring stuff. >>> >>> There is no simple solution. >>> >>> One solution might be that the core developers only focus on core Pharo functionalities but I think this is somewhat difficult, because most of the dev are from RMOD. RMOD is a research unit and could not spend all his money/effort on an engineering process. >>> >>> Another solution is to grow our community. More people, more companies to sustain more engineers through the consortium. The more people we are able to attract, the more people will help to develop working solutions for problems like deployment or to have bug-fixing intermediate releases. >>> >>> This is why we all need in the community to do as much as possible advertisements: lectures at universities, talk to your colleague about Pharo, do demos in companies, at open-source forums, use Twitter do talk about Pharo ecosystem, the software you are developing with Pharo. >>> Don't hide problems but talk about our nice platform and our community. >>> >>> We have done this with Stephane in the early days of Pharo at open-source forums in France and I remember that you come in the community after we meet you in one of these forums :-) >>> So DrGeo2 exists because of this kind of advertisement. >>> >>> Regards, >>> >>> -- >>> Serge Stinckwich >>> UCN & UMI UMMISCO 209 (IRD/UPMC) >>> Every DSL ends up being Smalltalk >>> http://www.doesnotunderstand.org/ >>> >> >> |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |