Excessively energy-consuming software considered malware?

Excessively energy-consuming software considered malware?

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 2135 bytes --]

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

Greetings,
Maxime.

(*) For this e-mail, I'm only considering cryptocurrencies based on
some ‘mining’ system and assuming that monero and ethereum have the
same energy problems as Bitcoin, although possibly with a smaller
constant factor.

[1]: See, e.g.,
https://www.nytimesn7cgmftshazwhfgzm37qxb44r64ytbb2dj3x62d2lljsciiyd.onion/2021/03/09/business/dealbook/bitcoin-climate-change.html
/
https://www.nytimesn7cgmftshazwhfgzm37qxb44r64ytbb2dj3x62d2lljsciiyd.onion/2021/03/09/business/dealbook/bitcoin-climate-change.html

[2]: zero hits when searching for "malware" in the manual!

[3]: I'm sure you can find some sources about destabilising climate
systems, species extinctions, fish getting third-degree burns, island
nations gradually disappearing because of raising sea levels ...

[3]: I'm not sure actually that mining would be (partially) responsible
for increasing energy prices but it seems plausible to me.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Excessively energy-consuming software considered malware?

[Tobias Platen]

Yes, bitcoin could be considered malware. There is GNU Taler which is
more efficent. Unfortunately Taler has not started yet, there is no
working exchange at the moment. 

Tobias

Re: Excessively energy-consuming software considered malware?

[Martin Becze]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

I don't consider mining to be wastefully and this is a extremely 
subjective opinion. It should be a users choose whether or not they want 
to mine. A corner stone of free software is "(0) The freedom to run the 
program as you wish, for whatever purpose." By limiting what is  
accessible to the user based an arbitrary, authoritarian and 
controversial morality goes against the nature of free software.

Martin

On 2/20/22 11:48, Tobias Platen wrote:
> Yes, bitcoin could be considered malware. There is GNU Taler which is
> more efficent. Unfortunately Taler has not started yet, there is no
> working exchange at the moment.
>
> Tobias
>
>

[-- Attachment #2: Type: text/html, Size: 2326 bytes --]

Re: Excessively energy-consuming software considered malware?

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 2897 bytes --]

Martin Becze schreef op zo 20-02-2022 om 12:13 [+0100]:
> I don't consider mining to be wastefully and this is a extremely
> subjective opinion.

What is subjective about the numbers about energy consumption?
Quoting myself:

‘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].’

[1]: See, e.g.,
https://www.nytimesn7cgmftshazwhfgzm37qxb44r64ytbb2dj3x62d2lljsciiyd.onion/2021/03/09/business/dealbook/bitcoin-climate-change.html
/ https://www.nytimesn7cgmftshazwhfgzm37qxb44r64ytbb2dj3x62d2lljsciiyd.onion/2021/03/09/business/dealbook/bitcoin-climate-change.html

(*) the word ‘absurd’ might count as subjective here

Where exactly you draw the line between wasteful and not wasteful
is rather subjective, but the numbers theirselves seem rather objective
to me and wherever the line lies exactly, these numbers seem to be
well over it.

It should be a users choose whether or not they want to mine. A
corner stone of free software is "(0) The freedom to run the
> program as you wish, for whatever purpose." By limiting what is 
> accessible to the user based an arbitrary, authoritarian and
> controversial morality goes against the nature of free software.

Guix refuses to have anything to do with non-free software, banning
it from its repositories.  That seems a bit authoritarian to me.  Some
people would say that's rather arbitrary of Guix.  There's still plenty
of software that is being kept non-free, so I guess that ‘software should
be free’ counts as ‘controversial morality’?

Along the same lines, Guix disabling telemetry and removing Google
Analytics from documentation could count as patronising to upstream.

I suppose that technically, ‘don't mess up the planet’ is ‘controversial
morality’ given the existence of various lobbies etc., but I don't
think we should listen to them; we all live on this planet after all
(unless you're a space alien of course :p) and it's not like we have
any back-ups.

Additionally, from a technical point of view, nothing in Guix is stopping
people from messing up the planet.  If they feel like it, they can
make a package definition and run "guix install -f
produce-lots-of-carbon.scm" or the like, or publish a channel, etc.

While it's the user's choice whether they _want_ to mine or not
(Guix is not a thought police!), it seems inadvisable to _help_ people
with mining and perhaps useful to _stop_ people from mining.
That is, stop people from doing the act, not stopping people from
wanting to mine.  Actually stopping people would be something for the law
and state though, not Guix.

Caveat: there's a risk of descending a slippery slope here, see e.g.
the mail by Taylan Kammer.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Excessively energy-consuming software considered malware?

[Martin Becze]

[-- Attachment #1.1.1: Type: text/plain, Size: 6158 bytes --]

> What is subjective about the numbers about energy consumption?

The numbers are not subjective. As stated later it is the opinion on 
whether it is useful or not that is subjective.

> 1 Bitcoin transaction is said to be equivalent to 735121 Visa transactions
>
This is a bad comparison since it compares two things that are 
different. A bitcoin tx is just an secp256k1 over some input and output 
opcodes. So forming at tx is not energy intensive. Processing a tx 
involves verifying the signature and running the opcodes. So this is 
also not energy intensive. What is energy intensive is PoW. PoW is used 
to achieve consensus on the ordering of tx's and *protects* the ledger 
for being reordered. Visa also ultimately relies on protection by law's 
and enforcement of those laws by governments within who's jurisdiction 
it operates. Bitcoin doesn't have any reliance on protection from the 
state, so it must provide its own protection and it does this through 
PoW. A better comparison would be comparing bitcoin mining to the US 
military expenditures. I would agree that military expenditures are too 
high and war is very bad for the environment. The ability of governments 
to wage massive wars rest on their ability to 1) collect taxes and 2) 
manipulating the supply of money. While it is a long shot, cryptos such 
as bitcoin could be used to prevent or at least make it hard for 
governments to seize crypto assets from the citizens, which could 
ultimate hinder them from raising the capital needed to wage mass war. 
In this context seems to me to be an great use of excess energy.

BTW you can already mine bitcoin and monero with current packages.

> Guix refuses to have anything to do with non-free software, banning
> it from its repositories.  That seems a bit authoritarian to me.  Some
> people would say that's rather arbitrary of Guix.  There's still plenty
> of software that is being kept non-free, so I guess that ‘software should
> be free’ counts as ‘controversial morality’?
Yes I agree, but it is quite clear what to expect from a GNU project. I 
agree with its stance on free software and that is why I use it.  Free 
software doesn't conflict with open source implementation of 
cryptocurrencies. I don't think it is fair to start add rules that ban 
software built with a particular political or ideological view point. It 
would be better to fork and create a new distro founded on your 
political and ideological principles. That way all newcomers could 
choose if participate and agree with the principles, instead of trying 
to force a participial ideological stance onto existing users that 
disagree with them.

> I suppose that technically, ‘don't mess up the planet’ is ‘controversial
> morality’
Once again agree we agree not to mess up the planet. But undermining the 
governments ability to raise tax and therefor to wage war or not 
expending energy to prevent government theft is the ‘controversial 
morality’ that I am sure can be agreed to death and which probably 
doesn't belong on this list.

2/20/22 17:52, Maxime Devos wrote:

> Martin Becze schreef op zo 20-02-2022 om 12:13 [+0100]:
>> I don't consider mining to be wastefully and this is a extremely
>> subjective opinion.
> What is subjective about the numbers about energy consumption?
> Quoting myself:
>
> ‘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].’
>
> [1]: See, e.g.,
> https://www.nytimesn7cgmftshazwhfgzm37qxb44r64ytbb2dj3x62d2lljsciiyd.onion/2021/03/09/business/dealbook/bitcoin-climate-change.html
> / https://www.nytimesn7cgmftshazwhfgzm37qxb44r64ytbb2dj3x62d2lljsciiyd.onion/2021/03/09/business/dealbook/bitcoin-climate-change.html
>
> (*) the word ‘absurd’ might count as subjective here
>
> Where exactly you draw the line between wasteful and not wasteful
> is rather subjective, but the numbers theirselves seem rather objective
> to me and wherever the line lies exactly, these numbers seem to be
> well over it.
>
> It should be a users choose whether or not they want to mine. A
> corner stone of free software is "(0) The freedom to run the
>> program as you wish, for whatever purpose." By limiting what is
>> accessible to the user based an arbitrary, authoritarian and
>> controversial morality goes against the nature of free software.
> Guix refuses to have anything to do with non-free software, banning
> it from its repositories.  That seems a bit authoritarian to me.  Some
> people would say that's rather arbitrary of Guix.  There's still plenty
> of software that is being kept non-free, so I guess that ‘software should
> be free’ counts as ‘controversial morality’?
>
> Along the same lines, Guix disabling telemetry and removing Google
> Analytics from documentation could count as patronising to upstream.
>
> I suppose that technically, ‘don't mess up the planet’ is ‘controversial
> morality’ given the existence of various lobbies etc., but I don't
> think we should listen to them; we all live on this planet after all
> (unless you're a space alien of course :p) and it's not like we have
> any back-ups.
>
> Additionally, from a technical point of view, nothing in Guix is stopping
> people from messing up the planet.  If they feel like it, they can
> make a package definition and run "guix install -f
> produce-lots-of-carbon.scm" or the like, or publish a channel, etc.
>
> While it's the user's choice whether they _want_ to mine or not
> (Guix is not a thought police!), it seems inadvisable to _help_ people
> with mining and perhaps useful to _stop_ people from mining.
> That is, stop people from doing the act, not stopping people from
> wanting to mine.  Actually stopping people would be something for the law
> and state though, not Guix.
>
> Caveat: there's a risk of descending a slippery slope here, see e.g.
> the mail by Taylan Kammer.
>
> Greetings,
> Maxime.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 2469 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 665 bytes --]

Re: Excessively energy-consuming software considered malware?

[Hartmut Goebel]

CW: politics below

Am 20.02.22 um 21:39 schrieb Martin Becze:
> But undermining the governments ability to raise tax and therefor to 
> wage war or not expending energy to prevent government theft is the 
> ‘controversial morality’ that I am sure can be agreed to death and 
> which probably doesn't belong on this list. 

Undermining the governments ability to raise tax also means undermining 
the ability to build schools, kindergartens, public libraries, public 
transport, streets, etc. Who is going to pay and provide all of this, If 
there is no democratically controlled(*) government?

You might argument that this will then be paid be wealthy people - but 
the country will depend solely on their will and want. And these wealthy 
people are not controlled at all. And these people might wage war, too. 
We already had such a system in the medieval time. It:s called feudalism.

So nothing is won by undermining the government.

(*) Democratic control still needs a lot of improvement. Esp. in the USA 
where „the winner takes it all“ results in a two-party system, which 
does not represent the people. But this is another issue.


-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Excessively energy-consuming software considered malware?

[Martin Becze]

[-- Attachment #1.1.1: Type: text/plain, Size: 2258 bytes --]

My point to here is not to argue a "libertarian" viewpoint (I'm not 
one), but to argue that there or other consideration to mining crypto 
and that it is outside the realm of the free software movement from 
which Guix's package inclusion policy is derived. You or I might not 
like or agree with the over viewpoints but that should be fine with in 
the context of free software and operating systems. This is also 
foundational to liberalism and having a functional government in the 
first place.

> Who is going to pay and provide all of this
I personal think it would be wonderful if governments focused on 
providing those things and mechanism such as the harbinger tax could be 
great and removing control of the monetary supply from the state would 
greatly reduce its ability to fund military expenditures. For reference 
David graeber's Debt: The First 5000 Years is an interesting narrative 
of how money's evolution was impart driven by the waging of mass war.

On 2/24/22 10:23, Hartmut Goebel wrote:

> CW: politics below
>
> Am 20.02.22 um 21:39 schrieb Martin Becze:
>> But undermining the governments ability to raise tax and therefor to 
>> wage war or not expending energy to prevent government theft is the 
>> ‘controversial morality’ that I am sure can be agreed to death and 
>> which probably doesn't belong on this list. 
>
> Undermining the governments ability to raise tax also means 
> undermining the ability to build schools, kindergartens, public 
> libraries, public transport, streets, etc. Who is going to pay and 
> provide all of this, If there is no democratically controlled(*) 
> government?
>
> You might argument that this will then be paid be wealthy people - but 
> the country will depend solely on their will and want. And these 
> wealthy people are not controlled at all. And these people might wage 
> war, too. We already had such a system in the medieval time. It:s 
> called feudalism.
>
> So nothing is won by undermining the government.
>
> (*) Democratic control still needs a lot of improvement. Esp. in the 
> USA where „the winner takes it all“ results in a two-party system, 
> which does not represent the people. But this is another issue.
>
>

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 2469 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 665 bytes --]

