On Aug 28, 2013, at 3:50 PM, Sven Van Caekenberghe <s...@stfx.eu> wrote:
> > On 28 Aug 2013, at 15:36, Stéphane Ducasse <stephane.duca...@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) yes, is possible that it runs. But basically what they say is that if it doesn't, you are by your own, they will not provide support (and I was talking about support). And they are oracle, that's my point: they dropped support for ubuntu 8 a couple of years ago... > 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. well... yes and no... pharo3 will require pharo3vm, but pharo2 can be run with VMs from more than a year (the real problem here was the annoying SmallInteger bug, and probably some other minor VM problems) > > 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 >>>> >>> >>> >> >> > >
