[Pharo-users] Critical issues for Dr. Geo on P6

phil at highoctane.be phil at highoctane.be
Fri Jul 28 14:08:47 EDT 2017


On Fri, Jul 28, 2017 at 3:25 PM, Sven Van Caekenberghe <sven at stfx.eu> wrote:

>
> > On 28 Jul 2017, at 15:13, phil at highoctane.be 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.
>

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.




> 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).
>

To be frank 14.04 is the only decent release I know. All of the other ones
have issues of one kind or another.

>
> Change is unavoidable, it is not just part of life, it *is* life.
>

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

>
> > 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 <
> serge.stinckwich at gmail.com> wrote:
> >
> >
> > On Fri, Jul 28, 2017 at 9:34 AM, Hilaire <hilaire at drgeo.eu> 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/
> >
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20170728/5558da9c/attachment.html>


More information about the Pharo-users mailing list