date:20220220

On 20.02.2022 22:02, Liliana Marie Prikler wrote:
> 
> "Sex is distinct from gender" is a common transphobic talking point. 
> 

Like I said I don't actually want to argue, but I really feel the need
to point out that what you seem to consider a transphobic talking point
is seen as a fundamental principle of feminism by many others, and that
long predates the contemporary transgender movement.

  "One is not born, but rather becomes, woman. No biological, psychic,
  or economic destiny defines the figure that the human female takes on
  in society; it is civilization as a whole that elaborates this
  intermediary product between the male and the eunuch that is called
  feminine."
-- Simone de Beauvoir, The Second Sex (1949), 2010 translation

This is one of the most iconic passages from the book (especially the
first sentence on its own), and the book is considered to be pretty
much one of the most important works in feminist history.

Given that, I find it somewhat baffling that distinguishing between sex
and gender is now apparently considered transphobic.  (This isn't the
first time I'm hearing that claim, but I was under the impression that
it's a very fringe position.)

Actually, I could swear that only about 5 years ago, "sex and gender are
*not* the same" was a very common thing transgender activists would say.
I might actually have learned that principle from trans activists before
reading up on feminist literature.

Anyhow, all that is only tangential to the topic at hand.  In context
of this topic, I want to mainly highlight one thing, which is that
regardless of what one thinks about gender as a social construct,
gender identity and expression, transgender identities, and so on,
there is undeniably a number of ways in which people born with female
anatomy have been and continue to be mistreated throughout history
and around the planet.  To acknowledge that has very little to do with
transgender identities, and at no point did I or will I argue that the
CoC should for instance exclude "gender identity" from the list.

Is it possible that we would meet in the middle on this topic and
acknowledge both perspectives?

-- 
Taylan

Re: [minor patch] Amend CoC

On 20.02.2022 22:37, Thiago Jung Bauermann wrote:
> 
> Taylan Kammer  writes:
> 
>> Just one remark for them: most women I know would think twice before
>> spending time trying to get into a community whose rules intentionally
>> don't acknowledge sex-based discrimination.
> 
> Honest question, because (IIUC) this is the whole point of having a CoC:
> 
> Do those women believe that “… harassment-free experience for everyone,
> regardless of … gender identity and expression, … or sexual identity and
> orientation.” would not cover any potential harassment that they could
> be subjected to while participating in Guix’s community?

If no characteristics were listed at all, it wouldn't matter, but if there's
a long list yet 'sex' is explicitly excluded, that seems rather hostile,
even if it doesn't mean that Guix maintainers would actually ignore
harassment that happened on the grounds of someone's sex.

Happy to talk more about this off-list.  As it stands I'm rather embarrassed
that this thread immediately blew up and wish I hadn't posted it at all now.

-- 
Taylan

Re: [minor patch] Amend CoC

2022-02-20 Thread Jonathan McHugh

Hi Liliana,

[dropping ML CC for this reply as its offtopic re Guix]

Thanks for the clarification.

Living in Belgium, this advert for bars/cafes always wrankles me:
```
cherche serveuse
```

It may be that Im missing some linguistic touches but I dont know why such 
gender inference is legal.

The francophone language doesnt fit in my head very well - my brain cant handle 
all these gender registers for every (effing) noun:
* Pencil - probably a male?
* Coffee - definately a male?
* large coffee - probably the same as a regular coffee?
* Tablecloth - male?
* Spacestation - ...female?

Its farcical, and weird that we tollerate gender specific nouns to be codified 
writ large across society.

Personally, Im getting better at using gender neutral nouns in English given 
this growing frustration. It takes time to undo such legacy habits but I 
consider that people should actively control language and alter it with greater 
autonomy.

Also, Im happy that Belgian laws allow for giving children both parents' 
surnames (which I did for mine), as well as establishing that wives should not 
have to lose their surname (almost wrote maidenname, g).

Dont get me started on weeklong knights and princesses themes at my childrens' 
school. My son picked up a lot of chauvanism very quickly from the 
'institution'.

Thanks all for an interesting thread, I appreciate your perspectives re trying 
to make people feel more confident in their own skin.

Jonathan

February 20, 2022 10:12 PM, "Liliana Marie Prikler"  
wrote:

> Salut Jonathan,
> 
> Am Sonntag, dem 20.02.2022 um 20:56 + schrieb Jonathan McHugh:
> 
>> Hi Liliana,
>> 
>> February 20, 2022 8:37 PM, "Liliana Marie Prikler"
>>  wrote:
>> Am Sonntag, dem 20.02.2022 um 19:45 +0100 schrieb Maxime Devos:
>> 
>>> 
>>> To me, this seems a rather contrived scenario though ...
>> 
>> In this "contrived" scenario Harold would still (intentionally or
>> otherwise) be discriminating Victor·ia over their gender by
>> publicly pointing out the disconnect between the two. In the daily
>> experience of trans people, such remarks typically serve to
>> invalidate their identities.
>> 
>> I notice the use of an an interpunct with your typing for Victor·ia.
>> 
>> Ive never noticed such a puncuation previously.
>> 
>> Is it a common typographic device for such instances of
>> identification?
>> It seems a beautiful technique for providing subtle signalling for
>> what can (unfortunately) be a sensitive area for communication.
> 
> Wikipedia has the following to say: "In modern French, the interpunct
> is sometimes used for gender-neutral writing, as in « les salarié·e·s »
> for « les salariés et les salariées » [1]." I personally picked it up
> after someone mentioned it in the IRC.
> 
> More generally speaking, there are few conventions that are really
> widely agreed upon. In my own country, there's at least three
> competing standards, so obviously borrowing from the French and
> introducing a fourth is the only right solution.
> 
> Bisous
> 
> [1] https://en.wikipedia.org/wiki/Interpunct#French

Re: [minor patch] Amend CoC

2022-02-20 Thread Thiago Jung Bauermann

Taylan Kammer  writes:

> Just one remark for them: most women I know would think twice before
> spending time trying to get into a community whose rules intentionally
> don't acknowledge sex-based discrimination.

Honest question, because (IIUC) this is the whole point of having a CoC:

Do those women believe that “… harassment-free experience for everyone,
regardless of … gender identity and expression, … or sexual identity and
orientation.” would not cover any potential harassment that they could
be subjected to while participating in Guix’s community?

-- 
Thanks
Thiago

Re: Documentation of what is appropriate for #guix?

2022-02-20 Thread Matt



  On Sun, 20 Feb 2022 13:36:30 -0500 Vagrant Cascadian  
wrote 

 > I admittedly forget to check the messages from chanserv for channels I
 > frequent regularly, having personally grown accustomed to the norms of
 > the channel...
 
In my opinion, it's easy to miss.  I had to actively look for it.  I use Emacs 
erc.  When I start that program and log in, I'm in a buffer for "Libera.Chat". 
I then do /join #guix. This opens a new buffer, hiding the "Libera.Chat" buffer 
and showing a new "#g...@libera.chat"   buffer. The ChanServ message is printed 
to the buried "Libera.Chat" buffer.  The "#g...@libera.chat" buffer on connect 
has a giant wall of text showing who's in the chat.  It causes the buffer to 
scroll to the bottom, hiding anything printed to the top.  Scrolling up, I see 
some links to various topics. I see no rules or guidelines there.
 
 > So yes, linking to the Free System Distribution Guidelines implies what
 > is off-topic, though is still maybe not targeted towards online
 > communications; it more appears to be written with the audience of
 > someone making a free software distribution or auditing one. It seems
 > like the most relevent passage is:
 > 
 >   "A free system distribution must not steer users towards obtaining any
 >   nonfree information for practical use, or encourage them to do so. The
 >   system should have no repositories for nonfree software and no
 >   specific recipes for installation of particular nonfree programs. Nor
 >   should the distribution refer to third-party repositories that are not
 >   committed to only including free software; even if they only have free
 >   software today, that may not be true tomorrow. Programs in the system
 >   should not suggest installing nonfree plugins, documentation, and so
 >   on."
 > 
 > People often miss the part about not indirectly referring to non-free
 > software. Even if pointed to the FSDG, it is admittedly a bit hard to
 > grasp at times just what exactly constitutes "steer users towards
 > obtaining any nonfree information for practical use" or how it applies
 > to, say IRC. Individuals in IRC are not "the distribution", though the
 > new and long-time community members obviously make up perhaps the most
 > imporant part of the distribution.

I agree, it's hard to miss within the FSDG. Aside from linked (and not on a 
main screen), it's several sections down within the FSDG. 

 > I only bring this up because I regularly see this come up in the IRC
 > channel, and if an issue frequently comes up, usually that is a sign
 > that something could be improved in documentation, website, tooling,
 > etc. ... and when asked for one, I didn't have a good summary to point
 > to in my toolbox.
 > 
 > 
 > Maybe it is now my job to propose something concrete, but I was
 > curious what others thought before diving into details. :)

