HN user

varl

428 karma
Posts6
Comments14
View on HN

I've had issues with the sandbox feature, both on linux (archlinux) and two macos machines (tahoe). There is an open issue[1] on the claude-code issue tracker for it.

I'm not saying it is broken for everyone, but please do verify it does work before trusting it, by instructing Claude to attempt to read from somewhere it shouldn't be allowed to.

From my side, I confirmed both bubblewrap and seatbelt to work independently, but through claude-code they don't even though claude-code reports them to be active when debugging.

[1] https://github.com/anthropics/claude-code/issues/32226

Chezmoi has some interesting features, that go beyond simply managing dot-files in a Git-repo, that allows it too deepen in a way that makes it quite capable:

- templating for any configuration file built-in

- support for password managers

- can download and unpack an archive, or clone a repo, and refresh it e.g. once a week

- run scripts when applying config changes (either once, or every time)

- can handle config files that are externally modified

- can keep the source dotfiles encrypted on disk, and only unlock them when applying changes to the local generated files

In my usage so far Chezmoi has replaced and is now responsible for:

- Vim plugins

- ZSH plugins

- Generate SSH and GPG keys per context when a new machine is set up

- Git configuration (with per-machine and per context GPG and SSH keys)

- Install software on FreeBSD/Linux/MacOS that I need, both from source and/or package managers

- Per machine customization (e.g. differences between 4 core and 8 cores, or 1 GB of RAM vs. 48 GB RAM, etc.)

- Per OS customization (e.g. differences between ZSH on Arch vs. MacOS)

- Per host customization (e.g. different Vim configs on workstations vs. servers)

As far as setting up a new machine goes, I install chezmoi and git manually, and then I run `chezmoi init {dotfiles-repo}`, and that takes care of (almost) everything else, for MacOS, FreeBSD, Debian, and Arch Linux, each with the specific customization I need for that specific distro and host, all generated from a single source of configuration files.

Key for me is that all variations of e.g. `.zshrc` is generated from a single `dot_zshrc_tmpl` file.

Chezmoi is a tool that deepens with use, and I am finding more uses for it as I continue to use it.

When symlinks or a bare Git repo becomes unwieldy, perhaps the platform itself has a native solution (nix, home-manager) or there is something else that does all of it (ansible, dhall) and that's cool. In other cases there is Chezmoi, which was easy to learn to use.

... Except getting used to `chezmoi edit ~/.vimrc` to make changes to a config file. That is some hefty muscle memory to overcome.

I was sceptical of changing my dotfile management strategy (it's worked fine for a decade), but after trying chezmoi on a single machine, I spent an evening migrating all my machines to it as well.

10/10.

I'm not entirely sure, but `:` means "true" in bash, and if I omit it, something like this happens:

  $ git config alias.foo '! echo "$1";'
  $ git foo bar
  bar
  echo "$1";: bar: command not found
Whereas if I end with `; :` then it works as expected:
  $ git config alias.foo '! echo "$1"; :'
  $ git foo bar
  bar
It seems to execute the last argument (`bar`) as a command without the `:` at the end, and I don't have a `bar` command on my PATH so it angrily fails with exit code 127. If it instead executes `:` however, that will make it happily exit with 0.

It seems to be a Git alias quirk, but I may be incorrect here.

I found this user management strategy somewhere, and it's been working great for me:

  git config --global --unset user.name
  git config --global --unset user.email
  git config --global --unset user.signingkey

  git config --global user.useConfigOnly true

  git config --global user.<id>.name "<name>"
  git config --global user.<id>.email "<email>"

  git config --global alias.identity '! git config user.name "$(git config user.$1.name)"; git config user.email "$(git config user.$1.email)"; :'
So given that I have created two users, e.g. personal and work I run:
  git identity work
in repos that need the work name/e-mail, and
  git identity personal
in the ones that are private.

Everything is in the CV linked below.

  Location: Oslo, Norway
  Remote: 100%
  Willing to relocate: No
  Technologies: Java, Python, JavaScript
  Résumé/CV: https://github.com/varl/cv
  Email: viktor@vardevs.se

I imagine that a minimap could help with that, or showing nearest neighbors at the edges of the viewport, and perhaps being able to alt-tab between applications as well as groups would help.

You can use space to have a visual organisation of things, but you don't have to navigate the space since it's virtual. You should be able to navigate suitable to your platform running the viewport.

Pinch-to-zoom, drag to move, two-finger tap to bring up list of applications to move to instantly on a tablet.

Keyboard based navigation and manipulation of the canvas if you prefer to not use a mouse on your workstation.

Click to drag and scroll-to-zoom to navigate with a mouse, when that is more appropriate, for example.

It's common that good ideas exist for a very long time before technology enables them, yet I feel that we are at that point /now/ and have been for a while, yet there is little-to-no activity in this area.

Every now and again I come back to this, and think that this is the future in user interfaces. It would unite tablets, pc and mobile platforms around a single ui concept. I could use my PC to write something and then grab my tablet and connect to the same canvas and proof-read it.

We can have different viewports connected to the same infinite canvas at the same time and visualise them.

Much of our lives, even at home, is spent in this virtual space, so why not share it with one another?

If I was sharing my home computer with my partner over remote viewports, I can pan over to the place at the canvas she was currently using as her viewport and get a visual connection with what she was doing and interact a bit.

Of course you could have a "redacted session" in which case the area used as viewport would be blacked out, if you need secrecy for e.g. work.

I really enjoy the concept of sharing one computer and at the same time, like virtual space in addition to apartment space. This is, pretty much, a user interface extension of finger[1].

[1] https://en.wikipedia.org/wiki/Finger_protocol