Skotty's Distributed Robocode Server
← Thread:Talk:Distributed Robocode/Skotty's Distributed Robocode Server/reply (9)
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page.
Return to Thread:Talk:Distributed Robocode/Skotty's Distributed Robocode Server/reply (9).
The way many Linux distributions (i.e. Fedora) are designed, is such that the more frequently you update, the less maintnance it is in the long run.
As far as long-term-stable distributions that still get security updates, they exist (i.e. Debian Stable, RHEL, CentOS) however you often cannot easily install packages made for newer versions (i.e. Java 7 and Fedora 13 situation). To remedy this, one thing that exists for some distributions is a "backports" repository that has newer versions of software build for the old/stable version of the distribution. So far as I can see, one does not exist for Fedora, but one does exist for Debian[1].
Basically, the closest thing that currently exists to what you want probably, is Debian Stable, with the backports repository. Certainly far closer to what you want than Fedora. Unfortunately Java 7 is not among the things in there yet, because backports only includes things from Debian Testing and Java 7 is not in Debian Testing (yet?), only in Debian Unstable.
If you really badly want to be able to install the newest versions while still using a long-term-stable distribution, what would be necessary would be one of two things:
- Building packages for things like Java 7 which build-in the required versions of libraries (as it done on windows). This is doable, but has two major drawbacks: 1) It makes security maintnance significantly more difficult because there are more pieces of software to worry about in each package, and 2) In general is much more work for package maintainers.
- Going further with the "backports repository" concept, trying to include the absolute latest versions, unlike Debian Backports which just includes versions likely to make it into the next major release. This would be nice, but it would be a lot of effort. The likely reason this doesn't exist is because it's rare to find someone with more than two of the three following traits: 1) Interested in long-term-stable releases, 2) Interested in having bleeding-edge versions of software, and 3) Have the time/motivation to make it happen.