I think your observation matches what I've seen and I think your suggestion to 
address the problem makes sense.  If you know how to and where to do this, 
great. I wish I could be of more help.  I'm only able to cheer you on and give 
opinions.

Re: [minor patch] Amend CoC

2022-02-20 Thread Blake Shaw

Liliana Marie Prikler  writes:

>> To me, this seems a rather contrived scenario though ...
> In this "contrived" scenario Harold would still (intentionally or
> otherwise) be discriminating Victor·ia over their gender by publicly
> pointing out the disconnect between the two.  In the daily experience
> of trans people, such remarks typically serve to invalidate their
> identities.
>

I agree, and given that so-called "men's rights activist" types have
time and time again used this type of argumentation to veil attacks on
trans women under the guise of feminism, it should be rejected. people's
sexual identities are already addressed as protected, and this is meant to
protect all women, not only some of them.

also I think when a man suggests making a changing to conduct regarding
women, and a woman says "hold up thats not protecting me", and no other
women come forward to defend the proposal, it should be obvious that
the "debate" need not move forward. 

-- 
“In girum imus nocte et consumimur igni”

Re: [minor patch] Amend CoC

Salut Jonathan,

Am Sonntag, dem 20.02.2022 um 20:56 + schrieb Jonathan McHugh:
> Hi Liliana,
> 
> February 20, 2022 8:37 PM, "Liliana Marie Prikler"
>  wrote:
> > Am Sonntag, dem 20.02.2022 um 19:45 +0100 schrieb Maxime Devos:
> 
> > > 
> > > To me, this seems a rather contrived scenario though ...
> > 
> > In this "contrived" scenario Harold would still (intentionally or
> > otherwise) be discriminating Victor·ia over their gender by
> > publicly pointing out the disconnect between the two. In the daily
> > experience of trans people, such remarks typically serve to
> > invalidate their identities.
> 
> I notice the use of an an interpunct with your typing for Victor·ia.
> 
> Ive never noticed such a puncuation previously. 
> 
> Is it a common typographic device for such instances of
> identification?
> It seems a beautiful technique for providing subtle signalling for
> what can (unfortunately) be a sensitive area for communication.
Wikipedia has the following to say: "In modern French, the interpunct
is sometimes used for gender-neutral writing, as in « les salarié·e·s »
for « les salariés et les salariées » [1]."  I personally picked it up
after someone mentioned it in the IRC.

