a blog post

a blog post

[Catonano]

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

Hello fellow guixers,

I posted a brand new post in my little personal somewhat indie blog

It's about Guix, Guile and Free Software in general. From my very own point
of view

You can find it here
http://catonano.v22018025836661967.nicesrv.de/guile-and-free-software.html

There's also a feed, reachable here
http://catonano.v22018025836661967.nicesrv.de/feed.xml

I hope you're not bothered by this shamelessly self promotional post on the
mailing list

But I remember Ludo saying that not only new packages and services would be
needed for the future of Guix but also community oriented stuff such as
blog posts and maybe screencasts and so on

The blog is made with Haunt and it's completely Javascript free. This
should make the consultation easier from Tor

Too bad I couldn't take care of the fonts yet so it still points to some
Google provided fonts 😓

Also, I host it on a vps by netcup.de, a German provider, I don't know how
that fares with Tor either.
I hope not too bad

So, this is it
Thanks

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

Autotools formely: a blog post

[Pjotr Prins]

Hi Catano,

Thanks for the blog.

Indeed, I love working with Guix and developing with Guix. Guix takes
care of my deployment and configuration requirements.

I have written some time in the past that with Guix you don't need
autotools. The main thing autotools solve is configuring the build for
an environment. At the same time, with Guix you get a predictable
environment, so a make file (or similar) suffices. It is what I do in
all my development projects - I don't use autotools to develop and
deploy them. It greatly simplifies my existence :). Indeed, I have
never liked autotools (essentially a nasty hack) and only used them
before Nix/Guix. So, my approach is the same as yours :) 

You can do without autotools once inside Guix and once you decide to
ignore targeting other distributions. Which I do, though I have ways
of deploying Guix built packages on other systems without Guix which
people also use. E.g.

  https://github.com/genetics-statistics/GEMMA/releases

The top files include a binary Guix package installer. You can try it.
It is a way of distributing pre-built code on other systems. If you
are interested you could package your stuff too. Though it probably
makes less sense for a library for Guile until it becomes something
accepted by the Guile ecosystem.

Pj.

Guix-based build tool

[Ludovic Courtès]

Hello!

Pjotr Prins <pjotr.public12@thebird.nl> skribis:

> Indeed, I love working with Guix and developing with Guix. Guix takes
> care of my deployment and configuration requirements.
>
> I have written some time in the past that with Guix you don't need
> autotools. The main thing autotools solve is configuring the build for
> an environment. At the same time, with Guix you get a predictable
> environment, so a make file (or similar) suffices. It is what I do in
> all my development projects - I don't use autotools to develop and
> deploy them. It greatly simplifies my existence :). Indeed, I have
> never liked autotools (essentially a nasty hack) and only used them
> before Nix/Guix. So, my approach is the same as yours :) 

+1!

If we could provide tooling with an abstraction level close to that of a
makefile, that’d help a lot.

Actually, just like we have ‘emacs-build-system’, we could very much add
‘guile-build-system’ for simple Guile packages that don’t need/use
Autoconf & co.

‘guile-build-system’ would automatically run ‘guild compile’,
‘makeinfo’, etc. pretty much like we do here:

  https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/guile.scm#n870

Once we have that, developers of Guile packages can simply drop a
‘.guix’ file in their project and use it with ‘guix environment’, ‘guix
build’, and ‘guix package’.

That’s coarser-grain than a makefile, of course, but would be a good
first step to providing tooling for people working on Guile code.

Any takers for ‘guile-build-system’?


A next step could be to add a tool that understands a syntax like that
of the guildhall, which gets us closer to the makefile/Makefile.am level
of abstraction:

  https://github.com/ijp/guildhall/blob/master/docs/packaging.texi#L121

Ludo’.

Re: Guix-based build tool

[julien lepiller]

Le 2018-04-09 17:30, ludo@gnu.org a écrit :
> Hello!
> 
> Pjotr Prins <pjotr.public12@thebird.nl> skribis:
> 
>> Indeed, I love working with Guix and developing with Guix. Guix takes
>> care of my deployment and configuration requirements.
>> 
>> I have written some time in the past that with Guix you don't need
>> autotools. The main thing autotools solve is configuring the build for
>> an environment. At the same time, with Guix you get a predictable
>> environment, so a make file (or similar) suffices. It is what I do in
>> all my development projects - I don't use autotools to develop and
>> deploy them. It greatly simplifies my existence :). Indeed, I have
>> never liked autotools (essentially a nasty hack) and only used them
>> before Nix/Guix. So, my approach is the same as yours :)
> 
> +1!
> 
> If we could provide tooling with an abstraction level close to that of 
> a
> makefile, that’d help a lot.

