The BOINC client core
The Berkeley Open Infrastructure for Network Computing (BOINC) is an open-
source software platform which supports distributed computing, primarily in
the form of "volunteer" computing and "desktop Grid" computing. It is well
suited for problems which are often described as "trivially parallel". BOINC
is the underlying software used by projects such as SETI@home, Einstein@Home,
ClimatePrediciton.net, the World Community Grid, and many other distributed
computing projects.
This package installs the BOINC client software, which will allow your
computer to participate in one or more BOINC projects, using your spare
computer time to search for cures for diseases, model protein folding, study
global warming, discover sources of gravitational waves, and many other types
of scientific and mathematical research.
- Developed at network
- Sources inherited from project openSUSE:Factory
-
3
derived packages
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout home:adrianSuSE:PL/boinc-client && cd $_
- Create Badge
Source Files
Filename | Size | Changed |
---|---|---|
8.0.2.tar.gz | 0046978849 44.8 MB | |
README.SUSE | 0000005364 5.24 KB | |
boinc-client-rpmlintrc | 0000000039 39 Bytes | |
boinc-client.changes | 0000028438 27.8 KB | |
boinc-client.service | 0000000954 954 Bytes | |
boinc-client.spec | 0000011336 11.1 KB | |
boinc-docbook2x.patch | 0000000801 801 Bytes | |
boinc-logrotate | 0000000486 486 Bytes | |
boinc-manager | 0000000221 221 Bytes | |
build-client-scripts.patch | 0000000353 353 Bytes | |
libboinc-shared.patch | 0000006134 5.99 KB | |
sysconfig.boinc-client | 0000001510 1.47 KB | |
xlocale.patch | 0000000569 569 Bytes |
Revision 63 (latest revision is 65)
fix for bnc#1227092 (forwarded request 1184356 from computersalat)
Comments 12
Why did you break idle detection in this?
What kinda question is that... if you have a bug report to make, please do so upstream at https://github.com/BOINC/boinc .
No, this is something that was done deliberately in the OpenSUSE packages, it works fine in the upstream version.
Idle detection was always broken. If you're running BOINC as a separate service, as openSUSE does it, it doesn't have access to your X server, and it will do nothing more than spam your logs (https://github.com/BOINC/boinc/issues/2256). Needless to say that it doesn't work on Wayland at all. That's why I proposed to disable it entirely in sr#626119.
Solving this doesn't seem trivial, which is why the upstream bug is almost three years old. My recommendation would be to go with exclusive applications or limits on CPU or memory usage for now.
Alternatively, solve the issue by finding a way to detect idleness without access to an X session.
It does work just fine, as long as you give Boinc access to the X server, except here the functionality has been patched out to very little benefit, with no alternative given. So now it will just refuse to work for no apparent reason even with the workarounds that work for the upstream version, and used to work with this version, leading to confusion. And you don't even mention this in the description. How about you find a way, if you're gonna patch out core functionality that works perfectly fine. As for limits, they do not work for GPU usage.
You can certainly give BOINC access to the X server, but we're talking about a service that downloads random binaries from not-really-trusted sources and runs them, so I wouldn't recommend this.
Removing the "functionality" provides the benefit of not spamming the system log to the point of rendering it unusable. Which is something that people care about. Also people care about a computation daemon not depending on X libraries.
The biggest problem about the existing idle detection is that it's architecturally wrong. The right architecture is a process running under the X or Wayland session and its user that signals to BOINC from the outside if it should do work or not. Gladly people are working on that. But I think you know that, since you commented on the issue.
Could we reenable idle detection in its current sorry state? Yes, but it's fundamentally at odds with users who want more security, see e.g. #4105. At some point we will run into conflicts between strengthening the sandboxing of the service and the current idle detection. If that were a fundamental conflict I would be happy to discuss it, but since a proper design would both allow idle detection and be secure that discussion doesn't make sense.
If you want this to work, my best advice is to check in with Germano about the state of his efforts or help get them in yourself. Resurrecting this broken mess isn't going to help anyone in the long run.
Not saying it's ideal in the long run. It should certainly be replaced as soon as possible. But until then, this is the only option. So I guess until then I'll keep compiling it on my own.
The issue that you've linked seems unrelated to idle detection, unless I'm missing something. And if you're using BOINC 7.25 as you wrote in the issue, you're probably not using this package here, which is at 7.24.1.
Apart from that, I don't really understand your questions. Not wanting
boinc-client
to depend on X libraries has nothing to do with whether they're up-to-date or not. You can find all technical background information in the issues linked above.Did you get an other impression from the software situation according to the message “Authorization required, but no authorization protocol specified” than the feedback by Vitalii Koshura on 2023-09-27?
Probably.
I am trying to find solutions for undesirable software behaviour which I observed on my openSUSE Tumbleweed system.
Which source code generates the mentioned message?
Would you like to influence progress for the issue “redesign Linux idle detection”?
I added some debug output in used source files.
Thus I wonder still about another test result like the following.
How should the control flow evolve further here?
How do you think about to compare software run time characteristics for the following code variant?
A corresponding test result looks promising.
Will any development ideas become more appealing (so that undesirable communication blockages will also be reconsidered accordingly)?
I am curious how another clarification approach will evolve.