More generally speaking, there are few conventions that are really
widely agreed upon.  In my own country, there's at least three
competing standards, so obviously borrowing from the French and
introducing a fourth is the only right solution.

Bisous

[1] https://en.wikipedia.org/wiki/Interpunct#French

Re: [minor patch] Amend CoC

Hi Mark,

Am Sonntag, dem 20.02.2022 um 14:47 -0500 schrieb Mark H Weaver:
> Hi Liliana,
> 
> Liliana Marie Prikler  writes:
> 
> > > Note: The upstream Contributor Covenant wouldn't want to include
> > > it because the author seems to have a peculiar world-view where
> > > they don't acknowledge that humans actually have a sex.  I hope
> > > the Guix maintainers are more reasonable than that. :-)
> > Sorry, but tracking down the issue you submitted towards the
> > contributor covenant, it appears to me that you are the misguided
> > one.
> > The CoC already prohibits discrimination based on gender identity,
> > sexual identity and sexual orientation.  If you identify your
> > gender as your sex, whatever that might be, you are thereby already
> > protected.
> > 
> > The wording you chose (intentionally or otherwise) tries to
> > invalidate other people's gender identity and thus violates the
> > CoC.
> 
> Can you please point out which of Taylan's words "tries to invalidate
> other people's gender identity", and explain how you reached that
> conclusion from the words you cite?
"Sex is distinct from gender" is a common transphobic talking point. 
Biologically speaking, there are already multiple ways of looking at
sex (chromosomes, particular features, hormones, ...), none of which
really map to the colloquial use of the word.

For example, you might point to some dictionary definition of "man" as
"an adult human male" and while we have a more or less clear
understanding of what a human is, neither "adult" nor "male" mean the
same things across different communities or more broadly speaking
cultures.  While we in Guix would very much accept a trans man as both
being a man and male, the bio-essentialist will point to this
definition and say "aha! you're not a man because you don't have a
penis" or in some cases even "because you don't have XY chromosomes",
completely ignoring how others interpret either term.

For this reason, I find it not very helpful to welcome such debate in
Guix' spaces and would like to avoid it if possible.  Taylan linked the
upstream issue and in my personal opinion, upstream has a good reason
to reject the proposal.

Cheers

Re: [minor patch] Amend CoC

