GHM debriefing

GHM debriefing

[Ludovic Courtès]

Hello!

So the GNU Hackers Meeting (GHM) in Paris [0] is well over now.  :-)

There were two Guix-related talks (Andreas and me), and no less than 4
Guix hackers were there!  My talk was on Friday morning, and included a
number of demos.  Andreas closed the day with a practical packaging
tutorial, taking examples of easy to tricky packages.

My slides are at http://gnu.org/s/guix and the source in the
guix-maintenance.git repo (those of Andreas should follow).

I hear that the videos should be on-line within a few days (thanks to
Luca Saiu, who’s been very professional with all the organization!),
though presumably not that of Andreas.

It was nice to get feedback from other hackers, and of course, I
appreciated the variety of talks and the chat (and beer) that we’ve had.

Ludo’.

[0] http://www.gnu.org/ghm/2013/paris/

GHM videos

[Ludovic Courtès]

The GHM videos are now available from audio-video.gnu.org.  My talk is
linked from http://gnu.org/s/guix/ with a fancy HTML5 <video> tag.  :-)

Thanks,
Ludo’.

PS: Thanks to Sylvestre Ledru and others for recording, to Luca Saiu for
    polishing, and to Mark H. Weaver and Luca for uploading to gnu.org!

GHM debriefing

[Ludovic Courtès]

[-- Attachment #1.1: Type: text/plain, Size: 1403 bytes --]

Hello!

The GNU Hackers Meeting (GHM) took place last week, with ~50 people
including 4 Guix hackers (less than at FOSDEM!).  I found myself talking
3 times (!) about Guix, hoping the audience would not saturate. ;-)

  https://www.gnu.org/ghm/program.html

Slides online, and hopefully videos will follow:

  https://www.gnu.org/software/guix/help/#talks

The first talk was the usual status update in which I also talked about
challenges that we face to scale up, how we address them and what
remains to be done.

On that topic, I had an interesting discussion with Nicolas Petton of
Emacs about patch tracking.  Nicolas explained that Gitlab (free
software) doesn’t have some of the technical defects that GitHub has; in
particular it can rebase instead of merging, thereby helping preserve a
linear history, and it can be dealt with “mostly” by email.  Perhaps we
could try running an instance and see what it’s like.

For the second talk, I replaced Mathieu who could not make it to the
event.  Essentially, I demoed most of the guix.el features described in
the manual, and expressed all my gratitude to Alex.  ;-)

For the last talk, I rehashed the basics since the audience wasn’t too
familiar I suppose, and then wrote a GuixSD service for OpenSSH’s ‘sshd’
(attached).  Hopefully a useful starting point and tutorial.

That’s it!

Ludo’.


