You are right. Quadlets require 4.4, Debian 12 has 4.3

Podman

• rootless by default
• daemonless
• integration with systemd, made even easier by podman-generate-systemd
• no third-party APT repository required, follows the same lifecycle as my LTS (Debian) distro
• podman and docker command-line are 100% compatible for my use cases

podman-compose is packaged in a separate podman-compose package in Debian 12 (did not try it though). The only thing missing (for me) in Debian 12 is quadlets support (requires podman 4.4+, Debian 12 has 4.3)

I use tt-rss and the android app

Don't mind him. He's always there ranting about who knows what whenever software he dislikes is mentioned. Lookup his comment history for more of the same.

Easiest method to summon him is to mention Nextcloud and Proxmox in the same sentence.

See you back on Debian in a few months

How does this compare to https://awesome-selfhosted.net/ ?

Not "self-hosted" (it doesn't even need a server, just a mobile app), but this is Free/Open-Source and works well: https://f-droid.org/en/packages/org.isoron.uhabits/

Lemmy is licensed under AGPL https://choosealicense.com/licenses/agpl-3.0/

When a modified version is used to provide a service over a network, the complete source code of the modified version must be made available.

awesome-selhosted maintainer here. This critique comes up often (and I sometimes agree...) but it's hard to properly "fix":

Any rule that enforces some kind of "quality" guideline has to be explicitly written to the contribution guidelines to not waste submitters' (and maintainers) time.

As you can see there are already minimal rules in place (software has to be actively maintained, properly documented, first release must be older than 4 months, must of course be fully Free and Open-source...). Anything more is very hard to word objectively or is plain unfair - in the last 7 years (!) maintaining the list I've spent countless hours thinking about it.

For example, rejecting new projects because an existing/already listed one effectively does the same thing would give an unfair advantage to older projects, effectively "locking out" newer ones. Moreover, you will rarely find two projects that have the exact same feature set, workflow, release frequency, technical requirements... and every user has different needs and requirements, so yeah, users of the list are expected to do some research to find the best solution to their particular needs.

This is of course, less true for some categories (why are there so many pastebins??). But again, it's hard to find clear and objective criteria to determine what deserves to be listed and what does not.

If we started rejecting projects because "I don't have a need for it" or "I already use a somewhat equivalent solution and am not going to switch", that would discard 90% of entries in the list (and not necessarily the worst ones). I do check that projects being added are in a "production-ready" state and ask more questions during reviews if needed. But it's hard to be more selective than we already are, without falling in subjective "I like/I don't like" reasoning (let's ban all Nodejs-based projects, npm is horrible and a security liability. Let's also ban all projects that are so convoluted and impossible to build and install properly that Docker is the only installation option. Follow my thoughts?)

Also, Free Software has always been very fragmented, which is both a strength and a weakness. The list simply reflects that.

Another idea I contemplated is linking each project to a "review" thread for the software in question. But I will not host or moderate such a forum/review board, and it will be heavily brigaded by PR departments looking to promote their companies software.

A HTML version is coming out soon (based on the same data) that will hopefully make the list easier to browse.

I am open to other suggestions, keeping in mind the points above...

250+ self hostable apps

1268 exactly.

You can help cleaning up the list of unmaintained projects by working on this issue

• How do you backup things to your server? - Lemmy.world
• How do you guys back up your server? - Lemmy.world
• What are your backup solutions? - Lemmy.world

I tried OpenLDAP but Jesus that was very involved.

OpenLDAP is easy :) Once you understand LDAP concepts.

Check this and read through the tasks/ directory (particularly openldap.yml and populate.yml. It sets up everything needed for an LDAP authentication service (if you don't use ansible you can still read what the tasks do and you should get a pretty good understanding of what's needed, if not let me know).

In short you need:

• slapd (the OpenLDAP server)
• set up a base LDAP directory structure (OUs/Organizational Units, I only use 3 OUs: system, users and groups)
• an admin user in the LDAP directory (mine is admin directly at the base of the LDAP directory)
• (optional but recommended) a so-called bind user in the LDAP directory (unvprivileged account that can only list/read users/groups) (mine is bind under the system OU)
• (optional) groups to map users to their roles (e.g. only users in access_jellyfin are allowed to login to jellyfin)
• actual user accounts, member of one or more groups if needed

When you login to an application/service configured to use the LDAP authentication backend, it connects to the LDAP directory using the bind user credentials, and checks that the user exists (depending on how you configured the application either by name, uid, email...) , that the password you provided matches the hash stored in the LDAP directory, optionally that the user is part of the required groups. Then it allows or denies access.

There's not much else to it:

• you can also do without the bind account but I wouldn't recommend it (either configure your applications to use the admin user in which case they have admin access to the LDAP directory... not good. Or allow anonymous read-only access to the LDAP directory - also not ideal).
• slapd stores its configuration (admin user/password, log level...) inside the LDAP directory itself as attributes of a special entity (cn=config), so to access or modify it you have to use LDIF files and the ldapadd/ldapmodify commands, or use a convenient wrapper like the ansible modules tools used above.
• once this is set up, you can forget LDIF files and use a web interface to manage contents of the LDAP directory.
• OUs and groups are different and do not serve the same purpose, OUs are just hierarchical levels (like folders) inside your LDAP tree. groups can contain multiple users/users can have multiple groups so they're like "labels" without a notion of hierarchy. You can do without OUs and stash everything at the top level of the directory, but it's messy.
• users (or other entities) have several attributes (common name, firstname, lastname, email, uid, password, description... it can contain anything really, it's just a directory service)
• LDAP is hierarchical by nature, so user with Common Name (CN) jane.doe in OU users in the directory for domain example.org has the Distinguished Name (DC) cn=jane.doe,ou=users,dc=example,dc=org. Think of it like /path/to/file.
• to look for a particular object you use filters which are just a search syntax to match specific entities (object classes) (users are inetOrgPersons, groups are posixGroups...) and attributes (uid, cn, email, phonenumber...). Usually applications that support LDAP come with predefined filters to look for users in specific groups, etc.