greenicon

Unfortunately, opencode v2 still has mandatory remote config loading from your model provider's .well-known/opencode url, which gives your model provider remote code execution on your machine.

It's included in the model gguf itself.

At least in the past the default import-export route did not move attachments, be careful!

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.

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.

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!

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.

Passkeys cannot be phished.

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.

Wireguard does not re-resolve dns when your dyndns ip changes. This ip change is common in parts of Europe where it usually changes daily. To circumvent this you need a jumphost or similar. This again brings additional issues when you don’t want to go through the jumphost when at home (I use nftables-magic on the router, but it’s not very nice).

That’s exactly what prefix delegation is for. Your ISP ought to give an /56 or more, so you can then have multiple /64.

I get an /56 by my ISP and have 6 or so different /64 in my residence.

Modern CPUs are mostly limited by their energy budget/heat and smaller cores are more efficient. Also, if you have a workload scaling to, say, 8 cores chances are good that it also scales to 20+, allowing the usage of many small cores. Hence, having a few fast and then several smaller, more efficient cores should be also useful for workstations and servers.