2022-02-20 Thread Jonathan McHugh

Hi Liliana,

February 20, 2022 8:37 PM, "Liliana Marie Prikler"  
wrote:
> Am Sonntag, dem 20.02.2022 um 19:45 +0100 schrieb Maxime Devos:

>> 
>> To me, this seems a rather contrived scenario though ...
> 
> In this "contrived" scenario Harold would still (intentionally or
> otherwise) be discriminating Victor·ia over their gender by publicly
> pointing out the disconnect between the two. In the daily experience
> of trans people, such remarks typically serve to invalidate their
> identities.

I notice the use of an an interpunct with your typing for Victor·ia.

Ive never noticed such a puncuation previously. 

Is it a common typographic device for such instances of identification?
It seems a beautiful technique for providing subtle signalling for what can 
(unfortunately) be a sensitive area for communication.

Jonathan McHugh
indieterminacy@libre.brussels

Re: Excessively energy-consuming software considered malware?

2022-02-20 Thread Martin Becze

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.

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

Re: Excessively energy-consuming software considered malware?

2022-02-20 Thread Jonathan McHugh

Hello Maxime,

February 20, 2022 1:37 PM, "Maxime Devos"  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: [minor patch] Amend CoC

2022-02-20 Thread Mark H Weaver

Hi Liliana,

Liliana Marie Prikler  writes:

>> Note: The upstream Contributor Covenant wouldn't want to include it
>> because the author seems to have a peculiar world-view where they
>> don't acknowledge that humans actually have a sex.  I hope the Guix
>> maintainers are more reasonable than that. :-)
> Sorry, but tracking down the issue you submitted towards the
> contributor covenant, it appears to me that you are the misguided one.
> The CoC already prohibits discrimination based on gender identity,
> sexual identity and sexual orientation.  If you identify your gender as
> your sex, whatever that might be, you are thereby already protected.
>
> The wording you chose (intentionally or otherwise) tries to invalidate
> other people's gender identity and thus violates the CoC.

Can you please point out which of Taylan's words "tries to invalidate
other people's gender identity", and explain how you reached that
conclusion from the words you cite?

  Thanks,
Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

Re: [minor patch] Amend CoC

On 20.02.2022 19:05, Liliana Marie Prikler wrote:
>> Note: The upstream Contributor Covenant wouldn't want to include it
>> because the author seems to have a peculiar world-view where they
>> don't acknowledge that humans actually have a sex.  I hope the Guix
>> maintainers are more reasonable than that. :-)
> Sorry, but tracking down the issue you submitted towards the
> contributor covenant, it appears to me that you are the misguided one.
> The CoC already prohibits discrimination based on gender identity,
> sexual identity and sexual orientation.  If you identify your gender as
> your sex, whatever that might be, you are thereby already protected.
> 
> The wording you chose (intentionally or otherwise) tries to invalidate
> other people's gender identity and thus violates the CoC.
> 
> Cheers

I had really hoped this would be an uncontroversial suggestion...

It might be useful to provide a link in case others want to take a look at
the debate as well:

https://github.com/EthicalSource/contributor_covenant/pull/548

I've said everything there I'd say now if I were to argue back, and I really
don't want to argue about this on a Guix ML anyway, so I'll leave it to the
maintainers to decide what to do.  Just one remark for them: most women I
know would think twice before spending time trying to get into a community
whose rules intentionally don't acknowledge sex-based discrimination.

-- 
Taylan

Re: Excessively energy-consuming software considered malware?

2022-02-20 Thread Ryan Sundberg

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

Re: [minor patch] Amend CoC

Hi Maxime,

