It's certainly better and more flexible for other formats. Except I'm
still not going to cater much for odder Thunderbird feed folder
structures. This is mainly for myself anyways. I'll just avoid setting
it up like that. :)
Not much respect for `category` attribute, apparently. I'll update it at
some point to consider the usual folder structure instead.
For now, it's not a problem for me since the exported feeds to be used
are so low anyways.
I haven't realized that my own workflows use them when profiles are not
even exported in the flake output. Whoops...
For this, I'll put up a compromise by explicitly importing them.
It is broken and it has been like that for a couple of months so we'll
just disable it completely. I mostly use the web UI with manual
management of archiving anyways.
Apparently, it doesn't really log the errors in the journal so it can
make the service failed for no reason. It can be configured to redirect
it to journal.
More self-descriptive == better. Plus it does imply that themes only
change aesthetics which is not often the case with the usual modules
that are defined here.
This is primarily intended to centralize where we define our
filesystems. This way, it would also avoid potential misconfiguration
with the mount options.
This is to easily install launcher plugins and scripts in NixOS. I don't
know if this is also possible on home-manager (which I think it could be
since it also has the capability to set files).
I didn't realize `network.target` is very ambiguous. The next best thing
for booting up the service after the system is up is `default.target`
but we're being explicit here for NixOS services just to make sure.
There's not much use for it since custom keyboard shortcuts are not
possible to set as a system-wide config. This could easily be added into
the list of packages so RIP... :(
It was supposed to create the directory if it wasn't found which is
self-defeating. In any case, it will still fail if the directory is in
the way of an unmounted device.
It is no more than a safety net and an expensive one at that. A
dedicated external storage media would be better. Ideally, hosts should
have a snapshotting system with btrfs or similar but it is what it is
for now.
Now that I have time, I've learnt that Git submodules are not supported
well with flake-based setup. Instead, I'll use my dotfiles repo as one
of the inputs as a non-flake which is exactly what I want. NICE!
Now, it properly integrates installed extensions by automatically
generating a separate dconf keyfile and enabling them individually.
There is also an additional option for setting the preferred terminal
emulator instead of manually setting certain things on the appropriate
keyfile (though, it doesn't work so...).
It is broken though because it cannot set things correctly. That may
have something to do with the lack of setup like certain services are
disabled or something. I'll just need help from the Cardboard
maintainers for this.
It now includes a yt-dlp script that includes the arguments as an extra
package. This is nice for custom downloads with the same preferences for
downloading.
There is the `--paths` option for that purpose. It also eliminates the
workaround for creating the directory before starting the service for
newly-bootstrapped systems.
The several hardening options have also been corrected.
Finally decided to try out KDE Plasma for a little while (at least a
week from now). It is said to be flexible so I'll attempt to recreate my
workflow from GNOME as closely as possible.
Structure-wise, it is pretty similar to the gallery-dl service. It was
about to be combined into a bigger service module as a dedicated service
for multimedia archiving but it is better to have them modularized in
the long run.
It can now add and schedule archiving tasks. Since archivebox will use
Crontab module (which uses `/usr/bin/crontab`), the scheduling with the
interface is out of the question. What better way to make it possible
than creating a home-manager module for it?
While Borgmatic is great, the NixOS module does have easier
configuration for various use cases such as backups in removable
devices. To make this possible in Borgmatic, you have to go through some
loops.
Borgmatic does have easier way of indicating paths. However, in recent
versions of Borg, they have the experimental feature of indicate both
include and exclude through patterns which is close enough.
Also, because of this, we'll be deprecating the custom borgmatic service
at this point. It'll be removed once all of my NixOS-related backup
setups are not using it.
Now, the configuration is made into a proper Nix configuration with the
output being converted to INI format.
For mapping the types, look for `mopidy/config/types.py`. The only
quirky mapping so far is the list type.
It is just an adapted version from the NixOS module. I'll eventually
figure out how to be 'properly configured' with the Nix language through
the `lib.generator`.
While it is easier to maintain the modules by prefixing them all with
`modules`, it is not easy when used from other flakes and/or modules.
This is my attempt on making it easier with appropriate namespaces.
Update home-manager user from the restructure
Now the browser-related cleaners are separated from the default cleaner
lists and has to be activated with `withBrowserCleanup` option.
Browser caches cleanup are also added as part of the updated module.
The dedicated editor module for NixOS has been removed seeing as it is
barely used. The only exception is Neovim which is moved into
`modules.dev.neovim`.
Now, it allows for fine-grained configuration for specific users. I also
managed to fix the infinite recursion error by directly assigning the
values to the keys instead of creating a merged module value in
`config`.
- `modules.bleachbit` for home-manager.
- `modules.hardware-setup.backup-archive` for NixOS. This might be
converted to a generic backup service for removable devices.
- Add `modules.desktop.cleanup` for the usual cleanup activties in
NixOS.
- Update to proper descriptions for module options added with
`lib.mkEnableOption`.
- Additional packages for various modules.
- Deleted `modules/home-manager/alacritty`. It is pretty useless though.
:(
I think this is better for separating modules explicitly. This is also
considered as there are similar objects between modules (e.g., NixOS
and home-manager modules and users).
Revert users module to old position
- Add custom GNOME configurations with dconf keyfiles.
- Refactoring in certain parts of files especially with handling merging
and importing of modules.
Welp, that's one step for more convenient and separate user-specific
configuration. It's a tad simpler than
https://github.com/divnix/devos but I want to work my way towards a
similar setup. It's just a little overwhelming starting with that
framework.
I revisited NixOS this week and I've rewritten my NixOS config from
scratch. I must say I really like Nix flakes. For whatever reason it
just clicked and I understood more programming with Nix despite my
previous experience which is not good. Could be just the fact I had a
break for a long time from completely using Nix (I still used it on
non-NixOS distros).
Eh... I still took some things from the original inspiration of this
configuration so there's that.
* Python module now has an additional option for the package to be
installed for easier installation of other versions.
* The Python module also has a restriction of installing version 3 and
above.
* The JavaScript module has been moved into a more general module for
web-based tools (including PHP).
This commit includes a bunch of minor updates of some Nix modules but
the focus here is the update of the theme template. The renaming of the
Cookiecutter template will now make backups and migration between
different filesystems very easy especially with NTFS-based filesystems
often found on external hard drives.
I also fixed the long-time occuring error when using the newest version
of the channel (or the unstable one). It turns out to be a simple type
error with the `my.user' attribute. (To be honest the error messages are
quite horrible.)
On another note, I also accidentally bricked my NixOS setup after a
garbage collection and a horrible update. The breakage includes not
being able to use any of the builtin tools of Nix (e.g., nix, nix-env,
nixos-rebuild) due to a shared library error that has been garbage
collected. Which means I have to reinstall it.
(I seem to have a talent for breaking things, if only I'm paid for it.)
One of the bigger changes is to make the setup hardware-independent
which is nice for easier (re-)installations.
Finally about time it happens.
Another big thing is the update of the README, now with some
self-reminding pitch why choose NixOS (or something similar like GuixSD)
which could be nice for other people too, provided they've come across
my NixOS config.
I made the module docstrings a bit more consistent (though still
useless, to be honest).
I've also updated config for Visual Studio Code.
