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.
Unfortunately command-not-found only works for channels and doesn't have
first-class support for flakes yet, and nix-index takes forever to build
the database on slower machines, so I'd rather just disable this by
default.
Seems like an alright categorization for now since dual-function-keys
can be used without a desktop environment, although realistically the
tty is impractical for things like CJK.
This makes it easier to ensure that the system has our network settings
such as random mac addresses. This makes sense since networking in
general is related to the system.
This isn't *perfect*, but it does make it possible to share files
between the guest and the host without having to imperatively create a
directory that may or may not exist on other systems.
It may be useful to add hashedPasswordFile in the future, although from
my testing it was possible to rebuild a VM that used a cached derivation
with the old password.
Ideally your main form of authentication is through LUKS encryption or
SSH keys anyway, and this password should solely be used for sudo
purposes.
Not really necessary anymore since I no longer test home-specific stuff
inside the virtual machine.
It would be nice if there was a way to create a temporary directory on
the fly (such as one in /tmp) that could be mounted and used for sharing
files between the virtual machine and the host.
Note that we will continue to use nixpkgs-fmt for the time being here
since nixfmt-rfc-style breaks string syntax highlighting and comments
like `/* this */` get turned into `# this`.
The conversion from lisp-like formatting to something else in flake.nix
is a bit unfortunate, but I'd rather have a singular style for the
entire code base to make things easier.
This increases boot times quite a bit so I'd rather use tmpfs as /tmp
where possible. Note that this defaults to cleaning /tmp anyway since
I'd rather clean /tmp than not do so at all.
For future reference, the message that gets shown is the following:
"A start job is running for Create Volatile Files and Directories"
This change makes it possible to use this nix-config in all the
different ways imaginable (containers, bare metal, tests, and as a
separate flake input) *without* running into infinite recursion
issues with self.
It does this by using a trick similar to JavaScript in which
`var self = this;`, thus enabling the usage of "this" (or self, in
Nix's case) where it wouldn't otherwise be possible.
Note that this *only* works if the input for this repository is named
nix-config. This makes it impractical to combine with multiple
configurations that employ the same strategy.
This change makes it possible to import the modules that are required
from the flake inputs in the output modules themselves, thus preventing
users from having to manually import those modules.
This simplifies things overall and was made possible by the specialArgs
option that allowed these flake inputs to be passed into our container.
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.
