I'm a user of BOINC under Windows. I'm familiar with the the separate Client and Manager components; the difference between Service mode (runs when no user is logged in) and User mode (required under Windows for GPU computing, because of driver restrictions); how to stop, pause, snooze and restart the client; and much else.

All of these apply to the Linux version of BOINC as well. I think the only significant change to what I've just said is that GPUs can be used in Service mode under Linux.

Because Windows is controlled centrally by Microsoft, there are few active versions in circulation at any one time, and it is relatively easy for the BOINC developers to manage 'one size fits all' in the Windows desktop environment. But Linux is available in multiple different flavours, and with multiple alternative desktop environments (or so I understand - I don't pretend to know the details).

For this reason, BOINC distribution has been largely delegated to the distribution managers who maintain the software installation packages. By default, these distributions of BOINC are installed in Service mode.

There is a move to make the Linux version of BOINC effectively 'Service Mode Only', and to remove certain controls which a Windows would expect to find in their user-mode interface: the ability to snooze the client from the system tray icon, for example, and to 'Shut down the connected client' (local or remote) from the main BOINC Manager menu.

I'm in regular contact with BOINC developers, but I'm not competent to debate the merits or de-merits of this particular proposal. Hence this consultation thread. Please add your comments, and perhaps indicate your particular Linux flavour, and your level of experience with it (advanced, intermediate, beginner, or refugee from Windows...)

[Previously posted on the BOINC Dev message board, but re-posting here to benefit from the wider and more active readership]

I am using BOINC 7.8.3 on a HP laptop with SuSE Leap 15.0 not in service mode, and only as a client on a Tumbleweed SuSE Linux, which is a Development version, sent to me by SuSE as an upgrade. It has a 5.0.6-1 kernel and BOINC Manager does not work on it,so I attached manually to the Einstein@home project. I have always used Linux but having bought two HP desktops with Windows installed I have kept them. On one of them I have installed a Virtual Linux, but Virtual Linux does not see the nVidia GPU board on its host, so I cannot run GPU tasks in SETI@home, Einstein@home and GPUGRID. The BOINC client is 7.14.2.
Tullio

---

I run three (four if you count a Raspberry Pi) computers using Linux.
The three I can see just now are running Mint 18.1, in user mode rather than service mode.
The impact of loosing snooze & halt would be very much down to the individual user, some would curse such a loss, others wouldn't notice, and some would miss it when needed...
I'm in the latter camp - being able to snooze is useful as there are time when I just want to snooze processing for a few minutes and being able to do it quickly and without having to remember a command line is quite useful.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

What are the benefits?

What are the benefit(s) from a Developers point of view of decreasing the "control" that a user has over being able to suspend or to pause app processing?

Does it make development easier? Does it make the processing faster?

I am running Linux on two machines. I don't use them as "daily drivers" all though I often read the Seti Website (like now) from them.

I also don't run the repository version of the BOINC manager. I run the CUDA91 "all in one" version that lives most anywhere and is basically a single user setup.

How many end users are running repository versions of BOINC?

Here is probably the crucial question. How many repository BOINC installs are running on multi-user systems? I can see a significant difference in the "production environment" of a single user Linux system and one that multiple people connect to and use.

I think I remember a "nice" command that you can run a disconnected app under that gave back cpu cycles to other users? Would the nice concept go away or does it even apply to processing under services?

---

A proud member of the OFA (Old Farts Association).

At the moment, (some) tools appear to be broken under (some distro versions of) Linux. The question is whether to fix them, or whether they were a bad idea in the first place and should be discarded. I'll leave it that: I want to listen to people's views and pass them upstream (probably next Thursday, unless public holidays intervene), without biasing the conversation in either direction.

As regards 'nice': this doesn't really apply to BOINC itself. BOINC places very few demands on the CPU, but needs to be responsive when needed. But 'nice' very much applies to the science applications - SETI and other projects - which BOINC launches. These do use the CPU heavily, and can get in the way: for that reason, BOINC automatically gives them a 'nice' setting which ensures that they yield CPU cycles to other, higher priority, applications when needed. I don't think Service or User mode makes any difference to that, and if it does, it's a bug.

For this reason, BOINC distribution has been largely delegated to the distribution managers who maintain the software installation packages. By default, these distributions of BOINC are installed in Service mode.

There is a move to make the Linux version of BOINC effectively 'Service Mode Only', and to remove certain controls which a Windows would expect to find in their user-mode interface: the ability to snooze the client from the system tray icon, for example, and to 'Shut down the connected client' (local or remote) from the main BOINC Manager menu.

Which are the most common users of Linux/Seti?

I am not sure but I wonder if the Pi ARM are the most common. If so, they mainly use a version of Linux specific to their hardware? Is the Rasberean release included in this conversation?

I suspect the NEXT most common users of Linux here are not running any of the repository versions of the BOINC Manager.
So I think this would impact the current Seti users minimally in terms of control because most don't use the repository BOINC Manager.

So am back to the question of "user friendliness"? Will this make the repository BOINC Manager easier to use?
Or would it keep more Windows users away from it?

As for the "broken tools" issue you really have two useful choices. 1) Fix a tool 2) Stop publishing it/making it available.

