Mike McCarty <mike.mccarty@xxxxxxxxxxxxx> 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.
--
Bryan J. Smith | Sent from Yahoo Mail
mailto:b.j.smith@xxxxxxxx | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
