Hi, I've launched a full FreeBSD mirror located in Belgium. It is accessible over HTTPS and RSYNC protocol. Can it be added to the Mirrors page? All details about the mirror: https://freebsd.teambelgium.net/
The mirror site has changed to: https://mirror-services.net/ And the mirror URL is: https://freebsd.mirror-services.net/
No one around to add my mirror? :( https://freebsd.mirror-services.net/pub/
In case you missed it: https://docs.freebsd.org/en/articles/hubs/ We are not accepting new community mirrors at this time.
(In reply to Muhammad Moinur Rahman from comment #3) Alright. Care to mention why? Most other distros can't have enough. FreeBSD has too many or...?
(In reply to Grozdan from comment #4) There are couple of reasons: 1. Bandwidth from our central servers. Increasing number of community mirrors require more bandwidth in case everyone starts pulling altogether like just after a new quarterly branch 2. While many sites are excited to create mirrors as they think they have real bandwidth in reality they lose their moral bandwidth in couple of days and our mirrors are no longer in sync. We are often communicated regarding the problems of other community mirrors. We already operate in a tight schedule and often overseeing other mirrors is just another nail in the wall. We still accept mirrors but on a different way. If people can sponsor bare metal we would be happy to deploy a new mirror. However our mirror requirements are pretty high. You can have a look at the following to understand our requirements: 1. https://wiki.freebsd.org/Teams/clusteradm/generic-mirror-layout 2. https://wiki.freebsd.org/Teams/clusteradm/tiny-mirror
(In reply to Muhammad Moinur Rahman from comment #5) I believe that “not accepting community mirrors” and “rejecting mirrors” are two entirely different things. Ubuntu has a large number of community mirrors, and very few of them are officially endorsed. This is simply the user’s freedom of choice. Users can choose a seemingly safer official mirror, or they can sacrifice some security and privacy in exchange for speed. We have no right to make this choice on behalf of users. For someone who is dying of thirst, the question is not whether they drink Coca-Cola or dirty water. By shutting down rsync and providing no alternative synchronization channels—when most open-source mirrors rely on rsync—they have in fact hindered the development of the FreeBSD project itself. The project says its bandwidth is insufficient, but I doubt OpenBSD or NetBSD have significantly more bandwidth. Yet they empower users by giving them open and free choices. It’s just like what happened today: I criticized a speed-test tool that is supposed to test and switch between different FreeBSD package mirrors, yet installing it requires 45 additional dependencies. This feels like imagining what clothes the emperor should wear and what kind of golden hoe he should use for farming — or like inventing a light bulb that only turns on during the daytime. I am not criticizing any individual; what I am questioning is whether the system and the design itself make sense.
(In reply to Muhammad Moinur Rahman from comment #5) FreeBSD may have switched to Git on a technical level, but its mindset still feels stuck in the Subversion era. The modern internet values decentralization and sharing. What you said is true and reflects reality: some community mirrors might sync for a few days and then abandon the effort. But the key issue is that the freedom to choose should belong to the users, not the project itself. To me, this reflects a kind of paternalistic attitude.
Having this discussion in Bugzilla doesn't help anyone.
My mirror is a community mirror, a personal project, I provide to the Linux/UNIX-like community. I do not ask anything in exchange except for it to be included to the distro's mirror list. I pay all expenses myself so it's free to use from the POV of the distro/users. FreeBSD is the ONLY distro that has rejected my mirror. The other 17 mirrors I provide are all too happy to be added, though some are still pending. FreeBSD is shooting itself in the foot on this one... I'll still provide the mirror on my page even though it won't be added to FreeBSD's list. Maybe someone comes by and downloads an ISO or so, who knows?... :)
In truth, it doesn’t matter where this is discussed, because the discussion itself has been shut down — what we’re seeing now is simply an evasion of the issue. The project will never address its harsh requirements in certain regions, nor the regulatory constraints it cannot change. This problem has remained the same since I first encountered FreeBSD in 2018. Or rather, ever since FreeBSD moved to pkgng, it has refused rsync. I still maintain that FreeBSD only switched to Git on a technical level, while its mindset is still stuck in the SVN era. SVN is centralized, unified, and tightly permission-controlled; Git is distributed, de-permissioned, and allows free branching. The modern internet values decentralization and sharing. There’s no deeper reason — just as both urbanization and de-urbanization can be reasonable and unreasonable — it’s simply a trend that forces us to behave in certain ways, or else we lose our own legitimacy. You’re right, and it is realistic: they might sync for a few days and then just walk away. But the core issue is that the choice should rest with the users, not the project. I agree that volunteer work doesn’t mean being unprofessional — in fact, it demands even more professionalism. But one cannot impose their own standards on others and restrict them accordingly. Almost all university and institutional open-source mirrors run purely out of goodwill and are completely unpaid. To me, this reflects a paternalistic attitude. It also shows that the biggest challenge for old projects during transitions is not technology but mindset. You can ignore this with formal language and rigid rules, but doing so also restricts a form of freedom. Whether users choose a mirror site or run rm -rf /, it’s their freedom. I understand that we can issue warnings, but we shouldn’t deny them the choice — Windows, after all, does not let you format the C drive. The FreeBSD cluster was attacked in 2012, so the project dramatically raised its security priorities and naturally adopted a default distrust of external contributors. This is also visible in the src management team. But ultimately, the choice should be left to the users. The current state of the internet is complicated, but that is not a reason to reject openness, because openness is an irreversible trend. It is entirely possible to address the issue through technical means — signatures, checksums, and the approaches used by other operating systems and distributions. At the moment, the FreeBSD project offers only positive liberty, without acknowledging that negative liberty is the baseline of freedom. The internet is inherently unsafe; there is nothing wrong with trying to find something stable in an unstable world — the ancient Greeks did exactly that — but the reality is that we live in turbulent conditions. Many countries and regions cannot even guarantee 24-hour electricity, let alone reliable network access. It is unrealistic to expect them to strictly follow every rule. FreeBSD mirrors today are located at backbone network nodes and even national-level data centers, yet sadly this brings no speed improvement for us. The funding and connections available to open-source communities are limited, but openness itself is not difficult. I understand this is not a wishing well: I know a university that is very willing to host a mirror, but tensions exist between regulatory policies and those of the FreeBSD project. In different countries, the price gap between commercial and residential broadband can be enormous — up to a hundredfold where I live. And if international bandwidth is required, the gap can reach a thousandfold. If the project ultimately decides not to address this matter, it may be partly because the rationale is still considered insufficient, and partly because the FreeBSD project is still in the middle of its transition. I may also choose not to raise or complain about these issues again, so as not to trouble you. The FreeBSD project adopted its CoC rather late, and its transition to Git was not early either. Most contributors have decades of experience, and I have no standing to demand anything from them; this is a request, not a command. According to surveys conducted by the Foundation, combined with my own experience, people under 25 have almost never heard of FreeBSD. The main obstacles that used to prevent them from using FreeBSD were drivers, virtualization, Docker, mirror sites, and the lack of a default graphical installation environment. I’m sorry—I’m not very good at communicating with people. I almost exclusively interact with a very small number of people closest to me. Please forgive me if anything I say makes you uncomfortable. English is not my native language, and different languages carry different worldviews; I have no intention of causing offense. However, our community has consistently had no one willing to respond directly or provide feedback on these issues. I understand that you may have been somewhat disturbed by this, but that was not at my instruction, and I apologize on their behalf. I have already explained to them that the project currently mainly operates on bare-metal servers rather than ordinary virtual machines or KVM, etc. I am unwilling to step forward to do anything, and in fact, I am unable to do so—but they are always reluctant to state the issues directly, attempting instead to bypass or cancel the problem. I believe this does not constitute a clear expression of opinion or stance. If the project still has concerns, it could consider providing only password-protected rsync, requiring verification of the legitimacy of institutions rather than individuals. I recognize that achieving a balance between security and convenience is difficult, but sacrificing either is undesirable. In fact, I’m very afraid of anyone replying to me—not because I would be disappointed, since I never hold any expectations about anything—but because I always imagine the worst possible scenarios and how to deal with them. If there is anything wrong in the way I express myself, it is not my intention. The project may prefer using zfs send and zfs receive to transfer files, but for most mirror sites and open-source distributions, rsync remains the classic choice. Making it available would represent another form of “Works As Intended.”If the project is willing, they can contact the representative of the university mirror I mentioned earlier at yaoge yaoge@nju.edu.cn. Thanks.