all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ng0 <ng0@pragmatique.xyz>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: Debugging info unavailability
Date: Thu, 11 May 2017 16:50:01 +0000	[thread overview]
Message-ID: <20170511165001.qq5jqhtwyzf2msmd@abyayala> (raw)
In-Reply-To: <87a86kkmbc.fsf@gmail.com>

Maxim Cournoyer transcribed 4.2K bytes:
> Hello ng0,
> 
> Sorry for the delayed reply!
> 
> ng0 <contact.ng0@cryptolab.net> writes:
> 
> > Maxim Cournoyer transcribed 1.0K bytes:
> > …
> >> >> What good is a substitute server if it doesn't hold the stuff I need
> >> >> *now*? :) On the other side, it really makes me want to look at GNUnet,
> >> >> which seems like the better long term solution.
> >> >
> >> > Though GNUnet doesn’t solve the fact that one needs a lot of CPU and
> >> > storage to build and store all this.  :-)
> >> >
> >> 
> >> I think what I meant was "integration of GNUnet with guix publish".
> >> Something which would allow anyone to effortlessly share what's been
> >> built on their machine with the other Guix users. A zero config kind
> >> of thing, with auto discovery of peers and available substitutes.
> >> 
> >> I haven't researched much about GNUnet yet, but it seems it might be
> >> fit for that purpose.
> >> 
> >> Maxim
> >> 
> >
> > This has been addressed between 2013? and late 2015, and I'm about to document my own
> > discussions, thoughts, and roadmap for this (gathered in the last 2 years).
> > In the sense of freedom of choice, I'd rather make this an opt-in (contrary to what
> > my own position in discussions was before) so that I can make pragmaOS use this and
> > those who would like to use it too.
> > The main roadblocker is 5 weeks - 5 months until a new GNUnet release, but there's
> > some tasks to work on which can be quickly updated once we have released GNUnet 0.11
> > or which version number is decided upon.
> > If you are interested, I can CC you in the message update when I have documented
> > the ideas (though they are 90% identical to the outcomes of the GSoC discussions
> > of the past, thought about without knowing it has been discussed
> > before).
> 
> Count me in. I'd like to learn more about GNUnet and any design
> ideas/known issues there might be to integrate 'guix publish' with it.

This week applications for university started, so I will transfer the
documentation when I have more time. Probably within the next weeks.

> > My basic idea without going too much into depth (I don't want to search my papers):
> >
> > - following the ideas of pragmaOS, to first make GNUnet as easy as
> >   possible to use and configure (the system service I'm working on)
> 
> Shouldn't deploying GNUnet on Guix be as easy as adding a service to the
> system declaration (and maybe tweeking a few parameters) ?

For just the system service, yes. But I want to make the most out of
shepherd and include every possible option which can be later extended
to have example or services documented for configuring the gnunet-vpn, etc
(actually the system-service part is only a small part of improving
the usability).

> > - update the gnunet-guile bindings for HEAD of gnunet but work with 0.10.1 for the
> >   current version of the service
> [...]
> > I know from the meeting december of last year that Ludovic is sceptic about
> > GNUnet by now to some degree, and if I could decide on releases GNUnet would now
> > have an -dev or -preview or whatever release. The amount of bugfixes which happened
> > since 0.10.1 are just too much to keep 0.10.1 around, especially since the compability
> > no longer works between nodes running 0.10.1 and ones running HEAD.
> >
> 
> Is backward compatiblity absolutely necessary, given that this version
> has its share of problems and is fragmenting the network. I'd rather put
> efforts on making GNUnet 'next' working, and well.

There is no backwards compability. This extra step is just done because
in past discussions some of us in Guix insisted on an available release.
Given that we (at GNUnet) now explicitly recommend not to run 0.10.1,
and the only delay is 2 bugs which depend on Christian freeing up time
in the schedule between jobs, it's annoying that we can't use HEAD.

Anyway, for getting the service started it should work like this,
I'm just generally stuck on services and the help on services is
mostly try and run it until it could/should/would work… I don't expect
any help, but there's more help on packages then getting started with
services. It takes much longer.

> Also, why not packaging a GNUnet-next already in Guix? With only two
> bugs left to fix, it should already work rather well (maybe better?)
> compared to 0.10.1? Guix makes it easy to have multiple versions if we
> need -- let's make use of it!

Refer to Ludovic and others for the reasons why we don't have that.
In any case I have many different variants of gnunet in my public
package repository https://git.pragmatique.xyz/ng0-packages/log.html

I could test run the current HEAD with some of my definitions, but
I don't really want to waste my time on discussions about the why
and why not again. If you want it, it can be added very quickly.

> Maxim



-- 
https://pragmatique.xyz
PGP: https://people.pragmatique.xyz/ng0/

  reply	other threads:[~2017-05-11 16:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-23  0:02 Debugging info unavailability Danny Milosavljevic
2017-04-24  7:35 ` Tomas Cech
2017-05-02 10:08 ` Ludovic Courtès
2017-05-02 16:39   ` Maxim Cournoyer
2017-05-02 21:16     ` Ludovic Courtès
2017-05-03  4:53       ` Maxim Cournoyer
2017-05-03  6:29         ` Ricardo Wurmus
2017-05-03 10:11           ` Ludovic Courtès
2017-05-03 15:22             ` Maxim Cournoyer
2017-05-05 20:31               ` Ludovic Courtès
2017-05-05 21:47                 ` Ricardo Wurmus
2017-05-06 12:21                   ` Ludovic Courtès
2017-05-05 22:09                 ` Maxim Cournoyer
2017-05-06 12:26                   ` Distributing substitutes over GNUnet Ludovic Courtès
2017-05-11 15:05                     ` Maxim Cournoyer
2017-05-06 12:46                   ` Debugging info unavailability ng0
2017-05-11  5:13                     ` Maxim Cournoyer
2017-05-11 16:50                       ` ng0 [this message]
2017-05-11 21:04                         ` Ludovic Courtès

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

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

  git send-email \
    --in-reply-to=20170511165001.qq5jqhtwyzf2msmd@abyayala \
    --to=ng0@pragmatique.xyz \
    --cc=guix-devel@gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.