4 ms·

I always get funny feelings when people use "ancient" and "modern" as argument, without further explanation. Not that it is an invalid point, mind you. But cert

by norswap 13y ago

I always get funny feelings when people use "ancient" and "modern" as argument, without further explanation. Not that it is an invalid point, mind you. But certainly one that would bear expanding on.

SwellJoe 13y ago
I mentioned one reason above. The Apache developers are far from incompetent, and all the changes in Apache since 1.3 have been because somebody (usually a lot of people) needed or wanted those changes. In most things I agree with you; I use vim, bash, shell scripts for automation, Perl, etc. All things that get the ancient vs. modern argument used against them...but, when it comes to software security old nearly always means "exploitable". Since Apache 1.3 became EOL in 2010, OpenBSD developers have been solely responsible for finding and fixing 1.3 security issues. That's a lot of work. If I were responsible for Apache packages (and I am; we ship a custom build of Apache for some of our supported operating systems in Virtualmin repos), I would want to leverage the knowledge and efforts of the people who primarily work on Apache. To continue... There have been major architectural changes in Apache from 1.3 to 2.x. Performance on a number of use cases has nearly doubled in those 15 years, for example. Modern web standards are more widely supported by recent versions, as well, either through modules or core HTTP protocol support changes. Wanna use SPDY? Yeah...gotta have 2.x. A ton of security and QoS oriented capabilities are also "new" in 2.x. Given OpenBSDs security focus, I believe tools to help prevent exploits and DoS of web apps should also be considered...not just whether the web server has any directly exploitable bugs. Very few people are just serving flat files with their web server today. The code interacting with clients is often mostly in Python, Ruby, Perl, PHP, etc. Those are as much potential attack vectors as the web server itself, and 2.x has better tools for managing that risk.

by norswap 13y ago

I always get funny feelings when people use "ancient" and "modern" as argument, without further explanation. Not that it is an invalid point, mind you. But certainly one that would bear expanding on.

SwellJoe 13y ago

I mentioned one reason above. The Apache developers are far from incompetent, and all the changes in Apache since 1.3 have been because somebody (usually a lot of people) needed or wanted those changes. In most things I agree with you; I use vim, bash, shell scripts for automation, Perl, etc. All things that get the ancient vs. modern argument used against them...but, when it comes to software security old nearly always means "exploitable". Since Apache 1.3 became EOL in 2010, OpenBSD developers have been solely responsible for finding and fixing 1.3 security issues. That's a lot of work. If I were responsible for Apache packages (and I am; we ship a custom build of Apache for some of our supported operating systems in Virtualmin repos), I would want to leverage the knowledge and efforts of the people who primarily work on Apache. To continue... There have been major architectural changes in Apache from 1.3 to 2.x. Performance on a number of use cases has nearly doubled in those 15 years, for example. Modern web standards are more widely supported by recent versions, as well, either through modules or core HTTP protocol support changes. Wanna use SPDY? Yeah...gotta have 2.x. A ton of security and QoS oriented capabilities are also "new" in 2.x. Given OpenBSDs security focus, I believe tools to help prevent exploits and DoS of web apps should also be considered...not just whether the web server has any directly exploitable bugs. Very few people are just serving flat files with their web server today. The code interacting with clients is often mostly in Python, Ruby, Perl, PHP, etc. Those are as much potential attack vectors as the web server itself, and 2.x has better tools for managing that risk.