centos-stream VS Avalonia

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 ?

You might also want to look at AvaloniaUI[0] for a cross platform .NET GUI library. It is similar to WPF but much nicer to work with.

[0] https://github.com/AvaloniaUI/Avalonia

Production user here. There's no money gotchas. They're above reproach. In fact, I've received considerable free support from their devs on GitHub Issues [1].

The Avalonia business model is based on selling XPF, which runs WPF (Windows-only) apps on other platforms. That's very interesting to big corps with existing codebases.

See my comment [2]

[1] https://github.com/AvaloniaUI/Avalonia/issues

[2] https://news.ycombinator.com/item?id=39246988#39249128

Yes, but the portable GUI frameworks by Microsoft themselves are generally not very good, and they tend to be abandoned after a couple of years.

Avalonia is developed outside of the Microsoft corporate madness and seems to be slowly becoming the defacto cross-platform framework because it is expected to last a bit longer than a manager's attention span: https://avaloniaui.net/

Not my comment, but relevant here "The problem with compiling Skia to WASM is you'll lose any benefits of hardware graphics acceleration on the device."

(From https://github.com/AvaloniaUI/Avalonia/discussions/6831#disc... )

It's a bit of a hit and miss as of today. CLI, back-end and natively compiled libraries (think dll/so/dylib or even .lib/.a - you can statically link NAOT binaries into other "unmanaged" code) work best, GUI - requires more work.

Avalonia[0] and MAUI[1] have known working templates with it, but YMMV.

[0] https://github.com/lixinyang123/AvaloniaAOT / https://github.com/AvaloniaUI/Avalonia/ / honorable mention https://github.com/VincentH-Net/CSharpForMarkup

[1] https://github.com/dotnet/maui (try out with just true in csproj - it is known to work e.g. on iOS)

For desktop, Avalonia, hands down.

https://avaloniaui.net/

Open source, powered by Skia, backed by JetBrains, and quite battle-tested at this point for small to medium-sized apps. In theory perfectly capable for enterprise as well, since it's basically a spiritual successor to WPF, which has been an industry standard for about 15 years.

They're diving into mobile and WASM well, but that's more of a recent effort and I haven't tested that yet.