Realistically this might be more related to "system" than shell, however
it may also be advantageous to keep system as minimal as possible since
it could also be argued that interpreted programming languages are a
part of the system.
This is just a proof of concept that I plan to integrate into NixOS
containers running specific users. The ensureDBOwnership part would no
longer be needed since each database would receive its own container
and consequently user.
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.
There is currently a bug where yazi crashes since it tries to create
directories but is unable to due to being managed at the system level.
There is an open PR in nixpkgs, however it's been 3 weeks and it hasn't
been merged yet.
This is a part of making it easier to instantly have access to yazi
without having to worry about using home-manager. Note that this works
for my use case since I don't use Nix on non-NixOS devices and don't
intend to do so anytime soon.
This continues the process of simplifying the available modules for
end-users. The final result would be having a clear set of modules like
"desktop" and "shell" that can be enabled if users want a complete
Hyprland environment or a complete shell environment.
Enabling the stylix module "only" would be a low-tech solution and at
that point it'd likely be better for end-users to take complete control
of their stylix config with their own module.
Thunar is an opinionated file manager that we're using as the GUI
application of choice because it handles directories with large files
*significantly* better than Nautilus. It also supports image previews
for files that have been trashed, as well as a slew of other convenience
features such as a built-in auto-renaming tool.
Realistically I want access to htop on any machine running my shell
configuration. Making this NixOS-specific removes some of the dependence
on home-manager as well.
Long-term this should make it easy to include all the GUI programs with
the desktop module and all the CLI programs with the shell module, as
well as the ability to easily disable sets of unneeded packages.
This is the start of making it possible to include desktop-related
configuration options instead of only hyprland-related ones.
This simplifies things a bit since opinionated configurations can be
hidden behind an option and end users won't have to worry about all
the different possible modules they could import.
This change is a part of making the desktop-specific stuff its own
module. Note that importing the entire hyprland module into the wine
container doesn't seem to change anything, so simplifying and including
everything in this module should be fine.
I originally separated these modules to avoid "opinionated" options like
neovim as the default editor. Now I realize however that it's easier to
load all opinionated settings by default since users can change them
either through the original options or with module-specific options.
By making this module more generic, it becomes possible to include CLI
programs and other applications as part of the "shell", then provide
options for users to enable or disable things as needed.
Realistically if hyprland is being used then the user *probably* wants
audio as well, so merging them makes sense here.
This commit is a part of ultimately having a single module for "desktop"
usage.
These options are pretty important so it'd be cool to be able to change
them. Current strategy is to assume that configuration through the
module is preferred over overriding the NixOS option directly.
This seems like it could fit with the hardware module as well, however
time will tell if we're able to keep this in system when importing it
into containers and virtual machines.
Note that boot.loader.efi.canTouchEfiVariables gets set to true during
the nixos-install process, so it should be okay to keep here.
Usually one would want to define all of these options at the same time,
so it doesn't make sense to require importing several different modules.
For values that aren't needed, users can either override the configuration
in their own module or use an option that has been written upstream for the
module.
Docker feels a bit too old school after being spoiled by the Nix
language and all the features that NixOS provides. Dockerfiles are not
as cool to write as Nix files and docker-compose.yml lacks many of the
reproducible benefits one gets from sticking with Nix.
Now that I have more experience with Nix, it should be possible for me
to build and run the services I want to run with Nix instead of Docker.
This should additionally reduce my personal machine's startup time,
which was already quite low with Hyprland.
As a final closing, expertise in Nix seems more useful than Docker for
my personal goals. I'd rather be able to control entire Linux systems
and their full environments with containers, virtual machines, and other
goodies than be restricted to the simplistic model that is Docker.
Specializations basically double the build time for each one added, so
requiring users to explicitly enable it means quicker build times for
those that prefer Hyprland (which is easier to configure declaratively).
Now it's possible to use the specializations in arbitrary configs. Note
that specializations do slow things down a bit so they may be disabled
by default in the future.
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
I only used inkscape to convert svg to png with the following command:
`fd -e svg -x inkscape -w 512 -h 512 "{}" -o "{.}.png"`
gthumb was crashing and I'd rather not have to deal with a non-trivial
GUI program that crashes on launch.
nb and obsidian are cute but ultimately I found quartz to be better for
my use case.
- Removed old hyprlang/hyprlock overlays that are now in nixos-unstable
- Replaced pnpm-shell-completion with the one upstream
- Changed old GPG option to new one
cargo-audit has been dropped to fix an issue with libgit2, which should
be fixed in 1-2 weeks or so. Additionally, nvim-base16 has been renamed
to base16-nvim, which is currently only recognized on -small.
This fixes an issue where podman was causing NixOS virtual machines
(which depend on QEMU) to not start with the following error:
qemu-kvm: could not stat pidfile /run/user/1000/pulse/pid: No such file or directory
This was my attempt at using Podman on NixOS. Although it worked and was
cool, Podman actually breaks audio for QEMU VMs and results in an error
message that returns 0 hits on search engines.
Fixes network connectivity in the virtual machine. Necessary due to the
change to the Mullvad packaging that required resolvconf to be disabled
on the host.
Kernel version is now 6.1.67 to avoid the ext4 data corruption bug.
Additionally, typst-lsp had to be removed since it fails to build. No
solution has been posted in the GitHub issue yet.
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.
exa hasn't been updated in a few years and has noticeable bugs such as
columns not working when the terminal is large enough that multiple
columns can show.
The white flash when starting hyprland is a deal breaker for me
personally and I'd rather not have to deal with it. Should hopefully be
fixed in a later release since it seems to be a wlroots issue.
Although this was cute, there are simply too many bugs and other
inconveniences to be worth it. For example, the bar cannot be focused
when a workspace has a fullscreen application.
This was the only way I could get plugins to work reliably. Might look
into this in the future, but v0.27.2 also includes some changes not
present in v0.27.0.
Fixes an issue where the new "full" option would cause letters such as
"m" to appear disoriented.
For more information, refer to the commit below:
b5d2d701d1
pqiv is an image viewer that, unlike feh, has native support for
Wayland, which makes working with it quite nice. It also supports
showing a thumbnail mode that lets you preview and switch between
images with ease, as well as the ability to run custom commands
based on the current image.
pqiv has more features than imv *and* anti-aliasing *actually works*,
making it an ideal choice for image viewing on Wayland. After years of
using feh, I am quite happy that I found pqiv.
Having some indicator that we're in a container is better than no
indicator at all. starship takes forever to compile, so patching it
would introduce excessively long build times.
The previous commit didn't actually work, and I shouldn't need to
change the variables often, so it's much simpler to not have them.
In the event that I do need to change something, rg and sd should get
the job done well.
Now that I have figured out how to get all the Windows applications I
previously used working under Wine (including those that didn't work in
the virtual machine after trying to manually install dependencies) there
is no reason for me to use vmware.
Using NixOS for Windows applications allows them to be used with
systemd-nspawn containers, thus achieving things like isolation, private
networks, impermanence, and more. All of this without having to maintain
a separate operating system install.
No ports need to be forwarded right now, however this is a good example
for when ports need to be forwarded from a container to the host in the
future.
This *works*, and it's possible to edit files in one virtual machine
while having those files instantly be updated in all other virtual
machines. Note that the host will also have access to the files, which
ultimately means that directory sharing is quite useful (and convenient).
This was a change to make networks somewhat usable, and it works to a
good extent, however I ultimately decided against using networks due to
their missing flake support.
This is a working example of using the modules in our existing
configuration to start a network of virtual machines with
nixos-build-vms. Note that VMs take longer to start up in this case than
nixos-rebuild build-vm, and that said VMs may lack certain functionality
(such as dynamic resolution in GNOME) that would otherwise be present
with build-vm.
Although networks are certainly cute (and I'm glad that I feel familiar
with them thanks to my better understanding of Nix), they do seem less
convenient than nixos-rebuild build-vm and don't appear to support Nix
flakes. Networks therefore seem more useful for running multiple one-off
services that couldn't otherwise be ran in a container.
This fixes an issue where some applications were using the default fonts
from nixpkgs instead of the fonts specified in the system configuration.
Notably, this led to the use of "TeX Gyre Heros" for body text, which
made distinguishing between i/I/l problematic at smaller font sizes.
Possibly useful for setting up computers with GNOME. The main advantage
GNOME has is the ability to have a consistent environment in both X11
and Wayland, which is useful to test whether or not something only works
in X11.
