gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] On Making Changes


From: Christian Grothoff
Subject: Re: [GNUnet-developers] On Making Changes
Date: Mon, 31 Dec 2018 16:17:46 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

On 12/31/18 12:24 AM, Devan Carpenter [dvn] wrote:
> Yes, that's a bit better. However, I am of the understanding tha the
> current OS has been hampering progress a bit. 

True. But in part this is because I hope that we can do it "right" and
then avoid larger administrative costs later.

> I would propose that we have a discussion on this list to determine the
> software stack which is most suitable for the project's needs.

Well, my meta-goals are

(1) to minimize friction between administration of GNUnet systems and
GNU Taler systems (production and development).

(2) to avoid the "grothoff is the only root" bottleneck _without_ going
all VM-crazy and ending up with having 50 VMs that all need to be
maintained (and being in a situation that would come crash down on us if
we ever had to temporarily migrate to a "weak" server, i.e. due to HW
downtime).  In the past, we then just disabled some buildslaves and
could run with a few GB or RAM, so the setup should also scale _down_.

As several users have personal data on gnunet.org that (ideally) no
sysadmin should be able to access without leaving a trace, my idea was
that we would manage the sysconfig via Guix and Git and ideally end up
in a situation where many admins can edit the system configuration in
Git (leaving always a trace of their activities) and ideally nobody ever
has to open a root shell -- except maybe on a buildslave/guest.

But we're still far from that point, so constructive ideas here would be
particularly welcome.

(3) to minimizing the use of terrible languages (PHP), in particular by
kicking Drupal, and also overall keeping the number of languages require
small-ish to avoid having to learn a dozen languages to effectively help
with administration or development.

> If the case is that that the entire machine is not solely dedicated to 
> supporting the GNUnet project, then we should be using virtualization 
> (kvm, libvirt, etc.) to allow us to have a (or multiple) dedicated
> environment[s], which wouldn't get in the way of other groups or users
> of the server. 

You can assume that gnunet.org's HW is entirely dedicated to running
GNUnet.org-services. Also, generally assume that some users will require
the use of unvirtualized HW for proper measurements and large-scale
benchmarks.


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]