8 ms·

> A corporate-led project does not have to answer to the community, and will leave whatever bugs they introduce in place for the sake of bug-compatibility with

by ajxs 7y ago

> A corporate-led project does not have to answer to the community, and will leave whatever bugs they introduce in place for the sake of bug-compatibility with their own software rather than fixing them. This speaks volumes very clearly. This highlights an immense hazard. Enterprise scale companies contributing to open-source is a fantastic thing, but enterprise scale companies thrusting their own proprietary libraries onto the open-source world is not. I'm already actively avoiding becoming beholden to Google in my work as it is already, let alone in the world where important software uses a libc written by Google. If you're not concerned by this, refer to the immense power that Google already wields over the extremely ubiquitous web-standards through the market dominance that Chrome has.

jchw 7y ago
(Disclosure, Googler here, not working on projects related to any of the things being discussed, speaking in a purely personal capacity.) I hate to disagree with Rich Felker. I think most people have a lot of respect for musl and the amount of effort it took. But, I disagree with the basic conclusions. For one thing, I don't think it's fair to compare this to Chrome, an end user product. libc is a fundamental piece of architecture, like (edit: as in, fundamental in stacks that they are used in, to clarify) protobufs, gRPC, Kubernetes, etc. I heavily sympathize with folks uneasy about the Chrome situation - like I've mentioned maybe hundreds of times now I use and recommend Firefox personally, but I feel this particular discussion will become more productive when that stops being a focal point. Their other points are not really related, but I disagree with them also. I don't think there's a good motivation to keep bugs for backwards compatibility: Google runs non-Google software, too; keeping subtle incompatibilities could be a disaster. Also, Google has a pretty good corpus of code to test their libc on, so I think they have a unique opportunity to fast-track a pretty battle-tested libc (I did not know of this project before this Hacker News post, so this is purely a hot take, but for now I stand by it.) No idea what their plan is, but open governance would probably work wonders here. After all, LLVM has plenty of corporate contributors, and it seems to do fine.
- stochastic_monk 7y ago
  I think trying to work with protobufs by analogy here fails because the scopes of power are so vastly different.
- gumby 7y ago
  The problem was stated in Felker's response: "...corporate development teams are uniquely qualified to utterly botch a libc, yet still push it into widespread use..." This can come innocently as well. For a simple non-code example: google has a code style guide. For C++ it says "don't use exceptions" and even (or used to?) explains that the writers consider exceptions to be a good thing but they have enough legacy / third party code base that doesn't use them that they can't switch. Lots of people use the google style guide because it exists, rather than write one themselves, or rather than spend time hashing one out. So they end up shackling themselves to a constraint entirely resulting from an environment they are not in. I see this indirectly in your own comment, where you casually referred to gRPC or protobufs as "fundamental piece[s] of architecture". Well they aren't standards, they are technologies that google likes. Protobufs is a perfect example of a technology in, well not widespread use, but is used by a bunch of projects, and as discussed elsewhere contains a number of decisions that reflect the google environment, probably not resulting in a great fit for a number of places where it is used. There's nothing malign in that; the whole point of writing code is to meet your needs. But when you're an 800 pound gorilla, don't presume your every step is what everyone else needs. They are what you need and without proactive effort may not help many others....but can crowd out what could.
  - jchw 7y ago
    >I see this indirectly in your own comment, where you casually referred to gRPC or protobufs as "fundamental piece[s] of architecture". Well they aren't standards, they are technologies that google likes. Protobufs is a perfect example of a technology in, well not widespread use, but is used by a bunch of projects, and as discussed elsewhere contains a number of decisions that reflect the google environment, probably not resulting in a great fit for a number of places where it is used. I am not suggesting they're fundamental to the world, rather just fundamental pieces of architecture where they're being used at. That is to say, fundamental in a similar (though not identical) way to a libc would be. This is more of a miscommunication than a disagreement I think. >There's nothing malign in that; the whole point of writing code is to meet your needs. But when you're an 800 pound gorilla, don't presume your every step is what everyone else needs. They are what you need and without proactive effort may not help many others....but can crowd out what could. So, I'm not in the know, but... To quote the original post: > So, what do you think about incorporating this new libc under the LLVM project? That would, to me, imply under LLVM governance, not Google, and I think that's the primary thing people should focus on if they are worried. Kubernetes is a good example of where I think this ended up going extremely well; Kubernetes is under control of CNCF and not Google. Moving governance elsewhere is surely beneficial for the project's health, and since it's a low level piece of architecture rather than an end user product, I see no reason why there wouldn't be motivation to do that. It appears it is the intent to do that in the first place.
