5 ms·

Why can’t forks just maintain an independent implementation afterwards?

• ffsm8 2y ago
  They could, theoretically. But just imagine what that actually means. Unless you cease merging upstream/the project you've forked, you'll have to resolve all conflicts caused by this divergence. And that's a lot of work for a multi million LOC project, unless the architecture is specifically made to support such extensions... which isn't the case here. And freezing your merges indefinitely isn't really viable either for a browser
  • Zak 2y ago
    A quick look at the code gives me the impression that webRequestBlocking is a fairly trivial modification to webRequest, and they seem to be keeping the latter. This leads me to two conclusions: it wouldn't be terribly hard for a fork maintainer to keep webRequestBlocking, and Google's technical excuses for removing it are disingenuous.
    • justinclift 2y ago
      > ... and Google's technical excuses for removing it are disingenuous. That's been the default assumption of pretty much everyone anyway.
    • account42 2y ago
      That may be true now but will it still be true when Google next refactors their request code under the assumption that no requirements for a webRequestBlocking API exist.
  • SirMaster 2y ago
    So go make an LLM manage the fork or something. Everyone keeps telling me they are amazing at code these days. Surely it can do a task like that if that's all it's doing all day. If not today maybe soon...
• bawolff 2y ago
  Because these aren't really independent browsers but reskins. Being independent of google requires actually doing the work and not just copying google.
  • notpushkin 2y ago
    The codebase is huge, sure, but the particular feature is relatively small and (as I assume and as verified by another poster) quite easy to implement: https://news.ycombinator.com/item?id=43204603 https://news.ycombinator.com/item?id=43204603