Hacker Newsnew | past | comments | ask | show | jobs | submit | varl's commentslogin

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


Its seccomp filter also doesn't work, at all: https://github.com/anthropics/claude-code/issues/24238

James Hoffmann has a video where he tastes different instant coffee. Subjective, but could serve as inspiration for products to try of good quality (and what to stay away from):

https://youtube.com/watch?v=8cIqLvJz8VM


I went to mesonbuild.org and it doesn't match the description (some sort of betting site? I didn't stick around ...), and a search turned up:

https://mesonbuild.com/


Thanks, I mistyped it.


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.


Honestly, that's quite the list. From the title and even the home page, it looks like yet another dotfiles manager, but it looks like it can replace what I've gotten with half-baked scripts. Integration with password managers is great!


If you're the kind of person to use ansible or equivalent, anything user-specific is most likely a better experience in czm.

You can get away with doing stuff like package installation as well but anything more advanced on system-level and you probably want to keep/introduce configuration management for that.


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 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.


I find it much easier to use direnv and set GIT_AUTHOR_EMAIL in each of ~/work/.envrc and ~/personal/.envrc No need to reconfigure every repo this way.


Git has conditional includes based on path[1]. My configuration is like:

On ~/.gitconfig

  [user]
    name = personal
    email = personal@example.com

  [includeIF "gitdir:~/workspace/"]
    path = ~/work.gitconfig

Then on ~/work.gitconfig

  [user]
    name = workname
    email = work@example.com
[1] https://git-scm.com/docs/git-config#_conditional_includes


Just a note of caution, when this feature was added tools based on libgit2 did not understand it. I just checked now, libgit2 eventually added support (though it took 5 months since I filed the ticket). But if you're using any tools that have a 3-year-old version of libgit2 they might not understand it.


Woah, this is neat!


I do the same. Also remember the following keyword if you use nested .envrc files: source_up

If you don't use this in any nested envrc files, the settings don't carry over which means your git settings are not maintained. It is kind of an escape hatch as the parent files are not verified in the same way normal envrc files are, but I have found the trade off to be worth it


I also appreciate using `git whoami` to check the current identity settings:

    $ git whoami 
    GIT_COMMITTER_IDENT=Mel Smith <mel@example.org>
    GIT_AUTHOR_IDENT=Mel Smith <mel@example.org>
`whoami` can be implemented via a simple alias:

    git config --global alias.whoami = "! git var -l | grep '^GIT_.*_IDENT'"


Nice! I was thinking of something like this recently, but decided instead to completely divorce personal and work projects. It’s nice to close the work laptop and go open the personal laptop knowing it’s impossible to cross the streams, as well as for the ritual.


Good idea as it makes the trees "self describing".

But: does this edit a file that can appear in .gitignore or are you uploading this to affect all your collaborators?


It writes to `.git/config` in the local repo. (.git/ is ignored by default, obviously.)


> git config --global alias.identity '! git config user.name "$(git config user.$1.name)"; git config user.email "$(git config user.$1.email)"; :'

Why `; :` at the end?


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.


Seems it's to allow implicit and explicit use of arguments passed to alias. Git does the following to the alias string[1]:

  argv_array_pushf(out, "%s \"$@\"", argv[0]);
So, you can have aliases like `!grep foobar` to automatically accept arguments or aliases like yours that use arguments explicitly.

I've done aliases like `!bash -c 'foo $1' sh` before, but on seeing yours, I see that it was unnecessary to re-wrap with bash.

[1] https://github.com/git/git/blob/e31aba42fb12bdeb0f850829e008...


Huh I had no idea $1/$2/etc worked as-is in an alias. The advice I learned years ago for dealing with any alias that needs to do something custom with parameters is to write it like

  git config alias.foo '!f() { actual command goes here }; f'
as that will pass all the args to the shell function. But if git is already setting it up so the args work then suffixing the alias with ";:" seems simpler.


> The advice I learned years ago

Being able to use $1/$2/etc directly might be a relatively new development.

EDIT: Or maybe not. This might have been doable since 2010:

https://github.com/git/git/commit/8dba1e634af1d973a47fca616a...


2010 is still “new development” to me


Interesting! Thanks for digging up the code.


I've been doing the same, this it's pretty good IMO.


I recommend and use this log system where you only have to take an action when you beat your rep range: http://exrx.net/WeightTraining/Log.html


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 pick an issue from the bug tracker and start working on it.


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.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: