Re: Clarifying blog post licensing

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

> With a few exceptions, our blog posts do not have a license, which is
> not great

Good catch, I agree!

Janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: Return back original implementation for text-config serialization

[Maxim Cournoyer]

Hi Andrew,

Andrew Tropin  writes:

[...]

> Ludovic mentioned someday that nginx-configuration is problematic, but I
> highlighted the generic problems, which are applicable for many other
> guix service configurations.
>
> I discussed some other pros and cons of record-based configurations in
> https://issues.guix.gnu.org/52698
>
> and I see the benifits of the records, but I'm not sure if they
> outweight the weaknesses.
>
> It maybe sound unrelated to this thread, but it's actually very ontopic,
> because it lead to the design and implementation of home services
> configuration approach in general and slurp-file-gexp and text-config in
> particular.

Pardon my ignorance about Guix Home, but couldn't we have configuration
as records by default, and the lower level, config stitching primitives
still available to hand craft strings that could be used as the value of
an 'extra-config' field, for example?

It seems to me the use of records for configurations in Guix Home would
be the natural choice, as Guix System users are already familiar with
them and it leans to better discoverability/documentation.

Thanks,

Maxim

Re: The way to promote GUIX package manager

[Vagrant Cascadian]

On 2022-01-27, Yasuaki Kudo wrote:
> Does Guix really run out of the box in Debian?
>
> I have never tried it but my friend Debian expert friend keeps telling me 
> that:
>
> * Just apt-get installing Guix doesn't work

What doesn't work?

The main two issues I'm aware of are...

Issue with "guix pull" from the guix 1.2 version:

  https://bugs.debian.org/1001833

The workaround is to first pull to the guix 1.3 commit.


The other issue has to do with incompatible glib versions in guix and
Debian:

  https://bugs.debian.org/988260

I'm not aware of a workaround there other than sticking with either Guix
or Debian for the affected packages.


So I'll admit the experience is not absolutely free of surprises, but
that's the generally the case of using any foreign package manager...


If there are other issues specific to the Guix packages in Debian,
please file bugs in the Debian bug tracking system; it's a great way to
contribute back to the community!


live well,
  vagrant


signature.asc
Description: PGP signature

Re: The way to promote GUIX package manager

[Yasuaki Kudo]

Well I have to tell you I am not too familiar with either Debian or Guix  So 
with that disclaimer:

- If I remember correctly, Guix in Debian just doesn't work straight away after 
apt-get install, meaning enabling of certain Guix services also required?

- He needs to have everything that Guix needs "virtualized", including the 
folder /gnu straight under root, (under some /home/xyzuser/blah/ directory I 
presume).   He does not care about Guix-as-container - he needs 
Guix-to-be-contained.

Again, I don't know much, Im' just a casual Guix OS user (and I love it ) but 
does it make sense?

-Yasu


> On Jan 27, 2022, at 07:46, Ricardo Wurmus  wrote:
> 
> 
> Yasuaki Kudo  writes:
> 
>> Does Guix really run out of the box in Debian?
>> 
>> I have never tried it but my friend Debian expert friend keeps telling me 
>> that:
>> 
>> * Just apt-get installing Guix doesn't work
> 
> How does “apt install guix” not work?  There’s an older version of Guix
> in Debian.  After installing it “guix pull” should get the latest
> version and it all works.
> 
> There’s also an installer script at https://guix.gnu.org/install.sh
> which skips the detour through apt and gets you the latest release
> directly.
> 
>> * and his really big complaint is evidently he creates "virtual
>> environments" (short of full-on VMware, I imagine it is an assortment
>> of Linux native tricks that are wrapped by tools like Docker) for
>> every OS he tries but
>> * Evidently the same tricks don't work with Guix
> 
> Is this not *exactly* what “guix shell” (formerly “guix enviromnent”)
> does?  “guix shell -C” enters a container, even, using the same Linux
> namespace mechanism that Docker wraps.
> 
>> * He does not want to try full blown Guix OS without first testing it in 
>> above ways
> 
> Guix can comfortably be used outside of Guix System.  And you can
> *still* use most “guix system” commands, e.g. to build containers or
> virtual machines.
> 
> -- 
> Ricardo

Re: The way to promote GUIX package manager

[Ricardo Wurmus]

Yasuaki Kudo  writes:

> Does Guix really run out of the box in Debian?
>
> I have never tried it but my friend Debian expert friend keeps telling me 
> that:
>
> * Just apt-get installing Guix doesn't work

How does “apt install guix” not work?  There’s an older version of Guix
in Debian.  After installing it “guix pull” should get the latest
version and it all works.

There’s also an installer script at https://guix.gnu.org/install.sh
which skips the detour through apt and gets you the latest release
directly.

