<div dir="auto"><div><br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, 3 Jan 2025, 01:40 Jacob Bachmeyer, <<a href="mailto:jcb62281@gmail.com">jcb62281@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div>
<div>On 1/2/25 03:43, Jonathan Wakely wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">
<div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, 2 Jan 2025, 02:55
Jacob Bachmeyer via cfarm-users, <<a href="mailto:cfarm-users@lists.tetaneutral.net" target="_blank" rel="noreferrer">cfarm-users@lists.tetaneutral.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On
1/1/25 19:23, Paul Eggert wrote:<br>
> On 2025-01-01 16:32, Jacob Bachmeyer via cfarm-users
wrote:<br>
>> Perhaps a combination of nice(1) and ulimit(1)
would be suitable?<br>
><br>
> Not for mining, no. It would still consume resources
that are better <br>
> used for cfarm's intended purposes.<br>
<br>
The intention is to limit "miner" testing to idle time, or
as close to <br>
that as we can get.<br>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">No, it should be zero time, not just idle time.</div>
</div>
</blockquote>
<p>I have a philosophical view that idle time on servers is
essentially wasted: a sunk cost.</p>
<blockquote type="cite">
<div dir="auto">
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, note that I am suggesting allowing /testing/ "miner"
software, not <br>
/using/ it.<br>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">I suggest banning it entirely. The cfarm has no
obligation to provide resources to miners, even for testing.</div>
</div>
</blockquote>
<p>The idea is for portability tests to less-common architectures.
I admit that that may actually not be something the "miner"
developers care about.</p></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">So a waste of time then</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<blockquote type="cite">
<div dir="auto">
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For testing, it should be possible to set up an
environment with a known <br>
state, instead of using a "live" blockchain, so there is
no need to <br>
actually store the blockchain structure, which I agree
would be an <br>
intolerable waste of disk space.<br>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">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?</div>
</div>
</blockquote>
<p>First, to appropriately minimize the resources used, and prevent
creating perverse incentives to tie the cfarm CPUs in knots.</p></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Or just say it's not allowed. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<p>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.</p></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">It's not a technical problem.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<blockquote type="cite">
<div dir="auto">
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[...]<br>
<br>
>> I would suggest ... making very clear that
"mining" for profit is not <br>
>> permitted<br>
><br>
> That wouldn't suffice, as it's too easy for me to say
that I'm not <br>
> doing something for profit, when I get to define
"profit". (See what <br>
> many US "nonprofits" do.)<br>
<br>
Simple definition: if the results of "miner" "testing"
are submitted to <br>
a blockchain network (directly or indirectly through a
pool), excepting <br>
Bitcoin "testnet" or analogous systems where the tokens
are agreed to be <br>
worthless, it is considered to be for profit.<br>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Simpler definition: no cryptocurrency, nft,
blockchain or bitcoin.</div>
</div>
</blockquote>
<p>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".)</p></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<p>Limiting that to "no cryptocurrency, including NFTs" might work
better. (No one can credibly argue that Bitcoin is not included
in "cryptocurrency".)<br></p></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Somebody has already tried to argue that on this mailing list!</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p>
</p>
<blockquote type="cite">
<div dir="auto">
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In other words, claiming a block reward is "profit" and
forbidden on the <br>
cfarm. Your access to the cfarm is gratis, you are not
allowed to use <br>
it to directly acquire "money" in the form of
cryptocurrency tokens.<br>
<br>
An accidental submission can be remedied by burning any
tokens <br>
received. (For Bitcoin, "send them to Satoshi", although
that cannot <br>
happen because you were testing on "testnet" where the
tokens are <br>
worthless, right?)<br>
<br>
Another option could be to use a provably invalid address
for "miner" <br>
testing, so any rewards received will go nowhere, which
amounts to <br>
burning the tokens.<br>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">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".</div>
</div>
</blockquote>
<p>According to <a href="https://gcc.gnu.org/wiki/CompileFarm" target="_blank" rel="noreferrer"><URL:https://gcc.gnu.org/wiki/CompileFarm></a>
referenced from <a href="https://portal.cfarm.net/" target="_blank" rel="noreferrer"><URL:https://portal.cfarm.net/></a>:<br>
</p>
<blockquote>
<p>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 <em>not</em>
a free cluster for computationally intensive computing using
Free Software. <br>
</p>
</blockquote>
<p>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".</p>
<p>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.</p>
<p><br>
</p>
<p>-- Jacob<br>
</p>
<p><br>
</p>
</div>
</blockquote></div></div></div>