unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: Maxime Devos <maximedevos@telenet.be>, guix-devel@gnu.org
Subject: Re: Excessively energy-consuming software considered malware?
Date: Sun, 20 Feb 2022 19:26:53 +0100	[thread overview]
Message-ID: <6985d4705e9b159efbfe0c7ae5cfd7415ada8d51.camel@gmail.com> (raw)
In-Reply-To: <2067ba1e606855eace261fd0b0ae9721b369bbd5.camel@telenet.be>

Hi Maxime,

Am Sonntag, dem 20.02.2022 um 11:05 +0100 schrieb Maxime Devos:
> [CC'ing some people in Guix I know to be interested in cryptocurrency]
> 
> Hi,
> 
> Guix packages some cryptocurrency(*) software (bitcoin, monero, some
> people have been working on packaging ethereum).  So far, it only
> appeared that clients are being packaged.
> 
> More recently, a ‘miner’ for monero has been packaged
> (https://issues.guix.gnu.org/54068).  At least for bitcoin, mining is
> known to consume an absurd amount of energy (the footprint of a whole
> country, and 1 Bitcoin transaction is said to be equivalent to 735121
> Visa transactions)[1].
> 
> Guix has a policy against including malware[citation needed 2], and
> furthering global warming[3] (and energy prices[4], if [3] is not bad
> enough for you) seems rather bad behaviour to me.
> 
> Would these miners be considered malware in Guix?
> 
> TBC I'm not making a case for rejecting all inefficient software, only
> software that is absurdly inefficient by design -- a, say, math
> library not using vectorised operations might be quite a bit less
> inefficient than a math library using vectorised operations, but that
> can be resolved with some programming work and it would seem to pale in
> contrast to the mining situation.
I don't think there's a case that can be made from the FSF's point of
view against wasteful software if the waste is intentional (which is
sadly part of the point of cryptocoins).  

To make my point in a more accessible manner, `guix show stress' yields
(as expected)
--8<---------------cut here---------------start------------->8---
name: stress
version: 1.0.5
outputs: out
systems: x86_64-linux i686-linux
dependencies: autoconf@2.69 automake@1.16.3
location: gnu/packages/admin.scm:2214:2
homepage: https://packages.debian.org/sid/stress
license: GPL 2+
synopsis: Impose load on and stress test a computer system  
description: Stress is a tool that imposes a configurable amount of
CPU, memory, I/O, or disk stress on a
+ POSIX-compliant operating system and reports any errors it detects.
+ 
+ Stress is not a benchmark.  It is a tool used by system
administrators to evaluate how well their systems will scale,
+ by kernel programmers to evaluate perceived performance
characteristics, and by systems programmers to expose the
+ classes of bugs which only or more frequently manifest themselves
when the system is under heavy load.
relevance: 29
--8<---------------cut here---------------end--------------->8---

Cheers


  parent reply	other threads:[~2022-02-20 18:27 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-20 10:05 Excessively energy-consuming software considered malware? Maxime Devos
2022-02-20 10:48 ` Tobias Platen
2022-02-20 11:13   ` Martin Becze
2022-02-20 16:52     ` Maxime Devos
2022-02-20 20:39       ` Martin Becze
2022-02-24  9:23         ` Hartmut Goebel
2022-02-24 11:18           ` Martin Becze
2022-02-25  0:27             ` Christine Lemmer-Webber
2022-02-25 12:41               ` Bengt Richter
2022-02-25 13:04                 ` Tobias Geerinckx-Rice
2022-02-25 16:14                   ` Bengt Richter
2022-02-25 16:32                     ` Ricardo Wurmus
2022-02-25 16:49                     ` Paul Jewell
2022-02-25 17:05                 ` Maxime Devos
2022-02-25 17:35                   ` Taylan Kammer
2022-02-25 19:00                     ` Leo Famulari
2022-04-04  8:00           ` Attila Lendvai
2022-04-04  9:43             ` Maxime Devos
2022-04-04 10:15             ` Maxime Devos
2022-04-04 12:49               ` Attila Lendvai
2022-04-04 10:16             ` Maxime Devos
2022-04-04 10:37             ` Maxime Devos
2022-04-04 11:22             ` indieterminacy
2022-04-04 18:39             ` Liliana Marie Prikler
2022-02-24  9:13       ` Hartmut Goebel
2022-02-24  9:36         ` Attila Lendvai
2022-02-20 11:08 ` Ekaitz Zarraga
2022-02-20 11:27   ` Compiling blender Ricardo Wurmus
2022-02-20 11:34     ` Ekaitz Zarraga
2022-02-20 12:19       ` Faster "guix pull" by incremental compilation and non-circular modules? Maxime Devos
2022-02-20 16:47         ` Philip McGrath
2022-02-20 17:47           ` Semantics of circular imports Maxime Devos
2022-03-27 14:12             ` Philip McGrath
2022-03-27 14:19               ` Maxime Devos
2022-03-27 14:24               ` Maxime Devos
2022-03-27 14:33               ` Maxime Devos
2022-03-27 14:55               ` Maxime Devos
2022-03-28  4:24               ` Zhu Zihao
2022-03-30  4:50                 ` Maxim Cournoyer
2022-02-28 13:17         ` Faster "guix pull" by incremental compilation and non-circular modules? Ludovic Courtès
2022-02-28 18:50           ` Maxime Devos
2022-05-31  4:54             ` Gábor Boskovits
2022-05-31  8:49               ` Maxime Devos
2022-05-31 10:23                 ` Ricardo Wurmus
2022-02-20 15:54       ` Compiling blender Ricardo Wurmus
2022-02-20 16:14         ` Ekaitz Zarraga
2022-02-20 12:20 ` Excessively energy-consuming software considered malware? Taylan Kammer
2022-02-20 12:37   ` Maxime Devos
2022-02-20 12:44     ` Taylan Kammer
2022-02-20 14:59       ` Philip McGrath
2022-02-20 18:53   ` Christine Lemmer-Webber
2022-02-20 20:34   ` Jonathan McHugh
2022-02-20 12:32 ` Paul Jewell
2022-02-20 18:26 ` Liliana Marie Prikler [this message]
2022-02-20 19:36 ` Ryan Sundberg
2022-02-21  9:29 ` Attila Lendvai
2022-02-21 13:06   ` Maxime Devos
2022-02-21 18:56     ` raingloom
2022-02-21 23:02     ` Attila Lendvai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6985d4705e9b159efbfe0c7ae5cfd7415ada8d51.camel@gmail.com \
    --to=liliana.prikler@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=maximedevos@telenet.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).