I went to https://www.ipfire.org/fireinfo/releases to see the level of adoption for the latest release. I was surprised to see the crazy preponderance of installs at CU183. What’s with that?
Two possible causes:
- ‘never touch a running system’ ( a sentence bad boys do not obey
) - Fireinfo switched off
Do dead or non-reporting systems ever age-out of the Fireinfo data set ?
Good Question - they should be…
It shows the current status of all the enabled to be sent systems within a 24 hour period.
If you have said yes to sharing the fireinfo then IPFire runs a fcrontab entry to send the current profile status once per night between 23:00 and 04:00.
Those time periods are local time based so the status update times will vary depending on where you are and the random period chosen for the sendprofile update.
Wow, It is amazing that so many live systems are running CU183!
This is definitely not good. Update your systems people!
Hello and good day everyone.
Sorry for the question, but does a system that doesn’t send its information, say for more than 12 months, remain among the devices, or is there a policy to delete all those machines that don’t update their data for X amount of time?
Never understood that in IT. It may have been somewhat valid in the 80’s and 90’s but once the software development picked up pace, and security related challenges with that, it became utterly false.
Perhaps in an extremely isolated system in a basement in a cave under a mountain or some such…
I understood in IT, but never in informatics.
A bit OT:
The sentence describes a system which finally ‘runs’, but it is not known why.
In software development there are so many ways to prove the effectiveness. First step in my professional time was the question: “How does it work?”. Answer produces two parts
- first topics for a verifcation
- possible design errors
The latter is sometimes a ‘mystical discovery’.
Yeah, that is true. 
Actually more now than ever since all systems are so complex.
Over the years, we have seen an ever-increasing software stack.
A Linux system may be considered secure, but even the kernel depends on countless components developed by others, starting with the firmware. No single person can realistically master the entire stack anymore.
Security is only as strong as its weakest link. Every day, new vulnerabilities are discovered somewhere in that chain.
Every update inevitably brings changes, and with those changes come bugs that are identified and fixed over time. Our experience with recent Core Updates shows that some functional issues are only discovered after release, despite the testing that has been carried out.
In practice, early adopters often become the first to encounter these issues (This is not specific to IPFire).
It is therefore understandable that many users prefer to wait a little before installing a newly released update.
But that doesn’t explain CU183 : 14.84% how many users does that represent who haven’t upgraded their system since 2024 ?
My opinion is based on the question I raised and on a few circumstances that, in my view, should be taken into account.
That 15% is certainly an interesting figure, but it would be even more valuable to understand how it is made up: how many machines are still actively sending the configuration file, how many have stopped sending it, and, most importantly, for how long.
As I mentioned before, I believe this figure may be influenced by a period when many people installed the system simply to try it out or evaluate it. Some may have decided it was not the right solution for their needs, while others may have moved on to different alternatives. However, I think the most likely explanation is that many users migrated from a test machine to a production machine, possibly while also performing a system upgrade.
To give a practical example, whenever I need to test a new release or create a specific configuration, I set up a dedicated virtual machine for testing. On some occasions, I have enabled the configuration file upload as well. Once my testing is complete, however, I simply delete the virtual machine. Scenarios like this could account for at least part of that 15%, without necessarily indicating that users have actually abandoned the system.
If it were not as hypothesized, it would not be possible to explain the 0.01% of the IPFire 2.11 version - Core Update 57 just to give an example
I can see where many at IPFire 2.27 - Core Update 182 would have spun up test beds for running IPFire 2.29 - Core Update 183 and then opted to stay at 182. However, all those non-operational CU183 test beds would need to be powered-up and forgotten in a closet or in virtual machine and still sending info to FireInfo … unless something in the FireInfo counting is not working as stated in comments above.
By clicking Random profile several times, you can see that some systems haven’t updated for several years.
That may support your assumptions, but we won’t find the real answer based on assumptions alone.
By clicking Random Profile I can see
- system updated information last time long before → the statistic involves the whole history
- systems with CU 183, 196, … with FireInfo updated in the last days → there are enough, each single system is enough, with dangerous ‘Never touch a running system’ philosophy.
Some users have left a very long time between updates. There have been users on this forum that have raised questions about updates over large numbers of Core Updates.
One that was going from CU159 (Aug 2021) to CU175 (June 2023)
One that was going from CU159 (Aug 2021) to CU180 (Oct 2023)
One that was going from CU168 (June 2022) to CU191 (Jan 2025)
So these are ones that came and asked questions about updating.
I, unfortunately, would not be surprised that there are ones that have installed IPFire and never looked at it again.
I have seen reports about live issues being tracked on three year old CVE’s and checks by tracking organisations that found 1000’s of involved units still connected on the internet, with the involved package still not updated even though the fix had been available for 3 years.
In terms of the web infrastructure of fireinfo directly, I can’t comment specifically on that as I am not involved in that activity so have no direct knowledge on it.
The Last update on Fireinfo Profile is the last time that the node reported – not the time the system was upgraded.
Hi! I don’t want to start a discussion that won’t lead anywhere.
My point was simply that if an installation hasn’t updated its profile for several years, it might make sense to consider it no longer active and remove it from the system.
I can also understand the reasons for choosing not to do this kind of cleanup. However, I believe it’s more useful and transparent to present statistics that are as close to reality as possible.