all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Danny Milosavljevic <dannym@scratchpost.org>
To: cinder88@hushmail.com
Cc: guix-devel@gnu.org
Subject: Re: Looking to contribute
Date: Wed, 28 Jun 2017 15:49:43 +0200	[thread overview]
Message-ID: <20170628154943.36021286@scratchpost.org> (raw)
In-Reply-To: <20170627221608.A23B52013B@smtp.hushmail.com>

Hi and welcome,

On Tue, 27 Jun 2017 18:16:08 -0400
cinder88@hushmail.com wrote:

> What is the current state of GuixSD? Is it currently too buggy or
> feature-deficient to use as a day-to-day os?

I'm using it every day, also for professional programming.

It's quite okay to use.  There are occassional problems - which can be mitigated by the feature below:

If there are bugs on system update, you can roll back by selecting another entry in the bootloader menu (a new one is created everytime you reconfigure the system).  This includes all the installed packages (!!!!).  So it's pretty much indestructible - I think that this is the killer feature of GuixSD.

Check the package list https://www.gnu.org/software/guix/packages/ for information on which packages are available.

Note that a normal GuixSD system takes at least 80 GB of disk space (it will suck), better 160 GB (that will work very nicely).  That mostly because of the rollback feature.

> How can I best contribute?

If you want to install GuixSD there's a "wip-installer" (WIP means "work in progress") branch on git <https://git.savannah.gnu.org/git/guix.git>.  If you just want to test the finished installer please download http://web.fdn.fr/~lcourtes/software/guix/guixsd-graphical-installer-x86-64-linux.lz and unpack it by invoking "lzip -d guixsd*.lz".  This results in a disk image that you can flash onto a USB flash drive (don't copy it as a file unto the filesystem on the flash USB drive - rather replace the entire drive by it).

It has quite a few rough edges so don't expect Ubuntu-style usability (yet).

If you do try the installer, it would be good if you noted which areas suck :)

I think you should contribute in an area that you care about.  There's plenty to do.  For example:

Installer:
- Currently, the installer invokes the parted executable for partitioning which is quite jarring (it looks very different).  It would be nice if it just used the parted library.  But there's no good guile-parted yet.  I've started hacking on one and it's starting to look OK but it's not done.  If you are interested in that I can upload it somewhere (github, gitlab etc).
- No mouse support yet.
- We have ISO9660 CD support code so it would be quite easy to make it so that the image file for the graphical installer (see link above) also worked if you burned it to a CD.  See threads mentioning "grub-mkrescue" on the mainling list.

Bootloader:
- The bootloader support code doesn't support booting Windows systems etcetc.
- There's no u-boot installer yet.  (There's support for using existing u-boot but it doesn't install the u-boot bootloader itself yet.  That's because doing that safely is very difficult)

Packages:
- Texlive for a long time was a 2 GB download which was done every time one of the dependencies changed.  It's better now but there are still situations where it does that.  It should be more modular so the downloads aren't that large (and not done as often).
- Rust is not the newest version because they changed the build system they use (sigh...) and I didn't get it to work yet.
- Our packaging is such that each package goes into its own directory /gnu/store/3523523643262hashvaluehere WHICH IS READ-ONLY, you can't possibly write there.  But dub, the D package manager, sometimes tries to do that and fails.  This is a design limitation in the D package manager (it has so-called "configurations" and if you switch configurations it will try to switch symlinks) but it means you can't run many of the D tests.  Fixing that in dub would be great.
- The GUI hooks for desktop files and mime types suck.  Usually, the desktop file database is updated much too late (mostly by accident).  I've looked into fixing it but it would entail rebuilding almost all the graphical packages we have - and I think KDE would still not do it correctly.

Some of the areas I work in are mostly bootloader, filesystem and partitioning stuff - which happen to be the areas where I have to be quite careful about not breaking the killer feature.  If you like that anyway, please help us with it :)

What are your interests?

  reply	other threads:[~2017-06-28 13:49 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-27 22:16 Looking to contribute cinder88
2017-06-28 13:49 ` Danny Milosavljevic [this message]
2017-06-28 15:01   ` Leo Famulari
2017-06-29 15:49     ` Danny Milosavljevic
2017-06-29 17:02       ` Mekeor Melire
2017-07-01 13:15         ` Deleting system generations Ludovic Courtès
2017-07-01 15:32           ` Thomas Danckaert
2017-07-02 20:22             ` Ludovic Courtès
2017-06-29 13:22   ` Looking to contribute cinder88
2017-06-29 13:46     ` Katherine Cox-Buday
2017-06-29 15:25     ` Alex Vong
2017-06-29 16:42     ` Pjotr Prins
2017-07-02 23:30     ` Binding generator, for Guile, to C libraries Danny Milosavljevic
2017-07-04  0:41       ` Installer development Danny Milosavljevic
2017-07-05 21:53       ` Binding generator, for Guile, to C libraries Ludovic Courtès
2017-07-06 19:57         ` Danny Milosavljevic
2017-07-07 11:41           ` Ludovic Courtès
2017-07-05 13:20   ` Looking to contribute Danny Milosavljevic
2017-07-07 11:34     ` Installer, ISO9660, etc Ludovic Courtès
2017-07-07 16:13       ` Danny Milosavljevic
2017-07-09 20:08         ` Ludovic Courtès
2017-07-10 13:41           ` Danny Milosavljevic
2017-07-10 21:02             ` Ludovic Courtès
2017-07-10 21:27               ` Danny Milosavljevic
2017-07-11  9:23                 ` Ludovic Courtès
2017-07-11 10:13                   ` Danny Milosavljevic
2017-06-28 13:56 ` Looking to contribute Alex Vong
2017-06-28 17:41 ` James Richardson

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=20170628154943.36021286@scratchpost.org \
    --to=dannym@scratchpost.org \
    --cc=cinder88@hushmail.com \
    --cc=guix-devel@gnu.org \
    /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.