Fedora is implementing a change to enhance package reproducibility, aiming for a 99% success rate. This involves using "source date epochs" (SDE) which fixes build timestamps to a specific point in the past, eliminating variations caused by differing build times. While this approach simplifies reproducibility checks and reduces false positives, it won't address all issues, such as non-deterministic build processes within the software itself. The project is actively seeking community involvement in testing and reporting any remaining non-reproducible packages after the SDE switch.
The author dramatically improved the debug build speed of their C++ project, achieving up to 100x faster execution. The primary culprit was excessive logging, specifically the use of a logging library with a slow formatting implementation, exacerbated by unnecessary string formatting even when logs weren't being written. By switching to a faster logging library (spdlog), deferring string formatting until after log level checks, and optimizing other minor inefficiencies, they brought their debug build performance to a usable level, allowing for significantly faster iteration times during development.
Commenters on Hacker News largely praised the author's approach to optimizing debug builds, emphasizing the significant impact build times have on developer productivity. Several highlighted the importance of the described techniques, like using link-time optimization (LTO) and profile-guided optimization (PGO) even in debug builds, challenging the common trade-off between debuggability and speed. Some shared similar experiences and alternative optimization strategies, such as using pre-compiled headers (PCH) and unity builds, or employing tools like ccache. A few also pointed out potential downsides, like increased memory usage with LTO, and the need to balance optimization with the ability to effectively debug. The overall sentiment was that the author's detailed breakdown offered valuable insights and practical solutions for a common developer pain point.
The GNU Make Standard Library (GMSL) offers a collection of reusable Makefile functions designed to simplify common build tasks and promote best practices in GNU Make projects. It provides functions for tasks like finding files, managing dependencies, working with directories, handling shell commands, and more. By incorporating GMSL, Makefiles can become more concise, readable, and maintainable, reducing boilerplate and improving consistency across projects. The library is designed to be modular, allowing users to include only the functions they need.
Hacker News users discussed the GNU Make Standard Library (GMSL), mostly focusing on its potential usefulness and questioning its necessity. Some commenters appreciated the idea of standardized functions for common Make tasks, finding it could improve readability and reduce boilerplate. Others argued that existing solutions like shell scripts or including Makefiles suffice, viewing GMSL as adding unnecessary complexity. The discussion also touched upon the discoverability of such a library and whether the chosen license (GPLv3) would limit its adoption. Some expressed concern about the potential for GPLv3 to "infect" projects using the library. Finally, a few users pointed out alternatives like using a higher-level build system or other scripting languages to replace Make entirely.
Apple is open-sourcing Swift Build, the build system used to create Swift itself and related projects. This move aims to improve build performance, enable more seamless integration with other build systems, and foster community involvement in its evolution. The open-sourcing effort will happen gradually, focusing initially on the build system's core components, including the build planning framework and the driver responsible for invoking build tools. Future plans include exploring alternative build executors and potentially supporting other languages beyond Swift. This change is expected to increase transparency, encourage broader adoption, and facilitate the development of new tools and integrations by the community.
HN commenters generally expressed cautious optimism about Apple open sourcing Swift Build. Some praised the potential for improved build times and cross-platform compatibility, particularly for non-Apple platforms. Several brought up concerns about how actively Apple will maintain the open-source project and whether it will truly benefit the wider community or primarily serve Apple's internal needs. Others questioned the long-term implications, wondering if this move signals Apple's eventual shift away from Xcode. A few commenters also discussed the technical details, comparing Swift Build to other build systems like Bazel and CMake, and speculating about potential integration challenges. Some highlighted the importance of community involvement for the project's success.
Werk is a new build tool designed for simplicity and speed, focusing on task automation and project management. Written in Rust, it uses a declarative TOML configuration file to define commands and dependencies, offering a straightforward alternative to more complex tools like Make, Ninja, or just shell scripts. Werk aims for minimal overhead and predictable behavior, featuring parallel execution, a human-readable configuration format, and built-in dependency management to ensure efficient builds. It's intended to be a versatile tool suitable for various tasks from simple build processes to more complex workflows.
HN users generally praised Werk's simplicity and speed, particularly for smaller projects. Several compared it favorably to tools like Taskfile, Just, and Make, highlighting its cleaner syntax and faster execution. Some expressed concerns about its reliance on Deno and potential lack of Windows support, though the creator clarified that Windows compatibility is planned. Others questioned the long-term viability of Deno itself. Despite some skepticism, the overall reception was positive, with many appreciating the "fresh take" on build tools and its potential as a lightweight alternative to more complex systems. A few users also offered suggestions for improvements, including better error handling and more comprehensive documentation.
Summary of Comments ( 195 )
https://news.ycombinator.com/item?id=43653672
Hacker News users discuss the implications of Fedora's push for reproducible builds, focusing on the practical challenges. Some express skepticism about achieving true reproducibility given the complexity of build environments and dependencies. Others highlight the security benefits, emphasizing the ability to verify package integrity and prevent malicious tampering. The discussion also touches on the potential trade-offs, like increased build times and the need for stricter control over build processes. A few commenters suggest that while perfect reproducibility might be difficult, even partial reproducibility offers significant value. There's also debate about the scope of the project, with some wondering about the inclusion of non-free firmware and the challenges of reproducing hardware-specific optimizations.
The Hacker News post "Fedora change aims for 99% package reproducibility" generated a moderate discussion with several insightful comments. Many commenters expressed support for the initiative, viewing reproducible builds as a crucial step towards enhancing software security and trustworthiness.
One compelling comment highlighted the significance of reproducibility in verifying the integrity of downloaded packages, ensuring they haven't been tampered with. This resonates with the broader security concerns around supply chain attacks, where malicious actors compromise software during the build process. Reproducibility offers a mechanism to verify the authenticity of builds by independently recreating them and comparing the results.
Another commenter delved into the technical challenges of achieving full reproducibility, particularly with aspects like timestamps and build paths embedded within binaries. They emphasized the need for careful consideration of these details to ensure consistent build outputs. This point underscores the complexity of implementing reproducible builds and the meticulous effort required by package maintainers.
Some users questioned the practicality of aiming for 99% reproducibility, wondering about the remaining 1% and the potential difficulties in achieving perfect reproducibility. This prompted a discussion about the trade-offs between striving for ideal reproducibility and the pragmatic limitations imposed by certain software components or build processes.
Furthermore, a comment mentioned the importance of tools and infrastructure for verifying reproducibility, suggesting that simply rebuilding packages isn't sufficient. Robust verification mechanisms are essential for ensuring the integrity and consistency of the reproduced builds.
Several comments also touched upon the broader benefits of reproducible builds beyond security, such as easier debugging, improved transparency, and greater community involvement in the software development lifecycle. These comments showcase the wide-ranging impact of reproducible builds on the software ecosystem.
Overall, the comments on Hacker News generally demonstrate a positive reception towards Fedora's initiative for reproducible builds, recognizing its potential to improve software security and reliability. The discussion also acknowledges the technical complexities and the need for robust tooling to effectively implement and verify reproducible builds.