I don't really agree mixing a package manager and a build tool is a
good idea. Sure, it helps a lot because they both solve the same kind
of problem and I certainly see what advantage it would have, but so do
maven devs. They mixed a package manager and a build system together.
It became the official way to build many packages, including its own
dependencies. As a result, it became a total mess to build maven from
scratch. So if someone wants to build a package whose only build
system is guix but can't use guix for some reason (maybe it wasn't
ported to their platform?) will just cry and hate us.

> 
> Actually, just like we have ‘emacs-build-system’, we could very much 
> add
> ‘guile-build-system’ for simple Guile packages that don’t need/use
> Autoconf & co.

That's more reasonable though :)

> 
> ‘guile-build-system’ would automatically run ‘guild compile’,
> ‘makeinfo’, etc. pretty much like we do here:
> 
>   
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/guile.scm#n870
> 
> Once we have that, developers of Guile packages can simply drop a
> ‘.guix’ file in their project and use it with ‘guix environment’, ‘guix
> build’, and ‘guix package’.
> 
> That’s coarser-grain than a makefile, of course, but would be a good
> first step to providing tooling for people working on Guile code.
> 
> Any takers for ‘guile-build-system’?
> 
> 
> A next step could be to add a tool that understands a syntax like that
> of the guildhall, which gets us closer to the makefile/Makefile.am 
> level
> of abstraction:
> 
>   https://github.com/ijp/guildhall/blob/master/docs/packaging.texi#L121
> 
> Ludo’.

Re: Guix-based build tool

[Catonano]

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

2018-04-09 17:30 GMT+02:00 Ludovic Courtès <ludo@gnu.org>:

> Hello!
>
> Pjotr Prins <pjotr.public12@thebird.nl> skribis:
>
> > Indeed, I love working with Guix and developing with Guix. Guix takes
> > care of my deployment and configuration requirements.
> >
> > I have written some time in the past that with Guix you don't need
> > autotools. The main thing autotools solve is configuring the build for
> > an environment. At the same time, with Guix you get a predictable
> > environment, so a make file (or similar) suffices. It is what I do in
> > all my development projects - I don't use autotools to develop and
> > deploy them. It greatly simplifies my existence :). Indeed, I have
> > never liked autotools (essentially a nasty hack) and only used them
> > before Nix/Guix. So, my approach is the same as yours :)
>
> +1!
>
> If we could provide tooling with an abstraction level close to that of a
> makefile, that’d help a lot.
>
> Actually, just like we have ‘emacs-build-system’, we could very much add
> ‘guile-build-system’ for simple Guile packages that don’t need/use
> Autoconf & co.
>
> ‘guile-build-system’ would automatically run ‘guild compile’,
> ‘makeinfo’, etc. pretty much like we do here:
>
>   https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/
> packages/guile.scm#n870
>
> Once we have that, developers of Guile packages can simply drop a
> ‘.guix’ file in their project and use it with ‘guix environment’, ‘guix
> build’, and ‘guix package’.
>
> That’s coarser-grain than a makefile, of course, but would be a good
> first step to providing tooling for people working on Guile code.
>
> Any takers for ‘guile-build-system’?
>

Ahem... that would be me

This would be the most advanced thing I' ve ever done in Guile until now

Recently rekado observed that (system*... does NOT spawn a shell and
execute commands in it

That was a surprise for me

Also in the Guile manual I found getcwd and a "chdir" (or something) in
order to run a Unix command from within a certain folder

So I feel less in the dark than I felt until a short time ago

And anyway, I' ll pester you, should I get stuck

I won' t be fast, but I' ll keep you updated ;-)



>
>
> A next step could be to add a tool that understands a syntax like that
> of the guildhall, which gets us closer to the makefile/Makefile.am level
> of abstraction:
>
>   https://github.com/ijp/guildhall/blob/master/docs/packaging.texi#L121


it's early for this one

We' ll see

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

Re: Guix-based build tool

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Hello!
>
> Pjotr Prins <pjotr.public12@thebird.nl> skribis:
>
>> Indeed, I love working with Guix and developing with Guix. Guix takes
>> care of my deployment and configuration requirements.
>>
>> I have written some time in the past that with Guix you don't need
>> autotools. The main thing autotools solve is configuring the build for
>> an environment. At the same time, with Guix you get a predictable
>> environment, so a make file (or similar) suffices. It is what I do in
>> all my development projects - I don't use autotools to develop and
>> deploy them. It greatly simplifies my existence :). Indeed, I have
>> never liked autotools (essentially a nasty hack) and only used them
>> before Nix/Guix. So, my approach is the same as yours :) 
>
> +1!
>
> If we could provide tooling with an abstraction level close to that of a
> makefile, that’d help a lot.
>
> Actually, just like we have ‘emacs-build-system’, we could very much add
> ‘guile-build-system’ for simple Guile packages that don’t need/use
> Autoconf & co.
>
> ‘guile-build-system’ would automatically run ‘guild compile’,
> ‘makeinfo’, etc. pretty much like we do here:
>
>   https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/guile.scm#n870
>
> Once we have that, developers of Guile packages can simply drop a
> ‘.guix’ file in their project and use it with ‘guix environment’, ‘guix
> build’, and ‘guix package’.
>
> That’s coarser-grain than a makefile, of course, but would be a good
> first step to providing tooling for people working on Guile code.
>
> Any takers for ‘guile-build-system’?
>
>
> A next step could be to add a tool that understands a syntax like that
> of the guildhall, which gets us closer to the makefile/Makefile.am level
> of abstraction:
>
>   https://github.com/ijp/guildhall/blob/master/docs/packaging.texi#L121
>
> Ludo’.

While this is a fun idea, I'd still much rather have a guile-based
DSL replacement for autotools type things that's standalone (but maybe
also which can export to shell if need be).

David Thompson has made many comments before on the mistake of mixing
build systems and package managers... I'm a bit worried that we might be
encouraging going down that same path?

Re: Guix-based build tool

[Chris Marusich]

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

Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

> David Thompson has made many comments before on the mistake of mixing
> build systems and package managers... I'm a bit worried that we might be
> encouraging going down that same path?

The Guix daemon implements the functional software deployment model.
That model can, in theory, be used to create various things.  One of
those things is a package manager.  Another of those things is a
continuous integration server farm (e.g., Hydra, Cuirass).  Another of
those things is a make-like build system (not yet created).

A make-like build system that leverages the functional software
deployment model by using the Guix daemon can, in theory, remain largely
decoupled from Guix, which is a package manager that happens to also
leverage the functional software deployment model by using the Guix
daemon.  This is similar to how, in theory, you could run Nix alongside
Guix and have them both use the same daemon.

So, I don't think the notion of creating a build system that leverages
the functional software deployment model by using the Guix daemon is
unreasonable.  However, I do agree it would be smart to think about ways
to keep such a build system decoupled from Guix, the package manager.

-- 
Chris

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

Re: Guix-based build tool

[Ludovic Courtès]

Hi Chris & Chris,  :-)

Chris Marusich <cmmarusich@gmail.com> skribis:

> Christopher Lemmer Webber <cwebber@dustycloud.org> writes:
>
>> David Thompson has made many comments before on the mistake of mixing
>> build systems and package managers... I'm a bit worried that we might be
>> encouraging going down that same path?
>
> The Guix daemon implements the functional software deployment model.
> That model can, in theory, be used to create various things.  One of
> those things is a package manager.  Another of those things is a
> continuous integration server farm (e.g., Hydra, Cuirass).  Another of
> those things is a make-like build system (not yet created).

Exactly, that was the spirit of my suggestion.

Now I’d be interested in reading David’s arguments!

Ludo’.

Re: Guix-based build tool

[Ludovic Courtès]

Hello,

Christopher Lemmer Webber <cwebber@dustycloud.org> skribis:

> While this is a fun idea, I'd still much rather have a guile-based
> DSL replacement for autotools type things that's standalone (but maybe
> also which can export to shell if need be).

Yeah, not depending on Guix would have pros (it’d be more widely
applicable), and cons (limited world view).

Food for thought!

Ludo’.

Re: Guix-based build tool

[Catonano]

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

2018-04-18 23:09 GMT+02:00 Ludovic Courtès <ludo@gnu.org>:

> Hello,
>
> Christopher Lemmer Webber <cwebber@dustycloud.org> skribis:
>
> > While this is a fun idea, I'd still much rather have a guile-based
> > DSL replacement for autotools type things that's standalone (but maybe
> > also which can export to shell if need be).
>
> Yeah, not depending on Guix would have pros (it’d be more widely
> applicable), and cons (limited world view).
>
> Food for thought!
>
> Ludo’.
>
>
there' s this file guix/buid/emacs-utils.scm

it contains utilities to let Emacs byte-compile elisp files

So that' s an Emacs build system and it' s embedded in Guix

My initial idea was to do something similar with Guile

But then I tought that it could have been a stand alone package

Today in the morning I could manage to take a look at this issue

I made a script that visits the file system tree of a project and compiles
the .scm files

Here' s a short demo
https://www.youtube.com/watch?v=LaypeR8uw3Q

It doesn' t check the availability of dependencies (other guile packages)
yet

I was not sure how to achieve that

I saw that Automake generates snippets of bash scripting that try to run
guile with an expression loading the required module and if that fails then
the module is not available

The same functionality could be reproduced in Guile

I also saw the guildhall files that Ludo mentioned

So the thing is that the interface towards the user should be like those
guildhall files

and the interface towards the system should be like the Automake one

But, like Automake, it should only check if a Guile module is reachable on
the guile load path

If it' s not it shouldn't try manouvres: no sat solving, no fetching,
nothing.

A dependency could be there because you installed it with apt-get or with
dnf or because you used configure make on a manually downloaded guile
package

Or because you installed it with Guix or Nix

If it' s there, fine. if it' s not, that' s bad, the package can' t be built

What I mean is that this should be a build system, not a package management
system

This should address the concern that has been raised

Does it ?

I'll publish this soon, reviews and contributions appreciated ☺

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

Re: Guix-based build tool

[Catonano]

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

2018-04-19 18:49 GMT+02:00 Catonano <catonano@gmail.com>:

>
>
> 2018-04-18 23:09 GMT+02:00 Ludovic Courtès <ludo@gnu.org>:
>
>> Hello,
>>
>> Christopher Lemmer Webber <cwebber@dustycloud.org> skribis:
>>
>> > While this is a fun idea, I'd still much rather have a guile-based
>> > DSL replacement for autotools type things that's standalone (but maybe
>> > also which can export to shell if need be).
>>
>> Yeah, not depending on Guix would have pros (it’d be more widely
>> applicable), and cons (limited world view).
>>
>> Food for thought!
>>
>> Ludo’.
>>
>>
> there' s this file guix/buid/emacs-utils.scm
>
> it contains utilities to let Emacs byte-compile elisp files
>
> So that' s an Emacs build system and it' s embedded in Guix
>
> My initial idea was to do something similar with Guile
>
> But then I tought that it could have been a stand alone package
>
> Today in the morning I could manage to take a look at this issue
>
> I made a script that visits the file system tree of a project and compiles
> the .scm files
>
> Here' s a short demo
> https://www.youtube.com/watch?v=LaypeR8uw3Q
>
> It doesn' t check the availability of dependencies (other guile packages)
> yet
>
> I was not sure how to achieve that
>
> I saw that Automake generates snippets of bash scripting that try to run
> guile with an expression loading the required module and if that fails then
> the module is not available
>
> The same functionality could be reproduced in Guile
>
> I also saw the guildhall files that Ludo mentioned
>
> So the thing is that the interface towards the user should be like those
> guildhall files
>
> and the interface towards the system should be like the Automake one
>
> But, like Automake, it should only check if a Guile module is reachable on
> the guile load path
>


I am experimenting with this line

(system* "guile" "-c" "(use-modules (commonmark)) (exit ((lambda () 0)))")

If it finds the module it returns 0

Otherwise it returns a different number

I copied some bits for a configure script for a Guile project instrumented
with the Autotools

I could use an example of usage of "status:Exit-val"

The Guile manual says:

     Return the exit status value, as would be set if a process ended
     normally through a call to ‘exit’ or ‘_exit’, if any, otherwise
     ‘#f’.

this is not enouhg for me to understand

In which scenario is thhis function supposed to be used ? In order to do
what ?
An example would be of great help

Anyway: Is this the idiomatic way ?

Or maybe I should use some try catch form wrapping some module loading
instruction ?
Without launching a different guile process ?

Thanks for any hint

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

Re: Guix-based build tool

[Catonano]

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

