Mike McCarty mike.mccarty@sbcglobal.net wrote:
I wasn't aware of that. I once installed RHL 6.1 on a few machines and used it for several months, but I never had any contact after that.
There is a lot of Red Hat Linux history that has been "retroactively rewritten" by many people.
Ok. That is what I sort of expected. I don't need to pay for hand-holding.
That's definitely not what you're paying for with RHEL.
But I do need support from time to time. CentOS sounds like ideal, nearly. But see below. I suppose you meant "threshhold". I'm accustomed to somewhat different language conventions. I've heard alpha engineer/internal only testing beta customer testing release believed stable
Yes, I know.
But even in that model, you can think of Fedora Development (fka Red Hat Rawhide) and "alpha," Fedora test (fka Red Hat Beta) as "beta," and release as release.
Development/Rawhide is where new packages are dropped. Eventually Red Hat reaches a set of packages it likes for the next release, freezes changes, and forks off the set as the next "Test/Beta." Test/Beta is where packages are integration tested. Integration testing is something that can be done on a package-level.
After a series of Test/Beta releases, 1-2-3-4, whatever it takes, then it is a release. That is the 2-2-2 month release model that results in the 6 month releases.
Now how the packages are selected leds us to the 6-6-6 month release model. Every 2-3 releases, Red Hat _purposely_ makes _major_ changes to the GCC, GLibC and/or kernel, possibly core features such as SELinux, devfs/udev, etc... Almost all of them are made in the first release, sometimes a few are tweaked/changed by the second release.
Red Hat Linux 4.0, 5.0, 6.0, 7.0, 8.0 and Fedora Core 2 are considered _major_ changes. Fedora Core 4 could also be considered a major change too.
engineer test engineer testing programs integration test engineers testing whole load verification test QA testing whole load against rqmts acceptance test customer test at live site before accepting roll-out (also called FVO or Field Verification Office) release/roll-out release to general public
[ BTW, as I mentioned before, understand you are talking to someone who has spent half his career developing avionics code for military and defense systems -- primarily with GNU/BSD platforms (Linux, VxWorks, etc...). ]
If at any point, any defects are found, then the load gets evaluated and if the defects are deemed unacceptable, (no acceptable work-around) then the load is retracted, reworked, and then starts over at an earlier stage.
Red Hat builds their packages upon the community, even if they are involved with much of the community. Red Hat eventually freezes the package set how it likes it and moves to an integration test. There are _several_ tests. Then there is an eventual release. This is the 2-2-2 month release model.
99.9% of the complaints I've seen on Red Hat Linux and, now, Fedora Core have to do with older compatibility, installer issues due to dual-booting/existing systems and other things that have *0* to do with the quality of the packages both individually and as a whole. In the case of Red Hat Enterprise Linux (and CentOS), the older compatibility is "shaken out" by the fact that they are 12-18 months _later_ than the ".0" release. But the installer issues are rarely worked out, because installers are, by their very nature, imperfect.
Hmm. Maybe what you're saying is that RH altogether is not what I had in mind. Or that I'll have to adjust my thinking if I intend to continue using RH at all.
You have to be around Red Hat awhile to understand how their release model works. For most of us who have, we trust it more than just about any other.
I don't know. I am new to Linux. I'm accustomed to Solaris. We weren't asked to upgrade every 6 mos with Solaris. More like every 4-5 years.
That's what Red Hat and SuSE do with their "enterprise" releases -- 5+ years of support.
_All_ other Linux releases are typically only 2 years or less, with few exceptions (maybe Debian).
[ BTW, don't assume you're not taking to a guy that has been deploying SunOS 3 on the Internet since 1989, and is a huge fan of Solaris 10 on Opteron. ]
Ok. Then RHL is beta test.
Fair enough.
Given the strict approach of Red Hat Linux, feel free to assert that every Linux distribution is a beta-test -- maybe Debian is one of the few exceptions.
"Ports" distros like Gentoo could even be considered totally lacking in integration testing, since you always build from source.
And I appreciate your efforts, here. I'm not sure "blame" is the right word. As I said, no criticism intended. It is whatever it is. I'm trying to evaluate what is best for my situation. What is best for yours may not be what is best for mine.
Agreed, although it would help me to know what you are developing. So far you have spoken in generalizations.
E.g., I have been developing mission-critical, real-time avionics for VxWorks and Linux targets on Solaris and Linux since the mid-'90s.
I have also done less critical embedded work using some BSD, mostly Linux and other systems (even DOS).
Ok, that seems fair enough. Perhaps simply watching FC closely and "upgrading" on my own schedule (not theirs) is good enough.
There is always Fedora Legacy.
As I mentioned before, if you're expecting "free support," then good luck. You're not going to find any vendor or community that's going to fulfill needs both ways.
CentOS does a pretty good job of balancing as best as it can -- a 1:1 rebuild of Red Hat Enterprise Linux from Source packages, but a good set of additional packages in CentOS Plus, Extras, etc...
I am doing contract work on software for pharmacists.
Ahh, so they are used to OS/2 and AIX solutions, maybe some SCO here and there, I assume? You'll probably want to stick with RHEL/RHD, or CentOS when you don't need Service Level Agreements (SLAs).
Currently, I'm building/testing on Linux FC2, with targets SCO and console app (pseudo MSDOS) under Windows.
FYI, I know what APIs are used in a OS/2 1.x/2.x console as well as a non-GDI Win32 target (or at least I used to, it's been awhile ;-).
[ In the early '90s, I was the OS/2 expert at the largest consulting engineering firm in the SE US, which was also the largest installed base of Bentley Systems Microstation -- the first native NT 3.1 application. I've been around OS/2-NT a long, long time. I'm proud to say I have _never_ had to support "Chicago" (Win95/98/Me) in my entire career, and told several people I'd be "professional negligent" if I allowed it on the network. This included early looks into the NT 3.1 betas and even some code. ]
We do compiles for release under SCO or Windows. I'm trying to get us to where we do cross-compiles for MSDOS, and use common source.
There is the DJGCC compiler for DOS16 and DOS32, which includes support for MS-DOS 7.x "Chicago" Int21h functions (like long filenames).
Frankly, I wish I could get them to abandon support for Windows console app.
Considering Windows RPC/SMB services are _not_ "safe" for console apps, I completely agree.
Reasonable. Perhaps then FC with careful choice of upgrades would be best.
I don't know, CentOS with CentOS Plus/Extras seems to be good. Red Hat Desktop is fairly cheap in quantity when you want a Service Level Agreement on all the software you don't write.
But I'm sure getting pressure to abandon FC2, although I'm using latest and greatest.
Fedora Core 2 was turned over to "Legacy" months ago.
Even CentOS 4, based on RHEL 4, is a fork of the "more mature" current Fedora Core 3 codebase.
But you say that they don't back port changes, rather make new releases to fix problems.
Not always. Red Hat Linux and, now Fedora Core, have always tried to backport to avoid changes. But there have been some newer package releases, depending on the effort. This is especially in comparison to most other distros (sands maybe Debian, maybe SuSE somewhat as well).
Red Hat Enterprise Linux (so CentOS) have _always_ been "extra anal" on avoiding new feature adoption or changes. SuSE Linux Enterprise Server (SLES) is close, although maybe not so anal, it depends.
So, what would be wrong with staying with FC2, and using Fedora Legacy in more or less the same manner?
If it works for you, great.
Is FC3 really that much different from the last FC2 + all updates + Legacy?
Yes.
The "next revision" after a "major change" typically fixes a crapload. ".1" releases were always much better than ".0" releases, and I purposely waited on ".1" releases before moving away from the previous ".1" or ".2".
I have had only one (1) problem with FC2, which was that it clobbered my partitition BR (or BPB if you prefer) and caused WinXP to refuse to boot. (Another problem was that I installed GRUB into my MBR, which caused my machine to want to go into recovery mode. But that was partly my own fault. It's also partly the fault of the installer, and people being slightly more enthusiastic than truthful about multi-boot systems.)
The PC is the worst multi-boot platform. Linux will not solve the problem, especially with Microsoft's heavy non-compliance with ATA standards.
I recently did a presentation on disk geometry and all the _stupid_ things that XP does -- especially just before SP2, in SP2 and many post-fixes that are trying for ATA-6 compliance.
Even Microsoft hasn't figured out what it's going to do yet. But one thing is for certain, Microsoft is regularly using undocumented bytes in the Master Boot Record (MBR) that is already in use by other boot loaders.
I typically recommend another swappable disk for Windows, or at least keeping your C: filesystem within the first 32GB of the disk.
Anyway, now that I've fixed the BRs, and got WinXP managing my multi-boot, and GRUB picking what version of the kernel to load, I've found it very stable.
The installer of every distro will not be able to handle that. Not even Microsoft's bootloader does all that automagically, and you have to do all sorts of manual steps.
It's not a Linux issue at all, but a PC/Windows one. And Microsoft and Intel are in no hurry to solve it either.
I wonder why the pressure to move on? I get advice from time to time on the FC echo making it sound like FC2 is a danger just being on my machine. But if it's sooooo bad, then why was it released in the first place?
Why was Red Hat Linux 5.0 or Red Hat Linux 7.0 released? Because sooner or later, new things have to be adopted. And Red Hat's typically the one that does it, and forces everyone to comply.
But you have suggested with some amount of force that I should move away from FC2 to FC3.
Sorry, I meant FC4 is not nearly as bad as FC2 (not FC3). Typo, sorry about that.
There is a reported known defect in the firewall for FC4 which prevents using Windows Shares. Why do you say this as nothing to do with FC?
Security and RPC services (like Windows Networking)compatibility are often mutually exclusive. You have to reduce security to get compatibility. It's a catch-22.
I would not like to categorize my statements as complaints. I'd rather categorize them as statements of what my situation is, and how well FC does or does not fit my situation.
Okay, let me rephrase, your statements are pretty much ones you're going to have issues with in general with Linux. Linux comes with many defaults that are not "play friendly" with "ready to be worm-infested" Windows networks, cannot deal with Microsoft's constantly changing geometry/boot issues, etc...
No vendor flavor really does it well at all, not even Microsoft's own different Windows versions.
I don't find Linux administration fun. If I wanted to load a dozen versions of Linux up to see what they are like, I'd download a bunch of Live CDs and boot them one after another. For my work machine I don't want to be reinstalling every few months.
RHEL/CentOS is probably best then. Fedora Core is still good, don't get me wrong, but the updates to RHEL/CentOS are better than Fedora Legacy.
To put it another way: every install/upgrade/whatever one runs the risk of data loss. Since data in this case is my livlihood, I'd rather do it less often than more.
Well, I've never had a data loss (although I lost a /var filesystem with XFS 1.0 back in Red Hat Linux 7.1, but no data loss on that). I've also upgraded from Red Hat Linux 4.2 -> 7.1, and subsequently from 7.3 -> Fedora Core 3 -- until I moved to x86-64.
Upgrading hasn't been an issue for me in the more "community" releases on my personal system (which is also a heavily used development/engineering system).
At work, I've typically deployed RHEL/RHD, although Gentoo for some R&D, and Debian at various locations.
IIU you, you're saying that the churn in CentOS is just about as bad.
Well, I'd at least start getting updates from Fedora Legacy for Fedora Core 2.
I have the ISOs for FC3, and have burnt discs. I tried an install on another machine, and it failed. Are you suggesting that I use those CDs to try to upgrade my work computer? (Now, I realize that "# yum upgrade" is not the same as booting the CD.)
Backups are always good, but yes, if the CD work. BTW, you don't have to use the CD to upgrade. You can boot CD #1 with "linux askmethod" and access the .iso files from a partition that you're not upgrading from -- such as a FAT32 partition.
Administer/support what? Somehow I lost track of the antecedent for the pronoun.
I meant FC/RHL/RHEL/CentOS are virtually the same from administering the system in configuration, day-to-day activities, etc...
Since I am a complete newbie to *NIX admin, I find it somewhat daunting to contemplate a wipe/reinstall. I don't want, for example, to have to re-build and re-install the cross-compiler which targets MSDOS. And other applications. And my /home tree, which has a great deal of stuff installed in it.
Then consider just sticking with Fedora Core 2 and Legacy Updates. At the most, if you upgrade to Fedora Core 3, it's pretty much the same GCC, GLibC and Kernel series, so the impact is minimal. But stay with Fedora Core 2 for now.
If you want, build a new "Sister Build System" based on CentOS 4, which is very much the same GCC, GLibC and Kernel series as FC2/3 as well.
I guess I'm pretty ignorant about this. What do you think I might miss from FC in going to CentOS?
Same as everything in RHEL, since CentOS is based on it. I don't know because I don't know how you use your system.
If you say so. Upgrade FC3->CentOS is easier?
No, FC2->FC3 is easiest. If you want to go CentOS 4, install new.
Thanks. I plunked down $100 for a fellow to build me up a machine with no disc, just a box with MB, Floppy, CDreader, Ethernet, pwr. I added a 40GB disc for $50, and intendto fiddle with it, until I get to where I can back up and restore and feel comfortable with being able to get my system back. THEN I want to think about possibly upgrading my system. This may be a few months, since I work during the week :-)
Then just stick with Fedora Core 2 if it's working for you. Fedora Legacy was still churning out necessary updates last time I checked. How well they are tested or if they are still in the "Testing" subdirectories, and not release, is always a consideration.
Could you elaborate on the reasons?
6-6-6 model. The earlier the revision, the more "issues" because of new adoption, etc... The latter the revision, the less "issues" because of the accommodations, maturity, etc...
Red Hat Linux 6.0, 6.1, 6.2 -> 6.2 "E" Red Hat Linux 7.0, 7.1, 7.2 -> Enterprise Linux 2.1 <- 7.3 Red Hat Linux 8.0, 9 -> Enterprise Linux 3 <- Fedora Core 1 Fedora Core 2, 3 -> Enterprise Linux 4 Fedora Core 4
As you can see, after 2-3 6-month releases, Red Hat bases its 18-month Enterprise release on. Sometimes there is a 3rd or 4th 6-month release before the next series.
Looking at the left, you'll see Red Hat Linux 6.0, 7.0, 8.0, Fedora Core 2 and 4. Looking towards the right you will see the "enterprise" releases, as well as Red Hat Linux 6.2, 7.3, Fedora Core 1 and Fedora Core 3.