AFAIK it doesn't require any service restart or does?

Boinccmd (uses GUI RPC network protocol) is fine for the bench test - no restart. My installer did need to stop and restart so that BOINC could recognise the changed files.

Well,instaler is quite another case, I demonstrate possibility of snooze w/o any service restarts so not quite understand why sudo is needed for snooze and why snooze so troublesome to drop it for Linux....

Both service-mode and user-mode installs have own advantages so better to keep them both. Unfortunately, under Windows service install has show-stopper limitations for any GPU usage - that biggest challenge - to hack windoze new desktop-handling model... NV has appropriate drivers but restricts them toTesla-class devices only (that is, hacking needed too to use them with user-class devices )

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Or is 'sudo' well enough known even by Windows users like me that it isn't a problem?

On real *nix system, not pet-OS for home PC sudo IS show-stopper cause ordinary user can't do it and hardly any admin will add boinc to sudo list.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Or is 'sudo' well enough known even by Windows users like me that it isn't a problem?

On real *nix system, not pet-OS for home PC sudo IS show-stopper cause ordinary user can't do it and hardly any admin will add boinc to sudo list.

EDIT: so, for _users_ (no root access, no boinc in sudo list for particular user) is vital to have user-mode only version of BOINC.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Or is 'sudo' well enough known even by Windows users like me that it isn't a problem?

On real *nix system, not pet-OS for home PC sudo IS show-stopper cause ordinary user can't do it and hardly any admin will add boinc to sudo list.

Thanks, that's helpful. Gary Roberts has also pointed me to ITMOTB on SUDO, which I'm still getting my head round.

I think the proposal which led to this discussion came from the Debian stable, which I think counts as "real *nix"? The originator's actual words are:

by default on Linux BOINC runs as a service, the GUI must not stop it.

(my emphasis). He seems to be envisaging a situation where an individual using the computer has access to BOINC Manager and can use the tools therein, but doesn't have access to any tool (whether root or sudo) which can restart the service once stopped.

We don't know what any such user might be using the computer for - though I suspect running Lunatics bench tests isn't on the list. We do know from discussions here some reasons why a user might wish to stop or snooze BOINC (and I'll come back to the distinction later)

- passive video display (watching a film, without mouse or keyboard activity)
- active video, such as gaming
- thermal control, including reducing noise from the cooling system
- foreground computing tasks requiring fullest resource utilisation

Most of these can be managed automatically by preference settings such as 'suspend while computer is in use' and '[don't] leave tasks in memory while suspended' - which a user with full GUI access can fiddle with. They also have access to daily schedules, so they can set 'BOINC all night, but not when I'm working' or similar.

