Hi BOINC Community,

Last week Richard Haselgrove and I were asked to join a BOINC Work Group committee which researches how BOINC can be made more user friendly, easier for anyone to set up their own short- or long term project, and for the community to join in on those endeavours. The goal is to get more people to run BOINC, to join in coding all parts that make BOINC (client, manager, web site, forums, projects, etc.), to test everything, to get them to set up their own projects, to make BOINC a future-proof and reliable brand that isn't dependent on any one person in particular.

We do know this is a big order and it won't be solved in a couple of weeks. So we'll work in the background together with some key people from projects/code developers to get things started. Eventually we will need answers from you as well, probably on a lot of things. But we'll start slow with a couple of small questions:

1. If there is anything at all you can change in/withdraw from/add to BOINC, what would that be? While we don't exactly look for enhancements or bug squashing, you may just let out anything you think would put BOINC on the map. For example to add social media inside BOINC Manager, or have certain add-ons integrated into the client (I am making these up, they aren't on the list (yet)).

2. Would you like to contribute to making BOINC better, or program for it, or walk the source code, or do anything to help the project forward? What has held you back thus far?

3. We'd like to get into contact with people who programmed for BOINC, but no longer do. Can you PM me or Richard on this, or contact me via email? Especially if you're one of the people in the Volunteer Developers section here.

4. We also like to get into contact with people who now voluntarily program for BOINC. Can you tell us why you decided to work on BOINC, how difficult it was to get into and what we can do to increase your involvement?

With thanks for any answers you have,

Richard Haselgrove
Jord van der Elst

I am sure that compared with some things others come up with this will be a minor niggle but it would be good to see estimated time remaining change so it is based on Fraction Done divided by Elapsed time. This wouldn't solve the estimated time often being way out for tasks yet to start but it would reduce the need for mental arithmatic to work out a realistic time remaining.

Dave

Hi Richard and Jord,

Thanks for coming to the community

I run BOINC under Linux or WINE, so my comments are for the Linux client. I would like that:

1. Linux client has the same GUI features as WIN client - set work queue length, select events to log etc
2. Linux 64bit client detects and install 32bit libs needed for running CPDN models. Currently this is done manually, it is not trivial and there are many mis-configured Linux 64 bit machines that crash CPDN models
3. Be able to set data directory during install or later via GUI
4. Be able to pause upload of selected tasks without suspending network
5. Toggle between hours or days view in time elapsed/remaining columns
6. Be able to set project resource share from GUI

Thanks for taking the BOINC development forward,
Cheers
Ivo

Coming as I do from an old-fashioned software development background in which there is a central project repository and team-wide project management processes, I have found it difficult to access some open-source software projects (mostly to apply fixes or add-ons).

The problem usually arises because there is a technical solution to the code-sharing problem (GitHub etc.) but an ad hoc solution to the collaboration problem, and I strongly suspect that some open-source projects deliberately erect a barrier-to-entry on the ad hoc part, in which the knowledge of how to cross the barrier is known only by those who have already crossed the barrier; it is then regarded as some kind of initiation rite to obtain the knowledge to cross the barrier from outside. Most people rapidly conclude that they have better ways to spend their time.

So, it's a big ask, but my recommendation is to make the whole process visible and welcoming to outsiders - and not to reject most code changes for failing to satisfy some rule or objective of which the submitter could never have been aware.

I am a complete amateur. I know nothing about coding. That said, there are some things that I would like to see in a future version of Boinc.

1. The ability to run a specific project on a set number of cores all the times. As it is, when running more than one project at a time, the Boinc Manager decides what runs, when and for how long. This problem is especially bad with CPDN. Because of its 11 month deadlines the Boinc Manager often suspends CPDN WU’s indefinitely while it runs all the short deadline projects. The only way to deal with this is to set the work buffer very low at <2 days. Fixing this would make it much easier to run multiple projects on the same machine.

2. The ability to set different size work buffers for different projects would also be a big help. I don’t want to download 10 day worth of Milkyway all at once. That project just about always has work available. On the other hand, I do want to download 10 worth (or more) of CPDN all at once. With work available only sporadically it is necessary to take a big bite when the feeding is good.

---

I run Red Hat Enterprise Linux, currently
Red Hat Enterprise Linux Server release 6.9 (Santiago)

Red Hat support each release for 10 years, and correct bugs and security problems essentially immediately. This includes those applications that are part of the release.

Red Hat put out a new release about once every year and a half. The current release is RHEL 7 something.

