roadmap.md (3007B)

      1 `((title . "Technical Roadmap") (date . "2025-12-19"));`
      2 I would like to take the time to establish a little roadmap for myself and the
      3 other technical folks who might be giving this a read.
      4 
      5 Now that a lot of general housekeeping has been done for MonasTech, I would like
      6 to focus on producing new "styles" of systems. Although I really think tiling
      7 window managers are the way to go, I understand that's not what most people
      8 want.
      9 
     10 I will be designing most of my systems around Wayland instead of X.
     11 Specifically, I'd like to focus on
     12 [wlroots](https://gitlab.freedesktop.org/wlroots/wlroots/) compositors for
     13 reasons that are primarily related to compatibility. The follow compositors are
     14 the ones I intend to explore and provide solid support for.
     15 
     16 Primary:
     17 - [Sway](https://swaywm.org/)
     18   - It's just good. It's what I daily drive.
     19 - [Labwc](https://labwc.github.io/)
     20   - The most "suckless" floating WM in my opinion.
     21   - XML-based configuration that will work excellently with Guile Scheme.
     22 - [Wayfire](https://wayfire.org/)
     23   - Seems to be the "other" stable compositor that everyone uses.
     24   - Maximalistic effects are very cool.
     25 
     26 Secondary:
     27 - [Niri](https://yalter.github.io/niri/)
     28   - I think this could be more approachable to Windows users, but that's just a
     29     hunch. Seems like a solid blend between WM-style and floating-style
     30     compositors. I like it, but I need to do more experimentation.
     31 - [Hyprland](https://hypr.land/)
     32   - The kiddos seem to like this one. Seems like Sway but with a different
     33     ecosystem.
     34 
     35 The first order of business is to produce example systems that I can confidently
     36 dogfood on my own machines. I am putting effort into organizing a very
     37 lightweight "base" system style that allows for most customization to be done on
     38 the home environment level. That way you could have several different users with
     39 completely different configurations on the same machine. It also makes updates a
     40 lot cleaner, only requiring a relog at the worst.
     41 
     42 I'll create more posts once I get something done for each.
     43 
     44 On the backend side, there are a few important things that I need to do.
     45 
     46 - Create a proper update service
     47 - Setup a proper build farm with substitutes
     48   - Substitutes are already available at `substitutes.monastech.xyz` but it's
     49     limited to what I manually choose to build as of right now.
     50   - I think setting up a build machine interface for incredibly low-end devices
     51     is a good idea.
     52 - Organize the aformentioned "base" system
     53   - This really just means figuring out what is the best platform to build off
     54     of. It's looking like it's going to be
     55     [greetd](https://sr.ht/~kennylevinsen/greetd/) with something similar to
     56     [tuigreet](https://github.com/apognu/tuigreet) because I do not like the
     57     idea of running another compositor solely for the login manager. However, I
     58     understand that users will be users and they will probably want something
     59     pretty like [QtGreet](https://gitlab.com/marcusbritanicus/QtGreet). I'll
     60     figure it out.