3 ms·
> One common strategy, used by Linux itself, is to maintain a high level of internal API churn coupled with genuinely good improvements in that churn Interesti
by frutiger 6y ago
> One common strategy, used by Linux itself, is to maintain a high level of internal API churn coupled with genuinely good improvements in that churn
Interesting angle that I had never thought of as deliberate. As someone who works on a (bespoke) integration/embedding of Chromium, I could say exactly the same thing about it too.
- cutemonster 6y agoMeaning, internal things in chromium change so fast, so you'd slightly wish you could have your custom changes merged into upstream? (I.e into chromium) So that the ppl at Google would keep your code working? And you didn't need to spend time resolving git merge conflicts, and compilation errors? But you cannot, because some of those bespoke changes are "secret" and what you make money from? (And maybe some changes are off topic to Google) I wonder how much time does it take to merge a new chromium version into your repo? Like, hours? Days? Weeks
- rfoo 6y agoYes. Also, the fact that Chromium is a high profile security critical software with occasional emergency security updates for bugs exploited in the wild, doesn't help at all when you want to maintain your own fork.
- afiori 6y agoPersonally I see this as a good counterargument for "just fork it." Imagine if chrome decided to crank up churn with the intention to exhaust forks. Maybe all forks would join together to fight google or more likely they would just fall behind.
- gsnedders 6y agoThis has practically already happened; there are very few Chrome-based applications that actually stay up-to-date, and Electron isn't much better.
- jabl 6y agoIt's not churn for churn's sake. But having a policy of having drivers in-tree and explicitly not caring about out-of-tree stuff allows them a relatively free hand to improve the internals. Which is then seen as churn by out-of-tree code.