The most practical source for me to obtain BOINC and its applications is from the EPEL project, but that is a volunteer effort, and BOINC and ClimatePrediction is not high on their priority list. So I currently run

boinc-client-7.2.33-3.git1994cc8.el6.x86_64

In the past, I have tried to obtain BOINC stuff direct from the BOINC web site, but this runs me into what is often called rpm hell as the dependencies to resolve BOINC cripple the system from running the normal stuff. And it requires completely different boinc-client file in /etc/rc.d/init.d

The fact that BOINC projects do not support older versions long enough has resulted me into dropping some projects altogether. I hated to do that, but I see no practical alternative.

---

Thanks all for your input, it is very much appreciated!
I'll be gathering everything everyone adds, no matter how weird, no matter how inconsequential you may feel it is, it's all very welcome!

Iain, I agree with the documentation side and am specifically working on that one. I totally agree that it lacks, that there should just be a page available that shows you in steps how to do things - and most importantly that when those steps change, that the documentation is adapted immediately.

BOINC for Linux is these days maintained by the package maintainers of the various distros. This so that BOINC is built with all the correct libraries for that distro.

'Berkeley' doesn't build BOINC anymore.
When a newer version is released for Windows or Mac, this is built and released by volunteers, by the BOINC community. Even David, Rom and Charlie are volunteers these days.

So you best ask your package maintainer about this, or check through the updates.

BOINC for Linux is these days maintained by the package maintainers of the various distros. This so that BOINC is built with all the correct libraries for that distro.

Good idea, but

Red Hat are responsible for the distribution of Red Hat Enterprise Linux (and, by implication, CentOS as well). BOINC and friends are not supported or maintained in these distributions. Volunteers maintain some additional packages, including BOINC, as part of the EPEL project, but they have not updated the boinc-client or boinc-manager since 2014-Feb-08, and I do not suppose they ever will.

https://fedoraproject.org/wiki/EPEL

---

Another consequence of this is version numbers not matching across distros - with Ubuntu the version number is 7. 6.33 I am not sure how version numbers compare and if version numbers will still be meaningful when comparing features?

Version numbers are derived from tags in the central BOINC git repository: they should be consistent across platforms.

The current (public, recommended) Windows version is also v7.6.33: Mac has an update to v7.6.34 to cope with an incompatibility in the latest release of the OS. So comparisons should be valid.

Thanks, that is good to be sure of Richard, though it seems strange that Ubuntu is offering 7. 6.33 when the newest version on the BOINC download page for Linux is 7.4.22 Also Red Hat seems to not have anything near the latest version.

Ubuntu (and I think one or two other distros) has an active volunteer package maintainer for BOINC.

Red Hat are responsible for the distribution of Red Hat Enterprise Linux (and, by implication, CentOS as well). BOINC and friends are not supported or maintained in these distributions. Volunteers maintain some additional packages, including BOINC, as part of the EPEL project, but they have not updated the boinc-client or boinc-manager since 2014-Feb-08, and I do not suppose they ever will.

https://fedoraproject.org/wiki/EPEL

That's for RH6, so you are probably right about it not changing. EPEL for RH7 has 7.6.22 right now. Of course that may never change through the life of RH7 either, but who knows...

Hi all,

First I'd like to thank those of you who took the time to post your grievances, feature requests and suggestions. We have quite a list already, but we'd love more. I can tell you that all of what makes it through to the list will be spoken about in detail between the group members and possibly back to you who asked about it.

Just so you know, this work group isn't some low people who were aimlessly waiting around in the lobby of some university, instead as I hinted in some posts already, these people aren't the least in BOINC, they do have something to say. They are senior project scientists and administrators, and other significant contributors.

Meet:
- Christian Beer - Einstein@Home
- David Wallom - Climateprediction.net
- Eric Korpela - Seti@Home
- Kevin Reed - IBM/World Community Grid
- Laurence Field - CERN/LHC
- Tristan Olive - Grid Republic
- David Anderson - BOINC

So yes, we're quite honored in that they asked us to gather around the table to discuss a lot of things about BOINC, and so should you. All the material Richard and I send in is talked about via email/a dedicated website. There's so much to talk about even, that some of it made it impossible for us to do all the Agenda points on the last weekly meetings. :)

Weekly we talk via teleconference with each other, which is really nice as at least that way the others can hear the urgency in my voice on anything I have to say. And that's not all just serious talk, there's a lot of humor passing by as well. Weirdly enough, sometimes these guys sound and act like humans. :-D

With that out of the way, please, continue. Give us a lot more to talk about, to decide upon, to vote on how we should change things. We're proud of you. We're BOINC, resistance is futile. :)