2018-04-20 8:52 GMT+02:00 Catonano <catonano@gmail.com>:

> 2018-04-19 18:49 GMT+02:00 Catonano <catonano@gmail.com>:
>
>>
>>
>> 2018-04-18 23:09 GMT+02:00 Ludovic Courtès <ludo@gnu.org>:
>>
>>> Hello,
>>>
>>> Christopher Lemmer Webber <cwebber@dustycloud.org> skribis:
>>>
>>> > While this is a fun idea, I'd still much rather have a guile-based
>>> > DSL replacement for autotools type things that's standalone (but maybe
>>> > also which can export to shell if need be).
>>>
>>> Yeah, not depending on Guix would have pros (it’d be more widely
>>> applicable), and cons (limited world view).
>>>
>>> Food for thought!
>>>
>>> Ludo’.
>>>
>>>
>> there' s this file guix/buid/emacs-utils.scm
>>
>> it contains utilities to let Emacs byte-compile elisp files
>>
>> So that' s an Emacs build system and it' s embedded in Guix
>>
>> My initial idea was to do something similar with Guile
>>
>> But then I tought that it could have been a stand alone package
>>
>> Today in the morning I could manage to take a look at this issue
>>
>> I made a script that visits the file system tree of a project and
>> compiles the .scm files
>>
>> Here' s a short demo
>> https://www.youtube.com/watch?v=LaypeR8uw3Q
>>
>> It doesn' t check the availability of dependencies (other guile packages)
>> yet
>>
>> I was not sure how to achieve that
>>
>> I saw that Automake generates snippets of bash scripting that try to run
>> guile with an expression loading the required module and if that fails then
>> the module is not available
>>
>> The same functionality could be reproduced in Guile
>>
>> I also saw the guildhall files that Ludo mentioned
>>
>> So the thing is that the interface towards the user should be like those
>> guildhall files
>>
>> and the interface towards the system should be like the Automake one
>>
>> But, like Automake, it should only check if a Guile module is reachable
>> on the guile load path
>>
>
>
> I am experimenting with this line
>
> (system* "guile" "-c" "(use-modules (commonmark)) (exit ((lambda () 0)))")
>
> If it finds the module it returns 0
>
> Otherwise it returns a different number
>
> I copied some bits for a configure script for a Guile project instrumented
> with the Autotools
>
> I could use an example of usage of "status:Exit-val"
>
> The Guile manual says:
>
>      Return the exit status value, as would be set if a process ended
>      normally through a call to ‘exit’ or ‘_exit’, if any, otherwise
>      ‘#f’.
>
> this is not enouhg for me to understand
>
> In which scenario is thhis function supposed to be used ? In order to do
> what ?
> An example would be of great help
>
> Anyway: Is this the idiomatic way ?
>
> Or maybe I should use some try catch form wrapping some module loading
> instruction ?
> Without launching a different guile process ?
>
> Thanks for any hint
>


so

this line (notice the module is named commonmarL)

(system* "guile" "-c" "(use-modules (commonmarl)) (exit ((lambda () 0)))")

returns 256

while this one

(status:exit-val (system* "guile" "-c" "(use-modules (commonmarl)) (exit
((lambda () 0)))"))

returns 1

what's the point ?

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

Re: Guix-based build tool

[Ludovic Courtès]

Hi Catonano,

That’s a lot of text :-) and it seems we’ve drifted away from the
initial discussion.

Perhaps this should go to guile-user@gnu.org, or did I mischaracterize
what you were asking?

Thanks,
Ludo’.

Re: Guix-based build tool

[Ricardo Wurmus]

Hi Catonano,

> I am experimenting with this line
>
> (system* "guile" "-c" "(use-modules (commonmark)) (exit ((lambda () 0)))")
>
> If it finds the module it returns 0
>
> Otherwise it returns a different number
>
> I copied some bits for a configure script for a Guile project instrumented
> with the Autotools
>
> I could use an example of usage of "status:Exit-val"
>
> The Guile manual says:
>
>      Return the exit status value, as would be set if a process ended
>      normally through a call to ‘exit’ or ‘_exit’, if any, otherwise
>      ‘#f’.
>
> this is not enouhg for me to understand
>
> In which scenario is thhis function supposed to be used ? In order to do
> what ?
> An example would be of great help

With this procedure you can obtain the return status for “system*”.
Here’s an example:

