as the message says... that client will have some basic features like return_results_immediately...
Note:
It'll be a stock client without any optimizations turned on. (like cpu affinity, double_num_cpus, reset_debs etc etc etc...)
(cpu_affinity etc. will be available to the team only...sorry)
you can decide here:
POLL
and feel free to leave a comment.
Copyright © 2024 Einstein@Home. All rights reserved.
POLL...Do you want a 64 bit BOINC client & BOINC MANAGER for Win
)
return_results_immediately is a bug not a feature.
BOINC WIKI
BOINCing since 2002/12/8
RE: return_results_immediat
)
depends on the point of view.
If you're in an area where powerloses are taking place in random. well i'd call that a feature instead of a bug.... AND it's been requested a lot of times.
Reagarding the DB load, well it's a kind of personal view... uploading and reporting the same time or not... Kinda stay safe while do both at the same time ...
To be more precise it was a
)
To be more precise it was a development option intended to be removed at about the 3.xx version level. Due to a improper compile setting it was set to on for all of the 4.45 clients. The bug was removed in the next version and the option removed in the 5.x.x client.
edit: I was actually on the verge of making a favorable response to the poll until I saw that this bug was part of the package.
BOINC WIKI
BOINCing since 2002/12/8
RE: It'll be a stock client
)
This strikes me odd. The boinc client is under the GPL, right? So you're obliged to provide source code of any modifications you do to it, aren't you?
So how can you legally limit distribution of modified client just to your team members?
RE: RE: It'll be a stock
)
Because the source requirement only applies if it's released to the general public.
The corollary to that is since a member of the private organization does not have access to the source code, it would be a license violation for them to turn around and distribute the binary outside of the private organization.
Alinator
Off-Topic : The
)
Off-Topic :
The -return_results_immediately should not be needed and the default, as there's literally no reason 'not' to report Results immediately.
The BOINC Manager not doing it by default was the result of an error in thinking in Berkeley, as it never had any advantage (only disadvantages for some)
RE: RE: RE: It'll be a
)
Wikipedia would appear to disagree with you, on lots of points:
GPL conveys rights on "recipients" or "licensees", including "the right to study how the program works, and modify it. (Access to the source code is a precondition for this)". I would argue that team members are "recipients" in this sense.
GPL "requires derivative works of GPL-licensed programs to also be licensed under the GPL" - so unless the author of the proposed 64-bit version is re-writing the whole thing from scratch, they are themselves breaching the GPL by passing on the derived work to anyone else. [edit - that is, if they don't pass it on under a GPL licence]
Conversely, no disclosure of source code is required if the resulting software is kept only for use by the modifier.
I suppose it depends whether the "team" in question has the legal status of a body corporate under the legal system of the governing territory.
I am worried by any poll
)
I am worried by any poll which has a pre-selected default answer. On the other hand, this would explain how on earth {insert name of your least-favourite politician} ever managed to get themselves elected in the first place!
RE: Off-Topic : The
)
Reporting results is a database access, doing 2 or 3 at the same time reduces the load on the database. So reporting results immediately has disadvantages for everyone in the form of slower database functions.
BOINC WIKI
BOINCing since 2002/12/8
RE: Reporting results is a
)
That was the exact thinking error Berkeley made in the old days.
Since the Database accesses have to happen eventually anyway, there's no difference if they happen immediately or after a day or after a week.
Therefor it makes no sense, as you and everyone of us produces a rather continuous stream of Results after a very short time and the Database is being accessed at the nominal level.
At this time, it's virtually the same Database access and it doesn't matter if the Results are 10 Seconds old or 1 week old (it only increases the chance of losing the Result in case of System problems)...
And if accepting 1 Result at a time is so much more burden on a Server, it simply is not a suitable server. That was the case when the idea was invented (Berkeley being catastrophically underpowered for the comparably bloated BOINC Server software). Modern and Project-size-appropriate Servers couldn't care less.
The other reason that way of thinking was wrong right at day 1, is that Uploading the Result should have been all that is required.
I mean, once the Result is uploaded (it's there, it is the largest data transfer in the whole process - ironically uploaded immediately with no option to even delay it - and in the Server Database anyway now, plus it has load balancing built in - delaying the Upload when no contact is possible or the Server asks for it), why on earth would a second step ("Report" Result") be needed anyway, while being all but a few bytes worth of traffic ?
No other DC platform ever needed this, and there is no practical use except putting unneeded additional stress on the databases plus it increases the probability of failures.