Hi,
On Tue, 2016-01-19 at 12:56 -0800, David J. Allen wrote:
While I am only a user, I am on this list so I can keep up with the progress and tone of the project. One can tell a lot about the health of the developer community involved in a project and thus the health of, and likely future of the project itself (e.g. likely to improve, getting stale, dying).
So my comments should be taken in that context: one user's perspective.
Thanks very much for commenting.
On 01/18/2016 05:16 PM, Michael Tremer wrote:
Hello,
I am actually at a point now where I think we need to talk about this. A lot.
So many people have been starting to contribute to this project - or as I sometimes see it - to parallel projects. Projects that are developed in parallel to the main distribution. Projects that have different goals or are at least from my perspective heading into a different direction.
The mail proxy/mail server/web mail project is one like these. There are also others like multiple versions of the update accelerator and some more.
I use IPfire intentionally and *only* because it is a router/firewall, and a good one. I am /not/ interested in it as an alternative Linux distribution, or as web server, development platform, DNS server, printer server, graphics workstation, or gaming zone.
Well, that is what we are actually doing in IPFire 3. It has the possibility to use external repositories better and it is more stripped down.
However, in 2016, we won't simply build a router. We will have more functionality in there that is used and needed by many people like proxies for the web, DNS, etc.
What should be part of that and what not is a completely different discussion though.
It's my router. Period. I don't need or want other non-router, non-firewall crap added to the recipe. If I wanted a Swiss Army knife distribution, there are plenty of others to look at*.
"Do one thing, and do it well".
We are not aiming to replace any major distribution here.
*I'm already not happy that IPfire has followed the herd into Systemd-land, since that path will lead (has lead) to more bugs and (hidden) security holes, as there are virtually no reliable security audits or real testing done by the ignorant "Change-for-change's-sake hipsters developing Systemd. However I can understand why you have gone that way, given that you depend on upstream code for most of your core systems, and it is now pretty much impossible to remove systemd's tendrils from even userland code ("One ring to bind them all").
We intentionally migrated to systemd. I guess we have been the second distribution to do that after Fedora. There are many good reasons to do that. To calm you all a little bit, we are using it as an init-system only and disabled all the stuff that should not belong in there for our purposes.
http://git.ipfire.org/?p=ipfire-3.x.git;a=blob;f=systemd/systemd.nm;h=3 5d2b0bef40b7234cf054489395d1d5b0a0f43e7;hb=HEAD#l60
And now that pretty much every Linux distro is defacto a Redhat/Fedora distro, you have no choice.
Yeah, but to make a quick point here: They are pretty much the biggest and only organisation that is actually funding this work. They are also the competition. So there is no way to develop an alternative as a side -project. And unfortunately there is no other source that is funding alternative free software projects. They are building a big monopoly here and I don't like this at all.
Although I would like to talk about this in length, this is not the time and place to do that. So let's leave it to that.
These changes are never submitted on here. There is not even a conversation on here about that being a goal. Despite me having multiple chats with people about how this process works and that they want to do it, soon-ish.
So here we are. Months later. With no progress at all.
So, then just ignore these "parallel" projects. They may be parallel in that they use IPfire as their code base, but they are, in my opinion, *not* Ipfire and should not claim to be.
That is one option. To me that comes with the big downside that it won't engage people to contribute to the actual IPFire project.
There can certainly be other projects that build on IPFire, but they need to be sure to contribute back to the main distribution. Without any talking this can't be working at all.
Instead I am getting requests and bug reports for that software that I am not involved with at all. People tell me that bugs are fixed there or that there are features available they want to use. They ask when this will be available in the distribution.
I don't have an answer to that. And what is even worse is that right now I am too tired to look into this.
Again. I suggest you just ignore those requests in as tactful manner as possible. Tell them to talk to the hand.
I usually do this. But that still keeps me busy at times.
Why should you be responsible for someone's fork of /your/ project? Do you feel obligated to answer questions about any other distro (and Ipfire really /is/ a Linux distribution)?
People out there don't know the difference. It is a bit like the grsecurity issue. People claim the name although there is something else inside their systems working. Brad didn't like that and took some action. I do not want to get into that situation.
So for many IPFire is one big thing and they just email me. I don't respond to most of the personal support queries any way, but that doesn't bother them.
These projects have diverted a lot in that sense that an easy merge is no longer possible. It will take a lot of work to split up the changes, test them, confirm that they work, do QA and then release them. This process itself is not foolproof and we are not getting a lot of feedback. We just get the backlash when something is not working properly. It will be very tough.
Very tough *and* very unnecessary. Don't do that work. If if diverts your attention from Ipfire-the-router, then eventually if will negatively affect the quality of your code, and robustness of Ipfire. The last thing I want to use is a poorly built router/firewall.
Working on these changes step by step would have certainly avoided getting to this state. Now we are at it. Frankly, I do not know what to do.
Such work would still have served no legitimate purpose in the context of a secure software router.
What to do? Easy. Get back to your roots or risk losing users.
I am not targeting to have as many users as we can get. That would spoil me making the right decisions. Some people want feature X. Denying that will make some people go and search for alternatives, but that is the way it is.
I have been heavily refusing to add SSL bump to the proxy that teared many people away. However this would have created many security issues that I don't want to constantly fix and that can't be fixed any way since they are in the design of the feature. A feature that makes no sense any way.
I sometimes take the non-intuitive route. If this was a commercial product I would have implemented that feature and earned the money for it.
I will certainly not sit down and take these things apart myself. I have actually not much interest in working on these things any way. Cleaning up after somebody else won't be my main job for the next few weeks. That is partly because I don't want to and partly because that won't work any way. It is not my code.
There. You've said. That's all the reason you need right there. No need to apologize or wring hands over that kind of honesty.
The other option would be just to leave these projects as they are. That may either be getting old and rot in a git tree. That may either be them becoming something else. But I do not think that any of these is the best option for the IPFire project as a whole. I am very much interested in keeping that as the main target of my work.
How about just kick non-router/firewall-related projects to the curb.
We pretty much did that in IPFire 3. That leads to that we don't get any support there from outside people.
Tell those who wish to add non-Ipfire cruft to go start their own distributions, set up their own servers, support teams, build up their own user community, and distribution, marketing, infrastructure, and all the other shit it takes, on their own dime.
And that might me or other IPFire developers to do the same work again. In this specific example update apache. From my point of view that only wasted valuable developer time. In both projects. That can't be the ideal.
So I would like to hear that from the people who are working on these parallel projects what they are intending to do and what they are expecting from me/the other developers. I honestly do not know if you think yourself that this is an issue, too. So let's have a productive discussion about that. I am expecting some answers...
Best, -Michael
You seem to have made what sounds like a disclaimer of your responsibility for what amounts to non-Ipfire (the concept) code. Why stop at halfway. Just do it:
Tell us "IpFire is a software router and firewall. That's it. It hopes to be the best in class at what it's intended to be. Nothing less. If you want something other than a world-class router and firewall, go somewhere else. If you want to help us in /our/ goal, then welcome aboard."
I can tell you that as a user, I know what *I* want from a router-firewall. I want rock solid security. I want robustness. I want a reasonably small footprint. I want the best possible performance. I want maintainability. I want it to just run and do the job it is designed to do. Nothing less, and certainly *nothing more*.
If I can't get that from IPfire, I'll go somewhere else. You have some good competition. In light of recent events in the Linux world *cough*cough*systemd* you're already at risk of losing users to similar BSD-based utilities.
And I still have an expensive, and very good appliance router -firewall sitting on the shelf which is not very happy about being replaced by IPfire. ;)
Just my opinion as a user.
Best Regards, David.
[snip]
-Michael