Re: Excessively energy-consuming software considered malware?

[Christine Lemmer-Webber]

I am all for these conversations; they are good to have as a society, to
examine our social foundations in earnest dialogue.  But I think they've
approached a point on here where they're no longer about Guix
development, in particular, so probably should be moved off-list.

Martin Becze <martin@becze.org> writes:

> [[PGP Signed Part:Undecided]]
> My point to here is not to argue a "libertarian" viewpoint (I'm not
> one), but to argue that there or other consideration to mining crypto 
> and that it is outside the realm of the free software movement from
> which Guix's package inclusion policy is derived. You or I might not 
> like or agree with the over viewpoints but that should be fine with in
> the context of free software and operating systems. This is also 
> foundational to liberalism and having a functional government in the
> first place.
>
>> Who is going to pay and provide all of this
> I personal think it would be wonderful if governments focused on
> providing those things and mechanism such as the harbinger tax could
> be great and removing control of the monetary supply from the state
> would greatly reduce its ability to fund military expenditures. For
> reference David graeber's Debt: The First 5000 Years is an interesting
> narrative of how money's evolution was impart driven by the waging of
> mass war.
>
> On 2/24/22 10:23, Hartmut Goebel wrote:
>
>> CW: politics below
>>
>> Am 20.02.22 um 21:39 schrieb Martin Becze:
>>> But undermining the governments ability to raise tax and therefor
>>> to wage war or not expending energy to prevent government theft is
>>> the ‘controversial morality’ that I am sure can be agreed to death
>>> and which probably doesn't belong on this list. 
>>
>> Undermining the governments ability to raise tax also means
>> undermining the ability to build schools, kindergartens, public 
>> libraries, public transport, streets, etc. Who is going to pay and
>> provide all of this, If there is no democratically controlled(*) 
>> government?
>>
>> You might argument that this will then be paid be wealthy people -
>> but the country will depend solely on their will and want. And these 
>> wealthy people are not controlled at all. And these people might
>> wage war, too. We already had such a system in the medieval
>> time. It:s called feudalism.
>>
>> So nothing is won by undermining the government.
>>
>> (*) Democratic control still needs a lot of improvement. Esp. in the
>> USA where „the winner takes it all“ results in a two-party system, 
>> which does not represent the people. But this is another issue.
>>
>>
>
> [2. OpenPGP public key --- application/pgp-keys; OpenPGP_0xB97E95F9DED5755D.asc]...
>
> [[End of PGP Signed Part]]

Re: Excessively energy-consuming software considered malware?

[Bengt Richter]

On +2022-02-24 19:27:37 -0500, Christine Lemmer-Webber wrote:
> I am all for these conversations; they are good to have as a society, to
> examine our social foundations in earnest dialogue.  But I think they've
> approached a point on here where they're no longer about Guix
> development, in particular, so probably should be moved off-list.
>

WDYT of starting a list called "guix-off-list" to provide a
place for those who enjoy this kind of discussion?

I do enjoy such discussions sometimes, but not on the same
plate as debug tracebacks or beautiful code examples from
the virtuosos.

I don't mind single-line BTW or FYI or IMO: footnote
references to out-of-thread content if the rest of the post
contributes something and isn't just one line in a full 
quote.

Having a "guix-offlist" would enable a reference like
"IMO:guix-offlist: bitcoin explained by me ;)"

And maybe also a mailing list called "guix-grownups" --
where casual adult language is accepted without triggering
endless complaints.

Coming to some mailing lists these days I sometimes feel
like I've entered a restaurant where the menu is dominated
by allergy and spice concerns.

(I have nothing againt special venues catering to sensitive
minorities, don't get me wrong. What do I mean "minorities" eh? :)

Wonder what George Carlin (R.I.P) would say about all this
:)

-- 
Regards,
Bengt Richter

Re: Excessively energy-consuming software considered malware?

[Tobias Geerinckx-Rice]

On 2022-02-25 13:41, Bengt Richter wrote:
> And maybe also a mailing list called "guix-grownups" --
> where casual adult language is accepted without triggering
> endless complaints.

This is guix-grownups, although we accept grown-ups of all ages.

Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

Re: Excessively energy-consuming software considered malware?

[Bengt Richter]

On +2022-02-25 14:04:34 +0100, Tobias Geerinckx-Rice wrote:
> On 2022-02-25 13:41, Bengt Richter wrote:
> > And maybe also a mailing list called "guix-grownups" --
> > where casual adult language is accepted without triggering
> > endless complaints.
> 
> This is guix-grownups, although we accept grown-ups of all ages.
>

Glad to hear it :)

But the serious part of my post was

--8<---------------cut here---------------start------------->8---
WDYT of starting a list called "guix-off-list" to provide a
place for those who enjoy this kind of discussion?

I do enjoy such discussions sometimes, but not on the same
plate as debug tracebacks or beautiful code examples from
the virtuosos.

I don't mind single-line BTW or FYI or IMO: footnote
references to out-of-thread content if the rest of the post
contributes something and isn't just one line in a full 
quote.

Having a "guix-offlist" would enable a reference like
"IMO:guix-offlist: bitcoin explained by me ;)"
--8<---------------cut here---------------end--------------->8---

The idea being to help factor off-topic discussion out of threads
without interfering with people's desire to follow up with
interesting ideas. Or not-so-interesting ideas :)

Thoughts?

> Kind regards,
> 
> T G-R
> 
> Sent from a Web browser.  Excuse or enjoy my brevity.

-- 
Regards,
Bengt Richter

Re: Excessively energy-consuming software considered malware?

[Ricardo Wurmus]

Bengt Richter <bokr@bokr.com> writes:

> WDYT of starting a list called "guix-off-list" to provide a
> place for those who enjoy this kind of discussion?

Not as part of the project.  So if you want a list like that, please
maintain it by yourself.

-- 
Ricardo

Re: Excessively energy-consuming software considered malware?

[Paul Jewell]

On 25/02/2022 16:14, Bengt Richter wrote:
> On +2022-02-25 14:04:34 +0100, Tobias Geerinckx-Rice wrote:
>> On 2022-02-25 13:41, Bengt Richter wrote:
>>> And maybe also a mailing list called "guix-grownups" --
>>> where casual adult language is accepted without triggering
>>> endless complaints.
>> This is guix-grownups, although we accept grown-ups of all ages.
>>
> Glad to hear it :)
>
> But the serious part of my post was
>
> --8<---------------cut here---------------start------------->8---
> WDYT of starting a list called "guix-off-list" to provide a
> place for those who enjoy this kind of discussion?
>
> I do enjoy such discussions sometimes, but not on the same
> plate as debug tracebacks or beautiful code examples from
> the virtuosos.
>
> I don't mind single-line BTW or FYI or IMO: footnote
> references to out-of-thread content if the rest of the post
> contributes something and isn't just one line in a full
> quote.
>
> Having a "guix-offlist" would enable a reference like
> "IMO:guix-offlist: bitcoin explained by me ;)"
> --8<---------------cut here---------------end--------------->8---
>
> The idea being to help factor off-topic discussion out of threads
> without interfering with people's desire to follow up with
> interesting ideas. Or not-so-interesting ideas :)
>
> Thoughts?
>
>> Kind regards,
>>
>> T G-R
>>
>> Sent from a Web browser.  Excuse or enjoy my brevity.

I think it would be a good idea. There have been a couple of threads 
recently which have taken a lot bandwidth in the main lists where the 
topics have been interesting, but perhaps not on topic for the group.

Re: Excessively energy-consuming software considered malware?

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 3983 bytes --]

Bengt Richter schreef op vr 25-02-2022 om 13:41 [+0100]:
> On +2022-02-24 19:27:37 -0500, Christine Lemmer-Webber wrote:
> > I am all for these conversations; they are good to have as a society, to
> > examine our social foundations in earnest dialogue.  But I think they've
> > approached a point on here where they're no longer about Guix
> > development, in particular, so probably should be moved off-list.
> > 
> 
> WDYT of starting a list called "guix-off-list" to provide a
> place for those who enjoy this kind of discussion?

I don't enjoy these discussions much, I only participate in them
(and sometime start them) because they seem necessary.
However, a kind of spin-off list for discussions that start at
guix-devel but became largely off-topic may be useful.

For some context, I sometimes see responses like e.g.

Christine Lemmer-Webber writes
> [...] But I think they've approached a point on here where they're no
> longer about Guix development, in particular, so probably should be
> moved off-list.

but currently there is not a standard way to move it off-list --
do I just put everyone who might be interested in 'To:' and hope that I
didn't include too many/forgot some people?  What if people weren't
initially interested but are later? How to keep archives?

A separate spin-off mailing list might address this (does not have to
be on gnu.org or associated with guix per-se).  It seems like Ricardo
Wurmus wants any such list, if any, to be outside guix itself.  Would
you have an idea for the location?

> And maybe also a mailing list called "guix-grownups" --
> where casual adult language is accepted without triggering
> endless complaints.

What does ‘adult language’ mean here?  Fancy titles (I sometimes
see a few Dr. and $FANCY_WORK_TILE)?  Complicated turns-of-phrase?
I haven't seen any complaints about that though.

Maybe you mean profanity?  Profanity is not limited to adults though,
there are plenty of adults that don't swear at all and plenty of
kids that swear.

And what does ‘casual’ mean here?  Often people just say 'Hi' and use
first names, seems rather casual to me; I haven't seen any complaints
about that so far.

Could you point me at some examples from the mailing list archives to
make things clearer?

The only thing I could think of here as ‘adult language’ would be some
event in the past where some rando accused me of gaslighting,
completely ignoring any explanation I gave previously on why I believe
X is Y.  Seems rather adult-y to me, but not good material for a
mailing list.

> Coming to some mailing lists these days I sometimes feel
> like I've entered a restaurant where the menu is dominated
> by allergy and spice concerns.

There's plenty of food (= patches, discussion about how to implement X,
etc.) on guix-devel.  I don't see the analogy, how could one be
allergic to patches?

