linuxulator-steam-utils VS source-build

GNU libc isn't a problem, or almost all programs would not work. ;) The problem can be Linux (the kernel) systems calls. For example, Steam uses some hacks (emulation of system calls) to run on FreeBSD. Here is a source code of FreeBSD package: https://github.com/shkhln/linuxulator-steam-utils

Another option is to use games/linux-steam-utils. It will install the Linux version of Steam. Not everything works, here is the compatibility list.

Here are some Linux games that work on FreeBSD: https://github.com/shkhln/linuxulator-steam-utils/wiki/Compatibility

You could (to some extent) say the same thing about FreeBSD: https://github.com/shkhln/linuxulator-steam-utils/wiki/Compa...

Please note, this is an unofficial wrapper for the Steam client and as such it is supported on a best effort basis. Limitations: - Sandbox is disabled for the web browser component. - Valve Anti-Cheat doesn't work with FreeBSD < 13. - No controller input, no streaming, no VR. - No support for Linux Proton builds. Additional dependencies: - If you use an NVIDIA card, you need to install a suitable x11/linux-nvidia-libs(-xxx) port. Steam setup: 1. Create a dedicated FreeBSD non-wheel user account for Steam. Switch to it. 2. Run `steam-install` to download the Steam bootstrap executable. 3. Run `steam` to download updates and start Steam. For the list of tested Linux games see https://github.com/shkhln/linuxulator-steam-utils/wiki/Compatibility. Native Proton setup (optional, semi-experimental): 1. Run `sudo pkg install wine-proton libc6-shim python3`. 2. Run `/usr/local/wine-proton/bin/pkg32.sh install wine-proton mesa-dri`. 3. In Steam install Proton 6.3 (appid 1580130). 4. Run `lsu-register-proton` to register emulators/wine-proton as a compatibility tool. 5. Restart Steam. To enable emulators/wine-proton right click a game title in Steam, click Properties, click Compatibility, select emulators/wine-proton.

Yea, thats what I do, and it works great. git clone https://github.com/shkhln/linuxulator-steam-utils

Looking at this and this, it looks like you can get Steam to run native GNU/Linux games on FreeBSD, but Proton is a no-go.

.NET applications are technically challenging for Linux distributions to package. https://github.com/dotnet/source-build/discussions/2960

Git Credential Manager indeed release a self-contained binary for Linux x86_64 (no arm64 yet), though the installation size is necessarily large (80 MB) to include the .NET runtime. git-credential-oauth Linux binaries (x86_64 and arm64) are much smaller at 5 MB. https://github.com/hickford/git-credential-oauth#comparison-...

It's recommended to build from source for Debian, at least. Here's the latest stable release of the SDK announcement: https://github.com/dotnet/source-build/discussions/3369

Unfortunately, packaging applications built on .NET is still a challenge for any OS that wants to build everything from source and doesn't allow network access. Like you say, duplicating nuget into os-app-package-manager is challenging. Even side from the duplication, we need to bootstrap the ecosystem, in particular dealing with cyclic dependencies and version explosion as a result of all the different versions of all the dependencies that an average dotnet application needs.

We are starting to work through it here: https://github.com/dotnet/source-build/discussions/2960. Any advice/tips/contributions would be welcome, I think.

If you want to build .NET Core yourself, Microsoft provides you with the steps necessary to do so here: https://github.com/dotnet/source-build

Maybe our definitions of open source are different, or maybe you're just shitting on Microsoft for your own reasons. Regardless of whatever your experiences have been with .NET in the past, they don't mirror the majority of the folks that use it everyday.

The C# compiler and parts of the supporting .NET runtime are written in C#, so yes there is a boot strapping issue. Other languages like Rust or even C compilers written in C have this problem.

For initial porting to a new system or processor architecture, the C++ part of CoreCLR (the main runtime for .NET) can be built with CMake and LLVM on the target system. The libraries can be cross-compiled on another system that already supports .NET and copied to the target system. Some Details are here:

https://github.com/dotnet/runtime/blob/main/docs/design/core...

For building from source to satisfy requirements Linux distributions, Microsoft has a system to build from source. My understanding from the last time I closely looked at it is some binary dependencies are de compiled to MSIL (the bytecode used by .NET). Since CoreCLR includes a MSIL assembler written in C++ (ilasm), it can bootstrap using these MSIL sources. But I have not looked at this project closely in a while and it evolved quite a lot while I was watching it. The system for the source build is here:

https://github.com/dotnet/source-build

Note that there's a bug with the version of dotnet from Fedora's repositories (basically any version built from source by distro maintainers) that breaks Omnisharp for a lot of projects. See https://github.com/dotnet/source-build/issues/2006

It's coming. Progress is being tracked here: https://github.com/dotnet/source-build/issues/1139