Apache May Stop 1.3, 2.0 Series Releases 77
Dan Jones writes "The Apache Software Foundation may stop releasing new versions of the older 1.3 and 2.0 series of its flagship Web server product with most development now focused on the 2.2 series. Nothing is final yet, but messages to the Apache httpd developer mailing list recommend the formal deprecation of the 1.3.x branch, with most citing a lack of development activity. The Apache HTTP server project is one of the most successful and popular open source projects and has become an integral part of the technology stack for thousands of Web and SaaS applications. The first generation of Apache was released in 1995, and the 2.0 series began in 2002. Apache httpd 2.2 began in 2005, with the latest release (October 2009) being 2.2.14. However, the most recent releases of the 1.3 and 2.0 series servers were back in January 2008. With the combined total of active 1.3 and 2.0 series Apache Web servers well into the millions, any decision to end-of-life either product will be watched closely."
Surly this is just a formality (Score:3, Interesting)
Re: (Score:2)
But this is slashdot...
The Open source product we will say the product is allowed to die. But if it was Microsoft we will fight tooth and nail to keep Windows 3.1 from going EOL. Stating how so many people still need it.
Re:Surly this is just a formality (Score:5, Insightful)
With open source, the product doesn't need to die. If ASF isn't going to put any more resources into it, but other people are still using it, then the code is out there and they can hire someone to work on it. There are lots of developers familiar with the Apache codebase who, I'm sure, would be happy for someone to pay them to back-port fixes to the 1.3 and 2.0 series.
It's also worth noting that this has, in fact, already happened. The OpenBSD base systems includes a fork of Apache 1.3.29 and will probably continue to do so for a long time, because Apache 2.x has a new license.
Re:Surly this is just a formality (Score:5, Insightful)
If a company that supports a closed-source product wants to end support, their customers can always pay them to continue support for the product somewhat longer
Their customers can always offer to pay them to continue support. The company may accept, or it may decide that discontinuing the product and expecting the customers to upgrade is more profitable.
The responsible thing is to ... (Score:2)
Apache should keep hosting basic pages for the old series with at least LINKS to where the projects have moved to be maintained. Sourceforge for example or OpenBSD.
The realistic measure should be USAGE not how much development activity there is on the last branch. Bug fixes may be few and years between when the software becomes rock solid. "Perfect" software (unobtainable) would never need patching outside of changes in the abstraction layer with the OS (ignoring compiler issues) but under this line of thin
Re: (Score:2)
Open Source products never die, they just hibernate until somebody starts using it again.
What Apache is effectively saying is; we don't plan on doing any active development on those products anymore. Rest assured that if a severe enough bug is found in Apache 1.3 or 2.0, it WILL be fixed. There's always somebody willing to put in the effort to fix it, and that's all that is needed.
Re: (Score:2)
Who you calling surly?
And what does this mean exactly? Obviously, no new features for 1.3 and 2.0 - what about bugfixes? They say: "we'll be distributing security updates by other means" - what are these other means?
Re:Surly this is just a formality (Score:5, Informative)
As per http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/README [apache.org] , the proposal (Full disclosure: I'm colm@apache.org - the proposer), was that we would start distributing security patches via;
http://www.apache.org/dist/httpd/patches/ [apache.org]
The main point is to reduce the overhead and burden of creating full releases. Releases take a large amount of community involvement and time, and are becoming impractical. The 1.3.x branch does not even build on many modern platforms - for example the configure script is incompatible with dash and there is a getline() function which conflicts with a glibc neologism.
Hope that helps.
Re: (Score:2)
Re: (Score:2)
Mostly. But if you found a really, really nasty security bug, does Apache go "OMG we must fix this" and release a vulnerability alert and a new point release even though it's been two years, or do they say that "that one's out of any kind of support, even extended security-only support, go upgrade because we won't even look at it". That is an important cutoff, even though nothing much happens with any product 3+ years after its release.
Re: (Score:2)
That's what Apache presently does with the Win32 versions for deprecated Windows releases [apache.org].
(Note the unsubtle hints that Apache for Windows never was a good idea.)
Re: (Score:2)
Umm, I don't think that word means what you think it means [google.com].
Netcraft confirms... (Score:3, Funny)
Re:Netcraft confirms... (Score:5, Insightful)
Bizarrely enough, this is actually something netcraft might confirm.
Re: (Score:2)
mmm, a quick look at thier site though doesn't seem to show any pages with server versions.
Re: (Score:2, Informative)
Re: (Score:1)
...Apache 1.3.x is dying
Has been for a looong time. Thus, I switched to Lighttpd. Apache2 is too bloated for me, sucks too much memory by default, and is too difficult to configure for small simple sites (last I tried anyway, which was a looong time ago).
Re: (Score:3, Informative)
Right. Upgrade to a modern HTTP server like Nginx http://www.nginx.net/ [nginx.net] or Lighttpd, you won't regret it.
And if for some reason you really need Apache 1.3.x, this code is maintained by OpenBSD and an enhanced version is shipped with the OS.
Re: (Score:3, Interesting)
Re:about time (Score:5, Interesting)
Re: (Score:2)
Either it is a joke, or it was ages ago.
Nginx has a completely decent documentation: http://wiki.nginx.org/Main [nginx.org]
And some tutorials to begin with: http://nginx.org/en/docs/http/request_processing.html [nginx.org] - http://nginx.org/en/docs/http/server_names.html [nginx.org] - http://nginx.org/en/docs/http/configuring_https_servers.html [nginx.org]
Re: (Score:2)
Either it is a joke, or it was ages ago.
Or maybe he just didn't remember to think IN RUSSIAN.
Re: (Score:1, Informative)
The problem is that nginx does not support IPv6 which is kind if sad for a "modern" HTTP server.
Not sure what universe in which you reside, but in this one nginx has supported IPv6 since 0.7.36, released in 21 Feb 2009.
Sauce: http://nginx.net/CHANGES-0.7
Re: (Score:2)
I've been using it with IPv6 for months with no problems.
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
That's all well and good 'till one of your clients wants to use a .htaccess file.
I make some use Nginx for my own sites on my own dedicated servers (and it works great for that), but for my shared web hosting clients, I need to use Apache because all kinds of common software like CMS systems want to use .htaccess files, and Nginx doesn't support that.
If the Nginx project wants to take a good share of the shared hosting market, they are going to need to come up with support for .htaccess files, and the Apach
go for it (Score:3, Insightful)
these people don't care if they're in active development - and almost all of them are running them because upgrading isn't worth it for their application.
all these people care about are security patches. as long as that keeps happening, depreciate them all you want
it's just like people running 2.2.x kernels on high uptime servers. they don't want new features - if they were willing to install a new version of something every time a new feature came out, they'd be running 2.6.x now anyway. but they'll keep using it as long as reliability and security fixes keep rolling out.
Re:go for it (Score:5, Interesting)
almost all of them are running them because upgrading isn't worth it for their application.
Or because the new configuration scheme is not backwards compatible and the time required to get up to speed on the new config is too much of a hassle. There should have been some sort of 1.3->2.0->2.2 configuration updater. If there is and I'm just blind please point in the general direction :)
Re: (Score:1)
2.0 is still supported in several Linux distros, including Red Hat Enterprise Linux 4, which is still in support. If you truly need 2.0.x, Red Hat (and I assume other distro maintainers) can be expected to continue providing basic security fix updates to the 2.0 series as long as RHEL4 is still in support. I don't see much reason to expect an upstream project like Apache.org to do that.
[Yes, I work for Red Hat. But I only represent myself, not my employer nor my colleagues.]
Re: (Score:2)
I'm going to go out on a limb here and say the real reason they don't upgrade is because they don't know which version of Apache they're using, and/or don't care.
I work for a web hosting company and lots of our customers are still running 1.3 and 2.0 because that's what they were originally set u
Security Patches (Score:3, Interesting)
Re: (Score:2)
It is opensource project, anyone and everyone, especially businesses that use that software, is candidate for those "other means". That is kind of OS gimmick.
Re: (Score:2)
It's not really a "gimmick". It usually does work out that way.
Apache can drop official support for them, but the reality is if some major security vulnerability comes out SOMEBODY will probably find it worth their time to go fix it. Given the way the OSS community works, those somebodies usually don't mind distributing their patch.
So while the Apache Foundation won't necessarily have a team working on it, you can bet that you'll probably still get security patches for it as long as there's interest (and
Answer Was Above (Score:2)
As per http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/README [apache.org] the proposal (Full disclosure: I'm colm@apache.org - the proposer), was that we would start distributing security patches via; http://www.apache.org/dist/httpd/patches/ [apache.org]
Thanks, colmmacc.
Re: (Score:2)
OpenBSD still won't include 2.0 or 2.2 in the distribution because the licence is not acceptable to them. I imagine they will continue take an interest in the 1.3 branch.
You can not kill FOSS! (Score:3, Insightful)
All kidding aside anybody with the skills and resources can now take over 1.3 and keep updating it. You can not really EOL a FOSS program if anybody wants to keep it alive. That being said there are other light weight web servers that can do what people are using 1.3 for. Now Apache 2.0 may be a bit harder to replace since the migration isn't automatic from what I hear.
Can Too (Score:2)
anybody with the skills and resources can now take over 1.3 and keep updating it.
And who, exactly, has these resources? This is not something a few hackers can take over and keep maintaining in their spare time. A project this size needs project management, QA resources, bandwidth, and a lot of developer hours.
Apache has done well because it has a robust well-funded organization behind it. That organization exists because a lot of people need Apache to prosper in order to prosper themselves. Yeah, if some of these supporters want to keep 1.3 alive, they can start a new organiz
Re: (Score:2)
"And who, exactly, has these resources?"
IBM, Google, Intel, a large ISP, or a major university.
That is why I said talent and resources, you are completely correct that it can die but not if enough users or powerful enough users want to keep it alive. You could also just keep it as is and just keep adding security patches which would take a lot few resources than active development.
And I really should have clarified that resources part. I was thinking of somebody like say RedHat, Novell, or IBM when I made t
Re: (Score:2)
You forgot to mention Donald Trump.
In addition to the resources, you have to have a sane business case for expanding them. I believe I mentioned that.
Re: (Score:1)
All kidding aside anybody with the skills and resources can now take over 1.3 and keep updating it. You can not really EOL a FOSS program if anybody wants to keep it alive.
OpenBSD's forked version of Apache 1.3.29 already fulfills this role.
Putting closure on a software project is important (Score:5, Interesting)
Putting closure on a software product is important.
Professional software usually has an EOL schedule. For example, RedHat Enterprise Linux and Windows XP both have EOLs for early 2014. This allows people using the software to plan upgrades and know when they need to be making a transition.
This is equally as important for open-source software. It looks really bad when this is not done. For example, Dan Bernstein's DjbDNS software package has three unpatched security holes [maradns.org]. People using this software have to know about these holes and apply third-party patches.
In addition, when the maker of an open-source program says "OK, I'm done with this program.", it allows maintainers to step forward and take over the project. For example, when I announced I would no longer work on a Doom random map generator [blogspot.com] I had been hacking on for a while, someone expressed interest in maintaining the software, and subsequent updates have since been done [blogspot.com].
I think the Apache foundation should either say "OK, we'll still fix security bugs on this program" or "We're no longer maintaining this release". This way, the users of these programs know whether to upgrade, form their own group applying security patches, or just know they're OK from a security prospective if they're current.
I have blogged about putting closure on open-source projects [blogspot.com] and have well defined EOL dates for older releases of my own MaraDNS [maradns.org].
A lot of open-source projects just languish when the developers lose interest; I feel this is irresponsible and feel EOL dates and putting closure is important.
Re:Putting closure on a software project is import (Score:1, Redundant)
Re: (Score:2)
wrong, it is irresponsible of *YOU* to use software which is not activity patched and maintained. Pretty easy to not commit that sin if you stay with high-level distro's maintained packages. But otherwise it's on your head. No one has to maintain software you like just because you wish they would.
Re: (Score:2)
About time (Score:3, Insightful)
Supporting Apache 1.3 is like Microsoft supporting Windows 98. Apache 1.x is almost 15 years and Apache 2.x has been out for 10 years. People have had plenty of time to upgrade. It's time to move on.
I would like to see 1.3 stay (Score:1)
Re: (Score:3, Insightful)
Although 1.3 certainly has a smaller memory footprint without some features I don't need, I usually try to get the best from both worlds. For my applications, I normally use the latest apache, and leverage its memory usage by using any of the following:
Not all
Is Solaris shipping 2.2 yet? (Score:2)
The last install I did of Solaris 10 included Apache 2.0 (.58, IIRC), so there are still new installations going in with 2.0. Since Sun started shipping Apache with the OS, we tend to use it rather than create our own packages or use the Sun freeware versions - theoretically, Sun will support the OS supplied version (never needed support on it, so couldn't say).
I believe the cooltools versions use 2.2, but not sure if the latest 10 releases include it as standard.
Our production estate includes every
Fully backwards compatible, or dead end. (Score:1)
sorry.
im in web hosting and web development business, and i can easily say that majority of the web still runs on 1.3. innumerable scripts, modules, software were coded for 1.3, and there are innumerable websites that still need those stuff. even the clients which start with newer versions are sometimes having to go back to 1.3 because they need some module or software that is uncommon but vital in their line of business.
'obsolete','old','development ceased','not supported' etc do not count. this is about b
Re: (Score:1, Funny)
So, do all people in "web development business" lack the SHIFT key or just you?
Re: (Score:2)
Re:Fully backwards compatible, or dead end. (Score:5, Insightful)
There's no way I can subscribe to the notion that Apache developers (or anyone, really) has an ethical obligation to keep maintaining a 10 year old codebase with any kind of implied guarantee. If there was a contract in place requiring that, then sure; but there isn't such a thing here.
Any people using Apache 1.3 should have really see this coming, and there's absolutely no excuse not to. It's the standard way of doing things in this industry, and if anything, the term was already waaay longer than is common.
Furthermore, the options are also fairly obvious:
1. Upgrade your environment to 2.2 (or pay someone to do so for you and accept responsibility).
2. Keep maintaining 1.3 on your own (or pay someone to do so for you and accept responsibility).
3. Migrate to a different server (or pay... you get the idea).
Now you also say that:
they dont have the funds or possibility to upgrade by themselves
to which I can only reply, "too bad, they should have engaged their brains at some point in the past - they had 10 years to do so". If they're screwed, they have absolutely no-one to blame by themselves.
Of course, in reality, when they realize that the FOSS white knight in shining armor won't save their ass by keeping to provide them quality software for free this time, you can bet the funds will suddenly be found. Furthermore, I suspect that vast majority of those people would actually go with option #1, and just upgrade to 2.2 (and also learn their lesson to keep up with the update curve to a reasonable extent to minimize "late upgrade" expenses).
Or maybe, if there are really that many 1.3 users who absolutely won't move to 2.2, and each one has so little money they can't pay anyone to get them to move to anything else, either (where are they hosting? in the basement?), then, well, the beauty of FOSS is that they can also come together, form some sort of non-profit funded by all of them - with minimal amount of contribution from each - that would hire people to fork and maintain 1.3 for the benefit of all.
Or maybe they can just donate to OpenBSD.
In any case, if people "don't have the means or resources" (which ultimately means "money") to do their business, then they shouldn't stay in that business - it really is as simple as that.
well excuse me, but all of your points are void. (Score:2)
the obligation is not ethical. its practical.
logical words, rationalizations, and even being right wont change the matter.
the success of a project, and ultimately open source depends on people using it. if the people and businesses using it are left out in the cold like piles of crap, by a major project, even only once, the opinion against open source will change. and the masses which were using that software will switch to other providers. very probably closed source proprietory software, because at least
Re: (Score:2)
How many years do you expect 1.x to be supported? 2.x is a bit over 8 years old right now, and as OP notes, it might not run on modern OSs. At some point, people will have to make the change (staying still is for the Amish - not everyone needs to be an early adopter, but doing anything on 1.x is getting very curmudgeonly at this point. You're not going to see a lot of support for ancient software in open *or* closed source environments.
Also, you're not the people if you're thinking this way, you're a busine
Re: (Score:2)
small businesses do not have the funds or time to make any kind of migration. this is a matter of life and death for many. 'necessities' of business, or 'technology' do not make any difference in such a situation. especially during a global crisis.
Re: (Score:2)
Then they will die. The world is not going to stand still for them. Customers arn't going to keep wanting Apache 1.x. OS's will stop supporting it. They won't be able to keep it secure if they stay behind on old OS's, and eventually won't be able to replace hardware when it wears out because such an old OS won't run on it. Changing tax codes might cause their frozen-in-time accountant's head to burst. Changing legal requirements might cause these in-a-rut businesses to fall apart.
Businesses that are so easi
Number 1! (Score:2)
The Apache HTTP server project is one of the most successful and popular open source projects
One of them? Is there any other OS project that even comes close to Apache's impact?
Re: (Score:2)
Re: (Score:2)
Apples and oranges, really. Lightweight http servers just don't serve the same users as Apache.