Seems NOT to work . . . I've tried just about everything I can think of, however, despite running the project exclusively on OS X (Unix) you CAN NOT ATTACH TO A REMOTE BOINC CLIENT and manage it from a remote computer. I would have ASSUMED it would use the standard Unix permissions and accounts, etc, yet all I've found are references to a "configuration file" that is in an as yet undisclosed location, that contains some contents whose format has yet to be specified by anyone, and whose exact utility is unknown.

Now, given ALL the standard methods for connecting from one Unix host to the next, I would have ASSUMED that this would be fairly straightforward . . . however, it is FAR from it, further there is NO documentation on the subject as that ENTIRE area in Wiki for the program is BLANK. As in NOT FILLED IN.

If you're going to use Wikipedia as a documentation source (not a bright move to begin with), you should at LEAST insure that the documentation posted there is complete. Hitting the "OS X Instructions" link, for instance, takes you to an EDIT URL instead of a view URL, and other basic mistakes. Not to mention the omission of the important "managing remote computers" part. Particularly since I rely on remote admin to access machines I can't physically get at.

Can ANYONE who's managed to get remote administration on the Mac working either followup to this or eMail me at caligula@pbth.com, so maybe I can get MORE than my primary workstation on this. I have a lab FULL of computers, but don't have physical access to most of them due to a combination of disability and a really REALLY messy lab.

Getting remote administration working is the ONLY thing that will get those machines connected to projects and working. I can get someone to INSTALL the software on those machines, but I don't want to go to the hassle of having to describe action by action the myriad steps involved in connection to each individual project.

---

there is NO documentation on the subject as that ENTIRE area in Wiki for the program is BLANK. As in NOT FILLED IN.

The info in the Wiki, what there is of it, is here.

If you're going to use Wikipedia as a documentation source (not a bright move to begin with), you should at LEAST insure that the documentation posted there is complete. Hitting the "OS X Instructions" link, for instance, takes you to an EDIT URL instead of a view URL, and other basic mistakes. Not to mention the omission of the important "managing remote computers" part. Particularly since I rely on remote admin to access machines I can't physically get at.

You have the misconception that UCB uses Wiki for documentation. Nope. The only documentation UCB provides is what you can find on _this_ site. (In other words, just about none.) The Wiki is a VOLUNTEER effort to provide decent documentation. The fact that one part is "blank" simply means that nobody has volunteered to fill it in yet. Perhaps when you get this working, you can write it up, email it to Paul, and it will be added.

Getting remote administration working is the ONLY thing that will get those machines connected to projects and working. I can get someone to INSTALL the software on those machines, but I don't want to go to the hassle of having to describe action by action the myriad steps involved in connection to each individual project.

How about this. I will pretend that instead of complaining about the documentation on "problem A", you instead came in and said "Hi, I have a lab of OS X machines, and I would like to make it such that I can hand a CD to someone and they can install BOINC and attach to these 'n' projects, without having to do any more than necessary. Can you help?"

The answer to _that_ question is very simple. "Yes". This is untested, but from what I understand of the way everything works, it _should_ be right. It's easy enough for you to try it once and make sure everything is OK before you do it on a whole bunch of Macs. Or somebody will come along and say "you left out step X".

Set your preferences on the website to have a cache size of 0.0001, and to only do work between the hours of 1AM and 2AM.

Install BOINC on one OS X Mac. Attach to whatever projects you want. If it happens to somehow get work for one or more of the projects, set it to "run always" in the Commands menu, and "No new work" on all projects in the Projects tab. Run it dry. Set "network activity suspended" in the Commands menu, and then "Allow new work" on all the projects. (You want all project info to be "as you want it on the target Macs", but BOINC Manager settings and website settings can be anything.) Stop BOINC Manager.

Edit the "gui_auth_rpc.xml" file and change the random password to one you like. Create a "remote_hosts.cfg" file in the same folder, with the IP address of the Mac you are going to use to do the remote controlling. You now have a Mac with a complete install of BOINC, all attachments already made, all accounts already defined, all subfolders already created. Just the way you want it on the lab of other Macs.

Burn the entire "Library/Application Support/BOINC Data" folder to a CD, along with the downloaded BOINC installer.

Change the preferences on the website to a cache size of 0.1, and work always, or whatever you want.

