Although I originally wanted to make some cool pull requests for stylix,
it turns out that adding such features would be non-trivial due to the
lack of home-manager support. Since I implemented the functionality I
wanted in my own config already, there's no need to maintain a separate
stylix branch.
Although maintaining my own home-manager repository was a nice learning
exercise, I don't contribute to home-manager enough to warrant having a
personal branch.
Since my pqiv pull request was merged upstream, my branch is basically
the same as upstream anyway.
This makes it possible to create multiple containers without duplicating
code. This may be useful for having an internet container and a no
internet container.
2 months ago, I figured out how to make Crystal work on NixOS and made
an upstream PR to fix Crystal being unable to find -lpcre. Unfortunately,
that change hasn't been merged yet and I even encountered a core dumped
error when trying to build Crystal myself recently.
Although people may be busy, I am concerned about the popularity of
Crystal relative to other languages. It could be the case that the build
was broken for so long precisely because no one used Crystal, and that
the language isn't popular enough to generate comments on the patch either.
In any case, JavaScript/TypeScript is here to stay, and it certainly has
better tooling and community support than Crystal at the moment. Deno
has been going strong for a few years now, and now that I know Rust, I
can also contribute to it if I want to.
Similar to the previous commit, I'm trying to reduce build times here.
Containers are great but each one increases the build time by a
non-trivial amount. By limiting the amount of containers and using
virtual machines for things that "absolutely need to be virtualized",
build times overall should be more productive.
I'll rename this later, but basically I got tired of the vastly
increased build times due to having multiple containers, and would
rather combine containers where possible.
Although unfortunate, this should still be better than not using
containers at all, and by making the usage of such containers easier,
the probability of using them increases as well.
This also has the advantage of fixing an issue where
hyprland-relative-workspace would prevent new workspaces from being
created in the previous direction when a special workspace was present.
