Application v0.911 is out, as a bugfix for the 0.91 release earlier today.

• This application is compiled with the same software as the original v0.90 This has means a) CentOS 7 is once again not supported, bug b) the extra crashes associated on non-Centos systems should go away.
  
• This update also fixes a checkpoint/snapshot issue present in 0.90.
  

Please report any further issues in the forum.

Looks like the decimal point in the application version got moved. My machine is showing it as 9.11, not .911.

---

Reno, NV
Team: SETI.USA

So I noticed. its not worth fixing.

Edit: I should elaborate. The application version is set to 0.911 everywhere I set it, but for some reason the UI has decided to ignore the decimal point. Eh, versions are just arbitrary numbers anyway.

The first task on my Gentoo Linux system failed.

https://www.mlcathome.org/mlcathome/result.php?resultid=50200

Apparently the app is trying to use /dev/fuse. Is that a security risk? I'm hesitant to open it up to non-root users.

So I noticed. its not worth fixing.

Edit: I should elaborate. The application version is set to 0.911 everywhere I set it, but for some reason the UI has decided to ignore the decimal point. Eh, versions are just arbitrary numbers anyway.

The BOINC version number format is MMmm (major major / minor minor). Only two digits are allowed for the version number to the right of the decimal place.

90 == 0.90

91 == 0.91

9 == 0.09

100 == 1.00

911 == 9.11

It's impossible to have a BOINC version number of "0.911"

The current documentation page for releasing apps is https://boinc.berkeley.edu/trac/wiki/AppVersionNew, but it doesn't describe the version number format. I suppose you need to look at the documentation for the older release mechanism at https://boinc.berkeley.edu/trac/wiki/UpdateVersions. The important part is:

VERSION is a string of the form N.M, where N and M are integers with M<100. This is converted to the single integer N*100 + M, which is used to specify application versions elsewhere in BOINC. M may have a leading zero, which is ignored.

---

Want to find one of the largest known primes? Try PrimeGrid. Or help cure disease at WCG.

The first task on my Gentoo Linux system failed.

https://www.mlcathome.org/mlcathome/result.php?resultid=50200

Apparently the app is trying to use /dev/fuse. Is that a security risk? I'm hesitant to open it up to non-root users.

FUSE is designed from the beginning to allow a filesystem in userspace, and is designed so that users can do it. Ubuntu/Debian/Fedora/OpenSUSE/Centos/RHEL all allow it. Still, I'd recommend you read up on it decide for yourself if you're comfortable opening it up. You could probably also limit it to only the boinc user.

The application is bundled as an AppImage, which allows me to ship the app and all its dependencies as one binary. To achieve this, it creates a small chroot with the binary and the dependent libs on a squashfs filesystem embedded in the binary. When executed, the appimage portion creates a temporary mount point in /tmp, mounts the squashfs image there, and executes a script which sets up the linker path to look for libs in the squashfs before looking on the main system, and then runs the app.

Installed Centos 8 on a new 32thread server and tested this and looks like results are valid.

...Apparently the app is trying to use /dev/fuse. Is that a security risk? I'm hesitant to open it up to non-root users.

FUSE is designed from the beginning to allow a filesystem in userspace, and is designed so that users can do it. Ubuntu/Debian/Fedora/OpenSUSE/Centos/RHEL all allow it. Still, I'd recommend you read up on it decide for yourself if you're comfortable opening it up. You could probably also limit it to only the boinc user.

The application is bundled as an AppImage, which allows me to ship the app and all its dependencies as one binary. To achieve this, it creates a small chroot with the binary and the dependent libs on a squashfs filesystem embedded in the binary. When executed, the appimage portion creates a temporary mount point in /tmp, mounts the squashfs image there, and executes a script which sets up the linker path to look for libs in the squashfs before looking on the main system, and then runs the app.

boinc is precisely the user I don't want having any added access for mounting. boinc needs to stay in the boinc home folder (/var/lib/boinc). There have been too many projects that have been malicious for me to trust boinc with any added priviledges. '/var/lib/boinc' has its own partition. Don't want it running anywhere else.