Please include an (optional) init script such as the following in a future GNU/Linux BOINC package. Also, the installer should let you choose where (like '/usr/local/bin/BOINC') and then install the program and an init script accordingliy. This would be the init script path & name for various distros:

Slackware, Slamd64: /etc/rc.d/rc.boinc
Debian, Redhat: /etc/rc.d/boinc

#!/bin/sh
# start/stop/restart BOINC

# start BOINC:
boinc_start() {

#!/bin/sh
cd /usr/local/bin/BOINC
./boinc&
#The following command should actually be set up to #allow the user to connect to projects that an #account manager cannot connect to if it is still the
#case you need to use this command separately for it.
./boinccmd
./run_manager
cd

}

# Stop BOINC:
boinc_stop() {
  killall boinc
}

case "$1" in
'start')
  boinc_start
  ;;
'stop')
  boinc_stop
  ;;
*)
  echo "usage $0 start|stop|restart"
esac

That would be useful for people that are running one computer or more just for BOINC or with a lot of extra power just for it.

It has been a while since I ran BOINC or even wrote scripts, so I do not recall if you really need boinccmd to attach to some projects a manager will not. I suppose there are always some it cannot work with. That would be a complicated part of making this script, but of course users could modify it if you give them a notice in the installation.

I do not recall if boinccmd even needs to be in the script otherwise, but one should assume people may want to use an account manager, and I think most/all need boinccmd--unless you want to do it manually in the manager.

--David

I am not talking about run_manager, but the 2 (or maybe more now) account managers that you download separately. boinc can attach to those, but then it at least used to not attach to projects the account manager did not support. I think when I attached to the project (particularly Einstein) separately with boinccmd then it worked. This would be good to have in the GNU/Linux setup.

Some distros may have packages, but Slackware, the oldest (and Slamd64) is not listed on your page. It is the only distro that has always installed correctly for me. I have used Debian and Gentoo... but no Redhat-based one or Ubunutu ever installed for me. (though I have used Redhat at school and it is nice.) I see Slackware as a standard in POSIX... many other distros can install its packages, though I think even BSD is less orderly.

Also the Berekely installer mereley installs it in your home directory instead of /usr/local/bin/BOINC if you are root, which is a mediocre installation process to put it mildly. Unarcing it is fine, but the run_manager then gets set to /root/BOINC instead of where it belongs.

See boinc-client.in in http://boinc.berkeley.edu/trac/browser/trunk/boinc/client/scripts.

The Debian and Ubuntu packages already have init.d scripts. Other distros probably do too, but I don't have personal experience with them.

---

See boinc-client.in in http://boinc.berkeley.edu/trac/browser/trunk/boinc/client/scripts.

The Debian and Ubuntu packages already have init.d scripts. Other distros probably do too, but I don't have personal experience with them.

The Fedora package should as well.

I use the one found at http://www.spy-hill.net/~myers/help/boinc/unix.html#start

---

Kathryn :o)

On Ubuntu, I'm not using the BOINC package anymore. I compiled it from source, and for startup on boot I wrote an upstart task. It was way easier than writing an init.d script! I wonder why anyone on Ubuntu still uses SysV init scripts.

service

start on runlevel [2345]
stop on runlevel [016]

chdir /home/nicolas/local/boinc
script
        su nicolas -c "./boinc --redirectio"
end script

---

I don't know of any account managers that one would download. Can you provide names of the files one would download in order to get the account managers you mention? Or perhaps a link to where one downloads them from?

I think I was wrong about that. In the last few/couple weeks I re-installed and did not have to download BAM.

I wasn't talking about run_manager either. I was talking about BOINC Manager which is the GUI[...]

I think that is what is started by run_manager, though I think I have seen the GUI start from commands run beforehand.

[quote] boinc can attach to those, but then it at least used to not attach to projects the account manager did not support. [...] This would be good to have in the GNU/Linux setup.

Boinccmd IS in the GNU/Linux setup.

I was talking about what a setup should do for boinccmd: enable it to still attach to chosen projects that an account manager does not.

Also the Berekely installer mereley installs it in your home directory instead of /usr/local/bin/BOINC if you are root, which is a mediocre installation process to put it mildly. Unarcing it is fine, but the run_manager then gets set to /root/BOINC instead of where it belongs.

I think lots of users agree that it is mediocre but there is another camp that calls it minimalist and they don't want it any other way. Both sides have their own needs, skills and expectations so neither side is right.[...]

If you want the BOINC developers to add bells 'n whistles to the Berkeley installer then you should probably submit a Trac ticket. However, the idea of making the Berkeley installer better was presented to them in the past and they nixed the idea because every distro wants/needs it installed differently. They don't have time and skills to do that so we get what we have now. I would like to see one installer that works on all distros and has all the bells and whistles but I don't think it will happen unless volunteers do it. Are you volunteering?

Besides for a simple Slackware build script (and if it was not discussed for Debian and Redhat I could explain/write those,) not presently. I had hoped if developers are capable of programming the complex program they could easily make an install script. Maybe it would take time to learn how; it would certainly take me time (at least review,) though not much: I guess I am willing to do a simple one for Slackware and Debian & Redhat, but I cannot guarantee when. It would not be a Slackpkg unless a friend of mine might advise me.

I think it is reasonable to have the installer work for 'standard' distros like Slackware (the oldest and likely simplest besides LFS) and perhaps the others I mentioned--which would cover many others--or distros set up in standard POSIX or LSB-type ways. It does not need to have something for every distro. I am willing to make something like 'Slackware_install.sh' which can be modified for others, but I could not make an entire install script that allows you to choose a distro. I could make part, but other people would have to fill in the installation commands for their distros. Maybe the dev. team could just make a directory 'install_scripts' or 'installs' so people do not have to look at a bunch of files unless they want to. However, a general installer is better: it is what programs do that run on different Windoze & Apple OSes.

If you msg me (I know not if this forum has reply notifications) I will start a Slackware or menu-based install sh-script within a few days.