Conservancy Blog

Report from the 2016 Reproducible Builds Summit

by Brett Smith on December 26, 2016

A couple of weeks ago I was at the Reproducible Builds Summit in Berlin. Over sixty representatives from all kinds of projects came together for three days to share information and ideas, plan solutions, and even squeeze in a little time to hack. It was my first real opportunity to dive into this work. I learned a ton, even enough to chip in a little, and I’m looking forward to working more on reproducible builds from here on out.

When we talk about reproducible builds, what we mean is a build process that produces the exact same binary every time you run it with the exact same inputs (like source code versions and compiler settings). If you’re interested in the details, check out the definition on the Reproducible Builds site—a bunch of folks hammered that out during the Summit.

You might think most build processes would be reproducible most of the time, but often the binaries include small inputs that are hard to reproduce, such as timestamps or build paths. Much of the work toward reproducible builds so far has focused on improving the inputs: removing inputs that aren’t really necessary to the final product, and better recording the ones that are. Once that’s done, most build processes are as reproducible as you’d expect. There’s still more to do there, but there’s enough of a foundation that we can start seeing some benefits from reproducible builds. Many of the discussions at the Summit were about planning those next steps.

Conservancy is really excited to help reproducible builds. Having a clear and trusted link from source code to binary helps the community in many different ways:

The most obvious is security. When builds are reproducible, everyone can check for themselves that binaries they download actually come from the expected source code. We can demonstrate that unwanted code isn’t being added to distributors’ binaries, either accidentally or maliciously.
A reproducible build is a documented build. When everyone can see exactly what inputs and build steps generated a binary, everyone can review and comment on that build process. It becomes easier to find binaries with “bad” inputs (like a version of a library with a critical bug) and plan an upgrade process for them.
Reproducible builds can make license compliance easier for binary distributors. When a free software license requires distributors to provide source code, sometimes it can take a little work for them to figure out exactly what the right source code is. For example, if they have three versions of a development library installed on their build system, how do they know for sure which one went into the binary and should be included in the source code release? Reproducible builds record the answer unambiguously, in a format that can make it simple to put all the source code together.

We’ll reap the most benefits if there’s support at every level of the stack. Debian kickstarted the reproducible builds effort, and at the Summit there was a lot of great discussion about reaching out to other communities. Right now the focus is on other package distributors, so it was great to see representatives from Fedora, openSUSE, F-Droid, and Nix there. But our discussions also recognized the need for outreach to other projects that can play a role in this work, like build tools and other software that generates binaries that get shipped to users (such as filesystems or bytecode compilers). If you’re involved in a project like that, I encourage you to join us on the general mailing list for reproducible builds and introduce yourself. The more people working on this, the merrier!

Many thanks to all the Summit organizers for planning and running a productive working space. I’m already looking forward to the next reproducible builds meeting.

[permalink]

Tags: conservancy, Reproducible Builds

Chromium's Alice Boxhall Explains Why She Supports Conservancy

by Brett Smith on December 20, 2016

Alice Boxhall helps develop Chromium, with a focus on accessibility features. In this video, she talks about some of her favorite Conservancy member projects and why she supports the organization. Do you want free software to be for everyone too? Support Conservancy today!

[permalink]

Tags: conservancy, supporter, Member Projects

Catching up with Godot: An interview with Juan Linietsky

by Christine Lemmer-Webber on December 13, 2016

Godot is a multi-platform engine for 2D and 3D games. It provides common functionality for graphics, audio, physics, and more, so game developers can build on top of a solid foundation and spend more time working on the unique parts of their game. Godot is a Conservancy member project. (Become a Conservancy Supporter!)

Christopher Allan Webber, co-maintainer of GNU MediaGoblin and a Conservancy volunteer, recently sat down to learn more about Godot with one of the core developers, Juan Linietsky. Recently Linietsky’s been working on a new graphics renderer for Godot with funding from a Mozilla Open Source Support grant that Conservancy helps administer for the team.

CW: Tell us a bit about your project. What’s Godot, and why might a potentially-interested user pick it up?

