Assuming the creators go into these deals eyes open I can see the appeal of making an exit from the grind. It's hard to spin up a business outside of the platforms without access to resources or other income. One person bands will burn out trying to manage merch, algorithm optimisation and content generation at the same time.
I can think of a few channels that have gone interdependent but I'm sure they get income from other places as well.
It takes a bit of a mental shift but in our case range is only ever an issue when visiting people elsewhere in the country. In those cases you are almost certainly using the motorway network and services have been rapidly upgrading with fast chargers that will get you to 80% in the time it takes to go to the loo and grab a coffee.
Edit to add book max range on my MG5 is ~220 miles but in practice we keep it at 80% charged so 160-180 miles which is enough to get to the local city and back in winter without even worrying about it.
You must make the source available to anyone you distributed the binaries to. Where in Red Hats TOS does it say they will sue you? As far as I understand it the reserve the right to terminate the service you are paying for. But your rights to source for the binaries provided are not affected.
I daily drive Debian and I switched to Trixie once the tooling freeze kicked in. Now the release is stable I'll be able to enable backports for the few bits and pieces I like to have the latest packages for. Generally I want a rock solid base and I can always use flatpak/snap for more recent apps.
Putting the AI specific stuff to the side for now I don't think it's unreasonable. Arm in the cloud has gone from an experiment to mainstream with all the major workloads running well on it. Now the hyperscalers can choose between multiple implementations including their own silicon cost is going to be a big driver going forward. No wonder Intel are having a crisis right now and RiscV is hanging around the corner wondering what it needs to do to break into the space.
There is a difference between reviewing code and the feedback when you have the job and during an interview when trying to get a job. I'm not saying you should never expect to be pulled up on mistakes just that an interview experience is very different to the work experience.
Maybe there are ways to ameliorate the stress during the interview to get a better view of how a candidate will perform once hired but I think it's a tricky balance to strike.
I think there is a difference in setting. Pair coding is a useful exercise but demands a degree of trust that the two of you are working together on a solution rather than one of the pair judging the other.
If you're expecting to be stressed all the time at work then that is a red flag. Some professions may involve a degree of stress, which should be mitigated, from time to time but software engineering shouldn't.
In my first interview they put me in a room with a PC with Borland C and a copy of K&R and a sheet with a simple problem to solve and some extra enhancements if I had time. They said they would be back in half an hour and left me to it. That I passed fine.
Some twenty-ish years later I was asked to write a C function to reverse a string on a white board and I failed because I'd misformatted the for loop. I don't think it was because I've become a worse C coder in the intervening years.
When I'm actually coding I'm sat with my editor configured Just So with completion, compilation and unit tests at my finger tips. My favourite coding music blasting my speakers and a handy browser window for looking up anything in unsure of. This is my most productive setting and expecting the same performance in a stressful interview setting is foolish in my opinion.
Working through problems on a white board can work well but you are looking for the problem solving approach, not an encyclopedic knowledge of regex syntax. Those same problems get immeasurably harder when explained over a phone call.
My personal preference when evaluating candidates ability to code is reading their actual production code, the break down of commits, the commit messages and the sort of unit tests they add with a feature. The interview is more focused on their soft skills, what about the work excites them and what they are looking to get out of the role.
From the linked comment it sounds like there was a license change in the projects history. I'm surprised the various distro packagers didn't just collaborate on a renamed fork, unless there are more actively developed emulators still under a FLOSS licence?
Currently my kids can only watch YouTube on a shared account on the TV. They haven't been exposed to any of the gift stuff as far as I can tell but we do regularly weed the history and subscriptions to keep it vaguely on track. While each of the kids have their own favourite creators we also have found a number of educational and comedy channels we'll watch with them on the account.
The bigger challenge comes with homework as once in secondary school the teachers regularly link to YouTube videos as an intro to a particular homework topic. Although their accounts are registered as kids accounts under our indirect control I keep having to move their pc out of the restricted group on the router because for some reason Eero prevents some videos from playing which from my point of view are fine. I dread to think what parents who aren't comfortable debugging network failures do, probably drop restrictions all together in frustration.
Assuming the creators go into these deals eyes open I can see the appeal of making an exit from the grind. It's hard to spin up a business outside of the platforms without access to resources or other income. One person bands will burn out trying to manage merch, algorithm optimisation and content generation at the same time.
I can think of a few channels that have gone interdependent but I'm sure they get income from other places as well.