News for hackers. Stuff that matters.
Re:Introducing Abseil, a new common libraries project by jzelinskie on Wednesday September 27, 2017 @11:56PM (#15354436)
At first I thought this would have a lot of overlap with Facebook's folly[0], but after glancing at the internal packages, Abseil looks lower level: it provides alternatives to STL types with shims for older compilers.

It's interesting to see more and more Google internals being open sourced. It's like Blaze being released as Bazel[1] opened the flood gates for many other projects to be shared. Can any Googlers speak to how these projects are synchronized with the internal monorepo?

[0]: https://github.com/facebook/folly

[1]: https://bazel.build

Re:Introducing Abseil, a new common libraries project by fourth_party on Thursday September 28, 2017 @12:40AM (#15354668)
Within google, google’s own open source software is treated as “third party”.

https://opensource.google.com/docs/thirdparty/

Re:Introducing Abseil, a new common libraries project by jzelinskie on Thursday September 28, 2017 @01:16AM (#15354823)
Thanks for the response. Are things moving into third party or are new projects being created in third party and maintained alongside the originals?

I and probably many others are more likely to be willing to depend on a library if I know Google internals directly depend on the maintenance of said library.

Re:Introducing Abseil, a new common libraries project by yegle on Thursday September 28, 2017 @01:55AM (#15354967)
Likely no one would answer this question considering the info is confidential. I think the best way to understand how Google uses a monorepo is this doc [0].

Disclaimer: yes I work for Google but my work is not related to Abseil team.

[0]: https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...

Re:Introducing Abseil, a new common libraries project by joshuamorton on Thursday September 28, 2017 @01:57AM (#15354979)
Parroting this comment (that is probably confidential), the abseil website does include this statement:

>The libraries we are releasing come with a pedigree: many years of experience using these APIs in Google’s production environments. We’ve seen what works and what doesn’t, what designs lead to bugs, performance problems, and misuse. What you see here is what we found to be a good balance between simplicity and meeting the needs of production use and an ever-evolving codebase. [1]

Also a googler who has nothing to do with abseil.

[1]: https://abseil.io/

Re:Introducing Abseil, a new common libraries project by ehnto on Thursday September 28, 2017 @01:45AM (#15354936)
I have always wondered how the monorepo design works in regards to more sensitive pieces of code. For example some of the key algorithms behind search.
Re:Introducing Abseil, a new common libraries project by joshuamorton on Thursday September 28, 2017 @01:50AM (#15354951)
>Since Google's source code is one of the company's most important assets, security features are a key consideration in Piper's design. Piper supports file-level access control lists. Most of the repository is visible to all Piper users;d however, important configuration files or files including business-critical algorithms can be more tightly controlled. In addition, read and write access to files in Piper is logged. If sensitive data is accidentally committed to Piper, the file in question can be purged. The read logs allow administrators to determine if anyone accessed the problematic file before it was removed.

From [1]. Essentially, there are files and changes that I cannot view the source of.

[1]: https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...

Re:Introducing Abseil, a new common libraries project by kerneis on Thursday September 28, 2017 @05:33AM (#15355869)
But where the real magic happens is that you can still build them, even if you cannot read them, if they are required as (direct or indirect) dependencies of your code.