Hello,
I’m using FreePBX and PBXact. I noticed that these are using old ditro images. For example currently I’m on:
Redhat ended support on October 2020 for version 7.8. And the kernel was compiled in 2020.
I’m bring this up because because when I started using FreePBX like 2 or 3 years ago I submitted a few bugs and other problems (some minor, but easy to fix). I just checked all this tickets and they are still open and unresolved. Sometimes with a reply like “we will look into this” or something similar.
So now that I see that these bugs haven’t been resolved I wanted to check what kernel version was being used.
I’m worried that development on bugs and reported problems are not being addressed.
@lgaetz may havee an answer for thee distro. I think there were plans to do something based off of Rocky Linux 8 peer thee last post on this. Not sure the direction of that.
For bugs feel free to paste links here. It may not help but it couldn’t hurt
Indeed, there is a plan to create a new distro based on Rocky Linux 8.
On going.
Why even bother at this point? This plan has been “on going” since the launch of Rocky 8, it’s been over 18 months. By the time FreePBX v17 is released there is going to be roughly 12-18 months before Rocky 8 enters the “5 years of no updates just required security fixes” phase. I mean unless the plan is to always release a distro that only gets security fixes for 5 years at a time. No feature enhancements or new adds just security fixes as needed. At this point, since nothing has really been done why not just work off of Rocky 9 which was released like 6 months ago.
This is the same with PHP, there was talk for a long time about moving to PHP 7.x and it took a community member to do it. When FreePBX v16 was released with PHP 7.x support it was released one month before PHP 7.x went SFO and now next month PHP 7.x dies for good. Right back in the same boat as PHP 5.x. So will FreePBX v17 see PHP 8.1 or greater support (8.0 goes SFO next month)?
This, of course, doesn’t cover any of the other things being used by FreePBX that are outdated and throw deprecation errors during installs/updates.
Sounds good… I have asked this question in the past but it was never a certain answer like yours. My only concern - why not Rocky 9 at this point?
Creating a distribution takes a lot of time. Need to do a lot of testing and be sure everything is working as expected. Noway to migrate it and we will see later if that works.
Need to adapt some Sangoma rpms…Etc
Seems to be easy for everyone, but easier said than done.
For now, we are working on Rocky Linux 8. So, no plan for 9 so far.
Makes sense. Do you have a rought ETA for a beta version that can be tested?
Unfortunately no for now.
Hoever, A beta version will be shared I think, but I don’t know when.
Not really. I mean, I cannot do it, that is true.
But many, many organizations create solutions and keep up to date with slow moving upstream distros such as RHEL and Debian.
We are not asking you to keep up with something like Fedora with bi-annual version updates.
This entire project is a wasteland of dead old code. PHP, APP_MACRO, CHAN_SIP, the operating system.
There is only 1 reason of this. The owners have chosen not to do anything about it.
Look at app_macro. It was depreciated in Asterisk 11, in 2012! We are 10 years later and there has been zero effort to clean up FreePBX to free it from app_macro.
The OS and is horribly decrepit and, as mentioned, the only reason PHP 7 was even implemented was because a community member did it.
Chan_SIP at least was only depreciated in 2019. But we’ve already been told that FreePBX will still have an option allowing it to be added back in.
Sure this costs money in employee time to update. Yes, you (Sangoma) will have to get nothing in direct returns for it. That is what it means to commit to open source.
So how about you (Sangoma) stop making excuses and follow through on this commitment.
Actually, it was deprecated in 1.6.0, but I think Digium then formalised the deprecation process better around Asterisk 11.
I’m retired now, but, in my experience (not with any of the companies mentioned here), this sort of thing also applies to a commitment to Microsoft. Keeping up with the latest technology is expensive and risky, and businesses do tend to put it off, as it involves significant rewriting, and a high risk of regression failures.
Incidentally, accountants depreciate, but IT people deprecate. They are not the same.
The original distro was created by Schmoozecom (much later acquired by Sangoma). Then the update which aligned with all of the upstream trademark requirements based on EL 7 was created/ported whatever you wanna call it by @xrobau . He also built the tools and processes to maintain it from the upstream. Meaning automagically taking upstream srpms, stripping trademarks as required packaging and adding to the repo. This part is simple enough anyone who can read can make it happen with the tools in place.
To create a new distro all of this tooling has to be updated or re-implemented. They are definitely not going to pay him to consult and I am sure he would not accept the offer. At the end of the day they need to have (pay) someone with this skill set and I don’t see it happening. Alternatively (likely the current case) Someone has to take the time to figure it all out.
When I left Sangoma in 2019 I worked with Matteo Bignotti (@mbignotti) on taking over and maintaining the distro (as I took it over from @xrobau). Matteo was the distro maintainer for Switchvox. (see Sangoma 7.6 Distro GA)
Since it looks like Matteo’s account here is broken I suspect it’s been deleted. Those of us from the Schmooze days retained our accounts because we never migrated to Microsoft Active Directory for our logins. So when accounts disappear it means the person left Sangoma.
According to linkedin he’s still there: https://www.linkedin.com/in/matteobignotti/
He was the person in charge and leading the distro. However his boss left last year and then Matt left earlier this year so no idea where the priorities are at now.
It depends on how many zeros follow the most significant digit. 
In this case, money isn’t what is a factor.
That was a joke, though I’m pretty sure that for the correctly outrageous amount anybody would consider it deeply. I don’t pretend to speak for @xrobau in any form, of course. Just considering human nature.
I know it was a joke, I saw the emoji at the end. I was saying money isn’t a factor here due to the dispute that happened about 18 months ago or so between said parties. That is a bigger factor than money in this case.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.