You can profit from GPL software. The only restriction is if you distribute it you also need to distribute modifications under the GPL.
GPL also does nothing for software as a service since it is never distributed.
GPL even explicitly allows selling GPL software. This is effectively what redhat do. They just need to distribute the source to those that they sell it to.
Not anymore because all the reason I mentioned. Has the experience change in recent years? Not likely. It is the same software as in other distros - just years out of date. That has not changed as the goals of these projects have not changed. They might be on newer versions then 10 years ago but they are still way behind more frequently updated distros - or at least will be very shortly. That is fundamentally how these enterprise distros work. Their target audience is businesses needing support, not lots of end users.
The big attraction towards these distros are the support that enterprise people will pay for - which you do not get with the free version. If you don't mind older versions of things then it might be nice for you. If not then I would stay clear of them.
So someone that is not involved in rust at all and does not seem to like the language thinks it will get a GC at some point? That is not a very credible source for such a statement. Rust is very unlikely to see an official GC anytime soon if ever. There are zero signs it will ever get one. There was a lot of serious talk about it before 1.0 days - but never made it into the language. Similar to green threads which was a feature of the language pre 1.0 days but dropped before the 1.0 release. Rust really wants to have a no required runtime and leans heavy on the zero-cost abstractions for things. Which a GC would impose on the language.
Systemd does a lot of things that could probably be separate projects,
I dont get the hate for this - Linux is full of projects that do the same thing: coreutils, busybox, kde, gnome, different office suites, even the kernel itself. It is very common for different related projects to be maintained together under the same project/branding with various different levels of integration between them. But people really seem to only hate on systemd for this...
Except the AUR does not normally count as redistribution. It distributes package automation scripts and patches. The source/binary is typically download by the user from the official distributor when they build the package. Some packages do include source/the binary, but most do not.
Distributing the built package might cause issues for some licenses though (not the GPL though).
Long enough to learn and switch to a new engine, possibly on your next game.
Push notifications are even worst that TOTP codes. Users can just hit accept without thinking, especially if they have gotten used to lots of things asking for it. An attacker can just keep sending requests hoping someone clicks on one of them and then they are in. At least with a code you need to get something from the users first. Hardware tokens with USB-c or NFC like the yubikey can be used on mobiles as well.
The killer feature is getting applications from a central repo, not so much that there was only one repo. Unlike windows where you have each application self updating or not updating at all and forcing you to have to go to several webpages to update things. Having to update two different repos IMO is not a huge problem, you just need to be aware of it and there are frontends to these systems that can update both at once. The only exception to that I think are AppImages - but those you don't really need to use on most distros.
Staying on unity might also be very expensive depending on how all this resolves. Switching might be a cheaper option and worth at least looking at.
I wonder could you interpret this as AI created movie script isn’t copyrightable
This first but I don't think that is how it can be interpreted like that. Looks like it comes down to how much human input was used to guide the AI in the works. The more the human guided the AI the more they have a claim to the copyright is how I read that. Not just all AI content cannot be copyrighted. Which IMO seems like a fair way to apply copyright to AI generated content.
The latter part is basically already handled - look at any film created from a public domain works, Shakespeare plays being a big example here. I would expect non-collectable AI works adapted to film to to be handled the same way. Though I suspect that to create any good movie script with AI you would need significant human input which could lean towards to script having a stronger copyright claim by those that guided the AI.
That is because GPL libraries are a pain for corporations. And popular languages like rust are built by corporations and a lot of the libraries for them are built by corporations. Rust would not be the same language as it is today without their contributions. If it were all GPL far few companies would want to use it so far fewer developers would be able to use it which would stunt its popularity. This is also true of python libraries and npm libraries which are mostly under permissive licences.
Looks like there is going to be a shift to using nftables in arch. The iptables package in core is currently for the legacy interface with an iptables-nft package for the new interface, but the core-testing iptables package is for nft interface and there is now a iptables-legacy package in core-testing.
My guess is they are moving packages that can work with nftables to depend on that instead of iptables which looks like it is shortly going to be using the new nftables interface anyway. Probably as part of migrating to nftables by default. Looks like docker does have experimental support for nftables in version 1.29 and that is when the dependency was added to the PKGBUILD script.
It does not look like nftables or iptables conflict with each other at a package level. And nftables can work with iptables rules.
It is probably worth just migrating to nftables now if you rely on managing iptables yourself.