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

[Jonathan Wakely]

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.


> 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.


> 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?


> In fact, for regression tests, you would /need/ that past tip of the
> blockchain and transaction buffer state in order to make the test
> repeatable.  You could also artificially lower the block difficulty to
> run the test faster.
>

Or ban it.


> For performance tests, ulimit(1) can be used to limit each run to a
> fixed amount of CPU time, with optimization measured in progress made
> before SIGXCPU is received.
>
> >> 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.


> 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".




> There should be viable solutions here, solutions that also scale to less
> controversial uses such as CI or automated snapshot builds, which could
> then be run with priorities below interactive users but above "miner"
> tests.
>
>
> -- Jacob
>
> _______________________________________________
> cfarm-users mailing list
> cfarm-users at lists.tetaneutral.net
> https://lists.tetaneutral.net/listinfo/cfarm-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tetaneutral.net/pipermail/cfarm-users/attachments/20250102/022bd119/attachment-0001.htm>