Am Sonntag, dem 20.02.2022 um 19:45 +0100 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op zo 20-02-2022 om 19:05 [+0100]:
> > > Note: The upstream Contributor Covenant wouldn't want to include
> > > it because the author seems to have a peculiar world-view where
> > > they don't acknowledge that humans actually have a sex.  I hope
> > > the Guix maintainers are more reasonable than that. :-)
> > Sorry, but tracking down the issue you submitted towards the
> > contributor covenant, it appears to me that you are the misguided
> > one.
> > The CoC already prohibits discrimination based on gender identity,
> > sexual identity and sexual orientation.  If you identify your
> > gender as your sex, whatever that might be, you are thereby already
> > protected.
> > 
> > The wording you chose (intentionally or otherwise) tries to
> > invalidate other people's gender identity and thus violates the
> > CoC.
> 
> Ignoring upstream's context and whether Taylan Kammer is misguided or
> not, listing sex among the list could be useful if a potential
> harasser H who understands the difference between sex and gender and
> knows that V has sex A not corresponding to gender B under current
> social convention, and H would harass V over their sex (but H is fine
> with V's gender).
> 
> To me, this seems a rather contrived scenario though ...
In this "contrived" scenario Harold would still (intentionally or
otherwise) be discriminating Victor·ia over their gender by publicly
pointing out the disconnect between the two.  In the daily experience
of trans people, such remarks typically serve to invalidate their
identities.

Re: Excessively energy-consuming software considered malware?

2022-02-20 Thread Christine Lemmer-Webber

Taylan Kammer  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: [minor patch] Amend CoC

Liliana Marie Prikler schreef op zo 20-02-2022 om 19:05 [+0100]:
> > Note: The upstream Contributor Covenant wouldn't want to include it
> > because the author seems to have a peculiar world-view where they
> > don't acknowledge that humans actually have a sex.  I hope the Guix
> > maintainers are more reasonable than that. :-)
> Sorry, but tracking down the issue you submitted towards the
> contributor covenant, it appears to me that you are the misguided
> one.
> The CoC already prohibits discrimination based on gender identity,
> sexual identity and sexual orientation.  If you identify your gender
> as
> your sex, whatever that might be, you are thereby already protected.
> 
> The wording you chose (intentionally or otherwise) tries to
> invalidate
> other people's gender identity and thus violates the CoC.

Ignoring upstream's context and whether Taylan Kammer is misguided or
not, listing sex among the list could be useful if a potential harasser
H who understands the difference between sex and gender and knows that
V has sex A not corresponding to gender B under current social
convention, and H would harass V over their sex (but H is fine with V's
gender).

To me, this seems a rather contrived scenario though ...

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Documentation of what is appropriate for #guix?

2022-02-20 Thread Vagrant Cascadian

On 2022-02-19, m...@excalamus.com wrote:
>   On Sat, 19 Feb 2022 21:33:47 -0500 Vagrant Cascadian 
>  wrote 
>  > Every now and then someone stumbles into #guix and ask questions that
>  > I've gleaned over time are off-topic (e.g. non-free software). While I
>  > have a pretty good idea what is appropriate for the channel, it is not
>  > clear to me where that is documentated.
>
> I see the following when I connect to #guix:
>
> -ChanServ- [#guix] Welcome to #guix, home of the GNU Guix project! | Be kind
>to everyone. Ground rules:
> |
>Non-free software is off-topic:
>
> 
>| Leave messages with sneek: /msg sneek help

I admittedly forget to check the messages from chanserv for channels I
frequent regularly, having personally grown accustomed to the norms of
the channel...

So yes, linking to the Free System Distribution Guidelines implies what
is off-topic, though is still maybe not targeted towards online
communications; it more appears to be written with the audience of
someone making a free software distribution or auditing one. It seems
like the most relevent passage is:

  "A free system distribution must not steer users towards obtaining any
  nonfree information for practical use, or encourage them to do so. The
  system should have no repositories for nonfree software and no
  specific recipes for installation of particular nonfree programs. Nor
  should the distribution refer to third-party repositories that are not
  committed to only including free software; even if they only have free
  software today, that may not be true tomorrow. Programs in the system
  should not suggest installing nonfree plugins, documentation, and so
  on."

People often miss the part about not indirectly referring to non-free
software. Even if pointed to the FSDG, it is admittedly a bit hard to
grasp at times just what exactly constitutes "steer users towards
obtaining any nonfree information for practical use" or how it applies
to, say IRC. Individuals in IRC are not "the distribution", though the
new and long-time community members obviously make up perhaps the most
imporant part of the distribution.

I only bring this up because I regularly see this come up in the IRC
channel, and if an issue frequently comes up, usually that is a sign
that something could be improved in documentation, website, tooling,
etc. ... and when asked for one, I didn't have a good summary to point
to in my toolbox.

Maybe it is now my job to propose something concrete, but I was
curious what others thought before diving into details. :)

live well,
  vagrant

signature.asc
Description: PGP signature

Re: Excessively energy-consuming software considered malware?

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: [minor patch] Amend CoC

> Note: The upstream Contributor Covenant wouldn't want to include it
> because the author seems to have a peculiar world-view where they
> don't acknowledge that humans actually have a sex.  I hope the Guix
> maintainers are more reasonable than that. :-)
Sorry, but tracking down the issue you submitted towards the
contributor covenant, it appears to me that you are the misguided one.
The CoC already prohibits discrimination based on gender identity,
sexual identity and sexual orientation.  If you identify your gender as
your sex, whatever that might be, you are thereby already protected.