> * and his really big complaint is evidently he creates "virtual
> environments" (short of full-on VMware, I imagine it is an assortment
> of Linux native tricks that are wrapped by tools like Docker) for
> every OS he tries but
> * Evidently the same tricks don't work with Guix

Is this not *exactly* what “guix shell” (formerly “guix enviromnent”)
does?  “guix shell -C” enters a container, even, using the same Linux
namespace mechanism that Docker wraps.

> * He does not want to try full blown Guix OS without first testing it in 
> above ways

Guix can comfortably be used outside of Guix System.  And you can
*still* use most “guix system” commands, e.g. to build containers or
virtual machines.

-- 
Ricardo

Re: The way to promote GUIX package manager

[Yasuaki Kudo]

Does Guix really run out of the box in Debian?

I have never tried it but my friend Debian expert friend keeps telling me that:

* Just apt-get installing Guix doesn't work

* and his really big complaint is evidently he creates "virtual environments" 
(short of full-on VMware, I imagine it is an assortment of Linux native tricks 
that are wrapped by tools like Docker) for every OS he tries but 
* Evidently the same tricks don't work with Guix

* He does not want to try full blown Guix OS without first testing it in above 
ways

* He is very comfortable with Debian - doesn't see any benefit that Guix brings

I cannot comment much because the whole point of my using Guix is precisely 
because I know very little if Linux and its surrounding toolset so I want to 
abstract it, paper it over with Guix 

-Yasu


> On Jan 27, 2022, at 06:43, Ricardo Wurmus  wrote:
> 
> 
> Sławomir Lach  writes:
> 
>> Solution is simple:
>> 1. Keep older packages in GUIX repo, so developers could request older 
>> version 
>> in scripts
> 
> Unforunately, it’s really not that simply to keep older packages around.
> I’m maintaining packages for a bunch of bioinformatics tools, for
> example, which are stuck in the past.  Building them becomes more and
> more difficult as time passes and the rest of the world moves on.  It is
> not feasible to maintain an ever-growing collection of outdated software
> and their toolchains.
> 
> But: Guix supports channels, so people who absolutely must use GCC 3 to
> build their abandoned tools to build their old source code that’s stuck
> in the past can totally do that.
> 
>> Minus: possible security hell.
> 
> :)
> 
> -- 
> Ricardo
> 

Re: The way to promote GUIX package manager

[Ricardo Wurmus]

Sławomir Lach  writes:

> Solution is simple:
> 1. Keep older packages in GUIX repo, so developers could request older 
> version 
> in scripts

Unforunately, it’s really not that simply to keep older packages around.
I’m maintaining packages for a bunch of bioinformatics tools, for
example, which are stuck in the past.  Building them becomes more and
more difficult as time passes and the rest of the world moves on.  It is
not feasible to maintain an ever-growing collection of outdated software
and their toolchains.

But: Guix supports channels, so people who absolutely must use GCC 3 to
build their abandoned tools to build their old source code that’s stuck
in the past can totally do that.

> Minus: possible security hell.

:)

-- 
Ricardo

Re: Clarifying blog post licensing

[Tobias Geerinckx-Rice]

Vagrant Cascadian 写道：
Just for clarity, do you mean the GFDL with a laundry-list of 
non-free

anti-features excluded, like the guix manual:


I think that goes without saying, but clarity is good: thanks for 
bringing it up.


Invariants would be a deal-breaker for several of us I'm sure, 
including myself.


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: Clarifying blog post licensing

[Vagrant Cascadian]

On 2022-01-26, Ludovic Courtès wrote:
> With a few exceptions, our blog posts do not have a license, which is
> not great as it prevents sharing and reuse, at least by those outside
> Guix circles (we discussed it in the past but never got around to fixing
> it).
>
> I’d like us to clarify that, with a footer on blog posts saying that,
> unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
> GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
> the manual).  Patch below.

Just for clarity, do you mean the GFDL with a laundry-list of non-free
anti-features excluded, like the guix manual:

  Permission is granted to copy, distribute and/or modify this document
  under the terms of the GNU Free Documentation License, Version 1.3 or
  any later version published by the Free Software Foundation; with no
  Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

Without that, I'm not sure you can actually include it in the guix
manual (other than, perhaps, by using CC-BY-SA 4.0, maybe)...

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Clarifying blog post licensing

[Tobias Geerinckx-Rice]

How does that sound?


Excellent.

Thanks!

T G-R


signature.asc
Description: PGP signature

Commit Access

[Vinicius Monego]

Hi everyone,

I was granted commit access to the repository [1] one hour ago. I am
signing this mail with the key that will be used to sign commits. My
public key can be found at [2] and [3].

Looking forward to working with all of you.

