There takes place ongoing development, and RH just recently migrated it on public gitlab. So I see no reason to do this given that they were speaking about closing git.centos.org in favor of gitlab repos and that they gonna make centos development an open process.
Did it?
https://gitlab.com/redhat/cent...
Now you can even contribute to RHEL development (which was unimaginable before)
RHEL never supported in-place upgrades until EL8. So need to make clean setup from the ground up during migration to new major release wasn't something new.
There are several reasons for that:
* RH didn't support upgrades between major releases until EL8 (ergo same was for centos). So this feature is relatively new and limited.
* Binary compatibility (being ABI-compatible) with rhel is main feature for derived distros (centos, alma, rocky, oracle, amazon etc). So this is important checklist item during migration.
* Every recent centos-related publications from RH were PR disasters. Every time it looked for community like world ends tomorrow while in reality it always were organisationally significant but not so technically important changes (I'll remind that RH is now in process of making RHEL development public and open and making it downstream to CentOS, not vice versa as it was before).
As far as I understand, it doesn't decide to isolate devices on it's own. This is triggered only by enterprise administrator.
Last time I looked at mdatp on Linux it didn't use own kernel modules, only mainline Linux uapi (fanotify, audit via auditd etc). Most likely for this function it uses netfilter or ebpf.
Any circuit design must contain at least one part which is obsolete, two parts which are unobtainable, and three parts which are still under development.