The wording you chose (intentionally or otherwise) tries to invalidate
other people's gender identity and thus violates the CoC.

Cheers

Semantics of circular imports

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


signature.asc
Description: This is a digitally signed message part

Re: [minor patch] Amend CoC

Thinking about it from the perspective of people that want to join the project 
and are not potential harassers makes more sense.
They will feel their problems are understood.

Thanks for elaborating with that beautiful quote. It makes total sense.

Ekaitz

Re: Excessively energy-consuming software considered malware?

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:

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

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.

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.

signature.asc
Description: This is a digitally signed message part

Re: unbound-service-type

2022-02-20 Thread Josua Stingelin

Hi Ludo,

Thank you for your reply!

> I’d recommend passing the config file directly, as in:
> 
>   "-c" #$(local-file "unbound.conf")

Doing that now.

> > However when I add these to my operating-system configuration, and copy the
> > configuration file using the etc-service-type it doesn't run on start.
> 
> Do you have additional info as to why it doesn’t start?  Perhaps error
> messages in /var/log/messages or something?

Turns out unbound segfaults when chrooting to a read-only directory. And if one
doesn't explicitly turn off the chroot it tries to chroot to 
"/../etc" (or something similar).

  unbound[1407]: segfault at ffb8 ip 7fd6498ecd67 sp 
7fffa4366550 error 5 in libc-2.33.so[7fd64984f000+141000]


Should I report this upstream - or is this considered a configuration issue?


I've gotten the service up and running. Going to try and generate the
configuration file based on the scheme configuration next.


Thank you for your help and sorry for posting pre-maturely. I suppose searching
a bit longer would have gotten me on track anyway.

Kind Regards,

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

2022-02-20 Thread Philip McGrath

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 [+]:
> > 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
, 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 —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

Re: [minor patch] Amend CoC

On 20.02.2022 14:16, Ekaitz Zarraga wrote:
> I have a weird question about this that might be a little bit offtopic.
> 
> Why should we specify reasons? It's like we are saying some reasons are more 
> important than others.
> 
> Is it not ok with...
> 
>> our project and our community a harassment-free experience for *everyone*.
> 
> ?
> 
> That should cover everything.
> I don't think anyone is reading all the list and saying: "oh they are missing 
> race so it's ok for a racist like me to join and harass people"
> 
> It's just a feeling. It would also remove the discussion about including sex 
> or not.
> 
> WDYT?
> 

I wouldn't have an issue with that personally, but I think it's meant to
make it clear that the maintainers are aware of various specific ways in
which people are commonly discriminated against in practice, to make it
clear that the commitment to anti-harassment is not just theoretical.

Not sure how to best describe what I mean, but one could use the following
analogy: why are there activists who see themselves as feminists, instead
of as humanists / human rights activists in general?  I'll just use a quote
from someone who's more eloquent than me:

  "Some people ask: “Why the word feminist? Why not just say you are a believer
  in human rights, or something like that?” Because that would be dishonest.
  Feminism is, of course, part of human rights in general—but to choose to use
  the vague expression human rights is to deny the specific and particular
  problem of gender. It would be a way of pretending that it was not women who
  have, for centuries, been excluded. It would be a way of denying that the
  problem of gender targets women."  -- Chimamanda Ngozi Adichie

-- 
Taylan

Re: [minor patch] Amend CoC

On 20.02.2022 14:10, Julien Lepiller wrote:
> Sounds good, but isn't that included in "sexual identity" already? For 
> reference, where does the author say that?

Apparently "sexual identity" is more like sexual orientation:

https://en.wikipedia.org/wiki/Sexual_identity

-- 
Taylan

Re: Compiling blender



> Ekaitz Zarraga eka...@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: Compiling blender

2022-02-20 Thread Ricardo Wurmus

Ekaitz Zarraga  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: Excessively energy-consuming software considered malware?

2022-02-20 Thread Paul Jewell

> On 20 Feb 2022, at 10:07, 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?
> 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?

2022-02-20 Thread 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: [minor patch] Amend CoC

I have a weird question about this that might be a little bit offtopic.

Why should we specify reasons? It's like we are saying some reasons are more 
important than others.

Is it not ok with...

> our project and our community a harassment-free experience for everyone.

?

That should cover everything.
I don't think anyone is reading all the list and saying: "oh they are missing 
race so it's ok for a racist like me to join and harass people"

It's just a feeling. It would also remove the discussion about including sex or 
not.