They can also suspend all projects indefinitely, without limit of time - which might be almost as bad as stopping the service. In the benchtest case, we do effectively suspend BOINC indefinitely, but then we actively turn it back on at the end of the test. If our hypothetical user has access to boinccmd (that isn't clear to me), they can similarly suspend boinc and resume it. And they can also stop the service with --quit, so I suspect the Debian proposer may wish to remove that too.

The 'snooze' action is distinctively different, because it sets a 60 minute timer: BOINC restarts even if the user has left the building. And it's relevant here, because the same Debian developer has also proposed "Disable BOINC Manager system tray icon on Linux platforms". And 'snooze' can only be invoked from the system tray icon.

There are other problems with the system tray interface, because apparently some *nix desktop inplementations can't display them, but that's a different question.

We don't know what any such user might be using the computer for - though I suspect running Lunatics bench tests isn't on the list. We do know from discussions here some reasons why a user might wish to stop or snooze BOINC (and I'll come back to the distinction later)

Two more for the list. They shouldn't be on it, but people will always complain that they can't use a computer they have no admin right to (or likely authorized to) use for BOINC.
- Work users that want's to suspend BOINC for intensive work loads
- Work users that are using company servers for BOINC use.

Just examples, I'm not singling you out Raistmer.

On real *nix system, not pet-OS for home PC sudo IS show-stopper cause ordinary user can't do it and hardly any admin will add boinc to sudo list.

EDIT: so, for _users_ (no root access, no boinc in sudo list for particular user) is vital to have user-mode only version of BOINC.

A work desktop user isn't really a big deal in my point of view. Since if BOINC was started as a service and stopped via the GUI for a period of time, a simple reboot would restore normal operation.

Work servers are different in that I'm sure the user wouldn't want to be rebooting the company mail, file, etc servers out of the blue - might get them fired!

In the 'home user' context, they know the sudo password because they own the computer and have full access to do what they please. Work user won't and shouldn't without authorization.

I still think that including a script in the install package to add a user to the BOINC group is the best way. Then the GUI should be able to restart boinc. That would require admin rights, and rightfully so. If you can't do that, you should be asking the boss if you should be running it in the first place.

---

Can we nail whether this is happening with the distro repository installations, please? That's my concern in this thread, and a question I can't answer for myself. I have read about libcurl4 uninstalling libcurl3, about libcurl4 and libcurl3 (separate installs) not being able to run together on the same system, and about the existence of libcurl34 for (or is that 43?) which combines both.

But have the package managers cracked all that?

All of the distro supplied BOINC packages run without the user needing to do anything with libcurl. Since the distro's BOINC package are compiled on their target host systems, all the dependencies are already satisfied.

The only reason the discussions about libcurl3 and libcurl4 come up are because of TBar's older All-in-One packages which were compiled on earlier distros compared to the current distros most people are likely running. Libcurl3 was available up until the Ubuntu 18.04 distro and dropped for the later distros in favor of libcurl4. The curl34 ppa package is very limited in that it covers only the Ubuntu bionic and cosmic releases. So not available to any other debian distro. There is a lot of dissension and controversy regarding libcurl in the developer forums and two camps of thought. One camp thinks libcurl3 and libcurl4 should be able to coexist and the other camp think that libcurl3 should be deprecated as it already has. There are apparently a LOT of older legacy applications that are still perfectly functional and in popular use that depend on libcurl3.

---

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

A proud member of the OFA (Old Farts Association)

The only reason the discussions about libcurl3 and libcurl4 come up are ...

OK, that's fine, and needn't concern us further. This thread is about the distro package releases, and whether their world-view should define BOINC for everyone. My initial feeling was that the controls they want to remove should not be removed globally, but only from the distros that the package maintainers are directly responsible for - and that feeling has been strengthened as the conversation has progressed. So I'll be arguing that the menu entries should be restored to the master code repositories (and thus to future branches based on that), and that distro managers should be enabled to set their own flags to enable them to compile different builds with alternate UI features.

I think the proposal which led to this discussion came from the Debian stable, which I think counts as "real *nix"? The originator's actual words are:

by default on Linux BOINC runs as a service, the GUI must not stop it.

(my emphasis). He seems to be envisaging a situation where an individual using the computer has access to BOINC Manager and can use the tools therein, but doesn't have access to any tool (whether root or sudo) which can restart the service once stopped.

We don't know what any such user might be using the computer for - though I suspect running Lunatics bench tests isn't on the list. We do know from discussions here some reasons why a user might wish to stop or snooze BOINC (and I'll come back to the distinction later)

Well, by "real Unix(Unix-like so *nix) I meant multi-user system (mainframe or such) as opposite to single user home PC, different Linux distros can play such role. And for such system one should consider (IMHO) 2 different scenarios.
1) Service install (made by administrator with root access). In this case users shouldn't even see BOINC. At all. It's just NOT their business.
2) User wants to run BOINC under own account. In this case BOINC just another user app and of course user running it SHOULD have access to all app features, snoozing and stopping/starting for famous Lunatics benchmarks also ;)
In cited phrase I see mix of those 2 _different_scenarios. Better not to mix them, they ARE different ones.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

- passive video display (watching a film, without mouse or keyboard activity)
- active video, such as gaming
- thermal control, including reducing noise from the cooling system
- foreground computing tasks requiring fullest resource utilisation

