On Wed, January 7, 2015 09:48, Jonathan Billings wrote:
On Tue, Jan 06, 2015 at 08:45:29PM -0600, John R. Dennison wrote:
It's not relevant in _any_ sense. CentOS is nothing more than (at it's core) a rebuild of RHEL. This type of nonsense should be directed to Red Hat in a Red Hat venue. It's nothing but off-topic noise here as CentOS will not deviate from its upstream in its core offerings.
Agreed.
If you want to participate in how the upstream OS is being shaped, I suggest looking at the Fedora Project, which is driven by volunteers.
If you notice the Subject: of this thread, it is "Design changes are done in Fedora". Pretty clear message.
There is a common word disguised in the letter E that we find in both the initialism RHEL and the acronym CentOS. It is the the word Enterprise. It is my observation that the subscriber base to this list tends to those who have wider responsibilities than deciding what the corporate GUI desktop layout should look like next year.
Most here also seem to be somewhat concerned with concepts of cost and benefit. It is evident in many posts that the increasing costs of supporting large numbers of people negatively impacted by changes introduced to CentOS from outside of their span of control is beginning to impinge more and more upon decision making. In some cases that consideration is evidently influencing the decision to deploy CentOS or not.
Now, what does the subscriber base to Fedora developers list look like? Well, to begin with there are no fewer than 209 official 'Fedora' lists. Which should one join to 'influence' anything? Let us grant that a number, say half, are self-evidently not of great concern to operational deployment and employment of RHEL, CentOS or SL in the Enterprise environment. The oddly named 'UK-Ambassadors' or the narrowly focused language translation mailing lists for instance.
That still leaves in excess of a hundred lists. Where should one apply pressure? What forum exists to discuss the economic costs to Enterprises of introducing a marginal, possibly questionable, improvement to an existing UI or common utility? The devel list? The users list?
A perusal of the contents of both the Fedora devel list and users list does not give one much hope that such a point of view would be tolerated, much less welcomed. For example, one the the notable contributors to those forums is himself banned from this list. Further, discussions tend to be far, far down in the weeds, if not subterranean altogether, when viewed from the perspective of the question: what is this change, improvement, alteration or deprecation going to cost the installed base to implement?
No, no-one presently on this list is likely to have very much of an impact on the folks that are the Fedora project. Their objectives are far removed from the concerns of those tasked to keep automated systems working and invisible to the Enterprises that employ them. The overarching concern of the Enterprise is to employ capital and labour to produce value; and not simply to prove technologies or advance personal or political agendas. Not that the later two situations are uncommon in the Enterprise either.
One might, however, consider that the CentOS list is a concentration of people that evidently have some status within a number of Enterprises. And these influential people have chosen not to pay RH for their offering. It might be of some interest to RH in determining why this is so. It might also be the case that this forum, being concerned with issues such as deployment on a large scale and the costs of upgrading RH flagship product, provides valuable insight on how RH's paying customers might be viewing their product as well.
After all, because we use CentOS rather than RHEL and forgo the provision of RH's expert advice, then we ourselves and our organisations are a self-identified technologically advanced user community. And we are concerned more with the entire package than with any particular component or detail. If we have concerns and reservations then perhaps RH should have concerns. If we express them here then there is a chance, a small chance but a chance nonetheless, that someone at RH with a view a little broader than that evidenced in most of the traffic on the Fedora devel list, might take notice.
IMHO, FWIW.
On Thu, Jan 8, 2015 at 9:48 AM, James B. Byrne byrnejb@harte-lyne.ca wrote:
A perusal of the contents of both the Fedora devel list and users list does not give one much hope that such a point of view would be tolerated, much less welcomed.
Exactly. They don't care about breakage, only change. In the early days I tried to follow Fedora development and no one paid any attention to complaints about breaking interfaces that other things rely on. I eventually just gave up when they pushed a kernel update mid-rev that wouldn't boot on my (mainstream IBM) test box and subsequent updates were the same. I don't really expect them to care - the people who have something invested in existing components and interfaces have been split out of that community. I just see it as a big mistake to let them control the future of the distribution to people that need stability and ongoing interface compatibility.
One might, however, consider that the CentOS list is a concentration of people that evidently have some status within a number of Enterprises.
I used to try to encourage using more linux vs.Windows here and deployed Centos for infrastructure myself wherever possible because it used to be easier to manage and more stable. But now that I'm approaching retirement and realizing that the current management processes aren't going to continue to work, I think that may have been a mistake.
On Thu, January 8, 2015 10:44 am, Les Mikesell wrote:
On Thu, Jan 8, 2015 at 9:48 AM, James B. Byrne byrnejb@harte-lyne.ca wrote:
A perusal of the contents of both the Fedora devel list and users list does not give one much hope that such a point of view would be tolerated, much less welcomed.
Exactly. They don't care about breakage, only change. In the early days I tried to follow Fedora development and no one paid any attention to complaints about breaking interfaces that other things rely on. I eventually just gave up when they pushed a kernel update mid-rev that wouldn't boot on my (mainstream IBM) test box and subsequent updates were the same. I don't really expect them to care
- the people who have something invested in existing components and
interfaces have been split out of that community. I just see it as a big mistake to let them control the future of the distribution to people that need stability and ongoing interface compatibility.
One might, however, consider that the CentOS list is a concentration of people that evidently have some status within a number of Enterprises.
I used to try to encourage using more linux vs.Windows here and deployed Centos for infrastructure myself wherever possible because it used to be easier to manage and more stable. But now that I'm approaching retirement and realizing that the current management processes aren't going to continue to work, I think that may have been a mistake.
I read it and there are very familiar feelings. Some 7 or so years ago I found myself at a meeting (that was open solaris meeting) with a bunch of people who started looking for alternatives to migrate their boxes to from Linux. (I may be off on time; it was right after Oracle acquired Sun Microsystems, so there was already this joke out there: how do you call that system? If you repeat Sun-Oracle very fast you likely will get it right: "snorkel" ;-) One of the pushing points was: already then on average every 30-45 days was either glibc or kernel update, meaning you have to reboot the box (and on multiple threads here there was a bunch of other unpleasant things mentioned so I'll skip them...). Linux from Unix-like system became more Windows like (sorry if it offends anyone, but I can't hold myself and not repeat what one of people called Linux then: "Lindoze").
So, several of those people fled to open solaris. My journey was different, I ended up migrating a bunch of most important boxes to FreeBSD. I know how many on this list are already allergic to me saying this, I promise, this is the last time. I'm using as excuse something familiar I feel in James's post...
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Hello,
Kt, 2015 01 08 11:32 -0600, Valeri Galtsev rašė:
right: "snorkel" ;-) One of the pushing points was: already then on average every 30-45 days was either glibc or kernel update, meaning you have to reboot the box (and on multiple threads here there was a bunch of other unpleasant things mentioned so I'll skip them...). Linux from
And your point? From my previous Linux Engineer experience in some small enterprise, being one of the top 5 biggest banks, there was a push to make mandatory scheduled server reboots every month or two.
Rationale was simple: keeping long uptimes does not makes sense, when updates (not necessary OS but also userspace) piles up and after unexpected reboot shit happens as server is no longer able to boot. This was the experiences with various systems, including RHEL5 on x86 and IBM AIX on Power, Windows and other lovely bunch of hardware. As there were multiple incidents, it was decided to move to a mandatory reboot schedule to have maintenance windows. I believe the only system that was excluded from such plans was mainframe.
Of course this requires to design systems to have load balancing, failover and other stuff available and working.
So, several of those people fled to open solaris. My journey was different, I ended up migrating a bunch of most important boxes to FreeBSD. I know how many on this list are already allergic to me saying this, I promise, this is the last time. I'm using as excuse something familiar I feel in James's post...
And does FreeBSD have magic bullet against reboot requirement after kernel/libc update? Or are you simply not patching system (which you can do on Linux too) ?
BTW Linux already (again) procedes to rebootless kernel upgrade. Unfortunately now there are 4 different implementations (thanks goes to Oracle for buying KSplice and making this exclusive to OL). Although if my memory does not fail there were talks about unification.
-- ____________________________________________________________ Elvinas Piliponis
[cid:1420798946.4375.1.camel@ltkaude5005]
Studentų g. 59-B707, LT-51365, Kaunas, Lietuva Email: elvinas.piliponis@virtustream.comhttps://exchangevs.virtustream.com/owa/redir.aspx?C=C7sp-jyqTEeF3k7ArpiVF1dOSht06dEImQkOuwrkH1VgCkmkTLcZmzDuYzOe4cWdlcZqPVHpALo.&URL=mailto%3aelvinas.piliponis%40virtustream.com | Mobile: +370 69807947
The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting the email and its attachments from all computers without copying or disclosing it.
On 1/8/2015 8:44 AM, Les Mikesell wrote:
But now that I'm approaching retirement ...
is that a promise ? please, hurry up. I, for one, am tired of your diatribes about how change is bad, and I suspect I'm not the only one.
On Thu, 2015-01-08 at 12:55 -0800, John R Pierce wrote:
On 1/8/2015 8:44 AM, Les Mikesell wrote:
But now that I'm approaching retirement ...
is that a promise ? please, hurry up. I, for one, am tired of your diatribes about how change is bad, and I suspect I'm not the only one.
Is change for advantage and betterment or merely because someone wants to do the same tasks in a different manner and wants everyone else to abandon their existing methods of working ?
Changes are not inherently bad but changes prompted by others' amusement are usually unproductively disruptive.
Enterprise, in the RHEL context, suggests stability or have I misunderstood the USA definition of "Enterprise" ?
On 1/9/2015 2:32 PM, Always Learning wrote:
Enterprise, in the RHEL context, suggests stability or have I misunderstood the USA definition of "Enterprise" ?
Enterprise to me implies large business. Businesses that don't adapt to external changes become fossils and die off.
On Fri, 2015-01-09 at 14:36 -0800, John R Pierce wrote:
On 1/9/2015 2:32 PM, Always Learning wrote:
Enterprise, in the RHEL context, suggests stability or have I misunderstood the USA definition of "Enterprise" ?
Enterprise to me implies large business. Businesses that don't adapt to external changes become fossils and die off.
Adapt sounds more pleasant than "disruptive change". It suggests a less abrupt change process :-)
On Jan 8, 2015, at 8:48 AM, James B. Byrne byrnejb@harte-lyne.ca wrote:
these influential people have chosen not to pay RH for their offering. It might be of some interest to RH in determining why this is so.
I’ll tell you why we don’t subscribe.
First, we don’t need their support. We’re quite capable of coping with problems ourselves, including those problems that are *caused by* Red Hat, or allowed into RHEL by Red Hat’s gatekeepers. We’ve been doing this since the GNU experience meant building executables from tarballs on top of some paid-for commercial Unix.
Second, the customers we send these boxes out to don’t *want* Red Hat’s support. They want to call us, not Red Hat. That means we “own” these boxes' problems. Good thing we’re capable of solving them.
There’s a price to not paying Red Hat: we take responsibility for coping with any problems. The CentOS warranty is that if it breaks, we get to keep both pieces. We’re fine with that.
Anyone that isn’t fine with that — those who think someone other than themselves should be responsible for fixing problems with the free OS they’re using — should be using something else.
On Thu, Jan 08, 2015 at 10:48:03AM -0500, James B. Byrne wrote:
After all, because we use CentOS rather than RHEL and forgo the provision of RH's expert advice, then we ourselves and our organisations are a self-identified technologically advanced user community. And we are concerned more with the entire package than with any particular component or detail. If we have concerns and reservations then perhaps RH should have concerns. If we express them here then there is a chance, a small chance but a chance nonetheless, that someone at RH with a view a little broader than that evidenced in most of the traffic on the Fedora devel list, might take notice.
I think this essentially sums up your point, and elucidates what I think is the error in your thinking.
At the point where anything is deployed in CentOS, all the decisions that have been made regarding the technologies in question have been made. The technologies had probably a year of use in Fedora and most likely several months of testing in RHEL's internal development. If you're talking about critical core software, whole infrastructures have been built around it, documentation, build infrastructure, deployment guidelines, etc.
I agree that following the Upstream is a significant time investment, however, as the saying goes, "You Get What You Pay For". Posting to a CentOS list asking for change is probably too little, too late.
On Thu, Jan 8, 2015 at 11:14 AM, Jonathan Billings billings@negate.org wrote:
If we express them
here then there is a chance, a small chance but a chance nonetheless, that someone at RH with a view a little broader than that evidenced in most of the traffic on the Fedora devel list, might take notice.
I think this essentially sums up your point, and elucidates what I think is the error in your thinking.
Yes, it is pretty clearly an error to think anyone else cares. Red Hat will make some money on new training classes helping people cope with the breakage. And CentOS will continue to be a copy with no input. That still doesn't make it any better for the CentOS users of things that now have an expiration date.
On 01/08/2015 11:23 AM, Les Mikesell wrote:
On Thu, Jan 8, 2015 at 11:14 AM, Jonathan Billings billings@negate.org wrote:
If we express them
here then there is a chance, a small chance but a chance nonetheless, that someone at RH with a view a little broader than that evidenced in most of the traffic on the Fedora devel list, might take notice.
I think this essentially sums up your point, and elucidates what I think is the error in your thinking.
Yes, it is pretty clearly an error to think anyone else cares. Red Hat will make some money on new training classes helping people cope with the breakage. And CentOS will continue to be a copy with no input. That still doesn't make it any better for the CentOS users of things that now have an expiration date.
How log do you need to keep saying the same thing.
CentOS is now what it has been for 11 years. If that is what you want, use it. If it is not what you want, use something else.
You think it is so easy to do something else .. then you hire the people required and do your own distro.
On Thu, Jan 8, 2015 at 1:56 PM, Johnny Hughes johnny@centos.org wrote:
How log do you need to keep saying the same thing.
As long as it is right and people keep arguing with it, I guess.
CentOS is now what it has been for 11 years. If that is what you want, use it. If it is not what you want, use something else.
Well it was what I want. Now it's different.
You think it is so easy to do something else .. then you hire the people required and do your own distro.
A different disto with unique maintenance requirements is exactly what I don't want. But I don't see how to avoid having multiple systems with different required procedures overlapping for some time now.
I don't blame anyone in CentOS-land for the breakage - I'm sure it eats some of your time too. But, is there anything that could help automate a transition? Are there tricks buried inside the automated 6x-7x upgrade tool that could be separated out to help build a working-but-parallel 7x system to test before cutting over? How are others dealing with the end of freenx and the inability of x2go to run gnome3? That's 'almost' a uniquely CentOS issue because freenx was so easy on CentOS5/6.
-
Always Learning -
Elvinas Piliponis -
James B. Byrne -
John R Pierce -
Johnny Hughes -
Jonathan Billings -
Les Mikesell -
Valeri Galtsev -
Warren Young