Slashdot Mirror

Arker: "In this case, because OpenStack is something RedHat is pushing hard .. it might be a reasonable expectation that they would at least be somewhat less than totally rigid about it."

Since when has any Open Source outfit offered 'free' support. The license specifically state that the software is distributed free of charge, not free of support charges ..

Apache License, Version 2.0

"If you are looking for enterprise-level support, or information on partner certification, Red Hat also offers Red Hat Enterprise Linux OpenStack Platform."

Can you not just run the unix kill command as per the first recommendation on the Apache documentation for stopping and restarting Apache?

https://httpd.apache.org/docs/...

Apache struts announced another general availability release that has the fix on April 24th.

This is why you shouldn't read a blog post when the source material is just as easy to read.

Not sure if to mod funny or insightful since "sarcastic" isn't an option...

Perhaps for programmers the need is not evident, but for anyone who writes long documents, it's indispensable. It's indispensable enough that I am still using Microsoft Word for anything that has any sort of header/subheader structure. OO and LO are OK for short letters and memos, but if it has more than 2 headings it gets clunky because of the lack of outline mode.

The core difference between writing text and writing code, which apparently the programmers working on OO and LO fail to grasp, is that writers are producing text which will be read by humans, not executed by machines.You can't just comment out the cruft and do a GOTO jump over that module you decided you don't want, then tell them to go back 17 pages to pick up the information in paragraph 3. Writing needs structure and flow to lead the reader through the material in a way that make the content comprehensible. It needs primary and subordinate ideas. Order and levels of importance are important. In Microsoft Word, collapsing the document into Outline mode and seeing the heading and subheading structure makes the flow of the document visible, and more important, the means to change that flow is on the same screen. There is no interruption in the work flow.

http://www.gigamonkeys.com/code-reading/ seems to understand it, going the other direction: most real code isn't actually in a form that can be simply read .... in order to grok it I have to essentially rewrite it. I'll start by renaming a few things so they make more sense to me and then I'll move things around to suit my ideas about how to organize code. Pretty soon I'll have gotten deep into the abstractions (or lack thereof) of the code and will start making bigger changes to the structure of the code. Once I've completely rewritten the thing I usually understand it pretty well and can even go back to the original and understand it too.

Which leads me to "Issue 3959", wherein writers asked for this on 2002-04-10 20:39:19 UTC ... it's ranked as "Trivial" now. It has nothing to prevent implementation except the inability of the code maintainers to accept that writers really do know what they need in their tools.

Here's the overview of Bug 3959 ... https://issues.apache.org/ooo/...

OVERSHOOT wrote upstream: Ah, yes. Issue number 3959. Originally filed April 10, 2002. More than twelve years ago. In that time it has remained in the top-voted issue list year-in and year-out. Others come and go, but 3959 keeps on pissing off users. At last look, there are about ten duplicates requests on file.

Every few years some developer wanders by and tells the people following it that nobody needs outline view, or that there are tools available to do it, or whatever. Often, they close the issue. In effect, "I don't use outline mode so obviously it's not important." The mailing list heats up for a while, the developer either mumbles something about maybe the team should look into it and vanishes or else just vanishes, but the issue is either reopened or left open. I've seen at least four of those cycles so far. We're probably due for another one.

At this point, I suspect that 3959 will outlive (Open|Libre|Star)Office for the classic open-source software reason: if it doesn't scratch a developer's itch, it ain't happening. And apparently, developers don't outline, edit, or otherwise structure their writing or much care about the people who do.

As the wisdom of XKCD proves - http://www.xkcd.com/619/

Steve Jobs was a brilliant CEO. A brilliant product manager. Also, a tyrannical, narcissistic douchebag, if the press accounts are true.

I'm guessing something like this is just a continuation of that. Corporate culture is set at the top level and it permeates the company.

Here are a list of platinum level (100K USD and above) donors to the Apache Software Foundation. List of sponsorship levels here

People are talking about providing code to open source, and certainly that's the core of it. But big projects need cash for organizational and administrative purposes.

Steve Jobs was a brilliant CEO. A brilliant product manager. Also, a tyrannical, narcissistic douchebag, if the press accounts are true.

I'm guessing something like this is just a continuation of that. Corporate culture is set at the top level and it permeates the company.

Here are a list of platinum level (100K USD and above) donors to the Apache Software Foundation. List of sponsorship levels here