Tom

---

A proud member of the OFA (Old Farts Association).

I run Linux under Ubuntu. The Boinc manager I use is from TBar. I like it as I can put it where I want and can modify things as I see fit.

Linux isn’t a friendly environment. Takes a lot of time to get used to and not for just anyone. If you’ve gotten that far installing it, you’ve probably got a good knowledge about computers.

So the question becomes why would the developers want to hamstring advance users? I’m saying if you got that far, it would really suck to find the Boinc manager isn’t going to cooperate with you. Why I went with TBars version

My 2 cents

Z

---

I have a fleet of 10 machines all running Debian and the repo version of BOINC (currently 7.10.2 from Stretch backports). I also have about 16 Raspberry Pis. They run a customised version of Debian Stretch known as Raspbian. The Pi’s run headless. All machines are dedicated crunchers.

I have used the manager to shut down the running client a few times in the past but I could live without it. I usually shut the service down using the service command if I have a need. Most command and control stuff I do via BOINCtasks on a Win7 laptop that is my daily driver.

---

BOINC blog

I think Tom's comment about repo vs "other", in the context of BOINC needs to be explored a bit more.
There are basically two "preferred" locations under Linux.
- The first, and the oldest, is in var/lib, which makes the application available to all users with only minimal ownership or access changes.
- The second is to place the application in the user's own "home" structure, OK on single user system, but not so easy on systems that are potentially multi user where there are all sorts of access and security ramifications for other users.

Neither of these is a "service" installation in the way that Windows does services, which is more akin to a kernel module application, which has to be bound to the kernel - which might be "nice" from a programmers point of view, with its quicker access to the system hardware, but may cause users a few headaches when performing administration tasks on something like BOINC - I guess that's why the developers want to get rid of things like suspend (GPU), suspend (all), etc., they probably aren't as easy to code as they are under Windows....

There are two major strands of Linux RPM & Debian, and each of those has a number of branches (which may in turn have sub-branches), and, in general, the further from the main branch one gets the more likely one is to have "problems". That said some of the major sub-branches are "frilly wrappers", or different sets of apps and tools, or for specific hardware, which are "something of nothing" variations. But some have "tinkered" kernels and that can cause issues. (It's a bit of an education to look at the (incomplete) list of Linux distros on Wikipedia (https://en.wikipedia.org/wiki/List_of_Linux_distributions)

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

I have reduced My machines down to Four. Of those Four, Two are on the first page of the Top Computer List. I detest any App that starts when My computer starts, Especially one that has taken steps to make it difficult to Turn Off. The First thing I do with a fresh install on My Mac is to Disable AutoStart. I think if they made it difficult to Disable AutoStart, I would be forced to Build My Own Version that could easily be turned Off. Personally, I think it is a Very Bad Idea to try and take control of a Linux Users machine. Most Linux Users I know dislike some company trying to take control of their machines, some even tell such companies where to place their software. Of course, I'm one of those types.

Greetings,

I have one Linux box running Linux Mint v19.1 Tessa and 3 Raspberry Pis running Raspbian Stretch (I think). I seldom access my Pis and when I do I use the service command to shut down BOINC. I use the BOINC Manager on my Linux box to control BOINC.

Since I am relatively new to running BOINC on Linux I really have nothing more to add to this. I will just deal with the machines as I always do. If anything new comes from this, then I will muddle through to learn. :)

