Opinions requested from home Linux users

Message boards : Number crunching : Opinions requested from home Linux users
Message board moderation

To post messages, you must log in.

Previous · 1 · 2 · 3

AuthorMessage
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1989999 - Posted: 14 Apr 2019, 9:25:22 UTC - in response to Message 1989988.  

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.
ID: 1989999 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1990002 - Posted: 14 Apr 2019, 9:29:08 UTC - in response to Message 1989991.  

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.
ID: 1990002 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1990003 - Posted: 14 Apr 2019, 9:30:42 UTC - in response to Message 1990002.  

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.
ID: 1990003 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14649
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1990006 - Posted: 14 Apr 2019, 10:48:30 UTC - in response to Message 1990002.  
Last modified: 14 Apr 2019, 10:53:12 UTC

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.
ID: 1990006 · Report as offensive
Profile Brent Norman Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 1 Dec 99
Posts: 2786
Credit: 685,657,289
RAC: 835
Canada
Message 1990015 - Posted: 14 Apr 2019, 13:07:39 UTC - in response to Message 1990006.  
Last modified: 14 Apr 2019, 13:10:10 UTC

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.
ID: 1990015 · Report as offensive
Profile Keith Myers Special Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 29 Apr 01
Posts: 13161
Credit: 1,160,866,277
RAC: 1,873
United States
Message 1990032 - Posted: 14 Apr 2019, 16:04:19 UTC - in response to Message 1989990.  

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)
ID: 1990032 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14649
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1990036 - Posted: 14 Apr 2019, 16:27:19 UTC - in response to Message 1990032.  

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.
ID: 1990036 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1990043 - Posted: 14 Apr 2019, 18:22:19 UTC - in response to Message 1990006.  


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.
ID: 1990043 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1990044 - Posted: 14 Apr 2019, 18:31:17 UTC - in response to Message 1990006.  


- 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.
ID: 1990044 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1990045 - Posted: 14 Apr 2019, 18:39:48 UTC - in response to Message 1990036.  

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.
ID: 1990045 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14649
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1990046 - Posted: 14 Apr 2019, 18:44:49 UTC - in response to Message 1990043.  

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.
ID: 1990046 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1990107 - Posted: 15 Apr 2019, 4:12:09 UTC - in response to Message 1990046.  


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.
ID: 1990107 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14649
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1990499 - Posted: 18 Apr 2019, 13:20:51 UTC

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.
ID: 1990499 · Report as offensive
Previous · 1 · 2 · 3

Message boards : Number crunching : Opinions requested from home Linux users


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.