Maybe I'm not seeing the speed improvements because it's a dense model, and I'm comparing it to the 3.6 MoE with MTP. Likely, I'm attributing the speed I see to something else.
Honestly, if MTP is available, I don't know why it's so much slower here.
Windows gives you recovery keys for each encrypted drive. With those you can even access tpm-protected drives on another machine.
I'd say it's mandatory today to encrypt drives. In the age of SSDs it's not really possible anymore to delete files and to be sure they are in no way recoverable by an adversary.
Docker (Compose) has some quirks compared to Podman (Compose), e.g. when using gvisor or a lot of internal networks. Depending on what you do your milage will vary, though.
Agreed. I found compose overlay files merged list values differently between the Docker and Podman versions, which was a PITA in teams running Docker & Linux dev machines.
FWIW, most of these issues were recently fixed in podman-compose. I can now use the current git version of podman-compose interchangeably with docker-compose.
And one nice thing about podman-compose is that it's ONE PYTHON FILE. You can just copy it into your source tree.
I'm using jj exactly this way, but `jj commit -i` is still somewhat backwards compared to `git commit -i`: jj displays the commit timestamp by default instead of the author timestamp like git. In addition, in jj the author timestamp of a commit is set to the time you started and not ended a commit/change. This results in unexpected timestamps when working with git-using people or tools. Also, it's rather weird if you use a previously empty commit for your work which was created months earlier by a previous `jj commit`, resulting in a timestamp neither correlating to when you started nor ended your work.
I guess the idea of jj's authors is that jj's commits are far more squishy and can always be changed, so a fixed finished timestamp makes less sense. I still prefer git's behaviour, marking work as finished and then keep the author (but not commit) timestamps on amends.
I use this jj alias to get git's timestamp behaviour:
[aliases]
c = ["util", "exec", "--", "bash", "-c", """
set -euo pipefail
change_id=$(jj log -r @ --no-graph -T 'change_id')
desc=$(jj log -r $change_id --no-graph -T 'description')
commit_author=$(jj log -r $change_id --no-graph -T 'author.email()')
configured_author=$(jj config get user.email)
jj commit -i "$@"
if [ -z "$desc" ] && [ z"$commit_author" = z"$configured_author" ]; then
echo "Adjusting author date"
jj metaedit --update-author-timestamp --quiet $change_id
fi
"""]
[templates]
# display author timestamp instead of commit timestamp in log
'commit_timestamp(commit)' = 'commit.author().timestamp()'
In German you use en-dashes with spaces, whereas in English it’s em-dashes without spaces. Some people dislike em-dashes in English though and use en-dashes with spaces as well.
In English, typically em-dashes are set without spaces or with thin spaces when used to separate appositives/parentheticals (though that style isn't universal even in professional print, there are places that aet them open, and en-dashes set open can also be used in this role); when representating an interruption, they generally have no space before but frequently have space following. And other uses have other patterns.
In British English en-dashes with spaces is more common than em-dashes without spaces, I think, but I don't have any data for that, just a general impression.
git absorb works surprisingly well. I was quite skeptical in the beginning, but it really turned into something I used daily (until I switched to jj, where I haven't found a replacement yet). If you use stepwise commits I can really recommend it.
small edit: It seems that jj supports `jj absorb` now as well. Wonderful!
Indeed, though I don't think it can create fixup commits if that's what you're looking for. However, it might work great for that if you pair it with jj-spr: https://github.com/LucioFranco/jj-spr
Yes, depending on your highlighting scheme. Not every highlighting scheme shows this by default, unfortunately.
To me, this seems initially like some very minor thing, but I find this very helpful working with non-trivial code. For larger methods you can directly discern whether a not-as-immutable-declared variable behaves immutable nonetheless.
Other than that they shouldn't have a big advantage for a more professional user with unique, long, and random passwords. For the common user it should be a great upgrade, giving all these advantages with better UX.
I'd say that the basic sailing knots should fit your bill pretty well. I can't recommend an online source, but you should find plenty resources on Youtube. It shouldn't take longer than an evening or two to learn them.