Jord.
Richard.

And while the out and out geeks could use Alien or some other solution to make an rpm from a recent .deb packages, it is never going to be an answer for the average Linux user.

Thanks for the opportunity to make some suggestions:

1. In BOINC Manager, in the Event Log, you can filter the entries by project only. I'd like to be able to filter by task as well. In both cases, it would be really good if the dropdown box listed the projects and tasks, so that you don't have to go searching for an entry to use as the filter "base".

2. This is a minor annoyance, but I'll put it on the list in case anyone is looking as the scheduler. I use app_config.xml files https://boinc.berkeley.edu/trac/wiki/ClientAppConfig to restrict the number of tasks that can run for projects that don't respect the Use at most N % CPU time option. However, the scheduler doesn't seem to cope with the restriction on the number of tasks properly, and there are occasions where even though there is work available, a core can sit idle presumably because the scheduler wants to run a project with a restricted number of tasks, but can't because of the restriction, and doesn't want to run a project which isn't restricted.

One for the server side BOINC I think given that I have seen the same on other projects.

On the server satus page under number of users and computers the numbers are aligned so that units are above units etc. Whereas left justification is used under the Tasks by application heading.

Haha, this seems like a fun thread. :)

Okay, I've been running BOINC at a user's perspective on-and-off for over a decade now. I'm a bit surprised that it hasn't really changed much over those years.

I live only in the "Advanced" interface. I don't even know what the basic interface properly looks like - first thing I do when I install it is switch to the advanced interface. It's hard to tell if regular Joes would prefer it to be in the basic interface or not. Maybe?

Logging - and communication of status - is my major gripe. I can't easily tell what BOINC sees available in my computer, and what it's telling projects I have. In fact, the most verbose computer stats I find are only on project websites - things like "GenuineIntel Intel(R) Core(TM) i5-6600K CPU @ 3.50GHz [Family 6 Model 94 Stepping 3] (4 processors)" and "NVIDIA GeForce GTX 1080 (4095MB) driver: 388.13 OpenCL: 1.2, INTEL Intel(R) HD Graphics 530 (6501MB) OpenCL: 2.0"... wow! Yeah, I'm sure, it just takes one basic API call to get them, and it doesn't seem like something materially worth giving its own place in the UI, but it's quite useful to know that it SEES them available! And alllllll the stuff in the show_host_detail.php pages... benchmark, fractions, settings, etc...

Basically, more local control and status over what the local machine is doing. Having to log into websites that look like they were last maintained in 2006 is really off-putting - especially if using an account manager that abstracts my login from other projects ("woh? I never signed up here~~ what's my login"). I'd think I should be able to see information about >this< computer... on >this< computer. Not from a distant website...

While the work/home location profiles are a clever hack, they also don't seem very intuitive. Put a computer into a location, then change the settings for the location. OK, good mechanism! But... locations aren't always in use by a computer, so there's a default location that's sometimes blank, "---", nonexistent, confusing. And locations don't always need settings, so the profile settings aren't shown until you "create" them. (??) ... The compromises made for location profiles to be "optional" are the most extremely confusing part of their implementation. If you just stop making those compromises - that is, to hard-code and make "locations" non-optional - then the interface would make a lot more sense. Heck, locations don't even need a default name - just create one default profile called "Default" and let people add extra ones - name them "Home" or "Laundromat" for all you care. That'd keep the experience consistent and understandable. Maybe?

As for the UI (on Windows):
- view menu is redundant. I get that it's keyboard-accessible, but... cluttering.
- Statistics; Disk. Why is disk even important? I only ever click "disk" out of bulk curiosity - what's this, what's that. A more generic "Stats" page would be more useful - wait, what's that, Stats is already there? Well, then, make it more generic - less about points, more about hardware info (above!), disk usage, memory consumption divided by task/process/OS, points, project WUs and graphs, etc... that tab has a lot of unused space on it ;)
- Tools menu -> "Project" menu. It's not really a menu of tools, is it? It's all about projects, account management, the act of messing with projects. "Tools" and "Options" are really too similar, I always find myself poking through both to find anything I'm looking for.
- "Read config files" needs a pairing with "Edit config files". I have absolutely zero clue where the config files exist, on neither Windows nor Linux. The UI doesn't really even make an effort of informing me of that. If there isn't a plan to make a more obvious "show me the configs!" action, then you should really just hide that button under the bigger "other options" dialog.
- worth noting again here, local control over project/computer options would be a super winner.

Hope that's at least somewhat helpful ;)