Have a great day! :)

Siran

---

CAPT Siran d'Vel'nahr - L L & P _\\//
Winders 11 OS? "What a piece of junk!" - L. Skywalker
"Logic is the cement of our civilization with which we ascend from chaos using reason as our guide." - T'Plana-hath

I have 5 Ubuntu Linux hosts running in user mode via a /home installation. They all have the Manager running on them but I only normally interact with the Manager on my daily driver. I have one new Raspberry Pi running headless in service mode that I occasionally view remotely. All hosts can be controlled via BoincTasks running on the daily driver. I'm with TBar in that I detest any program starting automatically on its own that I don't have any control over. One of the positive benefits of moving to Linux is regaining control over my PC's. I want to keep the ability to change how I interact with BOINC on my own terms.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I detest any App that starts when My computer starts, Especially one that has taken steps to make it difficult to Turn Off. The First thing I do with a fresh install on My Mac is to Disable AutoStart.

I think that might be an important point. What exactly do you dislike about autostart?

I think I've seen posts over the years, relating to specifically GPU computing, that suggested that GPU drivers may fail to load (and hence GPU detection fails, even before we get to GPU computing), until they are woken up by the X-server. And I also remember posts about how to re-order the boot sequence, so that BOINC starts much later, after these pre-requisite services have loaded. Can anybody confirm or correct my memory?

As part of this exercise, I've also refreshed my memory of how Windows Service Mode operates. I used to run all my Windows XP machines in service mode, but as they've gradually failed and been replaced by Windows 7, I've had to switch to User mode, to access the GPU drivers. But I have a new Windows 10 1809 machine available. so I installed the service. All Manager functions worked as I remember and expected, but I reminded myself of one timing problem: BOINC needed to contact some project or other as soon as it started. But the WiFi network connection hadn't initialised that early in the boot sequence, so the network RPC failed (although I believe secure WiFi login can occur before user login. I still need to check that). In the meantime, I'll be setting the Windows service mode to 'Automatic - delayed start' for BOINC - does Linux have any equivalent to that?

@ Rob: I think the BOINC service (repo) installation has more in common with Windows services than you describe. The file placement in shared system storage space, rather than the user filing area, is significant (of course): but in my discussion with the developer that started this enquiry off, I was told that if users were allowed to stop the Linux service, something in the system would have to issue a command like

sudo systemctl restart boinc-client

Normally, that's a terminal script, but in principal the Manager could issue it - but then, how would sudo's password prompt be handled? In my Windows 10 test, I found that I needed to process a UAC prompt every time I used BOINC Manager to re-start the service, but not when I connected to a running client.

I have 5 Ubuntu Linux hosts running in user mode via a /home installation. They all have the Manager running on them but I only normally interact with the Manager on my daily driver. I have one new Raspberry Pi running headless in service mode that I occasionally view remotely. All hosts can be controlled via BoincTasks running on the daily driver. I'm with TBar in that I detest any program starting automatically on its own that I don't have any control over. One of the positive benefits of moving to Linux is regaining control over my PC's. I want to keep the ability to change how I interact with BOINC on my own terms.

+1

I agree with TBar and Keith. I want to make sure everything booted up correctly before I fire up BOINC. If my Nvidia drivers didn't come up, I could (and have) had a ton of SETI jobs error out because no GPU as one example of why.

---

I have 5 Ubuntu Linux hosts running in user mode via a /home installation. They all have the Manager running on them but I only normally interact with the Manager on my daily driver. I have one new Raspberry Pi running headless in service mode that I occasionally view remotely. All hosts can be controlled via BoincTasks running on the daily driver. I'm with TBar in that I detest any program starting automatically on its own that I don't have any control over. One of the positive benefits of moving to Linux is regaining control over my PC's. I want to keep the ability to change how I interact with BOINC on my own terms.

+1

