# [arch-desktop](https://git.caseydelorme.com/cdelorme/arch-desktop)

This repository contains automation that matches [debian-stretch-desktop](https://git.caseydelorme.com/cdelorme/debian-stretch-desktop), but has been retooled for [arch](https://www.archlinux.org/) systems.

As a rolling release, there will be no need to create new repositories, I will simply update this one as needed.

There are two driving factors for me using arch:

1. I want it on my laptop and arch has way better modern driver support as it is a rolling release.
2. We have just entered the post-freeze on debian buster which is always a painful wait.

_During the creation of this project I have been surprised at how stable arch is and while I will still use debian for servers I may consider moving to arch for my desktop and development machine._


## usage

If you want to test my build locally, you can do so with [`virtualbox`](https://www.virtualbox.org/), [`packer`](https://www.vagrantup.com/), and [`vagrant`](https://www.packer.io/) by running these commands with them installed.

	packer build packer.json
	vagrant up

The first will build an entire image, which takes roughly 5GB of disk space, and the second will launch an instance from that image that is accessible with the username and password of `vagrant`.

You can also run these commands from the installation terminal:

	pacman -S git
	git clone https://git.caseydelorme.com/cdelorme/arch-desktop.git
	cd arch-desktop
	./setup/install.sh


## notes

I ran into quite a few interesting caveats during the creation of this project, and wanted to comment on them.

The pinned comments on the AUR are offensive to beginners and do not answer any questions, RTFM does not explain how to actually fix GPG signature errors.  The wiki is useful, but it is hard to pin down what you are looking for.  So good job being useless by threatening a ban hammer on comments with questions related to the lack of clear instructions on packages.

The `makepkg` restriction that prevents execution as root is dumb as hell.  I get the security constraints, but the instructions to run as nobody are hella flawed; test suites basically can't run as nobody due to directory permissions (so many with loads of undocumented ENV variables), and creating a faux user from a script just to install some relatively common and popular packages seems like a ridiculous work-around.  So great job making automation harder and solving nothing.

Finally, while I am not a fan of how `systemd` forced proliferation into all linux distributions, nor do I care for binary logs (_that seems like a major step backwards_), I am incredibly thankful for how simple `bootctl` made EFI bootloader setup, and also user-space unit files.  _I only wish there was a more clear way to deal with setting up user-space files from scripts during arch installation._


# references

- [Arch Installation Guide](https://wiki.archlinux.org/index.php/installation_guide)
- [old arch docs in system-setup](https://github.com/cdelorme/system-setup/blob/6c0661c5556fae6126e2eb9e7525aafd143b7518/docs/linux/arch/gui.md)
- [arch efi installation guide by GloriousEggroll](https://www.gloriouseggroll.tv/arch-linux-efi-install-guide/)
- [Arch Wiki NVidia Documentation](https://wiki.archlinux.org/index.php/NVIDIA)
- [Arch Wiki makepkg](https://wiki.archlinux.org/index.php/Makepkg)
- [Arch Wiki AUR](https://wiki.archlinux.org/index.php/Arch_User_Repository)
- [ip command cheatsheat](https://access.redhat.com/sites/default/files/attachments/rh_ip_command_cheatsheet_1214_jcs_print.pdf)
- [packer-arch by elasticdog](https://github.com/elasticdog/packer-arch)