<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 1/3/25 06:20, Jonathan Wakely wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAH6eHdTZHBh5RoAy8u2mhZN_eiVT-thYoZMfmUicpr6y1irEfQ@mail.gmail.com">
<div dir="auto">
<div>
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">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">
<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" moz-do-not-send="true"
class="moz-txt-link-freetext">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>
</blockquote>
<p>Which is why I am looking for solutions that also give us
conventions for "politely" running other jobs like CI or fuzzing,
so we get /something/ even if the end result is that the cfarm
proves uninteresting for "miner" development.</p>
<p>I doubt that those conventions will need much enforcement, only
consensus to set them and perhaps an autoreniced to take care of
lowering/restoring priorities for detached screens.</p>
<blockquote type="cite"
cite="mid:CAH6eHdTZHBh5RoAy8u2mhZN_eiVT-thYoZMfmUicpr6y1irEfQ@mail.gmail.com">
<div dir="auto">
<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>
</blockquote>
<p>Banning "miners" categorically is one way to eliminate those
perverse incentives, yes. However, having at least considered
other options makes any whining about a ban look that much more
stupid. If less-severe options are infeasible to implement, then
they are infeasible to implement, and banning "miners" is easily
justified.</p>
<p>The problem is that our stated purposes for the cfarm (quoted
below from my earlier message on this thread) can be reasonably
read to include development and testing of "mining" software.<br>
</p>
<blockquote type="cite"
cite="mid:CAH6eHdTZHBh5RoAy8u2mhZN_eiVT-thYoZMfmUicpr6y1irEfQ@mail.gmail.com">
<div dir="auto">
<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>
</blockquote>
<p>Yes, but being clear and precise will help to stop crypto-bros
from whining---or simply make them look really stupid for whining
anyway.<br>
</p>
<blockquote type="cite"
cite="mid:CAH6eHdTZHBh5RoAy8u2mhZN_eiVT-thYoZMfmUicpr6y1irEfQ@mail.gmail.com">
<div dir="auto">
<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>
</blockquote>
<p>I said "credibly" and that same post tried to claim (while
presenting no evidence) that Bitcoin is somehow good for the
environment, despite the massive waste of energy in Bitcoin
"mining". That is not a seriously credible position and we can
easily define cryptocurrency in a way that unquestionably includes
Bitcoin if needed.</p>
<p>Example: "No cryptocurrency. NFTs and Bitcoin are considered
cryptocurrency."</p>
<p>We might have to extend that as people try to claim loopholes.
(I expect that crypto-bros will search for loopholes. They are
annoying that way.)<br>
</p>
<blockquote type="cite"
cite="mid:CAH6eHdTZHBh5RoAy8u2mhZN_eiVT-thYoZMfmUicpr6y1irEfQ@mail.gmail.com">
<div dir="auto">
<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>
</blockquote>
<p>According to <a
href="https://gcc.gnu.org/wiki/CompileFarm"
target="_blank" rel="noreferrer"
moz-do-not-send="true"><URL:https://gcc.gnu.org/wiki/CompileFarm></a>
referenced from <a href="https://portal.cfarm.net/"
target="_blank" rel="noreferrer"
moz-do-not-send="true"><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>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<div dir="auto">
<div dir="auto">
<div class="gmail_quote gmail_quote_container">
<div>
<p>The above was probably the most important part of that
message. I believe that it nicely sums up the issue that
we are dealing with here.</p>
<p><br>
</p>
<p>-- Jacob</p>
</div>
</div>
</div>
</div>
</body>
</html>