Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[Jim Jagielski]

> On Jan 3, 2017, at 8:04 PM, Noel Butler  wrote:
> 
> On 03/01/2017 23:11, Jim Jagielski wrote:
> 
>> Back in the "old days" we used to provide complimentary builds
>> for some OSs... I'm not saying we go back and do that necessarily,
>> but maybe also providing easily consumable other formats when we
>> do a release, as a "service" to the community might make a lot
>> of sense.
>>  
> 2 years ago it was decided to stop the official -deps (despite they are 
> included in dev still)... now you want to bring it back? (you'd have to if 
> you're going to roll usable binary packages or your "community service" 
> re-built packages are going to be broken)

Nope. Didn't say that. And the inclusion on dev still is known
and even explicitly addressed.

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[William A Rowe Jr]

On Tue, Jan 3, 2017 at 7:04 PM, Noel Butler  wrote:
>
> On 03/01/2017 23:11, Jim Jagielski wrote:
>
> Back in the "old days" we used to provide complimentary builds
> for some OSs... I'm not saying we go back and do that necessarily,
> but maybe also providing easily consumable other formats when we
> do a release, as a "service" to the community might make a lot
> of sense.
>
>
> 2 years ago it was decided to stop the official -deps (despite they are 
> included in dev still)... now you want to bring it back? (you'd have to if 
> you're going to roll usable binary packages or your "community service" 
> re-built packages are going to be broken)

I don't think he said that. For years httpd shipped the compiled
current openssl, expat, pcre sources as a binary. There was no sources
package of these, although we did provide the .diff to get the
packages to build correctly.

Because HTTP/2 requires OpenSSL 1.0.2, that will have to be part of
most packages, including semi-modern Linux flavors.

PCRE[2] is unavoidable, and while libxml2 can sub in for libexpat, the
SVN project would rather we bound to libexpat for specific features
they rely on.


> Although I as many others here prefer to roll our own due to our configs, and 
> not having to deal with bloat, I can see this having a positive effect for 
> users of a couple of distros who when they release brand new releases, come 
> with antiquated junk thats outdated and stays outdated, to give those users a 
> choice of using a modern code set would be good, but requires long term 
> dedication.

Agreed - it simply has to land somewhere like /opt/apache/httpd/ or
whatnot, to disambiguate whatever the user builds for themself in
/usr/local/ and what the OS might provision in /usr/

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[Noel Butler]

On 03/01/2017 23:11, Jim Jagielski wrote:

> Back in the "old days" we used to provide complimentary builds
> for some OSs... I'm not saying we go back and do that necessarily,
> but maybe also providing easily consumable other formats when we
> do a release, as a "service" to the community might make a lot
> of sense.