> (I have nothing againt special venues catering to sensitive
> minorities, don't get me wrong. What do I mean "minorities" eh? :)

I don't know what you mean with ‘What do I mean "minorities" eh? :)’.
Also, I don't see the relationship between these paragraphs:

> And maybe also a mailing list called "guix-grownups" --
> where casual adult language is accepted without triggering
> endless complaints.
> [...]
> [... some analogy between mailing lists and allergy information at
> restaurants? ...]
> I have nothing againt special venues catering to sensitive minorities
> [...]

What does not excluding people from minorities from going to
restaurants and mailing lists have to do with the proposed guix-
grownups?  I'm pretty sure that adults don't form a minority,
and I'd hope that grownups aren't either.

(After this mail, I'll stop CC'ing guix-devel@gnu.org except perhaps
to say where the new mailing list, if any, is/will be, feel free to CC
me. Otherwise, I think we could keep going.)

Greetings,
Maxime

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Excessively energy-consuming software considered malware?

[Taylan Kammer]

On 25.02.2022 18:05, Maxime Devos wrote:
> 
> A separate spin-off mailing list might address this (does not have to
> be on gnu.org or associated with guix per-se).  It seems like Ricardo
> Wurmus wants any such list, if any, to be outside guix itself.  Would
> you have an idea for the location?
> 

There's a gnu-misc-discuss mailing list which seems to be used for topics
that are only tangentially on-topic.  It might be a candidate.  Though it
has some... well, trolls IMO, though I won't name names.  So maybe it's
not the best place.  Just throwing it out there.

https://lists.gnu.org/archive/html/gnu-misc-discuss/

-- 
Taylan

Re: Excessively energy-consuming software considered malware?

[Leo Famulari]

On Fri, Feb 25, 2022 at 06:35:19PM +0100, Taylan Kammer wrote:
> There's a gnu-misc-discuss mailing list which seems to be used for topics
> that are only tangentially on-topic.  It might be a candidate.  Though it
> has some... well, trolls IMO, though I won't name names.  So maybe it's
> not the best place.  Just throwing it out there.
> 
> https://lists.gnu.org/archive/html/gnu-misc-discuss/

That list is a bad place because it's where all the bad conversations go
--- tautological.

If Guix were to set up a similar list, we'd end up hosting something
just as bad, and to outsiders, it would reflect poorly on Guix. Just
like gnu-misc-discuss makes GNU look awful to outsiders.

It won't benefit Guix to have a mailing list dedicated to off-topic
tangents. We should strive to maintain an atmosphere that is focused,
courteous, and collegial.

There *is* a Guix community, but Guix is not a community space, or a
place to live. It's a software project.

On the topic of cryptomining and its inclusion in the distro, there have
always been programs that people think should not be distributed. The
problem is that there's no consensus about which programs are beyond the
pale.

Re: Excessively energy-consuming software considered malware?

[Attila Lendvai]

hi Hartmut and Martin,

i have just found this draft email, and i'm sending it to you two directly in the hope that you will find these thoughts useful/interesting, but i don't want to further annoy the mailing list with this topic.


> Undermining the governments ability to raise tax also means undermining
> the ability to build schools, kindergartens, public libraries, public
> transport, streets, etc. Who is going to pay and provide all of this, If
> there is no democratically controlled() government?


there's plenty of past examples of financing these things without the government collecting the necessary funds. also, these things are only a tiny fraction of the government's budget.

if you want to dig deeper, then a book titled 'The Machinery of Freedom' discusses the various alternative forms of financing in more detail (http://daviddfriedman.com/#mybooks).


> You might argument that this will then be paid be wealthy people - but


the vast majority of the taxes are not taken from the wealthy, but from the masses. the well-connected easily pays for the marginal cost of the tax consultants, lawyers, judges, offshore entities, and whatnot... and ultimately buy/corrupt the entire political system.

and especially so for inflation, which is straight out a tax that siphons the purchasing power from people who hold cash equivalents (i.e. the poor), to the people who own assets (i.e. the wealthy)... who are also closer to the source of new money, and therefore spend it first on the market, when it has not yet elevated the prices. see the Cantillon effect: https://en.wikipedia.org/wiki/Richard_Cantillon#Monetary_theory

which here reminds me of:

“In a just society, it is shameful to be poor. In a corrupt society, it is shameful to be rich.”
	— Confucius (551–479 BC), 'The Analects', Chapter VIII, paraphrased

this is the original:

“When a country is well governed, poverty and a mean condition are things to be ashamed of. When a country is ill governed, riches and honor are things to be ashamed of.”
%	— Confucius (551–479 BC), 'The Analects', Chapter VIII (邦有道貧且賤焉恥也，邦無道富且貴焉恥也。)

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“And the day came when the risk to remain tight in a bud was more painful than the risk it took to blossom.”
	— Anaïs Nin (1903–1977)

Re: Excessively energy-consuming software considered malware?

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]

Attila Lendvai schreef op ma 04-04-2022 om 08:00 [+0000]:
> > Undermining the governments ability to raise tax also means
> > undermining
> > the ability to build schools, kindergartens, public libraries,
> > public
> > transport, streets, etc. Who is going to pay and provide all of
> > this, If
> > there is no democratically controlled() government?
> 
> 
> [...] also, these things are only a tiny fraction of the
> government's budget.

In the Netherlands, these things appear to be a large fraction of the
government budget [0].  E.g.

* Education, culture and science:  44.3/353 = 12%
* ‘Zorg’ (= public hospitals but also other related things):  93.0/353 = 26%
* Infrastructure and ‘waterstaat’: 10.3/353: 2.9%
* ‘Sociale zekerheid’: 94.6/353=27%

That's 67.9%, which seems like a large fraction to me.

[0] https://www.rijksoverheid.nl/documenten/brochures/2021/09/21/miljoenennotaposter-2022

Greetings,
MMaxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Excessively energy-consuming software considered malware?

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]

Attila Lendvai schreef op ma 04-04-2022 om 08:00 [+0000]:
> > Undermining the governments ability to raise tax also means
> > undermining
> > the ability to build schools, kindergartens, public libraries,
> > public
> > transport, streets, etc. Who is going to pay and provide all of
> > this, If
> > there is no democratically controlled() government?
> 
> 
> there's plenty of past examples of financing these things without the
> government collecting the necessary funds.

Here's an example I know of:

  * Education.  From what I have heard, students in the UK have to pay
    huge sums to be admitted to their universities.  In Belgium, it's
    much lower (e.g. € 1000 a year(*)), AFAIK it's independent of
    the ‘status’ of the university and some arrangements are made
    for people that cannot afford the normal tarif.

    IIUC, the relatively low tarif is mostly thanks to government
    funding and the (public) universities not being for-profits.

    I think I prefer the government funding here above the seemingly
    non-existent private benefactors.

(*) with some caveats, e.g. depends on the number of ‘studiepunten’
(ECTS) and IIUC there if you fail too much the university can refuse
to admit you or demand a higher tarif.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Excessively energy-consuming software considered malware?

[Attila Lendvai]

my apologies for reviving this thread! i did not inted to, i have just failed to remove the mailing list address.

in that spirit i'll refrain from further commenting on guix-devel, and i encourage others also to stay on topic.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Freedom is strangely ephemeral. It is something like breathing; one only becomes acutely aware of its importance when one is choking.”
	— William E. Simon

Re: Excessively energy-consuming software considered malware?

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 329 bytes --]

Attila Lendvai schreef op ma 04-04-2022 om 08:00 [+0000]:
> if you want to dig deeper, then a book titled 'The Machinery of Freedom' discusses the various alternative forms of financing in more detail (http://daviddfriedman.com/#mybooks).
> 

I get a:

  403 Forbidden
  openresty

for that URL.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Excessively energy-consuming software considered malware?

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1467 bytes --]

Attila Lendvai schreef op ma 04-04-2022 om 08:00 [+0000]:
> the vast majority of the taxes are not taken from the wealthy,
> but from the masses. the well-connected easily pays for the
> marginal cost of the tax consultants, lawyers, judges, offshore
> entities, and whatnot... and ultimately buy/corrupt the entire
> political system.

If these wealthy evade taxes, wouln't they, after a transition from
public funding to private funding, just keep hoarding the money for
theirselves and not fund anything?  I don't see how eliminating taxes
here would make these corrupt wealthy more likely to pay taxes/fund
things.

If it's all private, no mechanism remains to extract money from these
wealthy.  If it's public, then even if it's partially corrupt, at least
a portion of their wealth would be extracted.

Additionally, there are efforts underway to at least in-part eliminate
off-shore constructions and other tax evasion schemes.  E.g., I forgot
the name, but there was some proposal for a world-wide lower bound on a
certain kind of tax.  And in e.g. Belgium there's a ‘Dienst Bijzondere
Belastingsinspectie’ dedicated to ‘structured combat against fraud’,
and the ‘Federale Overheidsdiensten Financiën’ apparently has recovered
€110,69 * 10^9 in 2020 [0] (or maybe 2019-2020, these reports appear to
be made every two years).

Greetings,
Maxime.

[0] https://www.2020.jaarverslag.financien.belgium.be/index-nl.html

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Excessively energy-consuming software considered malware?

[indieterminacy]

Attila Lendvai <attila@lendvai.name> writes:

>
> and especially so for inflation, which is straight out a tax that
> siphons the purchasing power from people who hold cash equivalents
> (i.e. the poor), to the people who own assets (i.e. the
> wealthy)... who are also closer to the source of new money, and
> therefore spend it first on the market, when it has not yet elevated
> the prices. see the Cantillon effect:
> https://en.wikipedia.org/wiki/Richard_Cantillon#Monetary_theory
>

With respect, please dont justify philosophies of restrictive supply
when writing on technichal forums predicated on ideals of non rivalrous behaviour.

Otherwise, I enjoyed the post :)


Jonathan

Re: Excessively energy-consuming software considered malware?

[Liliana Marie Prikler]

Am Montag, dem 04.04.2022 um 08:00 +0000 schrieb Attila Lendvai:
> There's plenty of past examples of financing these things without the
> government collecting the necessary funds. also, these things are
> only a tiny fraction of the government's budget.
Name one.  If you want to appeal to charity, consider that charity has
not yet solved world hunger despite the fact that it'd be very possible
to do so.  Then again, neither have taxes, so there's more than just
that at play here, but generally speaking taxing the rich (or eating
them when they no longer want to be taxed) sounds like a better
solution than waiting for them to give up their fortunes willingly.

> 
> The vast majority of the taxes are not taken from the wealthy, but
> from the masses. the well-connected easily pays for the marginal cost
> of the tax consultants, lawyers, judges, offshore entities, and
> whatnot... and ultimately buy/corrupt the entire political system.
You complain about taxes, but have you considered that the largest
theft is in fact wage theft?  The state only takes a comparatively
small cut with respect to your boss or your landlord.

> and especially so for inflation, which is straight out a tax that
> siphons the purchasing power from people who hold cash equivalents
> (i.e. the poor), to the people who own assets (i.e. the wealthy)...
> who are also closer to the source of new money, and therefore spend
> it first on the market, when it has not yet elevated the prices. see
> the Cantillon effect:
> https://en.wikipedia.org/wiki/Richard_Cantillon#Monetary_theory
Apart from inflation not being a tax, you are right in that money tends
to concentrate around those who already have it.  If only there was
some 19th century German philosopher who described that in more
detail...

> which here reminds me of:
> 
> “In a just society, it is shameful to be poor. In a corrupt society,
> it is shameful to be rich.”
>         — Confucius (551–479 BC), 'The Analects', Chapter VIII,
> paraphrased
> 
> this is the original:
> 
> “When a country is well governed, poverty and a mean condition are
> things to be ashamed of. When a country is ill governed, riches and
> honor are things to be ashamed of.”
> %       — Confucius (551–479 BC), 'The Analects', Chapter VIII
> (邦有道貧且賤焉恥也，邦無道富且貴焉恥也。)
Perhaps this holds in societies that have not reached overproduction,
but what it should say in modern times, is that in a just society there
exists no poverty.

Even then, shame is a social construct largely indoctrinated into us by
the ruling class, so if you find yourself seeing poor people as
shameful, that is just capitalist propaganda doing its job.

In any case, bitcoin is the solution to none of those problems and a
major contributor towards climate change.  While there might be a
consensus among capitalist countries that bitcoin removes you, in
communist Guix we remove bitcoin.

Cheers

Re: Excessively energy-consuming software considered malware?

[Hartmut Goebel]

Am 20.02.22 um 17:52 schrieb Maxime Devos:
> While it's the user's choice whether they_want_  to mine or not
> (Guix is not a thought police!), it seems inadvisable to_help_  people
> with mining and perhaps useful to_stop_  people from mining.

+1

Since we are technicians, we have to take your share of responsibility 
to save our planet. (Much like we want planet-savers to respect the 
human right to privacy.)

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Excessively energy-consuming software considered malware?

[Attila Lendvai]

i'm not sure everybody is aware in this discussion: mining Bitcoin is only profitable using special hardware, and nowadays it needs to be deployed next to powerplants and oil wells to use their waste energy/gas, or next to renewable sources like geothermal.

the standard bitcoin tools are not relevant for mining.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“There are three kinds of lies: lies, damned lies, and statistics.”
	— probably Mark Twain (1835-1910)

Re: Excessively energy-consuming software considered malware?

[Ekaitz Zarraga]

Note the joke here but:

Yesterday I spent like 6 hours trying to install a package (blender).

My Guix system compiled tons of rust modules, texlive, inkscape, gtk+ more than one time, qt aaaand finally blender.

All that with my CPU to 100%.

Is Guix malware?

Cheers,
Ekaitz

Compiling blender

[Ricardo Wurmus]

Ekaitz Zarraga <ekaitz@elenq.tech> writes:

> Yesterday I spent like 6 hours trying to install a package (blender).
>
> My Guix system compiled tons of rust modules, texlive, inkscape, gtk+ more than one time, qt aaaand finally blender.

On purpose?  We have binaries for blender:

   https://ci.guix.gnu.org/search?query=blender

-- 
Ricardo

PS: I don’t take the bait :)

Re: Compiling blender

[Ekaitz Zarraga]

> On purpose? We have binaries for blender:
>
> https://ci.guix.gnu.org/search?query=blender
>

I was updating mesa, see #54066.

> PS: I don’t take the bait :)

But think about it, that makes Guix unusable when running
on battery for instance. Making a Guix pull is unpredictable too...