Vinicius

[1]
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=070b8a893febd6e7d8b2b7c8c4dcebacf7845aa9


[2]
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=keyring=3b84ecee5958b38a6bc866c939903099edfa259b

[3] https://savannah.gnu.org/users/monego


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

The way to promote GUIX package manager

[Sławomir Lach]

Maybe it's road to security hell, but it is also very important for beginners 
and developers.

Promote GNU GUIX by add support for installers/some scripts, which detects OS 
and install software by package manager based on detection.
It is very hard to keep this kind of scripts fresh, because distribution will 
evolve. One think, that developers should still do is keep instructions to 
install guix package manager for some distros, but it is easier than keep 
instruction to install ton of packages. Maybe creating script to install guix 
for distributions and place it on single place + allow distro vendor to change 
it? Solution is simple:
1. Keep older packages in GUIX repo, so developers could request older version 
in scripts
2. Send patches to developers of these scripts, which will detects if there is 
gnu guix package manager on target system installed and request to install 
packages in exact versions, if there was gnu guix installed

USE CASES:
1. KDevelop could request to install developers tools, such like gcc, gdb, 
php, etc.
2. Gaming managers could base on gnu guix instead of custom repository
3. ETC.

RESULT:
Simpler script to maintain, more distribution addressed, user do not have to 
worry if script will work for one's distro, faster advantage in linux 
ecosystem. Minus: possible security hell.

Re: Clarifying blog post licensing

[Maxim Cournoyer]

Hello,

Ludovic Courtès  writes:

> Hello Guix!
>
> With a few exceptions, our blog posts do not have a license, which is
> not great as it prevents sharing and reuse, at least by those outside
> Guix circles (we discussed it in the past but never got around to fixing
> it).
>
> I’d like us to clarify that, with a footer on blog posts saying that,
> unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
> GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
> the manual).  Patch below.
>
> What do people think?

Sounds good to me.  I'm curious though; why do we need CC-BY-SA,
additionally to GFDL?

Thanks,

Maxim

Shepherd should not reboot on exit when running as root

[Arun Isaac]

Hi,

If shepherd is run as root, it assumes it is the init system and reboots
the system. Since shepherd is not just an init system, but can also be
used as a non-init process to manage other daemons, this is probably not
good default behaviour. At the very least, it would be nice to have a
command-line option to disable this behaviour.

Just yesterday, I was tinkering with shepherd on a production server
running Debian as the host system, and ended up accidentally rebooting
it. Needless to say, I went through much pain and suffering! :-) I
suppose I should count myself very lucky that it didn't halt the system!
:-P

Here is the relevant piece of code in modules/shepherd.scm of the
shepherd source code.
--8<---cut here---start->8---
(define* (quit-exception-handler key #:optional value)
  "Handle the 'quit' exception, rebooting if we're running as root."
  (if (zero? (getuid))
  (begin
(local-output (l10n "Rebooting..."))
(reboot))
  (quit)))
--8<---cut here---end--->8---

Thanks!
Arun


signature.asc
Description: PGP signature

Re: Clarifying blog post licensing

[Ricardo Wurmus]

Ludovic Courtès  writes:

> With a few exceptions, our blog posts do not have a license, which is
> not great as it prevents sharing and reuse, at least by those outside
> Guix circles (we discussed it in the past but never got around to fixing
> it).
>
> I’d like us to clarify that, with a footer on blog posts saying that,
> unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
> GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
> the manual).  Patch below.
>
> What do people think?

Sounds good.