Take the CD to the target Mac. Run the installer. Then copy the BOINC Data folder off of the CD right over the newly-created folder on the target Mac. (Two steps instead of one, but a lot simpler than attaching to projects, etc.) Reboot.

You're done. The lab Macs should be downloading work and running it and returning it. They _should_ also be able to be controlled remotely from your Mac, but quite frankly, I myself have not gotten that to work. I tried once and got nowhere, haven't had time to try again. I only have two Macs on the same network, so it's not a big deal to me. If I'd gotten it to work, I would have written that Wiki page...

---

there is NO documentation on the subject as that ENTIRE area in Wiki for the program is BLANK. As in NOT FILLED IN.

The info in the Wiki, what there is of it, is here.

I don't use Windows, the only OS for which those instructions are of ANY use.

The answer to _that_ question is very simple. "Yes". This is untested, but from what I understand of the way everything works, it _should_ be right. It's easy enough for you to try it once and make sure everything is OK before you do it on a whole bunch of Macs. Or somebody will come along and say "you left out step X".

Untested, undocumented, and non functional . . . . the "config file" you talk of MAY be of use, but there is no way to tell WHERE in the directory structure BOINC intends to find it. Hence, it's useless. Who the HELL distributes an untested application!!!

From the Instructions you cited.

The computer to be monitored has to be enabled through the use of a file named "remote_hosts.cfg" in the BOINC Directory of the BOINC Client Software on the computer that will be monitored.

Please note that on the Macintosh the BOINC application is distributed AS A PACKAGE. Unlike Windows the files it contains are bundled into a single pseudo directory with a .app extension, which MOST users (fortunately) don't screw with. On a Unix machine it would be LOGICAL to use the home directory of the running user. Just ONE problem. The program installs itself SUID (sets the sticky bit), so if a user who ISN'T the installing user runs it, it accesses the file system of the installing user and NOT the running user . . . This can create issues on systems used by more than one person where you want BOINC to be run no matter WHO logs in, and without using any fancy Unix tricks (CLI version, with system launch at boot . . . something I've been considering in light of the limitations of the GUI version).

It just feels like whoever wrote the interface not only isn't a daily Mac user, but likely hasn't written many, if any, Mac programs for public distribution. You've GOT to follow the User Interface Guidelines and PREFERABLY build your GUI (at least, if not the whole program) around the base application class.

Now, it's not biggy working around the "ugly" for me . . . I've been a Mac developer for YEARS, mostly for private companies/universities, but I've also done two commercial titles (WarBirds and World War II Online) and I would NEVER have let something like THAT get out of beta!! SURELY they have at LEAST a couple Mac users/programmers who are working with multiple machines and don't want or have to use Remote Access (OK, my fault, I'm cheap, I need to upgrade to the new version to get it to work with Tiger, and I haven't yet, otherwise I would have done it via RA), and still have a farm of machines to work on.

Unix is ALL about remote administration. It's a pity to see the feature on the Mac version so poorly implemented.

Let me know if you ever figure out where that file is supposed to go on the Mac. I THINK I know, but I have to test it . . . I'll just make a copy and move it around a bit until it works, or I get frustrated and give up . . . if i find a way to MAKE it work, I'll post it as a reply.

Sorry if I ruffled any feathers, today has been "hectic", even notwithstanding the BOINC distribution onto my network.

How about this. I will pretend that instead of complaining about the documentation on "problem A", you instead came in and said "Hi, I have a lab of OS X machines, and I would like to make it such that I can hand a CD to someone and they can install BOINC and attach to these 'n' projects, without having to do any more than necessary. Can you help?"

No, because THAT would have been the wrong question, and, btw, I do my installations from a file server over Gigabit ethernet. I have no need to burn an installation CD . . . that's for people with a lab of Windows machines to do.

Edit the "gui_auth_rpc.xml" file and change the random password to one you like. Create a "remote_hosts.cfg" file in the same folder, with the IP address of the Mac you are going to use to do the remote controlling.

Fascinating advice and proof you know NOTHING of the MacOS version of BOINC since it neither creates configuration files, nor does it reside in a "folder". Oh, wait, I already pointed out THAT fallacy when you foolishly pointed me to Windows instructions. You'd have been better to point me to the Linux version, since it's more likely to be apropos. At least that's something closer to a real operating system :-)

You're done.

Hardly. SETI should have stayed with the original program rather than using a half baked beta that doesn't even have a 64bit OS X 10.4+ version . . . given that this is supposed to be for scientific computing, ignoring the upper 32 bits of my registers seems alittle self defeating, to say nothing of the time it wastes when dealing with 64 bit primitives like doubles. I was VERY surprised to NOT see a 64 bit version available given that the compiler to generate such a version has been available since before the public release of Tiger.

---

Well, having been a Mac developer either full or part-time since 1984, I think I _do_ have some basic idea of how OS X works. You however obviously have no idea how BOINC works, and aren't very interested in finding out, you'd rather just complain.

The folder that BOINC creates on the Mac, along with the config files you insist it doesn't create, is Library/Application Support/BOINC Data. That is the _only_ difference between the Mac version and the Windows version, the location and folder name. (Hint: There is something called "Find File". It's been around for a while.) Installing from a network instead of a CD is a minor issue.

