On Wed, 2005-05-25 at 13:51, Bryan J. Smith wrote:
> The reality is that most things are _not_ exposed _until_ people
> actually start using things.
Agreed. But note that the standards are set long before that...
> Your option is always that you can stick with the older release.
> Again, 6+ months for Fedora Core today, 36+ months for RHEL/
> CentOS.
If you are doing anything complicated, I'm not sure you have any
other choice. But then you run into ugliness where you want to
run perl programs that need perl=>5.8.3 to get character set handling
right, and you can't, or you have to do a local install trying not
to break the system version. Or you need mysql 4.x for transactions.
> > with many things that don't work at all that worked in
> > the previous version.
>
> Of course not! That's what change does! ;->
I guess my real complaint is that the bugfixes and improvements to
the old releases that you are forced by the situation to run are
minimal as soon as it becomes obvious that the future belongs to
a different version - that may be a long time in stabilizing to
a usable point.
> Otherwise, the overwhelming distros don't do such a good job, and _any_
> release of theirs can dork up anything! I'd really like to find a vendor
> who balances "early adoption" with "anal SLA-level reliably" so well and
> for so long. It's the 2-2-2, 6-6-6 model that everyone, even Novell-SuSE,
> have adopted.
It will be interesting to see how this works out for Ubuntu. I think it
would be possible to be more aggressive with the application versions
but hold back more than RH on the kernel changes. Of course they'll
have it easy for the first few since they don't have to be backwards
compatible to a huge installed base.
> Both FC3 and RHEL3 started with FC2. And FC2 has already been through
> 6 months of development and Fedora Core 3 was already entering into
> Test by the time CIPE 1.6 was finally available.
How was the CIPE author supposed to know that what would be released as
FC2 would have a changed kernel interface? He did respond with 1.6
as quickly as could be expected after a released distribution didn't
work with it and a user reported problems on the mailing list.
> And when a package doesn't get modified to support kernel 2.6 until
> some 9 months after kernel 2.6 release, and still has issues, at some
> point, Red Hat's gotta say "this is going to cause us headaches to support."
About the kernel, or all of the drivers' authors that assumed that
kernel interfaces shouldn't change?
> If you want to see something change, you have to get involved.
> And that means taking the time to understand what you _can_ do to see
> things change.
And if you want the things that work to not change???
> > It's a complicated system, and it isn't immediately obvious that other
> > distros have exactly the same problems.
>
> Do you know how many times I hear people say that? And I just have to
> shake my head because it can't be categorized as anything else but
> ignorance?
Where do you find the real info? Specific example: I'm trying to make a
software RAID1 partition with one internal IDE and a matching external
drive in a firewire case work. FC1 worked flawlessly once the raid was
established but would not autodetect the drive, either when hotplugged
or at bootup. Everything later that I've tried is worse. Some get the
autodetect right on a hotplug but crash after some amount of runtime.
Is any distro likely to autodetect at bootup in time to cleanly connect
the RAID and then keep working? Maybe it matters that the filesystem
is reiserfs - I see some bug reports about that, but rarely have
problems when the internal IDE is running as a broken mirror.
> > But, in spite of what I consider an occasional bad choice,
>
> Like CIPE I assume? At what point are you going to recognize that
> CIPE was really "no choice" until Fedora Core 3 was in Test?
Like letting it be a surprise to the CIPE author that it didn't work
at release time. I don't remember seeing a hint about this on the
CIPE mail list when someone must have known well ahead that it was
coming.
> > Fedora/RH seem to be among the best and I do give the fact that
> > they've been responsible for getting buggy software in front of a
> > vast number of people credit for it eventually being fixed.
>
> "Buggy"? Or "incompatible?" Big difference!
Buggy. I don't mean RH bugs, I mean bugs from the upstream packages
that got their first huge real world exposure because RH bundled them
on a CD that you could drop into just about any PC and have a working
system. I mean things like the bind, sendmail, and ssh versions that
went out with RH 4.0 and were installed on more machines than ever
before - all with remote exploits that weren't known yet.
> If GNU Tar is incompatible with POSIX, and someone introduces a
> new version or replacement program, like Star, that is, do you know
> how much the "ignorant majority" absolutely derail that person?
The real world is a complicated place. If you want to substitute
a different program for an old but non-standard one you need to
make sure it handles all the same things. Until just recently,
star didn't even come close to getting incrementals right and still.
unlike gnutar, requires the runs to be on filesystem boundaries for
incrementals to work. And, it probably doesn't handle the options
that amanda needs. Theory, meet practice.
> > If you remember the state of free software before RH 4.0 was
> > released you will know what I mean. I do sometimes wonder
> > how things would have turned out if someone had built an equally
> > easy to install CD based on freebsd first, though.
>
> Who says it isn't and I don't also deploy FreeBSD and NetBSD?
By 'first', I meant before RH 4.x, which in my opinion really drove
the popularity of Linux simply because it had a decent installer
that came up working on most hardware at the time. Freebsd was
around at the time but in a form that was much more difficult
for a new user to get working.
> As I always said about Windows, you had your choice between
> incompatible (NT) and unreliable ("Chicago"). I choose the former,
> and I was in the minority. But I didn't have 98% of the problems
> other people had.
That depends on when you started. Before SP6, NT was also unreliable.
Remember that in the timeframe of RH4, you could kill an NT box
by sending it an oversized ping packet - and have a fair chance of
corrupting the filesystem beyond repair from the ungraceful shutdown.
> > Who would you blame for the upgrade that made interfaces not
> > start if the hardware address in the configs didn't match
> > the NIC? That was bad news for my remote machines where all
> > the drives had been cloned and the IP addresses set before
> > shipping.
>
> I'd blame you because you cloned, not installed. ;->
It wasn't so much the cloning as it was setting the IP address
with their GUI tool (and I did that because when I just made
the change to the /etc/sysconfig/network-scripts/ifcfg-xxx file
the way that worked in earlier RH versions it sometimes mysteriously
didn't work). Then I shipped the disks in their hot-swap carriers to
the remote sites to be installed.
> You can't blame Red Hat for an install approach they don't test for.
That procedure can't be uncommon. And the same thing would happen
if you swapped a NIC card - hmmm, I wonder about PCMCIA cards now.
> > I'm not positive about this, but I think it happened
> > at about the same time across Fedora/RH/Centos updates instead
> > of following the scenario you mentioned for testing things that
> > are supposed to change behavior.
>
> What version? I can tell you exactly if it was a major or minor change.
I'm not sure exactly when it happened because it was an update that
did not include a new kernel so the machines weren't rebooted
immediately. I think the ones where I noticed it first were somewhere
in the Centos 3.4 range with some subsequent updates (maybe a month
or so ago).
> .0 always changes stuff.
> Sometimes .1 changes a few things that didn't make it or needed to
> be addressed.
> .2 rarely does, as well as the "enterprise" release.
I think this was just an update without a version number change. As it
turned out, I saw the screen of one that was rebooted at a nearby site
and knew more or less what happened but before I got around to fixing
them all a machine crashed at a distant site and I had to talk someone
who didn't know vi through finding the file and removing the hardware
address entry. If I hadn't already known about it by then or if a
lot of the remote servers had been rebooted and came up with no network
access it might have ruined my whole day.
--
Les Mikesell
lesmikesell at gmail.com