Liquibase and Flyway are the only major frameworks on the JVM which could be embedded into a JVM application to get rid of a sidecar or a startup process which has to run before the actual application could start.

That's exactly why Liquibase turned source-available. These abstractions are leaky, error-prone and are better maintained via the money from support contracts.

"Make problem, they earn money fixing them" is a reasonable modus operandi.

Try to sit through the 5 hours of interview with Carmack if you are a coder, or the interview with Aella, if you are more into humanities.

These two are his crown jewels, IMO.

Oh those snowflake politicians! When do they grow thick skin? /s

For them, it's more about enabling micropayments. So far, the only successful micropayments system was advertising, and it's a real shame we couldn't build better.

You probably don't realize it, but multi-device support, group chats of tens of thousands of users, channels with millions of users and comments of said users. Attachments and history and search. And then a whole infrastructure for running bots and processing payments. And proxies to fight blocking attempts. All of these are either highly problematic or computationally intensive and practically infeasible with E2E on.

Otherwise, someone would have taken the opportunity and reimplemented Telegram on top of homomorphic encryption /s.

Small groups could likewise be supported.

I take the point that for large groups client fan out of the double ratchet doesn't scale. We now have MLS but we didn't. There's also an argument of how can you really keep a secret in an open group of a few thousand people.

But on a small, "personal" level, e2e could absolutely be done. Not doing so is a choice, one that conveniently ends with almost everyone's chats stored on servers somewhere.

I would go so far as to say I bet telegram is a goldmine for TLAs.

Change directory to your local git repository that you want to share with friends and colleagues and do a bare clone `git clone --bare . /tmp/repo.git`. You just created a copy of the .git folder without all the checked out files.

Upload /tmp/repo.git to your linux server over ssh. Don't have one? Just order a tiny cloud server from Hetzner. You can place your git repository anywhere, but the best way is to put it in a separate folder, e.g. /var/git. The command would look like `scp -r /tmp/repo.git me@server:/var/git/`.

To share the repository with others, create a group, e.g. `groupadd --users me git` You will be able to add more users to the group with groupmod.

Your git repository is now writable only by me. To make it writable by the git group, you have to change the group on all files in the repository to git with `chgrp -R git /var/repo.git` and enable the group write bit on them with `chmod -R g+w /var/repo.git`.

This fixes the shared access for existing files. For new files, we have to make sure the group write bit is always on by changing UMASK from 022 to 002 in /etc/login.defs.

There is one more trick. For now on, all new files and folders in /var/git will be created with the user's primary group. We could change users to have git as the primary group.

But we can also force all new files and folders to be created with the parent folder's group and not user primary group. For that, set the group sticky bit on all folders in /var/git with `find /var/git -type d -exec chmod g+s \{\} +`

You are done.

Want to host your git repository online? Install caddy and point to /var/git with something like

    example.com {
    root * /var/git
    file_server
    }