Year-end roadmap review

docs/roadmap.md

@@ -8,11 +8,13 @@ order they will be implemented.
 These items are listed more or less in the order they need to be completed, as
 they generally depend on the items previous to them.
 
-### Cross Compilation
+### Window Support + GUI
 
-Currently the only supported OS/CPU is Linux/amd64. This can be expanded
-_theoretically_ quite easily, using nix's cross compilation tools. First target
-should be OSX/arm64, but windows would also be quite the get.
+Support for Windows is a must. This requirement also includes a simple GUI,
+which would essentially act as a thin layer on top of `daemon.yml` to start
+with.
+
+Depending on difficulty level, OSX support might be added at this stage as well.
 
 ### NATS
 
@@ -35,14 +37,6 @@ requiring a passphrase.
 Most likely this integration will require NATS as well, to coordinate cache
 invalidation and cert refreshing.
 
-### Web server + interface
-
-Have every `isle daemon` run a webserver as one of its sub-processes. Status and
-connectivity information for the local host could be provided via a simple web
-interface, which the user can open in their browser. This saves us the effort of
-needing to develop UIs for individual OSs. This could also make remotely
-debugging hosts easier for admins.
-
 ### Invitation code bootstrapping
 
 Once an HTTP gateway/load-balancer is set up it should be possible to do host
@@ -99,15 +93,14 @@ It should theoretically be possible for the internal network IP range to be on
 IPv6 rather than IPv4. This may be a simple matter of just testing it to confirm
 it works.
 
-### DNS resolver settings
+### Proper Linux Packages
 
-The daemon should update the resolver settings of the host, so that it
-automatically serves DNS queries, unless set to not do so in `daemon.yml`.
-
-### Install sub-command
-
-It would be great to have a `isle install` sub-command which would
-auto-detect the installed operating system and install the daemon automatically.
+Rather than distributing raw binaries for Linux we should instead be
+distributing actual packages, e.g. deb files for debian/ubuntu, PKGBUILD for
+arch, rpm for fedora (if we care), etc... This will allow for properly setting
+capabilities for the binary at install time, so that it can be run as non-root,
+and installing any necessary `.desktop` files so that it can be run as a GUI
+application.
 
 ### Mobile app
 
@@ -130,6 +123,12 @@ necessary ambient capabilities up-front, and then drop down to a specified user.
 This is how the tests work. Doing this with other OS's will depend on how they
 work.
 
+### DNS/Firewall Configuration
+
+Ideally Isle could detect the DNS/firewall subsystems being used on a per-OS
+basis and configure them as needed. This would be simplify necessary
+documentation and setup steps for operators.
+
 ### Plugins
 
 It would not be difficult to spec out a plugin system using nix commands.

tests/NOTES.txt

@@ -1,3 +1,10 @@
 Ctrl+A X -> exits
 
-qemu-system-aarch64 -M virt -nographic -cdrom tests/alpine-virt-3.17.3-aarch64.iso
+qemu-system-aarch64 -nographic -cdrom tests/alpine-virt-3.18.4-aarch64.iso
+
+Ctrl+Alt+G -> Escape mouse capture
+qemu-system-x86_64 \
+    -cdrom tests/virt/Win11_23H2_English_x64.iso \
+    -m 8G \
+    -boot order=d \
+    -drive file=./tests/virt/winblows.qcow2