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.