3 ms·

From your post > you will (...) want to change the name of your browser [to] "Browser of Bliss" instead of as "Chromium". You will find that this is already h

From your post > you will (...) want to change the name of your browser [to] "Browser of Bliss" instead of as "Chromium". You will find that this is already hard to do. The browser name is hard-coded in many places in the millions of lines of Chromium source code. (...) Viasat are offering a (...) fork called Rebel that makes this easier I am surprised that kind of change has not been upstreamed, or is Google actively working against forks?

Vinnl 2y ago
I'd also be surprised if that browser name is "Chromium", given that Google Chrome doesn't brand itself as such. (And vice versa.)
mherrmann 2y ago
It depends on the individual part of Chromium. Some teams seem to be much more open to contributions than others. (I believe to recall that this is also what someone at Viasat told me at some point, but I'm not sure). Also, for example the browser name appears in a lot of places. It is very hard to fully extract it into a single configurable option.
benreesman 2y ago
It’s just the kind of thing that happens in a huge, production codebase. There are plenty of reasons to be skeptical of Google, but some strings in multiple places isn’t a good reason to be skeptical of the Chromium maintainers.
- KolmogorovComp 2y ago
  I know it's naturally happening in a large codebase, I'm asking why they specifically maintain a fork just for that instead of trying to push what are probably easy (but tedious) upstream fixes.
  - poincaredisk 2y ago
    Purely guessing: abstracting a browser name is yet another abstraction layer. A later that is not needed by chromium. Maintainers of chromium primarily care about maintainability of chromium, not other forks.
    - throwaway35023 2y ago
      If the browser name is referenced in multiple places, it seems to me that by defining it in one place actually increases the maintainability.
      - filcuk 2y ago
        I think what they're saying is that Chromium will remain Chromium, so maintainers have little incentive to worry about this
- deleted 2y ago
  [deleted]
IshKebab 2y ago
> is Google actively working against forks They could not accept those changes without being actively against forks. It would just mean they aren't actively supporting forks, which is a different thing.

Vinnl 2y ago

I'd also be surprised if that browser name is "Chromium", given that Google Chrome doesn't brand itself as such. (And vice versa.)

mherrmann 2y ago

It depends on the individual part of Chromium. Some teams seem to be much more open to contributions than others. (I believe to recall that this is also what someone at Viasat told me at some point, but I'm not sure). Also, for example the browser name appears in a lot of places. It is very hard to fully extract it into a single configurable option.

benreesman 2y ago

It’s just the kind of thing that happens in a huge, production codebase. There are plenty of reasons to be skeptical of Google, but some strings in multiple places isn’t a good reason to be skeptical of the Chromium maintainers.

KolmogorovComp 2y ago
I know it's naturally happening in a large codebase, I'm asking why they specifically maintain a fork just for that instead of trying to push what are probably easy (but tedious) upstream fixes.
- poincaredisk 2y ago
  Purely guessing: abstracting a browser name is yet another abstraction layer. A later that is not needed by chromium. Maintainers of chromium primarily care about maintainability of chromium, not other forks.
  - throwaway35023 2y ago
    If the browser name is referenced in multiple places, it seems to me that by defining it in one place actually increases the maintainability.
    - filcuk 2y ago
      I think what they're saying is that Chromium will remain Chromium, so maintainers have little incentive to worry about this
deleted 2y ago
[deleted]

IshKebab 2y ago

> is Google actively working against forks They could not accept those changes without being actively against forks. It would just mean they aren't actively supporting forks, which is a different thing.