Hi and welcome, On Tue, 27 Jun 2017 18:16:08 -0400 cinde...@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?