Linux with caveats [LWN.net]

Linux with caveats

Posted Apr 23, 2010 15:43 UTC (Fri) by nevyn (subscriber, #33129)
In reply to: Linux with caveats by pboddie
Parent article: RHEL 6 beta version available

> 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
> radically different

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
and often go into different places. Things like multi-minor-versioned python are std. in debian but not in Fedora.

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
> is what many people see (perhaps implicitly) in Linux.

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.

(Log in to post comments)

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.