For modifying and compiling my BOINC core clients, I used the source code of the developer versions, and kept its version number. This client was compiled with Microsoft Visual Studio 2005 (v8), intentionally without using any processor specific optimizing. Although it has more functionality, the executable file is smaller than other currently available clients.
When the Credit Calibration option is enabled, the client will report adjusted Whetstones benchmark (Mfpops), and will finetune the claimed credit by sligthly modifying the final WU time. The resulting claimed credit respects the rules and the real value of the WU much better than when using stadard plain benchmarks only. The calibration uses the built-in correction coefficient that self-adjusts its value with each WU. Additionally, the ratio of FPOPS and IOPS benchmarks is taken in the calculation, and there is also mechanism avoding excessive claims, and limiting external manipulation. Resulting Claimed Credits (CC) for full-length S@H units should be close to the ideal 32 Cobblestones, and accordingly smaller at shorter units. After enabling the calibration feature, it can take several days (couple of dozens of units), before reaching full claimed credits.
In similar way, the client is also capable to adjust the CC at other projects. However, at projects with no optimized application, the correction will usually result in shorter corrected final WU time than the time actually spent on the calculation. It also means smaller Claimed Credit, and it is actually the intended purpose - we do not want to claim unfairly high credits at project with no optimization.
The goal of the feature is that the client claims fair credits for the work done. Normally, the SETI@Home reference WU, when calculated by a reference machines should result in credit of 32.32 cobblestones. Approximately the same credit should be granted for any full-length WU. Unfortunately, due to the optimized S@H applications, performing faster than anticipated, this is rarely the case - the credit may be as low as just ~5 cobblestones per standard WU. This is the reason people are hunting for clients with higher benchmarks, and some people even try to manipulate them manually. That is rather unfair, especially if the host computer works on multiple projects. The credit claimed for the work at other projects may be then far over the normal level, which is certainly not fair, should be avoided, and can even trigger alarms or bans on the project server.
The real CPU time spent on the unit and the corrected whetstone benchmark value may be viewed in the messages or logs on the host, and also in the workunit details in your project account on the web. It may contain the following information in the stderr out field:
<core_client_version>5.3.8.tx20</core_client_version> <real_cpu_time>111</real_cpu_time> <corrected_cpu_time>129</corrected_cpu_time> <corrected_Mfpops>733.8</corrected_Mfpops>
Please note that the software is offered as is, with no warranty at all. Use on your own risk! Since I compiled the source code of the developer version (not the public release), it is very likely that the client can contain some bugs. Do not forget to make backup before you install the software.
The same version can be used for all processors. Unlike at optimized clients, the benchmark is unimportant. Better told, we intentionally want to keep the benchmark low, causing the projects without optimized applications not sending exagerated credit requests like it happens with optimized clients. I am also attaching the source code of the modified files. All my modifications are marked with // TX and well commented for easy comprehension. I tried to write all modifications cleanly, and respecting the syntax and the structure used by the original developers.
Codes in the table are MD5 checksums over the entire package file (zip or tar.gz). They can be used to verify whether the archive file was downloaded in its full integrity
| Version | Windows (1) | Linux (2) | FreeBSD (3) | Mac (4) | Source Code |
|---|---|---|---|---|---|
| v5.3.12.tx36 | zip | tar.gz | n.a. | MacOS 10.4 | zip |
| Version | Windows (1) | Linux (2) | FreeBSD (3) | Mac (4) | Source Code |
|---|---|---|---|---|---|
| v5.3.12.tx39 | recalled | n.a. | n.a. | n.a. | n.a. |
| v5.3.12.tx37 | zip | n.a. | tar.gz | n.a. | n.a. |
| Version | Windows (1) | Linux (2) | FreeBSD (3) | Mac (4) | Source Code |
|---|---|---|---|---|---|
| v5.3.12.tx35 | zip | n.a. | n.a. | n.a. | zip |
| v5.3.12.tx34 | zip | n.a. | n.a. | n.a. | zip |
| v5.3.11.tx32 | zip | n.a. | n.a. | n.a. | n.a. |
| v5.3.11.tx31 | zip | n.a. | n.a. | n.a. | zip |
06-02-01 5.3.15.tx43 NEW: rpc_ip - limiting RPC interface (credit: CFMP) NEW: <suspend_new> suspending downloaded WU (credit: Pepo) 06-01-30 5.3.15.tx42 NEW: synchronized with official v5.3.15 NEW: continuing work on project and schedule scopes 06-01-29 5.3.12.tx41 NEW: <schedule> scopes in truxoft_prefs.xml (major remake) 06-01-28 5.3.12.tx40 NEW: <project> scopes in truxoft_prefs.xml (major remake) NEW: most configuration code moved to tx_prefs.C and tx_prefs.h NEW: tx_prefs.C and tx_prefs.h added to makefiles FIX: decreasing cache at priority projects FIX: work_buf_days handling 06-01-24 5.3.12.tx39 FIX: work_buf_days zero message FIX: argh, another forgotten project name lowercase 06-01-22 5.3.12.tx38 FIX: S@H-specific calibration limits FIX: clean up for FreeBSD build NEW: work_buf_days configuration setting 06-01-20 5.3.12.tx37 FIX: more lowercase at project names FIX: backup projects on multi-CPU boxes 06-01-19 5.3.12.tx36 FIX: lowercase at project names 06-01-19 5.3.12.tx35 NEW: <no_popup_alerts/> suppressing popup alerts <check_max_time> - suspending WU immediately (credit: forest) FIX: cleaning source code for Linux/GCC (credit: Uftoun-zemedelec) 06-01-18 5.3.12.tx34 NEW: option <check_max_time> alert (credit: Uftoun-zemedelec) 06-01-18 5.3.12.tx33 NEW: synchronized with the official build 5.3.12 06-01-17 5.3.11.tx32 FIX: <process_priority> used wrong type bool 06-01-16 5.3.11.tx31 NEW: calibrating client - 1st public release version
Please note: the list contains also alpha and beta versions. Beta versions are available in the download section above. Alpha versions are being tested internally only, and will be released here for beta testing when all functions work as intended. Please do not send any requests for alpha testing.
tx39 CRITICAL: work_buf_days causes undefined request lengths (fix: tx40) tx38 COSMETIC: work_buf_days displays 0.0 in messagesv (feature works) (fix: tx39) tx37 NORMAL: problems w. calibration at completed WU's after client restart tx37 NORMAL: backup project work requests at startup need some tweaking tx37 NORMAL: S@H calibration limits not working (fix: tx38) tx36 SERIOUS: decreasing cache at priority projects due backup ltd (fix tx41) tx36 NORMAL: cpu_affinity set by default? (unverified) tx36 COSMETIC: project names lowercase (fix: tx39) tx36 NORMAL: code needs cleaning for Unix/GCC (fix: tx38) tx35 NOT_A_BUG: SIMAP may not calibrate correctly (exclude SIMAP)
antispyware features (i.e. montoring outgoing connections of project applications) abuse protection (i.e. checking WU content against fraudulent project forwarding) Carsten Giese Trojan checker - alert when multiple BOINC instances found limiting RPC to a specific network interface - CFMP (added in tx43) project specific CPU affinity (added in tx42) scheduled configuration settings (added in tx41) project specific configuration settings (added in tx40) down/uploading another host's WU's into a separate dir SMTP alerting, SNMP reporting / monitoring suspending WU right after download - Pepo (added in tx43) watchdog / starting a new WU if WU's < CPU's
Stop the running BOINC program or service (depending on the original installation mode), replace the original boinc.exe file in the BOINC directory (typically in C:\Program Files\BOINC). You can only replace matching versions of boinc.exe - v5.x by v5.x (no v4.x clients). Keep backup copy of the original file for the case you need to put it back! Copy also all other files in the distribution zip archive (except of the readme files) to the main BOINC directory. Then restart BOINC again.
Some modifications were made in the official source code and additional features added. Please see below the details (the list of added features may grow over time). You can configure the additional options and features by editing the new configuration file truxoft_prefs.xml that you copied from the zip file to the main BOINC directory. The content of another sample configuration file with more options, can be found below. You do not need to add parameters for features you do not plan to use, and you do not need to add the file at all if you do not plan using any of the extensions. Note: for backwards compatibility to my older versions, the client also reads the configuration parameters from global_prefs.xml, and some of them in an older format from remote_hosts.cfg too. In that case, the client will automatically create the file truxoft_prefs.xml and move the parameters there.
Please note: the configuration documentation contains also features of alpha and beta versions. Beta versions are available in the download section above. Alpha versions are being tested internally only, and will be released here for beta testing when all functions work as intended. Please do not send any requests for alpha testing.
Configuration scopes were introduced in the release version 5.3.12.tx40. Most configuration settings can be used globally for all projects at any time, in a project scope for specific project only, or in a schedule scope for time limited effect only. The parser reads the setting from top to the bottom, where the last read setting value will override all preceding values. Therefore the global settings should be at the top, project and schedule settings below. Schedule scope may be both within the global scope and within project scopes, or may contain both global settings and project scopes.
<truXoft_conf> ...</truXoft_conf>
The global scope in the configuration file truxoft_prefs.xml is delimited by the tags <truXoft_conf></truXoft_conf>. Anything found outside these tags will be ignored and may be considered as comment. The global scope may contain project scopes delimited by the tags <project name="SomeProjectName"></project> and schedule scopes delimited by the tags <schedule start="2006/01/30 16:40" lenght="8" period="24"></schedule>. The parser reads the setting from top to the bottom, where the last read setting value will override all preceding values. Therefore the global settings should be at the top, project and schedule settings below. Schedule scope may be both within the global and within the project scopes, or may contain both global settings and project scopes.
<project name="SETI@Home"> ...</project>
<schedule start="2006/01/30 17:40" length="2.5" period="168"> ...</schedule>
With the help of the schedule scope you can define separate blocks of settings that are applicable only during the specified time range. The schedules may be repetitive or one-time only. The <schedule> XML tag must contain at least the length argument that defines in hours how long the configuration block should be active after the starting time.
The starting time can be passed through the argument start and must have exactly the following format YYYY/MM/DD hr:mn - for example 2006/01/30 18:45 If none starting point is given, 1970/01/01 00:00 is used. The time must be given in 24 hours format.
The argument period may be used to specify the frequency of repeating the schedule. The value is to be given in hours defining the distance between the starting time point and the beginning of the next schedule repetition. The schedule will be then repeated with the given period indefinitely. For example, the settings inside a schedule scope shown above, will be launched first time on Jnuary 30th, 2006; will be active during two and half hours, and repeated each week (7 x 24 = 168 hours).
The starting time can be a past date of course too. In that case the period is being calculated from that point and launched at the next closest repetition. If no period is specified or if it is set to zero, the schedule will be activated only once - at the specified time.
The schedule scope may contain global configuration directives valid for all projects, or it can contain project scopes with project-specific settings. When schedule is terminated, the client will parse the configuration file again, setting first the global settings, then looking for active project or schedule scopes and overriding with their settings the global configuration.
<rpc_port>1043</rpc_port>
I use BoincView for remote control of my machines. Some of them are behind a remote NAT router / firewall. Since there is only one IP address, no VPN tunel, and no possibility to remap ports on the router, I needed to change the ports in the BOINC clients, so that I can control multiple machines through a single IP address. You can pass the port number by adding the following line to truxoft_prefs.xml:
If the port parameter is not set, the default RPC port 1043 (at older versions) or 31416 is used. Of course, if using BoincView or similar manager, you have to set the same port number for the given client there too.
Setting the port to 80 (HTTP) or 21 (FTP) may be another possible use of this option for cases when you need to access a BOINC host from within a LAN protected by firewall with just those ports open in the outgoing direction.
<rpc_port>192.168.1.1:1043</rpc_port>
Added on request of Crunchers For More Power from SETI.Germany team. You can (but you do not need to) use this syntax if your computer has more than one network interfaces (i.e. multiple Ethernet cards, or Ethernet + WiFi, etc.) and you do not want unnecessarilly keeping the RPC port open on all of them. When the IP address of a network adapter is set, the BOINC core client will accept RPC requests for remote control/monitoring through the specified interface only.
<return_results_immediately/>
This option forces the BOINC client to report completed results immediately after uploading the result. Please note that the immediate reporting of the result may fail in some cases - for example when the network connection is not available, when the server is down or refuses the request, when another scheduler request has been made shortly before the current one, and possibly in some other situations. The WU will be then reported at the next scheduled time, or at the completion of the next WU (whatever comes first). Depending on the availability of the project server, the failure rate is typically around 10%.
<cpu_affinity/> (global scope)<cpu_affinity>2</cpu_affinity> (project scope)
In the version v5.3.2, I introduced a new change - assigning processor affinity to individual project tasks (WU's). On multiprocessor machines, if enabled in the global preferences, BOINC core client launches as many project processes (WU's), as many processors are available (or allowed to use). Unfortunately, the official client currently does not assign each process to a specific processor, and hence Windows spreads individual threads of the process among all available CPU's. In some cases, when a task intensively uses the L1/L2 cache, it can lead to loss of performance due to the CPU change and cache misses.
By adding the parameter cpu_affinity you can turn on the CPU affinity assignment of individual BOINC processes - each will be processed exclusively with a single CPU only.
Since the revision 5.3.12.tx40, you can assign the CPU affinity in individual project scopes, assigning so the respective project to the specified CPU. Workunits of the respective project will be started only on the given processor(s). Using <cpu_affinity/> in the global scope will result in using CPU affinity for every launched WU, but WU of any project may be assigned to any available CPU. When <cpu_affinity>1</cpu_affinity> is used at a project, its WU's will be launched on CPU1 only if it does not process any WU of any other project. CPU's are numbered from 1 to N (number of CPU's in the system). Value <cpu_affinity>0</cpu_affinity> is reserved for overriding the global affinity - use it when you turn on the global affinity, but desire that a specific project ignores it, and launches porcesses without CPU affinity set. You can assign multiple CPU's to a project by repeating the directive tags in separate lines, with another value in each of them.
Note: currently functional in Windows versions only!
<calibrate_credit/> (v5.3.12.40 and above)<calibrate_credit>Einstein@Home,SETI@Home</calibrate_credit>More details about the credit calibration and its reasoning can be found at the top of this page. Even more details are available on the S@H discussion board. If you do not agree with manipulating the claimed credit or fear some penalization, do not turn it on. Personally, I feel the feature is much fairer than using optimized BOINC core client when you participate in several projects. When you want to test it, turn it on by adding the project name(s) to calibrate into the truxoft_prefs.xml configuration file in the following format (use only one of them, depending on the number of projects you wish to calibrate):
<calibrate_credit>SETI@Home</calibrate_credit>
<calibrate_credit>Einstein@Home,SETI@Home</calibrate_credit>
<calibrate_credit>all</calibrate_credit>
The calibration was primarily developped for calibrating SETI@Home work units processed by the 4.x applications. At other projects, it should work too, but was not extensively tested, and it will typicaly reduce the claimed credit instead of increasing it (since there are currently no optimized applications for other projects). At some projects using different crediting system it will not work at all. At S@H Enhanced application, that uses operation counter instead of CPU time for the credit estimation, calibration will not be needed unless there is a new client with considerably different functionality.
NOTE: the final calibrated claimed credit will not be visible in Boinc Manager or in BoincView, but only in the user account on the web, or in Boinc Messages and the log file (stderrdae.txt). The calibrating coefficients are stored in status files and protected by a checksum and a password. Any attempt to manually modify the coefficients will result in resetting and restarting the calibration process. After significant change in performance of the PC, or after running benchmarks, the client will need to adjust the calibrating coefficients accordingly, so the first few claimed credits after such change may have bigger tolerance.
<process_priority>4</process_priority>
Another change in the v5.3.2 is the possibility to assign higher than the default 'idle' priority to BOINC tasks. You can set it with the help of the parameter set_priority in remote_hosts.cfg:
<process_priority>0</process_priority> ... (or parameter not set) default IDLE priority<process_priority>1</process_priority> ... BELOW NORMAL priority<process_priority>2</process_priority> ... NORMAL priority<process_priority>3</process_priority> ... ABOVE NORMAL priority<process_priority>4</process_priority> ... HIGH priority<process_priority>5</process_priority> ... REALTIME priority (dangerous - not recommended!)Note: currently functional in the Windows version only!
<project_priority>2</project_priority>
Added on request of user ThierryH from L'Alliance Francophone. When you assign a project or multiple projects to the priority group with the help of this tag, the core client will ignore all other rules for scheduling individual tasks and as long as there is work available it will always start the first project in the comma delimited list. If there are no workunits available for the first priority project, it will try starting the second one (if present), etc. When there is no work for projects of the priority group, the client switches to the standard scheduling mode.
IMPORTANT: when the priority project works, the backup project(s) will not be started even if their work units are close to the deadline or over it!
<priority_projects>SETI@Home</priority_projects>
<priority_projects>Einstein@Home,SETI@Home</priority_projects>
<delete_overdue/><delete_overdue>1</delete_overdue> (syntax for future extesnions)
When set to 1, the client automatically deletes all unfinished overdue workunits of all projects to avoid spending the time on them uselessly. Currently only workunits with expired deadline are being deleted. Next release may allow deleting of workunits with estimated completion time past the deadline too.
<check_max_time>2.2</check_max_time>
This was an idea of Vejpuste aka Uftoun - Zemedelec from CNT who first implemented it with the help of a sell script under Linux. The script alerts him by email when a WU has been procesed suspiciously long time. There were couple of erroneous S@H units that took several hundreds hours before completing or ending with an error. Since the release v5.3.12.34, the Windows client will write a message to the stdoutdae.txt and an alert window pops up, asking you if you want to abort the unit. The value within the XML tags assign the threshold value that triggers the alert. For example, if you set it to 2.5, the alert will come when the processing time exceeds two and half times the estimated WU calculation time.
<no_popup_alerts/>
If you do not want that the client alerts you by poping up a dialogue box, at some critical events (currently at check_max_time only), add this tag to the truxoft_prefs.xml configuration file:
Note: popup alerts are currently available in Windows versions only, hence using the option under other OS'es is irrelevant
<work_buf_days>5.5</work_buf_days>
Normally, you can influence the workunit cache by modifying the contacting period (exactly the setting Connect to network about every:). However, it has also the effect that the client will contact the scheduler accordingly. It means at low setting, the client will contact the scheduler for new work frequently, but will always ask just for very little work. If you then lose the connection or the server is down, you can easily finish with no work at all. In contrary, if you set the option high, you will request high number of units, but will not restock them too frequently. In case of project server that is often unavailable, it may happen that the client misses the rare opportunity to download new work. In such cases, it may be wiser to set the work cache higher than the contacting period. You can do it now with this setting:
Note: Please use with caution and do not abuse it to load excessive number of units that you are not able to process within the given deadline. Since the setting is currently global for all projects, keep on mind the lowest deadline of all projects. Please be modest especially in peak times when project servers are overloaded. Also please do not set your contacting period in the web settings too low - it puts unnecessary load on the project sever.
<suspend_new/>
Added on request of Pepo from TatraMed team. When set, the client will suspend all newly downloaded WU's. The purpose is to avoid unattended starting of potentially dangerous units that need to be surveyed, or that may crash the computer - for example at some beta projects. In the same time, at such projects, availability of the units on the server may be rather low and hence forbidding network access at such project in absence of an operator is not a good solution. Automatically suspended new units may be then started manually when needed. You can use the option in the specific project scope, of course.
41.123.32.233/22
You can allow remote control over RPC by adding idividual IP addresses of the controlling computers to the file remote_hosts.cfg. Unfortunately, in the original BOINC client you can only use indivdual IP addresses, and no subnets or blocks of addresses. When you need to allow control from a remote mahine with no fix IP address or at least a dynamic domain name, or when you need to allow acess from multiple IP addresses on the LAN, it is really not easy. I added the possibility to define blocks of addresses with the help of network mask - the most common way used for such purposes. The modified code accepts masks both in bit length and in dotted address format.
For example the bit lenght mask of 24 in 41.123.32.233/24 is equivalent to 41.123.32.233/255.255.255.0, and it represents all addresses in the range of 41.123.32.1 to 41.123.32.255. Address/mask pair of 41.123.32.233/24 would result in 41.123.32.233/255.255.0.0, which is the range of 41.123.1.1 to 41.123.255.255. There is a third way to assign ranges of addresses: for example the address 41.123.32.0 represents the range 41.123.32.1 to 41.123.32.255, or the address 41.123.32.0 describes the range of addresses from 41.123.1.1 to 41.123.255.255.
The following examples are equivalent:
41.123.32.233/24 = 41.123.32.233/255.255.255.0 = 41.123.32.0 ==> 41.123.32.1-41.123.32.255 12.111.22.123/12 = 12.111.22.123/255.255.0.0 = 12.111.0.0 ==> 12.111.1.1-12.111.255.255
boinc.exe -reset_debts (command line)
Added on request of user Honza from CNT. This is a command line switch, not a configuration setting. If used when starting the core client from the command line, all short time and long time debts will be set to zero.
<truXoft_conf> <return_results_immediately/> <cpu_affinity/> <process_priority>0</process_priority> <rpc_port>1043</rpc_port> <delete_overdue>1</delete_overdue> <check_max_time>2.2</check_max_time> <work_buf_days>2.5</work_buf_days> <no_popup_alerts/> <project name="SETI@Home"> <calibrate_credit/> <cpu_affinity>1</cpu_affinity> <process_priority>2</process_priority> <projects_priority>1</projects_priority> <delete_overdue>1</delete_overdue> <check_max_time>1.8</check_max_time> <work_buf_days>5.0</work_buf_days> </project> <project name="Einstein@Home"> <cpu_affinity>2</cpu_affinity> </project> <schedule start="2006/01/30 17:40" length="2" period="24"> <check_max_time>4.5</check_max_time> <project name="SETI@Home"> <cpu_affinity>0</cpu_affinity> <process_priority>4</process_priority> </project> <project name="Einstein@Home"> <process_priority>4</process_priority> <cpu_affinity>0</cpu_affinity> </project> </schedule> </truXoft_conf>
The optimized client writes a log message to the stdoutdae.txt file at the loading time when it finds any of the additional parameters. You can view the messages by opening the file in Notepad, or in Messages in BOINC Manager or BoincView too. In this way you can easily verify if your settings were accepted.
2006-01-04 23:26:05 [---] General prefs: no separate prefs for home; using your defaults 2006-01-04 23:26:07 [---] Remote control allowed 2006-01-04 23:26:07 [---] Listening on port 31416 2006-01-04 23:26:07 [---] truXoft add-on: process priority = 4 2006-01-04 23:26:07 [---] truXoft add-on: return_results_immediately 2006-01-04 23:26:07 [---] truXoft add-on: set_cpu_affinity 2006-01-04 23:26:07 [---] truXoft add-on: calibrate_credit = SETI@home
# port = 1044 # return_results_immediately # set_cpu_affinity # set_priority = 1 192.168.2.1/24 123.12.123.12 12.123.12.123/255.255.0.0 some.site.com Joe
You can freely redistribute the software, but I do prefer that you link to this page instead of serving the files from your site. Also please do not link directly to the download files! Linking to the main page will greatly simplify future updates, and I also prefere if people have the chance to read the accompanying description and notes here.
IMPORTANT: If you have any troubles or doubts, please write your question to the BOINC message boards - there are plenty of experts who will happily jump in with a helpful advice, and I may answer too if I have the chance to see it. Please do not use e-mail, unless your message necessarily requires confidentiality. I am handling daily many hundreds of emails, and often have to ignore messages not concerning my daily job.
My BOINC clients do not contain any hidden functions that would collect or forward data from your computer or network, or that would redirect work done on your computer to other user accounts (and yes, that is all actually easily possible). It was not designed to do anything else than the standard BOINC core client, except of the additional functionality documented on this page. The client does not contact my server ("calling home"), and it also does not contact any other 3rd party, with the exception of project servers you deliberately adhered to. Some BOINC versions may contact the main Berkeley's BOINC server when checking for new versions.
The functionality of the original official BOINC core client from Berkeley will be maintained also in future versions, so you should also study the privacy policy of the original developer team. I'll be using their source code possibly without reviewing and analyzing all changes, so I cannot take full responsibility for the functionality of the original. I fully stand behind my modifications though and publish them in source code as soon as they are released as public stable version. I can also guarantee that Windows and FreeBSD binaries compiled by myself, and available on my server, will be identical to binaries compiled from the published source code.
Binaries from 3rd parties (such as the Linux client) were compiled from the same source code, and although I trust the author, I cannot take the full responsibility for them. Please scrutinize the source code and compile the client yourself whenever you are in doubts, or if you plan to use it in corporate environment requiring higher level of security. The compiling is pretty straightforward and there are free compilers for most operating systems. Do not trust unknown 3rd parties offering my (or any other) BOINC clients or applications without the possibility to review and recompile their source code.
The best way to run BOINC core client and BOINC projects, regardless of the OS, is doing it under a separate user account with maximally restricted rights. In such way you can avoid damage caused by buggy or fraudulent clients or applications. Read more details about security concerns related to BOINC in the coming article BOINC and Security.
First of all, credits go to the original BOINC developers and all their countless volunteer helpers. Then, I'd like to thank to those who greatly helped me actively with beta testing and debugging - especially to Miras (CNT), Mr.Pernod (2CPU.com), 'bosh (CNT), Vejpuste (aka Uftoun-zemedelec, CNT) but also a number of others. Further, credits must not be forgotten for feature and improvement suggestions: ThierryH (L'Alliance Francophone), Honza, Uftoun-zemedelec, forest (all from CNT), CFMP (SETI.Germany), Pepo (TatraMed), and others (many from CNT). Special thanks go to Czech National Team anyway - for their support, testing and suggestions.
Big thanks and credits go also to those who compiled the calibrating client for platforms I could not easily do myself: to Vejpuste (aka Uftoun-zemedelec) for the Linux version, and to boog for the MacOS versions.
The financial help offered by some members is equally important and allows me to buy and update the much needed compilers, libraries, debugger, profiler, analysers, and other needed tools, which I could not easily afford without the sponsors. Special thanks belong to the very first donor - member my former Czech National Team reALTom. I especially value his contribution, because I am well aware that for Czechs, who still gain often tenfold less than is usual in Western Europe, such donation is much more difficult to make. In fact, 'bosh (another member of my fromer Czech team) ought to be the first donor with a very major subvention - he offered his financial help before I purchased the ICC compiler and IPP libraries. I refused in that time, because I was not sure if I manage to create what was expected. However, 'bosh sent his huge donation later anyway, but it was delayed due to PayPal problems. Big thanks 'bosh!!
Big thanks for other donations, besides reALTom and 'bosh, to John Roberts, KevinT (twice!), parknook, and four other donors who wished to stay anonymous!
|
The compiled clients are my contribution to the BOINC community, and I do not intend profiting from it. However, the cost of the software tools for Windows development is huge (over three thousands of dollars), so if you can help with a small donation, I may be able to buy other tools I need for better optimizing - Intel Math Libraries, Intel Debugger, Profiler, and possibly other needs may emerge (i.e. updates). I already purchased full and legal versions of MS Visual Studio PRO 2003, and the Intel ICC Compiler + the Intel IPP Library. I did so spontaneously, without expecting any return, but unfortunately I cannot afford spending any more funds on the other needed tools. Any donations to help covering the cost of the development tools are very much appreciated!
Current donation status: €352.20 (updated manually) |