The (single) Mac developer who works on both BOINC and SETI is, I believe, a volunteer. There are a total of six developers, I believe only two are "paid". I don't like the GUI interface myself, and I do have a copy of the HIG sitting here, as well as "Tog on Interface", but I also understand that when you have a few hours or days to "port" whatever the latest Windows/Linux changes are over to the Mac, you take the lowest-common-denominator approach. It would be nice to have a true Mac app - it's all open source, you are welcome to contribute.

Good luck!

EDIT:: No point in a 64-bit version, with Mac going Intel; even on Linux, where one _was_ created, the performance gain just wasn't there. There _is_ an Altivec-optimized version available though. But you'd have to install it in that folder that doesn't exist.

---

After trying about 5 different was to present the data I did elect to use MediaWiki as it is the best compromise on features and colaborative editing. Sorry you don't like it.

As far as the location of the file, well, the text does say that the file is located in the "BOINC Direcotory", and following that link takes you to a page that says:

----
The directory on your computer that contains all of the BOINC related files.

On Windows, this is generally C:\\Program Files\\BOINC

On Macintosh OS X, this is generally /Library/Application Support/BOINC Data

On Linux, the directory varies, but is frequently ~/BOINC

The directory will vary if non-standard choices are made during the installation process.
----

And Bill is correct, if you write something that makes sense and is of reasonable quality I will be more than happy to include it in the WIki. If you have corrections to the text, if they make it better, well, I take all suggestions.

I am also sorry you find my effort unsatisfactory, but, like you I too am disabled and for the last couple months my disability has been winning and I have not been able to put in the concentrated effort it takes to do quality work. So, yes, there is a lot of content missing. There is a lot that could be improved. But, there is only one person that was able to put in 8 hour days writing content and that was me, to work on BOINC there are 6 UCB developers, a half a dozen volunteers, and several projects. All of which combine to invalidate the work almost as fast as it can be written.

WIth regard to testing of all aspects, well, this is a low budget, open source project. We have to fend for ourselves at times.

Welcome to BOINC.

---

The folder that BOINC creates on the Mac, along with the config files you insist it doesn't create, is Library/Application Support/BOINC Data. That is the _only_ difference between the Mac version and the Windows version, the location and folder name.

Bingo, yepper, I found it, though I was searching for THAT particular file name . . .

There is a lot that could be improved. But, there is only one person that was able to put in 8 hour days writing content and that was me, to work on BOINC there are 6 UCB developers, a half a dozen volunteers, and several projects. All of which combine to invalidate the work almost as fast as it can be written.

WIth regard to testing of all aspects, well, this is a low budget, open source project. We have to fend for ourselves at times.

Yes, it's a worthwhile project, if I can clear some other crap away I'm thinking about possibly volunteering some time. It's been awhile since I worked for Playnet on World War II Online, and I need to knock some of the rest off. Putting alittle polish on the Mac Client in the way of traditional access to preferences, and a few other elements, might not be a bad use of time at all.

I've been involved with the SETI project for some time, and have always loved distributed computing . . . the World War II Online server is the first distributed host Massively Multiplayer online game server, and, as far as I know, possibly the ONLY one in the United States. All the rests have to run their worlds as "shards" by breaking them into different realms, etc . . . WWIIOL handles vast number of players by using a secondary network controller as a backbone bus to let the hosts keep necessary information synchronized with the responsibility for updating individual players being up to whatever cluster node they happened to get sent too when they logged in.