I understand your point with Bitcoin, and I agree to certain
extent, but I think it's too strict thinking.

Malware is software that does bad things that are not expected by
the user. Bitcoin is supposed to act like that, so that's ok imho.

Also, anyone can use any software in a very inefficient way... IDK

It just feels like too much in my opinion.

Faster "guix pull" by incremental compilation and non-circular modules?

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1213 bytes --]

Ekaitz Zarraga schreef op zo 20-02-2022 om 11:34 [+0000]:
> Making a Guix pull is unpredictable too...

An idea for making "guix pull" faster:

  1. Make package imports non-circular, breaking up package modules
     in parts when necessary.

  2. Instead of building all of Guix as a single derivation,
     create a DAG of derivations.  More concretely:

     First read the *.scm files to determine which module imports
     which modules. Then to compile, say, (gnu packages acl),
     a derivation taking gnu/packages/acl.scm and its dependencies
     gnu/packages/attr.go, gnu/packages/base.go, ... is made
     compiling gnu/packages/acl.scm to a gnu/packages/acl.go.

     Then to build all of Guix, 'union-build' or 'file-union' is used.

The benefit is that if, say, gnu/packages/gnunet.scm is changed, then
the old gnu/packages/acl.go will be reused because its derivation
doesn't depend on gnu/packages/gnunet.scm (*).

The need for non-circular imports can be avoided by computing the
strongly-connected components and compiling all the modules in a
component as a single unit.

Greetings,
Maxime.

(*) Actually I didn't verify if acl.scm depends on gnunet.scm or not.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Faster "guix pull" by incremental compilation and non-circular modules?

[Philip McGrath]

[-- Attachment #1: Type: text/plain, Size: 7074 bytes --]

Hi,

On Sunday, February 20, 2022 7:19:07 AM EST Maxime Devos wrote:
> Ekaitz Zarraga schreef op zo 20-02-2022 om 11:34 [+0000]:
> > Making a Guix pull is unpredictable too...
> 
> An idea for making "guix pull" faster:
> 
>   1. Make package imports non-circular, breaking up package modules
>      in parts when necessary.
> 
>   2. Instead of building all of Guix as a single derivation,
>      create a DAG of derivations.  More concretely:
> 
>      First read the *.scm files to determine which module imports
>      which modules. Then to compile, say, (gnu packages acl),
>      a derivation taking gnu/packages/acl.scm and its dependencies
>      gnu/packages/attr.go, gnu/packages/base.go, ... is made
>      compiling gnu/packages/acl.scm to a gnu/packages/acl.go.
> 
>      Then to build all of Guix, 'union-build' or 'file-union' is used.
> 
> The benefit is that if, say, gnu/packages/gnunet.scm is changed, then
> the old gnu/packages/acl.go will be reused because its derivation
> doesn't depend on gnu/packages/gnunet.scm (*).
> 
> The need for non-circular imports can be avoided by computing the
> strongly-connected components and compiling all the modules in a
> component as a single unit.
> 
> Greetings,
> Maxime.
> 
> (*) Actually I didn't verify if acl.scm depends on gnunet.scm or not.

I was just (or maybe am still?) dealing with some issues caused by cyclic
imports of package modules while updating Racket to 8.4: see in particular
<https://issues.guix.gnu.org/53878#93>, as well as #66, #112, and #113 in the
same thread.

As I mentioned there, I am most familiar with the semantics of Racket
modules,[1][2][3][4][5][6] and secondarily with R6RS libraries.[7]

I find the semantics of Guile's cyclic module imports very confusing, and I
don't know of any documentation for what is and isn't supported other
than advice from Ludo’ in <https://issues.guix.gnu.org/48682#7>—is there any?

Racket's module system fundamentally requires that module imports for a DAG
(see footnote 1 in § 2.2 of [1]), which is necessary to provide “The Separate
Compilation Guarantee”[1][6]:

> Any effects of the instantiation of the module’s phase 1 due to compilation
> on the Racket runtime system are discarded.

This is an extremely useful property, especially if you care about
reproducibility.

I know that R6RS does not provide The Separate Compilation Guarantee, since
§ 7.2 [8] explicitly says:

> An implementation may distinguish instances/visits of a library for
> different phases or to use an instance/visit at any phase as an
> instance/visit at any other phase. An implementation may further expand
> each library form with distinct visits of libraries in any phase and/or
> instances of libraries in phases above 0. An implementation may create
> instances/visits of more libraries at more phases than required to satisfy
> references. When an identifier appears as an expression in a phase that is
> inconsistent with the identifier's level, then an implementation may raise
> an exception either at expand time or run time, or it may allow the
> reference. Thus, a library whose meaning depends on whether the instances
> of a library are distinguished or shared across phases or library
> expansions may be unportable.

I haven't found anything in R6RS that explicitly addresses cyclic library
imports, but I think this passage from § 7.2 [8]:

> If any of a library's definitions are referenced at phase 0 in the expanded
> form of a program, then an instance of the referenced library is created
> for phase 0 before the program's definitions and expressions are evaluated.
> This rule applies transitively: if the expanded form of one library
> references at phase 0 an identifier from another library, then before the
> referencing library is instantiated at phase n, the referenced library must
> be instantiated at phase n. When an identifier is referenced at any phase n
> greater than 0, in contrast, then the defining library is instantiated at
> phase n at some unspecified time before the reference is evaluated.
> Similarly, when a macro keyword is referenced at phase n during the
> expansion of a library, then the defining library is visited at phase n at
> some unspecified time before the reference is evaluated.

combined with the specification in § 7.1 [9] that:

> The expressions of variable definitions are evaluated from left to right, as
> if in an implicit letrec*, and the body expressions are also evaluated from
> left to right after the expressions of the variable definitions. A fresh
> location is created for each exported variable and initialized to the value
> of its local counterpart. The effect of returning twice to the continuation
> of the last body expression is unspecified.

means that they are prohibited. If library (a) and library (b) were each to
import each other and each to refer to the other's definitions at phase 0,
then library (a) must be instantiated *before* library (b), but library (b)
must also be instantiated *before* library (a), so an attempt to instantiate
either library would diverge.

Of course, Guile can, as an extension, assign meaning to cyclic module
imports, but I question whether Guile would be wise to do so, and whether
Guix would be wise to rely on it. It was before my time, but I know the
design of Racket's module system was influenced by the experience of
programming with Rackets "units"[10][11], which do support mutually recursive
references. Units are great when you really do need them, but the view of
those who experienced them was that acyclic modules are a better choice as
the fundamental mechanism of code organization. While you can make a compiler
or build system handle cyclic dependencies (albeit without all the nice
properties of the Racket and R6RS module systems), humans tend to find them
very confusing, especially when they are not explicit.

-Philip

[1]: Matthew Flatt, “Composable and Compilable Macros: You Want it When?”
(ICFP 2002), https://www.cs.utah.edu/plt/publications/macromod.pdf
[2]: Matthew Flatt, "Submodules in Racket: You Want it When, Again?"
(GCPE 2013), https://www.cs.utah.edu/plt/publications/gpce13-f-color.pdf
[3]: https://docs.racket-lang.org/reference/syntax-model.html#%28part._mod-parse%29
[4]: https://docs.racket-lang.org/reference/eval-model.html#%28part._module-eval-model%29
[5]: https://docs.racket-lang.org/reference/eval-model.html#%28part._module-phase%29
[6]: https://docs.racket-lang.org/reference/eval-model.html#%28part._separate-compilation%29
[7]: http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-10.html#node_chap_7
[8]: http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-10.html#node_sec_7.2
[9]: http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-10.html#node_sec_7.1
[10]: Flatt & Felleisen, "Units: Cool Modules for HOT Languages" (PLDI 1998),
http://www.ccs.neu.edu/scheme/pubs/pldi98-ff.ps.gz
[11]: https://docs.racket-lang.org/reference/mzlib_unit.html

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Semantics of circular imports

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 4055 bytes --]

Philip McGrath schreef op zo 20-02-2022 om 11:47 [-0500]:
> I was just (or maybe am still?) dealing with some issues caused by cyclic
> imports of package modules while updating Racket to 8.4: see in particular
> <https://issues.guix.gnu.org/53878#93>, as well as #66, #112, and #113 in the
> same thread.
> [...]
> I find the semantics of Guile's cyclic module imports very confusing,
> and I don't know of any documentation for what is and isn't supported
> other than advice from Ludo’ in <https://issues.guix.gnu.org/48682#7
> —is there any?

