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.

Maybe we should talk about what “infinite” means. I’d like to propose the following idea: a sequence of things is infinite, if there is always “one more” object to consider. We could also say that for any number of finite steps, there is always another object of the series we haven’t looked at yet.

As an example, the sequence of natural numbers would satisfy this: if I start considering the sequence 1, 2, 3 and so on, if I ever stop after finite time (say 1729 steps), I can always compute +1 to find another element of the sequence I haven’t seen yet.

Also consider the following: the set of all numbers between 0 and 1 is in some sense bounded. However, I can find an infinite sequence of numbers in this set: consider 1/1, 1/2, 1/3, 1/4, …

These numbers are always between 0 and 1, and are infinitely decreasing.

Perhaps the confusion comes from you talking about infinity as in a number which is larger than any real or natural number, while I’m talking about sizes of sets of infinite size. As I had demonstrated earlier, we can show the existence of uncountable infinite vs countably infinite sets, while such distinctions don’t really come up in limit theory and calculus.

I’m not entirely sure I understand your comment, but the fact that there are more real numbers than natural numbers can be readily shown using something called cantor’s diagonal argument. It goes something like this:

Suppose the set of real numbers and natural numbers had the same size. Then we could write down an infinite list, where each line represents some real number written in it’s decimal representation. So something like

1: 3.14159265
2: 1.41421356
3: 0.24242424
...

This list goes on forever. We will now construct a new real number r as follows: The first number after the decimal point of r shall be different from the first number after the decimal point of the first number in our list, the second shall be different from the second decimal of the second number on the list, and so on (the name diagonal argument comes from this, we consider the entries on the diagonal from top left towards the bottom right).

The key point now is that this constructed real number is different from every single number on the list: After all, we have made sure it differs from each number on the list in at least one place. Therefore, it is impossible to write down the real numbers in such a way that each real number gets its own natural number: There are simply too few natural numbers for this. In particular, there are at least two different “sizes” of infinities.

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.

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.