Most of these can be managed automatically by preference settings such as 'suspend while computer is in use' and '[don't] leave tasks in memory while suspended' - which a user with full GUI access can fiddle with. They also have access to daily schedules, so they can set 'BOINC all night, but not when I'm working' or similar.

They can also suspend all projects indefinitely, without limit of time - which might be almost as bad as stopping the service. In the benchtest case, we do effectively suspend BOINC indefinitely, but then we actively turn it back on at the end of the test. If our hypothetical user has access to boinccmd (that isn't clear to me), they can similarly suspend boinc and resume it. And they can also stop the service with --quit, so I suspect the Debian proposer may wish to remove that too.

The 'snooze' action is distinctively different, because it sets a 60 minute timer: BOINC restarts even if the user has left the building. And it's relevant here, because the same Debian developer has also proposed "Disable BOINC Manager system tray icon on Linux platforms". And 'snooze' can only be invoked from the system tray icon.

There are other problems with the system tray interface, because apparently some *nix desktop inplementations can't display them, but that's a different question.

Well, most of those activities are about single-user "home" PCs. Where "user" and "admin" is the same physical person. For such "service" install just choice it can be "user" install also. And on such system what "service" advantages? Why install it as such at all?

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

The only reason the discussions about libcurl3 and libcurl4 come up are ...

OK, that's fine, and needn't concern us further. This thread is about the distro package releases, and whether their world-view should define BOINC for everyone. My initial feeling was that the controls they want to remove should not be removed globally, but only from the distros that the package maintainers are directly responsible for - and that feeling has been strengthened as the conversation has progressed. So I'll be arguing that the menu entries should be restored to the master code repositories (and thus to future branches based on that), and that distro managers should be enabled to set their own flags to enable them to compile different builds with alternate UI features.

++, Richard, that would be right move IMHO. The one thing is "distro" flavour and quite another lack of possibility in sources - better to avoid such at all cost to simplify life and to reduce possibility of BOINC fragmentation at source code level.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

In cited phrase I see mix of those 2 _different_scenarios. Better not to mix them, they ARE different ones.

I've been thinking about that - for client installation by a corporate administrator in service mode, without user control - why install the Manager at all? it won't be needed for the service to run.

But I have come up with one possible use case. One of the developers I have to convince - in fact, somebody who had a role in the proposed change - is a father with young children, who works as an administrator in one of the big projects. I can imagine a BOINC service being installed on his work laptop - and that laptop having a second life at home, perhaps occasionally playing Peppa Pig while the children are very young, and helping them with their homework when they are a little older. That would merit the administrator/user distinction, but the owner/administrator would still require total control.

But I have come up with one possible use case. One of the developers I have to convince - in fact, somebody who had a role in the proposed change - is a father with young children, who works as an administrator in one of the big projects. I can imagine a BOINC service being installed on his work laptop - and that laptop having a second life at home, perhaps occasionally playing Peppa Pig while the children are very young, and helping them with their homework when they are a little older. That would merit the administrator/user distinction, but the owner/administrator would still require total control.

If he wants to share PC then run BOINC in "user"mode underown account and create separate one for children, for example. Or install it as service - no big difference as long as children do smth else onPC.
Only if generalized PeppaPig requires BOINC snooze for playing problems occur. But in this case (users allowed to snooze admin-installed BOINC) controls to snooze it should be available for service-install mode... just opposite of change in discussion.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

We've just finished the developer conference call, and we reached a consensus that the proposal to remove the menu items from Linux will be shelved for now - the menus remain unchanged for general users. It's possible that they might still be removed from the service installs made from repository distributions, but that would be selective and wouldn't impact home users building from source.

Later, we'll try to find time to investigate the whole Linux situation - User / Service modes, and starting / stopping the client in each mode - in more depth. Your comments here will be most useful, but in the meantime, please considered the first phase of this consultation closed. Thanks for your input.