I agree with TBar and Keith. I want to make sure everything booted up correctly before I fire up BOINC. If my Nvidia drivers didn't come up, I could (and have) had a ton of SETI jobs error out because no GPU as one example of why.

+1

With Linux we recovered the control of our machine loosed when we change from DOS to Windows.

---

sudo systemctl restart boinc-client

Normally, that's a terminal script, but in principal the Manager could issue it - but then, how would sudo's password prompt be handled? In my Windows 10 test, I found that I needed to process a UAC prompt every time I used BOINC Manager to re-start the service, but not when I connected to a running client.

I'm told there's a "visual sudo" system in 'every' (!?) distribution.

sudo systemctl restart boinc-client

Normally, that's a terminal script, but in principal the Manager could issue it - but then, how would sudo's password prompt be handled? In my Windows 10 test, I found that I needed to process a UAC prompt every time I used BOINC Manager to re-start the service, but not when I connected to a running client.

I'm told there's a "visual sudo" system in 'every' (!?) distribution.

I'm not aware of any "visual sudo" There used to be a gksudo command that enabled graphical applications with admin privileges but that was dropped in the distros after 18.04. Nothing similar anymore on modern distros.

I don't want BOINC to start automatically because I want to make sure the graphics drivers are loaded OK. Also I might want to do some system maintenance or configuration changes after rebooting since I probably was changing things in the BIOS. So I would have to stop BOINC anyway right at the beginning to test things out that I am playing around with. Stopping BOINC is an unnecessary step if I just stop and start it on my own terms and schedules.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I don't want BOINC to start automatically because I want to make sure the graphics drivers are loaded OK.

Where as for me running Windows, Auto-starting is best- such programmes don't start till after the underlying OS & drivers have started running. If i'm going to do some system fiddling that may affect Seti, I disable the auto start till I've finished fiddling, then re-enable it.
Even with Windows, to auto start or not is user selectable when installing BOINC, and at any time afterwards.

---

Grant
Darwin NT

There is a move to make the Linux version of BOINC effectively 'Service Mode Only', and to remove certain controls which a Windows would expect to find in their user-mode interface: the ability to snooze the client from the system tray icon, for example, and to 'Shut down the connected client' (local or remote) from the main BOINC Manager menu.

I think the BOINC developers need to decide what their main goal is.

If it's just to offer BOINC for LINUX, then cutting back of the options would make development much easier and letting the users compile their own or use scripts to do what they want to do would be the way to go.
If it's for the widest possible adoption of BOINC, then they would need to keep all the present operator options & User/Service installation options. For those coming from Windows it would make the transition easier, for those new to computing & beginning with LINUX it would help them also. For those that don't want Auto start or such functions, allow them the switches to make that possible.

Given how fractious LINUX (and it's user base) is, whatever you do a lot of people won't be happy. Your best bet is do what allows the BOINC development team to reach their goals & objectives. If that's to make BOINC used as widely as possible then keep (as much as possible) functional parity between Operating Systems, but allow the minimalist crowd to do their thing as well.

---

Grant
Darwin NT

Debian "stretch" release 9.8.0, repository boinc client/manager 7.6.33 in user mode.
I've compiled a custom Linux kernel and I'm running the cuda91 app, so I guess that puts me in the "advanced" Linux user group.

I find it useful to be able to suspend activities (GPU, Network) as well as to set "no new tasks" and to suspend individual projects in a multi-project context. I'm also running two concurrent instances of boinc - a complicated story, but one manages two projects that are CPU only and runs with time-schedule preferences to run only at night; and the other (24/7) runs Seti and Einstein mixed CPU & GPU tasks. Would that be possible in "service mode?" Twice in the past 6 months I have needed to recover "ghost" tasks. That involves some rather direct boinc-manager operations that I infer would not be possible in "service mode." ( Yes, I know that boinc (eventually) errors-out those tasks and no real harm is done, but I personally hate to leave those wing persons hanging in the wind - and racking up my error count unnecessesarily.)
Some configuration changes require a restart of boinc and with the current boinc-manager controls that can be done in a smooth and orderly fashion.

Those are my thoughts on the subject.

---