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

[Jacob Bachmeyer]

On 1/3/25 06:20, Jonathan Wakely wrote:
> 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

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.

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.

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

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.

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.

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

Yes, but being clear and precise will help to stop crypto-bros from 
whining---or simply make them look really stupid for whining anyway.

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

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.

Example:  "No cryptocurrency.  NFTs and Bitcoin are considered 
cryptocurrency."

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

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


-- Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tetaneutral.net/pipermail/cfarm-users/attachments/20250103/726e6c8a/attachment-0001.htm>