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.

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.

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.

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?

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.