Might add some more search engines later, but Mullvad usually produces
better results for less popular content, especially with topics such as
PinePhone troubleshooting.
I originally wanted to avoid maintaining my own forks of flake inputs to
simplify usage with the actual upstream if wanted, however the lack of
flakes supporting patches means that it's actually *easier* to maintain
my own repositories with the changes I want.
The main advantage of this is not having to wait for upstream. This also
means that I'm able to easily control which things I want to update and
when.
This is a huge step towards using the phone as a phone without having to
worry about using Phosh long-term. This could potentially lead to an
extremely minimal phone in the future that has improved performance for
simple tasks.
Will be using the phone as a portable web browser to avoid issues with
native applications generally being slower and lacking features you'd
find in their web counterparts.
Had to reinstall NixOS on the PinePhone again since a corrupted Nix
store broke everything and was unrecoverable due to not being able to
successfully repair specific files with the use of SSH substituters.
This time we will be trying the PinePhone without LUKS encryption to see
if this makes a difference in the performance of the device. Technically
encryption *isn't* supposed to make things slower in 2024 but the
PinePhone CPU is old enough that performance could've been affected.
Alacritty has some significant issues that make it a non-starter for me
on the PinePhone, such as neovim not displaying properly over SSH.
As an alternative to no touch support in kitty and no shift modifiers in
squeekboard, tmux can be used instead.
rustscan is a nice alternative to nmap that's easier to use and doesn't
require the usage of sudo in certain situations.
nix-update is a nice script that makes updating the versions and hashes
of packages way easier than editing them by hand.
It's better to be pragmatic here and not choose tectonic when texlive
works extremely well and without any of the problems one would encounter
with tectonic.
The future of tectonic is unfortunately a mystery as well, due to the
status of the GitHub repository and its dependence on the unmaintained
XeTeX.
See: https://tex.stackexchange.com/questions/593031/what-are-the-downsides-of-using-xetex/593217#593217
I don't use deno enough to justify having separate abbreviations for it,
and I doubt I will anytime soon due to the vastly superior ecosystem of
npm. Just as an example, `deno task` autocomplete support isn't
implemented, whereas `npm run` does have autocomplete.
I only use alacritty on the phone due to the superior touch support.
Touch support might be added to kitty later if someone is willing to
patch it. See: https://github.com/kovidgoyal/kitty/issues/5432
Now that tmux works again, it makes sense to choose it over zellij due
to the vastly superior community support around it. Using tmux-256color
makes colors work properly in programs like htop, and neovim benefits
from squiggly lines and italics from kitty as well.
Now it's possible to enjoy kitty image previews inside tmux, which is
something that zellij doesn't support.
Although tmux is slightly slower than zellij on startup, it has the
major advantage of a larger community with more time to iron out bugs
like the cursor jumping when scrolling in neovim with zellij.
After having to use vagrant again after a while I've decided that it's
better to simply "do things the right way" the first time with the
declarative nature of Nix instead of trying to make install scripts
work.
Notably, the feedback loop between provisioning Vagrant boxes was
lacking compared to rebuilding on NixOS, and the virtual machine
frequently had to be destroyed and provisioned all over again, versus
having already built derivations with Nix.
Not interested in dealing with fixing the nixf-tidy issue here which
would cause a massive formatting diff with nixfmt-rfc-style. Might
upstream later or find a better solution without chameleon.nvim.
There really isn't a reason to use pug or ecr in 2024 when the
development experience with JSX/TSX is so great, and sticking to
what's popular makes it easier for other people to contribute.
I haven't used Vue in years and have much more expertise in vanilla
JavaScript/TypeScript with React and JSX/TSX, so there's really no
reason for me to keep it here.
This prevents us from having specialization-specific configs in the home
directory, which would be unrelated to the main hyprland environment and
would require explicitly disabling it.
Other nix-configs solve this problem with nested directory structures,
however I enjoy being able to access all files in the nix-config one
directory away.
Sometimes you really need to use a stable and reliable Xorg desktop
system. GNOME crashes when switching workspaces with osu! open, and
Plasma seems like too much for just wanting to run osu! without
having to worry about all the Wayland shenanigans decreasing fps.
I used bspwm for years however development has slowed down recently.
I've always liked dwm from trying it previously, and it is comforting
knowing that your window manager is minimal and will always work the
same way.
As much as I love reading the Crystal programming language, it's clear
that there are more opportunities to be had with prioritizing Rust
instead. The ecosystem for Rust is vastly superior with higher quality
libraries and an LSP that's actually feature-complete, and I'd rather
deal with the known problems I'm aware of with Rust than the problems
I'm aware of with Crystal.
Rust won. Joking aside, the ecosystem for Rust is vastly superior, even
if the language is more difficult.
Having to change the package list in two places was a bit redundant. We
can also use `with` patterns now since nixd warns if there are escaping
variables being used.
Note that variables used in multiple places are kept to make it easier
to recognize that those variables must be changed together. Also note
that inherit (pkgs) inside of mkMerge are currently kept to reduce the
diff.
Prevents the desktop entry from showing in applications like Thunar.
Long-term this isn't a viable solution since it prevents the hidden
applications from being used by Thunar.