(The following explanation ignores syntax transformers, #:select and
#:autoload.)

Basically, a module consists of a hash table and a thunk
initialising the hash table.  A few situations to demonstrate:

;; Non-cyclic
(define-module (foo)
  #:export (foo))
(define foo 0)

(define-module (bar)
  #:export (bar)
  #:use-module (foo))
(define bar (+ 1 foo))

The thunk of 'foo' would be

  (lambda ()
    (set-module-value! '(foo) 'foo 0))

and the thunk of 'bar' would be

  (lambda ()
    ;; This calls the thunk of 'foo' if it hasn't yet been called
    ;; before.
    (initialise-module '(foo))
    (set-module-value! '(bar) 'bar (+ 1 (module-value '(foo) 'foo 0))))

;; Cyclic, non-problematic
(define-module (foo)
  #:export (foo)
  #:use-module (bar))
(define foo 0)
(define (calculate-foobar)
  (+ 1 (calculate-bar))

(define-module (bar)
  #:export (calculate-bar)
  #:use-module (foo))
(define (calculate-bar) (+ 1 foo))

The initialisation thunk of 'foo' would be

 (lambda ()
   (initialise-module '(bar))  ; L1
   (set-module-value! '(foo) 0) ; L2
   (set-module-value! '(foo) 'calculate-foobar ; L3
     (lambda () (+ 1 ((module-value '(bar) 'calculate-bar)))))) ; L4

and the thunk of 'bar' is:

  (lambda ()
    (initialise-module '(foo)) ; L6
    (set-module-value! '(bar) 'calculate-bar ; L7
      (lambda () (+ 1 (module-value '(foo) 'foo))))) ; L8

Now let's see what happens if the module (bar) is loaded:

; Initialising '(bar)'
(initialise-module '(foo)) ; L6
   ;; (foo) has not yet begun initialisation, so run the thunk:
   ->  (initialise-module '(bar)) ; L1
       ;; (bar) is being initialised, so don't do anything here
   -> (set-module-value! '(foo) 0) ; L2
   -> (set-module-value! '(foo) 'calculate-foobar ; L3
        (lambda () (+1 ((module-value '(bar) 'calculate-bar)))) ; L4

      The hash table of '(bar)' does not yet contain 'calculate-bar',
      but that's not a problem because the procedure 'calculate-foobar'
      is not yet run.
(set-module-value! '(bar) '(calculate-bar) ; L7
  (lambda () (+ 1 (module-value '(foo) 'foo)))) ; L8
;; The hash table of '(foo)' contains 'foo', so no problem!
;; Alternatively, even if '(foo)' did not contain 'foo',
;; the procedure '(calculate-bar)' is not yet run, so no problem!

;; Done!

Now for a problematic import cycle:

(define-module (foo)
  #:export (foo)
  #:use-module (bar))
(define foo (+ 1 bar))

(define-module (bar)
  #:export (bar)
  #:use-module (foo))
(define bar (+ 1 foo))

Now let's reason what happens when we try importing 'bar'.
The init thunk of '(foo)' is:

  (lambda ()
    (initialise-module '(bar)) ; L1
    (set-module-value! '(foo) 'foo (+ 1 (module-value '(bar) 'bar)))) ; L2

and the thunk of '(bar)':

  (lambda ()
    (initialise-module '(foo)) ; L3
    (set-module-value! '(bar) 'bar (+ 1 (module-value '(foo) 'foo)))) ; L4

Now let's see what happens if 'bar' is loaded:

; Initialising (bar)
(initialise-module! '(foo)) ; L3
  ;; (foo) has not yet begun initialisation, so run the thunk:
  -> (initialise-module '(bar)) ; L1
     ;; (bar) is already initialising, so don't do anything
  -> (set-module-value! '(foo) 'foo (+ 1 bar)))

     Oops, the variable foo of the module (foo) has not yet been defined,
     so an 'unbound-variable' exception is raised!

I hope that illustrates a little when and when not cyclic imports work!

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Semantics of circular imports

[Philip McGrath]

[-- Attachment #1: Type: text/plain, Size: 8644 bytes --]

Hi,

(Apparently I wrote this a month ago but left it sitting in "Drafts" ...)

On 2/20/22 12:47, Maxime Devos wrote:
> Philip McGrath schreef op zo 20-02-2022 om 11:47 [-0500]:
>> I was just (or maybe am still?) dealing with some issues caused by cyclic
>> imports of package modules while updating Racket to 8.4: see in particular
>> <https://issues.guix.gnu.org/53878#93>, as well as #66, #112, and #113 in the
>> same thread.
>> [...]
>> I find the semantics of Guile's cyclic module imports very confusing,
>> and I don't know of any documentation for what is and isn't supported
>> other than advice from Ludo’ in <https://issues.guix.gnu.org/48682#7
>> —is there any?
> 
> (The following explanation ignores syntax transformers, #:select and
> #:autoload.)
> 
> Basically, a module consists of a hash table and a thunk
> initialising the hash table.  A few situations to demonstrate:
> 
> ;; Non-cyclic
> (define-module (foo)
>    #:export (foo))
> (define foo 0)
> 
> (define-module (bar)
>    #:export (bar)
>    #:use-module (foo))
> (define bar (+ 1 foo))
> 
> The thunk of 'foo' would be
> 
>    (lambda ()
>      (set-module-value! '(foo) 'foo 0))
> 
> and the thunk of 'bar' would be
> 
>    (lambda ()
>      ;; This calls the thunk of 'foo' if it hasn't yet been called
>      ;; before.
>      (initialise-module '(foo))
>      (set-module-value! '(bar) 'bar (+ 1 (module-value '(foo) 'foo 0))))
> 
> ;; Cyclic, non-problematic
> (define-module (foo)
>    #:export (foo)
>    #:use-module (bar))
> (define foo 0)
> (define (calculate-foobar)
>    (+ 1 (calculate-bar))
> 
> (define-module (bar)
>    #:export (calculate-bar)
>    #:use-module (foo))
> (define (calculate-bar) (+ 1 foo))
> 
> The initialisation thunk of 'foo' would be
> 
>   (lambda ()
>     (initialise-module '(bar))  ; L1
>     (set-module-value! '(foo) 0) ; L2
>     (set-module-value! '(foo) 'calculate-foobar ; L3
>       (lambda () (+ 1 ((module-value '(bar) 'calculate-bar)))))) ; L4
> 
> and the thunk of 'bar' is:
> 
>    (lambda ()
>      (initialise-module '(foo)) ; L6
>      (set-module-value! '(bar) 'calculate-bar ; L7
>        (lambda () (+ 1 (module-value '(foo) 'foo))))) ; L8
> 
> Now let's see what happens if the module (bar) is loaded:
> 
> ; Initialising '(bar)'
> (initialise-module '(foo)) ; L6
>     ;; (foo) has not yet begun initialisation, so run the thunk:
>     ->  (initialise-module '(bar)) ; L1
>         ;; (bar) is being initialised, so don't do anything here
>     -> (set-module-value! '(foo) 0) ; L2
>     -> (set-module-value! '(foo) 'calculate-foobar ; L3
>          (lambda () (+1 ((module-value '(bar) 'calculate-bar)))) ; L4
> 
>        The hash table of '(bar)' does not yet contain 'calculate-bar',
>        but that's not a problem because the procedure 'calculate-foobar'
>        is not yet run.
> (set-module-value! '(bar) '(calculate-bar) ; L7
>    (lambda () (+ 1 (module-value '(foo) 'foo)))) ; L8
> ;; The hash table of '(foo)' contains 'foo', so no problem!
> ;; Alternatively, even if '(foo)' did not contain 'foo',
> ;; the procedure '(calculate-bar)' is not yet run, so no problem!

Oh, wow. I definitely had not realized that, *even inside a declarative 
module*, a reference to a variable with no statically visible definition 
would semantically be a dynamic lookup in a mutable environment at 
runtime (rather than a compile-time error), though I do see now that 
`info guile declarative` does indeed say that marking a module as 
declarative "applies only to the subset of top-level definitions that 
are themselves declarative: those that are defined within the 
compilation unit, and not assigned (‘set!’) or redefined within the 
compilation unit."

Does this mean that Guile treats all imported bindings as non-declarative?
This seems like a big barrier to cross-module inlining, though IIUC Guile
currently doesn't do much of that by default (maybe for this reason).

The use of "top-level" to refer to definitions within a module is 
somewhat confusing to me. I usually understand "top-level" to refer to 
the kind of interactive REPL environment for which R6RS leaves the 
semantics unspecified. Racket uses "module-level variable"  and "module 
context" in contrast to "top-level variable" and "top-level context" to
make this distinction.[1][2][3] (There are also R6RS "top-level 
programs", but I wouldn't think of those unless made very clear from 
context.)

(Also, what is a "compilation unit" in Guile? Is it ever something other 
than a single module corresponding to a single file (potentially using 
`include` to incorporate other files at expand time?)

> 
> ;; Done!
> 
> Now for a problematic import cycle:
> 
> (define-module (foo)
>    #:export (foo)
>    #:use-module (bar))
> (define foo (+ 1 bar))
> 
> (define-module (bar)
>    #:export (bar)
>    #:use-module (foo))
> (define bar (+ 1 foo))
> 
> Now let's reason what happens when we try importing 'bar'.
> The init thunk of '(foo)' is:
> 
>    (lambda ()
>      (initialise-module '(bar)) ; L1
>      (set-module-value! '(foo) 'foo (+ 1 (module-value '(bar) 'bar)))) ; L2
> 
> and the thunk of '(bar)':
> 
>    (lambda ()
>      (initialise-module '(foo)) ; L3
>      (set-module-value! '(bar) 'bar (+ 1 (module-value '(foo) 'foo)))) ; L4
> 
> Now let's see what happens if 'bar' is loaded:
> 
> ; Initialising (bar)
> (initialise-module! '(foo)) ; L3
>    ;; (foo) has not yet begun initialisation, so run the thunk:
>    -> (initialise-module '(bar)) ; L1
>       ;; (bar) is already initialising, so don't do anything
>    -> (set-module-value! '(foo) 'foo (+ 1 bar)))
> 
>       Oops, the variable foo of the module (foo) has not yet been defined,
>       so an 'unbound-variable' exception is raised!


In the context of Racket or R6RS modules, where the semantics are 
essentially those of `letrec*`, I'm used to distinguishing "unbound" variables
from "undefined" variables, two types of errors, though informally "defined"
is often used more loosely: 

  1. Every variable reference must refer to a lexically visible binding, or
     it is an "unbound" variable error. Inherently, this can *always* be
     detected statically at compile time.

  2. A variable may not be accessed until it has been initialized. (More
     precisely, we could discuss a variable's "location", which I see is
     part of Guile's model.) This is the essence of the `letrec`/`letrec*`
     restriction: while the "fixing letrec" papers[4][5] show that useful
     static analysis can be done, this is fundamentally a dynamic property.
     Violating the restriction is an "undefined" variable error at runtime.

> 
> I hope that illustrates a little when and when not cyclic imports work!

This helped quite a bit with avoiding problems in practice---thanks!

I think there are two aspects I still feel uncertain about:

First, it is not clear to me why there was a dependency between
(gnu packages chez) and (gnu packages racket) prior to the change that
prompted me to ask this. Given what Ludo’ wrote in
<https://issues.guix.gnu.org/48682#7>:

> > Do you have any advice on what would be good practice?
> 
> For package modules, the main things are:
>   1. Don’t use #:select or #:autoload for (gnu packages …) modules in a
>      (gnu packages …) module.
>   2. At the top level of a module, only refer to variables within that
>      module.

it sounds like maybe there's some kind of implicit cycle involving---most?
all?---(gnu packages …) modules. Is that true?

Second, Guile's semantics being what they are, is it considered good practice
to take advantage of this dynamic variable resolution and tolerance for cyclic
modules? My personal taste (you may not be surprised to hear) is to prefer
more static semantics and handling cycles explicitly when they are truly
necessary. But if this is a pervasive idiom in Guile, I can try to write with
less of a Racket "accent".

Thanks again for this detailed explanation!

-Philip

[1]: 
https://docs.racket-lang.org/reference/eval-model.html#%28part._vars-and-locs%29
[2]: 
https://docs.racket-lang.org/reference/eval-model.html#%28part._module-eval-model%29
[3]: 
https://docs.racket-lang.org/reference/syntax-model.html#%28part._expand-context-model%29
[4]:
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.441.8816&rep=rep1&type=pdf
[5]:
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.309.420&rep=rep1&type=pdf

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Semantics of circular imports

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]

Philip McGrath schreef op zo 27-03-2022 om 10:12 [-0400]:
> Oh, wow. I definitely had not realized that, *even inside a
> declarative 
> module*, a reference to a variable with no statically visible
> definition 
> would semantically be a dynamic lookup in a mutable environment at 
> runtime (rather than a compile-time error), though I do see now that 
> `info guile declarative` does indeed say that marking a module as 
> declarative "applies only to the subset of top-level definitions that
> are themselves declarative: those that are defined within the 
> compilation unit, and not assigned (‘set!’) or redefined within the 
> compilation unit."
> 
> Does this mean that Guile treats all imported bindings as non-
> declarative?
> This seems like a big barrier to cross-module inlining, though IIUC
> Guile
> currently doesn't do much of that by default (maybe for this reason).

To my understanding, declarative modules are orthogonal to circular
imports.  All declarative modules do, is telling the Guile compiler
that ‘yes, inlining is fine, I won't change the value of these top-
level variables’.

Declarativity does not change the module variable lookup system and
module loading system, it only changes the set of optimisations.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Semantics of circular imports

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

Philip McGrath schreef op zo 27-03-2022 om 10:12 [-0400]:
> The use of "top-level" to refer to definitions within a module is 
> somewhat confusing to me. I usually understand "top-level" to refer
> to 
> the kind of interactive REPL environment for which R6RS leaves the 
> semantics unspecified. Racket uses "module-level variable"  and
> "module 
> context" in contrast to "top-level variable" and "top-level context"
> to
> make this distinction.[1][2][3] (There are also R6RS "top-level 
> programs", but I wouldn't think of those unless made very clear from 
> context.)

In Guile, if you start a REPL, the REPL is inside some module.  By
default, this module is the (guile-user) module (or (guix-user), when
using "guix repl"), although this can be changed with ',m' and maybe by
stepping through the debugger (not sure).

As such, if you run (define foo 'bar) inside a REPL currently in
(guile-user), then this corresponds to defining a top-level
variable/module variable inside the (guile-user) module.

Summarised: REPL environments have a corresponding Guile module and in
Guile, there is no meaningful distinction between "top-level variable"
and "module variable", unlike in Racket.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Semantics of circular imports

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]

Philip McGrath schreef op zo 27-03-2022 om 10:12 [-0400]:
> (Also, what is a "compilation unit" in Guile? Is it ever something
> other  than a single module corresponding to a single file
> (potentially using  `include` to incorporate other files at expand
> time?)

(the following explanation ignores (guile)Eval when, which seems to
assign a different meaning)

IIUC, a compilation unit is what is turned into a .go file as a unit,
full of literals and code.  There are at least three situations:

  * (common):   If "foo.scm" is of the form

      (define-module (foo) #:use-module (bar)) ... (stuff)

    then, if, "foo.scm" is compiled "foo.go", "foo.go" contains code
    that constructs the value of global variables (procedures etc.),
    fix ups relocations, creates a module object, add the variables
    to the module object, and registers the module into the module
    system and runs (stuff)

  * (uncommon, discouraged):  "foo.scm" can, in principle, contain
    multiple modules:

    (define-module (bar) ...) ...
    (define-module (foo) ...) ...

    Then "foo.go" will contain code initialising both the modules.
    It can be rather confusing though, so I cannot recommend this.

  * (common):  It is also possible to compile Scheme files that don't
    define modules and only import some modules, e.g.

    (use-modules (fibonnaci))
    (for-each display (fibonacci-numbers #:upto 900))

    Then when "foo.go" is loaded, the fibonacci numbers are printed.

Greetings,
Maxime

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Semantics of circular imports

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]

Philip McGrath schreef op zo 27-03-2022 om 10:12 [-0400]:
> In the context of Racket or R6RS modules, where the semantics are 
> essentially those of `letrec*`, I'm used to distinguishing "unbound"
> variables from "undefined" variables, two types of errors, though
> informally "defined" is often used more loosely: 

Guile also distinguished them, though possibly in a different way, and
terminology is inconsistent.

> 
>   1. Every variable reference must refer to a lexically visible
>      binding, or it is an "unbound" variable error. Inherently, this
>      can *always* be detected statically at compile time.

This is different in Guile.  If a variable reference 'foo' is not a
lexical variable, then Guile assumes it is a global variable -- it
doesn't check if the name of the global variable reference actually
belongs to an imported module, this only happens at runtime. 
Apparently Guile is a bit lazier than Racket.

> 
>   2. A variable may not be accessed until it has been initialized.(
>      More precisely, we could discuss a variable's "location", which
>      I see is part of Guile's model.) This is the essence of the
>      `letrec`/`letrec*` restriction: while the "fixing letrec"
>      papers[4][5] show that useful static analysis can be done, this
>      is fundamentally a dynamic property. Violating the restriction
>      is an "undefined" variable error at runtime.

I don't know how Guile handles letrec/letrec*.  However, Guile has
undefined(uninitialised? unbound? Guile has inconsistent terminology
here) variables:

(define foo) ; no value
foo ; I thought this would raise an "Unbound variable: ..." error but apparently not?  A bug? Looks like it returns *unspecified* instead ...

(variable-ref (make-undefined-variable)) ; -> Unbound variable: ...

(define f (make-variable #f))
(variable-unset! f)
(variable-ref f) ; --> Unbound variable: #<variable 7fb531f1cce0 value: #<undefined>>

(variable-ref (make-variable #f)) ; this variable has no name, so in a sense, it is not ‘bound’, yet it has a value

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Semantics of circular imports

[Zhu Zihao]

[-- Attachment #1: Type: text/plain, Size: 2474 bytes --]


Philip McGrath <philip@philipmcgrath.com> writes:

> Oh, wow. I definitely had not realized that, *even inside a declarative 
> module*, a reference to a variable with no statically visible definition 
> would semantically be a dynamic lookup in a mutable environment at 
> runtime (rather than a compile-time error), though I do see now that 
> `info guile declarative` does indeed say that marking a module as 
> declarative "applies only to the subset of top-level definitions that 
> are themselves declarative: those that are defined within the 
> compilation unit, and not assigned (‘set!’) or redefined within the 
> compilation unit."

It depends on how you reference to it. If a variable is referenced in
the same module, it'll be inlined if it's small enough.

If you reference it from another module, it'll do something like
module-ref instead (works like non-declarative binding)

> This seems like a big barrier to cross-module inlining, though IIUC Guile
> currently doesn't do much of that by default (maybe for this reason).

Guile 3.0.8 comes to rescue. It works by rewrite the `define-module`
call and attach the tree-il of some bindings on it.

For details, read the blog post authored by Andy Wingo

https://wingolog.org/archives/2021/05/13/cross-module-inlining-in-guile

TIPS: If you're interested in the implementation detail of Guile. You
should not miss the Andy Wingo's blog post!  

> The use of "top-level" to refer to definitions within a module is 
> somewhat confusing to me. I usually understand "top-level" to refer to 
> the kind of interactive REPL environment for which R6RS leaves the 
> semantics unspecified. Racket uses "module-level variable"  and "module 
> context" in contrast to "top-level variable" and "top-level context" to
> make this distinction.[1][2][3] (There are also R6RS "top-level 
> programs", but I wouldn't think of those unless made very clear from 
> context.)

Top-level is the set of outermost brackets in a file :)

The optimization pass related to the top-level in Guile is called
letrectify. It rewrites the top-level bindings into a big letrec block.
You can check the comment of (language tree-il letrectify) and it has
a good example.

Because top-levels can reference each other, so the evaluation order
will not the same as the code order.

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

Re: Semantics of circular imports

[Maxim Cournoyer]

Hello,

Zhu Zihao <all_but_last@163.com> writes:

> Philip McGrath <philip@philipmcgrath.com> writes:
>
>> Oh, wow. I definitely had not realized that, *even inside a declarative 
>> module*, a reference to a variable with no statically visible definition 
>> would semantically be a dynamic lookup in a mutable environment at 
>> runtime (rather than a compile-time error), though I do see now that 
>> `info guile declarative` does indeed say that marking a module as 
>> declarative "applies only to the subset of top-level definitions that 
>> are themselves declarative: those that are defined within the 
>> compilation unit, and not assigned (‘set!’) or redefined within the 
>> compilation unit."
>
> It depends on how you reference to it. If a variable is referenced in
> the same module, it'll be inlined if it's small enough.
>
> If you reference it from another module, it'll do something like
> module-ref instead (works like non-declarative binding)
>
>> This seems like a big barrier to cross-module inlining, though IIUC Guile
>> currently doesn't do much of that by default (maybe for this reason).
>
> Guile 3.0.8 comes to rescue. It works by rewrite the `define-module`
> call and attach the tree-il of some bindings on it.
>
> For details, read the blog post authored by Andy Wingo
>
> https://wingolog.org/archives/2021/05/13/cross-module-inlining-in-guile

Thanks for the interesting read (nice writing from Wingo, as usual :-)).

Maxim

Re: Faster "guix pull" by incremental compilation and non-circular modules?

[Ludovic Courtès]

Hi,

Maxime Devos <maximedevos@telenet.be> skribis:

>   2. Instead of building all of Guix as a single derivation,
>      create a DAG of derivations.  More concretely:
>
>      First read the *.scm files to determine which module imports
>      which modules. Then to compile, say, (gnu packages acl),
>      a derivation taking gnu/packages/acl.scm and its dependencies
>      gnu/packages/attr.go, gnu/packages/base.go, ... is made
>      compiling gnu/packages/acl.scm to a gnu/packages/acl.go.
>
>      Then to build all of Guix, 'union-build' or 'file-union' is used.

This is what (guix self), used by ‘guix pull’, is already doing.

However, currently, package modules are split in just two groups: the
“base” group is the closure of (guix packages base), and the second
group has all the rest:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(guix modules)
scheme@(guile-user)> (length (source-module-closure '((gnu packages base))))
$4 = 417
scheme@(guile-user)> ,use(ice-9 ftw)
scheme@(guile-user)> (length (scandir "gnu/packages" (lambda (f) (string-suffix? ".scm" f))))
$5 = 537
scheme@(guile-user)> (- $5 $4)
$6 = 120
--8<---------------cut here---------------end--------------->8---

This is clearly uneven, especially considering that the biggest file,
crates-io.scm, is in the first group.

At its core though, the situation pretty much reflects the free software
situation: there are low-level packages (glibc, GCC, GTK, etc.) that
might depend on high-level packages (Python, Pandoc, Rust, etc.).

It’s not easy to split this spaghetti ball in smaller groups.

Thoughts?

Ludo’.

Re: Faster "guix pull" by incremental compilation and non-circular modules?

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 2707 bytes --]

Ludovic Courtès schreef op ma 28-02-2022 om 14:17 [+0100]:
> Hi,
> 
> Maxime Devos <maximedevos@telenet.be> skribis:
> 
> >   2. Instead of building all of Guix as a single derivation,
> >      create a DAG of derivations.  More concretely:
> > 
> >      First read the *.scm files to determine which module imports
> >      which modules. Then to compile, say, (gnu packages acl),
> >      a derivation taking gnu/packages/acl.scm and its dependencies
> >      gnu/packages/attr.go, gnu/packages/base.go, ... is made
> >      compiling gnu/packages/acl.scm to a gnu/packages/acl.go.
> > 
> >      Then to build all of Guix, 'union-build' or 'file-union' is used.
> 
> This is what (guix self), used by ‘guix pull’, is already doing.
> 
> However, currently, package modules are split in just two groups: the
> “base” group is the closure of (guix packages base), and the second
> group has all the rest:
> 
> [...]

Looking at (guix self), it also has a few groups for non-package
modules (system tests, scripts, ...).

> At its core though, the situation pretty much reflects the free software
> situation: there are low-level packages (glibc, GCC, GTK, etc.) that
> might depend on high-level packages (Python, Pandoc, Rust, etc.).
> 
> It’s not easy to split this spaghetti ball in smaller groups.

It's not easy to manually split the spaghetti, but we don't have
to, we could let the computer split the spaghetti for us (at least
partially, because of the circular imports), by computing the graph of
strongly-connected components and considering each SCC to be a ‘group’,
some of which depend on other groups, forming a DAG.

I believe Ricardo Wurmus has some script for computing the SCC?

Splitting large SCC in smaller parts can be left as an exercise
for later, it's a somewhat orthogonal concern.

> Thoughts?

I think it would be nice to let (guix self) automatically determine the
DAG of groups.  It would reduce the ad-hocness of the *...-modules*
variables (some care required for patches, guix/man-db.scm, .js ...).

It would also make the node tree wide, which could reduce memory usage
(which might help with the ‘guix pull segfaults on i686-linux’
reports).  In case of a crash (*), "guix pull" does not have to start
over from scratch, which would also help with those reports.

(*) This does not help with "failed to compute the derivation of Guix".

Some work would be required, but I think it will be worth it, and it
only has to be done once.

TBC, this was just an idea I wanted to share, I won't be working on it
in the forseeable future.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Faster "guix pull" by incremental compilation and non-circular modules?

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 3405 bytes --]

Hello Maxime,

Maxime Devos <maximedevos@telenet.be> ezt írta (időpont: 2022. febr. 28.,
H, 19:51):

> Ludovic Courtès schreef op ma 28-02-2022 om 14:17 [+0100]:
> > Hi,
> >
> > Maxime Devos <maximedevos@telenet.be> skribis:
> >
> > >   2. Instead of building all of Guix as a single derivation,
> > >      create a DAG of derivations.  More concretely:
> > >
> > >      First read the *.scm files to determine which module imports
> > >      which modules. Then to compile, say, (gnu packages acl),
> > >      a derivation taking gnu/packages/acl.scm and its dependencies
> > >      gnu/packages/attr.go, gnu/packages/base.go, ... is made
> > >      compiling gnu/packages/acl.scm to a gnu/packages/acl.go.
> > >
> > >      Then to build all of Guix, 'union-build' or 'file-union' is used.
> >
> > This is what (guix self), used by ‘guix pull’, is already doing.
> >
> > However, currently, package modules are split in just two groups: the
> > “base” group is the closure of (guix packages base), and the second
> > group has all the rest:
> >
> > [...]
>
> Looking at (guix self), it also has a few groups for non-package
> modules (system tests, scripts, ...).
>
> > At its core though, the situation pretty much reflects the free software
> > situation: there are low-level packages (glibc, GCC, GTK, etc.) that
> > might depend on high-level packages (Python, Pandoc, Rust, etc.).
> >
> > It’s not easy to split this spaghetti ball in smaller groups.
>
> It's not easy to manually split the spaghetti, but we don't have
> to, we could let the computer split the spaghetti for us (at least
> partially, because of the circular imports), by computing the graph of
> strongly-connected components and considering each SCC to be a ‘group’,
> some of which depend on other groups, forming a DAG.
>

I was thinking about a bit of a different structure that can also be
automated. My original idea was to use the already existing tree structure
of the derivations, and split it based on depth. I think that gives a bit
more structure, but might require splitting things that now are together
(for example iirc sometimes we are defining bootstrap packages inheriting
from the fully fledged ones, which introduces a syntactic dependency on
something that is  higher up the tree). Wdyt?

Regards,
g_bor


> I believe Ricardo Wurmus has some script for computing the SCC?
>
> Splitting large SCC in smaller parts can be left as an exercise
> for later, it's a somewhat orthogonal concern.
>
> > Thoughts?
>
> I think it would be nice to let (guix self) automatically determine the
> DAG of groups.  It would reduce the ad-hocness of the *...-modules*
> variables (some care required for patches, guix/man-db.scm, .js ...).
>
> It would also make the node tree wide, which could reduce memory usage
> (which might help with the ‘guix pull segfaults on i686-linux’
> reports).  In case of a crash (*), "guix pull" does not have to start
> over from scratch, which would also help with those reports.
>
> (*) This does not help with "failed to compute the derivation of Guix".
>
> Some work would be required, but I think it will be worth it, and it
> only has to be done once.
>
> TBC, this was just an idea I wanted to share, I won't be working on it
> in the forseeable future.
>
> Greetings,
> Maxime.
>

[-- Attachment #2: Type: text/html, Size: 4320 bytes --]

Re: Faster "guix pull" by incremental compilation and non-circular modules?

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

Gábor Boskovits schreef op di 31-05-2022 om 06:54 [+0200]:
> I was thinking about a bit of a different structure that can also be
> automated. My original idea was to use the already existing tree
> structure of the derivations, and split it based on depth. I think
> that gives a bit more structure, but might require splitting things
> that now are together (for example iirc sometimes we are defining
> bootstrap packages inheriting from the fully fledged ones, which
> introduces a syntactic dependency on something that is  higher up the
> tree). Wdyt?

The package modules could be split and reorganised a bit to roughly
follow the derivation DAG, if that's what you mean (*)? Then the "guix"
package would depend on less -> compute-guix-derivation etc has less to
do, also good for lowering "guix $do_something" memory footprint. 
Seems orthogonal to my proposal.  I guess we could eventually do both?

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Faster "guix pull" by incremental compilation and non-circular modules?

[Ricardo Wurmus]

Maxime Devos <maximedevos@telenet.be> writes:

> [[PGP Signed Part:Undecided]]
> Gábor Boskovits schreef op di 31-05-2022 om 06:54 [+0200]:
>> I was thinking about a bit of a different structure that can also be
>> automated. My original idea was to use the already existing tree
>> structure of the derivations, and split it based on depth. I think
>> that gives a bit more structure, but might require splitting things
>> that now are together (for example iirc sometimes we are defining
>> bootstrap packages inheriting from the fully fledged ones, which
>> introduces a syntactic dependency on something that is  higher up the
>> tree). Wdyt?
>
> The package modules could be split and reorganised a bit to roughly
> follow the derivation DAG, if that's what you mean (*)? Then the "guix"
> package would depend on less -> compute-guix-derivation etc has less to
> do, also good for lowering "guix $do_something" memory footprint. 

This seems like a thing we’d have to do repeatedly as module cycles can
appear due to seemingly innocent package upgrades.

I get the appeal of untangling the module graph, but I suspect it will
turn out to be a lot of busywork leading to repeated disruption (because
packages keep moving to different modules, breaking third party channels
for no good reason) for little gain.

I do hope we can reduce the amount of work that compute-guix-derivation
has to perform, even if it causes some disruption once.

-- 
Ricardo

Re: Compiling blender

[Ricardo Wurmus]

Ekaitz Zarraga <ekaitz@elenq.tech> writes:

> I was updating mesa, see #54066.

Give the build farm some time and it will build things for you.  Nobody
else is expected to build all the packages you mentioned.

>> PS: I don’t take the bait :)
[…]
> I understand your point with Bitcoin […]

I made no point about Bitcoin.

-- 
Ricardo

Re: Compiling blender

[Ekaitz Zarraga]

> Ekaitz Zarraga ekaitz@elenq.tech writes:
>
> > I was updating mesa, see #54066.
>
> Give the build farm some time and it will build things for you.
> Nobody else is expected to build all the packages you mentioned.

But I wanted to use it in my machine anyway.


> > > PS: I don’t take the bait :)
>
> […]
>
> > I understand your point with Bitcoin […]
>
> I made no point about Bitcoin.

Sorry I thougth you made the first post.

Re: Excessively energy-consuming software considered malware?

[Taylan Kammer]

On 20.02.2022 11:05, Maxime Devos wrote:
> 
> 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?
> 
I'm not a fan of cryptocurrencies at all, but I don't like the idea of
excluding software from Guix on the grounds that it's harmful in some
indirect way.

Malware is software that harms/exploits the user without their knowledge.
The inefficiency of cryptocurrencies was never a secret, though people
didn't think much about it; recently it's become widespread knowledge, so
I think considering crypto miners to be malware is somewhat unreasonable.

An example of actual malware would be a *hidden* crypto miner that sends
the mined coins to the author of the software.

If we're going to exclude software on grounds of it being used in harmful
ways, I can already see people arguing that one should exclude software
such as aircrack-ng for aiding in breaching into networks, or anonymity
software like Tor because it aids perverts in sharing you-know-what or
aids terrorists in planning attacks.  Slippery slopes and all.

One might argue that those pieces of software also have good uses, but
the same could be argued about a crypto miner: perhaps I want to install
one simply to study its operation to aide in some sort of research, maybe
even research about its inherent inefficiency.  Or maybe I want to devise
a small-scale blockchain-based network for a niche use-case where the
blockchain won't reach an unwieldy size or will be limited in lifetime.

All in all, I think the baseline is that if something is software, and it
respects the user's freedoms, it belongs in Guix.

What do you think?  I'm happy to have my mind changed.  I've never used a
crypto miner and continue to be disinterested in them so don't care about
this particular case all that much, but the principle behind the reasoning
bothers me somewhat.

-- 
Taylan

Re: Excessively energy-consuming software considered malware?

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 2298 bytes --]

Taylan Kammer schreef op zo 20-02-2022 om 13:20 [+0100]:
> If we're going to exclude software on grounds of it being used in harmful
> ways, I can already see people arguing that one should exclude software
> such as aircrack-ng for aiding in breaching into networks, or anonymity
> software like Tor because it aids perverts in sharing you-know-what or
> aids terrorists in planning attacks.  Slippery slopes and all.
> 
> One might argue that those pieces of software also have good uses, but
> the same could be argued about a crypto miner: perhaps I want to install
> one simply to study its operation to aide in some sort of research, maybe
> even research about its inherent inefficiency.  Or maybe I want to devise
> a small-scale blockchain-based network for a niche use-case where the
> blockchain won't reach an unwieldy size or will be limited in lifetime.
> 
> All in all, I think the baseline is that if something is software, and it
> respects the user's freedoms, it belongs in Guix.
> 
> What do you think?  I'm happy to have my mind changed.  I've never used a
> crypto miner and continue to be disinterested in them so don't care about
> this particular case all that much, but the principle behind the reasoning
> bothers me somewhat.

The points about slippery slopes, research and niche use-cases seem
reasonable to me.  I do see follow-up questions though, should the
description in Guix warn about potential issues?  And should the
description focus on research uses? ...

More concretely, the p2pool description is:

‘Monero P2Pool is a peer-to-peer Monero mining pool.  P2Pool
combines the advantages of pool and solo mining; you still fully
control your Monero node and what it mines, but *you get frequent
payouts like on a regular pool.*’

This is quite a bit different from, say, aircrack-ng which seems
to be mostly about assessing security, whereas the p2pool description
is about gaining money (see ‘payouts’), and without mentioning that
mining costs a lot of energy (and hence money, and possibly the money
that is gained by mining is smaller than the amount lost due to energy
costs!).

My dislike for the description of p2pool might just be my views on
money leaking through, though.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Excessively energy-consuming software considered malware?

[Taylan Kammer]

On 20.02.2022 13:37, Maxime Devos wrote:
> 
> The points about slippery slopes, research and niche use-cases seem
> reasonable to me.  I do see follow-up questions though, should the
> description in Guix warn about potential issues?  And should the
> description focus on research uses? ...
> 
> More concretely, the p2pool description is:
> 
> ‘Monero P2Pool is a peer-to-peer Monero mining pool.  P2Pool
> combines the advantages of pool and solo mining; you still fully
> control your Monero node and what it mines, but *you get frequent
> payouts like on a regular pool.*’
> 
> This is quite a bit different from, say, aircrack-ng which seems
> to be mostly about assessing security, whereas the p2pool description
> is about gaining money (see ‘payouts’), and without mentioning that
> mining costs a lot of energy (and hence money, and possibly the money
> that is gained by mining is smaller than the amount lost due to energy
> costs!).
> 
> My dislike for the description of p2pool might just be my views on
> money leaking through, though.
> 
> Greetings,
> Maxime.

I guess a different description would be better.  It sounds almost
like a sales pitch with the mention of making money. :-)

I'm not familiar with Monero/P2Pool so I don't know what a better
description might sound like though.

-- 
Taylan

Re: Excessively energy-consuming software considered malware?

[Philip McGrath]

On Sunday, February 20, 2022 7:44:18 AM EST Taylan Kammer wrote:
> On 20.02.2022 13:37, Maxime Devos wrote:
> > The points about slippery slopes, research and niche use-cases seem
> > reasonable to me.  I do see follow-up questions though, should the
> > description in Guix warn about potential issues?  And should the
> > description focus on research uses? ...
> > 
> > More concretely, the p2pool description is:
> > 
> > ‘Monero P2Pool is a peer-to-peer Monero mining pool.  P2Pool
> > combines the advantages of pool and solo mining; you still fully
> > control your Monero node and what it mines, but *you get frequent
> > payouts like on a regular pool.*’
> > 
> > This is quite a bit different from, say, aircrack-ng which seems
> > to be mostly about assessing security, whereas the p2pool description
> > is about gaining money (see ‘payouts’), and without mentioning that
> > mining costs a lot of energy (and hence money, and possibly the money
> > that is gained by mining is smaller than the amount lost due to energy
> > costs!).
> > 
> > My dislike for the description of p2pool might just be my views on
> > money leaking through, though.
> > 
> > Greetings,
> > Maxime.
> 
> I guess a different description would be better.  It sounds almost
> like a sales pitch with the mention of making money. :-)
> 
> I'm not familiar with Monero/P2Pool so I don't know what a better
> description might sound like though.

This description sound like it is promising that, if you run this software, 
you will "get frequent payouts". I don't think that's a claim Guix can or 
should make. I guess there's maybe some tension about to what extent package 
descriptions are speaking on behalf of the package or on behalf of Guix, but I 
don't think it usually causes too much confusion for the description of a 
package like `pypy3` to say what the program's developers think its merits 
are, without Guix as a project appearing to take a position on which is the 
best Python implementation. However, a package description claiming that you 
will get money if you use it seems like quite an extreme case.

(More generally, I share both the concerns about the impacts of crypto mining 
and the concern that for Guix to refuse to package such software might have 
problematic implications.)

-Philip

Re: Excessively energy-consuming software considered malware?

[Christine Lemmer-Webber]

Taylan Kammer <taylan.kammer@gmail.com> writes:

> On 20.02.2022 11:05, Maxime Devos wrote:
>> 
>> 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?
>> 
> I'm not a fan of cryptocurrencies at all, but I don't like the idea of
> excluding software from Guix on the grounds that it's harmful in some
> indirect way.
>
> Malware is software that harms/exploits the user without their knowledge.
> The inefficiency of cryptocurrencies was never a secret, though people
> didn't think much about it; recently it's become widespread knowledge, so
> I think considering crypto miners to be malware is somewhat unreasonable.
>
> An example of actual malware would be a *hidden* crypto miner that sends
> the mined coins to the author of the software.

I think that's a good analysis.  Software which installs a crytpo-miner
*without a user's knowledge* is a serious problem.

> If we're going to exclude software on grounds of it being used in harmful
> ways, I can already see people arguing that one should exclude software
> such as aircrack-ng for aiding in breaching into networks, or anonymity
> software like Tor because it aids perverts in sharing you-know-what or
> aids terrorists in planning attacks.  Slippery slopes and all.

I agree... I'm also conscious that it'll put Guix in a position where
this will be a large portion of the work that Guix is doing is screening
software on a very large number of grounds, whereas we already screen
software much more so than most places.  It could absorb a lot of our
energy.  It's easy to underestimate just how all-consuming this could
become.

I share criticisms of proof-of-work.  Though some of the criticisms
being raised on this list are treating "blockchains" and
"cryptocurrencies" as if they even were one coherent thing.  In reality
the variance space of this is huge:

  https://dustycloud.org/blog/what-is-a-blockchain-really/

You'll see plenty of my own criticisms coming up in there.  But part of
my issue is, it's worth being precise about what's being criticized.
For instance, "proof of stake" has other problems (arguably still has
plutocratic properties), but not the energy consumption issue.  Most of
the discourse contemporarily is acting as if both are the same.  But
even proof of stake based systems are often being built on top of
software that's being refactored from "proof of work".

I think this activism criticizing design choices along these lines *is*
worthwhile, but building alternatives and getting them adopted may be a
stronger choice.  I'd like to replace proof-of-work based systems
largely; there are under-appreciated directions that even predate
Bitcoin dramatically that are worth exploring.

Relatedly, the title of this is: "Excessively energy-consuming software
considered malware?"  That's broad enough that it could also put a lot
of emphasis on "don't use inefficient languages" (actually that's how I
misread what the subject of this thread originally before opening it).
That's worthwhile also, but similarly, is Guix's package repository
acceptance/rejection the right place?

> One might argue that those pieces of software also have good uses, but
> the same could be argued about a crypto miner: perhaps I want to install
> one simply to study its operation to aide in some sort of research, maybe
> even research about its inherent inefficiency.  Or maybe I want to devise
> a small-scale blockchain-based network for a niche use-case where the
> blockchain won't reach an unwieldy size or will be limited in lifetime.
>
> All in all, I think the baseline is that if something is software, and it
> respects the user's freedoms, it belongs in Guix.
>
> What do you think?  I'm happy to have my mind changed.  I've never used a
> crypto miner and continue to be disinterested in them so don't care about
> this particular case all that much, but the principle behind the reasoning
> bothers me somewhat.

Re: Excessively energy-consuming software considered malware?

[Jonathan McHugh]

Hello Maxime,

February 20, 2022 1:37 PM, "Maxime Devos" <maximedevos@telenet.be> wrote:
> 
> More concretely, the p2pool description is:
> 
> ‘Monero P2Pool is a peer-to-peer Monero mining pool. P2Pool
> combines the advantages of pool and solo mining; you still fully
> control your Monero node and what it mines, but *you get frequent
> payouts like on a regular pool.*’
> 

The Monero description is evidently written by a marketer - thats enough justification for caution.

For example, the use of the word "like" in the description appears to remove rather than add clarification

I know which of the following statements is more reassuring:
* You will be paid Saturday
* You will be paid like Saturday

Similarly, the repeating use of terms (P2P, mining, pool) and the name Monero feels like a cynical approach at inbibing rather than educating.

FWIW, Ive noticed that many toolset descriptions are turning into hyperbole on the homepages.
Ive found that visiting forges READMEs tends to provide clearer and more concise descriptions of what a tool is and its functions.

If a concise and normative technical definition of the tool exists then maybe it can be considered (inspite of all the moral hazards and negative externalities).

Until then, let such hazardous pools mine their chains *all solo like* on other OSes.


====================
Jonathan McHugh
indieterminacy@libre.brussels

Re: Excessively energy-consuming software considered malware?

[Paul Jewell]

> On 20 Feb 2022, at 10:07, Maxime Devos <maximedevos@telenet.be> wrote:
> 
> 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?
> Greetings,
> Maxime.

To directly answer your question, in my opinion miners should not be considered malware in Guix. 
Much as I don’t like the adverse climate impact of miners and crypto, I think it is the thin end of the wedge of packages are restricted based on climate impact. I think we should stick to restrictions based on licence conditions. Of course, this is just a personal opinion, and has no more validity than your opinion!!

Best regards,
Paul

Re: Excessively energy-consuming software considered malware?

[Liliana Marie Prikler]

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

Re: Excessively energy-consuming software considered malware?

[Ryan Sundberg]

[-- Attachment #1: Type: text/plain, Size: 2656 bytes --]

I'd prefer to steer clear of passing value judgments on individual packages of free software as a policy. All of the tools we provide can be used for good or evil. It is up to the user to bear responsibility for their own actions with the software they choose to build.

Sincerely,

Ryan Sundberg


-------- Original Message --------
From: Maxime Devos <maximedevos@telenet.be>
Sent: February 20, 2022 2:05:44 AM PST
To: guix-devel@gnu.org
Subject: Excessively energy-consuming software considered malware?

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

Greetings,
Maxime.

(*) For this e-mail, I'm only considering cryptocurrencies based on
some ‘mining’ system and assuming that monero and ethereum have the
same energy problems as Bitcoin, although possibly with a smaller
constant factor.

[1]: See, e.g.,
https://www.nytimesn7cgmftshazwhfgzm37qxb44r64ytbb2dj3x62d2lljsciiyd.onion/2021/03/09/business/dealbook/bitcoin-climate-change.html
/
https://www.nytimesn7cgmftshazwhfgzm37qxb44r64ytbb2dj3x62d2lljsciiyd.onion/2021/03/09/business/dealbook/bitcoin-climate-change.html

[2]: zero hits when searching for "malware" in the manual!

[3]: I'm sure you can find some sources about destabilising climate
systems, species extinctions, fish getting third-degree burns, island
nations gradually disappearing because of raising sea levels ...

[3]: I'm not sure actually that mining would be (partially) responsible
for increasing energy prices but it seems plausible to me.

[-- Attachment #2: Type: text/html, Size: 3344 bytes --]

Re: Excessively energy-consuming software considered malware?

[Attila Lendvai]

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

the moral argument has been spelled out nicely already.

let me add, though, that a more apples-to-apples comparison here would be to compare Bitcoin to the FED, and PoW to the costs of enforcing the PetroDollar system on the entire world.

these costs not only include the direct environmental damages of wars and militaries. more generally, it also includes the costs of enforcing a certain economic structure globally, instead of potential better alternatives for facilitating cooperation between strangers that may very well promote peace and prosperity more effectively and efficiently than the current system.

and from that perspective i don't see the use of 'absurd amount' justified, by a large margin.

and the more some of us disagree with the above, the more appropriate it seems to have been to use 'controversial morality' by Martin.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“The bond that links your true family is not one of blood, but of respect and joy in each other's life. Rarely do members of one family grow up under the same roof.”
	— Richard Bach (1936–), 'Illusions: The Adventures of a Reluctant Messiah' (1977)

Re: Excessively energy-consuming software considered malware?

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

Attila Lendvai schreef op ma 21-02-2022 om 09:29 [+0000]:
> let me add, though, that a more apples-to-apples comparison here would be to
> compare Bitcoin to the FED, and PoW to the costs of enforcing the PetroDollar
> system on the entire world.

Here PetroDollar = US dollar and FED=US Federal Government?

> these costs not only include the direct environmental damages of wars and
> militaries. more generally, it also includes the costs of enforcing a certain
> economic structure globally, instead of potential better alternatives for
> facilitating cooperation between strangers that may very well promote peace and
> prosperity more effectively and efficiently than the current system.

If the US Government enforces the US Dollar with wars etc., then this
seems more a bug of the US than a benefit of Bitcoin to me.  Also, I
don't understand what you mean with ‘enforcing’ here.

Locally, in Belgium, I can use the Euro as currency.  The US isn't
forcing me to use the US dollar, in fact I have never seen a US dollar
in person and most (all?) local businesses accept the Euro as currency
and most physical shops wouldn't accept foreign currency(*).

I can also use the US dollar as currency to buy from overseas (after
trading Euro for US dollar, this happens automatically when
e-shopping), even though the US hasn't stationed military forces
at the banks to force the banks to allow converting Euro<->US dollar.

I'm not seeing any enforcement here, nor any need for enforcement to
make the US dollar a usable currency.

While the US would (does?) wage wars to force countries to trade with
the US (and perhaps force them to accept US dollar maybe?), I don't see
how Bitcoin would change this -- Bitcoin might change the currency used
for the forced trade, but not the existence of the forced trade.

(*) at least, I think so, I haven't ever tried.

> and from that perspective i don't see the use of 'absurd amount' justified, by a large margin.
> 
> and the more some of us disagree with the above, the more appropriate it seems to have been to use 'controversial morality' by Martin.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Excessively energy-consuming software considered malware?

[raingloom]

On Mon, 21 Feb 2022 14:06:07 +0100
Maxime Devos <maximedevos@telenet.be> wrote:

> Attila Lendvai schreef op ma 21-02-2022 om 09:29 [+0000]:
> > let me add, though, that a more apples-to-apples comparison here
> > would be to compare Bitcoin to the FED, and PoW to the costs of
> > enforcing the PetroDollar system on the entire world.  
> 
> Here PetroDollar = US dollar and FED=US Federal Government?
> 
> > these costs not only include the direct environmental damages of
> > wars and militaries. more generally, it also includes the costs of
> > enforcing a certain economic structure globally, instead of
> > potential better alternatives for facilitating cooperation between
> > strangers that may very well promote peace and prosperity more
> > effectively and efficiently than the current system.  
> 
> If the US Government enforces the US Dollar with wars etc., then this
> seems more a bug of the US than a benefit of Bitcoin to me.  Also, I
> don't understand what you mean with ‘enforcing’ here.
> 
> Locally, in Belgium, I can use the Euro as currency.  The US isn't
> forcing me to use the US dollar, in fact I have never seen a US dollar
> in person and most (all?) local businesses accept the Euro as currency
> and most physical shops wouldn't accept foreign currency(*).
> 
> I can also use the US dollar as currency to buy from overseas (after
> trading Euro for US dollar, this happens automatically when
> e-shopping), even though the US hasn't stationed military forces
> at the banks to force the banks to allow converting Euro<->US dollar.
> 
> I'm not seeing any enforcement here, nor any need for enforcement to
> make the US dollar a usable currency.
> 
> While the US would (does?) wage wars to force countries to trade with
> the US (and perhaps force them to accept US dollar maybe?), I don't
> see how Bitcoin would change this -- Bitcoin might change the
> currency used for the forced trade, but not the existence of the
> forced trade.
> 
> (*) at least, I think so, I haven't ever tried.
> 
> > and from that perspective i don't see the use of 'absurd amount'
> > justified, by a large margin.
> > 
> > and the more some of us disagree with the above, the more
> > appropriate it seems to have been to use 'controversial morality'
> > by Martin.  
> 
> Greetings,
> Maxime.

For some reason, assholes like Peter Thiel (co-founder of Palantir
among others) seem to love cryptocurrencies, so maybe remember to
mention that next time in comparisons with the US government. I think
something about the total lack of regulations and customer protections
appeals to his ilk, but what do I know. :)
As Folding Ideas put it (paraphrased): the problem is patterns of human
behaviour, it's what people do to eachother, not that the building they
do it in has the word "Bank" written on it.
If you haven't seen it, I really recommend it:
https://redirect.invidious.io/watch?v=YQ_xWvX1n9g

I'd much rather see Spritely's OCAP money and LETS take off than the
"everything is a stock market" future that cryptocurrency fans envision.

Anyways, IMHO a blanket ban on blockchain based cryptocurrency in Guix
is not necessarily the best step to take, but I also don't think we
should welcome all such packages with open arms. But if others want to
ban some of them, I won't complain.

Re: Excessively energy-consuming software considered malware?

[Attila Lendvai]

> Here PetroDollar = US dollar and FED=US Federal Government?


FED = Federal Reserve, the (private) central bank that issues the US Dollar for about a century now. interesting tidbit: originally 'a US Dollar' meant a specific amount of silver.

and the 'petrodollar' is a unique keyword that you can chose to research. it's way offtopic here, but very briefly: if you want to issue more fiat money, *and* you also want to avoid it going worthless in short term, then you need to arrange for a proportional demand for your new tokens.

one important pillar of that demand can come from making sure that most of the energy trade is settled in USD, and as a consequence of that, most of the large economic players will want to hold USD as reserves to cover their expected energy consumption. this can be an enormous driver of demand for USD (for a while). it's also worth mentioning here that blocking your account at the FED means getting cut off from most of the energy suppliers/consumers who cannot dare to risk a visit from the US military.

this model nicely explains most of the US wars in the last few decades, and many, otherwise hard to explain political phenomena (e.g. US - Saudi Arabia relations).

---

the monetary system is what facilitates cooperation among strangers, i.e. among a group of humans larger than the Dunbar's number (about 150 people). sound money is a kind of decentralized, anonymous reputation system (that can only track positive reputation, and the tokens serve as the proof). its primary role is to lock out non-cooperating agents from the fruits of cooperation.

cooperation -> specialization -> efficient agents -> wealthy society.

IOW, the monetary system fundamentally influences what our everyday existence looks like. and the more anomalies there are in the rules governing the acquisition of the tokens (e.g. someone is allowed to print it while others must work for it), the more twisted society will become.

i have plenty more to say, but i doubt there's general interest in having this discussion on guix-devel. i hope though, that i managed to incite some curiosity, because this topic has much more depth than you seem to be aware of, and blockchains/Bitcoin are only one piece of this puzzle.

essentially, it's a new battlefront between centralized command and decentralized consensus; between coercive hierarchies and voluntary networks.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Those who love peace must learn to organize as effectively as those who love war.”
	— Martin Luther King, Jr. (1929–1968, assassinated)