I thought it went without saying that fixes for problems that don't apply to previous versions of software packages wouldn't (couldn't) be backported. :wink:

And RHEL has quite a bit more than just "good maintainers doing what they can to track fixes." I don't think you quite understand what an enterprise level OS is if you think this is the case. Indeed, Red Hat actually has dozens of employees whose sole purpose in life is to find and fix problems with packaged software (and a lot of the times they do so even before the software developers are aware of the problems themselves).

Anyway, I just wanted to clarify it in case someone was reading this thread and thought to themselves "oh man, CentOS/RHEL must be a horrible OS if they don't even keep their packages up-to-date," because that's obviously not the case.

Hmm, I wasn't trying to say something so simplistic as fixes for problems that were created for new features wouldn't apply. Rather, it was that some fixes can eventually become intertwined with new features to the extent that it's difficult to extract the fix from the feature.

And no, I'm well aware of what "enterprise-level OSs" are, however in my experience they haven't been quite as nice as you say.

Regardless the point remains that you will be using software that is very likely to be several versions out of date, which sometimes is a far larger problem than having what are likely to be relatively obscure bugs fixed. Security is a different question, of course.

But the simple fact of the matter is that if your application requires Python 2.6, for instance (or Ruby 1.9 or Lua 5.1 or whatever), and the fancy-pants enterprise OS only has Python 2.1 (or Ruby 1.4 or Lua 4.0 or whatever), well, you're basically up a creek without a paddle unless you're willing to maintain a local installation.

For this reason, understanding that "enterprise-level OSs" don't have new versions of software can actually be very important, and I would in turn say that saying that they actually do keep things up to date is in fact misleading itself.

If you want the latest Python/Ruby/whatever, and you don't want to maintain a source-compiled installation, you simply find the repository that has the version of the package you're looking for and use it. You can even configure your system to use it during auto-updates, if keeping it "up-to-date" floats your boat. I see no reason why you would think you'd be "up a creek without a paddle." I've never found myself in such a position since I began using Linux in general. :grinning:

Well, sure, if you start allowing arbitrary third-party repository sources – assuming that such things exist for your particular combination of software and enterprise OS, which isn't at all a given – then you can get the software provided by those sources. But the whole point of using an enterprise OS is to not do things like that, really, because you want the stability etc. So if you're going to start getting new versions of all kinds of things, you eventually might as well get a non-enterprise OS.

I use Windows, although I try to maintain backward compatibility with unices.

No, not "arbitrary". Nobody's suggesting you go to Bob's Fishing Shack website and click on the worm icon to download a repo config for his newest version of Ruby. There are several major, well-respected repositories out there that encompass just about every latest-and-greatest software package you'd ever want. Also, I think it's gross exaggeration on your part to say that you might as well get a non-enterprise OS if you want unsupported software updates. You'd be surprised at how many corporate giants use, say, PHP 5.3 on an RHEL server. It doesn't bring the world to an end :grinning:

Give me examples of repositories "that encompass just about every latest-and-greatest software package" that will install seamlessly onto all these enterprise OSs, then. No, I'm not interested in source packages, because that defeats the whole point of using the packaging system.

I already gave a prime example for CentOS/RHEL up a few posts. There's also EPEL. I can't speak for non-RH platforms, because I don't use them and don't know anything about their package management systems or subsequent resources. I'd still blindly bet on them having equivalents, though.

I'm somewhat surprised that you think that it's ok to want to use something for rock-solid stability etc. etc. and then at the same time use something maintained by some dude who does it for apparently a hobby. I maintain that if you get to the point where all your production software is running from sources other than your enterprise OS provider, well, it's unclear how much you're really getting from them anyhow for anything other than the kernel.

In other words, the only way to get recent software is to rely on people who are essentially doing it as amateurs. You've lost all advantages for that software that you were supposed to get by paying for your enterprise OS. :shrug:

Also, you mention EPEL but even cursory investigation reveals that EPEL won't replace packages but only provides add-ons.

Also, more cursory investigation reveals that neither Remi's repository nor EPEL provide Python 2.6, and it's not the available version in RHEL5. And it's been out since October 2008. So… yeah. :shrug:

Remi Collet currently works on the Fedora project.


No, it isn't. Most of the people running and contributing to these repositories contribute to the OS and software projects found within it. You're going to trust them to make the software, but not deliver it? Shrug. If that's the case, then you should just get comfortable building from source. It's not rocket science, after all.


It serves packages like lua, git, clamav, wine, etc. If you don't need what it has, use another repo.


Python is a special case, because yum itself requires 2.4, so there's no way around having to manually install it in parallel unless you're some kind of wizard ninja.



Anyway, my intention was merely to educate people on backporting so that they didn't get the wrong impression about a great OS. I think I've done that as well as I can possibly do it, so I'll leave it at that. :grinning:

Enterprise OS == z/OS

And yet you place value in people you pay to maintain stuff for you. Surely even you, although you will leave things at that, realize that there is a slight incongruity in the statements you are making.

You just broke my heart.

That looks so good (reminds me of Amiga OS) yet I don't have a VAX or Itanium based system (the later one being no. 2 on my "what I would do if I had money to burn" list).


I just thought of the 3 operating systems I consider the worst choices for a server (from worst to best of the worst :lol:) :

1. MacOSX (cocoa = "TZE DOOM" :evil:)
2. Windows Vista (aero = "TZE DOOM's young, slightly deliberate brother.)
3. Amiga OS (at least somehow fail-safe. Compared to MacOSX and Windows Vista).

Well what's this about? Are you just dicking around looking for weird shit to do?

Install Linux then install VirtualBox on Linux then install Solaris 10 on VirtualBox then install a
non-global zone in Solaris 10 then install a chroot jail instance in that non-global zone then
run your mud in THAT, and come back and brag about your weird setup.

As for this "worst servers" list, the only one you listed that is arguably a server is
OS X, and that's if you specify the server version. The default versions of what you
listed as "worst servers" aren't servers in the first place, but desktop/workstation OSes.

That's like listing motorcycle models in order of which is the worst truck.

-Crat
http://lpmuds.net

No. I'm not bored or anything like that.

I'm just overly interested in different operating systems and would like to benchmark as many as possible. My server is going to be Solaris* based, no matter what.


As for the "worst server" list of mine. I confused Vista with Windows Server 2008. There are Amiga OS server releases in existence, though. They are rare and far off the main system path, but they exist.


*+ Virtual Box for the programming and client testing stuff. So I don't have to change systems.

I'm not sure why you care about benchmarking and comparing if you've already made a decision "no matter what". Seems odd to shop around if you know exactly what you're getting and won't change your mind.

Ok. "No matter what" sounds slightly surreal, I suspect. I would of course change my mind, if I stumbled across a system which is superior in every possible way.

I don't know what is so hard to believe, though. Never tried out multiple systems? That's how I found out that MacOSX suits my graphic design needs.


All that chit chat aside, I still haven't decided on the guest systems (so beside my eagerness to do benchmarks, there's also a rational reason). I know I'll use Windows XP for the programming and client testing stuff. However, since I'll have to return my Macbook (my college screwed the deal in charging me 500 bucks more. That's 1508 euros for the lowest spec 13" machine.) in July, I will have to look for a new (preferably free of charge) OS for my graphical work.

It's not hard to believe that you would like to see many options. What was hard to believe is that you'd already made up your mind no matter what, and still found it useful to look around. :smile: But we've established that that was just hyperbole, so ok.

Anyone accustomed with Corel Painter 11 (my favourite graphics tool, ever since I got that Macbook)?

Curios how the Windows version looks and feels, since that seems to be my only (legal) alternative.



PS: Sorry for all the faulty grammar. Totally downed by college and my stupid Skype acquaintance who wouldn't stop spamming "Men behind the wire". As a Englishman, that song offends me in so many ways.

Personally, I prefer the more modern versions of Solaris for servers. RingMUD is currently running on top of Nexenta, which is an OpenSolaris derivative. Things like ZFS and zones make it hard to pass up Solaris for a server environment.