New guy with a question.

The 8.* version was released by Set1@Home in April 2016 and should be available from there. I found the rather cryptic advice to get it "From the project, Attach your Arm device to Setiathome as you would any other computer." at

Depends what format it in. If its a .deb file, install as a normal package. If its an executable, put it in /usr/local/bin because thats the recommended place to put all executables that aren't part of packages and put configuration files, etc where the installation documentation says they should, except for anything that should go in /etc - try putting this in /usr/local/etc first and only move it to /etc of seti@home can't find it there.

The advantage of putting your own and 3rd party programs, config files etc. in the /usr/local/* directory tree is that they won't get accidentally clobbered by normal updates and upgrades, which is always a possibility for files and executables plonked into /bin, /usr/bin and /etc but are still easily accessable because /usr/local/bin and /usr/local/sbin should be included in $PATH by default and all properly written programs should search for configuration files etc. by looking in

.:/usr/local/bin:/usr/bin

in that order.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

Should, of course, have been

.:/usr/local/etc:/etc

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

Point of order: it's generally not a good idea to have '.' on your path, because then you risk your system tools being clobbered by ones in the current directory. For instance, you download a tarball, unpack, cd into it and type 'ls'. If the tarball contains a malicious program called 'ls' then you've just executed it.

Prefix program names with './' if you want to run ones in the current directory.

Theo

Agreed - if its at the front of the $PATH list. OTOH I see nothing wrong with *appending* :~/bin:. to $PATH. Been doing it for years with no bad effects.

Yes, if you're using sudo execution, because $PATH as defined in your user profile is pushed aside in the sudo environment.

However, you probably saw my later correction and now know that I meant to write ".:/usr/local/etc:/etc" because I was talking about my preferred search order when looking for configuration files.

The reason for this preference is because it allows a site configuration in /usr/local/etc to override a default configuration in /etc while allowing any site-specific configuration to be overridden by a locally declared one in the current directory. This can be very useful during program development because it lets the special testing configuration(s) override the normal configuration.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

The risk here is from typos.

Testing is normally done by specifying an alternative configuration via a command-line argument or an environment variable.

For production uses, /etc is not there to provide defaults; it is there to provide the live configuration.

--
http://www.greenend.org.uk/rjk/

Command-line override is always an additional nice to have.

Depends. I'd agree for anything out of a standard package, but for anything from a third party source or locally developed, I think /etc/ local/etc is a better place for its configuration. For one thing, if /usr/local is a symlink pointing to, say, /home/local then provided that /home is in a partition that's not reformatted during a clean system reinstall, there's no danger of the reinstall clobbering third party softare configurations.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

Frustrating. Lots of information seemingly about how to make it work better, but nothing that tells you how to get it.

FYI, the only thing I've seen that's even close it is to issue a sudo apt-get update boinc-client boinc-manager which tells me every things current and nothing was done. Still got version 7* there so S@H still won't give me tasks.

I've got some other stuff in the mail, part of which is a new SD cards with Raspbian for a 3B pre-installed. I'll dd it and then lay that over the current installation and start from scratch. Who knows, it might work (not holding my breath though).

Why do you feel you need BOINC v8? BOINC v7.4.23 and the projects below all run okay on my Pi 3's.

--
If you're not part of the solution, you're part of the precipitate.

One of the posts on the the Seti@Home site page announcing 8.1 for RPI said something like "Connect to the site and download it as usual", which implies that more complete instructions should be somewhere on that site.

Looking for the boinc manpage might be a good idea.

Its a very long time since I gave up on running Seti@home (when I replaced my old Pentium 4 home server with a Dual Athlon box). I was happy to share unused cycles on a fixed frequency chip, less so when boinc caused the Athlon to run flat out with a howling fan for 24/7: that's scarcely unused cycles or wasted electricity.

I might consider doing it again on an RPi except that back in the day some boinc clients were greedy and refused to run on the P4, claiming it was too slow to bother with.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

Oh? All I did was install boinc-client and then run

boinccmd --project_attach

(key)

and that was that. After a few minutes /var/lib/boinc-client/stdoutdae.txt showed:

15-Feb-2017 14:58:19 [SETI@home] Scheduler request completed: got 4 new tasks 15-Feb-2017 14:58:21 [SETI@home] Started download of setiathome_8.02_arm-unknown-linux-gnueabihf 15-Feb-2017 14:58:38 [SETI@home] Finished download of setiathome_8.02_arm-unknown-linux-gnueabihf 15-Feb-2017 14:58:38 [SETI@home] Starting task 28mr08ah.1771.25021.11.38.67_1 15-Feb-2017 14:58:38 [SETI@home] Starting task 28mr08ah.1771.25021.11.38.73_0 15-Feb-2017 14:58:38 [SETI@home] Starting task 28mr08ah.1771.25021.11.38.79_0 15-Feb-2017 14:58:38 [SETI@home] Starting task 28mr08ah.1771.25021.11.38.85_0

I'm wondering if it has to do with the fact that I joined the SETI project in 1999.

In any event I've decided to run: Einstein@Home been running this since SIMAP went away. Evolution@Home if I can figure out how to get to it. Go through yoyo and specify that I want to run only Evolution? Find@Home which I already have joined. SETI Beta once I figure out what the old SETI has in it so I can rejoin? Universe@Home new one, haven't tried to get to it yet.

Listed in alphabetical order, not by preference.

On 5 Intel machines I'm running Rosetta and World Community Grid. Four Pi3B's running all the stuff above when I get it figured out.

blather...blather...

OK, here's how the one Pi is running...

1. Einstein working.
2. Evolution seems to be working, no data yet, and I did have to go to yoyo and specify I only wanted this work.
3. Find seems to be OK, has no data as yet though, but the site indicates that's the way things are.
4. Universe working.
5. Seti is processing data. Which tells me I had to join the beta project. I totally messed around with this so I'm not sure if I need the original Seti or not. As someone said...I checked the preferences on the Seti site and it is set to V8.

I'll hopefully know more by weeks end, and I get the other 3 running, if anybody wants to know.

A big thanks to all for the support.

You would have to do a typo which happens to turn into a program which can cause you some harm, which strikes me as very unlikely.

I've had '.' at the end of my PATH for dozens of years and that hasn't happened to me yet. But I have save lots of time over the years by not typing "./". YMMV.

Cheers.

Jim

Perhaps not that unlikely, since a good strategy for malware authors might be to pick a common typing error as the name of their program.

--
Cheers, 
John

See also "Midnight Commander" (mc) and why I uninstall it from any system that includes it.

Elijah

------ ld is useful, even if also typed accidentally

The big differences here are appending them (so an intruder cannot stuff in eg. a new ls) and using ~/bin, not ~/ . A local /bin is a place where you put executables you are in good control of, not some random stuff in your ~/ . And don't do this as root, but as a normal user, and I would think you would be pretty safe.

At least some orders of magnitude better than some known office packages that automatically executes incoming emails.

I concur with both of you, and you are not in such disagreement.

/etc is the global, live configuration of the machine. Updated via repositories.

/usr/local/etc is for the development and local specialities, to be updated manually. This is for where the local installation deviates from what comes with the repositories.

~/etc is for the personal stuff, eg. a newer version, or one specially built from sources.

-- mrr