[-- Attachment #1.2: the sshd service --]
[-- Type: text/plain, Size: 1404 bytes --]

(define-module (gnu services openssh)
  #:use-module (gnu)
  #:use-module (gnu services shepherd)
  #:use-module (gnu packages ssh)
  #:use-module (guix)
  #:export (openssh-service-type))

(define (ssh-shepherd-service config-file)
  (list (shepherd-service
         (provision '(ssh-daemon))
         (requirement '(networking))
         (start #~(make-forkexec-constructor
                   (list (string-append #$openssh "/sbin/sshd")
                         "-f" #$config-file)
                   #:pid-file "/etc/sshd.pid"))
         (stop #~(make-kill-destructor)))))

(define %sshd-accounts
  (list (user-account
         (name "sshd")
         (comment "OpenSSH privilege separation user")
         (home-directory "/var/empty")
         (system? #t)
         (group "nogroup"))))

(define %sshd-keygen
  #~(system* (string-append #$openssh "/bin/ssh-keygen")
             "-t" "ed25519" "-N" "" "-f"
             "/etc/ssh_host_ed25519_key"))

(define openssh-service-type
  (service-type
   (name 'openssh)
   (extensions (list (service-extension shepherd-root-service-type
                                        ssh-shepherd-service)
                     (service-extension account-service-type
                                        (const %sshd-accounts))
                     (service-extension activation-service-type
                                        (const %sshd-keygen))))))

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

Re: GHM debriefing

[David Craven]

> Slides online, and hopefully videos will follow:
>
>   https://www.gnu.org/software/guix/help/#talks

Nice slides!

> On that topic, I had an interesting discussion with Nicolas Petton of
> Emacs about patch tracking.  Nicolas explained that Gitlab (free
> software) doesn’t have some of the technical defects that GitHub has; in
> particular it can rebase instead of merging, thereby helping preserve a
> linear history, and it can be dealt with “mostly” by email.  Perhaps we
> could try running an instance and see what it’s like.

Calling it a technical defect is a little harsh... ;-) Gitlab is going to be an
improvement over the existing state of affairs. Just spent an hour fixing
the u-boot [0] patch manually to apply to a fresh tree. (Line wrapping mostly,
removing some hunks and adding a newline at the end)

[0] http://lists.gnu.org/archive/html/guix-devel/2016-07/msg01414.html

Re: GHM debriefing

[Vincent Legoll]

>          (home-directory "/var/empty")

Argh, nooooooooooooooo !

;-)

-- 
Vincent Legoll

Re: GHM debriefing

[Christopher Allan Webber]

All good news!  One comment:

Ludovic Courtès writes:

> For the last talk, I rehashed the basics since the audience wasn’t too
> familiar I suppose, and then wrote a GuixSD service for OpenSSH’s ‘sshd’
> (attached).  Hopefully a useful starting point and tutorial.

It looks like a good tutorial in its simplicity!  Maybe it could be
added as an "example" section at the end of the Defining Services
chapter?

You might have also seen that, as a non-tutorial, Julien Lepiller has
been working on getting an openssh-service into GuixSD.  It might be
good for someone to look if there are any overlaps or things that should
be joined between both definitions, as in terms of getting it really
into Guix :)

(Unfortunately, I'm still in crunchmode, so I'm not volunteering
myself!)

 - Chris

> That’s it!
>
> Ludo’.
>
> (define-module (gnu services openssh)
>   #:use-module (gnu)
>   #:use-module (gnu services shepherd)
>   #:use-module (gnu packages ssh)
>   #:use-module (guix)
>   #:export (openssh-service-type))
>
> (define (ssh-shepherd-service config-file)
>   (list (shepherd-service
>          (provision '(ssh-daemon))
>          (requirement '(networking))
>          (start #~(make-forkexec-constructor
>                    (list (string-append #$openssh "/sbin/sshd")
>                          "-f" #$config-file)
>                    #:pid-file "/etc/sshd.pid"))
>          (stop #~(make-kill-destructor)))))
>
> (define %sshd-accounts
>   (list (user-account
>          (name "sshd")
>          (comment "OpenSSH privilege separation user")
>          (home-directory "/var/empty")
>          (system? #t)
>          (group "nogroup"))))
>
> (define %sshd-keygen
>   #~(system* (string-append #$openssh "/bin/ssh-keygen")
>              "-t" "ed25519" "-N" "" "-f"
>              "/etc/ssh_host_ed25519_key"))
>
> (define openssh-service-type
>   (service-type
>    (name 'openssh)
>    (extensions (list (service-extension shepherd-root-service-type
>                                         ssh-shepherd-service)
>                      (service-extension account-service-type
>                                         (const %sshd-accounts))
>                      (service-extension activation-service-type
>                                         (const %sshd-keygen))))))

Re: GHM debriefing

[Ludovic Courtès]

Hi!

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

> Ludovic Courtès writes:
>
>> For the last talk, I rehashed the basics since the audience wasn’t too
>> familiar I suppose, and then wrote a GuixSD service for OpenSSH’s ‘sshd’
>> (attached).  Hopefully a useful starting point and tutorial.
>
> It looks like a good tutorial in its simplicity!  Maybe it could be
> added as an "example" section at the end of the Defining Services
> chapter?

It would make sense, indeed!  If somebody else wants to do that, that’d
be welcome, of course.  :-)

> You might have also seen that, as a non-tutorial, Julien Lepiller has
> been working on getting an openssh-service into GuixSD.

I actually noticed after I came back from my “retreat” (I did not read
guix-devel while at the GHM, the unread message count was already too
intimidating…)

Ludo’.

Re: GHM debriefing

[ng0]

Hi,

Ludovic Courtès <ludo@gnu.org> writes:

> [ Unknown signature status ]
> Hello!
>
> The GNU Hackers Meeting (GHM) took place last week, with ~50 people
> including 4 Guix hackers (less than at FOSDEM!).  I found myself talking
> 3 times (!) about Guix, hoping the audience would not saturate. ;-)
>
>   https://www.gnu.org/ghm/program.html
>
> Slides online, and hopefully videos will follow:
>
>   https://www.gnu.org/software/guix/help/#talks
>
> The first talk was the usual status update in which I also talked about
> challenges that we face to scale up, how we address them and what
> remains to be done.
>
> On that topic, I had an interesting discussion with Nicolas Petton of
> Emacs about patch tracking.  Nicolas explained that Gitlab (free
> software) doesn’t have some of the technical defects that GitHub has; in
> particular it can rebase instead of merging, thereby helping preserve a
> linear history, and it can be dealt with “mostly” by email.  Perhaps we
> could try running an instance and see what it’s like.

Before you came up with gitlab, I started a thread[0] to see what the
feedback would be like, and some people mentioned gitlab.
Personal experience is not so much, but I prefer it over most systems
I've used now. We use it in a non-public instance for bug-tracking and I
just started using it on gitlab.com (too lazy to setup my own) for
adding an issues/milestones/roadmap feature to the preparation from $now
to live systems shipped with $applications and NixOS/GuixSD and more.

I would very much welcome the move to (a selfhosted) gitlab (instance),
even if it would only be for better patches and bugs tracking.
The current status (email in general) is terrible, and we can only move
upwards.
The features gitlab offers look promising so far.


Also: someone should package gitlab for Guix ;)
Btw: I had a short view into the local doctors/hospital IT suppliers a
couple of years ago, and the solutions were 99% Windows based. I like
GNU/health (http://health.gnu.org/), having this as a package and
service could be another big selling point for Guix.

[0]: https://lists.gnu.org/archive/html/guix-devel/2016-08/msg00854.html
-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: GHM debriefing

[David Craven]

> Also: someone should package gitlab for Guix ;)
> Btw: I had a short view into the local doctors/hospital IT suppliers a
> couple of years ago, and the solutions were 99% Windows based. I like
> GNU/health (http://health.gnu.org/), having this as a package and
> service could be another big selling point for Guix.

The problem there is that guix is free. Doctors don't know about technical
stuff so they hire an IT company. IT companies like windows crap because
it increases their billables without any actual work.

Re: GHM debriefing

[Clément Lassieur]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> On that topic, I had an interesting discussion with Nicolas Petton of
> Emacs about patch tracking.  Nicolas explained that Gitlab (free
> software) doesn’t have some of the technical defects that GitHub has; in
> particular it can rebase instead of merging, thereby helping preserve a
> linear history, and it can be dealt with “mostly” by email.  Perhaps we
> could try running an instance and see what it’s like.

According to Gitlab Documentation [0] [1], the rebase feature you are
talking about is only available in Gitlab Enterprise Edition, which is
proprietary [2].

The libreboot website [3] explains "what's wrong with Gitlab", I think
it is worth reading.

The Kernel Recipes talk by Greg KH [4] about why the Linux kernel
developers rely on plain text email instead of using "modern"
development tools might be of some interest too. It'll happen in Paris
on September 28 [5].

[0]: https://about.gitlab.com/features/#compare
[1]: http://docs.gitlab.com/ee/workflow/rebase_before_merge.html
[2]: https://about.gitlab.com/2014/02/11/gitlab-ee-license-change/
[3]: https://libreboot.org/gitlab/
[4]: https://kernel-recipes.org/en/2016/talks/patches-carved-into-stone-tablets/
[5]: https://kernel-recipes.org/en/2016/schedule/

Clément

Re: GHM debriefing

[Leo Famulari]

On Thu, Sep 01, 2016 at 12:28:51AM +0200, Clément Lassieur wrote:
> The Kernel Recipes talk by Greg KH [4] about why the Linux kernel
> developers rely on plain text email instead of using "modern"
> development tools might be of some interest too. It'll happen in Paris
> on September 28 [5].

I am interested in this talk. Hopefully it will be accessible to those
who can't be present at the event.

Re: GHM debriefing

[ng0]

Clément Lassieur <clement@lassieur.org> writes:

> Hi Ludovic,
>
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> On that topic, I had an interesting discussion with Nicolas Petton of
>> Emacs about patch tracking.  Nicolas explained that Gitlab (free
>> software) doesn’t have some of the technical defects that GitHub has; in
>> particular it can rebase instead of merging, thereby helping preserve a
>> linear history, and it can be dealt with “mostly” by email.  Perhaps we
>> could try running an instance and see what it’s like.
>
> According to Gitlab Documentation [0] [1], the rebase feature you are
> talking about is only available in Gitlab Enterprise Edition, which is
> proprietary [2].
>
> The libreboot website [3] explains "what's wrong with Gitlab", I think
> it is worth reading.
>
> The Kernel Recipes talk by Greg KH [4] about why the Linux kernel
> developers rely on plain text email instead of using "modern"
> development tools might be of some interest too. It'll happen in Paris
> on September 28 [5].
>
> [0]: https://about.gitlab.com/features/#compare
> [1]: http://docs.gitlab.com/ee/workflow/rebase_before_merge.html
> [2]: https://about.gitlab.com/2014/02/11/gitlab-ee-license-change/
> [3]: https://libreboot.org/gitlab/
> [4]: https://kernel-recipes.org/en/2016/talks/patches-carved-into-stone-tablets/
> [5]: https://kernel-recipes.org/en/2016/schedule/
>
> Clément
>

Oh, too bad...

I used kallithea a while ago, I will set this up at git2.n0.is this week
if my schedule allows me to and look at its features again. License is
no problem there. would be neat to add features like remote instance
"PR" etc..
-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: GHM debriefing

[Ludovic Courtès]

Hi,

Clément Lassieur <clement@lassieur.org> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> On that topic, I had an interesting discussion with Nicolas Petton of
>> Emacs about patch tracking.  Nicolas explained that Gitlab (free
>> software) doesn’t have some of the technical defects that GitHub has; in
>> particular it can rebase instead of merging, thereby helping preserve a
>> linear history, and it can be dealt with “mostly” by email.  Perhaps we
>> could try running an instance and see what it’s like.
>
> According to Gitlab Documentation [0] [1], the rebase feature you are
> talking about is only available in Gitlab Enterprise Edition, which is
> proprietary [2].
>
> The libreboot website [3] explains "what's wrong with Gitlab", I think
> it is worth reading.

You’re preaching to the choir. ;-)  Of course I’d only be interested in
running a community-controlled instance of the free software version of
GitLab (“Community Edition”).  If it lacks that rebase feature, that’s
probably a showstopper.

> The Kernel Recipes talk by Greg KH [4] about why the Linux kernel
> developers rely on plain text email instead of using "modern"
> development tools might be of some interest too. It'll happen in Paris
> on September 28 [5].

I’m curious about that one.

Thanks for your feedback,
Ludo’.

Re: GHM debriefing

[Hartmut Goebel]

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

Am 01.09.2016 um 00:28 schrieb Clément Lassieur:
> The libreboot website [3] explains "what's wrong with Gitlab", I think
> it is worth reading.

Below the line these thoughts are worth to consider. Esp. that the
"Community Edition" will always be on the drip of the vendor. This is
the same problem for all "community edition" projects.

(Beside this the libreboot page holds some un-backed statements like
"the opinions expressed", which makes me take that page with a grain of
salt.)

-- 
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog:
http://www.goebel-consult.de/blog/bestanden-iso-27001-lead-implementer
Kolumne:
http://www.cissp-gefluester.de/2012-01-in-die-cloud-in-die-cloud-aber-wo-soll-die-sein



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