WDYT?
--- Original Message ---
On Sunday, February 20th, 2022 at 2:10 PM, Julien Lepiller  
wrote:

> Sounds good, but isn't that included in "sexual identity" already? For 
> reference, where does the author say that?
>
> On February 20, 2022 2:02:07 PM GMT+01:00, Taylan Kammer 
>  wrote:
>
>> This is a really tiny thing.  A recent thread on the ML prompted me to
>>
>> look at our CoC and I noticed it doesn't include 'sex' in the list of
>>
>> things based on which one might be discriminated against, so attached
>>
>> is a patch that adds that one word.
>>
>> Note: The upstream Contributor Covenant wouldn't want to include it
>>
>> because the author seems to have a peculiar world-view where they don't
>>
>> acknowledge that humans actually have a sex.  I hope the Guix maintainers
>>
>> are more reasonable than that. :-)
>>
>> --
>>
>> Taylan

Re: [minor patch] Amend CoC

2022-02-20 Thread Julien Lepiller

Sounds good, but isn't that included in "sexual identity" already? For 
reference, where does the author say that?

On February 20, 2022 2:02:07 PM GMT+01:00, Taylan Kammer 
 wrote:
>This is a really tiny thing.  A recent thread on the ML prompted me to
>look at our CoC and I noticed it doesn't include 'sex' in the list of
>things based on which one might be discriminated against, so attached
>is a patch that adds that one word.
>
>Note: The upstream Contributor Covenant wouldn't want to include it
>because the author seems to have a peculiar world-view where they don't
>acknowledge that humans actually have a sex.  I hope the Guix maintainers
>are more reasonable than that. :-)
>
>-- 
>Taylan

[minor patch] Amend CoC

This is a really tiny thing.  A recent thread on the ML prompted me to
look at our CoC and I noticed it doesn't include 'sex' in the list of
things based on which one might be discriminated against, so attached
is a patch that adds that one word.

Note: The upstream Contributor Covenant wouldn't want to include it
because the author seems to have a peculiar world-view where they don't
acknowledge that humans actually have a sex.  I hope the Guix maintainers
are more reasonable than that. :-)

-- 
TaylanFrom 3e7577ab3265ae61df7bb152d1bb843e375fa35b Mon Sep 17 00:00:00 2001
From: Taylan Kammer 
Date: Sun, 20 Feb 2022 13:28:30 +0100
Subject: [PATCH] CODE-OF-CONDUCT: Add 'sex' to protected characteristics.

---
 CODE-OF-CONDUCT | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CODE-OF-CONDUCT b/CODE-OF-CONDUCT
index ef90330cda..c1dcf3d144 100644
--- a/CODE-OF-CONDUCT
+++ b/CODE-OF-CONDUCT
@@ -9,7 +9,7 @@ In the interest of fostering an open and welcoming environment, 
we as
 contributors and maintainers pledge to making participation in our project and
 our community a harassment-free experience for everyone, regardless of age, 
body
 size, disability, ethnicity, gender identity and expression, level of 
experience,
-education, socio-economic status, nationality, personal appearance, race,
+education, socio-economic status, nationality, personal appearance, race, sex,
 religion, or sexual identity and orientation.
 
 Our Standards
-- 
2.30.2

Re: Excessively energy-consuming software considered malware?

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

Expensive builds when computing channel instance derivations

2022-02-20 Thread Christopher Baines

Hey,

Back in early 2021, I was trying to address the issues the Guix Data
Service has when trying to compute channel instance derivations for
various systems [1].

1: https://issues.guix.gnu.org/47989

Some changes did some out of that, and I believe the helped, but even
with those changes, being able to build things for the system you want
to compute the channel instance derivation for seemed to remain
necessary.

This poses an operational issue for things like data.guix.gnu.org, since
it can only compute channel instance derivations for systems it can
build for, which in practice means that it's limited by the systems
which QEMU emulation is enabled for. Even for those systems it can build
for, because builds can happen when attempting to compute these
derivations, it means that data.guix.gnu.org spends a lot of time
waiting for builds to complete, just so it can store these derivations.

I have a suspicion that this issue is a big contributor to the
data.guix.gnu.org slowness when processing new revisions, so I tried to
dig in to it more recently as I didn't know why these builds were
happening.

I think I figured out that it's related to grafts. I've attached a test
script which computes the channel instance derivation for mips64el-linux
which I'm not set up to build things for (if you can build for
mips64el-linux, replace this with a system you can't build for). You'll
need to use the attached patch (also present on [2]) when running this
script.

2: https://git.cbaines.net/guix/log/?h=channel-instances-manifest-graft-control

