Previously the old phinger-cursors package was being used without the
overlay. This fixes that and ensures that all packages have their
appropriate overlays.
Simplifies things a bit since my target audience includes those
interested in the Japanese language. Opinionated defaults like this
makes it easier for end-users to be immediately productive without
having to spend time configuring things.
Now it's possible to use whatever username you want for your system. The
default value of "user" is good if you're concerned about information
disclosure attacks through things like the username being visible in
logs or other output.
Now that I have more experience with nix, I know how to write an
expression that automatically outputs all the overlays in the
repository, as well as automatically import them inside the nixos
configuration.
After almost a year of using joshuto, I have decided to switch to yazi.
The latest joshuto update broke my image preview configuration, and it
didn't make sense trying to figure out the issue with yazi already
having built-in image support and more.
Other notable improvements from this change include:
- Simplified configuration since defaults no longer have to be
re-declared
- Faster directory loading, especially for /nix/store/ and symlinks to
/nix/store/
- Text files are more likely to show previews without manual
configuration
- Videos now have working previews again, similar to ranger
Fixes an issue where the newer version of wine would cause my current
wine prefixes to crash with missing DLL errors. Might be fixable by
creating new prefixes with the new version, however it's much easier
for me to stick with what's known to work.
See: https://github.com/NixOS/nixpkgs/pull/273232
Makes it possible to use sakaya without worrying about the container
automatically restarting on config changes and closing all the wine
applications.
This was previously part of my personal nixpkgs branch but I turned it
into an option that should hopefully be upstreamed soon.
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.
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 combined with su makes it possible to automatically start a user
environment with sakaya-server running, thus eliminating the need to
spawn a shell with machinectl.
This works, which is pretty cool. One unfortunate consequence is that
networking with the host is required, thus an alternative approach needs
to be considered if one still wants to eliminate internet access from
certain wine applications.
Although this was cool, it created some inconveniences that I'd rather
not have to deal with. For example, opening a document required manually
copying the file to the container mount first.
Instead of containerizing a subset of GUI applications, it's likely much
easier and more effective to spin up a virtual machine of the current
system. That way all GUI applications benefit from virtualization and
not simply containerization, which caused issues when certain programs
detected that they were already open from the wayland socket.
A final benefit of this change is that which container an application is
running in is no longer ambiguous. Although it was possible to use
custom GTK themes depending on which container an application belonged
to, containers for system-installed applications tend to bring a large
amount of overhead. Only using containers for applications that deal
with untrusted inputs and have a large attack surface seems better in
this case.
After using Logseq for a few months, using Obsidian for just a little
bit is quite repulsive. Taking notes that aren't in outliner form feels
alien and not worth it for me personally.
