Almost everyone here has probably read this by now. If so, move along, nothing new here. But just in case you haven't, please take the time to read this.
Here it is, in their own words: what Redhat thinks of Centos, and it's plans for the future of Centos.
Can you read between the lines? In this case, it isn't very hard to do, IMHO.
community.redhat.com/centos-faq
On Fri, 2015-04-03 at 20:01 -0500, Francis Gerund wrote:
Here it is, in their own words: what Redhat thinks of Centos, and it's plans for the future of Centos.
community.redhat.com/centos-faq
It is what many of us feared.
I never noticed any of the Centos bosses stating they are on a Centos board dominated by Red Hat employees.
It is a de facto take-over of Centos by Red Hat. Centos Independence has been "sold" to Red Hat by the supposed guardians of Centos.
"The role of the Red Hat Enterprise Linux Developer Program is to provide participants with the tools and resources they need to develop on and for deployment on Red Hat Enterprise Linux; CentOS does not fit into this. .........
".... developing on CentOS does not guarantee that the resulting application will work on Red Hat Enterprise Linux."
So I was 100% correct when I wrote earlier
"Am I mistaken in thinking, after reading recent postings, Centos is slowly moving in a different direction to RHEL and the removal of useful and informative sub-version numbers is merely the first of many manifestations of the growing-gap, or eventual gulf, between "upstream" and Centos ?"
"Will Centos versions eventually become incompatible, partially or wholly, with its parent's RHEL versions ? I can understand why that would be commercially advantageous to RH."
This Centos mailing list, just like the Centos name and logo is the corporate property of Red Hat Inc. How much did Red Hat pay the guardians of the Centos brand to sell-out the whole of Centos to RH ?
I do not know how this previously unpublished commercial take-over of Centos will affect the running of our systems. Hopefully things will continue smoothly for everyone's benefit. Perhaps a Fork will emerge.
I wonder why this take-over was continually denied by Centos bosses at the beginning.
Probably to prevent effective forks, Red Hat will deliberately make it more difficult for the community to compile their sources and produce a workable distribution closely resembling RHEL. One thing is for sure, all the advantages of Centos development will enrich RH whilst Centos will lack all the advantages of RHEL.
That is commercial business folks !
On 03/04/15 09:25 PM, Always Learning wrote:
On Fri, 2015-04-03 at 20:01 -0500, Francis Gerund wrote:
Here it is, in their own words: what Redhat thinks of Centos, and it's plans for the future of Centos.
community.redhat.com/centos-faq
It is what many of us feared.
I never noticed any of the Centos bosses stating they are on a Centos board dominated by Red Hat employees.
It is a de facto take-over of Centos by Red Hat. Centos Independence has been "sold" to Red Hat by the supposed guardians of Centos.
"The role of the Red Hat Enterprise Linux Developer Program is to provide participants with the tools and resources they need to develop on and for deployment on Red Hat Enterprise Linux; CentOS does not fit into this. .........
".... developing on CentOS does not guarantee that the resulting application will work on Red Hat Enterprise Linux."
So I was 100% correct when I wrote earlier
"Am I mistaken in thinking, after reading recent postings, Centos is slowly moving in a different direction to RHEL and the removal of useful and informative sub-version numbers is merely the first of many manifestations of the growing-gap, or eventual gulf, between "upstream" and Centos ?"
"Will Centos versions eventually become incompatible, partially or wholly, with its parent's RHEL versions ? I can understand why that would be commercially advantageous to RH."
This Centos mailing list, just like the Centos name and logo is the corporate property of Red Hat Inc. How much did Red Hat pay the guardians of the Centos brand to sell-out the whole of Centos to RH ?
I do not know how this previously unpublished commercial take-over of Centos will affect the running of our systems. Hopefully things will continue smoothly for everyone's benefit. Perhaps a Fork will emerge.
I wonder why this take-over was continually denied by Centos bosses at the beginning.
Probably to prevent effective forks, Red Hat will deliberately make it more difficult for the community to compile their sources and produce a workable distribution closely resembling RHEL. One thing is for sure, all the advantages of Centos development will enrich RH whilst Centos will lack all the advantages of RHEL.
That is commercial business folks !
If you and others believe this to be the case, then form an organization and fork CentOS. Or, do as CentOS did in the beginning and recompile the RHEL binaries to be binary-compatible and create your own OS.
It is the open-source way, and I am not being sarcastic.
On Fri, 2015-04-03 at 21:30 -0400, Digimer wrote:
If you and others believe this to be the case, then form an organization and fork CentOS. Or, do as CentOS did in the beginning and recompile the RHEL binaries to be binary-compatible and create your own OS.
It is the open-source way, and I am not being sarcastic.
Then call it ROSIE, Red Hat Operating System Intentionally ..... I need a suitable word beginning with 'E' :-)
Well, now everyone knows the future of Centos.
On 03/04/15 09:46 PM, Always Learning wrote:
On Fri, 2015-04-03 at 21:30 -0400, Digimer wrote:
If you and others believe this to be the case, then form an organization and fork CentOS. Or, do as CentOS did in the beginning and recompile the RHEL binaries to be binary-compatible and create your own OS.
It is the open-source way, and I am not being sarcastic.
Then call it ROSIE, Red Hat Operating System Intentionally ..... I need a suitable word beginning with 'E' :-)
Well, now everyone knows the future of Centos.
No, people are speculating about the future of CentOS.
On Fri, 2015-04-03 at 22:47 -0400, Digimer wrote:
No, people are speculating about the future of CentOS.
I agree with your point that if RH is to commercially benefit from Centos installations transferring to (or upgrading to) RH, then the base systems should not be radically different or even incompatible.
The future is certain. To benefit from this free operating system, tolerate the RH control and desire to ensure Centos and RHEL are not exactly the same (including incompatible version numbers) or get another operating system. It is that simple.
Happy Easter to everyone.
On 04/04/15 07:16, Always Learning wrote:
On Fri, 2015-04-03 at 21:30 -0400, Digimer wrote:
If you and others believe this to be the case, then form an organization and fork CentOS. Or, do as CentOS did in the beginning and recompile the RHEL binaries to be binary-compatible and create your own OS.
It is the open-source way, and I am not being sarcastic.
Then call it ROSIE, Red Hat Operating System Intentionally ..... I need a suitable word beginning with 'E' :-)
Well, now everyone knows the future of Centos.
If you guys have that much of a problem with CentOS/RedHat collaboration, why not just move on things like Debian, arch, Suse etc...
On Sat, April 4, 2015 10:12 pm, John R Pierce wrote:
On 4/4/2015 8:10 PM, dE wrote:
If you guys have that much of a problem with CentOS/RedHat collaboration, why not just move on things like Debian, arch, Suse etc...
they just like to whine.
Some did move to other systems (even away from Linux totally; somehow many assume choices are Linux only). You will not hear them here anymore. I recognize them on other systems mail lists often. Some still comment (lightly), but not because all of them (us I might say) like to whine. No, just to provide feedback, which is courtesy actually as we gain nothing (but slaps: "you like to whine!"). Don't get me wrong, significant split of my systems are and stay CentOS ;-)
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Sat, 2015-04-04 at 20:12 -0700, John R Pierce wrote:
On 4/4/2015 8:10 PM, dE wrote:
If you guys have that much of a problem with CentOS/RedHat collaboration, why not just move on things like Debian, arch, Suse etc...
they just like to whine.
If the *whole* truth had been told to the public (i.e. "us") at the first mention of the RH take-over, including the divergence away from RH versions and the RH dominated management board controlling the now Red Hat owned Centos product, then significant qualities of our time and energy could have been more usefully spent on other things.
Reading about C7 problems and systemd, sysctrld etc., I now wish I never threw away (for recycling) my 1990's purchase of a FreeBSD technical manual.
Above all, I want stability in a product. Once I have learned increasing amounts of a product, I am adverse to replacing that knowledge with tomorrow's new versions especially if - for me - those alleged "improvements" offer me no beneficial advantage.
I like C5 and C6 and hope the BSDs systems are similar.
On 03/04/15 09:01 PM, Francis Gerund wrote:
Almost everyone here has probably read this by now. If so, move along, nothing new here. But just in case you haven't, please take the time to read this.
Here it is, in their own words: what Redhat thinks of Centos, and it's plans for the future of Centos.
Can you read between the lines? In this case, it isn't very hard to do, IMHO.
community.redhat.com/centos-faq
How about you elaborate on your theory?
Publicly, and I believe honestly, Red Hat wanted to ensure the long-term health of the CentOS project. Many companies, when starting out, use CentOS because of it's enterprise lineage and free-as-in-beer cost.
Eventually, some of those companies will succeed and grow. Along the line, they will realize the value and ROI of switching to full enterprise support. Being on CentOS, it is then trivial for these companies to switch the RHEL proper.
There is no grand conspiracy here. It is very much in Red Hat's interests to keep CentOS healthy and thriving. Will CentOS change over time? Yes, of course. Every project, company (and people) need to change and adapt, or else they will fade into irrelevance.
On 03/04/15 09:39 PM, Always Learning wrote:
On Fri, 2015-04-03 at 21:27 -0400, Digimer wrote:
Being on CentOS, it is then trivial for these companies to switch the RHEL proper.
Not if Centos and RHEL become too incompatible.
Exactly why I believe it will not come to be.
SIGs/variants may, but CentOS base will stay very close. It would be very stupid of RH to do otherwise.
On 04/04/15 02:40, Digimer wrote:
On 03/04/15 09:39 PM, Always Learning wrote:
On Fri, 2015-04-03 at 21:27 -0400, Digimer wrote:
Being on CentOS, it is then trivial for these companies to switch the RHEL proper.
Not if Centos and RHEL become too incompatible.
Exactly why I believe it will not come to be.
SIGs/variants may, but CentOS base will stay very close. It would be very stupid of RH to do otherwise.
Exactly, the core distro stays where it is - we add layered and enhanced options with low barriers to entry around it.
yum install centos-release-gluster yum install gluster.
makes for a much easier gluster onramp ( or ceph or openafs ).
If you look at the projects we interface with, it will be clear that this is all in the interest of the regular established existing CentOS userbase - eg. ci.centos.org now hosts the integration testing for libvirt upstream ( I suspect most people will agree that libvirt is something we all care about deeply ). Other projects I am working with to have them come test with CentOS are : OpenStack, theforeman, libguestfs, mariadb, postgresql etc ( and we welcome others a well).
Now if you look at the SIGs coming up and delivering content - it should again be pretty clear what sort of content we are facilitating here.
On Sat, 2015-04-04 at 11:10 +0100, Karanbir Singh wrote:
Now if you look at the SIGs coming up and delivering content - it should again be pretty clear what sort of content we are facilitating here.
I think it inevitable that Red Hat will introduce some closed source packages for the its paying customers, and thus hinder parasitic Oracle, whilst continuing the development of the base system. This will probably not affect the majority of 'standard' Centos users.
We have a proven reliable *free* operating system produced by The Centos Team, just as good as RHEL although RH is preventing Centos certifying a comparison. The comparison between RH and Centos versions is gradually being separated, but never-the-less we retain a professional operating system entirely free of licensing costs which satisfies our needs. And, as a bonus, it is not Windoze.
If this had been explained at the beginning of the take-over of an operating system clone by the originating source ('upstream') which desired a de facto 'fork' to protect its commercial interests.
Back to work on RH Centos :-)
On 04/04/2015 07:04 AM, Always Learning wrote:
I think it inevitable that Red Hat will introduce some closed source packages for the its paying customers, ...
For the sake of perspective, even in the old Red Hat Linux boxed sets in 1997 this was true. There was a whole CD of closed source stuff that you got in the boxed set that was never available for download. Things like WordPerfect for Linux, for starters. Sybase ASE was in one of the boxed set's Linux Applications CDs (but I seem to remember it being a 'limited' or 'personal' edition).
Harking back to 1998, here's what is on that CD for Red Hat Linux 5.2: [lowen@dhcp-pool114 Red Hat Vendor Disc Oct 1998]$ ls -1 AIS Applix ARDI CASEMaker CodeForge Crosswinds Decosoft DigitalControls EST Fastlane Flame Herrin HKS InfoSpring JX KAI Knowledge Knox Multisoft NetWin NExS Perforce README REBOL RPMS SAFE Shpink SpectraLogic Stalker SuSE Sybase Take5 TRANS.TBL VariCAD Visual WGS WP [lowen@dhcp-pool114 Red Hat Vendor Disc Oct 1998]$
This is also true for RHEL, and has been for quite a while. There is a whole 'Supplemental' disc that has packages for which there is no source freely available, although the number of packages on that disc is relatively small, most of it being IBM Java for the 7.1 supplemental server disc.
So it is nothing new to have closed source value-add in the Red Hat ecosystem.
100% with Digimer here.
I think there are no conspiracy theories. IMO RedHat does not want nor does it afford to mess up CentOS.
All this energy should be put into contributing towards to the project, testing, helping out community.
Lucian
-- Sent from the Delta quadrant using Borg technology!
Nux! www.nux.ro
----- Original Message -----
From: "Digimer" lists@alteeve.ca To: "CentOS mailing list" centos@centos.org Sent: Saturday, 4 April, 2015 02:27:53 Subject: Re: [CentOS] The future of centos
On 03/04/15 09:01 PM, Francis Gerund wrote:
Almost everyone here has probably read this by now. If so, move along, nothing new here. But just in case you haven't, please take the time to read this.
Here it is, in their own words: what Redhat thinks of Centos, and it's plans for the future of Centos.
Can you read between the lines? In this case, it isn't very hard to do, IMHO.
community.redhat.com/centos-faq
How about you elaborate on your theory?
Publicly, and I believe honestly, Red Hat wanted to ensure the long-term health of the CentOS project. Many companies, when starting out, use CentOS because of it's enterprise lineage and free-as-in-beer cost.
Eventually, some of those companies will succeed and grow. Along the line, they will realize the value and ROI of switching to full enterprise support. Being on CentOS, it is then trivial for these companies to switch the RHEL proper.
There is no grand conspiracy here. It is very much in Red Hat's interests to keep CentOS healthy and thriving. Will CentOS change over time? Yes, of course. Every project, company (and people) need to change and adapt, or else they will fade into irrelevance.
-- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education? _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 04/04/2015 06:12 AM, Nux! wrote:
100% with Digimer here.
I think there are no conspiracy theories. IMO RedHat does not want nor does it afford to mess up CentOS.
All this energy should be put into contributing towards to the project, testing, helping out community.
Lucian
Agreed, and I want to thank you specifically for the nux dextop repo, which is in my standard installed repo set for EL6 and EL7.
In the context of this discussion I would appreciate any feedback the list might have on this article I wrote for my new company.
http://otternetworks.de/tech/rhel-centos-brief/
I for one welcome our Redhat overlords. I think they will provide better governance which should give Centos better credibility as an Enterprise, community supported operating system.
On 4 April 2015 at 17:17, Lamar Owen lowen@pari.edu wrote:
On 04/04/2015 06:12 AM, Nux! wrote:
100% with Digimer here.
I think there are no conspiracy theories. IMO RedHat does not want nor does it afford to mess up CentOS.
All this energy should be put into contributing towards to the project, testing, helping out community.
Lucian
Agreed, and I want to thank you specifically for the nux dextop repo,
which is in my standard installed repo set for EL6 and EL7.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sat, April 4, 2015 11:46 am, Andrew Holway wrote:
In the context of this discussion I would appreciate any feedback the list might have on this article I wrote for my new company.
Once you asked for comments, here it goes:
You are saying: "Currently is appears that there are two strong contenders for a Linux distribution. Ubuntu and Redhat Enterprise Linux/Centos."
You seem to be overlooking Debian. Ubuntu (and many others) at some point were "clones of Debian". One can argue Ubuntu stepped up (or aside) a lot since. Still...
Just MHO.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
You seem to be overlooking Debian. Ubuntu (and many others) at some point were "clones of Debian". One can argue Ubuntu stepped up (or aside) a lot since. Still...
This is very true. Maybe I should say "yum based systems" and "apt based systems" but I did not want to turn it into a technical article. Ill have a think about that.
On Sat, 2015-04-04 at 11:12 +0100, Nux! wrote:
100% with Digimer here.
<snip>
All this energy should be put into contributing towards to the project, testing, helping out community.
Well, I used to agree. But when a bug report filed in December goes untouched entering April, which I don't recall happening prior to RH subsuming the project, it takes away impetus to ever file one again from lowly end users like me I think.
http://bugs.centos.org/view.php?id=7972
Crashes related to 6.6 update involving the way init is done and X is done seem, at least to me, serious enough to have warranted a look-see, at least, if there is still real concern for the (desktop?) community.
Since I don't feel it's my place to tell others how to behave, this (lack of) response has me now looking for alternatives that are (maybe?) more reliable and responsive. Since I've transitioned to a user that just wants a reliable tool now, the 6.6 upgrade soured me big-time. Then having the bug report serve only to grow mold, rather than getting the (apparent) conflict twixt init, X, the (new?) init processes ... looked at is sealing my decision to find a more reliable desktop distribution.
Been UNIX (programming and user) since 1978, Linux since some early Slackware distributions, CentOS since 4.x. Will now be looking for something staying truer to the original UNIX concepts but full-featured and stable - may not be available, but I've got to at least look. You know, something that doesn't bomb on a point release update because (inadequately tested/previewed and unnecessary/useless?) changes were thrown in. Add in the extra instance of Firefox that hogs a 6-core AMD processor (patch provided to the list earlier), stuff X-related running and trying to contact the free desktop org folks w/o any notification (shades of MS!), ... I can't speak for others, but changing much of anything in the init processes and having extra instances of application software started and running without user being ware (when these weren't so common in the past?) seems significant and my thinking would be to save those for better testing, possible RFCs, and major releases.
But I'm not a developer any more and don't expect the rigor I used to apply still works in today's world.
Lucian
<snip>
MHO, in (partial) ignorance, Bill
Well, I used to agree. But when a bug report filed in December goes untouched entering April, which I don't recall happening prior to RH subsuming the project, it takes away impetus to ever file one again from lowly end users like me I think.
It appears that you are the only one to have encountered this bug. Within any project, open source or proprietary; problems are usually prioritized according to the severity of the bug and the number of users that it affects.
On Sat, 2015-04-04 at 19:14 +0200, Andrew Holway wrote:
Well, I used to agree. But when a bug report filed in December goes untouched entering April, which I don't recall happening prior to RH subsuming the project, it takes away impetus to ever file one again from lowly end users like me I think.
It appears that you are the only one to have encountered this bug. Within any project, open source or proprietary; problems are usually prioritized according to the severity of the bug and the number of users that it affects.
Yep. I may be the only one that happens to use this in the way I do. But then I would expect at least a change to closed status with a reason to be given, based on past behavior?
Regardless, if one is given the ability to switch run levels via the use of telinit and the like, shouldn't one be able to rely on it operating properly?
When one takes the time to run multiple tests demonstrating the problem, collect and make available the related files, post with "if more is needed or something wasn't properly reported let me know", wouldn't one deserve at least a look-see and some sort of response or status change? That being in the "contribute to the community" spirit under discussion.
The processes I go through that produced the bad results have been used by me since CentoS4.x, IIRC, and certainly through all of CentOS 5 and 6 prior to 6.6.
BTW, in acknowledgment of the CentOS folks, I realize they try to be 100% compatible with RH, warts and all, so the occurrence of the problem is not really a CentOS group problem, per se, but a RH issue.
Bill
Le 04/04/2015 18:57, Bill Maltby (C4B) a écrit :
Been UNIX (programming and user) since 1978, Linux since some early Slackware distributions, CentOS since 4.x. Will now be looking for something staying truer to the original UNIX concepts but full-featured and stable - may not be available, but I've got to at least look.
I'm using Slackware and CentOS, and I'm happy with both. The former may be just what you are looking for. The bone-headed installer hasn't changed much since the early versions, building software from source is dead easy (without tossing a monkey wrench in the package manager), and everything JustWorks(tm). I have a few production servers and many desktop clients running Slackware, and I'm quite happy with it. I'm using CentOS for stuff that Slackware can't do (FreeIPA, etc.)
Cheers,
Niki
On 2015-04-04, Bill Maltby (C4B) centos4bill@gmail.com wrote:
On Sat, 2015-04-04 at 11:12 +0100, Nux! wrote:
100% with Digimer here. <snip>
All this energy should be put into contributing towards to the project, testing, helping out community.
Well, I used to agree. But when a bug report filed in December goes untouched entering April, which I don't recall happening prior to RH subsuming the project, it takes away impetus to ever file one again from lowly end users like me I think.
Thanks for drawing my attention to that bug. I encountered it the other day after switching from runlevel 5 to 3 (and back again) on a CentOS 6.6 machine.
The purpose of the runlevel switch was to restart gdm. Is there a better way?
On Wed, 2015-04-08 at 10:36 +0000, Liam O'Toole wrote:
On 2015-04-04, Bill Maltby (C4B) centos4bill@gmail.com wrote:
On Sat, 2015-04-04 at 11:12 +0100, Nux! wrote:
100% with Digimer here. <snip>
All this energy should be put into contributing towards to the project, testing, helping out community.
Well, I used to agree. But when a bug report filed in December goes untouched entering April, which I don't recall happening prior to RH subsuming the project, it takes away impetus to ever file one again from lowly end users like me I think.
Thanks for drawing my attention to that bug. I encountered it the other day after switching from runlevel 5 to 3 (and back again) on a CentOS 6.6 machine.
The purpose of the runlevel switch was to restart gdm. Is there a better way?
ISTR an alt-backspace to restart X (been a _long_ time)? Of course with the apparent conflicts in underlying script/config (tries to spawn gettys on tty1-6 expecting X to start on tty7 but X starts on tty1) I don't know if this would work any better.
My work around is a dummy user logged in on the first session (tty1) and use System->Log-out->Switch User from the panel to run real users on second and subsequent sessions for other users (all me). The subsequent sessions will start on tty7.
Nice to know I'm not the only one that tries to use system facilities the way they were intended to work and has problems. Maybe if you touch the bug report so they know I'm not the only one the folks will look and elevate to RH bug just like they used to do? I was surprised that "crash" didn't get any attention.
Bill
On 2015-04-08, Bill Maltby (C4B) centos4bill@gmail.com wrote:
On Wed, 2015-04-08 at 10:36 +0000, Liam O'Toole wrote:
On 2015-04-04, Bill Maltby (C4B) centos4bill@gmail.com wrote:
On Sat, 2015-04-04 at 11:12 +0100, Nux! wrote:
100% with Digimer here. <snip>
All this energy should be put into contributing towards to the project, testing, helping out community.
Well, I used to agree. But when a bug report filed in December goes untouched entering April, which I don't recall happening prior to RH subsuming the project, it takes away impetus to ever file one again from lowly end users like me I think.
Thanks for drawing my attention to that bug. I encountered it the other day after switching from runlevel 5 to 3 (and back again) on a CentOS 6.6 machine.
---SNIP--
Nice to know I'm not the only one that tries to use system facilities the way they were intended to work and has problems. Maybe if you touch the bug report so they know I'm not the only one the folks will look and elevate to RH bug just like they used to do? I was surprised that "crash" didn't get any attention.
Bill
Good idea. I'll go and add to the bug report.
Nice to know I'm not the only one that tries to use system facilities the way they were intended to work and has problems. Maybe if you touch the bug report so they know I'm not the only one the folks will look and elevate to RH bug just like they used to do? I was surprised that "crash" didn't get any attention.
While only vaguely related to this topic, does anyone else find that CentOS6 desktop stability is lacking? Or did we just never notice because no monitoring was in place pre-C6?
I'm refering to abrtd which is sending out a susprising amount of notifications about crashing desktop components like nautilus gthumb gnome-panel gvfsd-trash gvfsd-metadata gnome-settings-daemon, to name just a few.
On Thu, 2015-04-09 at 12:50 +0100, lhecking@users.sourceforge.net wrote:
<snip>
While only vaguely related to this topic, does anyone else find that CentOS6 desktop stability is lacking? Or did we just never notice because no monitoring was in place pre-C6?
I'm refering to abrtd which is sending out a susprising amount of notifications about crashing desktop components like nautilus gthumb gnome-panel gvfsd-trash gvfsd-metadata gnome-settings-daemon, to name just a few.
I've seen this many times, predominately when using ksnapshot to get an image and display it and with nautilus. Gave up trying to get a report via the abort daemon stuff into someplace it might count as I don't have an RH account.
Initially I thought it would improve as folks with subscriptions reported it, but that seems to have not happened.
Fortunately, it's only a minor irritation for me.
<snip>
Bill
On Thu, Apr 09, 2015 at 12:50:41PM +0100, lhecking@users.sourceforge.net wrote:
While only vaguely related to this topic, does anyone else find that CentOS6 desktop stability is lacking? Or did we just never notice because no monitoring was in place pre-C6?
I'm refering to abrtd which is sending out a susprising amount of notifications about crashing desktop components like nautilus gthumb gnome-panel gvfsd-trash gvfsd-metadata gnome-settings-daemon, to name just a few.
I don't see this in our ~1000 RHEL6.6 student workstations we run. Assuming the desktop packages are bug-identical in CentOS, I'd assume to see the same amount of errors.
I suspect you might want to investigate the abrt errors to see if there isn't something amiss in your environment.
On 04/09/2015 06:50 AM, lhecking@users.sourceforge.net wrote:
While only vaguely related to this topic, does anyone else find that CentOS6 desktop stability is lacking? Or did we just never notice because no monitoring was in place pre-C6?
I'm refering to abrtd which is sending out a susprising amount of notifications about crashing desktop components like nautilus gthumb gnome-panel gvfsd-trash gvfsd-metadata gnome-settings-daemon, to name just a few.
The only one I was seeing was pulseaudio crashing in the host whenever I started up a virtual machine. I say "was seeing" because I've since shut off the abrtd service.
The easy way to restart gdm is when you are on the login screen itself or the desktop simply press Ctrl-Alt-Backspace. This works for Upstart in CentOS 6.x but will not work for CentOS 7.x which uses Systemd. The service command does not work for gdm. However, logging out of the desktop will restart gdm. It works for the graphical login exactly like the gettys in a TTY environment.
On 04/08/2015 06:36 AM, Liam O'Toole wrote:
On 2015-04-04, Bill Maltby (C4B) centos4bill@gmail.com wrote:
On Sat, 2015-04-04 at 11:12 +0100, Nux! wrote:
100% with Digimer here. <snip> All this energy should be put into contributing towards to the project, testing, helping out community.
Well, I used to agree. But when a bug report filed in December goes untouched entering April, which I don't recall happening prior to RH subsuming the project, it takes away impetus to ever file one again from lowly end users like me I think.
Thanks for drawing my attention to that bug. I encountered it the other day after switching from runlevel 5 to 3 (and back again) on a CentOS 6.6 machine.
The purpose of the runlevel switch was to restart gdm. Is there a better way?
Am 08.04.2015 um 13:08 schrieb David Both dboth@millennium-technology.com:
The easy way to restart gdm is when you are on the login screen itself or the desktop simply press Ctrl-Alt-Backspace. This works for Upstart in CentOS 6.x but will not work for CentOS 7.x which uses Systemd. The service command does not work for gdm. However, logging out of the desktop will restart gdm. It works for the graphical login exactly like the gettys in a TTY environment.
I remember that this "shortcut" is an X11 server feature (it kills the process!) that can be en/disabled.
-- LF
On 2015-04-08, David Both dboth@millennium-technology.com wrote:
The easy way to restart gdm is when you are on the login screen itself or the desktop simply press Ctrl-Alt-Backspace. This works for Upstart in CentOS 6.x but will not work for CentOS 7.x which uses Systemd. The service command does not work for gdm. However, logging out of the desktop will restart gdm. It works for the graphical login exactly like the gettys in a TTY environment.
Thanks for the suggestion.
Logging out and keying ctrl-alt-backspace both restart X, certainly, but I'm not so sure about gdm. I'm not at a CentOS 6 machine right now so I can't confirm one way or the other.
On 04/08/2015 06:36 AM, Liam O'Toole wrote:
On 2015-04-04, Bill Maltby (C4B) centos4bill@gmail.com wrote:
On Sat, 2015-04-04 at 11:12 +0100, Nux! wrote:
100% with Digimer here. <snip> All this energy should be put into contributing towards to the project, testing, helping out community.
Well, I used to agree. But when a bug report filed in December goes untouched entering April, which I don't recall happening prior to RH subsuming the project, it takes away impetus to ever file one again from lowly end users like me I think.
Thanks for drawing my attention to that bug. I encountered it the other day after switching from runlevel 5 to 3 (and back again) on a CentOS 6.6 machine.
The purpose of the runlevel switch was to restart gdm. Is there a better way?
Am 08.04.2015 um 16:22 schrieb Liam O'Toole liam.p.otoole@gmail.com:
On 2015-04-08, David Both dboth@millennium-technology.com wrote:
The easy way to restart gdm is when you are on the login screen itself or the desktop simply press Ctrl-Alt-Backspace. This works for Upstart in CentOS 6.x but will not work for CentOS 7.x which uses Systemd. The service command does not work for gdm. However, logging out of the desktop will restart gdm. It works for the graphical login exactly like the gettys in a TTY environment.
Thanks for the suggestion.
Logging out and keying ctrl-alt-backspace both restart X, certainly, but I'm not so sure about gdm. I'm not at a CentOS 6 machine right now so I can't confirm one way or the other.
gdm is a "sub-process" of X ...
-- LF
On 2015-04-08, Leon Fauster leonfauster@googlemail.com wrote:
Am 08.04.2015 um 16:22 schrieb Liam O'Toole liam.p.otoole@gmail.com:
On 2015-04-08, David Both dboth@millennium-technology.com wrote:
The easy way to restart gdm is when you are on the login screen itself or the desktop simply press Ctrl-Alt-Backspace. This works for Upstart in CentOS 6.x but will not work for CentOS 7.x which uses Systemd. The service command does not work for gdm. However, logging out of the desktop will restart gdm. It works for the graphical login exactly like the gettys in a TTY environment.
Thanks for the suggestion.
Logging out and keying ctrl-alt-backspace both restart X, certainly, but I'm not so sure about gdm. I'm not at a CentOS 6 machine right now so I can't confirm one way or the other.
gdm is a "sub-process" of X ...
-- LF
Not according to the output of pstree. See the following snippet:
├─gdm-binary─┬─gdm-simple-slav─┬─Xorg │ │ ├─gdm-session-wor─┬─gnome-session─┬─bluetoo+ │ │ │ │ ├─compiz─+ │ │ │ │ │ + │ │ │ │ ├─gdu-not+ │ │ │ │ ├─gnome-p+ │ │ │ │ ├─gpk-upd+ │ │ │ │ ├─nautilu+ │ │ │ │ ├─polkit-+ │ │ │ │ ├─python │ │ │ │ ├─restore+ │ │ │ │ └─{gnome-+ │ │ │ └─{gdm-session-wo} │ │ └─{gdm-simple-sla} │ └─{gdm-binary}
Xorg is in fact a sub-sub-process of gdm-binary.
While logged into a GNOME session, I ran the pgrep command as follows:
$ pgrep -fl gdm 1583 /usr/sbin/gdm-binary -nodaemon 1619 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1 1622 /usr/bin/Xorg :0 -br -verbose -audit 4 -auth /var/run/gdm/auth-for-gdm-EcVz3c/database -nolisten tcp vt1 1801 pam: gdm-password
I restarted X using ctrl-alt-backspace, logged back in and ran the command again:
$ pgrep -fl gdm 1583 /usr/sbin/gdm-binary -nodaemon 1619 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1 1622 /usr/bin/Xorg :0 -br -verbose -audit 4 -auth /var/run/gdm/auth-for-gdm-EcVz3c/database -nolisten tcp vt1 1801 pam: gdm-password
X has indeed restarted, but the gdm-related processes have not.
On 2015-04-08, Liam O'Toole liam.p.otoole@gmail.com wrote:
On 2015-04-08, Leon Fauster leonfauster@googlemail.com wrote:
Am 08.04.2015 um 16:22 schrieb Liam O'Toole liam.p.otoole@gmail.com:
On 2015-04-08, David Both dboth@millennium-technology.com wrote:
The easy way to restart gdm is when you are on the login screen itself or the desktop simply press Ctrl-Alt-Backspace. This works for Upstart in CentOS 6.x but will not work for CentOS 7.x which uses Systemd. The service command does not work for gdm. However, logging out of the desktop will restart gdm. It works for the graphical login exactly like the gettys in a TTY environment.
Thanks for the suggestion.
Logging out and keying ctrl-alt-backspace both restart X, certainly, but I'm not so sure about gdm. I'm not at a CentOS 6 machine right now so I can't confirm one way or the other.
gdm is a "sub-process" of X ...
-- LF
Not according to the output of pstree. See the following snippet:
├─gdm-binary─┬─gdm-simple-slav─┬─Xorg │ │ ├─gdm-session-wor─┬─gnome-session─┬─bluetoo+ │ │ │ │ ├─compiz─+ │ │ │ │ │ + │ │ │ │ ├─gdu-not+ │ │ │ │ ├─gnome-p+ │ │ │ │ ├─gpk-upd+ │ │ │ │ ├─nautilu+ │ │ │ │ ├─polkit-+ │ │ │ │ ├─python │ │ │ │ ├─restore+ │ │ │ │ └─{gnome-+ │ │ │ └─{gdm-session-wo} │ │ └─{gdm-simple-sla} │ └─{gdm-binary}Xorg is in fact a sub-sub-process of gdm-binary.
While logged into a GNOME session, I ran the pgrep command as follows:
$ pgrep -fl gdm 1583 /usr/sbin/gdm-binary -nodaemon 1619 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1 1622 /usr/bin/Xorg :0 -br -verbose -audit 4 -auth /var/run/gdm/auth-for-gdm-EcVz3c/database -nolisten tcp vt1 1801 pam: gdm-password
I restarted X using ctrl-alt-backspace, logged back in and ran the command again:
$ pgrep -fl gdm 1583 /usr/sbin/gdm-binary -nodaemon 1619 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1 1622 /usr/bin/Xorg :0 -br -verbose -audit 4 -auth /var/run/gdm/auth-for-gdm-EcVz3c/database -nolisten tcp vt1 1801 pam: gdm-password
X has indeed restarted, but the gdm-related processes have not.
As a follow-up, running the command 'initctl restart prefdm' as suggested by Johnathan did the trick:
$ pgrep -fl gdm 5728 /usr/sbin/gdm-binary -nodaemon 5744 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1 5747 /usr/bin/Xorg :0 -br -verbose -audit 4 -auth /var/run/gdm/auth-for-gdm-QmU6b6/database -nolisten tcp vt1 5804 pam: gdm-password
On Wed, Apr 08, 2015 at 07:16:48PM +0000, Liam O'Toole wrote:
Xorg is in fact a sub-sub-process of gdm-binary.
Yup. In fact, it's possible to run GDM without X at all, such as when you're running display manager with XDMCP.
Am 08.04.2015 um 21:16 schrieb Liam O'Toole liam.p.otoole@gmail.com:
On 2015-04-08, Leon Fauster leonfauster@googlemail.com wrote:
gdm is a "sub-process" of X ...
Not according to the output of pstree. See the following snippet:
oh, i had something in mind that obviously is obsolete, okay :-)
-- LF
On Wed, Apr 08, 2015 at 10:36:05AM +0000, Liam O'Toole wrote:
Thanks for drawing my attention to that bug. I encountered it the other day after switching from runlevel 5 to 3 (and back again) on a CentOS 6.6 machine.
The purpose of the runlevel switch was to restart gdm. Is there a better way?
Since CentOS 6 uses Upstart as its init system, and GDM is run from an Upstart service (and not a SysV init script), you can use the upstart tools to restart GDM. It's actually run from the 'prefdm' service (because it could also run kdm or xdm).
# initctl restart prefdm prefdm start/running, process 29141
On 2015-04-08, Jonathan Billings billings@negate.org wrote:
On Wed, Apr 08, 2015 at 10:36:05AM +0000, Liam O'Toole wrote:
Thanks for drawing my attention to that bug. I encountered it the other day after switching from runlevel 5 to 3 (and back again) on a CentOS 6.6 machine.
The purpose of the runlevel switch was to restart gdm. Is there a better way?
Since CentOS 6 uses Upstart as its init system, and GDM is run from an Upstart service (and not a SysV init script), you can use the upstart tools to restart GDM. It's actually run from the 'prefdm' service (because it could also run kdm or xdm).
# initctl restart prefdm prefdm start/running, process 29141
That did the trick. Thank you.
Le 04/04/2015 03:01, Francis Gerund a écrit :
Almost everyone here has probably read this by now. If so, move along, nothing new here. But just in case you haven't, please take the time to read this.
Here it is, in their own words: what Redhat thinks of Centos, and it's plans for the future of Centos.
Can you read between the lines? In this case, it isn't very hard to do, IMHO.
community.redhat.com/centos-faq
Yes, I already read this last June, when RedHat announced they had recruited CentOS main developpers. I don't see anything new here, or at least no change since this time. So, nothing new concerning the future of CentOS.
Could you elaborate what you read between the lines there ?
Alain
2015-04-04 4:01 GMT+03:00 Francis Gerund ranrund@gmail.com:
Almost everyone here has probably read this by now. If so, move along, nothing new here. But just in case you haven't, please take the time to read this.
Here it is, in their own words: what Redhat thinks of Centos, and it's plans for the future of Centos.
Can you read between the lines? In this case, it isn't very hard to do, IMHO.
If this is a problem, just pick another RHEL clone like Scientific Linux ?
-- Eero
On Sun, 2015-04-05 at 21:27 +0300, Eero Volotinen wrote:
If this is a problem, just pick another RHEL clone like Scientific Linux ?
I thought I read on this List the intention of Scientific to base its future distribution on Red Hat's Centos product.
-
Alain Péan -
Always Learning -
Andrew Holway -
Bill Maltby (C4B) -
David Both -
dE -
Digimer -
Eero Volotinen -
Francis Gerund -
John R Pierce -
Jonathan Billings -
Karanbir Singh -
Lamar Owen -
Leon Fauster -
lhecking＠users.sourceforge.net -
Liam O'Toole -
Niki Kovacs -
Nux! -
Robert Nichols -
Valeri Galtsev