[cfarm-users] Compile Farm acceptable usage---low priority batch jobs

[Jonathan Wakely]

On Fri, 3 Jan 2025, 01:40 Jacob Bachmeyer, <jcb62281 at gmail.com> wrote:

> On 1/2/25 03:43, Jonathan Wakely wrote:
>
> On Thu, 2 Jan 2025, 02:55 Jacob Bachmeyer via cfarm-users, <
> cfarm-users at lists.tetaneutral.net> wrote:
>
>> On 1/1/25 19:23, Paul Eggert wrote:
>> > On 2025-01-01 16:32, Jacob Bachmeyer via cfarm-users wrote:
>> >> Perhaps a combination of nice(1) and ulimit(1) would be suitable?
>> >
>> > Not for mining, no. It would still consume resources that are better
>> > used for cfarm's intended purposes.
>>
>> The intention is to limit "miner" testing to idle time, or as close to
>> that as we can get.
>>
>
> No, it should be zero time, not just idle time.
>
> I have a philosophical view that idle time on servers is essentially
> wasted: a sunk cost.
>
> Also, note that I am suggesting allowing /testing/ "miner" software, not
>> /using/ it.
>>
>
> I suggest banning it entirely. The cfarm has no obligation to provide
> resources to miners, even for testing.
>
> The idea is for portability tests to less-common architectures.  I admit
> that that may actually not be something the "miner" developers care about.
>

So a waste of time then


For testing, it should be possible to set up an environment with a known
>> state, instead of using a "live" blockchain, so there is no need to
>> actually store the blockchain structure, which I agree would be an
>> intolerable waste of disk space.
>>
>
> Just because something is possible doesn't make it useful. Why are you
> trying to find a way to support something that doesn't need to be supported?
>
> First, to appropriately minimize the resources used, and prevent creating
> perverse incentives to tie the cfarm CPUs in knots.
>

Or just say it's not allowed.

Second, I like finding technical solutions to technical problems, and I
> view this as a technical question of how we can maximize the global utility
> of the cfarm with minimal compromise to other uses.
>

It's not a technical problem.


[...]
>>
>> >> I would suggest ... making very clear that "mining" for profit is not
>> >> permitted
>> >
>> > That wouldn't suffice, as it's too easy for me to say that I'm not
>> > doing something for profit, when I get to define "profit". (See what
>> > many US "nonprofits" do.)
>>
>> Simple definition:  if the results of "miner" "testing" are submitted to
>> a blockchain network (directly or indirectly through a pool), excepting
>> Bitcoin "testnet" or analogous systems where the tokens are agreed to be
>> worthless, it is considered to be for profit.
>>
>
> Simpler definition: no cryptocurrency, nft, blockchain or bitcoin.
>
> Careful with that:  strictly, Git uses a blockchain structure to store
> revision history.  (Each repository has its own independent set of
> interwoven blockchains.  Each commit is a "block".)
>

Nobody is going to think Git couldn't be tested. It doesn't need to be a
legally watertight definition. The cfarm has no legal obligation to provide
services to anybody, and discriminating against some cryptocurrency project
is fine because being a crypto-bro is not a legally protected
characteristic.

Limiting that to "no cryptocurrency, including NFTs" might work better.
> (No one can credibly argue that Bitcoin is not included in
> "cryptocurrency".)
>

Somebody has already tried to argue that on this mailing list!



In other words, claiming a block reward is "profit" and forbidden on the
>> cfarm.  Your access to the cfarm is gratis, you are not allowed to use
>> it to directly acquire "money" in the form of cryptocurrency tokens.
>>
>> An accidental submission can be remedied by burning any tokens
>> received.  (For Bitcoin, "send them to Satoshi", although that cannot
>> happen because you were testing on "testnet" where the tokens are
>> worthless, right?)
>>
>> Another option could be to use a provably invalid address for "miner"
>> testing, so any rewards received will go nowhere, which amounts to
>> burning the tokens.
>>
>
> Maybe for would be reasonable rules for a server farm available for
> testing cryptocurrency tech. But the cfarm is not such a resource, so
> doesn't need to come up with any such rules. It seems like a waste of time
> trying to craft such rules, just say "find somewhere else to do this".
>
> According to <URL:https://gcc.gnu.org/wiki/CompileFarm>
> <https://gcc.gnu.org/wiki/CompileFarm> referenced from
> <URL:https://portal.cfarm.net/> <https://portal.cfarm.net/>:
>
> The GCC Compile farm project maintains a set of machines of various
> architectures and provides ssh access to Free Software developers, GCC and
> others (GPL, BSD, MIT, ...) to build, test and debug Free, Libre and Open
> Source Software. It is *not* a free cluster for computationally intensive
> computing using Free Software.
>
> Cryptocurrency software (at least any credible system) falls under "Free,
> Libre and Open Source Software".  Cryptocurrency "mining" *definitely*
> falls under "computationally intensive computing using Free Software".
>
> So we are in a position where we need to define boundaries on this issue.
> If we can develop conventions and/or infrastructure that can also be
> applied to more-important uses, then so much the better.
>
>
> -- Jacob
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tetaneutral.net/pipermail/cfarm-users/attachments/20250103/c2ce93cf/attachment.htm>