On Wed, May 11, 2016 11:10 am, Warren Young wrote:
> On May 11, 2016, at 9:38 AM, m.roth@xxxxxxxxx wrote:
>>
>> Warren Young wrote:
>>> This isnâ??t just about RHEL vs Debian and
>>> derivatives of same. Several major non-Linux OSes also manage to do
>>> automatic upgrades between major releases: Windows, OS X, FreeBSD...
>>
>> I was under the impression that all the releases of OS X were more like
>> what we call subreleases (6.6->6.7).
>
> You canâ??t transfer meaning between different version number systems.
> There is no global standard for the meaning of version numbers. The only
> thing that matters is that there is internal consistency.
>
> (Which is why Windows version numbering is a joke.)
And there was a joke about them. When RedHat started pacing fast with
their CD version releases: 7.3 --> 8 --> 9 in very short time, someone
said: they try to catch up with others in major version number. And
someone else pointed: they cant: MS already has Windows 2000 ;-)
>
> OS X treats changes to the â??xâ?? component of their OS X 10.x.y version
> numbering system about the same way as EL does in its x.y system. The
> only difference is that major OS X versions have been coming out yearly in
> recent years, so that there is less cumulative difference between major
> versions than in CentOS major versions. But thereâ??s probably at least
> as much change every 3 major OS X versions, as youâ??d expect since CentOS
> major versions are also about 3 years apart.
>
> And, in fact, OS X will allow itself to be upgraded across major OS
> versions. It doesnâ??t demand that you upgrade to each intermediate
> version separately.
MacOS 10 server (sorry about using Arabic number, I hate using Roman
numbers written with Latin letters, makes any search useless) breaks
things between 10.x versions consistently. They change the way
authentication is done, add, then drop Apache modules, and so on. No, I do
not run any of my servers under MacOS (FreeBSD is current choice,
hopefully for long time to come). But some of Professors I work for do it,
and I have to help them by doing dirty part that comes with it. So: nobody
is perfect (meaning MacOS 10 here ;-)
Valeri
>
> Calling OS X major releases â??subversionsâ?? is just as fallacious as the
> opposite problem we see here in the CentOS world, where some people
> believe that CentOS 7.1 is incompatible with CentOS 7.2. A change to y in
> these two x.y system means something very different, yet both are correct
> because both systems are internally consistent.
>
>>> Your point about the 10 year support cycle for RHEL is also invalid.
>>> The
>>> time spacing between major releases is only about every 3 years, and
>>> that
>>> is the period that matters here.
>>
>> No, it's not invalid, nor is it what matters. For example, here at work,
>> we have clusters, and a small supercomputer, all running 6.x (in the
>> case
>> of the supercomputer, it's an SGI-modified RHEL 6.x), and they'll go to
>> 7
>> probably when they're surplused replaced.
>
> Yes, andâ?¦? Just because you have one use case where a major version
> upgrade does not make sense does not mean that major version upgrades
> donâ??t make sense everywhere.
>
> I already covered that case in my previous post, and the counterargument
> remains the same: not all OS upgrades can be coupled with hardware
> upgrades. VMs are only one reason, though a big one.
>
> As for all the rest of your post, yes, I get it: nothing should ever
> change, nothing should ever break. You just go and live live that dream.
> Meanwhile, in my world, change happens. Your unwillingness to cope with
> it does not prevent me from doing so.
> _______________________________________________
> 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
