centos-stream VS bflat

In an unexpected and surprising move, contrary to what Red Hat has been saying lately to the community about CentOS Stream collaboration and rebuilders, Red Hat will refuse patches to CVE issues, developed by downstream contributors, in CentOS Stream citing "no customer demand".

Link to CentOS Stream Gitlab of the AlmaLinux CVE patch commit: https://gitlab.com/redhat/centos-stream/rpms/iperf3/-/merge_requests/5

Discussion going on Reddit: https://www.reddit.com/r/AlmaLinux/comments/1544w8b/red_hat_refuses_almas_cve_patches_to_centos/

The source RHEL is built from can be found here with absolutely no restrictions: https://gitlab.com/redhat/centos-stream

https://gitlab.com/redhat/centos-stream/src/kernel/centos-st...

Fedora and many other distros do a lot of valued work, too.

FWICS there are FIPS kernel variants for Ubuntu <= 20.04 LTS (2020) but not 22.04 LTS (2022), and Debian and Ubuntu don't have the selinux policy set that Fedora and RHEL+EPEL have. https://ubuntu.com/kernel

From https://news.ycombinator.com/item?id=36480033 :

> Would it be feasible to sed-replace the RHEL and/or Fedora selinux and container-selinux rulesets for use with other Linux distros?

> "AFAIU only SUSE can run both AppArmor and SELinux?*

> And browsers are running as unconfined in selinux with like all major distros; even on ChromiumOS

Act like you added `systemd-nspawn respawn` to every SysV-init script and correctly formatted the epoch time in the correct column of each of the log files to merge and then logship again.

There is nothing stopping any of the rebuilders from using gitlab.com/redhat/centos-stream to continue rebuilding.

Is "284.18 1" the commit that gets you the kernel version 5.14.0-284.18.1 ?

The sibling pretty much sums it up. But if you want more detail, read on:

Generally, there are three publishing options that each make sense depending on scenario:

JIT + host runtime: by definition portable, includes slim launcher executable for convenience, the platform for which can be specified with e.g. -r osx-arm64[0].

JIT + self-contained runtime: this includes IL assemblies and runtime together, either within a single file or otherwise (so it looks like AOT, just one bin/exe). These requires specifying RID, like in the previous option.

AOT: statically linked native binary, cross-OS compilation is not supported officially[1] because macOS is painful in general, and Windows<->Linux/FreeBSD is a configuration nightmare - IL AOT Compiler depends on Clang or MSVC and a native linker so it is subject to restrictions of those as a start. But it can be done and there are alternate, more focused toolchains, that offer it, like Bflat[1].

If you just want a hello world AOT application, then the shortest path to that is `dotnet new console --aot && dotnet publish -o {folder}`.

[0] https://learn.microsoft.com/en-us/dotnet/core/rid-catalog

[1] https://github.com/bflattened/bflat (can also build UEFI binaries, lol)

See here

See B flat

I've been wondering how to integrate modern .NET Core into a custom build system (buck2) and was wondering similar things. There's this project I think is cool called bflat[1] that basically makes the C# compiler more like the Go compiler in the sense it's a one-shot single-use tool that can cross compile binaries natively. It's done by one of the people on the .NET Runtime team as a side project, but quite neat.

I think in practice you're supposed to compile whole .dll's or assemblies all at once, which acts as the unit of compilation; I don't think the csharp compiler generates native object-files-for-every-.cs, the kind of approach you'd expect from javac or g++. Someone please correct me if I'm wrong though! I'd like to learn more about this.

[1] https://github.com/bflattened/bflat

You can compile without a GC using https://github.com/bflattened/bflat

nice. have you tried compile it using https://github.com/bflattened/bflat to have native executable? as long as you don't have PackgeReference it can be compiled using bflat instead of full dotnet

The creator actually addresses this issue: