Presumably it would be worth enquiring into the coverage offered by the distribution-specific packaged versions, before committing any resources. What proportion of our Linux volunteers (both current and potential) are running a dialect of Linux for which there is an active package maintainer?
SETI@Home used to maintain a list of client versions used at their project. The script hasn't been maintained for several years, but https://setiathome.berkeley.edu/client_types.php shows what was being used as at March 19 2013 (considerably earlier than the last Berkeley compatibility packages). If that script could be tickled into life again for one last hurrah, we might get a snapshot of the balance between Linux versions 7.2.42/7.4.22 (presumed Berkeley) and versions 7.6.33/7.8.3 (presumed distro maintainer). We ought also to mention security. As I understand it, the distro maintainers tend to implement restricted-user sandboxing, whereas the Berkeley static-linked .sea packages ran in user space. Volunteers who like to tinker with their installations sometimes find the latter approach easier to work with. On Sunday, 22 October 2017, 15:49, Steffen Möller <steffen_moel...@gmx.de> wrote: Hello, On 17.10.17 00:15, David Anderson wrote: > Our policy for a long time was: > > - provide a .sea release (including manager) for current Ubuntu/x86, > with no effort to make it run anywhere else. > - provide a client-only (no manager) release built on an old Linux > system, > everything static, for maximum compatibility. > We have a "compatability VM" in which to build this. Close to nothing on Ubuntu is statically linked. And for BOINC there is not need to be statically linked, either - when shipping as as part of the distribution, this is. > At some point (maybe when Rom left) we stopped doing this. > I suggest that we start again. > Maybe change to 64 bit. Of course you can just go and do that. And for the "competition is always good" mantra or as a reference for bug reports I am also embracing that. A complementary strategy could be to just embrace all those volunteer packagers out there and call them a part of BOINC. I have not talked back to Gianfranco about it, but I have some confidence that he does not mind to move the Debian/Ubuntu-package build instructions from git.debian.org to github for easier accessibility, if that is of any help. Best, Steffen > > On 10/16/2017 7:46 AM, Steffen Möller wrote: >> On 16.10.17 15:07, Laurence wrote: >>> Hi Jord, >>> >>> On 16/10/17 12:24, Jord van der Elst wrote: >>>> On Mon, Oct 16, 2017 at 12:06 PM, Richard Haselgrove >>>> <r.haselgr...@btopenworld.com <mailto:r.haselgr...@btopenworld.com>> >>>> wrote: >>>> >>>> Berkeley has outsourced the distribution of Linux clients to the >>>> package maintainers for individual distributions, for several >>>> years now. >>>> >>>> >>>> Laurence is the release manager for Linux, I suspect he knows about >>>> all of that. :-) >>> No I didn't, so thanks. Only stepped forward after the September >>> workshop. >>>> But even if the distro package maintainers release these versions, >>>> they also do so first for testing and can then still ask people to >>>> report their results on the Alpha project. Their source code is still >>>> coming from github as well. >>> Even if the package maintainers build and release, as you pointed out >>> the versioned upstream code still comes from the project. I have just >>> discovered that Gianfranco is doing daily builds (every 4h) and >>> creating packages for Debian from the git master. This is a nice step >>> towards CI. >> And he also builds the complete packages together with the server side >> components afterwards that go to the experimental section of Debian - >> see the boinc-server-maker package >> https://packages.qa.debian.org/b/boinc/news/20171005T094923Z.html. It >> would help a lot if the server bits in master are always be at a stage >> that it could be released. >> >> In my mind this goes as far as that for automated testing we could have >> dummy project set up in an automated fashion and do few workunits on >> those. >> >> Cheers, >> >> Steffen >> >> _______________________________________________ >> boinc_dev mailing list >> boinc_dev@ssl.berkeley.edu >> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >> To unsubscribe, visit the above URL and >> (near bottom of page) enter your email address. > > _______________________________________________ > boinc_dev mailing list > boinc_dev@ssl.berkeley.edu > https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