> If maintainers and everyone agrees, I’d like to publicly email all the
> authors asking them whether they agree with the proposed licensing
> terms, or whether they’d like a different free license.  The script
> below enumerates blog post authors (the list needs a bit of cleanup
> still):
>
> scheme@(guile-user)> ,pp authors
> $22 = ("A collective of GNU maintainers"
[…]
>  "Ricardo (rekado) Wurmus"
>  "Ricardo Wurmus"

I agree.

-- 
Ricardo

Re: Clarifying blog post licensing

[Oliver Propst]

Me too.

--
Kinds regards Oliver Propst
https://twitter.com/Opropst

Re: Clarifying blog post licensing

[Julien Lepiller]

On January 26, 2022 10:24:11 AM GMT+01:00, "Ludovic Courtès"  
wrote:
>Hello Guix!
>
>With a few exceptions, our blog posts do not have a license, which is
>not great as it prevents sharing and reuse, at least by those outside
>Guix circles (we discussed it in the past but never got around to fixing
>it).
>
>I’d like us to clarify that, with a footer on blog posts saying that,
>unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
>GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
>the manual).  Patch below.
>
>What do people think?
>
>If maintainers and everyone agrees, I’d like to publicly email all the
>authors asking them whether they agree with the proposed licensing
>terms, or whether they’d like a different free license.  The script
>below enumerates blog post authors (the list needs a bit of cleanup
>still):
>
>--8<---cut here---start->8---
>scheme@(guile-user)> ,pp authors
>$22 = ("A collective of GNU maintainers"
> "Andreas Enge"
> "Chris Marusich"
> "Chris Marusich and Léo Le Bouter"
> "Christopher Baines"
> "Christopher Lemmer Webber"
> "Danjela Lura"
> "Danny Milosavljevic"
> "David Thompson"
> "Efraim Flashner"
> "Florian Pelz"
> "Guix Hackers"
> "Gábor Boskovits"
> "Jakob L. Kreuze"
> "Jan (janneke) Nieuwenhuizen"
> "Jan Nieuwenhuizen"
> "Joshua Branson"
> "Julien Lepiller"
> "Konrad Hinsen"
> "Laura Lazzati"
> "Ludovic (civodul) Courtès"
> "Ludovic Courtès"
> "Ludovic Courtès and Leo Famulari"
> "Magali Lemes"
> "Manolis Ragkousis"
> "Marius (mbakke) Bakke"
> "Marius Bakke"
> "Mathieu Othacehe"
> "Maxim Cournoyer"
> "Pierre Neidhardt"
> "Pjotr Prins"
> "Ricardo (rekado) Wurmus"
> "Ricardo Wurmus"
> "Roel Janssen"
> "Simon Tournier"
> "Tatiana Sholokhova"
> "Tobias Geerinckx-Rice"
> "sirgazil")
>--8<---cut here---end--->8---
>
>How does that sound?
>
>Thanks,
>Ludo’.
>

I agree

Re: Clarifying blog post licensing

[Efraim Flashner]

On Wed, Jan 26, 2022 at 10:24:11AM +0100, Ludovic Courtès wrote:
> Hello Guix!
> 
> With a few exceptions, our blog posts do not have a license, which is
> not great as it prevents sharing and reuse, at least by those outside
> Guix circles (we discussed it in the past but never got around to fixing
> it).
> 
> I’d like us to clarify that, with a footer on blog posts saying that,
> unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
> GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
> the manual).  Patch below.
> 
> What do people think?

I agree


-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Clarifying blog post licensing

[Manolis Ragkousis]

I agree!

On 1/26/22 11:24, Ludovic Courtès wrote:

Hello Guix!

With a few exceptions, our blog posts do not have a license, which is
not great as it prevents sharing and reuse, at least by those outside
Guix circles (we discussed it in the past but never got around to fixing
it).

I’d like us to clarify that, with a footer on blog posts saying that,
unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
the manual).  Patch below.

What do people think?

If maintainers and everyone agrees, I’d like to publicly email all the
authors asking them whether they agree with the proposed licensing
terms, or whether they’d like a different free license.  The script
below enumerates blog post authors (the list needs a bit of cleanup
still):

--8<---cut here---start->8---
scheme@(guile-user)> ,pp authors
$22 = ("A collective of GNU maintainers"
  "Andreas Enge"
  "Chris Marusich"
  "Chris Marusich and Léo Le Bouter"
  "Christopher Baines"
  "Christopher Lemmer Webber"
  "Danjela Lura"
  "Danny Milosavljevic"
  "David Thompson"
  "Efraim Flashner"
  "Florian Pelz"
  "Guix Hackers"
  "Gábor Boskovits"
  "Jakob L. Kreuze"
  "Jan (janneke) Nieuwenhuizen"
  "Jan Nieuwenhuizen"
  "Joshua Branson"
  "Julien Lepiller"
  "Konrad Hinsen"
  "Laura Lazzati"
  "Ludovic (civodul) Courtès"
  "Ludovic Courtès"
  "Ludovic Courtès and Leo Famulari"
  "Magali Lemes"
  "Manolis Ragkousis"
  "Marius (mbakke) Bakke"
  "Marius Bakke"
  "Mathieu Othacehe"
  "Maxim Cournoyer"
  "Pierre Neidhardt"
  "Pjotr Prins"
  "Ricardo (rekado) Wurmus"
  "Ricardo Wurmus"
  "Roel Janssen"
  "Simon Tournier"
  "Tatiana Sholokhova"
  "Tobias Geerinckx-Rice"
  "sirgazil")
--8<---cut here---end--->8---

How does that sound?

Thanks,
Ludo’.


diff --git a/website/apps/blog/templates/post.scm 
b/website/apps/blog/templates/post.scm
index de02c6c..0d6b08e 100644
--- a/website/apps/blog/templates/post.scm
+++ b/website/apps/blog/templates/post.scm
@@ -60,4 +60,19 @@
#:label tag
#:url (guix-url (tag-url-path tag)))
   " ")) ; NOTE: Force space for readability in non-CSS browsers.
