[csmithuk]

Actually no. We get 13-14 years out of Microsoft offerings which is enough lead time for test, provisioning and an 8-10 year lifecycle. Plus due to overlap we have enough time to test v.next.

With respect to support you get a very narrow configuration of supported software and hardware with RH. Keeping it rolling isn't as easy as it looks. The developer support is awful as well. Documentation is shitty,you're tied to C++/JDK versions that are ancient etc. Also no MSDN, no partner support (which is pretty awesome). My few dealings with RedHat support have left us without a solution.

For ref - platforms: Exchange, Windows Server, IIS, SQL Server (the latter I've got an installation that has been cleanly upgraded since 1996 though TWO versions)

[72deluxe]

I hadn't thought about it but you're very correct about documentation for development. Doxygen generated pages are one thing, but the MSDN is another and it's excellent.

Well done Microsoft.

[matwood]

I worked with MS technologies for years at a previous job and you are right that MSDN docs are the best out there. Javadoc, doxygen, etc... all pale in comparison. Now that I mostly work with OSS technologies I usually just read the source and any comments/docs that happen to be included.

[jamespo]

Red Hat are taking steps to address the development software through "Software Collections", but JDK wise I don't see how that differs from windows?

[csmithuk]

You're right. But Windows has CLR which is integrated in Microsoft's support offerings.

[gnaffle]

How are you any more tied to old JDK versions on Linux, compared to Microsoft? Also, I'm curious to what requirements you have that makes it OK to upgrade hardware and apply service packs and Java updates, but not to do OS release upgrades on Linux?

[csmithuk]

There are no supported versions by RedHat other than that which ships with the OS distribution. To get a recent JDK we then have to deal with Oracle as well and the cost goes right up. With the CLR and Microsoft there is one point of call under one contract. Plus no one wants to deal with Oracle.

Hardware isn't upgraded. It's replaced when it fails. It's easier to get hardware off the shelf that is certified for Windows Server (any version!). This is particularly true on the tail end of a product lifecycle.

The OS upgrades in Linux are usually utterly painful (Debian included). If you go with CentOS/RH, you have to do this every 5 years at average due to the API churn in Linux distributions[1]. You need to get your developers on there ASAP. With Service Packs and Java updates, a simple test cycle will suffice as they don't break the API contracts. They promise this and deliver.

[1] The kernel syscall interface is fine but major versions of Apache, glibc and compilers and anything even vaguely related to client-side stuff is a PITA.

[72deluxe]

I had to upgrade a machine running an old version of Slackware on the 2.0 kernel. Yes, from about 1999 I think.

It was impossible to get that Perl web system running on anything modern without massive pain.

For the wonderful bliss of Linux-land, at least with Windows you know that something written 20 years ago will probably still work. (Yes, I know - they shouldn't have written it in Perl)

[draegtun]

If it had been written in some other scripting language then I'd guess you would have had even more issues upgrading! Because Perl, despite all its supposed warts & bad image, remains highly backward compatible.

NB. The biggest issues I've seen in upgrading are modules that use C libraries (unfortunately things do change over time!).

As an example I'm still running a Perl web system & data munging backend that I wrote back in 2001 with only minor tweaks over the years for new/modern systems.

[acqq]

Exactly. Perl 5 exists since 1994, so it's probably Perl 5 code there which needs probably little to no changes to run even today on the latest 5.x interpreter. I don't understand what were the issues that 72deluxe faced.

[72deluxe]

I think it was renamed modules between versions? I never got to the bottom of it. In fact, I aborted migrating it and ended up leaving it running, but instead virtualised the machine (that was fun!)

If I had known what I was doing with Perl, it might have been better. I was a bit harsh on Perl, apologies. But it still stands that migration on Linux boxes isn't massively easy or fun (not that Windows is either)

[acqq]

I see, so you use .NET and complain about the fact that Oracle owns Java. And somehow you blame Red Hat for all that.

[csmithuk]

No. I complain that Red Hat support a bastardised version of Java (and Eclipse) that ships with their OS meaning that for the sake of sanity you have to deal with Oracle and RH to get a cohesive platform versus the single vendor. Subtly different.

[acqq]

Isn't the "bastardized version" of Java actually the "Java as supported by Red Hat"? If you don't want RH's support but still want some support of course you have to depend on some other company.

And the reason why you consider RH's version "bastardized" is, I assume, that it's not "the newest and latest." Which is the main argument with which we started: that RH intentionally doesn't push "newest" all the time in order to have long support cycles.

Your argument for Microsoft was that their technology changes slower, and then complain that RH technology doesn't change fast enough?

[csmithuk]

Not really. They barely support it, it's half integrated into RPM and is impossibly difficult to persuade a lot of stuff to work with it due to system dependencies on certain jars. You end up having to pull a full JDK from somewhere else which isn't supported.

If you look at the CLR there are only two major current versions: 2.0 and 4.0 and perfect legacy compat and wide support across all windows server versions.