On 1/2/25 03:43, Jonathan Wakely wrote:
On Thu, 2 Jan 2025, 02:55 Jacob Bachmeyer via cfarm-users,
<cfarm-users@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.
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.
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.
[...]
>> 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".)
Limiting that to "no cryptocurrency, including NFTs" might work better.
(No one can credibly argue that Bitcoin is not included in
"cryptocurrency".)
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> referenced from
<URL: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
_______________________________________________
cfarm-users mailing list
cfarm-users@lists.tetaneutral.net
https://lists.tetaneutral.net/listinfo/cfarm-users
