View source for Talk:Distributed Robocode

From Robowiki
Jump to navigation Jump to search

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)

Contents

Thread titleRepliesLast modified
Skotty's Distributed Robocode Server1121:23, 11 March 2013

Skotty's Distributed Robocode Server

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.

Skotty02:32, 11 March 2013

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.

Skotty02:37, 11 March 2013

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.

Skotty02:40, 11 March 2013
 

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.

Chase04:39, 11 March 2013
 

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.

Skilgannon06:15, 11 March 2013

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Users.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page.

Return to Thread:Talk:Distributed Robocode/Skotty's Distributed Robocode Server/reply (5).

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

Skilgannon18:05, 11 March 2013
 
 

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.

Voidious18:11, 11 March 2013
 

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.

Skotty18:49, 11 March 2013
 

You know what we really need at this point is an OS that doesn't change (or rarely changes), with the exception of security patches and new hardware support. Modern OS's already do everything a typical user needs them to do. The constant changes, new versions, etc just lead to what I will call "technical exhaustion". Tons of time gets spent by people just trying to keep things "up to date", which is fine for tech geeks who have the time and love the latest things, but it costs a lot of people and a lot of businesses a lot of time and money when the older versions were working fine for most of them.

From the OS development company's standpoint in a market economy, I can understand. The desire for them is to keep releasing new versions for people to spend money on, and to encourage upgrades by canceling support for older versions. But don't you think it's about time for a stable Linux release whose purpose is to be a low cost long lived low maintenance OS? Something where updates are just for security patches and to add new hardware support, and it's all handled by automatic updates? Something that will stop costing companies millions of dollars per year in server maintenance / software upgrades / compatibility testing? Something where even if you installed the OS 2 years ago, it's still up to date thanks to the automatic updates, and you can easily install and run Java 7? Hm... or would that make too much sense?

Skotty20:24, 11 March 2013

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

Voidious20:27, 11 March 2013
 

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.
Rednaxela21:05, 11 March 2013