Vanilla BOINC packages: the reason and the purpose


I have very controversial feelings about open-source software and Linux OS. From one hand, I like the idea of the transparency, when you can always check what is really doing every application you run. From the other hand, as a maintainer of the application, you lose some part of control on it, because it is possible to modify some application's behavior (e.g. via distro patches), that contradicts the original idea of it or break some functionality. And because there are so many different OSs, you can't keep an eye on all of them. That is why sometimes you receive a bug report that looks completely weird, and when you start doing the investigation, you realize, that this happened because of the distro patch, that was intended to fix another issue, but as a result introduced a new one. And, as a maintainer of the application, there are not so much options for you here. But in any case, you have unsatisfied user, that is always bad.

We, at BOINC, faced several times the situation when the package that is distributed with the distro is completely broken, and users have no idea how to fix that. You can post instructions, blog posts, answer questions of forums, but still the same question about the same bug will be asked. Sometimes the communication with the distro maintainers becomes hot, and every party is completely sure that only their opinion is correct.

To get rid of this situation, we decided to create our own BOINC vanilla builds for Linux. We have started with the most popular distributions: Debian, Ubuntu, Fedora and openSUSE. Currently we target only the LTS releases that are officially supported, so that is why for now we provide packages for Ubuntu 20.04 and 22.04 only.

More details (including the list of supported OSs) are here: https://github.com/BOINC/boinc/wiki/Linux-DEB-and-RPM-support

Since building all these packages (20 in total for every version) is quite a task, I had to try to automate this as much as possible, including adding some integration tests to avoid very dumb bugs. I can't say that the current CI is finished, but it does its work already: every night we have a new build that is automatically published to the 'nightly' channel on the BOINC official website. This gives our users the opportunity to test new features as soon as they added to the codebase even before the alpha testing phase begins. I can't say this is a recommended way of installing BOINC, but since we have now 2-3 releases every year, it might be helpful for those who have problems with the issues that are blockers for them only.

These packages are not yet recommended to use, but the first result is already very promising. On the video below the process of installation of both BOINC client and Manager on Ubuntu 22.04 is shown:


Of course, there are still some issues, but now it will be much easier to fix them and deliver to our users faster.

Stay tuned for further updates.

Introduction

Several weeks ago I was working on a solution for a bug that was in Android BOINC for at least 4 years. This bug was very minor, that is why it was not fixed during all this time.

This was not the easiest bug to fix, and it required quite a deep research into Android internals, so I decided that it would be nice to share my findings (there will be a post about it later).

Usually I don't like writing long posts, but sometimes it's very important to share some information, including the technical one, with the people who might be interested in it. Also, such a posts might bring some light to the technical and design solutions in BOINC.

So, if any of you ever asked a question like "Why this was done in BOINC in this way?", you could probably find some answers in this blog.

I'm not a blogger, but I'll try to share more information about BOINC and what happens around it. This blog will not contain any personal and/or any other information that is not related to BOINC in one or another way. Also, the posts will be more or less big. That is why it will be updated very rare. Shorter but more frequent news and updates I usually post on my X/Twitter and/or Mastodon pages.