I know that header files have some pretty horrible issues with templates and cyclic dependencies and so on, but from an organisational perspective I really like them. If I have to implement some complicated algorithm I could easily have a thousand likes + of Code, but the header still quite nicely shows the general structure in one or two screens. Whenever I do classes in python I start wishing for headers at like 300 lines, simply because I loose track of all the functions I already made.

Maybe I’m just not a good python programmer tho.

I use tiddlywiki for my single-user wiki. The setup is dead simple, one html file on your computer you open directly. There is also a nodejs server implementation, which I use.

Pihole reloading in my case is probably mostly slow because of the hardware. That signal functionality to reload is pretty neat, though I think I disagree with the config files being the only thing specifying the servers behaviour exactly being a big advantage. In an environment using infrastructure as code it would probably be better to define DNS over the generic nsupdate API (e.g. with ansible or other equivalent tools) than having to write custom code to reload some config files that have to be regenerated every time. But for smaller home setups both options are probably fine anyhow.

Does this support DNS management with nsupdate? I’m currently automating DNS on pihole by changing a text file and reloading the service, which is just not very convenient not to mention slow.

kobo.com sells books without DRM (under eBook details they tell you the exact format). For example, the murderbot chronicles are sold without. Sadly they don’t have everything like amazon does, especially for niche authors that only publish digitally.

I tried photoprism and thought it was pretty neat feature-wise. If I recall correctly they even sort received photos in a sensible date-based structure automatically. Don’t think they have an official app but maybe some third party stuff; the web UI is mobile friendly though.

To talk backups, I’d deploy the thing using containers and then back up the volumes any way you like.

This may not be the ideal solution for you, especially due to lack of decent android support. The workflow would probably be something like take photo -> sync to protoprism to sort -> view in photoprism gallery, which may also be too convoluted for you. Also, I’m not sure what you mean by the last paragraph.

Yes, it’s possible but this is not documented anywhere official from what I could tell

I found the following in a github issue comment chain: Assuming you have a container based deployment (which if you don’t have, you should probably get), you can set the environment variable OVERWRITE_SETTING_Show_Setup_Wizard=completed to skip the registration. As far as I can tell this still works with the current rocketchat versions. A small additional complexity is that you then can’t create your first admin user. This can be fixed by also setting other environment variables which create an administrator if no other admins are found on start:

    OVERWRITE_SETTING_Show_Setup_Wizard=completed
    ADMIN_USERNAME=example
    ADMIN_PASS=example
    ADMIN_EMAIL=example@localhost
    INITAL_USER=yes

The alternative is to register a user and then do some raw database manipulation as documented here and promote the new user; for this you need the mongosh shell in the mongodb container (i. e. something like docker exec -it mongodb mongosh):

use rocketchat                                                                  // switch to rocketchat db

db.getCollection('users').find()                                                // list users
db.users.update({username: "test"}, { $push: { roles: "admin"}})       // make user admin
db.users.update({username: "test"}, { $pull: { roles: "admin"}})       // remove admin role from user

As another user mentioned, the alternative is to deploy older versions and then upgrade. Old container images are available under registry.rocket.chat/rocketchat/rocket.chat:$ver. Versions as recent as 4.4.0 still allow setup without cloud registration. You just need to be a bit careful in the upgrade, as you need to do several smaller steps to reach the current version, so from 4.4.0 to the most recent 6.x would for example be:

4.4.0 -> latest 4.x -> 5.0 -> latest 5.x -> 6.0 -> latest version

(make backups of your db though with mongodump)

In my opinion, rocketchat has an easier deployment compared to matrix (only two containers, three if counting the reverse proxy), but the recent pushiness of the company with their paid services (the seemingly disabled registration, giant advertisements in the settings and most recently the forced depreciation of older instances for their official apps among other things) really makes me question whether that somewhat decreased complexity makes it worth investing time and effort into such a product.