I don’t think Netflix actually cancels shows after two seasons any more often than other networks do.

Somehow people got it into their heads that Netflix is far more cancel-happy than its competitors, but if you look at the numbers, traditional TV networks have had like a 50% cancellation rate for decades.

Even TOS was cancelled after two seasons!

If Netflix is more prone to cancelling shows at all, which I’m not convinced is even true, it can’t be by an enormous margin.

I think this is a more subtle question than it appears on the surface, especially if you don’t think of it as a one-off.

Whether or not Scientology deserves to be called a “religion,” it’s a safe bet there will be new religions with varying levels of legitimacy popping up in the future. And chances are some of them will have core beliefs that are related to the technology of the day, because it would be weird if that weren’t the case. “Swords” and “plowshares” are technological artifacts, after all.

Leaving aside the specific case of Scientology, the question becomes, how do laws that apply to classes of technology interact with laws that treat religious practices as highly protected activities? We’ve seen this kind of question come up in the context of otherwise illegal drugs that are used in traditional rituals. But religious-tech questions seem like they could have a bunch of unique wrinkles.

Tunic, but that was kind of the point.

O’Reilly books were my go-to when I worked at a company that had a training budget I had to spend every year. Not hard to rack up a couple hundred dollars of book purchases.

The “developed or supplied outside the course of a commercial activity” condition is part of why people are up in arms about this. If I’m at work and I run into a bug and submit a patch, my patch was developed in the course of a commercial activity, and thus the project as a whole was partially developed in the course of a commercial activity.

How many major open-source projects have zero contributions from companies?

It also acts as a huge disincentive for companies to open their code at all. If I package up a useful library I wrote at work, and I release it, and some other person downloads it and exposes a vulnerability that is only exploitable if you use the library in a way that I wasn’t originally using it, boom, my company is penalized. My company’s lawyers would be insane to let me release any code given that risk.

Answering my own question: My systems do zero-downtime deployment. Some of my services are managed using ECS and some using custom deployment scripts.

It’s interesting that people mostly focus on the mechanics of launching the new code. To me, the interesting thing about zero-downtime deployment is what happens while the release is in progress, when there will be a mix of the old and new code versions accessing the same resources (databases, microservices, etc.) at the same time.

For example, you don’t want to just drop a previously-mandatory column from a SQL database: even if your new release no longer references the column, the new code will break if you deploy code before updating the database, and the old code will break if you update the database before deploying code. Obviously there are ways to do this kind of thing (roll out the change in small backward-compatible steps) but they’re extra work and can be easy to get wrong even if you’re using ECS to launch the code. Whereas, if you’re allowed to take downtime, you can do it all in one step without worrying about mixed-version environments.