[CentOS] Re: Contemplating Move -- [OT] Fedora Core

[Preston Crawford]

Thanks for the resume...

On Wed, 17 Aug 2005, Bryan J. Smith wrote:

> Mike McCarty <mike.mccarty at 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.
>
>
>
>