2 years ago it was decided to stop the official -deps (despite they are
included in dev still)... now you want to bring it back? (you'd have to
if you're going to roll usable binary packages or your "community
service" re-built packages are going to be broken) 

Although I as many others here prefer to roll our own due to our
configs, and not having to deal with bloat, I can see this having a
positive effect for users of a couple of distros who when they release
brand new releases, come with antiquated junk thats outdated and stays
outdated, to give those users a choice of using a modern code set would
be good, but requires long term dedication.

-- 
Kind Regard, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument

signature.asc
Description: OpenPGP digital signature

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[William A Rowe Jr]

On Jan 3, 2017 07:11, "Jim Jagielski"  wrote:

Back in the "old days" we used to provide complimentary builds
for some OSs... I'm not saying we go back and do that necessarily,
but maybe also providing easily consumable other formats when we
do a release, as a "service" to the community might make a lot
of sense.


It could be really helpful. Or we can follow svn's lead and hand it
entirely off to the broader community, which proved really effective on
Windows, given the number of distros to now choose between. I haven't seen
similar for RHEL users, for example.

That said, only one major Linux distro (April Ubuntu LTS) is at OpenSSL
1.0.2, which is a necessary part of http/2's special sauce.

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[Jim Jagielski]

Back in the "old days" we used to provide complimentary builds
for some OSs... I'm not saying we go back and do that necessarily,
but maybe also providing easily consumable other formats when we
do a release, as a "service" to the community might make a lot
of sense.

RE: The Version Bump fallacy [Was Re: Post 2.4.25]

[Houser, Rick]

I agree with a lot of what Daniel says, and I'm in a similar role with 
maintaining my organization's httpd RPM packages.

However, I don't look at this suggestion so much as a replacement, but rather 
an additional option end users can use if they aren't up to the challenge of 
using sources, but can't get by with ancient builds in RHEL, etc.  I personally 
doubt this would affect that many of the bigger users (let alone those on this 
list), as we would just keep using sources to keep up with what the LTS distros 
leave off (a 5+ year cycle is just too slow for the modern web tier).  As 
someone who does distro packaging, I think this is completely the wrong 
distribution model, but it's also the quick and dirty one.

Just throwing this out there, but a better middle of the road option for 
similar user coverage may be a more aggressive backporting of bleeding edge 
apache-related packages from development distros like Fedora to repositories 
maintained for the LTS distros.  A lot of people already do this work 
independently, so perhaps much of the labor overhead could be knocked off with 
a bit more initial organizational effort, and referral/hosting support from the 
httpd project?


Rick Houser
Web Administration

> -Original Message-
> From: Daniel Ruggeri [mailto:drugg...@primary.net]
> Sent: Friday, December 30, 2016 10:12
> To: dev@httpd.apache.org
> Subject: Re: The Version Bump fallacy [Was Re: Post 2.4.25]
> 
> On 12/28/2016 6:40 PM, Yehuda Katz wrote:
> > On Wed, Dec 28, 2016 at 12:35 AM, William A Rowe Jr
> > <wr...@rowe-clan.net <mailto:wr...@rowe-clan.net>> wrote:
> >
> > Our adoption is *broadly* based on the OS distributions
> > from vendors, not from people picking up our sources.
> > Yes - some integrate directly from source, and others
> > use a non-OS distribution.
> >
> >
> > I think a significant number of users of nginx add the official nginx
> > yum/apt sources and keep up to date that way
> > (http://nginx.org/en/linux_packages.html#mainline).
> > This is particularly true because the vendor-supplied version are so
> > old. You can see this in the w3techs data: nginx 1.10.2 came out in
> > October and already makes up 75% of all nginx 1.10 users. nginx 1.11.8
> > usage has similar trends.
> >
> > A possible solution to this would be to start publishing binaries in a
> > package-manager-accessible format.
> > I am confident it would see a much higher rate of adoption.
> >
> > - Y
> 
> I feel strongly about this...
> 
> As a package builder/maintainer at $dayjob, this idea terrifies me.
> Given the huge variation in distributions and what is current on those
> platforms, the "best" option I see is to build for the least common
> denominator (minimum common libc, APR, APR-UTIL, openssl, openldap,
> etc). Otherwise, the package may only work on sufficiently modern
> installations. Things like Docker containers for the different distros
> are nice, but I'm not sure those are guaranteed to be current or
> accurately represent what an installation will look like. Additionally,
> vendors set different prefixes or split their configurations up
> differently meaning we would then have to bite off the work of creating
> vendor-specific packages (sucks for us) or force a standard installation
> format (sucks for operators of the servers). A really good illustration
> of this challenge is the layout differences between Debian and CentOS
> where even the name of the server binary is changed from "httpd" to
> "apache2" in the former distro.
> 
> Or worse... we would have to bundle/vendor a copy of the dependencies
> inside the httpd package. This becomes a nightmare for the package
> builders because (as wrowe pointed out recently) it requires us to build
> these updated libraries and push the new package at some cadence as well
> as changing library search paths to potentially funky locations. It also
> becomes a challenge for server operators because a library now exists in
> two locations on the machine so compliance auditing gets forked (my
> httpd installation may be using openssl 1.0.2j but my postfix server may
> be using 0.9.8zh).
> 
> Also, I'm sure it goes without saying, but we can't reasonably consider
> either approach without full CI... doing all this manually is
> unmaintainable (heh - ask me how I know).
> 
> --
> Daniel Ruggeri

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[Daniel Ruggeri]

On 12/28/2016 6:40 PM, Yehuda Katz wrote:
> On Wed, Dec 28, 2016 at 12:35 AM, William A Rowe Jr
> > wrote:
>
> Our adoption is *broadly* based on the OS distributions
> from vendors, not from people picking up our sources.
> Yes - some integrate directly from source, and others
> use a non-OS distribution.
>
>
> I think a significant number of users of nginx add the official nginx
> yum/apt sources and keep up to date that way
> (http://nginx.org/en/linux_packages.html#mainline).
> This is particularly true because the vendor-supplied version are so
> old. You can see this in the w3techs data: nginx 1.10.2 came out in
> October and already makes up 75% of all nginx 1.10 users. nginx 1.11.8
> usage has similar trends.
>
> A possible solution to this would be to start publishing binaries in a
> package-manager-accessible format.
> I am confident it would see a much higher rate of adoption.
>
> - Y

I feel strongly about this...

As a package builder/maintainer at $dayjob, this idea terrifies me.
Given the huge variation in distributions and what is current on those
platforms, the "best" option I see is to build for the least common
denominator (minimum common libc, APR, APR-UTIL, openssl, openldap,
etc). Otherwise, the package may only work on sufficiently modern
installations. Things like Docker containers for the different distros
are nice, but I'm not sure those are guaranteed to be current or
accurately represent what an installation will look like. Additionally,
vendors set different prefixes or split their configurations up
differently meaning we would then have to bite off the work of creating
vendor-specific packages (sucks for us) or force a standard installation
format (sucks for operators of the servers). A really good illustration
of this challenge is the layout differences between Debian and CentOS
where even the name of the server binary is changed from "httpd" to
"apache2" in the former distro.

Or worse... we would have to bundle/vendor a copy of the dependencies
inside the httpd package. This becomes a nightmare for the package
builders because (as wrowe pointed out recently) it requires us to build
these updated libraries and push the new package at some cadence as well
as changing library search paths to potentially funky locations. It also
becomes a challenge for server operators because a library now exists in
two locations on the machine so compliance auditing gets forked (my
httpd installation may be using openssl 1.0.2j but my postfix server may
be using 0.9.8zh).

Also, I'm sure it goes without saying, but we can't reasonably consider
either approach without full CI... doing all this manually is
unmaintainable (heh - ask me how I know).

-- 
Daniel Ruggeri

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[William A Rowe Jr]

On Thu, Dec 29, 2016 at 8:25 AM, Jim Jagielski  wrote:
> It wasn't the paste that was the problem, but the inability
> of other email clients to determine from your email what
> parts/sections are quoted from *previous* emails.

Yann pointed me in the right direction, I believe it is fixed now.

Thanks for the heads-up!

>> On Dec 28, 2016, at 5:49 PM, William A Rowe Jr  wrote:
>>
>> Hi Jim,
>>
>> Talk to Google and the OpenOffice Team, that was a paste from OpenOffice 
>> Calc.
>>
>> I'll be happy to start summarizing as a shared Google sheet.

Google sheet might still be useful, so I'll maintain that as a general purpose
collection of shared-with-httpd-dev tabs.

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[Jim Jagielski]

> On Dec 28, 2016, at 7:40 PM, Yehuda Katz  wrote:
> 
> On Wed, Dec 28, 2016 at 12:35 AM, William A Rowe Jr  
> wrote:
> Our adoption is *broadly* based on the OS distributions
> from vendors, not from people picking up our sources.
> Yes - some integrate directly from source, and others
> use a non-OS distribution.
> 
> I think a significant number of users of nginx add the official nginx yum/apt 
> sources and keep up to date that way 
> (http://nginx.org/en/linux_packages.html#mainline).
> This is particularly true because the vendor-supplied version are so old. You 
> can see this in the w3techs data: nginx 1.10.2 came out in October and 
> already makes up 75% of all nginx 1.10 users. nginx 1.11.8 usage has similar 
> trends.
> 
> A possible solution to this would be to start publishing binaries in a 
> package-manager-accessible format.
> I am confident it would see a much higher rate of adoption.
> 

Good point. +1

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[Jim Jagielski]

It wasn't the paste that was the problem, but the inability
of other email clients to determine from your email what
parts/sections are quoted from *previous* emails.

> On Dec 28, 2016, at 5:49 PM, William A Rowe Jr  wrote:
> 
> Hi Jim,
> 
> Talk to Google and the OpenOffice Team, that was a paste from OpenOffice Calc.
> 
> I'll be happy to start summarizing as a shared Google sheet.
> 
> Cheers,
> 
> Bill
> 
> 
> On Dec 28, 2016 14:22, "Jim Jagielski"  wrote:
> Bill, I don't know if it's just my Email client or not (doesn't
> look like it) but could you fix your Email client? It's impossible to
> reply and have the quoted parts parsed out correctly. I think
> it's to do w/ your messages being RTF or something.
> 
> Thx!
> 
> Included is an example of how a Reply misses quote levels...
> 
> > On Dec 28, 2016, at 1:34 PM, William A Rowe Jr  wrote:
> >
> > On Wed, Dec 28, 2016 at 9:13 AM, Jim Jagielski  wrote:
> > cPanel too... They are moving to EA4 which is Apache 2.4.
> >
> > If not moved yet, that example wouldn't be helpful, it reinforces my point
> > four years later. But EA itself seems to track pretty closely to the most
> > contemperanious versions, looks like within a month.
> >
> >
> > So the idea that supplemental (ie: 2.4.x->2.4.y) patches don't
> > have the reach or range of larger ones (2.4.x->2.6/3.0) isn't
> > quite accurate.
> >
> > It's entirely accurate. It isn't all-encompassing. We have that data too,
> > let's tear down SecuritySpace's Nov '16 dataset;
> > http://www.securityspace.com/s_survey/data/201611/servers.html
> >
> 

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[Stefan Eissing]

> Am 29.12.2016 um 01:40 schrieb Yehuda Katz :
> 
> On Wed, Dec 28, 2016 at 12:35 AM, William A Rowe Jr  
> wrote:
> Our adoption is *broadly* based on the OS distributions
> from vendors, not from people picking up our sources.
> Yes - some integrate directly from source, and others
> use a non-OS distribution.
> 
> I think a significant number of users of nginx add the official nginx yum/apt 
> sources and keep up to date that way 
> (http://nginx.org/en/linux_packages.html#mainline).
> This is particularly true because the vendor-supplied version are so old. You 
> can see this in the w3techs data: nginx 1.10.2 came out in October and 
> already makes up 75% of all nginx 1.10 users. nginx 1.11.8 usage has similar 
> trends.
> 
> A possible solution to this would be to start publishing binaries in a 
> package-manager-accessible format.
> I am confident it would see a much higher rate of adoption.

Very good point. Myself using a ppa for my ubuntu server via

deb http://ppa.launchpad.net/ondrej/apache2/ubuntu trusty main

that updates very quickly. It already has 2.4.25. There are other people doing 
this for various distros. The least we could do is document the ones we know, 
talk to people how they see it continue. Offer a https place and visibility on 
Apache servers maybe?

Does that make sense?

> - Y

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[Yehuda Katz]

On Wed, Dec 28, 2016 at 12:35 AM, William A Rowe Jr 
wrote:

> Our adoption is *broadly* based on the OS distributions
> from vendors, not from people picking up our sources.
> Yes - some integrate directly from source, and others
> use a non-OS distribution.
>

I think a significant number of users of nginx add the official nginx
yum/apt sources and keep up to date that way (
http://nginx.org/en/linux_packages.html#mainline).
This is particularly true because the vendor-supplied version are so old.
You can see this in the w3techs data: nginx 1.10.2 came out in October and
already makes up 75% of all nginx 1.10 users. nginx 1.11.8 usage has
similar trends.

A possible solution to this would be to start publishing binaries in a
package-manager-accessible format.
I am confident it would see a much higher rate of adoption.

- Y

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[William A Rowe Jr]

On Dec 28, 2016 10:34, "William A Rowe Jr"  wrote:


Specific
Revision
Of all Most
Recent
Of m.m Of all
Apache/1.3.x 391898 3.33% 1.3.42 42392 10.82% 0.36%
Apache/2.0.x 551117 4.68% 2.0.64 36944 6.70% 0.31%
Apache/2.2.x 7129391 60.49% 2.2.31 1332448 18.78% 11.31%
Apache/2.4.x 3713364 31.51% 2.4.17+ 1502061 42.90% 12.74%

11785770
2.4.23 754385 21.54% 6.40%


Since this table is illegible to some, please see the second tab of

https://docs.google.com/spreadsheets/d/1aOxBRZ2IHsUJJcQNXu-oe6la4wMRIHN2mOlJCQGRy0k/edit?usp=drivesdk

The first tab is a crossref of many OS distribution components used by
httpd, as well as httpd itself.

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[William A Rowe Jr]

Hi Jim,

Talk to Google and the OpenOffice Team, that was a paste from OpenOffice
Calc.

I'll be happy to start summarizing as a shared Google sheet.

Cheers,

Bill


On Dec 28, 2016 14:22, "Jim Jagielski"  wrote:

> Bill, I don't know if it's just my Email client or not (doesn't
> look like it) but could you fix your Email client? It's impossible to
> reply and have the quoted parts parsed out correctly. I think
> it's to do w/ your messages being RTF or something.
>
> Thx!
>
> Included is an example of how a Reply misses quote levels...
>
> > On Dec 28, 2016, at 1:34 PM, William A Rowe Jr 
> wrote:
> >
> > On Wed, Dec 28, 2016 at 9:13 AM, Jim Jagielski  wrote:
> > cPanel too... They are moving to EA4 which is Apache 2.4.
> >
> > If not moved yet, that example wouldn't be helpful, it reinforces my
> point
> > four years later. But EA itself seems to track pretty closely to the most
> > contemperanious versions, looks like within a month.
> >
> >
> > So the idea that supplemental (ie: 2.4.x->2.4.y) patches don't
> > have the reach or range of larger ones (2.4.x->2.6/3.0) isn't
> > quite accurate.
> >
> > It's entirely accurate. It isn't all-encompassing. We have that data too,
> > let's tear down SecuritySpace's Nov '16 dataset;
> > http://www.securityspace.com/s_survey/data/201611/servers.html
> >
>
>

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[Jim Jagielski]

Bill, I don't know if it's just my Email client or not (doesn't
look like it) but could you fix your Email client? It's impossible to
reply and have the quoted parts parsed out correctly. I think
it's to do w/ your messages being RTF or something.

Thx!

Included is an example of how a Reply misses quote levels...

> On Dec 28, 2016, at 1:34 PM, William A Rowe Jr  wrote:
> 
> On Wed, Dec 28, 2016 at 9:13 AM, Jim Jagielski  wrote:
> cPanel too... They are moving to EA4 which is Apache 2.4.
>  
> If not moved yet, that example wouldn't be helpful, it reinforces my point
> four years later. But EA itself seems to track pretty closely to the most
> contemperanious versions, looks like within a month.
> 
> 
> So the idea that supplemental (ie: 2.4.x->2.4.y) patches don't
> have the reach or range of larger ones (2.4.x->2.6/3.0) isn't
> quite accurate.
> 
> It's entirely accurate. It isn't all-encompassing. We have that data too,
> let's tear down SecuritySpace's Nov '16 dataset;
> http://www.securityspace.com/s_survey/data/201611/servers.html 
> 

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[Jan Ehrhardt]

William A Rowe Jr in gmane.comp.apache.devel (Wed, 28 Dec 2016 10:46:51
-0600):
>On Wed, Dec 28, 2016 at 9:05 AM, Jan Ehrhardt  wrote:
>
>> Do not underestimate the influence of control panels. On all my Centos
>> servers I am running Directadmin. DA always offers to upgrade to the
>> latest release within a day after the release. Hence, I am running
>> Apache 2.4.25 everywhere at the moment.
>
> Excellent pointer. Thanks Jan.

BTW: I would be more hesitant to directly install a new release if I
would not have tested the dev/dist release candidates on my Windows
dev-server. But I am quite sure a lot of Directadmin users follow suit
soon.
-- 
Jan

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[William A Rowe Jr]

On Wed, Dec 28, 2016 at 9:13 AM, Jim Jagielski  wrote:

> cPanel too... They are moving to EA4 which is Apache 2.4.
>

If not moved yet, that example wouldn't be helpful, it reinforces my point
four years later. But EA itself seems to track pretty closely to the most
contemperanious versions, looks like within a month.


So the idea that supplemental (ie: 2.4.x->2.4.y) patches don't
> have the reach or range of larger ones (2.4.x->2.6/3.0) isn't
> quite accurate.
>

It's entirely accurate. It isn't all-encompassing. We have that data too,
let's tear down SecuritySpace's Nov '16 dataset;
http://www.securityspace.com/s_survey/data/201611/servers.html

First off, if you follow that link, you'll find much larger numbers
associated
to those specific revisions shipped with the likes of RHEL or CentOS, Ubuntu
(particularly -LTS flavors), etc etc etc. That was my contention in the top
post. But let's quantify 'accuracy' as you defined it in the reply...

Specific
Revision
Of all Most
Recent
Of m.m Of all
Apache/1.3.x 391898 3.33% 1.3.42 42392 10.82% 0.36%
Apache/2.0.x 551117 4.68% 2.0.64 36944 6.70% 0.31%
Apache/2.2.x 7129391 60.49% 2.2.31 1332448 18.78% 11.31%
Apache/2.4.x 3713364 31.51% 2.4.17+ 1502061 42.90% 12.74%

11785770
2.4.23 754385 21.54% 6.40%

The applicable data are 37.47% of all 'Apache[/n[.n[.n]]]' items, meaning
that some 2/3rds of users drop the ServerTokens down to product only
or major version only, and we can't derive anything useful from them, so
we will ignore the Apache and Apache/2 references for our % evaluations,
'Of all' refers to those with at least Apache/2.x designations.

I included 2.4.17-2.4.23 as an item, because that group are the versions
that released within the past year of this particular survey data (that does
include the then-current 2.4.23.)

The 'Of m.m' - same major.minor - backs out that Apache/2.x (without a
known subversion) from the calculation because we can't tell whether they
are the corresponding or a different subversion.

Of httpd users we can quantify, 6.4% updated within months of the 2.4.23
release (your 'power users' classification.) That minority doesn't move the
needle much on total adoption of httpd vs. others.

Only 11.3% bothered to pick up the final 2.2.31 that has been out
over a year, and combined with 12.74% running some 2.4.17...2.4.23,
*** only 24% *** run a version that had been a current release within
the preceding year.  E.g. of those running a somewhat-current version,
more than 1/4 are running the July 2.4.23 release by the end of November.
Note that Fedora 25 didn't move the needle much on this, it shipped GA
in December.

aren't the ones we are talking about in the 1st place. We are
> talking about real, "power" users, who want/need the latest
> and greatest.
>

Not if you are talking overall adoption rate. As illustrated, those
users adopting 2.4.23 already are an nearly accidental minority,
after 5 mos half of the 'current' 2.4 users are running 2.4.23, the
other half are running a flavor between 12 and 6 mos old. That
looks like overall random distribution by deployment date, with
no particular effort expended on 'staying current'.

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[William A Rowe Jr]

On Wed, Dec 28, 2016 at 9:05 AM, Jan Ehrhardt  wrote:

> William A Rowe Jr in gmane.comp.apache.devel (Tue, 27 Dec 2016 23:35:50
> -0600):
> >But the vast majority of httpd, nginx, and yes - even IIS
> >users are all running what they were handed from their
> >OS distribution.
>
> Do not underestimate the influence of control panels. On all my Centos
> servers I am running Directadmin. DA always offers to upgrade to the
> latest release within a day after the release. Hence, I am running
> Apache 2.4.25 everywhere at the moment.
>
> Excellent pointer. Thanks Jan.

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[Jim Jagielski]

cPanel too... They are moving to EA4 which is Apache 2.4.

So the idea that supplemental (ie: 2.4.x->2.4.y) patches don't
have the reach or range of larger ones (2.4.x->2.6/3.0) isn't
quite accurate.

IMO, people who are comfortable with "whatever the OS provides"
aren't the ones we are talking about in the 1st place. We are
talking about real, "power" users, who want/need the latest
and greatest.

just my 2c

> On Dec 28, 2016, at 10:05 AM, Jan Ehrhardt  wrote:
> 
> William A Rowe Jr in gmane.comp.apache.devel (Tue, 27 Dec 2016 23:35:50
> -0600):
>> But the vast majority of httpd, nginx, and yes - even IIS
>> users are all running what they were handed from their
>> OS distribution.
> 
> Do not underestimate the influence of control panels. On all my Centos
> servers I am running Directadmin. DA always offers to upgrade to the
> latest release within a day after the release. Hence, I am running
> Apache 2.4.25 everywhere at the moment.
> -- 
> Jan
> 

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[Jan Ehrhardt]

William A Rowe Jr in gmane.comp.apache.devel (Tue, 27 Dec 2016 23:35:50
-0600):
>But the vast majority of httpd, nginx, and yes - even IIS
>users are all running what they were handed from their
>OS distribution.

Do not underestimate the influence of control panels. On all my Centos
servers I am running Directadmin. DA always offers to upgrade to the
latest release within a day after the release. Hence, I am running
Apache 2.4.25 everywhere at the moment.
-- 
Jan

The Version Bump fallacy [Was Re: Post 2.4.25]

[William A Rowe Jr]

On Fri, Dec 23, 2016 at 2:52 PM, Jim Jagielski  wrote:

>
> As I have also stated, my personal belief is that
> 2.4 is finally reaching some traction, and if we
> "turn off" development/enhancement of 2.4, we will
> stop the uptake of 2.4 in its track.


This is where I think we have a disconnect.

Our adoption is *broadly* based on the OS distributions
from vendors, not from people picking up our sources.
Yes - some integrate directly from source, and others
use a non-OS distribution.

But the vast majority of httpd, nginx, and yes - even IIS
users are all running what they were handed from their
OS distribution. This is why an amazing number of people
run 2.4.3-2.4.10 and soon, 2.4.18, even though these are
all already out of date. Once RHEL, Ubuntu LTS, SUSE
or others pick up a specific rev, that's where the typical
user is going to land for the next several years.

The raw stats show a couple of interesting things, IMO;
https://w3techs.com/technologies/overview/web_server/all
While we have slipped somewhat, the old adage that
httpd or another "Web Server" must sit in front of the
cobbled-together app servers doesn't apply anymore.
Code like Tomcat, etc, is now far more robust and
capable of sitting on the outward facing edge of the DMZ.

The two runners up in web server space have essentially
switched places, nginx now has the market penetration
that IIS once enjoyed. IIS now amounts to a fraction of
what it once did, essentially the 'everything else' share
that used to be held by webservers we don't think about
any more, such as Sun's, lighttpd, etc. And of course
custom server agents of the top 10 data providers skew
the results significantly.

Other surveys paint the data a little differently;
https://news.netcraft.com/archives/2016/12/21/december-
2016-web-server-survey.html
http://www.securityspace.com/s_survey/data/201611/index.html

Next up, we will see broad distribution of 2.4.23 - why?
Because that shipped in Fedora 25 which will very likely
become RHEL 8. E.g. we missed the boat, Generally
the Fedora release a year out from RHEL GA become
the shipping packages, and the pattern suggests this
early winter release becomes an early winter '17 RHEL.

If we don't ship improvements, we wither and fall into
oblivion. It does not matter that these are called 2.4.26
because *no vendor will ship it*. Not until they start
gathering the components of their next major release.
Which means, they are shipping are least interesting
sources over and over because we aren't shipping new
major releases.

So I'd respectively suggest that adding a feature to
2.4 vs releasing the feature in 3.0 makes not one
iota of difference in goodwill/adoption. The next major
releases who code freeze after 3.0 has shipped will
be in position to pick up and distribute 3.0. All the
rest will be stuck in the past.

But as a bottom line, all those users stuck in the past
until their OS catches up will have little opinion about
a feature in a 2.4.x release they will never see, since
their vendor keeps shipping the same 2.4.n that their
OS revision had initially shipped.
.