What's in a (CentOS) version number?
The relationship between CentOS and Red Hat has always been interesting. Red Hat provides the source packages that, after removal of branding elements, are built into the CentOS release. By one measure, CentOS is sustaining freeloaders who want to benefit from Red Hat's work without paying for it. By another, CentOS helps Red Hat by bringing users into its ecosystem; some of those users eventually become paying Red Hat customers. So it is not surprising that users can see the recent acquisition of CentOS by Red Hat in two different lights: it's either an attempt to squash a competing distribution or an effort to sustain that distribution with much-needed support.
Either way, changes were always going to happen after the acquisition. CentOS users will certainly be happy about the first of those changes: support for CentOS developers so they can work on the distribution full time, and support for the infrastructure needed to keep CentOS going. But when CentOS project leader Karanbir Singh proposed a change to the seemingly trivial issue of version numbers, users were quick to express their disapproval.
Traditionally, CentOS releases have used the same version number as the RHEL release they are based on; CentOS 6.5 is a rebuild of the RHEL 6.5 release, for example. The CentOS developers now want to change to a scheme where the major number matches the RHEL major number, but the minor number is generated from the release date. So, if the CentOS version of RHEL 7.0 were to come out in July 2014, it might have a version number like 7.1407. Derivative releases from CentOS special interest groups (SIGs) would have an additional, SIG-specific tag appended to that number.
To the CentOS developers, this change offers a number of advantages. The close tie with RHEL version numbers, it is claimed, can confuse users into believing that a release is supported with security updates when it is not; see this detailed message from Johnny Hughes for an explanation of the reasoning there. Putting the release date into the version number makes the age of a release immediately obvious, presumably inspiring users to upgrade to current releases. This scheme would also make it easier to create releases that are not directly tied to RHEL releases; that is something that the SIGs, in particular, would like to be able to do.
Supporting the SIGs is a big part of the project's plan for the future in general. Karsten Wade described it this way:
So it seems that CentOS wants to follow Red Hat into the cloud. Simply providing a rebuild of RHEL is not as exciting as it once was, so the project wants to expand into other areas where, it is hoped, more users are to be found.
It should be possible to expand in this way as long as the core CentOS distribution remains what it has always been. Unfortunately, some users are worried that things will not be that way. Ljubomir Ljubojevic, the maintainer of the CentOS Facebook page, described his feelings about the change:
A large number of "me too" posts made it clear that Ljubomir is not alone in feeling this way. There is a lot of concern that the project might break the core distribution and that adopting a new version numbering scheme looks like a first step in that direction.
For their part, the CentOS developers have tried to address that concern. Karanbir stated directly that there is no plan to change how the core distribution is managed:
For the most part, the users in the discussion seemed to accept that promise, but that made them no happier about the version numbering change. The date-based numbers, they say, make it harder to know which version of RHEL a CentOS release is based on, and it can make it harder to justify installations (or upgrades) to management. All told, it was hard to find a single supportive voice for this change outside of the CentOS core developers.
Those developers have not said anything about what changes, if any, they
might make to their plans in response to the opposition on the list. They
are in a bit of a difficult position: they want to make changes aimed at
attracting a broader set of users, but those changes appear threatening to
their existing users, most of whom are quite happy with the distribution as
it is now and are not asking for anything different. If the existing users
start to
feel that their concerns are not being heard, they may start to look for
alternatives. In this case, the powers that be at CentOS may want to make
a show of listening to those users and finding a way to resolve their
version number concerns that doesn't appear to break the strong connection
between RHEL and CentOS releases.
Posted Jun 11, 2014 14:56 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (5 responses)
Posted Jun 11, 2014 15:13 UTC (Wed)
by Tara_Li (guest, #26706)
[Link] (2 responses)
Posted Jun 11, 2014 15:40 UTC (Wed)
by salimma (subscriber, #34460)
[Link]
Posted Jun 12, 2014 20:42 UTC (Thu)
by tjc (guest, #137)
[Link]
Posted Jun 11, 2014 16:21 UTC (Wed)
by drag (guest, #31333)
[Link]
This. People treat Redhat 6.3 as a separate OS from Redhat 6.4 in their organizations. It takes time to test and make sure version releases are going to work well and it always involves a incremental roll out.
If we have to make configuration files for out tools to create mappings between CentOS and Redhat versions then it's going to be a huge PITA. It's much simpler using Mathstuf's scheme.
Posted Jun 12, 2014 22:17 UTC (Thu)
by mattrose (guest, #19610)
[Link]
Having said that, I've been on the CentOS-devel list for about 5 years, and the past few months have been really encouraging, and productive. KB and the gang have really open-ed up their build, QA, and development processes, and patches and improvements have started to trickle into the list now.
Posted Jun 11, 2014 15:27 UTC (Wed)
by Baylink (guest, #755)
[Link] (3 responses)
And, by the only measure that *matters*: Red Hat *would not exist* had it not had the shoulders of giants to stand on, for free. So for all the labor that Red Hat has admittedly added to the Linux ecosystem, I remain somewhat jaded about any complaints it may have about CentOS.
And don't even get me started about their enabling of systemd.
Posted Jun 11, 2014 15:41 UTC (Wed)
by salimma (subscriber, #34460)
[Link]
Posted Jun 11, 2014 15:49 UTC (Wed)
by misc (subscriber, #73730)
[Link]
Posted Jun 11, 2014 18:51 UTC (Wed)
by Fats (guest, #14882)
[Link]
And Linux would not stand as high today as an OS without Red Hat.
Posted Jun 11, 2014 16:20 UTC (Wed)
by lkundrak (subscriber, #43452)
[Link]
There still are users out there for which providing a compatible rebuild of RHEL certainly is "as exciting as it once was".
Posted Jun 11, 2014 18:28 UTC (Wed)
by einstein (guest, #2052)
[Link] (11 responses)
Surely they can find some way to retain the compatible version string, while adding their own a Centos-specific addendum, as is done e.g. with the SUSE-supported RHEL variant.
Posted Jun 11, 2014 19:23 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (7 responses)
And then, I hope, root goes to the vendor and complains.
Posted Jun 11, 2014 19:52 UTC (Wed)
by khim (subscriber, #9252)
[Link] (6 responses)
Which leads to withdrawl of support because vendor only supports RHEL (and may be SLES). Good idea. Not.
Posted Jun 11, 2014 23:26 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link] (5 responses)
Or in other words.. just be very glad the installer devs were as lazy as they were in tasting the OS flavor, instead of actually validating the OS flavor.
-jef
Posted Jun 13, 2014 9:48 UTC (Fri)
by jubal (subscriber, #67202)
[Link]
Posted Jun 13, 2014 11:57 UTC (Fri)
by dag- (guest, #30207)
[Link] (3 responses)
Why would CentOS risk breaking 3rd party software for a questionable change in version numbering ?
Posted Jun 13, 2014 16:30 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
My personal opinion is that /etc/redhat-release should become an actual file instead of a symlink to centos-release, and /etc/redhat-release should be as compatible as the 3rd party ISV channel needs it to be to taste for RHEL binary compatibility. And then CentOS can do the more elaborate project naming stuff in /etc/centos-release.
There's no standing requirement that the files be the same content. It's just an historic anomaly because well 3rd party vendors starting hardcoding /etc/redhat-release as an important thing to taste so its become a defacto standard location to test OS version. Which if you think about it.. sucks..a filesystem with a vendor name in the filename to hold a string to tell you what vendor and version your system actually is. Its just..wrong. But we live with it.
For CentOS specifically, if the project still desires to be a binary compatible rebuild of RHEL, having /etc/redhat-release report the RHEL compatibility versioning that ISV installers expect, and /etc/centos-release supplying CentOS project specific versioning to aid local admins and contributors building content for the CentOS layercake...probably satisfies enough constraints to be a usable approach.
-jef
Posted Jun 14, 2014 11:07 UTC (Sat)
by khim (subscriber, #9252)
[Link] (1 responses)
Why do you think 3rd party vendors suppport RHEL (and, sometimes, SLES) exclusively? Because they hate developers of all other distributions? Nope. They only support RHEL to save on support costs. As long as you don't explicitly say that you are using not RHEL but something else they could pretend that they don't know about that fact and will continue to support you. Actually even if you'll say that you use CentOS they will not stop supporting you right away. More likely you'll hear something like “we don't support CentOS, try to reproduce on RHEL”. But if you'll show that package works on RHEL just fine but will continue to insist that they should “fix” to also support CentOS… what could they do? Eventually they will be forced to actually cite the piece of contract which lists supported distributions and cancel you support. Note: if you think that they will go and fix their package because “it's so very easy” then you are wrong. In most cases bug will not be even shown to developers before it could be reproduced on RHEL! That's the whole point after all. It's possible that some developer will receive a world from his (or her) friends and will fix the package in question to be CentOS-compatible, but don't count on it as a rule. CentOS is tolerated till support of RHEL-conpatible packages is done by CentOS developers, if people will insist on theating it as anything but full RHEL clone it'll quickly lose even that thin “you don't say I don't hear” support it has. P.S. And yes, separate
Posted Jun 19, 2014 12:34 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
On top of the reasons you're giving, note that it's not unknown for the 3rd party vendor to want to be able to punt problems in their dependencies back up to the enterprise Linux vendor. You may simply get an answer of "RHEL ticket opened - we'll push them on a fix, but you need to tell your support contact that you need the fix for #abcdefg ASAP."
Posted Jun 12, 2014 23:11 UTC (Thu)
by pjtait (subscriber, #17475)
[Link] (2 responses)
Posted Jun 13, 2014 0:45 UTC (Fri)
by raven667 (subscriber, #5198)
[Link]
Posted Jun 13, 2014 4:25 UTC (Fri)
by einstein (guest, #2052)
[Link]
I did notice that once you registered the RHEL servers with the SMT, it changed some packages including /etc/redhat-release, but as far as we could tell the OS worked just like the officially supported RHEL.
Posted Jun 11, 2014 23:30 UTC (Wed)
by johannbg (guest, #65743)
[Link] (23 responses)
Now people can just patiently watch slowly but surely as CentOS sole purpose of existence as in it being an distribution that is 100% binary compatibility with its upstream source Red Hat with the same lifecycle, is gradually being deluded,altered,changed, it's lifecycle it's direction as Red Hat polices, dictates and dominates it's direction as it does with Fedora while squeezing every ounce of it's community and it's spirit while doing so.
Let's just hope that Scientific Linux and it's community does not follow the same futile path..
Posted Jun 12, 2014 0:02 UTC (Thu)
by jspaleta (subscriber, #50639)
[Link] (9 responses)
I was off the grid for much of January so I probably missed such the discussion as it happened as a reaction to the brand acquisition announcement. And my mailing list archive data dive isn't coming up with a salient thread dated within the last year. So if you could provide me with a best effort starting point to go back and read over the public discussion on the idea of moving the repo across brand boundaries, I'd appreciate it.
-jef
Posted Jun 12, 2014 0:32 UTC (Thu)
by johannbg (guest, #65743)
[Link] (8 responses)
But I might have never filed that ticket based on response from those ultimately responsible for making that decision on infra, board and here on lwn, facebook and elsewhere.
Has the CentOS community been granted access to Red Hat's build system ( which basically is the same thing) If the answer to that is no then you have your answer to epel anyway...
Posted Jun 12, 2014 0:41 UTC (Thu)
by jspaleta (subscriber, #50639)
[Link] (6 responses)
As far as you know...there isn't a public discussion about the idea, outside of your comments here on lwn. I easily found your proposal for the idea in an lwn thread from January. But so far I can't find a public record discussion where anyone has brought this idea forward, even as a rough outline as something for the CentOS community to be interested in taking on as part the CentOS branded deliverables.
Seems likes that an important part of laying the ground work for any transition. Just dumping EPEL on the CentOS community if they aren't ready and willing to take it on is a bad idea..regardless of how good an idea moving EPEL over. CentOS has to show a desire to take it, or its just going to be an unwanted burden.
-jef
Posted Jun 12, 2014 1:08 UTC (Thu)
by johannbg (guest, #65743)
[Link] (5 responses)
However interesting perspective hinting that the CentOS community would not be ready and willing to take it on since by my calculation it would it would be the wisest move since it would among other things strengthen it's community significantly without weakening Fedora which would certainly not happen now since Red Hat is pushing the CentOS community into copy pasting what Fedora does so it would be interesting to hear from someone from within the CentOS community if the community would be against that and or is incapable of doing that, which should answer that, those contemplation's.
In anycase at the time of those discussion it was clear that there where other forces than the CentOS community itself, keeping it from being moved.
Posted Jun 12, 2014 17:45 UTC (Thu)
by jspaleta (subscriber, #50639)
[Link] (4 responses)
So no discussion on fedora-devel, where I would expect this to pop up for a fist fight. no discussion on fedora infra list afaict, nothing on epel-devel.
What I have found is a pretty long discussion on centos-devel from Feb which goes into some of the sticky details of how CentOS wants to use a SIG approach such that currently conflicting addon repositories (which EPEL is but one of several) can live inside CentOS SIGscape. It is far from clear from that discussion that CentOS is structurally ready to subsume EPEL content as a preferred addon repository. Especially when EPEL and CentOS Extras still conflict with each other.
The EPEL specific discussion basically peters out on the note that the discussion between CentOS and Fedora concerning the future of EPEL needs to happen "at some point in the future"
http://lists.centos.org/pipermail/centos-devel/2014-Febru...
That's where it stands. No dark conspiracy theories, just head-scratching over how to align processes and to get to a point where existing conflicting content can be merged with as little heartburn as possible. You seem to be suggesting that EPEL just be rammed into CentOS regardless of the fact the CentOS Extras conflicts with EPEL. That would be an unwise and insensitive coarse of action.
Look man here's the deal...
EPEL takes care and feeding, not unlike a beloved family pet. You don't just hand a dog over to your relative going... "I have calculated that you totally should be the one taking care of this dog instead of me or my immediate family. Like it totally suits your lifestyle better than mine....here.... no givesies-backsies." You don't do crap like that unless you hate your dog and you hate your extended family. A compassionate human being would make some effort to feel out the potential new owner and make them a stakeholder in the continued well being of the animal in question instead of just dropping the animal off on their door step before they have consented to be the new owner. Only an unfeeling skynet automaton sent from the future to destroy mankind would lack the necessary empathy to miscalculate the situation so badly.
And really, it seems to me CentOS is already trying to work out the details as to how they want to take advantage of having access to RH infrastructure and support. It appears to me CentOS does want to incorporate much of the functionality of the external repository space that has grown up outside of CentOS... and that's not just EPEL..several other repos are named in the discussion I cite.. under the SIG approach instead of trying to cram it all into the existing CentOS Extras repo.
Providing "just" EPEL which conflicts with other external repos seems to be a non-goal. CentOS doesn't just want to take care of EPEL, Fedora's family dog. CentOS wants to construct a dog yard to house a dog team, a team meant to harnessed together towards some goal. This may not be what you personal want to see, but its what CentOS seems to be working towards. The content now living in EPEL will most likely play a role in that new structure. But, I suspect EPEL itself may simply stop existing as a distinct thing once CentOS has an established onramp into its layered SIGscape of content, if the new onramp leverages enough of existing build infrastructure that Fedora contributors are use to working with.
-jef
Posted Jun 12, 2014 19:36 UTC (Thu)
by johannbg (guest, #65743)
[Link] (3 responses)
Posted Jun 12, 2014 20:21 UTC (Thu)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
I'm not even disagreeing with the soundness of the idea. History is full of examples of very intelligent people coming up with very good ideas but not having the skills or the interest necessary organize or influence the correct group of people to work to make it happen. Thankfully you didn't go so far as to file a detailed business method patent as part of your thorough calculation when doing the Pro bono benefit analysis on behalf of the CentOS community. Thank you for showing that much restraint, so as to not be an insurmountable hurdle for others to implement a similar idea months later, when they finally get around to catching up with you.
I believe the phrase is "an idea ahead of its time".. which again is exactly the sort of thing I would expect to see proposed again and again from a skynet android sent from the future. But what do I know, I'm just a self-aware AI from the matrix.
Credit where credit is due, you came up with the idea as far as I can tell. Good for you. I will think about spinning up a fedora badge to honor such impressive prescient thinking moving forward. It's really is an oversight that such effort goes completely unrewarded. Never again.
The only thing I find moderately distasteful is this propensity to jump to conspiracy theories and implication of some sort of behind the scenes strong arming of motivation because other people are moving at a more deliberate speed in implementing a more nuanced plan of action on a timescale slower than you would like to see.
The issue isn't just about where EPEL lives, that's just a part of the question. The issue really is how does CentOS get structured such that CentOS can build a contributor space which is attractive enough to drain as much of the swamp of overlapping/conflicting addon repositories as possible and make it easier to give users the layer cake they seem to want in practice.
Ironically pushing for an EPEL centric merger quickly, as you have proposed here in LWN in January, and seem to still be a proponent of now, smacks as exactly the sort of heavy handed corporate interest interactions that you'd rather not see. It's only because you thought of it that you want to see it done in a rush, without building stakeholder buy-in from inside the CentOS community itself.
Personally, I'm really much happier to see CentOS think about what they want to achieve with expanded resource support from shadowdaddy, without that discussion being dominated by insistent calls to rush EPEL under the CentOS banner. At the end of the process CentOS might come up with a structure where both EPEL and CentOS Extras as they exists today just do not map coherently and will disappear as recognizable distinct things inside the CentOS branded binary content space. Which is where I think they are headed with their variants idea.
-jef
Posted Jun 12, 2014 21:01 UTC (Thu)
by johannbg (guest, #65743)
[Link] (1 responses)
Now this was not "an idea ahead of its time" from my point of view since I have always failed to see the purpose of EPEL being a part of Fedora in the first place and never been silent about that point of view of mine since it's sole existence is to overcome limitation in RHEL dont get me wrong I can see the convenience in it for people maintaining components both in Fedora and EPEL and the gain Red Hat has from it,
It's the same view I share with the "Software Collection" that Red Hat manage to push into the Fedora project to overcome limitation that did not exist in the project to begin with from my perspective.
Now my so called conspiracy theories is just based on responses I received from Red Hat employees as well as community members when mentioning this possible future for EPEL in various places.
Anyway less about me more about EPEL where I have to agree with you on the point where distributions like CentOS was and Scientific Linux still is, that arguably there should never have existed nor should exist in the future the distinction of community maintained components from their src rebuilds.
Posted Jun 12, 2014 21:45 UTC (Thu)
by jspaleta (subscriber, #50639)
[Link]
It's difficult to judge the conclusions you are drawing without some modicum of public record from which to read for myself. I'm disinclined to believe you without at least one public record conversation to review. So please, if you are going to refer to conversations with red hat employees, please provide the public record citation to them so I can verify they happened and the things you said were said were said.
Protip, if you are going to make it a habit of talking trash about policy decisions happening across a corporate fenceline, you really need to make sure your conversations with key people you are in disagreement with are happen in the public record as much as possible. If you are going out of your way to have...disagreements..in private conversations.. and then taking those disagreements into public forums (like here), that's a bit uncool and doesn't really help substantiate your policy argument or grow wider support for your opinion (even if you have the better reasoning).
It's generally not a good idea to reference private conversations, unless of course, your goal is to just besmirch reputations and you really don't care about seeing policy decisions changed.
That's not your goal right? You are still trying to have a positive impact on policy direction right? Contrary to your last statement that you believe that as individuals you and I are both powerless to have a positive influence, right? That was just silly talk. Of course you are still endeavoring to have a positive influence, your just doing it wrong, terribly terribly wrong. That previous statement was just your defensive cynicism talking earlier as a batter you with my indomitable rhetoric. Sorry about that. And we all now inside every cynic there's just a disappointed idealist underneath. But once we surgically remove your idealism and replace it with synthetic lab grown pragmatism, you'll be feel much better about everything.
-jef
Posted Jun 12, 2014 4:25 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link]
Posted Jun 12, 2014 0:06 UTC (Thu)
by andresfreund (subscriber, #69562)
[Link] (11 responses)
Posted Jun 12, 2014 0:40 UTC (Thu)
by johannbg (guest, #65743)
[Link] (6 responses)
Either way the outcome for you is the same so prepare yourself to get used to it until it does...
Posted Jun 12, 2014 6:46 UTC (Thu)
by amacater (subscriber, #790)
[Link] (5 responses)
This is becoming worse not better and is has its roots in the way that Red Hat Enterprise Linux and Fedora were split all those years ago. Fedora was left as a rump, feeding the commercial product line but at several removes - but Red Hat had to release sources so the copycat distributions followed.
Pink Tie, White Hat and others were either shut down by legal action or by the weight of managing a distribution build on too few shoulders. CentOS and Scientific remained as the only two successful clones. CentOS was alternately disparaged / recommended as the way to learn proper, paid for supported Red Hat (but without support) and Fedora was for very committed bleeding edge enthusiasts, for Red Hat to cherry pick and for no support ever. Scientific just ticked over.
Now Red Hat has a huge legacy support burden of installed Linux on its hands 4,5,6 still in support, 7 just released and is now pushing cloud, SAAS, PAAS, Docker, Openhatch ...
Meanwhile, CentOS and Fedora now occupy the same space and CentOS is being made deliberately incompatible with RHEL as the days and months go by. The people who may have built a business on CentOS now have nothing and Fedora have a new adoptive sibling in their space, competing for their toys and their parents' money.
Red Hat should make some decisions - pure Linux distribution or Linux-based services in cloud / independent existence at the head of a vibrant Linux community or only as a more anonymous part of the big consortia (think Fujitsu / HP / Oracle). Sadly, Red Hat hasn't had ordinary users since Red Hat 9 ten years ago - it's had corporate paid for customers and "freeloaders" and customers on its certification courses.
If I were advising someone to build a heavyweight Linux based business today, I couldn't recommend Red Hat (or SUSE) and Ubuntu also seems slightly too widely focussed - is it that commercial Linux has had its day?
Posted Jun 12, 2014 12:52 UTC (Thu)
by ovitters (guest, #27950)
[Link]
That's not a burden, that is their main product. Stable versions supported for a very long time. You see doom and gloom, while Red Hat saw it (ages ago) as an opportunity to make loads of money :-P
Posted Jun 12, 2014 13:42 UTC (Thu)
by NRArnot (subscriber, #3033)
[Link] (3 responses)
Unlike CentOS, Scientific Linux did not set out to be bug for bug compatible, but so far there has been very little divergence between RHEL and SL. It will be very interesting to see where they go with Scientific Linux 7.
Posted Jun 12, 2014 14:09 UTC (Thu)
by smoogen (subscriber, #97)
[Link]
Posted Jun 12, 2014 16:45 UTC (Thu)
by ewan (guest, #5533)
[Link] (1 responses)
Posted Jun 12, 2014 17:23 UTC (Thu)
by amacater (subscriber, #790)
[Link]
I knew also that there was discussion about SL becoming a CentOS SIG. That would be good and useful so long as it doesn't impact the level of support SL currently provide.
The rationale behind starting SL does make sense - I can't see anyone paying for 10,000+ servers and the servers needed to run an additional PB of storage each and every month for the LHC :)
Posted Jun 12, 2014 17:33 UTC (Thu)
by NightMonkey (subscriber, #23051)
[Link] (3 responses)
Posted Jun 12, 2014 18:12 UTC (Thu)
by andresfreund (subscriber, #69562)
[Link]
Posted Jun 13, 2014 8:15 UTC (Fri)
by ovitters (guest, #27950)
[Link] (1 responses)
Lastly, "babe", wtf?
Posted Jun 13, 2014 9:49 UTC (Fri)
by andresfreund (subscriber, #69562)
[Link]
I felt so enthralled by the diminutive that I've since privately asked for a date.
Posted Jun 18, 2014 23:18 UTC (Wed)
by hughesjr (guest, #29949)
[Link]
Just as important is the Authentication structure used and the VAST majority of EPEL maintainers also maintain the SAME package in Fedora. Since they are already maintaining more than one version of that package inside Fedora already it is significantly easier to just add one more RPM within the Fedora infrastructure than do it at a completely separate place with separate logins, etc. SO most of the maintainers want to stay right where they are.
Not only that, BUT CentOS has no mass community builder yet as it is currently being developed ... and EPEL is up and running in Fedora land right now.
So this idea has been discussed and it has merit .. but it is not something we need to do right now. It might happen in the future or it might stay the same. That's the thing about community projects.
Posted Jun 12, 2014 13:39 UTC (Thu)
by Tet (guest, #5433)
[Link]
Posted Jun 19, 2014 19:43 UTC (Thu)
by jb.1234abcd (guest, #95827)
[Link] (4 responses)
CentOS legalese
Crippleware: Is Red Hat Rewriting the GPL and the Future of Open Source?
Posted Jun 20, 2014 10:40 UTC (Fri)
by LightDot (guest, #73140)
[Link] (3 responses)
For starters, one should refer to https://www.centos.org/legal/trademarks/ and if there is still any need for further clarifications, post on the appropriate mailing lists.
BTW, is the short term rise in visitor traffic really worth it? Where's the dignity in doing this "blog" stunts?
Posted Jun 20, 2014 10:46 UTC (Fri)
by LightDot (guest, #73140)
[Link] (2 responses)
Hm. Freud would probably say that I actually expect people to be hyped... :)
Posted Jun 22, 2014 11:23 UTC (Sun)
by jb.1234abcd (guest, #95827)
[Link] (1 responses)
Posted Jul 6, 2014 20:04 UTC (Sun)
by LightDot (guest, #73140)
[Link]
Instead, I would categorize this simply as "being slightly disgusted by the bottom feeders". Hyped is a overhyped word anyway.
Posted Jul 2, 2014 20:23 UTC (Wed)
by invain (guest, #97711)
[Link]
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
And then, I hope, root goes to the vendor and complains.
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
redhat-release and centos-release look like a best solution to me.What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
you don't drop a new work load on a volunteer staffed community just because you have _calculated_ its the best idea ever in the history of ideas.
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
There's enough real discussion to be had instead of the same back and forth.
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
So, have your favorite Kool-Aid and follow an "alternative universe".
http://lists.centos.org/pipermail/centos/2014-February/14...
http://nerdvittles.com/?p=8888
Has anybody from RH officially answered the questions raised here ?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
What's in a (CentOS) version number?
post :-)
What's in a (CentOS) version number?
What's in a (CentOS) version number?