View source for Talk:Distributed Robocode

I will be very thankful, if someone go through the how-tos and say, it there any problems --Jdev 04:54, 31 August 2011 (UTC)

Looks neat, I may give it a try soon. I think Simonton and/or Chase had RoboResearch working over a network at one point, but I'm not sure how easy to use it was. So basically you setup the battles you want to run on the server, and any clients connecting will run the battles and report results to the server? --Voidious 15:54, 31 August 2011 (UTC)

No. Server has web methods to submit battles, request they state and results. When client starts, it's try to connect to all servers, listed in servers.cfg file and process them in different threads submitting battles and getting results. --Jdev 04:01, 1 September 2011 (UTC)

I spent a little time tonight seeing if I could get my server up and running like I have been planning to do, now that I have fixed my hardware (replaced the dead CPU fan among other things).

Unfortunately, I only have Java 6, and the system requirements say I need Java 7. Since Linux generally hates me, it came at no surprise that to install Java 7 on my outdated Fedora install, I first have to update Fedora. I tried both the Oracle JDK 7 and the OpenJDK 7, but neither would install. I'm on Fedora 13 now, and it is my understanding that you cannot upgrade more than 2 revisions, so if I want to upgrade to current, it will take several back to back upgrades (I think the current release is Fedora 18, so I would probably have to upgrade to Fedora 15, then Fedora 17, then Fedora 18, though I could just stop at whatever the first version is that allows Java 7). The recommended method for upgrades prior to Fedora 18 is to use DVDs with the Anaconda installer. I'll probably have to create several upgrade DVDs and include some time to make sure everything works for each step in the upgrade sequence.

Long story short, I'm looking at probably several hours to get to a point where I have a functioning copy of Java 7 on my server. So I am shelving the effort until a weekend when I have a whole day to dedicate to upgrading my server.

Whenever I get around to it again, I will post another update here.

As much as i want to love Linux, this is just another example in a long history of examples of why I will probably always stay with Windows. I shouldn't have to upgrade my OS just to upgrade my Java version. It would be like having to upgrade to Windows 8 in order to install Java 7. Ridiculous.

However, one thing I haven't tried yet is just unpacking Oracle Java 7 manually and figuring out how to change my path and environment variables to point to the manually unpacked Java 7. It seems like that might work. But if it doesn't, then it's just more wasted time.

Actually there are some programs that require a specific windows version to run. For example DirectX 10-11 requires Vista or above. There are Windows 8 only programs.

Linux doesn't keep stable ABI between kernel versions, so although it means binaries aren't compatible with old/new versions, it also means that a lot of cruft can be cleaned out, making it a more efficient, less bloated piece of software. Chances are, if you wanted you could take modern OpenJDK source and compile it against your old kernel. But there have been a lot of kernel fixes and improvements since F13, so it's probably worth the upgrade from a security standpoint anyway for anything that will be public-facing.

Actually, that's not really accurate. The Linux Kernel keeps the ABI to userspace *very* strictly stable. The part of the kernel that doesn't have a stable ABI is the interface to drivers, but that's not relevant to the issue of programs like Java 7. In this context, the issue is that certain userspace libraries that don't always maintain a stable ABI.

The thing with linux distributions, is that they don't just contain the core OS, they also contain libraries that aren't always compatible across versions. On Windows, similar libraries often are not compatible across versions either (i.e. MSVC redistributables which are essentially libc shared libraries). The only thing that's different under Linux distributions, is that under Linux, the distribution is typically responsible for providing those libraries that may not be compatible across versions, whereas under Windows individual application installers are responsible for bringing in their own versions of every library. The advantage is that it makes is that the system is not filled with multiple versions of the same library and bugfixes in a library that many programs depend on can be taken advantage of much more rapidly, among other advantages. The disadvantage is that you cannot treat major versions of Linux distributions as compatible unless you bundle your libraries the way Windows programs typically do (which you can, and is a common practice if one wants a program to work across versions). In summary: It's not a deficiency of linux distributions, it's just a different philosophy in how programs are bundled, with both advantages and disadvantages. One thing this means, is that you shouldn't expect to be able to be able to use the latest versions of software unless you either keep your distribution version up-to-date, or are willing to compile the software yourself.

Ah, thanks for the correction! So it's the libraries which keep breaking binary compatibility, not the kernel...

Kind of tangential to the OS discussion, but I wonder if/why DR really needs Java 7? I doubt there could be that many changes required to build it with Java 6 compatibility.

I know I'm kind of being bitchy on this, but when most of my time is spoken for due to work, family, house, and car maintenance, not being able to install Java 7 on a 2 year old Fedora install when it works just fine on a 12 year old copy of Windows XP is downright irritating.

And yes, I should really upgrade my Windows XP as well, but until daycare goes away, I really can't authorize spending $200+ for a new copy of Windows just to have improved security, better file searches, and slightly better 3D graphics. Plus again, needing a day to rebuild my system from the ground up.

I don't know, all I can think of is this. =) http://xkcd.com/927/

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.