On Mon, April 24, 2017 10:52 am, Warren Young wrote:
> On Apr 24, 2017, at 7:53 AM, Lamar Owen <lowen@xxxxxxxx> wrote:
>> James' point isn't the hardware cost, it's the people cost for
>> retraining.
>
> Unless youâ??ve hired monkeys so that you must train them to do their
tasks by rote, that is a soft cost, not a hard cost. If youâ??ve hired
competent IT staff, they will indeed need some time to work out the
differences, but they will do that on their own if only given that time.
I've been through that, I agree almost on all counts with James Byrne, so
I can give some comments from my chair here. Yes, I do consider myself a
notch more intelligent sysadmin than a monkey, and it does cost me time to
adjust to the differences, and it is annoying, and most annoying is to
adjust to some changes in philosophy (whoever considers the last
non-existent is allowed to re-qualify me back to the level of monkey ;-)
>
> Note also that Byrneâ??s solution was to move to an entirely different
OS,
> but we donâ??t hear about the â??retraining costâ?? involved with that.
Surely it was a larger jump from C6 or C7 to FreeBSD 10 than from C6 to
C7?
Yes and no. Maybe it is just my case, as I stared migrating servers to
FreeBSD even before C7 was released. FreeBSD feels closer to C5, whereas
difference between C5 and C7 is more dramatic (in my by no means objective
feeling). So, everyone who maintained C5 after quick "jump start" may feel
at hone with FreeBSD. My case may be even simpler as as many older
sysadmins I maintained a few UNIXes in the past, including FreeBSD.
>
> He also seems to be sweeping aside the fact that FreeBSD major releases
generally stay in support for about half the span of RHEL and its
derivatives.
True, but keeping your system incrementing in smaller steps that happen
more often is not a big deal. But this is a question of taste: both long
support life like RHEL and CentOS and shorter but smoother changes like
FreeBSD or some Linuxes (Debian and its clone Ubuntu come to mind) - they
both have their advantages and their place where they shine.
> If he wants to stay on a supported OS the whole time that C7
> remains in support, heâ??s probably looking at 2 major OS version upgrades.
I've been through several FreeBSD major version upgrades on servers I
migrated to FreeBSD earliest, and they went smoothly, requiring just 3
reboots in the process. They all had a bunch of jails that were upgraded
as well. Not a single major issue that I had to resolve in a process (call
me lucky... knocking on wood ;-)
>
> Itâ??ll be interesting to see how much change FreeBSD gets in the next 7
years.
It really is. Unless my usual luck in choosing what I expect to be in a
future fails me, not much change will happen to FreeBSD. I was thanking my
luck big time for choosing RedHat (and continuing to Fedora, then CentOS)
instead of Debian once when big flop in Debian (and all clones) was
discovered that was sitting there for over two years (search for Debian
predictable keys). My Debian friend was re-creating all his certificates,
re-generating ssh keys, rebuilding systems from scratch (as you don't know
who might have had root access to your box). And I was repeating myself,
that RedHat never had such a big flop. So I hope, I will be the same lucky
with my choice of FreeBSD as I was with my choice of RedHat (and clones)
back then.
And while we are here: My big thanks to RedHat, and big thanks to CentOS
team for the great job you guys are doing!! I wish I could help you more
than just maintaining CentOS and centosvault public mirrors.
Valeri
>
>> In many ways the Fedora treadmill is easier, being that there are many
more smaller jumps than the huge leap from C6 to C7.
>
> That depends on the organization and its goals.
>
> If you have a true IT staff that exists just to keep servers up to date
and working properly, then yes, youâ??re right, smaller upgrades every
3-6
> months are often easier to handle than trying to choke down 2-10 years
of
> changes all at once, depending on the LTS release strategy and how many
major upgrades you skip.
>
> If youâ??re trying to treat the OS as a base atop which you do something
else, and you just need something that will keep working for 2-10 years
despite being continually patched, then choking that big ball of changes
down every 2-10 years might be preferable.
>
> My main point is that if youâ??re going to take the second path, donâ??t
cry about how much change there is to choke down when youâ??re finally
forced to move forward. You choose to put off dealing with it for many
years; the chickens have come back home to roost, so there will of
course
> be a lot of work to do.
>
>> ...dual-socket Opteron LS20 blades (10+ years old)...CentOS 7, once
installed, works great...
>
> That doesnâ??t really contradict my point.
>
> First, I said â??mostâ?? hardware, but youâ??ve gone and cherry-picked
uncommonly durable hardware here; youâ??re probably out in +3 sigma
territory. A lot of commodity PC-grade SOHO â??serverâ?? hardware
wonâ??t
> even last the 3 years between major CentOS upgrades before dying of
something. There was a period where Iâ??d budget 1-2 years for a
Netgear
> switch, for example. (They appear to be lasting longer now.)
>
> Second, the application of my quoted opinion to your situation is that
you
> should run that hardware with CentOS 7 through the EOL of the hardware
or
> software, whichever comes first. That is, Iâ??m advising the
> change-adverse members of the audience to opt into the second group
above,
> taking OS changes in big lumps when itâ??s time to move to new hardware
anyway.
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> https://lists.centos.org/mailman/listinfo/centos
>
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
