On Wed, December 9, 2015 16:50, James Hogarth wrote:
On 9 Dec 2015 9:07 p.m., "Lamar Owen" lowen@pari.edu wrote:
No, it seems to me that a suitably motivated CentOS user needs to scratch this itch; and, no, I am not volunteering, as I've followed Fedora before......and just simply cannot give the time to it at this point in time in my life.
<snip>
So who wants to be the CentOS-Users to Fedora liaison, likely to be one of the most thankless jobs on the planet?
I'm an active Fedora packager and yet I dare say Mark would hate me as liaison for I find the changes in EL7 most refreshing and look forward to bring able to make better use of them in due course ;)
But I really do question whether someone in this industry is really not able to spend 30 minutes or so every six months checking changes for anything interesting.
And frankly if one isn't willing to get either get a subscription and feedback as a paying customer or to get involved with the upstream sources then no one does not have say in direction and one shouldn't be surprised by that.
If it was a democracy with a vote on every possible choice then we'd never get anywhere given the time to carry out such a survey and the vast differences in opinions.
No, as the Debian folks say it is a meritocracy instead and those who get stuck in and actively discuss at the right time provide the influence on what happens next.
Since the import of what I was trying to convey has been lost, no doubt due to my poor choice of words, I will restate the obvious: If the bulk of the developers working on Fedora use laptops as their platform then, inevitably, Fedora will become in essence a laptop distribution and RHEL will follow. Talking about the server community monitoring the Fedora development channel once every six months, or every day for that matter, is simply not going to change this.
A handful of voices representing server installations, who by definition are not development types, has no hope of dealing with the incremental changes introduced every day by hundreds of people that use laptops as their primary development platform and all of whom have their own 'itch' to scratch. That is just the way it is in open source. The choice to go to Fedora for RHEL development was a commitment to the laptop environment, whether consciously made or not. And it is not in the control of RH to dictate this. If the Fedora developers take up tablets en masse then guess what?: We will end up with a tablet distribution.
The OS distro we get is the consequence of the culture and environment predominant in the development community. This is neither good nor bad. It just is. Our firm has specific requirements which to date have been more than adequately met by RHEL and CentOS. But that seems to us to be changing in ways that no longer meet our expectations from a server based distro.
A server based distro to us has certain characteristics that are orientated to long running processes and system uptimes measured in months if not years. I have given up counting how many times I have to reboot all of our CentOS servers in the past year because of updates.
On the other hand I have this task running on a different server with a different OS:
Priority = DS; Inpri = 8; Time = UNLIMITED seconds. Job number = #j3719. TUE, NOV 4, 2014, 2:04 PM.
We do not need plug-and-play; or usb hot-swapping; or hibernation; or screen savers; or audio-video players; or power optimisation. All of which are worthy things in their own right and certainly have their place in computing. While these occasionally have proved convenient for me none are really necessary for a server host and their presence undoubtedly significantly increases the complexity and maintenance burden of the distribution.
What we need is simplicity, stability, reliability, and consistency. What seems to be happening instead is feature-creep, software-bloat and increased coupling.
And lest I be accused of 'wingeing' from the sideline I have been contributing to Open Source in a modest way since 1995, starting with Sendmail-8.7 on HP-UX. I just have limited time to give over to these things. The selection of RHEL for our primary platform was, in large part, to reduce the resources given over to managing the software. It would be ironic in the extreme were the reverse prove the case.
On Thu, Dec 10, 2015 at 10:21:56AM -0500, James B. Byrne wrote:
Since the import of what I was trying to convey has been lost, no doubt due to my poor choice of words, I will restate the obvious: If the bulk of the developers working on Fedora use laptops as their platform then, inevitably, Fedora will become in essence a laptop distribution and RHEL will follow. Talking about the server community monitoring the Fedora development channel once every six months, or every day for that matter, is simply not going to change this.
But this isn't the case, so it's not really a very productive line of speculation. We _have_ a server community around Fedora, both developers and users.
source. The choice to go to Fedora for RHEL development was a commitment to the laptop environment, whether consciously made or not.
This does not match history nor the current situation.
On 12/10/2015 10:21 AM, James B. Byrne wrote:
Since the import of what I was trying to convey has been lost, no doubt due to my poor choice of words, I will restate the obvious: If the bulk of the developers working on Fedora use laptops as their platform then, inevitably, Fedora will become in essence a laptop distribution and RHEL will follow. Talking about the server community monitoring the Fedora development channel once every six months, or every day for that matter, is simply not going to change this.
As Matthew said, there is a Fedora _server_ community already. Not all Fedora devs are running laptops; but a laptop is one target, just as a server is another. I've said it before and I'll say it again: Enterprise != Server. I need an Enterprise distribution for my workstation needs, on a laptop. Dell has been supporting RHEL on their Precision Mobile Workstations (aka 'high end laptops') for years; and there is a definite market segment for that use.
A server based distro to us has certain characteristics that are orientated to long running processes and system uptimes measured in months if not years. I have given up counting how many times I have to reboot all of our CentOS servers in the past year because of updates.
There is no single 'server-oriented' way of doing things; different servers have different requirements, and CentOS already gets poked on by those who think version number is a good indicator of how up to date a piece of software is for security and/or bugfix purposes. Owncloud, for instance, is server software, but it needs a far more up-to-date PHP than the default in CentOS 6 (Software Collections to the rescue).
On the other hand I have this task running on a different server with a different OS:
Priority = DS; Inpri = 8; Time = UNLIMITED seconds. Job number = #j3719. TUE, NOV 4, 2014, 2:04 PM.
And I have a Cisco 7401 running a different OS (IOS, of course) with the following uptime (and other details.....): .............................................................................................. colo-7400-2 uptime is 6 years, 43 weeks, 3 days, 14 hours, 13 minutes System returned to ROM by reload at 00:40:17 UTC Tue Feb 10 2009 System restarted at 00:43:11 UTC Tue Feb 10 2009 ... Cisco 7401ASR (NSE) processor (revision A) with 491520K/32768K bytes of memory. Processor board ID 74993065 R7000 CPU at 375MHz, Implementation 39, Rev 3.3, 256KB L2 Cache 1 slot ASR midplane, Version 2.0
Last reset from power-on PXF processor tmc 'system:pxf/ucode0' is running ( v1.1 ). 2 Gigabit Ethernet interfaces 509K bytes of NVRAM. ..............................................................................................
But uptime isn't everything. That router would not have been up that long if there was a more updated IOS available for it (I am running the last security update available from Cisco's TAC for that box, and it is way out of support, but it's in a 'sheltered' position and works fine for what it is doing).
Certain updates require a reboot; without ksplice or similar technology it will always be that way for the kernel. Certain glibc updates are similar.
What we need is simplicity, stability, reliability, and consistency. What seems to be happening instead is feature-creep, software-bloat and increased coupling.
Many share your needs; at this point in time, CentOS 6 is in that form of maintenance mode. CentOS 7 is still in a 'can get new features' mode (this due entirely to upstream's model). If you need something in a stable mode today, use C6. C7 will get there in a few releases.
The footprint of the needs met by a general-purpose Enterprise Linux distribution is getting larger, not smaller, and the software needed to meet all of these needs is necessarily not as simple as it once was. Now, niche distributions can be a bit more simple, but they will not have as broad of a footprint as the general-purpose ones. CentOS, and its upstream, is a general-purpose Enterprise (and Enterprise != Server) OS where one of the many use cases is as a traditional server.
Other use cases exist, and are targeted by upstream as being valuable market segments. That includes the Dell Precision Mobile Workstation line of high-end laptops (like my 2010-vintage M6500), as well as the Precision Workstation desktops and the PowerEdge servers, all of which can be ordered from Dell with a fully-supported RHEL factory-installed. But there is also the virtualization market and the lightweight containers ('cloud') market. And now there is the IoT market, and those are almost entirely ARM-based systems. Perhaps a 'tablet' market for Enterprise Linux will come into play; at the moment the Linux penetration here is mostly Android, with some niche traditional Linux distributions filling certain needs (like Kali Linux for things like the Pwnie Express Pwn Pad).
On 12/10/2015 07:21 AM, James B. Byrne wrote:
If the bulk of the developers working on Fedora use laptops as their platform then, inevitably, Fedora will become in essence a laptop distribution and RHEL will follow.
Surely you're not suggesting that the code a developer writes is dependent on the form factor of the computer on which they write it? I'm sure that idea would shock nearly all of the developers of software for both rack mounted servers and embedded devices.
I think it's likely that, instead, you believe that you are representative of all of the people who do your job, and that features which you do not need are therefore not needed by others. That logic is quite normal, but completely wrong.
Take for instance your opinion of power management for NICs. While power management is important to mobile, battery-operated devices, it is also desirable in large data centers. Cooling and power use are big issues for data centers, and that feature was intended for that environment. You dismiss it as laptop-oriented technology, but not all system administrators do.
A handful of voices representing server installations, who by definition are not development types
"By definition?" Have you heard of DevOps? Whatever your opinion of that idea, there are definitely server admins who take part in development at all levels of the stack.
A server based distro to us has certain characteristics that are orientated to long running processes and system uptimes measured in months if not years. I have given up counting how many times I have to reboot all of our CentOS servers in the past year because of updates.
I share that frustration, but it has nothing to do with whether or not Fedora developers use laptops. The truth is simply that software becomes more complex over time, that there is a growing value in attacking computer systems, and that the world is increasingly connected. These things act together to create a situation where bugs are more likely in the core components, where it's harder to update a system without fully rebooting it.
But there's hope. There are a number of efforts to produce a system to update the kernel without reboots (ksplice, kgraft, kpatch, and KernelCare). More developers are writing unit tests. Code analysis tools are improving. Both the number of bugs produced and the cost of fixing them are getting better over time, too.
We do not need plug-and-play; or usb hot-swapping; or hibernation; or screen savers; or audio-video players; or power optimisation.
That's great for you, but some of those things are really valuable for system admins, especially those who run *really large* numbers of systems. Power and cooling cost money, so optimization has a lot of value. A lot of those plug-and-play and hot-swapping technologies that you deride are essential for high availability systems (such as SAS/SATA hot swapping).
Gordon Messmer wrote:
I think it's likely that, instead, you believe that you are representative of all of the people who do your job, and that features which you do not need are therefore not needed by others. That logic is quite normal, but completely wrong.
On the other hand, it would be relatively easy to determine the number of CentOS users, or CentOS machines, in various categories. For some reason both CentOS and Fedora seem to shy away from gathering this kind of information, or indeed any information from users.
On Fri, Dec 11, 2015 at 11:45:05AM +0000, Timothy Murphy wrote:
On the other hand, it would be relatively easy to determine the number of CentOS users, or CentOS machines, in various categories. For some reason both CentOS and Fedora seem to shy away from gathering this kind of information, or indeed any information from users.
I'm interested in any suggestions for how to do this in a "relatively easy" way. Traditionally, Fedora users have been very wary of any opt-out metrics-gathering. So, that leaves either reach-out information seeking (which is valuable but expensive, hard, and time-consuming) or else self-selected feedback, which when not done carefully can be _worse_ than nothing.
And when I say I'm interested in suggestions, that's not a rhetorical flourish. I mean it. :)
On 12/11/2015 06:45 AM, Timothy Murphy wrote:
On the other hand, it would be relatively easy to determine the number of CentOS users, or CentOS machines, in various categories. For some reason both CentOS and Fedora seem to shy away from gathering this kind of information, or indeed any information from users.
Users' privacy, perhaps? Maybe some users don't want people to know that they use CentOS, for whatever reason. Fedora/Red Hat tried doing this sort of gathering of data, years ago, and it didn't work out well (I'm trying to remember the name of the program that did the data collection, which was an opt-in thing, but I'm coming up blank).
-
Gordon Messmer -
James B. Byrne -
Lamar Owen -
Matthew Miller -
Timothy Murphy