Something like BOINC is SIGNIFICANTLY nicer in that it isn't so finicky about time, but the end result of the work is better in that it actually does something other than entertain . . . and given how overpowered personal computers are these days, there are a GREAT many free processing cycles out there that could be put to good work. Making BONIC alittle more user friendly might help some of the more or less technically "uninclined" (most Mac users) actually join in as well.

I'll have to see how next month goes then start taking a look at a the source and see if I can be of assistance.

---

I played EverQuest until my reflexes were too poor that I was endangering my other members of the party. I also got tired of the need to endlessly level the character up to enjoy the content and the only way to do this was to do combat. The feature to tailor an scenario to the group was one of the nicer features, though the manical insistance that grouping was mandatory was the biggest downside for me. Since I never know how long I would have to play it was a bad fit.

I tried a couple of the others, and one of them was a little better "fit" for my style, but, I guess I was gamed out ...

There are many aspects of BOINC that need significant work, preferences is just one of the small areas. Though, working on the code to make Mac only features will not fly. So, be prepared for the need to be able to make the proposed changes cross-platform. Though with WxWidgets much of that is taken care of for you.

---

There are many aspects of BOINC that need significant work, preferences is just one of the small areas. Though, working on the code to make Mac only features will not fly. So, be prepared for the need to be able to make the proposed changes cross-platform. Though with WxWidgets much of that is taken care of for you.

True, I just have an abiding distaste for essentially requiring users to go someplace they should never be, the system level library . . . Having to edit (or in this instance, create) files there is NOT a good thing. Although preferences may SEEM a minor issue, Mac users are used to being able to control ALL the functionality of their program from the GUI. When they don't have that they give up in disgust.

Because the SETI project shut down the traditional method, I suspect the work units generated will go down significant at Mac users who can get along with a simple GUI based application where all the controls are "right there" and preferences are actually where preferences belong, shift to BOINC where SOME of the preferences are pretty darn well hidden, not well documented, and difficult to use.

On the UP side, nothing right now is significantly difficult that those who REALLY want to work on a project can't. I found NO problems adding projects as long as I wasn't doing it remotely, and though its not QUITE as easy as the original SETI Application, it has the DISTINCT advantage of being significantly more flexible.

One thing I DON'T like is it's apparently need to set the sticky bit though . . . I'm wondering if that's a shortcut to avoid permissions issues, or what . . .but in general SUID programs are considered to be a significant potential threat to MacOS X. I think that ONE of those aspects that needs significant works is shedding the need to run something that loads remote program modules with a sticky bit set . . .

Still, I don't even have time to spend taking a serious look at the code to find if there's a design issue or if it was just a shortcut . . . (hopefully just a shortcut), though hopefully I'll have time in January. I haven't contributed to an Open Source project since the mid 1990's, so I'm alittle overdue . . . that crass commercialism thing kind of ate up all my time until MS finally retired me for good.

OTOH, if I hadn't been willing to do it, there would never have been a Mac version of WarBirds, and World War II Online probably wouldn't have ever been created at all.

I'll have to take a look at WxWidgets, though usually I did my cross platform work via API abstraction, I usually preferred to use my own API's . . . Call me a library bigot, but when I had control of the projects I used this ONE technique, so I've never gotten to really look at any of the other libraries out there that do similar things. Then again, WWIIOL and WarBirds were both fullscreen applications, so we were able to MUCH more easily create an abstraction layer to avoid cross platform issues. With a Windowed application it's significantly more difficult.

---

once the correct directory is found for the remote_hosts.cfg for the IP address/machine name to allow access, and gui_rpc_auth.cfg password I hit one final stumbling block on my Mac.... the firewall wasn't allowing port 1043 through... opened that up and now the Mac is controlled just like the PCs at home.
Shame it's so complicated. A simple password would probably be enough, and allow me to control from where-ever I want... even with NAT it's hard to check on status when I'm away from home (at the moment I RDP into a machine on the internal network and use BOINC Manager on that to adjust which machine is doing what - that at least has a known IP/machine name... but it's not very elegant!)

---

Random Thoughts