> Just for curiosities sake why don't you want to use BOINC as your platform?
> Or, can you tell us what you don't like about it?
It's the whole idea of having to run an application to run an application that turns me off, and I don't care what it looks like, because it belongs in the task tray as an ICON or hidden 99% of the time. ;)
I can appreciate trying to create a one stop shop.
If there was a .txt config file where one could list the projects they were interested in, like in this example, I've heard some folks would rather do this.
SETI=0;www.website.linkage
Einstein=1;www.website.linkage
However, that's just another Menu system but it would be a better approach.
I prefer to run the clients that I chose directly, from a command line, without any GUI to take cycles away from said client to maximize results to the project.
It would also be easier to port to other platforms other than windows.
Which would give you a larger user base of participation.
If project admins want to be serious about getting folks to run their clients, it needs to be maximized for results, not slowed down by any fancy graphics.
I know it's the graphics that sell the project to the newbies, but dedicated crunchers that spend alot of money on the pharms and the electricty to keep them running, appreciate robust clients that maximize client output.
I also don't like projects that require JAVA either, but, that's just me.
For examples:
DNET is a great client and if all projects used that concept/design, they would be better off for some of the reasons I mentioned above.
Screensavers are not a very effective means to get results either.
Just my 2 cents - not trying to bash anyone.
I was interested in running this project, but without a stand alone client that just gets the work done, I'll just have to wait for project admins to figure it out.
My favorite clients are DNET, old SETI CLI, SOB, Chessbrain CLI, DF when it was active, DPAD/Muon1 CLI etc.
Yeah... you need to do some more homework. There is a CLI version of BOINC. However if you don't manually open up the graphics or set BOINC as your screensaver, it will take up very few resources. I just checked 3 of my computers. On each one it looks like BOINC itself is taking up less than one minute of CPU time per day. One computer has been running it for 38 days straight and BOINC has accumulated 35 minutes of CPU time. The others have all been restarted recently so it isn't quite as accurate but about 1 minute per day appears to be about right. That is pretty minimal if you ask me. The OS will take up way more than that.
Also the next major release of the BOINC windows installer will supposedly have some kind of fleet deployment tool that will let you set it up on your entire farm at once. If you are running linux, then all it takes is a file download and a chmod +x to run it. Doesn't get much simpler than that really. Also with the new version will come increased control over the client via RPC calls which will also make it friendlier to farms.
The whole point of BOINC is to make it easy to develop distributed computing projects because BOINC takes care of the underlying infrastructure so to expect BOINC projects to also furnish a standalone client is completely unrealistic.
BOINC got off to a rough start because of server problems at seti@home and I think people have been badmouthing it because of this without bothering to check back and see if things have gotten better (but don't look now - seti is having more problems after several months of smooth running :).
The graphics run as a seperate thread which simply does nothing as long as you don't chose to show them by opening the window or running the screensaver. On Linux the graphics code isn't even loaded when it can't be run (due to lack of libs etc) and silently dies when it doesn't get a connection to an X server without affecting the "worker" thread (science code).
Current Linux and Mac clients are command line clients only. The command line client is also part of the Windows bundle. Install BOINC on one (frontend) machine, attach it to the projects you want to, then zip up the client "boinc_cli.exe" and the "account_(project_url).xml" files, distribute this zip to the farm and start the clients remotely. No graphical interface is needed. The messages are written to files stderr.txt and stdout.txt, so these can also be monitored remotely.
There is no single config file, but you can assign parts of the farm to different projects by chosing which account files are in the bundle and end up in the directory where you run the client. Look into the account file once you created one by attaching to a project - the structure is simple enough so you can clone and modify them yourself for the projects you want to run.
> Install BOINC on one machine,
> attach to the projects you want to, then zip up the client "boinc_cli.exe" and
> the "account_(project_url).xml" files, distribute this zip to the farm and
> start the clients remotely. No graphical interface is needed. The messages are
> also written to files stderr.txt and stdout.txt, so these can also be
> monitored remotely.
Exactly - and BOINC is actually easier to manage because of the webbased system where you can control many machines at once and group them to ease maintenance.
With the new network aware BOINC manager (and some of those nice addon managers) you can even control your clients (hundreds of em) directly over the LAN network. Which is great for even very large farms.
> I would really like to participate in this project, however, I have no
> interest in using BOINC.
> I know I'm not alone.
>
> Do you intend to create a client for this purpose?
>
> Thanks.
>
Without BOINC
)
No. Sorry.
BM
BM
Just for curiosities sake why
)
Just for curiosities sake why don't you want to use BOINC as your platform? Or, can you tell us what you don't like about it?
Your feedback if given constructively could have future merit in the even t that the core client is upgraded.
Don't be shy!
> Just for curiosities sake
)
> Just for curiosities sake why don't you want to use BOINC as your platform?
> Or, can you tell us what you don't like about it?
It's the whole idea of having to run an application to run an application that turns me off, and I don't care what it looks like, because it belongs in the task tray as an ICON or hidden 99% of the time. ;)
I can appreciate trying to create a one stop shop.
If there was a .txt config file where one could list the projects they were interested in, like in this example, I've heard some folks would rather do this.
SETI=0;www.website.linkage
Einstein=1;www.website.linkage
However, that's just another Menu system but it would be a better approach.
I prefer to run the clients that I chose directly, from a command line, without any GUI to take cycles away from said client to maximize results to the project.
It would also be easier to port to other platforms other than windows.
Which would give you a larger user base of participation.
If project admins want to be serious about getting folks to run their clients, it needs to be maximized for results, not slowed down by any fancy graphics.
I know it's the graphics that sell the project to the newbies, but dedicated crunchers that spend alot of money on the pharms and the electricty to keep them running, appreciate robust clients that maximize client output.
I also don't like projects that require JAVA either, but, that's just me.
For examples:
DNET is a great client and if all projects used that concept/design, they would be better off for some of the reasons I mentioned above.
Screensavers are not a very effective means to get results either.
Just my 2 cents - not trying to bash anyone.
I was interested in running this project, but without a stand alone client that just gets the work done, I'll just have to wait for project admins to figure it out.
My favorite clients are DNET, old SETI CLI, SOB, Chessbrain CLI, DF when it was active, DPAD/Muon1 CLI etc.
For large home pharms the
)
For large home pharms the ease of installation not requireing GUI or install packages is great.
Just a client with a simple TEXT config file that could be spread quickly to all the other computers to get them up and running quickly is ideal.
Services is not that important to me, as I never use them, except for SOB on my 3 Duals.
There are folks out there with 50-100GHz pharms to offer up to proejcts for free, for those that take the above approach...
just something to keep in mind when designing clients...
Again, just my 2 cents...
Ironbits, if you had checked
)
Ironbits, if you had checked out the reality of how BOINC works by actually INSTALLING it, you might be taken a bit more seriously. ;)
Be lucky,
Neil
IronBits, Looks like you
)
IronBits,
Looks like you and the others in the anti-BOINC league will have to find something else to do with those extra cycles.
There's a fine line between fishing and standing on the shore looking like an idiot -- Steven Wright
Yeah... you need to do some
)
Yeah... you need to do some more homework. There is a CLI version of BOINC. However if you don't manually open up the graphics or set BOINC as your screensaver, it will take up very few resources. I just checked 3 of my computers. On each one it looks like BOINC itself is taking up less than one minute of CPU time per day. One computer has been running it for 38 days straight and BOINC has accumulated 35 minutes of CPU time. The others have all been restarted recently so it isn't quite as accurate but about 1 minute per day appears to be about right. That is pretty minimal if you ask me. The OS will take up way more than that.
Also the next major release of the BOINC windows installer will supposedly have some kind of fleet deployment tool that will let you set it up on your entire farm at once. If you are running linux, then all it takes is a file download and a chmod +x to run it. Doesn't get much simpler than that really. Also with the new version will come increased control over the client via RPC calls which will also make it friendlier to farms.
The whole point of BOINC is to make it easy to develop distributed computing projects because BOINC takes care of the underlying infrastructure so to expect BOINC projects to also furnish a standalone client is completely unrealistic.
BOINC got off to a rough start because of server problems at seti@home and I think people have been badmouthing it because of this without bothering to check back and see if things have gotten better (but don't look now - seti is having more problems after several months of smooth running :).
A member of The Knights Who Say Ni!
My BOINC stats page
IronBits: The graphics run
)
IronBits:
The graphics run as a seperate thread which simply does nothing as long as you don't chose to show them by opening the window or running the screensaver. On Linux the graphics code isn't even loaded when it can't be run (due to lack of libs etc) and silently dies when it doesn't get a connection to an X server without affecting the "worker" thread (science code).
Current Linux and Mac clients are command line clients only. The command line client is also part of the Windows bundle. Install BOINC on one (frontend) machine, attach it to the projects you want to, then zip up the client "boinc_cli.exe" and the "account_(project_url).xml" files, distribute this zip to the farm and start the clients remotely. No graphical interface is needed. The messages are written to files stderr.txt and stdout.txt, so these can also be monitored remotely.
There is no single config file, but you can assign parts of the farm to different projects by chosing which account files are in the bundle and end up in the directory where you run the client. Look into the account file once you created one by attaching to a project - the structure is simple enough so you can clone and modify them yourself for the projects you want to run.
BM
BM
> Install BOINC on one
)
> Install BOINC on one machine,
> attach to the projects you want to, then zip up the client "boinc_cli.exe" and
> the "account_(project_url).xml" files, distribute this zip to the farm and
> start the clients remotely. No graphical interface is needed. The messages are
> also written to files stderr.txt and stdout.txt, so these can also be
> monitored remotely.
Exactly - and BOINC is actually easier to manage because of the webbased system where you can control many machines at once and group them to ease maintenance.
With the new network aware BOINC manager (and some of those nice addon managers) you can even control your clients (hundreds of em) directly over the LAN network. Which is great for even very large farms.
> I would really like to
)
> I would really like to participate in this project, however, I have no
> interest in using BOINC.
> I know I'm not alone.
>
> Do you intend to create a client for this purpose?
>
> Thanks.
>