I saw something recently that many many programs ignore, including the boinc software. The FHS recommend splitting programs from data. I'd suggest, as explained below, that now might be a good time to adopt this standard.

One intention of the FHS is to separate programs from data. Thus the program would be installed in /usr/local/bin/, but when it ran it would put its data in /var/local/. See http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY

So if boinc were fully compliant, the program would go into /usr/local/bin/BOINC. The important point is that the /usr/... files should be able to be read only at run time.

Then all the writable stuff, the xml files and the writable subdirectories go into /var/local/ (yes, always into /var/local/, even if the program went into /usr/local/bin).

Motivation

This means that upgrading the program becomes simple so long as data formats do not change.

This means that backups of data do not contain backups of the program.


Comment

The separation of program and data used to be commonplace in the days when disks had a write-protect switch on the outside. We'd usually run with a 'system disk' that was read only, and a 'data disk' that was read-write.

The introduction of the IBM PC with at most a single hard drive caused programmers to forget that old good practice. This is a pity, as with a write protected system disk containing the programs it is a lot harder for a virus to get established.

BOINC

Like most packages written with a PC in mind, the separation of program and data was ignored during development.

Now (wait for it, I am going to say something nice about them) Microsoft have re-introduced the idea of program and data separation in Vista. I read somewhere recently that the boinc devs are therefore going to separate the program from the data. Of course in the case of BOINC, the project program needs to be counted as 'data', as it is downloaded dynamically - so just the BOINC client and interfaces (boinc_cmd and the manager if required) will be in the program space.

If this is true, then I'd suggest that at the ame time it would be good to separate the linux files between /usr/local/(share/)BOINC and /var/local/BOINC and set up separate envronment variables that point to each directory. Then folk with the current sceme would simply set both variables to the same point. Folk wanting to keep to the letter of the FHS could separate them.

Clearly there is more work here than would be worth doing to comply with the most overlooked standard in the Linux world. However, if the splitting up has to be done to keep windows installers happy, then very little extra work would be needed to do the same for Linux at the same time.


And it will be a lot less work to do it at the same time now than to do Windows now and leave Linux till sme future event forces it upon us. It is just possible that one day the FHS will start to be taken seriously... tho I am not holding my breath on that one ;-)


River~~

PS

Of course, if you *really* want to do the split properly, then the user editable config files go into a third place, /etc/BOINC/...


edit added link, added PS, removed some incorrect info re /usr/local/share

---

I didn't read all your message carefully, but I want to point out this would also solve our problems with Windows Vista, where BOINC is not able to write its data on Program Files.

The Ubuntu boinc-client package (which I guess may apply to other Debian distros but I'm no expert on this), gets fairly close to this.

It puts the programs in /usr/bin, the data in /var/lib/boinc-client and the config files in /etc/boinc-client with symbolic links to /var/lib/boinc-client.

---

I didn't read all your message carefully, but I want to point out this would also solve our problems with Windows Vista, where BOINC is not able to write its data on Program Files.

Thanks Nicolas - that is exactly what I am trying to say. While the devs are putting in the work to clean up for Vista, with an extra 10% they can get it standards-conforming on Linux too.

R~~