When I run this script locally, it first succeeds in computing the
channel instance derivation when grafts are disabled, but then fails
when grafts are enabled:

  while setting up the build environment: a `mips64el-linux' is required
  to build
  `/gnu/store/g40shyhsd00r5dq3mm76c2b1krnr1njh-guile-bootstrap-2.0.drv',
  but I am a `x86_64-linux'

Even though I think this shows that grafts are involved, I'm not sure
what this means? I'm guessing that the effects of grafts aren't as clear
cut as for packages here, since the grafts are happening here as part of
computing a derivation I'm guessing that the derivation is actually
built with the grafted outputs, which differs from how grafts affect
packages. Given this, I guess computing the derivation without grafts
means that the replacements that would be grafted in are just not used
at all.

To recap on my aim here, I really just want to be able to compute
channel instance derivations without performing any expensive builds, or
if that's not possible, it would be good to understand why?

Thanks,

Chris


From 38a12f0f22841b76050a0cf5163cdc65b7f92193 Mon Sep 17 00:00:00 2001
From: Christopher Baines 
Date: Fri, 18 Feb 2022 23:06:57 +
Subject: [PATCH] channels: Allow disabling grafts when computing derivations.

---
 build-aux/build-self.scm | 23 +++
 guix/channels.scm| 19 +++
 2 files changed, 26 insertions(+), 16 deletions(-)

diff --git a/build-aux/build-self.scm b/build-aux/build-self.scm
index 02822a2ee8..0e7fc2907d 100644
--- a/build-aux/build-self.scm
+++ b/build-aux/build-self.scm
@@ -241,7 +241,8 @@ (define guile-gcrypt
 
 (define* (build-program source version
 #:optional (guile-version (effective-version))
-#:key (pull-version 0) (channel-metadata #f))
+#:key (pull-version 0) (channel-metadata #f)
+(graft? #t))
   "Return a program that computes the derivation to build Guix from SOURCE."
   (define select?
 ;; Select every module but (guix config) and non-Guix modules.
@@ -316,6 +317,8 @@ (define fake-git
 (read-disable 'positions))
 
   (use-modules (guix store)
+   (guix grafts)
+   (guix monads)
(guix self)
(guix derivations)
(srfi srfi-1))
@@ -348,12 +351,14 @@ (define fake-git
  (%make-void-port "w"))
 (current-build-output-port sock))
(run-with-store store
- (guix-derivation source version
-  #$guile-version
-  #:channel-metadata
-  '#$channel-metadata
-  #:pull-version
-  #$pull-version)
+ (mbegin %store-monad
+   (set-grafting #$graft?)
+   (guix-derivation source version
+#$guile-version
+

Re: Excessively energy-consuming software considered malware?

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.


signature.asc
Description: This is a digitally signed message part

Re: Excessively energy-consuming software considered malware?

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

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

Ekaitz Zarraga schreef op zo 20-02-2022 om 11:34 [+]:
> 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.


signature.asc
Description: This is a digitally signed message part

Expat 2.4.5 with security fixes released

2022-02-20 Thread Sebastian Pipping


Hello everyone!


Expat 2.4.5 with security fixes has been released.

Please note that different people evaluate the impact of security issues 
differently: 2 of those 5 vulnerability allow proven code execution not 
within Expat but in (some) applications using Expat, and hence they are 
"critical" on my personal scale while e.g. Ubuntu considers these two as 
"low" and "medium" respectively, only.  I have contacted Ubuntu security 
about that earlier today but have yet to hear back.


There will be a summary blog post at [1] and the change log is at [2] 
with more details already.


If you have patches for Expat that are still required with version
2.4.5, please send them my way.  Thank you!

Best



Sebastian


[1] https://blog.hartwork.org/posts/expat-2-4-5-released/
[2] https://github.com/libexpat/libexpat/blob/R_2_4_5/expat/Changes

Re: Compiling blender



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

Re: Excessively energy-consuming software considered malware?

2022-02-20 Thread Martin Becze

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

Compiling blender

2022-02-20 Thread Ricardo Wurmus



Ekaitz Zarraga  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 nd 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: Excessively energy-consuming software considered malware?

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 nd finally blender.

All that with my CPU to 100%.

Is Guix malware?

Cheers,
Ekaitz

How to run a command before shutdown.

2022-02-20 Thread tumashu

Hello:


 I want to run "rmmod mt7921e" before shutdown, how to setup in guix system?


Thanks!

Re: Excessively energy-consuming software considered malware?

2022-02-20 Thread 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

Excessively energy-consuming software considered malware?