sporkland 7y ago
I'm not making a comment dressed as a question, I'm genuinely curious. Is this super different from the linux kernel policy that you don't break user space? Both in intent and in effect.
- firethief 7y ago
  In this scenario "userspace" refers to Google's code, and "breaking" it would be necessary to fix it for everyone else.

by ajxs 7y ago

jchw 7y ago

(Disclosure, Googler here, not working on projects related to any of the things being discussed, speaking in a purely personal capacity.) I hate to disagree with Rich Felker. I think most people have a lot of respect for musl and the amount of effort it took. But, I disagree with the basic conclusions. For one thing, I don't think it's fair to compare this to Chrome, an end user product. libc is a fundamental piece of architecture, like (edit: as in, fundamental in stacks that they are used in, to clarify) protobufs, gRPC, Kubernetes, etc. I heavily sympathize with folks uneasy about the Chrome situation - like I've mentioned maybe hundreds of times now I use and recommend Firefox personally, but I feel this particular discussion will become more productive when that stops being a focal point. Their other points are not really related, but I disagree with them also. I don't think there's a good motivation to keep bugs for backwards compatibility: Google runs non-Google software, too; keeping subtle incompatibilities could be a disaster. Also, Google has a pretty good corpus of code to test their libc on, so I think they have a unique opportunity to fast-track a pretty battle-tested libc (I did not know of this project before this Hacker News post, so this is purely a hot take, but for now I stand by it.) No idea what their plan is, but open governance would probably work wonders here. After all, LLVM has plenty of corporate contributors, and it seems to do fine.

stochastic_monk 7y ago
I think trying to work with protobufs by analogy here fails because the scopes of power are so vastly different.
gumby 7y ago
The problem was stated in Felker's response: "...corporate development teams are uniquely qualified to utterly botch a libc, yet still push it into widespread use..." This can come innocently as well. For a simple non-code example: google has a code style guide. For C++ it says "don't use exceptions" and even (or used to?) explains that the writers consider exceptions to be a good thing but they have enough legacy / third party code base that doesn't use them that they can't switch. Lots of people use the google style guide because it exists, rather than write one themselves, or rather than spend time hashing one out. So they end up shackling themselves to a constraint entirely resulting from an environment they are not in. I see this indirectly in your own comment, where you casually referred to gRPC or protobufs as "fundamental piece[s] of architecture". Well they aren't standards, they are technologies that google likes. Protobufs is a perfect example of a technology in, well not widespread use, but is used by a bunch of projects, and as discussed elsewhere contains a number of decisions that reflect the google environment, probably not resulting in a great fit for a number of places where it is used. There's nothing malign in that; the whole point of writing code is to meet your needs. But when you're an 800 pound gorilla, don't presume your every step is what everyone else needs. They are what you need and without proactive effort may not help many others....but can crowd out what could.
- jchw 7y ago
  >I see this indirectly in your own comment, where you casually referred to gRPC or protobufs as "fundamental piece[s] of architecture". Well they aren't standards, they are technologies that google likes. Protobufs is a perfect example of a technology in, well not widespread use, but is used by a bunch of projects, and as discussed elsewhere contains a number of decisions that reflect the google environment, probably not resulting in a great fit for a number of places where it is used. I am not suggesting they're fundamental to the world, rather just fundamental pieces of architecture where they're being used at. That is to say, fundamental in a similar (though not identical) way to a libc would be. This is more of a miscommunication than a disagreement I think. >There's nothing malign in that; the whole point of writing code is to meet your needs. But when you're an 800 pound gorilla, don't presume your every step is what everyone else needs. They are what you need and without proactive effort may not help many others....but can crowd out what could. So, I'm not in the know, but... To quote the original post: > So, what do you think about incorporating this new libc under the LLVM project? That would, to me, imply under LLVM governance, not Google, and I think that's the primary thing people should focus on if they are worried. Kubernetes is a good example of where I think this ended up going extremely well; Kubernetes is under control of CNCF and not Google. Moving governance elsewhere is surely beneficial for the project's health, and since it's a low level piece of architecture rather than an end user product, I see no reason why there wouldn't be motivation to do that. It appears it is the intent to do that in the first place.

sporkland 7y ago

I'm not making a comment dressed as a question, I'm genuinely curious. Is this super different from the linux kernel policy that you don't break user space? Both in intent and in effect.

firethief 7y ago
In this scenario "userspace" refers to Google's code, and "breaking" it would be necessary to fix it for everyone else.