[Pharo-dev] Recent VM for Pharo 2 on Ubuntu 8.04

Esteban Lorenzano estebanlm at gmail.com
Wed Aug 28 11:41:22 EDT 2013


just because I have vocation of service :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pharovm-u804.tar.gz
Type: application/x-gzip
Size: 684758 bytes
Desc: not available
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20130828/2cf6ee05/attachment-0002.gz>
-------------- next part --------------


enjoy,
Esteban


On Aug 28, 2013, at 3:50 PM, Sven Van Caekenberghe <sven at stfx.eu> wrote:

> 
> On 28 Aug 2013, at 15:36, Stéphane Ducasse <stephane.ducasse at inria.fr> wrote:
> 
>> Indeed I do not see how we could provide support that oracle does not.
>> We should be realistic.
> 
> I know our resources are limited, but some arguments in this discussion are just wrong.
> 
> It might at the moment not be possible to run the latest JVM on Ubuntu 8.04, but it is still possible to run Java on such older systems, many VM's that came after the inception date of 8.04. For example. we run java 7 (2011) on ubuntu 8.04 (2008)
> 
> On the other hand, Pharo 2.0 was released with support for 8.04 AFAIK and now, after minor updates, it no longer works. That is completely different, IMHO.
> 
> And AFAICT newer images require newer, pharo specific VM's, so using the older release VM's doesn't seem to work.
> 
> But unless someone says, 'here take this vm', I don't require support, I will work around it, it is just frustrating.
> 
>>>>> for older systems, you are by your own. Is like that, yes.
>>>>> 
>>>>> We cannot maintain all VM for all possible configurations. Nobody can do that, not even canonical, less us. Ubuntu 8.04 is just too old.
>>>>> 
>>>>> Even JVM is not supported on Ubuntu 8.04: http://www.oracle.com/technetwork/java/javase/config-417990.html
>>>>> (latest is 10.04... which we support, or intent to at least)
>>>>> Also... we are not oracle, we have more limited resources.
>>>>> 
>>>>> So , is not a workaround. Is the only reasonable solution: every software provider in earth supports a limited amount of system configurations, usually from some years ago, we provide at least the sources, instructions and support in the form of help/answering questions.
>>>>> 
>>>> 
>>>> This is not the only instance of the problem.
>>>> If I'm not much mistaken, same problem has been recently reported for Debian 7
>>>> (Laszlo Zsolt KIss, 08/08/13 10:43). As Andres pointed out (08/08/13 14:40), it's libc is 17 months old. The proposed "solution" was the same - recompile on target system.
>>> 
>>> in that moment answer was: compile it yourself until we provide a working version (which we now provide). 
>>> Ubuntu 8 is another problem :(
>>> but do not get me wrong... is not that I do not would want to help... is just that I need to be realistic about what I can and what I don't :(
>>> 
>>> 
>>>> 
>>>> To make me clear, I have no problem if you say "Sorry, we don't support
>>>> anything older than 12 months. Or 3 years. Or ...". I just don't think
>>>> that asking people to recompile whenever there is glibc dependency problem is "real solution".
>>>> 
>>>> I'm very sorry for starting this pointless discussion.
>>>> 
>>>>> 
>>>>>> 
>>>>>>> we can offer support (but should be pretty straight forward, specially in linux systems).
>>>>>>> 
>>>>>>> I disagree with the solution proposed in (2), the cost of maintaining such approach would be exponential.
>>>>>> 
>>>>>> No, not really. There aren't many of those (at least, weren't in my case) and I found out that sometimes I could do better (faster) job :-)
>>>>> 
>>>>> you are invited to provide your working version, it would be cool for everybody :)
>>>>> 
>>>> 
>>>> Unfortunately, I've done it for a different VM :-)
>>>> 
>>>> 
>>>> Best, Jan
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 



More information about the Pharo-dev mailing list