marauding_gibberish142

What freedom in the sense of writing code does the GPL inhibit? GPL simply says that changes to the source must be published. MIT is just a scapegoat for companies to get stuff for free without helping the developer that's giving their time and soul for it

Not using GPL or derivatives doesn't force companies to publish changes (which are usually improvements) which harms the community

Do you feel that way about all MAC or just SELinux? AppArmour is similarly arcane when you're in the zone configuring your application. TBH RedHat has troubleshooting instructions in their docs, I just Copts paste and edit as necessary and it doesn't take that long. I guess I just spent more time at it

To be honest I had the exact same situation with AppArmor, and since then I have grown to like MAC. I know they're doing it to keep me safe so I don't complain. Honestly if people find MAC to be a hassle they should also in theory find file permissions and ACLs a hassle

SELinux is installed by default on RHEL derivatives like AppArmour is on Debian derivatives. Sure maybe it's annoying to see a package you didn't download explicitly but I still don't see why it's a big deal. I guess having to delve into SELinux in the middle of configuring another app will cause some pain

I think this is where the confusion happens.

I use SELinux at my job. I admit that I'm not a Linux expert, neither am I an SELinux guru. The only interaction I have with SELinux is:

• Oh, my app keeps dying even after I chown the relevant directories.
• Looks at SELinux AVCs
• Creates new policy and puts in the home directory for the application - example: I just did it for HAProxy this week.
• If I fucked something up and I know the other apps have their policy modules in their place, I just do a restorecon and spend 5 minutes going through the policies whilst reprimanding myself for my stupidity.

I'm being honest that is literally what's it's been like to use SELinux. For context, AppArmour is exactly the same situation but now I need to edit a file (I can be lazy and keep appending rules to it but that will bite me later). If we're going down the path of SELinux being complex for daily usage, then all MAC has the same problem.

I admit that I would find it daunting to do this for a desktop environment. It's there that I want a pre-configured SELinux policy OOTB. On servers though? It's not a big deal for me.

Or maybe I missed something.

Altruism towards shareholders, not the open-source community

The only problem is companies will always try to use MIT and using it for small projects will set a precedent. And we don't have a governing body strong enough to enforce the GPL (nobody listens to the FSF)

UFW syntax is easier. And it wraps nftables now which means I don't have to bother learning even more arcane syntax.

I hope I'll still be using the terminal when I'm 70 or something.

Not a jab at you OP, great work on your part. I'm just making a general comment towards my own predicted cognitive functioning

I prefer some of my applications to be on VMs. For example, my observability stack (ELK + Grafana) which I like to keep separate from other environments. I suppose the argument could be made that I should spin up a separate k8s cluster if I want to do that but it's faster to deploy directly on VMs, and there's also less moving parts (I run two 50 node K8S clusters so I'm not averse to containers, just saying). Easier and relatively secure tool for the right job. Sure, I could mess with cgroups and play with kernel parameters and all of that jazz to secure k8s more but why bother when I can make my life easier by trusting Red Hat? Also I'm not yet running a k8s version that supports SELinux and I tend to keep it enabled.

Sometimes, VMs are simply the better solution.

I run a semi-production DB cluster at work. We have 17 VMs running and it's resilient (a different team handles VMWare and hardware)