My personal experience as a software engineer, and a former security researcher who did manual code audit, is that this code review tool has such poor results that it isn't worth the "noise" and friction it causes developers during C/I code review

MRC, which is already being used by OAI in production for training their models, aims to provide robust network utilization, allowing improved bandwidth while also efficiently handling network failures automatically at routing level.

Comments URL: https://news.ycombinator.com/item?id=48045851

Points: 5

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=47958364

Points: 25

# Comments: 3

Comments URL: https://news.ycombinator.com/item?id=46214483

Points: 2

# Comments: 0

Hence, for a "file-sections" flag, we would only resolve relocations within a given file, but will leave intact relocations that cross the file boundary. Accordingly, this means that "function-sections" is identical to generating a static bundle object per original object file, and bundling them all together inside a .a archive.

This is the current intention, as implemented in the up-to-date draft: https://github.com/bminor/binutils-gdb/commit/99aef6ba8db670.... Please note however that one would no longer need to specify the "--whole-archive" flag, hence resolving issues with potential duplicate placement of the static library in the linker's CLI.

> Are there cases in which function-sections doesn't work (GCs too much) but a hypothetical "file-sections" does? For example cases in which the code relies on side effects of global constructors, but those would be left out by function-sections?

Good question. In the first article in this series I discussed issues with global constructors and was pretty much waved away, being told that code should not be written this way. One of the members of the ELF committee did suggest an alternative for handling it yet pretty much mentioned that there are still missing pieces that require handling for their proposal to work (https://groups.google.com/g/generic-abi/c/sT25-xfX9yc/m/NRo0...).

The key point in the proposal for a static-bundle-object is to properly handle static libraries as linked objects, instead of as a bunch of plain .o files.

I hope that once integrated to linkers the adoption of this new format will help convince that it deserves significantly better tooling.

While the previous article presented the problem domain (multiple issues with using .a archives of plain object-code files for static libraries), this article presents the technical white paper that formally proposes an alternative format (accompanied by a POC on top of GNU's ld), as well as the gist of the ELF committee's discussion about the proposal.

Given the decision of the ELF committee, the format will be judged by adoption in practice and the feedback it receives from users. In other words, your opinion is more than welcome.

Comments URL: https://news.ycombinator.com/item?id=45503958

Points: 4

# Comments: 2

Isn't this policy overruling the judgement of the team/product lead and focuses too much "only" on the bugs?

Aside from that, while it might seem like an ideal engineering culture, I find it a bit extreme. The harsh SLA leaves little room for prioritization. Sometime the team is in fact working on a tough integration deadline, and medium-level bugs can wait for it to finish.

Going over my current list of bugs, some are minor and can wait to the last mile of the release and some will be resolved by new features we have in planning. I do aim to minimize the list of bugs and even my email inbox is based on a "zero inbox" policy. Still "zero" in this case is some small epsilon that is under control, and will go down to zero if no new bugs/emails arrive in the meantime. Call it a sliding window of epsilon width, but it almost never really reaches zero.

Propagating the fix downstream depends on the release cycles of all downward vendors. Giving them a heads up will help planning, but I doubt it will significantly impact the patching timeline.

It is highly more likely that companies will get stressed that the public knows they have a vulnerability, while they are still working to fix it. The pressure from these companies will probably shut this policy change down.

Also, will this policy apply also to Google's own products?

If pkg-config was never meant to be consumed directly, and was always meant to be post processed, then we are missing this post processing tool. Reinventing it in every compilation technology again and again is suboptimal, and at least Make and CMake do not have this post processing support.