| |||||||||||||
Linux with caveatsLinux with caveatsPosted Apr 22, 2010 14:55 UTC (Thu) by pboddie (subscriber, #50784)In reply to: Linux with caveats by gmagklaras Parent article: RHEL 6 beta version available
As part of the "regime", I do not really understand why you are stuck, when your RHEL 5.5 workstation could easily KVM/xen your favourite distro on which you can base your development environment. Some things for my friendly sysadmins to do when they get back, then. :-) What motivated my remark was that claims to support "Linux" which amount to only being able to run one particular "blessed" distribution often undermine the benefits of Linux, one of which was articulated in the comment I responded to: you can always find a distribution which suits you best. Of course no-one wants to have to support every distribution out there, but when the "regime" is happy to indulge Windows users with the latest and greatest, but they won't even entertain a second choice of well-regarded Linux distribution, one can't help feeling that one has drawn a very short straw indeed.
(Log in to post comments)
Linux with caveats Posted Apr 22, 2010 19:35 UTC (Thu) by nevyn (subscriber, #33129) [Link]
> Of course no-one wants to have to support every distribution out there,
> but when the "regime" is happy to indulge Windows users with the latest > and greatest, but they won't even entertain a second choice of > well-regarded Linux distribution
But these are not the same. In many ways the difference between RHEL-5 and RHEL-6 will be significantly less than the difference between RHEL-6 and Ubuntu-10.4, even though they'll be released within months of each other (as against years).
Linux with caveats Posted Apr 23, 2010 12:51 UTC (Fri) by pboddie (subscriber, #50784) [Link]
The most blatant differences are surely in things like packaging and update delivery, but in a sense, these things are what you rely on the vendor for (if they can be bothered to fix stuff, that is). Meanwhile, having all the infrastructure hooks in place is going to be more work for the "regime" in question: how the software uses the existing authentication systems, and so on.
Even if it's not the case now, over time the goal of the distribution vendors should be to make their products fit in with the minimum of local effort. Once upon a time, having huge numbers of local customisations and packages would have been the norm, but effectively saying that "Red Hat's package for XYZ isn't as good as our local package" can be regarded as making a bold claim indeed, at least for software where Red Hat can bring a lot of top-level expertise to bear.
I've worked in places where the "regime" even felt the need to have their own special Windows distribution, much to the annoyance of colleagues who found stuff mysteriously disappearing and having "fresh" stuff copied in on a regular basis, so if the support burden starts to stack up to "double the work", my experience tells me to review what the nature of some of that "support" is. I can well imagine that an mindset of maintaining lots of "special" software (from the days when people had to deliver stuff in a heterogeneous environment where the target platforms - stuff like Ultrix, IRIX, HP-UX, Tru64, SunOS, Solaris, AIX - had no decent repositories of their own) persists in many institutions and is not always adequately reviewed.
But anyway, the deployment of different distributions shouldn't be radically different. Although vendors may see some benefit in having things that way, or selling management tools to smooth over the cracks, it's certainly not in the spirit of giving end-users the choice, which is what many people see (perhaps implicitly) in Linux.
Linux with caveats Posted Apr 23, 2010 15:43 UTC (Fri) by nevyn (subscriber, #33129) [Link]
> The most blatant differences are surely in things like packaging and
> update delivery, but in a sense, these things are what you rely on the > vendor for
Yes, but that's a huge difference on it's own! The next big difference is that the bits coming from those updates are very different.
> But anyway, the deployment of different distributions shouldn't be
I guess this depends on your definition of "radically different". Some of the components are the same or similar (say, the version of vim, coreutils or maybe perl). But a _lot_ is different.
Configuring network is radically different between debian/ubuntu and Fedora/RHEL, a bunch of other configuration is almost as bad. As you said, all the package tool are named differently, act differently and have different feature sets. Packages are named differently, split differently
If you hit a kernel bug in one distro. there's no guarantee it'll be in the other one (even with 10.4 vs. 6, the backport work is _huge_ on the 6 side ... and there are a bunch of changes from debian in 10.4). If it is in both you'll need to open two support tickets, and they'll almost certainly have different resolution timelines etc.
All of which is why I said it'd be nearly double the work, to support both.
> it's certainly not in the spirit of giving end-users the choice, which
There is choice ... you just have to choose given a number of differences.
Even if you forked from RHEL-6 beta tomorrow, by the time RHEL-6 came out you are guaranteed to have "more than one difference". If the user liked some differences on one side and some on the other, they'd have to choose the least worst.
Linux with caveats Posted Apr 24, 2010 16:13 UTC (Sat) by pboddie (subscriber, #50784) [Link] Yes, but that's a huge difference on it's own! The next big difference is that the bits coming from those updates are very different. So, Debian and Red Hat split things up differently. It'd be interesting to see, once you've installed all the necessary packages, which differences there actually are. And why should it matter? Back in the day, you'd have your institution's private repository giving out packages, albeit all built from source and more or less the same on every platform, but underneath all that the differences would be profound. Configuring network is radically different between debian/ubuntu and Fedora/RHEL, a bunch of other configuration is almost as bad. As you said, all the package tool are named differently, act differently and have different feature sets. Packages are named differently, split differently and often go into different places. Things like multi-minor-versioned python are std. in debian but not in Fedora. I don't deny that it could be confusing, but as an individual it's possible to remember how the networking is configured on different distributions and where the Python packages go, so I struggle to see how it should be an insurmountable burden for an organisation dedicated to managing this kind of stuff. And weren't there tools for handling at least stuff like network configuration? Once upon a time, people swore by stuff like Webmin, and before Caldera was subverted for lawsuit purposes they even had a project going to try and standardise this stuff. If you hit a kernel bug in one distro. there's no guarantee it'll be in the other one (even with 10.4 vs. 6, the backport work is _huge_ on the 6 side ... and there are a bunch of changes from debian in 10.4). If it is in both you'll need to open two support tickets, and they'll almost certainly have different resolution timelines etc. Isn't Launchpad supposed to solve this problem? No, you don't have to answer that. ;-) All of which is why I said it'd be nearly double the work, to support both. For one specific kernel-related bug, yes. For the entire Linux support activity, I'm not completely convinced. Either way, vendors should be working towards standardising much of the administrative interface, and those deploying Linux should be attempting to take advantage of the choice the Linux ecosystem offers, not taking one particular vendor's flavour and pretending it's something like HP-UX.
|
|||||||||||||