centos-stream VS CoreWCF

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 ?

CoreWCF might be of some use.

You can open a discussion in the CoreWCF repo:

In the later versions you could avoid almost all the XML mess by configuring all of the settings in code. The experience is pretty close to gRPC imo, one plus point is you don't need to learn how to write proto classes. Though you could use protobuf-net for a similar experience. I'm kinda hopeful with CoreWCF, they aim to support more transports (including event gRPC) in the future along with queues other than MSMQ and slowly evolve from being too SOAP specific. There's a lot of potential still for WCF to be a transport agnostic framework that ecompass a lot of transports.

On our end, it's WCF for some servers that haven't been upgraded over. Though it seems we have a path forward for that now with CoreWCF that we're working towards.

There's ongoing work on adding generic queue support. The first two concrete implementations should be MSMQ and RabbitMq from what I recall, though MSMQ will be windows only. But the nice thing about the work is it also opens up other types of message queues for WCF (e.g. Azure Service Bus, RabbitMq, Amazon SQS etc...).

It's seems there's already design work started for a generic queue concept here. I'm pretty interested to see how it goes as well as that'll be a big part for CoreWcf to move forward as a viable choice for greenfield projects and not just a way to migrate existing Wcf projects to Core.

The ongoing .net core port called CoreWcf plans to realize that goal as a future feature on it's roadmap. Where there's plans on adding new transports that didn't exist on .net framework wcf like Grpc, Azure Service bus, Amazon SQS, rabbitmq etc...

If you hit any difficulties or have any problems, feel free to jump on the gitter channel. Details for that are in the repo contributing guide.