People are talking about providing code to open source, and certainly that's the core of it. But big projects need cash for organizational and administrative purposes.

I'm voting for (a) with a helping of very-not-(c), given:

- the comments on https://issues.apache.org/jira...
- this story http://www.infoq.com/news/2014...
- and this twitter conversation https://twitter.com/gstein/sta...

Does the APL and GPL require granting the public a license to all of Apple's patents, or does it only require granting a license to users of the software when they use the software

The Apache license (read it now) requires each "Contributor" to a covered program (those who modify it, as Apple would when porting Android to its device) to grant a license to its "patent claims licensable by such Contributor that are necessarily infringed" by the program.

I base this on section "3. Grant of Patent License" in the license of Android.

This may explain why the incredibly ancient feature request for an "Outline View" in OpenOffice has gone over a decade (Reported: 2002-04-10) with no resolution.

https://issues.apache.org/ooo/...

The mental mapping of code for programmers and the mental mapping of text to those of us who write literature and non-fiction is totally different. They can't visualize how an outline and headings and the cues fonts give readers differs from all the "mind maps", "document navigators", and other inadequate replacements they keep suggesting will fill the need.

due to low numbers of people working on the project.. but here's an idea.. GET INVOLVED. https://incubator.apache.org/wave/get-involved.html

I think it's actually a little of each. Look at the apache POI project for supporting microsoft document formats in enterprise java apps. from wikipedia:

The name was originally an acronym for "Poor Obfuscation Implementation", referring humorously to the fact that the file formats seemed to be deliberately obfuscated, but poorly, since they were successfully reverse-engineered.

The other acronyms in the project, such as HSSF (horrible spreadsheet format) are equally revealing.

OpenMeetings is an Apache Foundation project. Java-based client. The feature set is overkill for support, but it supports voice chat and screen sharing.

OpenMeetings is an Apache Foundation project. Java-based client. The feature set is overkill for support, but it supports voice chat and screen sharing.

So? gcc has much better support for C++11 and C++14

Much better? Maybe "a tad better" And the things icpc is missing are not so important. But that wiki (while the best reference for it that I know of) is out of date, so if you are comparing the latest version of each, I think you'd find that they are fairly compatible.

Oh, and their C++11 support is atrocious.

From the Apache Flex webpage:
What happens to my projects if Adobe Discontinues the Flash Player?
It is true that current Flex projects are tied to either the Adobe Flash Player or Adobe AIR. We have been making great strides to compile projects to native JavaScript, therefore bypassing the Flash Player in the browser. Adobe has made a commitment to support the Flash Player and our current runtime for at least 5 years from the time they donated the project to Apache.
--
See for example the FlexJS project, that intends to run Flash directly on a JavaScript VM instead of the Flash Player VM.

From the Apache Flex webpage:
What happens to my projects if Adobe Discontinues the Flash Player?
It is true that current Flex projects are tied to either the Adobe Flash Player or Adobe AIR. We have been making great strides to compile projects to native JavaScript, therefore bypassing the Flash Player in the browser. Adobe has made a commitment to support the Flash Player and our current runtime for at least 5 years from the time they donated the project to Apache.
--
See for example the FlexJS project, that intends to run Flash directly on a JavaScript VM instead of the Flash Player VM.

