unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Steve George <steve@futurile.net>
To: "Gábor Boskovits" <gboskovits@gmail.com>
Cc: Guix Devel <guix-devel@gnu.org>, pjotr.public12@thebird.nl
Subject: Re: GSoC 2024
Date: Thu, 7 Mar 2024 14:09:32 +0000	[thread overview]
Message-ID: <yhkswe6oissfqwidudi6zqu32dnsvmas7inl4wk5wci4qaczz5@k46atld26rsb> (raw)
In-Reply-To: <CAAqdTgM50-yWe9EPS7YTxOiAe40uNjROPx8fEFTu_9nUVUHibg@mail.gmail.com>


Hi,

I had a couple of ideas - but would need help from someone to mentor

1. Moldable development in Guix
Exploratory REPL experience is one of the hall-marks of 'moldable' systems. This shortens the development cycle and improves the ability of users to explore Guix.

The best REPL experience today is through Emacs. We have a modern nREPL implementation that is compatible with Guile. This needs further development and the Guix client side improved.

* Develop a basic CLI Nrepl experience in guile-ares-rs (https://git.sr.ht/~abcdw/guile-ares-rs)
* Add further CLI REPL functions to Guix 
* Stretch goal to add a Guix / Guile Scheme nrepl support to Conjure 
(https://github.com/Olical/conjure/issues/549) 

This would need co-ordination with Andrew Tropin (abcw) and Oliver Caldwell (Olical), and some help from a Guix mentor. 

2. Improving Docker image output (guix pack)
Docker containers are a common deployment method for applications. While they may be good for deployment, they have weak reproducibilty which Guix solves. Docker containers generated by Guix for deployment are large compared to similar deployments using Nix or Alpine. The purpose of this project is to optimise the build and deployment pipeline in Guix.

* Examine the current 'guix pack' process for optimisations
* Optimise the build process to add docker specific capabilities like multi-stage builds
* Explore using grafts or masking to reduce final image size

** NOTE:** I know this is a bit weak - I don't know enough about this myself yet - is this even a good target - I think it's interesting for scientific computing?

3. Add sandboxing to guix packages
Improving the security for end-users by implementing optional sandboxing for desktop applications. The likes of Bubblewrap and Flatseal are available for Linux. There's some existing Nix prior-art that could be a good starting point (https://nixos.wiki/wiki/Firejail) and (https://sr.ht/~fgaz/nix-bubblewrap/)

* Figure out which of the available options is the most sustainable
* Integrate policys and implementation into high-profile packages
* Stretch would be to create a Guile native library / approach

Anyone interested in these - willing to mentor/co-mentor with me?

On  4 Mar, Gábor Boskovits wrote:
> Hello guix,
> 
> I coordinated with the GNU org admins, and we can still do this round,
> but we have to go fast to make this happen. I have already taken the
> initiative to try to get an ideas page up, now I would like to confirm
> if the mentors from last year are still available, and that the ideas
> are still valid.
> 
> Hereby I quickly collected the projects with the respective mentors,
> please pm me your availability:
> 
> Decentralized substitute distribution
> pukkamustard (pukkamustard [at] posteo [dot] net)
> attila.lendvai (ethswarm.org, scheme)
> 
> Robustify long-term support for Reproducible Research
> Simon Tournier (zimoun)
> 
> Develop a Web interface to configure Guix System
> Ludovic Courtès (civodul)
> 
> Trusted computing: Goblins for GNU Guix
> Christopher Webber, Ludovic Courtès and Pjotr Prins
> 
> Guix Data Service revision processing instrumentation and performance
> Christopher Baines
> 
> Guile based build-tool
> Pjotr Prins
> 
> GNU Guix system monitor
> Pjotr Prins
> 
> Booting via network
> Danny Milosavljevic
> 
> Syntax and semantics of systemd units in the Shepherd
> Ludovic Courtès (civodul)
> 
> GNUnet integration
> no mentor available
> 
> Adding modules in support of continuous integration to cuirass
> Ludovic Courtès (civodul)
> 
> Continue rewrite build daemon in Guile Scheme
> Ludovic Courtès (civodul)
> 
> I myself am available to co-mentor, and also to be the formal mentor
> in case someone does not feel like doing the official dance with
> Google. Currently I can commit to devoting two hours a week to this.
> 
> Regards,
> g_bor
> 


  parent reply	other threads:[~2024-03-07 14:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-04 19:10 GSoC 2024 Gábor Boskovits
2024-03-04 22:46 ` Pjotr Prins
2024-03-05  9:40 ` Ricardo Wurmus
2024-03-07 14:09 ` Steve George [this message]
2024-03-11  8:37   ` Efraim Flashner
2024-03-07 14:15 ` Ekaitz Zarraga
2024-03-07 20:38   ` Gábor Boskovits

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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=yhkswe6oissfqwidudi6zqu32dnsvmas7inl4wk5wci4qaczz5@k46atld26rsb \
    --to=steve@futurile.net \
    --cc=gboskovits@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=pjotr.public12@thebird.nl \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).