--8<---------------cut here---------------start------------->8---
(display "Checking for commonmarl...")
(let ((status
       (parameterize ((current-error-port  (%make-void-port "w")))
         (status:exit-val (system* "guile" "-c"
                                   "(begin (use-modules (commonmarl))
                (exit 0))")))))
  (display (if (zero? status)
               "Success!"
               "Oh no!"))
  (newline))
--8<---------------cut here---------------end--------------->8---

> Anyway: Is this the idiomatic way ?
>
> Or maybe I should use some try catch form wrapping some module loading
> instruction ?
> Without launching a different guile process ?

There are advantages to spawning a new guile process.  One is that
whatever modules you may have loaded for your tool won’t affect the
check.  It’s possible that your tool bundles a bunch of modules, but
when Guile is spawned in a pure environment it won’t be able to load
these modules.  You may want to fail the configure test then.

On the other hand, it’s ugly to pass a Guile programme as a string to
system*, when you could do that instead with pure Guile.  I haven’t
thought enough about this to give a recommendation either way.

--
Ricardo

Re: a blog post

[Erik Edrosa]

Hello Catonano,

Thanks for the blog post, I added your feed to my feed reader. I
understand your frustration with autotools, it can be difficult to
figure out how to get autotools to do what you want. The benefit of
autotools is that it creates the same interface to build, test, and
install GNU software (of course if implemented the correctly...). This
interface usually makes it easier for others to package for their
distribution.

What I think we need to do to improve Guile's chances for success is to
take a serious look at our tools and practices, improve them if needed,
and document the best ways to set up Guile and use it. Guix is great,
but we can't forget Guile users who don't use Guix. This probably
includes packaging Guile libraries for these other package managers.

- Erik (OrangeShark)

Re: a blog post

[Hartmut Goebel]

Am 06.04.2018 um 10:58 schrieb Catonano:
> It's about Guix, Guile and Free Software in general. From my very own
> point of view

Quote:

    [org.mode…] as far as I understand some Google employees worked on it.

Does one become blessed and enlightened by getting employed by Gugle? Is
Gugle a magic guild?

Sorry, can't stand this google devoutness.

-- 
Regards
Hartmut Goebel

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

Re: a blog post

[Tobias Geerinckx-Rice]

On 2018-04-07 11:53, Hartmut Goebel wrote:
> Am 06.04.2018 um 10:58 schrieb Catonano:
>> It's about Guix, Guile and Free Software in general. From my very own
>> point of view
> 
> Quote:
> 
>     [org.mode…] as far as I understand some Google employees worked on 
> it.
> 
> Does one become blessed and enlightened by getting employed by Gugle? 
> Is
> Gugle a magic guild?

Who knows? Who cares?

I wonder why you think this an appropriate reply to a blog post that 
clearly implies neither, and how it will influence people still 
considering writing about Guix.

Kind regards,

T G-R

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

Re: a blog post

[Catonano]

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

2018-04-07 11:53 GMT+02:00 Hartmut Goebel <h.goebel@crazy-compilers.com>:

> Am 06.04.2018 um 10:58 schrieb Catonano:
> > It's about Guix, Guile and Free Software in general. From my very own
> > point of view
>
> Quote:
>
>     [org.mode…] as far as I understand some Google employees worked on it.
>
> Does one become blessed and enlightened by getting employed by Gugle? Is
> Gugle a magic guild?
>
> Sorry, can't stand this google devoutness.
>

Hartmut,

it's not devoutness

What I was trying to convey is that org-mode reached a wide community, it
entered places where the common attitude towards the gpl is of prudence, to
say at least.

I was not referring to a technological success but rather to a
communitarian (political ?) one.

Guile is light years far away from such a success, sadly.

That said, I also expect the average Google engineer to be quite competent.
But admittedly that's not by direct experience

That's all ☺

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

Re: a blog post

[Chris Marusich]

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

Catonano <catonano@gmail.com> writes:

> I posted a brand new post in my little personal somewhat indie blog

Thank you for sharing it!

> I remember Ludo saying that not only new packages and services would
> be needed for the future of Guix but also community oriented stuff
> such as blog posts and maybe screencasts and so on

Yes.  Even if a piece of software is the best software in the world,
it's unlikely to gain mind-share unless people try using it and talk
about it.

> I host it on a vps by netcup.de, a German provider, I don't know how
> that fares with Tor either.  I hope not too bad

It worked for me just fine!

-- 
Chris

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