-   (sort tags tag-first?
+   (sort tags tag-first?)))
+
+(div
+ (@ (class "license"))
+ ,(G_ `(p "Unless otherwise stated, blog posts on this site are
+copyrighted by their respective authors and published under the terms of
+the " ,(G_
+`(a (@ (href 
"https://creativecommons.org/licenses/by-sa/4.0/;))
+"CC-BY-SA 4.0"))
+  " license and those of the "
+  ,(G_
+`(a (@ (href
+"https://www.gnu.org/licenses/fdl-1.3.html;))
+"GNU Free Documentation License"))
+  " (version 1.3 or later, with no Invariant Sections, no
+Front-Cover Texts, and no Back-Cover Texts)."
diff --git a/website/static/blog/css/post.css b/website/static/blog/css/post.css
index 57d7f0d..95035ba 100644
--- a/website/static/blog/css/post.css
+++ b/website/static/blog/css/post.css
@@ -38,3 +38,8 @@ article {
  article.limit-width {
  max-width: 720px;
  }
+
+.license {
+font-size: 0.8em;
+line-height: 1.4em;
+}

Clarifying blog post licensing

[Ludovic Courtès]

Hello Guix!

With a few exceptions, our blog posts do not have a license, which is
not great as it prevents sharing and reuse, at least by those outside
Guix circles (we discussed it in the past but never got around to fixing
it).

I’d like us to clarify that, with a footer on blog posts saying that,
unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
the manual).  Patch below.

What do people think?

If maintainers and everyone agrees, I’d like to publicly email all the
authors asking them whether they agree with the proposed licensing
terms, or whether they’d like a different free license.  The script
below enumerates blog post authors (the list needs a bit of cleanup
still):

--8<---cut here---start->8---
scheme@(guile-user)> ,pp authors
$22 = ("A collective of GNU maintainers"
 "Andreas Enge"
 "Chris Marusich"
 "Chris Marusich and Léo Le Bouter"
 "Christopher Baines"
 "Christopher Lemmer Webber"
 "Danjela Lura"
 "Danny Milosavljevic"
 "David Thompson"
 "Efraim Flashner"
 "Florian Pelz"
 "Guix Hackers"
 "Gábor Boskovits"
 "Jakob L. Kreuze"
 "Jan (janneke) Nieuwenhuizen"
 "Jan Nieuwenhuizen"
 "Joshua Branson"
 "Julien Lepiller"
 "Konrad Hinsen"
 "Laura Lazzati"
 "Ludovic (civodul) Courtès"
 "Ludovic Courtès"
 "Ludovic Courtès and Leo Famulari"
 "Magali Lemes"
 "Manolis Ragkousis"
 "Marius (mbakke) Bakke"
 "Marius Bakke"
 "Mathieu Othacehe"
 "Maxim Cournoyer"
 "Pierre Neidhardt"
 "Pjotr Prins"
 "Ricardo (rekado) Wurmus"
 "Ricardo Wurmus"
 "Roel Janssen"
 "Simon Tournier"
 "Tatiana Sholokhova"
 "Tobias Geerinckx-Rice"
 "sirgazil")
--8<---cut here---end--->8---

How does that sound?

Thanks,
Ludo’.

(use-modules (haunt reader commonmark)
 (haunt reader)
 (haunt post)
 (guix build utils)
 (srfi srfi-1))

(define files
  (find-files "posts" "\\.(md|sxml)$"))

(define authors
  (delete-duplicates
   (append-map (lambda (file)
 (define reader
   (if (string-suffix? ".md" file)
   commonmark-reader
   sxml-reader))

 (map string-trim-both
  (string-split (post-ref (read-post reader file) 'author)
#\,)))
   files)))
diff --git a/website/apps/blog/templates/post.scm b/website/apps/blog/templates/post.scm
index de02c6c..0d6b08e 100644
--- a/website/apps/blog/templates/post.scm
+++ b/website/apps/blog/templates/post.scm
@@ -60,4 +60,19 @@
 		#:label tag
 		#:url (guix-url (tag-url-path tag)))
 	   " ")) ; NOTE: Force space for readability in non-CSS browsers.
-	(sort tags tag-first?
+	(sort tags tag-first?)))
+
+(div
+ (@ (class "license"))
+ ,(G_ `(p "Unless otherwise stated, blog posts on this site are
+copyrighted by their respective authors and published under the terms of
+the " ,(G_
+`(a (@ (href "https://creativecommons.org/licenses/by-sa/4.0/;))
+"CC-BY-SA 4.0"))
+  " license and those of the "
+  ,(G_
+`(a (@ (href
+"https://www.gnu.org/licenses/fdl-1.3.html;))
+"GNU Free Documentation License"))
+  " (version 1.3 or later, with no Invariant Sections, no
+Front-Cover Texts, and no Back-Cover Texts)."
diff --git a/website/static/blog/css/post.css b/website/static/blog/css/post.css
index 57d7f0d..95035ba 100644
--- a/website/static/blog/css/post.css
+++ b/website/static/blog/css/post.css
@@ -38,3 +38,8 @@ article {
 article.limit-width {
 max-width: 720px;
 }
+
+.license {
+font-size: 0.8em;
+line-height: 1.4em;
+}

Re: Return back original implementation for text-config serialization

[Andrew Tropin]

> I have some attention problems, so I don't follow all the patches on
> guix-patches, please CC me for Guix Home related changes if it's
> possible and not very burdening.  

I'll make a special search query, which shows all the messages with
"home:" in subject line, so I should be fine on following Guix Home
related threads, still don't hesitate to CC me =)

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Language menu in the HTML manual

[Andreas Enge]

Am Mon, Jan 24, 2022 at 04:11:16PM +0100 schrieb Ludovic Courtès:
> Heh.  :-)  Done!  That should appear on-line soon (you may have to
> reload with Ctrl-F5.)

Thanks, working well! (Except for the sun that has disappeared again...)

Andreas

Re: Return back original implementation for text-config serialization

[Andrew Tropin]

On 2022-01-24 16:37, Ludovic Courtès wrote:

> Hi Andrew,
>
> Andrew Tropin  skribis:
>
>>> Making Guix Home part of Guix was and still is a commitment, in
>>> particular the commitment that we’d all be working on one
>>> implementation, that there are no “competitive incompatible
>>> implementations”.  It’s a choice we made, not a phenomenon we’re
>>> passively observing.
>>
>> This is exactly what I want to achieve: To be able to collectively work
>> on one consistent implementation, but fee0bc, which slipped to the
>> master unreviewed, splitted home service configuration approach into two
>> competitive implementations, a few essential home services in guix repo
>> and bigger rest of non-essential stuck in rde.
>
> I love that rde is going much further than Guix, but I think it’s in
> nobody’s interest to “compete”.
>
> The change in question was discussed at length and reviewed at
> .
>

The intent of the patch series was to rename modules and the change
about text-config was added somewhere in between.  I asked to move it
out to the separate thread and do a separate review on that, but seems
the message was missed.

> I think this patch requires more discussion and better to keep it
> outside of this patch series.  Skimmed throught other patches, overall
> LGTM.

The proper review of this big patch series with a few unrelated changes
is hard and inefficient.  We can see that here:
https://issues.guix.gnu.org/50967#66

The semantically-incorrect change was applied, not mentioning that the
discussion about this whole patch #13 wasn't finished in my opinion.

I'll be more clear next time and will state the intent more precisely to
prevent such situations in the future.


Sorry for rising the same thread again and again, but it's really
improtant in my opinion and I would like to complete this discussion.

Seems Maxime rised good questions and proposed nice ideas and discussion
is going forward.

>> I already mentioned at least two possible ways to handle this
>> situtation:
>> 1. Rewrite the rest of rde home services.
>> 2. Rollback this change.
>>
>> I'm ok with both options, but #1 requires much more human hours to
>> complete and I still not sure if fee0bc was introduced for strong
>> reasons or was added almost accidentially.  So I try to find a
>> justification for this change.
>
> I don’t want to cause troubles in rde for you and its users, but I also
> don’t want Home decisions to be discussed there.
>
>>> Are there Guix Home issues reporting this?
>>>
>>
>> Just a 3 cases I observed in Guix Russia telegram chat.
>
> OK.  I don’t see anything at  though, which
> is where I’d expect bug reports for Guix Home.
>

Of course, I try to redirect people to guix mailing lists, but despite
this fact the discussions and question happens in other places too.

>>> Are there any new arguments since the already lengthy discussions that
>>> led to fee0bced7fec2f9950957976a28f033edd4f877c?  Is it really what’s
>>> leading to Guix Home being stale, or is there something else?
>>
>> IMO, changes to text-config in fee0bc really makes it harder to continue
>> the work on many Guix Home related tasks.
>
> It feels exaggerated to me, but that’s perhaps because I’m overlooking
> important aspects.
>
> I’d like us to move forward on this.  I think the best course of action
> is to focus on concrete things rather than abstract design discussions.
>
> Can we move, one by one, a few more services from rde to Home?
>
> Earlier I mentioned the SSH client service, but there are more.  When we
> move them, let’s see if problems arise related to this pattern or to
> other changes made in Guix Home.  At that point perhaps it’ll be clearer
> for everyone (or at least for me) what concrete problems this poses and
> how we could address it.
>
> How does that sound?
>

Ok, let's try, but please don't hurry, a few first services are
important, because they set the style and I would really want it to be
consistent and well-designed.

> In the meantime I submitted a patch for my first Home service this
> week-end.  :-)

Saw one of your week-end patches, will find the rest, test them and
share my thoughts in a few days.

I have some attention problems, so I don't follow all the patches on
guix-patches, please CC me for Guix Home related changes if it's
possible and not very burdening.  

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Return back original implementation for text-config serialization

[Andrew Tropin]

On 2022-01-21 10:30, Maxime Devos wrote:

> Andrew Tropin schreef op do 20-01-2022 om 16:20 [+0300]:
>> [...]
>> 
>> From what I understood from Liliana's and Maxime's replies: I'm not the
>> only one finding the original implementation to be more intuitive and
>> consistent with the rest of Guix API.  Please, correct me if I'm wrong.
>
> To be clear:
>
>   * >> source \
> >> /gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh
>
> How about defining a procedure
>
> (define (source-file file-like)
>   (mixed-text-file "source " file-like)),

Possible, but not really necessary I think it will be ok to just use:

(mixed-text-file "" "source " file-like)

It looks like a light missuse of file like objects because we have to
specify "" file name each time, nothing critical, but still feels a
little wierd.

>
> the 'concatenated-file' described below, and giving an example or
> two in the manual on how to use it?
>
> (concatenated-file ""
>   (source-file (local-file "some-bash-functions.sh"))
>   (mixed-text-file "" (file-append coreutils "/bin/echo")
>   "hello Guix Home!) "\n"
>"invoke-some-function" "argument")) 

concatenated-file is not needed, we already can use source-file and
mixed-text-file directly in bash-home-configuration:
(bashrc
 (list
  (source-file (local-file "some-bash-functions.sh"))
  (mixed-text-file "" (file-append coreutils "/bin/echo")
   " hello Guix Home!) \n"
   "invoke-some-function" "argument"))
   
>
> * I don't like 'slurp-file-gexp' (what are G-exps doing there, and
> what's slurping?).  A better name would improve things though.

The G-expression, which slurps the file.  It's just a funny name I
borrowed from Clojure:
https://clojuredocs.org/clojure.core/slurp
It was just WIP name, I don't mind naming it differently.

> Also, we already have 'mixed-text-file', so maybe we can create
> an ‘concatenated-file'?

Yes, I was missing it a few times, when I started to use guix services a
year ago.

Current implementation of text-config do a similar thing, but it would
be cool to have a separate helper function independent from guix
services.

>
> (appended-file name (plain-file "" "foo") (local-file "bar"))
> -->
> foo
> 
>
> A slight downside is that the plain-file needs to be given a name,
> in this case "", as you have noted for 'mixed-text-file', but that
> can be avoided to a degree by giving it "" as name.

Not a big deal I think.  Optionally, we can support strings, so it will
work as a mixed-text-file, but will be inserting the content of the file
instead of the path, however it can be a little confusing.

>
> * IIUC, the reason why 'slurp-file-gexp' or the like was necessary,
> was because the implementation doesn't use records for
> configuration, but rather some mixture of S-exps and ‘copy this
> and that file is the serialisation here and there’.
>
> I would prefer not using S-exps like
>
> (home-service barfoo-service-type
>   (barfoo-configuration
> (config
>   `((this-option "that")
> (foo (bar z)
>  (foobar (include ,(local-file ...)))
>
> and instead write these 'this-option', 'foo', 'bar' and 'foobar'
> in records, such that there's to some degree a type system and
> some discoverability.

Very good you rised this question.  Discoverability is true, with
records it's a little easier to get tips from geiser, however, the
safety provided by this weak type system is almost illusory, also, the
same degree of type correctness can be achieved without records.

IIRC, I covered this tradeoff in Writing Service Configuration manual
section: https://issues.guix.gnu.org/52698

>
> Yes, if there's a lot of options that can be configured,
> then initially Guix won't support all, but it should be easy
> to patch Guix to support more options on an as-needed basis.
> There can also be an 'extra-content' escape hatch.
>
> For software that doesn't support inclusion directives in
> configuration, we could:
>
>   1. patch upstream to support it (it's free software and
>  it's potentially useful outside Guix, so why not?)
>   2. or do something like 'concatenated-file'
>
> with a preference for (1).
>
> As such, I'm not exactly agreeing, since there appear to be better
> options than 'slurp-file-gexp'.  Renaming 'slurp-file-gexp' to
> something more descriptive would help, but there's more that could be
> done.

Having extra-content basically says that we give up on implementing a
proper serialization and user have to use a mix of target configuration
format placed inside a string, which must be escaped of course +
lisp-flavored version of the same configuration.

I have an excerpt of very simple real-world nginx configuration, which
still demonstrate the idea:

--8<---cut 

Re: Return back original implementation for text-config serialization

[Andrew Tropin]

On 2022-01-21 10:30, Maxime Devos wrote:

> Andrew Tropin schreef op do 20-01-2022 om 16:20 [+0300]:
>> [...]
>> 
>> From what I understood from Liliana's and Maxime's replies: I'm not the
>> only one finding the original implementation to be more intuitive and
>> consistent with the rest of Guix API.  Please, correct me if I'm wrong.
>
> To be clear:
>
>   * >> source \
> >> /gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh
>
> How about defining a procedure
>
> (define (source-file file-like)
>   (mixed-text-file "source " file-like)),

Possible, but not really necessary I think it will be ok to just use:

(mixed-text-file "" "source " file-like)

It looks like a light missuse of file like objects because we have to
specify "" file name each time, nothing critical, but still feels a
little wierd.

>
> the 'concatenated-file' described below, and giving an example or
> two in the manual on how to use it?
>
> (concatenated-file ""
>   (source-file (local-file "some-bash-functions.sh"))
>   (mixed-text-file "" (file-append coreutils "/bin/echo")
>   "hello Guix Home!) "\n"
>"invoke-some-function" "argument")) 

concatenated-file is not needed, we already can use source-file and
mixed-text-file directly in bash-home-configuration:
(bashrc
 (list
  (source-file (local-file "some-bash-functions.sh"))
  (mixed-text-file "" (file-append coreutils "/bin/echo")
   " hello Guix Home!) \n"
   "invoke-some-function" "argument"))
   
>
> * I don't like 'slurp-file-gexp' (what are G-exps doing there, and
> what's slurping?).  A better name would improve things though.

The G-expression, which slurps the file.  It's just a funny name I
borrowed from Clojure:
https://clojuredocs.org/clojure.core/slurp
It was just WIP name, I don't mind naming it differently.

> Also, we already have 'mixed-text-file', so maybe we can create
> an ‘concatenated-file'?

Yes, I was missing it a few times, when I started to use guix services a
year ago.

Current implementation of text-config do a similar thing, but it would
be cool to have a separate helper function independent from guix
services.

>
> (appended-file name (plain-file "" "foo") (local-file "bar"))
> -->
> foo
> 
>
> A slight downside is that the plain-file needs to be given a name,
> in this case "", as you have noted for 'mixed-text-file', but that
> can be avoided to a degree by giving it "" as name.

Not a big deal I think.  Optionally, we can support strings, so it will
work as a mixed-text-file, but will be inserting the content of the file
instead of the path, however it can be a little confusing.

>
> * IIUC, the reason why 'slurp-file-gexp' or the like was necessary,
> was because the implementation doesn't use records for
> configuration, but rather some mixture of S-exps and ‘copy this
> and that file is the serialisation here and there’.
>
> I would prefer not using S-exps like
>
> (home-service barfoo-service-type
>   (barfoo-configuration
> (config
>   `((this-option "that")
> (foo (bar z)
>  (foobar (include ,(local-file ...)))
>
> and instead write these 'this-option', 'foo', 'bar' and 'foobar'
> in records, such that there's to some degree a type system and
> some discoverability.

Very good you rised this question.  Discoverability is true, with
records it's a little easier to get tips from geiser, however, the
safety provided by this weak type system is almost illusory, also, the
same degree of type correctness can be achieved without records.

IIRC, I covered this tradeoff in Writing Service Configuration manual
section: https://issues.guix.gnu.org/52698

>
> Yes, if there's a lot of options that can be configured,
> then initially Guix won't support all, but it should be easy
> to patch Guix to support more options on an as-needed basis.
> There can also be an 'extra-content' escape hatch.
>
> For software that doesn't support inclusion directives in
> configuration, we could:
>
>   1. patch upstream to support it (it's free software and
>  it's potentially useful outside Guix, so why not?)
>   2. or do something like 'concatenated-file'
>
> with a preference for (1).
>
> As such, I'm not exactly agreeing, since there appear to be better
> options than 'slurp-file-gexp'.  Renaming 'slurp-file-gexp' to
> something more descriptive would help, but there's more that could be
> done.

Having extra-content basically says that we give up on implementing a
proper serialization and user have to use a mix of target configuration
format placed inside a string, which must be escaped of course +
lisp-flavored version of the same configuration.

I have an excerpt of very simple real-world nginx configuration, which
still demonstrate the idea:

--8<---cut