3 ms·

For FreeBSD support, see the following issue for the porting effort. The community has been working like hell to make it happen since 2015 and at this point we

For FreeBSD support, see the following issue for the porting effort. The community has been working like hell to make it happen since 2015 and at this point we have regular unofficial builds: https://github.com/dotnet/runtime/issues/14537 https://github.com/dotnet/runtime/issues/14537 About 2 months ago they crushed hopes that official FreeBSD support will happen anytime soon by clearly stating that at this point, updating their Quality Assurance process to support FreeBSD would not make business sense for them as they have to put together an extensive test suit and manual testing procedures for every OS. Microsoft folks remain friendly and helpful in the thread though. The FreeBSD ports system insists on requiring third party applications to be able to be built from source offline, while the .NET build process downloads packages left and right at various parts of the process. This is one of the things that complicates its inclusion in the ports tree. Building .NET for FreeBSD is close to rocket science, the community has worked to make the process way simpler. It is frustrating that the .NET team refuses to take things from there. Providing FreeBSD support is what I would expect from them to strengthen their cross-platform posture. This is the last major platform they need to support, and one being heavily used for servers.

pxc 4y ago
> The FreeBSD ports system insists on requiring third party applications to be able to be built from source offline, while the .NET build process downloads packages left and right at various parts of the process. As someone who is not a part of the FreeBSD community, I just wanted to chime in to say that the FreeBSD Ports people are absolutely correct here, and that the build time behavior you describe is Bad Behavior™ that is likely to get in the way of any distribution (Linux or FreeBSD or macOS or anything else) that follows basic best practices with respect to build sandboxing on their CI/CD systems, build clusters, etc., even if it can eventually be hacked around. Building software outside of a sandbox with restricted network access is how you get lovely exports like credential scrapers in your setup.py or your NPM install hooks, perhaps running as root. Downloading your dependencies at build time from within the build system without first emitting a manifest with hashsums of what you intend to download is a huge problem for reproducibility, too.
- GekkePrutser 4y ago
  Yeah the FreeBSD team is full of common sense, which is why I use it so much. Also much less likely to drink the corporate Kool-Aid.

pxc 4y ago

> The FreeBSD ports system insists on requiring third party applications to be able to be built from source offline, while the .NET build process downloads packages left and right at various parts of the process. As someone who is not a part of the FreeBSD community, I just wanted to chime in to say that the FreeBSD Ports people are absolutely correct here, and that the build time behavior you describe is Bad Behavior™ that is likely to get in the way of any distribution (Linux or FreeBSD or macOS or anything else) that follows basic best practices with respect to build sandboxing on their CI/CD systems, build clusters, etc., even if it can eventually be hacked around. Building software outside of a sandbox with restricted network access is how you get lovely exports like credential scrapers in your setup.py or your NPM install hooks, perhaps running as root. Downloading your dependencies at build time from within the build system without first emitting a manifest with hashsums of what you intend to download is a huge problem for reproducibility, too.

GekkePrutser 4y ago
Yeah the FreeBSD team is full of common sense, which is why I use it so much. Also much less likely to drink the corporate Kool-Aid.