Threads for twp

  1. 9

    I never really got into dotfiles. My problem is:

    • If I’m working on a remote system, it’s likely not mine, and I’ll only be there for a short time, or worse, on someone else’s account over a screenshare, so investing in knowing the defaults and quickly changing the intolerable is more convenient than trying to pull dotfiles on a client’s system.
    • If it’s my own system, I rarely configure a primary system (it’s usually like 5-7 years), and by the time I do get around to it, there’s a good chance I’ve switched platform, my own needs and tastes have changed, and I want to experiment with something new. Each new system is an opportunity to approach things with a clean slate.
    1. 5

      Pulling dotfiles on to a machine can be simple. Installing chezmoi is a one line command that only requires a shell and curl/wget, nothing else. You don’t need to install a scripting language runtime, or even git (chezmoi has a builtin git client using go-git if no git binary is present on the machine).

      Even if you rarely configure a primary system, I’m sure that you use a version control system for your code. Using any dotfile manager (there are many to chose from) brings the benefit of version control to your dotfiles, including easy rollback/undo (great for experimenting) and backups.

      1. 2

        That would be nice if the platform I work on supported Go :) - in all seriousness, while git is likely installed, the fact of the matter is it’d be ridiculous to install my configuration environment onto a client’s machine, let alone account on their own system.

        I don’t really change my configuration or deviate much from defaults either. It’s massive overhead for like what, 5 lines of .vimrc? Not to mention for i.e. GUI stuff, the config files in the XDG dir are possibly fragile across versions and not worth including in a scheme.

        1. 1

          if the platform I work on supported Go

          What platform is it?

      2. 2

        I’m in a pretty similar boat. I could use VS Code with a vi keybindings plugin, which is pretty great, or I could get better at vim/neovim, which is installed on literally every machine I have to work with, which often have to get worked on remotely or ad-hoc or through weird VPN’s. And I’m now even the person who writes the default .vimrc file, as long as other people are happy with it.

        The fish shell is worth it though. I wish I could install fish as default on all our work machines, but our infrastructure involves too many terrible bash scripts and people keep adding more. (Don’t say “use fish for interactive use and bash for scripting”, there’s (bad) reasons we can’t do that.)

        1. 2

          Well, at least you can use VSC on the local system and usually use it as the frontend for a remote system, almost like what the TRAMP people on Emacs do. (I’ve never had good luck with TRAMP, but the VSC remote editor works pretty well the few times I’ve tried it…. except none of my remote servers are Linux 🙄)

          1. 1

            Yeah I’ve used VSC a few times. It’s pretty great, but again, I’m often doing this on a generic service-terminal-we-provide-with-our-hardware Linux laptop or something of that nature. I haven’t yet had to hack a client’s workstation or a hotel courtesy PC to fix something, but I could see it happening.

            1. 1

              Curious what issues you’ve had with tramp

              1. 1

                Two issues from my list:

                • one of my customers has configured the prompt of all his servers with colors in the bashrc. Tramp checks for a specific regex (I believe) to figure out it had a successful login. I can’t find how to connect without editing those. Took me a long time to understand what was going on
                • I am too thick to understand how to use sudo
                1. 1

                  I can’t help with the first.

                  For me, sudo is :sudo-edit

                  1. 1

                    Ahhh interesting.. thanks. I’ll be experimenting immediately if that cover also org remote execution. Thanks

        1. 20

          With respect to “Every computer is different”, chezmoi has explicit support for this: you can use templates to handle small differences (e.g. tweak your gitconfig for home or work machines, or tweak your .zshrc for Linux or macOS), and include or exclude dotfiles completely for large differences (e.g. only include a PowerShell config on Windows). See this page in the user guide for more details.

          Disclaimer: I’m the author of chezmoi.

          1. 4

            Thank you for making chezmoi, I use it on several Mac and Linux machines and it works great. Much easier than trying to manage my dotfiles in Ansible, which was my previous plan.

            Perhaps the killer app for me is that if there’s some weird hack I do to get something working on a given machine, I can document it in code e.g. in my setup scripts, so that if I have to (god forbid) wipe the machine and start over, I can just run the hacks again instead of trying to remember what the heck I did last time. This happens with depressing frequency because our entire field is bad at what we do.

            If anyone wants to see the ungodly mess I’ve made of my dotfiles, here’s my chezmoi repo.

            1. 3

              wow, thanks for sharing your project, I had never heard of it. between the template support, and the thorough documentation, I think I may have to give this a try.

              I’m currently running with the “$HOME is a git repo” method, which has been working well but obviously has at least one major footgun to avoid, and doesn’t really work well with having multiple systems that require different config/options.

              1. 2

                I recently started a new job and for the first time in years decided to split my personal and work stuff onto two separate computers, so I’ll want some configuration that follows me between machines. This also gave me a chance to rethink my shell environment generally (e.g. moving from bash to zsh).

                Choosing chezmoi was one of my first decisions and it’s been great. Thank you for your work on this project!

              1. 21

                Appreciated that you’re trying to help here, but open source projects don’t just get maintainers by looking for random people on the internet. A new maintainer needs to be invested in the project, have an existing history of high quality contributions, and a be trusted to maintain the project’s vision, i.e. any potential new maintainers will already be known to the existing maintainers.

                1. 6

                  You’re correct, but I don’t think it defeats OP’s purpose.

                  There are many projects that I use (but have never contributed to), that I’d be willing to find the time to inherit if no one else would. I’m not saying the outgoing maintainer should hand it off to me straight away, but this serves as a plaza to put outgoing and incoming maintainers in touch with each other.

                  1. 5

                    There’s also for this specific purpose

                  2. 1

                    Right. I find it hard to work or understand things I’m not interested in (or motivated to be), so I’m not sure how well this drive-by maintainer search could work.

                    1. 4

                      The idea for this list came from a Mastodon thread. Someone I follow was feeling burnt out about his project and was looking for someone to help him review submissions for the, to which I offered my help. I’m now reviewing multiple PRs a day for the project.

             is an experiment to see if there is demand for such a platform in other parts of the internet.

                      1. -6

                        Looks like no.

                  1. 5

                    Great article!

                    From the article:

                    A modern templating engine

                    Short-circuit evaluation. Go’s templating language always evaluates an entire conditional in a clause, which makes for some really fun bugs (that again will not manifest until runtime.)

                    This is coming in Go 1.18:


                    The and function no longer always evaluates all arguments; it stops evaluating arguments after the first argument that evaluates to false. Similarly, the or function now stops evaluating arguments after the first argument that evaluates to true. This makes a difference if any of the arguments is a function call.


                    1. 1

             is a similar library for Go. Strongly recommended if you want both shorter tests and better test coverage.

                      1. 2

                        Talking about CPU-friendly code, is there a good example of a Go application written in a data-oriented design paradigm? Something that Mike Acton and Stoyan Nikolov described in their talks concerning C++.

                        1. 6

                          go-geom uses a linear layout for its coordinates, which makes it 30% faster than the equivalent C library in benchmarks, see

                        1. 2


                          Pure Python implementation of make (note: Makefiles are written in Python too) written to support cross-platform development some time ago.

                          1. 8

                            chezmoi gives me the same CLI environment (shell aliases, editor configs, etc.) across all the machines I use, including work, home, laptops, desktops, and temporary VMs and containers.

                            Disclaimer: I’m the author of chezmoi, but it’s popular and a lot of people have written about it.

                            1. 3

                              Chezmoi has been absolutely phenomenal, as has your support! I’m delighted to regularly evangelize it.

                            1. 2

                              I’m not sure what is the advantage of Chezmoi over more powerful tools like Ansible, Saltstack. I take a look at the Quick Start guide and not really convinced.

                              1. 7

                                I think they are intended for different use cases. Chezmoi is about setting the user config, by copying the config files to the right places under $HOME, while Ansible and Saltstack are for configuring the whole OS.

                                This is a matter of a personal preference, but one should never “program” in YAML to configure anything, even the OS :)

                                1. 3

                                  Exactly this. Chezmoi is aimed at a much smaller problem than “whole system” configuration. In fact, I use ansible to set up my Chezmoi initial configuration when bringing up a new computer, so for me at least the two are complementary.

                                1. 4

                                  Great write-up!

                                  A few comments as the author of a filesystem abstraction library for Go (

                                  • io/fs will surely be useful in some circumstances, but its lack of support for writes is a major omission that limits its usefulness.
                                  • Afero’s MemMapFs attempts to simulate a filesystem in memory but the simulation is buggy. One bug I encountered is that file system access is not correct: if you make chmod 000 a directory, Afero’s MemMapFs still allowed you to read subdirectories of that directory, whereas a real filesystem doesn’t.
                                  • Furthermore, the filesystem semantics vary from operating system to operating system and from filesystem to filesystem. For example, on Windows you cannot delete a file while another process has opened it. Different filesystems have different behavior when it comes to filename limitations (e.g. FAT), case sensitivity, and whether they are case preserving. MemMapFs - and generally any simulated filesystem - will invariably have bugs where it does not behave in the same way as the real filesystem and therefore is not useful for testing.

                                  For this reason, wraps Go’s os functions, rather than trying to simulate them. This means that for testing it behaves the same way as the underlying filesystem, and has significantly less code (and therefore hopefully fewer bugs).

                                  1. 2

                                    Afero’s MemMapFs attempts to simulate a filesystem in memory but the simulation is buggy. One bug I encountered is that file system access is not correct: if you make chmod 000 a directory, Afero’s MemMapFs still allowed you to read subdirectories of that directory, whereas a real filesystem doesn’t.

                                    This is exactly the kind of metadata finicking that made them stick to read-only and no writes :P

                                    Speaking from experience with strange bigcorp data storage systems, I have to say that specific writing interface + generic reading interface works surprisingly well. As a concrete example, append-only filesystems unlock a lot of performance boosts. Having separate PosixWritableFS and WindowsWritableFS interfaces seems prudent.

                                  1. 4

                                    This article seems to be based on a flawed understanding of floating point numbers. The author complains that “sin(x) gives me different results in different versions of Node”. What the author does not demonstrate in the article is the understanding that floating point numbers are approximations themselves, i.e. a given pattern of bits does not represent a precise number, but rather some range of numbers. Consequently, sin(x) is not well defined because x itself is not well defined.

                                    1. 2

                                      a given pattern of bits does not represent a precise number, but rather some range of numbers.

                                      Do you have a source for this? I don’t think this is correct - my understanding is that while every floating point number has an infinite number of numbers that will round to the same value, a given pattern of bits has a single canonical value that it represents.

                                      As the author points out, while floating point operations like addition/etc can exhibit surprising results, they are well defined, in that any two floating point numbers have a specific floating point number that is their sum. The fact that addition/subtraction/etc have this property, but sin/etc do not is somewhat interesting.

                                      1. 1

                                        It’s not so much that the numbers themselves are approximations; it’s that the formulas used to compute trig functions are infinite series. The more terms you add up, the more accurate the result, but the longer it takes. I’m not an expert on current FP code, but I doubt it keeps grinding out terms until the result stops changing. Instead there’s a balance between speed and accuracy. And of course different implementations have different trade-offs.

                                        1. 1

                                          There used to be LUT accelerated solution in i387 and i486+ CPUs. Since SSE2 there are fast trigonometric functions (faster and simpler to call I think) than the i387 floating point solutions. Switching between these implementations may result in different results. Software solutions are available, based on the Taylor series of the functions, but those are multiple magnitudes slower, and I doubt that node would rely on those.

                                          Also floating point numbers do have a canonical value per se, but floating point arithmetic is an approximation, and it is expected to be treated as such.

                                          1. 2

                                            For sine in particular, because a transcendental constant is involved, we have what Kahan called The Table-Maker’s Dilemma: How do we round the result?

                                        2. 1

                                          Even the sum may change in a way “unexpected” by the author:

                                          Even the conversion between the binary and decimal representation of a floating point binary number is (as in printf/scanf) an approximation, and this may change with node version (if they ship their solution and don’t use libc). Theoretically even a microcode update may effect floating point operations (although not likely).

                                          Thus even by having the same Math.js deployed everywhere there are a multitude of variables at play on lower levels. Here cross-platform differences have been generously ignored.

                                      1. 1

                                        Consider - it’s a dotfile manager with many of the features that you want and is very quick and simple to get started with.