This should help avoid surprises when using other computers and simplify
things a bit. Note that super for the application launcher was cool but
now I prioritize launching applications from ironbar instead.
This was an interesting experiment however it wasn't very practical
since text became difficult to read and the wider width of the font
broke a lot of programs on the small PinePhone screen.
Will be trying this again since Hyprland offers a substantial
performance improvement over Phosh and hardware accelerated videos
are broken anyway with the lower cpu speed.
This was my attempt at using GNOME Mobile. It works inside the x86_64
virtual machine but fails when reaching "Started Display Manager" on the
actual device.
Unfortunately there are too many bugs for Hyprland on the PinePhone such
as hardware accelerated videos appearing red and convergence in general
being much slower than the phosh counterpart.
Most of these applications are poorly designed for mobile,
don't start up at all, or aren't relevant for my use case.
Note that the correct `portfolio` application was actually
`portfolio-filemanager` in nixpkgs, and I removed it due to
the lack of thumbnailing support.
`networking.firewall.checkReversePath` was being set to "loose" from
Mullvad VPN, which was causing an issue with the kernel used by the
PinePhone with Mobile NixOS.
By changing this option to `false`, we get rid of the "This kernel does
not support rpfilter" error, which seems to be inaccurate due to the
result of `sysctl -a | grep \\.rp_filter` on the phone being consistent
with the result on the laptop.
A lot of these applications are cute but I'd never end up using them,
such as a regular expression GUI and other novelties that web
applications accomplish in a more advanced manner.
Helps prevent issues where we accidentally use an import from derivation
and cause flakes with multiple platforms to fail when running things
like `nix flake check`.
This fixes an issue where previously the derivation had to be evaluated
before importing the base16 scheme, thus causing `nix flake check` to
fail when multi-platform support was added.
See: https://github.com/NixOS/nix/issues/4265
This was causing a lot of issues unfortunately presumably due to things
not working with the aarch64 PinePhone system. Random errors like
"expected string 'D'" were common and I'd rather use a separate flake to
make things easier to debug and keep evaluation times to a minimum.
Note that using a separate fork is necessary since overlaying flakes
seems to be non-trivial here.
Also note that previously the nixpkgs hyprland was being started from
greetd. This fixes that.
Avoids having a separate home module just for packages and makes
essential tooling accessible in all shells.
Note that the legacy `texlive.combined.scheme-full` was replaced with
`texliveFull` in this commit.
Necessary since we take advantage of newer hypridle and hyprlock
modules while sticking with an older version of nixpkgs to avoid issues
with newer versions of hyprland and ironbar.
Breakage may have been influenced by a dependency but seems to occur
with various combinations of hyprland and ironbar.
- hyprland v0.39.1 + ironbar v0.14.1
- hyprland v0.39.1 + ironbar master
- hyprland master + ironbar master
It turns out that I'd rather have a battery indicator than having to
`cat /sys/class/power_supply/BAT0/capacity` all the time.
Depends on upower and results in the battery indicator always being
shown even when virtualized.
2.0 introduces some kind of breaking change that results in the cursor
appearing larger than usual, which I haven't been able to find an answer
for. The 1.1 cursor has been great already, so I'll probably stick with
that until further notice.
Not needed since we can just reference the background directly instead.
Note that the linking actually occurs in the modules for the DEs that
add backgrounds since it isn't part of the defaults.
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.
