unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Leo Prikler <leo.prikler@student.tugraz.at>
To: Pjotr Prins <pjotr.public12@thebird.nl>
Cc: guix-devel@gnu.org
Subject: Re: Meta Guix: why guix is awesome!
Date: Thu, 29 Apr 2021 11:50:13 +0200	[thread overview]
Message-ID: <ccd3d2731cea2de1c7f18d27aaab0ef26a8ae888.camel@student.tugraz.at> (raw)
In-Reply-To: <20210429054404.tpyl6qj35s3b6ezy@thebird.nl>

Hi Pjotr,

Am Donnerstag, den 29.04.2021, 07:44 +0200 schrieb Pjotr Prins:
> Hi Leo (Prikler),
> 
> On Thu, Apr 29, 2021 at 01:52:12AM +0200, Leo Prikler wrote:
> > I don't know enough about marketing to give you a good answer on
> > that,
> > but when it comes to what we're competing against, it seems to be a
> > rather uphill battle outside of the small bubble, that we've carved
> > out.  According to distrowatch we're still far away from Nix and
> > back
> > when I was using Gentoo I thought that was some super niche distro.
> 
> As Guix is now also a Debian package I think it is doing extremely
> well. I know people who are silently introducing Guix :). As a full
> distro it may be niche, but it is also very successful because it
> keeps growing and growing. Nix has a 10 years head start (I was
> there)
> and does better in industry, but it does not mean it wil be ahead in
> another 10 years.
> 
> Look where Linux came from.
Point taken, we do still get some complaints from people running Guix
on foreign distros and how we violate the expectations of those
distros.  But I do think sooner or later those would end up bumping
statistics based on search terms at least a little.

> > Guix may perhaps not be the smallest package manager (to be honest,
> > I have no way of telling as it's the only one I'm involved in), but
> > I can definitely say, that it does things well, so your point about
> > violating Unix philosophy is invalidated :P
> 
> Guix abides by the Unix philosophy in many ways. All the tools (or
> their invocations) do the minimum. It is actually an interesting
> mixture of composition and isolation. Guix has the advantage of
> learning from other attempts. But think about the Guix choice of
> shepherd over systemd: systemd is not a tool in the spirit of Unix
> (in my opinion) because it tries to think for you and can be
> unpredictable :). Guix' focus is on being predictable and hackable -
> i.e., very Unix spirited.
I respectfully disagree, building a profile (or even better a system)
is in no way "minimal", but it also doesn't need to be.  Package
management by Guix is appealing exactly because it *can* handle
everything, particularly configuration in the case of Guix System, in
the same way that service management through systemd is appealing to
some because it *can* unify a lot of common concerns into one monolith.
"Being predictable" is not a quality unique to Unix nor is it a quality
guaranteed by Unix.  Also we get a lot of unpredicted backtraces :)

> > Which ties back to point 2.  Guix aims to be inclusive and being
> > inclusive means toning down the rudeness.
> 
> That is true. Though rudeness can also serve a purpose (Linus comes
> to mind though he is trying to tone down the last years) and some
> people can't help it. We walk a fine line here when we tell people to
> be less rude and lose some value if we can not be honest. There is a
> cultural angle for sure. The Fins, Dutch, Russians and Germans can be
> honest in their language, but that appears as rude in English. Common
> English can be extremely rude in Japanese. I think, in an
> intercultural sense, we ought to strive for not taking everything at
> face value, and try reading beyond the surface. Some people are in
> the autistic spectrum, do we shut them down and have them not
> participate? I don't think that is particularly inclusive either. 
As a German native speaker learning Japanese, I am aware of some
cultural tendencies, e.g. the polite rejection of a proposal.  When it
comes to being rude, the onus is absolutely on the person being rude to
read the room.

> Even so, if someone crosses a line with intent to hurt we should have
> policies that protect the attacked. That is civil.  But I'd argue
> against judging people by popular opinion. Courts of law are there to
> judge badness.  Likewise, projects have policies and a code of
> conduct. We should abide by those (the alternative being that people
> can decide not to participate with the project). It is very hard,
> perhaps impossible, to defend yourself against (perceived) popular
> opinion.
> 
> Character assassination on the internet is all to common now. What we
> should aim for is trying to keep discussion technical in a technical
> project, even is it is in reality also a social experiment - as all
> of free software is and even humanity as a whole. The good news is
> that almost all our discussions and choices can be technical.
I think you might have misunderstood me her a bit, so let me rephrase
that: I wasn't trying to advocate for lengthy, mostly political
discussions in the mailing lists, but what I am trying to say, is that
whenever people do express opinions, when those opinions are harmful
(whether or not they are popular) we ought to stop them from spreading.

> > - I don't think anyone has ever been offended by trees – it's
> > usually the other way round – but there are (some reasonable and
> > some less reasonable) arguments to support one's fear of spiders,
> > both physical and digital.
> 
> We had a cat that got stuck in a tree once. Since that time he looked
> up and we could virtually see him think: trees are evil. He never
> went up again.
I don't know your cat, but it could very well be possible, that your
interpretation is exaggerated.  You can be afraid of someone or
something without assuming ill intent.  For instance, I am afraid, that
Raghav might inadvertently push a poorly reviewed piece of code
(especially in haste), but I also fear I myself might do harm, when in
a few days I'll be forced to merge wip-emacs with only the knowledge,
that no one has so far complained about my latest patch set.

> Being inclusive actually implies celebrating our differences. 
That is true in the general case, but I just wanted to point out
exceptions so as to make people aware of them.

Regards,
Leo



      reply	other threads:[~2021-04-29  9:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-28 17:20 Meta Guix: why guix is awesome! Joshua Branson
2021-04-28 23:52 ` Leo Prikler
2021-04-29  5:44   ` Pjotr Prins
2021-04-29  9:50     ` Leo Prikler [this message]

Reply instructions:

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

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

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

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

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

  git send-email \
    --in-reply-to=ccd3d2731cea2de1c7f18d27aaab0ef26a8ae888.camel@student.tugraz.at \
    --to=leo.prikler@student.tugraz.at \
    --cc=guix-devel@gnu.org \
    --cc=pjotr.public12@thebird.nl \
    /path/to/YOUR_REPLY

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

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

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

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