Companies can change terms of employment at any time, as can employees. Ever been presented with new paperwork - things to agree to, partway through a job? Big policy changes? I have.

Are you really telling someone it's unethical to haggle over some of the terms of their employment arrangements? You have strange ethics.

Unless otherwise arranged. Your post is not insightful - people can make other arrangements. He's asking questions about that.

"Accept this kernel patch because some web browser unwisely introduced a dependency on a kernel feature two years before it would be sane to do so"

"That's crazy, hell no"

I think you've misidentified the side that's in the wrong here. Software developers, when they see a new feature in some library they use or in a kernel or whatever, should be thinking "That'll be nice to use someday, I'll start playing with it in a bit, make it an option in a year if that's workable, and maybe make it a dependency in two years". Deciding "OMG yes NOW NOW NOW" is moronic.

Your browser, right or wrong. Doesn't matter that the Chrome people are being ridiculously brain-damaged here, you've decided that the OS people are always wrong in any conflict.

Are you really going to be confused by the words that have been borrowed from other activities for lack of more appropriate terms? Look at the structure of how science happens - the interplay between research departments and funding sources, the role of reputation and qualification, the peer review system, the metrics of empiricism, testability, reproducibility, and follow-up studies, and reinterpretations of conclusions. It's a complicated, powerful, and beautiful process but it has no resemblance to debate.

Nonsense. Science is not a debate club, and it doesn't have opponents. Consensus plays a role, and there is a (complicated) role of qualification that fits into peer review.

The technical skill of programming, while potentially deep and subtle, doesn't imply scientific literacy or even necessarily any broad intellectual merit.

It'd be more interesting to ask how this passed code review. Expecting code to remain static out of a fear of touching it is unreasonable. Expecting a solid code review process, by contrast, is very reasonable.

See "Tortious interference".

It doesn't seem prudent to be figuring out ways to violate another country's airspace unless wants to actually be at war with them. I wouldn't want to comment on the merits of war with North Korea per se, but at least from the perspective of maintaining peace and a normal international order, nations generally expect to have their borders respected, and they take responsibility to control their citizens enough to make sure they don't violate the borders of their neighbours.

Not everyone configures this stuff the same way, and new versions of software would mean you'd need to change this tuning all the time. Plus, you'd likely need to know all the tuning anyhow in case you need to debug or adjust it. Your best solution probably is not going to hope for a distro so much as baking yourself an image (or install script, or chef/puppet/ansible recipeset, or similar) and using it to build these systems for you. A custom distro wouldn't make sense.

The process of getting rejected from a journal may lead to improvements in a paper, or lead the paper to be submitted to a journal that's more tier-appropriate than one's first choice. Both can be very healthy.

In open-source, forking is as healthy as democracy, perhaps moreso.

That's not what TRIM is for.