Apache Flex (available at http://flex.apache.org/) became the natural progression after the proprietary strategy by Adobe failed.

There is never a way to predict the future... merely expect change and anticipate failure. When new frameworks are available, there are typically code-conversion utilities that demonstrate (or incite an appearance of) maturity. As any new technology is presented, the strength of attendance AND technical prowess of the developer community surrounding the technology is a reliable indicator to its longer-term viability.

A simple measurement is this: IF the tech should last for 4 years, then how much history and roadmap (and financial backing) is equally present? If there are sufficient history and roadmaps present, then how sound is the technical basis for the framework? Should the basis and direction apply to your problem, then it becomes a viable solution; otherwise, look elsewhere because it doesn't matter whether it sticks for 10 years or 10 months, it still won't solve your problem and thus be a viable option for you or your projects (or career).

It can't even do basic stuff properly. It's even more buggy than MS Office. Even simple things are broken.

For example this bug has been around for years:
https://issues.apache.org/ooo/show_bug.cgi?id=15501
Basically you can't step by step find within a selection and choose which found item you want to replace.

I just wasted time downloading and installing 4.1.2.3 and the bug is still around after TEN YEARS!

They even regressed this feature in their spreadsheet (e.g. it worked, then they broke it, then they fixed it (recently): https://bugs.freedesktop.org/show_bug.cgi?id=53106 ).

OpenOffice Impress used to bother me a lot too - formatting presentations was just much harder than it needed to be - had to fight it a lot with text sizes. I hope it's better now.

If you don't use the bleeding edge Microsoft Office, you don't encounter as many "obvious" bugs like that.

Why would NASA send Maven to Mars? Are they building Java apps up there or something?

http://maven.apache.org/

Never believed NASA was a waste.... Until now...

They all suck for specifics. _All_ of them. If it's not written specifically for your business, you're not going to be very happy. If you want something that's not perfect pretty much by definition, you might as well consider something from Apache.

http://httpd.apache.org/docs/2.2/rewrite/access.html

LibreOffice is replacing the shitty HSQLDB database with Firebird, which actually works, is actually maintained, and is not written in Java, so this stuff will not happen any more.

Apache OpenOffice of course is trying to cover up just how shitty Base with HSQLDB is.

If you're CPU bound, use sa-compile. It made a P4 regularly hitting 1.0 load drop down to 0.6

http://wiki.apache.org/spamassassin/FasterPerformance

Check out this link: http://projects.apache.org/indexes/quick.html

Granted, not all of these are of the highest quality, but it may jog your memory of a few projects which are used in high demand environments everyday.

• Open Source Medical Record System
• Natural Language Processing of Physician Notes
• Wikipedia list of FOSS Health-IT projects

He pulled up his browser and typed into it the words: Free Subversion Repository. Up popped a list of places that stored code, for free, and in a convenient fashion. He clicked the first link on the list. The entire process took about eight seconds. And then he did what he had always done since he first started programming computers: he deleted his bash history. To access the computer he was required to type his password. If he didn't delete his bash history, his password would be there to see, for anyone who had access to the system.

What? It is possible to put your password on the command line with subversion, but why would you do that if you are going to delete your history? Why not just let subversion prompt for a password (or use a keyring to store it)?

I'm not an svn user, but according to the release notes on http://subversion.apache.org/docs/release-notes/, storing paswords on keyring wasn't a feature until 1.6, which was released March 20, 2009. He apparently uploaded the code changes around that time, but may not have been using that latest-and-greatest release.

Even rm ~/.bash_history isn't failsafe security since the temp copy is sniffable on nfs (in cleartext!) before the end of the session.

The jclouds framework enables abstraction of your cloud (read: IaaS) layer. I don't work for these guys but I've seen it used in several tools. Using tools based on jclouds makes it easy to shift your deployments from one cloud to another, be it public or private. There are other concerns when doing that, such as synchronizing the data that needs to be available in each specific deployment, but there are tools for that as well.
Here is a quote from their "What is jclouds?" page:

jclouds is an open source library that helps you get started in the cloud and utilizes your Java or Clojure development skills. The jclouds API gives you the freedom to use portable abstractions or cloud-specific features.

jclouds tests support of 30 cloud providers and cloud software stacks including Amazon, Azure, GoGrid, Ninefold, OpenStack, Rackspace, and vCloud...jclouds offers several API abstractions as Java and Clojure libraries. The most mature of these are BlobStore and ComputeService.

The problem is that Apache is more of a BSD license and Libre is GPL, no point in starting up THAT old flamewar so lets just say they agree to disagree and move on.

Actually, they agree to cooperate and move on.

3."Do you share code with Libre? sub question A: If so, will you soon both be even more similar -- in effect unforked? Sub question B: If you are not using each other's code, why not?"

We cooperate and coordinate and share with LibreOffice, as well as other open source and even proprietary application vendors, in several ways

https://blogs.apache.org/OOo/entry/your_top_questions_answered

That's the great benefit of FOSS projects. Their goals don't include locking users or developers down.

My point was entirely relevant and you're just trying to weasel out of it with a false dilemma. Then you attempt to sweep inconvenient facts under the rug as "irrelevant," and you have the bombast to attempt to portray your willingness to do so as generosity. Such an argument is worthy of Schopenhauer's Art of Being Right; for you to argue in such a fashion and then perpetually loudly claim that everything anybody else says is fallacious is pretty laughable.

You were saying there are tons of LO contributions being dual-licensed for AOO inclusion because all those who "don't care about the license bullshit" are "happy to work with both projects." I countered that the dual-license contributors are not that numerous, and that an absence of philosophical objections to the Apache license does not entail a willingness to license LO related work for use by AOO-- in particular, some people have become unwilling to do so because of the caustic, acerbic, and rude behavior that has been exhibited on the AOO dev list and elsewhere.

Any search for your posts here, at lwn, or on the Apache mailing lists will turn up this kind of stuff. From the security list debacle two years ago to the present, just about any time you've opened your mouth you've alienated people, including many who might otherwise have contributed in some way to AOO's success. I haven't been following aoo-dev for a while, and I'm not on top enough of all the drama you generate to give an itemized list here, but it doesn't take much looking to find you behaving like an adolescent and people being disgusted by it.

In any case, I too am done talking with you. Maybe once you've driven AOO into the dirt with your toxic "leadership" and been let go by IBM you'll rethink your ways of dealing with people.

It is not quite true to say this was just a merge from Symphony. Actually, your statement is entirely false. The core Sidebar was reimplemented in AOO 4.0, by developers at Apache. One of the core goals was to make it a framework that could be used by Extension authors as well.

You can read more details on this in this blog post:

https://blogs.apache.org/OOo/entry/the_sidebar_new_and_improved

And as I've said before, it is regrettable that LibreOffice supporters find it so difficult to graciously accept good code from a good project. No one, absolutely no one, is complaining about you using it. It is under the Apache License, free for LibreOffice or anyone else to use it, now and forever. Although the license says nothing about polite manners, and I never expect to hear even the smallest statement of thanks, I think the larger open source community does find it disturbing that LibreOffice supporters are so eager to take code from AOO while continually insulting it at the same time. Remember, using code from other open source projects does not make you smaller. We all "stand on the shoulders of giants", so try not to piss on them, or upstream in general.

Does your product even filter spam? How? When a virus is delivered via email, your tool does nothing. When an IP link is clicked, your tool does nothing. Against a 419er's solicitations, your tool does nothing. When faced with a fresh malware link, your db may be up to 12h out of date and lack an entry for it.

You claim your product is accurate. Prove it. Spamassassin is free and open, you can look at the source. Its efficacy is demonstrated daily. There are plenty of third party reports over the last 10+ years demonstrating its utility. SA has millions of users and hundreds (at least) of contributers. How about your tool?

You claim your product is fast. Perhaps it is leaner than Spamassassin (with SA's Bayesian filters and regular expressions, as you note, it almost certainly is), but Spamassassin runs on servers. It consumes zero disk, zero memory, and zero CPU on user systems.

I put my Spamassassin developer status on my resume. Sure, I'm not the sole dev of SA, but that's a feature. I can work on (and lead) a team. If I go away, the project will continue without me. Do you put APK Hosts File Engine on your resume? Whatever would people think when they search for it? ... oh, never mind, a quick search yields your full name attached to these shenanigans anyway. How then could my Fortune 100 employer hire you into any team?

Oh, and so you know it's "me" to the same level of clarity as I have for you,
Khopesh

The summary does not tell me what this thing, apparently popular in Beijing, actually is! You could at least link their website. :)

Anyway, looking at their website, it looks like it's a "cloud operating system", i.e. infrastructure for managing a cluster in a virtualized, "cloud-like" way. Does anyone know how it compares to other such platforms, like Eucalyptus and the confusingly-similar-in-name CloudStack?

here ya go.

Displaying page boundaries, headers & footers, etc is of exactly zero benefit while one is composing the text of the document.

I beg to differ, sir!

It is not exactly zero benefit. It is actively distracting, and hence of negative benefit.

Incidentally, there's an 11-year-old bug report with 281 votes (there are only two bug reports with more votes) if you want to add your voice. I rarely use word processors (Latex here, as much as I hate it there's not really anything better for what I need), but if I did, I'd use Word almost on account of the lack of a normal view alone.

It does in many way sounds like it could be exploited as a tax dodge too. And the thing is, these would be companies free/open source people wouldn't have ever heard of, because they would be fake.

That seems like a conclusion jumped to with not a single example.

Check out the first line on this page: http://www.libreoffice.org/about-us/
Or this IRS letter proudly displayed on the Apache Foundation. http://www.apache.org/foundation/records/ASF-501c3.pdf
Or the statements on the Samba website: http://www.samba.org/samba/donations.html

These are hardly companies you have never heard of.
But each of them have probably taken a lot of money out of the pocket of other big players in the industry.
Players that have influence. Players that hold grudges. Players that can write letters and offer campaign donations.

This isn't about catching fake companies, its a political payback for large corporations.

The thing about a non-profit is that it really doesn't reduce tax revenue much at all. The money has to go somewhere, to the employees as salary or perks that have to be reported on their tax forms. It all gets taxed in the end.

I'm a Subversion developer and would like to clarify this bit of the summary:

Major new features of 1.8 include switching to a new metadata storage engine by default instead of using Berkeley DB, first-class renames (instead of the CVS-era holdover of deleting and recreating with a new name) which will make merges involving renamed files saner, and a slightly simplified branch merging interface.

The "new metadata storage engine" probably refers to FSFS which has been the default repository backend since Subversion 1.2. FSFS has been improved since then, and 1.8 contains some new improvements (such as directory deltification) but does not add a new repository backend. The BDB-based backend is the one from Subversion 1.0 and is rarely used these days.

Subversion 1.8 doesn't contain support for "first-class renames". Renames are still modeled as copy+delete, with special annotations. The working copy is so far the only part of the system which is aware of moves. There are plans to make other subsystems aware of moves in future releases. Also, while tree-conflicts involving local moves can now be auto-resolved after 'svn update', 'svn merge' mostly behaves as it did in 1.7, expect there is no need to use the --reintegrate option and tree conflicts are now flagged if a directory was renamed or deleted on the merge source branch. Whereas Subversion 1.7 would unconditionally perform the deletion in the merge target.

Most of Android is under the Apache License. If Microsoft customizes Android for its own hardware and distributes it, Microsoft becomes a "Contributor", and a Contributor gives up some power to assert its patents against other distributors of the software.

Have a look at Apache VCL: http://vcl.apache.org/ - it is a cloud computing system developed specifically for use in the education space.

It's almost obsolete already on modern Linux installs
See here for how to get past it and the system configuration needed to do so.

I doubt they have the storage capacity.

Never heard of Hadoop?

Apache directory

It's included in Slackware 14.0 and Slackware current.

But there is a bug in "htpasswd" (bug 54735), which has not been backported to the "2.4.x" branch yet.

Which of course, you should never do, since .htaccess will grind the performance of your site directly into the ground. It also means that anyone with access to the filessytem (such as an already-hacked WP instance) can revert your changes.

http://httpd.apache.org/docs/2.2/en/howto/htaccess.html#when

I see a lot of posts around the topic of "Just use PHP/Rails/etc now, worry about scale later." I disagree, it doesn't take THAT much more effort to think about scaling up front, and develop the correct solution now, so that you don't have a (or multiple) panic re-orgs. The key is getting something that scales from small to big somewhat effortlessly. Nothing will scale perfectly. So here's my recommendation:

1. Use RackSpace - I've seen this mentioned before. And I agree, RackSpace or some other OpenStack provider will ease your IT pains as you grow, plus you can start small.

2. Use Nginx - It is as easy to setup as Apache (some say simpler) and can connect to most anything apache can. A micro-sized VM from Rackspace (256MB RAM) is more than enough if this is the only thing running -- and it should be. I actually perfer the OpenRESTY build of Nginx, the extra modules allow for some nice improvements over the vanilla system. For example, off-loading your session management/timeout/login to the webserver so that the backend doesn't have to do it.

3. Use Java - Two reasons, first, use what you know. You are going to be the only programmer to start, so it'll be the fastest way to get to market -- VERY important with your new venture. Second, While the fancy "Java Extensions" like Grails, Scala, etc have some nice features, it's just syntactic sugar in the end. Why add a layer of indirection, also there are more Java developers than Scala developers so your talent pool is larger. If you want a framework to help you get going quickly, use Apache Camel. It's an excellent framework for handling traffic from all sorts of places, they not only support HTTP/REST, but SMS, Message Queue's, Email Systems, IRC, and a lot more.

4. Use Static HTML , JSON, and AJAX. Template languages are soooooo 2008. To get tha tweb 2.0 appeal (and scalability) you cannot have template engines chugging through producing HTML on the server. Use your Nginx to serve static page, call your java servers to get the raw data (in JSON) and use a client framework like jQuery to produce the output on the browser. If you are going to scale to tens-of-millions of users, you are going to need to push as much work to the client as possible. If you MUST use a template language use a light-weight one like HandleBars or Velocity.

5. Use RIAK - I'm making an assumption that your social application is going to need the noSQL/document-oriented type database over the traditional SQL DB, if only for the sheer amount of data you will be storing. RIAK is simple to setup, simple to use in a small environment (1-3 servers) but has massive horizontal and vertical scaling options. We routinely push millions of records a day into it, and use it's built-in map/reduce functions to process the data as we need it. It's a bit memory hungry, I recommend a 4GB RAM VM at a minimum, but it will grow with you without having to re-engineer core parts of the system.

So, in comparison to the LAMP framework of the past, I offer the ONRAC framework (OpenStack, Nginx, RIAK, Apache Camel) Not as catchy of a name, but exactly what you need to scale from a few 1000 users to tens-of-millions.

I see a lot of posts around the topic of "Just use PHP/Rails/etc now, worry about scale later." I disagree, it doesn't take THAT much more effort to think about scaling up front, and develop the correct solution now, so that you don't have a (or multiple) panic re-orgs. The key is getting something that scales from small to big somewhat effortlessly. Nothing will scale perfectly. So here's my recommendation:

1. Use RackSpace - I've seen this mentioned before. And I agree, RackSpace or some other OpenStack provider will ease your IT pains as you grow, plus you can start small.

2. Use Nginx - It is as easy to setup as Apache (some say simpler) and can connect to most anything apache can. A micro-sized VM from Rackspace (256MB RAM) is more than enough if this is the only thing running -- and it should be. I actually perfer the OpenRESTY build of Nginx, the extra modules allow for some nice improvements over the vanilla system. For example, off-loading your session management/timeout/login to the webserver so that the backend doesn't have to do it.

3. Use Java - Two reasons, first, use what you know. You are going to be the only programmer to start, so it'll be the fastest way to get to market -- VERY important with your new venture. Second, While the fancy "Java Extensions" like Grails, Scala, etc have some nice features, it's just syntactic sugar in the end. Why add a layer of indirection, also there are more Java developers than Scala developers so your talent pool is larger. If you want a framework to help you get going quickly, use Apache Camel. It's an excellent framework for handling traffic from all sorts of places, they not only support HTTP/REST, but SMS, Message Queue's, Email Systems, IRC, and a lot more.

4. Use Static HTML , JSON, and AJAX. Template languages are soooooo 2008. To get tha tweb 2.0 appeal (and scalability) you cannot have template engines chugging through producing HTML on the server. Use your Nginx to serve static page, call your java servers to get the raw data (in JSON) and use a client framework like jQuery to produce the output on the browser. If you are going to scale to tens-of-millions of users, you are going to need to push as much work to the client as possible. If you MUST use a template language use a light-weight one like HandleBars or Velocity.

5. Use RIAK - I'm making an assumption that your social application is going to need the noSQL/document-oriented type database over the traditional SQL DB, if only for the sheer amount of data you will be storing. RIAK is simple to setup, simple to use in a small environment (1-3 servers) but has massive horizontal and vertical scaling options. We routinely push millions of records a day into it, and use it's built-in map/reduce functions to process the data as we need it. It's a bit memory hungry, I recommend a 4GB RAM VM at a minimum, but it will grow with you without having to re-engineer core parts of the system.

So, in comparison to the LAMP framework of the past, I offer the ONRAC framework (OpenStack, Nginx, RIAK, Apache Camel) Not as catchy of a name, but exactly what you need to scale from a few 1000 users to tens-of-millions.

Although Struts 2 is a complete rewrite, it's backward compatible with Struts 1.

Rubbish, it has entirely different concepts, architecture configurations and just about everything. There are migration tools, but these are far from automatic.

Developers have had years to start making the switch.

True, but many haven't because if you have a website in maintainance mode (a small number of upgrade and changes) it is hard to get approval for an upgrade if what you are using is still supported. I am actually pleased that it is now at end of life, we have been wanting to evaluate new frameworks and upgrade for ages but not given the budget.

It's just Struts 1 that is being EOLed. Given that Struts 2 was 6 years old in February, developers had plenty of time to switch to Struts 2. The current release is 2.3.12.