Hi All,
I’ve been playing around with QoS and other router software, and I was wondering is there an official roadmap for ipfire? Specifically when will the kernel version be bumped to 4.19 ( currently on 4.14). I ask because I am waiting for CAKE to be in the kernel
https://www.phoronix.com/scan.php?page=news_item&px=CAKE-Qdisc-Linux-4.19
At the moment there are no plans to update the kernel.
I will not update from a extended LTS kernel 4.14 that has support until Jan 2024 to a kernel 4.19 with EOL at Dec 2020.
Ok let me rephrase the question. Is adding CAKE to IPFire on the roadmap?
That’s why you take LTS 5.4.
We know that 
Currently not. We have fq_codel and make some bigger improvements to the QoS recently:
Although it would be nice to integrate cake, I do not see a game changer in terms of performance or anything else. It will decrease CPU load slightly, but I suppose that normally is not a problem.
If you want to work on it, you are welcome to do so.
I don’t know if such a strong response is necessary. I do find it frustrating that we seem to be using some older packages and the tree is getting stale.
Don’t get me wrong ipfire can do QoS and traffic shaping better than pfsense. I’ve tested it and it’s a night and day difference in quality. Is there room for improvement? Especially at the 1Gb/s level. Absolutely.
Exactly because security. As Arne wrote in this exact thread, 4.14 is a LTS kernel and has security support until 2024, while all the others have way shorter support life. Being IPFire a small project it has not the resources to do everything, so they have to make a priority choice. Updating the kernel without introducing security risk bugs is a major endeavor which they cannot afford to do too often. And they have to progress to IPFire 3, which will eliminate the barrier of only 3 zones and introduce IPV6. As much as the CAKE feature is useful, these two I mentioned have a higher priority for a firewall. And even then, we are years away from that goal. IPFire has very few developers behind it.
I understand your frustration, however the reality is that If you want to accelerate the cycle, either you contribute to the code or you contribute with money so that someone else can spend his/her time doing that and get a fair wage for the labor.
Money can’t buy you any time. So it’s all about manpower. The older I get, the more I understand that fact.
it can buy developers time that otherwise is going to be used to do something else that pays the bills. The IPFire project needs to be funded by its users.
Why am I against it? Because it technically does not make any sense and causes a lot of work. Have you never checked what kernel RHEL or Debian are running on? IPFire is not doing anything differently here.
The kernel is not old. In the development tree is usually a kernel that is not older than a week since its release. They are all starting with 4.14 currently: git.ipfire.org Git - thirdparty/kernel/stable.git/shortlog
Good luck with that. And indeed thank you for the tone of your message.
What is frustratingly old?
In a business it does.
I think it’s a little bit more then that. Everybodies day has got 24h. You have to sleep, take some time with your family, sports and hobbies and you have to work. Sure if you don’t take your work time for the project, because you don’t get money for it, but have to earn money to finance your life. If you get some money to support the project and finance your work you may take more time for the project, but that will only be possible if you are self-employed. And still your time is limited, independent how much money you get to put some work into the project. Therefore you need manpower.
I don’t know if such a strong response is necessary. I do find it frustrating that we seem to be using some older packages and the tree is getting stale.
What is frustratingly old?
Obviously I understand that this isn’t a full blown distribution that I can just run apt install on. However when I want to get statics off box with what is there, aka collectd, I find out we have a forked very old version.
I would like to have the ability to put netflow on the box, I’m not saying that ipfire has to be opnsense or anything like that, as a matter of fact I much PERFER ipfire and it’s use of linux as a kernel. I’m probably not the average user of ipfire, I get that. For example I want to put in a couple more network cards in my box because I want to do link aggregation from my Cable Modem ( Comcast multigig Docsis service).
I’ve worked around some of this by mirroring the output ethernet port of ipfire on my switch to another computer ( for netflow analysis).
Maybe it’s just a matter of digging in and figuring out how to compile packages with the ipfire 2.x source tree. I’m open to just about anything.
Hi all,
in the old forum are some examples according to this topic, not sure if this interesting for you
Just to mention some of them. Some packages are surely outdated but there are plenty of possibilities with your own DEV environment.
Just a beside one.
Best,
Erik
@ Arne.F [ Comment 1 ):
Perhaps you do not need to do it lonely all by yourself,
because others are in same urgent need for “quality and longevity of products”:
. . . Linux “Super Long Term Support Kernel”:
. . . 4.19 supported until 2029+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . <— !
. . . “Upstream first” policy
. . . Release twice a month (second and fourth Fridays)
“The Civil Infrastructure Platform (“CIP”) is a collaborative, open source project
hosted by the Linux Foundation.”
[ https://www.cip-project.org/ ]
Nothing of that is upstreamed.
ipfire’s collectd is a forked version…
I understand why, but the farther we get away from the mainline the more features we lose.
I am all about digging in and helping… I did embedded C for 15 years on Set top Boxes doing digital encryption and embedded DOCSIS cable modems. I’ve written kernel ethernet drivers.
I’m now doing devops type stuff so I can totally get involved, happy to do so.
Hi Michael,
this was meant in first place as “plenty of possibilities with your own DEV environment.” including some possible hints in the specifics if needed.
Can also push some of them if there are some interesting ? Even some of them are as mentioned outdated (fprobe last update 2005, NFSen makes no sense without PHP) but the rest seems to have an active development.
Best,
Erik
Addendum: Reference:
“I go into why older kernels are supported longer in my big “What stable kernel should I run” post at http://kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/ See the section about “Older LTS releases” at the bottom.
Normally I say I will support LTS releases for only 2 years, …
But I am not promising to do that just yet. Plan on getting your code upstream and then it doesn’t matter about the length of a LTS release at all, you can just update to the next major LTS release each year and all is fine. That’s the safest and best thing to do, you never want to be running older LTS kernels unless you are forced to by a horrible SoC vendor who is holding your kernel version hostage.”
…
If you look at the history of that page over time, the projected end of life for 4.9 was originally just over 2 years, but Greg has continued to maintain it and extended the expected end of life.
…
So it will pretty much always be the case . . . . . . . . . . . . . . . < - - - !
(unless policies or practices change) that
the latest LTS has an expected lifetime of two years, . . . . . . < - - - !
but older ones will have longer expected lifetimes. . . . . . . . . < - - - !
[ https://www.reddit.com/r/linux/comments/aa6ou5/why_are_the_lts_kernel_releases_being_supported/ ]
I am very interested in pmacct. Please make this one official.
Why you think it is a fork?
IPFires collectd is the latest collectd 4.10.x you can get this here: Index of /files
wget https://collectd.org/files/collectd-4.10.9.tar.bz2
--2020-02-08 10:35:57-- https://collectd.org/files/collectd-4.10.9.tar.bz2
Auflösen des Hostnamens collectd.org (collectd.org) … 62.128.13.221, 2001:780:0:1e::c
Verbindungsaufbau zu collectd.org (collectd.org)|62.128.13.221|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 1287153 (1,2M) [application/x-bzip2]
Wird in »collectd-4.10.9.tar.bz2« gespeichert.
collectd-4.10.9.tar 100%[===================>] 1,23M 540KB/s in 2,3s
2020-02-08 10:35:59 (540 KB/s) - »collectd-4.10.9.tar.bz2« gespeichert [1287153/1287153]
md5sum collectd-4.10.9.tar.bz2
980dd3387508f9ad209df04a6f7a126c collectd-4.10.9.tar.bz2
Newer verions needs many other changes. If someone has time to do its a good Idea to update this of course.