JL: To explain why Godot is important, I believe it’s enough to explain some numbers about the software industry. Globally, the software industry moves around 400 billion dollars in revenue, out of which 100 billion are from the video game industry. Games are a huge industry that keeps growing.

Game development happens mostly with proprietary software, and almost half of it is done with a single proprietary tool (Unity 3D). For being such a huge industry, there are no comparable open source alternatives like Apache or Linux that game developers can use instead of proprietary solutions, even if they would be very welcome.

Godot is a project that aims to change that, by being a comparable open source offering. It’s growing very quickly in community and has a large and dedicated group of users and developers.

CW: So you’re a Conservancy member project! What was the decision like to join under the Conservancy umbrella?

JL: Godot is a project that has many users, institutions, companies and other non profit organizations interested in funding its development. As we the developers are only individuals, we need to make sure our donors and sponsors have a strong promise that their donations will be used for the benefit of the project. Conservancy is an institution with a flawless track record in this regard.

CW: Godot has its own internal language, I believe partly to control issues like garbage collection pauses. But Godot recently started adding support for C♯, which is garbage collected. Could you talk about your history of game scripting support, its motivations, and where you see it going in the future?

JL: The reasons why we ended up using our own scripting language are not obvious, but are very strong. Popular languages like Python and Lua were not designed with real-time applications in mind. The garbage collector can cause random stalls, and support for multithreading is not so efficient because they use giant locks. On top of that, the complexity of binding them to Godot was huge and very error-prone.

GDscript is a language that “just works” and Godot users love that. That said, we’re adding C♯ support due to popular demand, and the fact that Mono was released under the permissive MIT license a few months ago.

CW: How would you describe Godot’s community, and your relationship with it? Is there a direction you’d like to go towards stewarding community interactions?

JL: The Godot community is awesome, they are very helpful with each other (and if they are not, we make sure they are). We try to help everyone, no matter how much (or little) experience they have, and always encourage users to help each other.

CW: If someone is interested in getting into game engine development, with Godot or otherwise, where should they start and what sorts of resources are available to them?

JL: There is some documentation on the C++ side of things, and the code in general is well-organized. The best approach to starting with development is to implement your own feature (make sure main devs would like to merge it first) and then do a pull request.

CW: How long until Godot overtakes Unity? ;) More seriously, do you see Godot as an alternative to proprietary engines like Unity or the Unreal Engine? Or do you see Godot as serving a different niche?

JL: Our development is very focused on the following premises:

Godot must be very easy to use, simple and to the point, even by compromising flexibility if necessary.
It must be easy to make a 2D or 3D game look great with little effort.

So, in pratice, we aim for an engine that is easier to use than Unity, and that looks better than Unreal, and we are very close to getting there in the upcoming Godot 3.0.

CW: What kind of overlap do you have or hope to have with related libre software media production projects and communities like Blender?

JL: Many Godot users create their 3D art on Blender, and we’d like to have a better relationship with the team. We just heard they are working on a PBR viewport, so we will work hard to allow users exporting their 3D content as faithfully as possible to Godot.

CW: Thanks for the interview! Anything else you’d like readers to know about Godot before we wrap up?

JL: We always listen to our users, their problems and wishes even though we can’t always take immediate action. Currently we are focused on shipping a 3.0, wich will come with a completely new renderer. Godot 3.1 will improve some peripheral areas like the physics engine and the audio engine. Afterwards, I dream of a time where no new large features need to be implemented, so we can polish and improve as much as possible everything that is there!

Help Conservancy provide the stewardship to support projects like Godot by joining as a Conservancy Supporter today!

[permalink]

Tags: conservancy, Member Projects, Godot

QEMU's Stefan Hajnoczi on Why He's a Conservancy Supporter

by Karen Sandler on December 12, 2016

In this video, Stefan Hajnoczi, free software developer and contributor to QEMU, briefly explains why QEMU joined Conservancy and why he is a Conservancy Supporter. Join Stefan and join now!