[HN Gopher] A decade of dotfiles
___________________________________________________________________
A decade of dotfiles
Author : mmazzarolo
Score : 276 points
Date : 2022-05-30 10:25 UTC (12 hours ago)
(HTM) web link (evanhahn.com)
(TXT) w3m dump (evanhahn.com)
| thayne wrote:
| The first part of his murder command can be accomplished by using
| pkill or killall (but maybe those aren't available on mac?). The
| second part is useful though.
| asiachick wrote:
| Going to be _that_ person but an article named "a decade of
| dotfiles" has nothing to do with dotfiles. The first sentence
| says "My first commit to my dotfiles repository was ten years
| ago" and then the entire rest of the article has nothing to do
| with "dotfiles" whatsoever.
|
| And then nearly all of the comments are actually about the title,
| not about the article itself.
| swyx wrote:
| sharing my own new mac setup + dotfiles here:
| https://github.com/sw-yx/swyxdotio/issues/420 (maintained for ~5
| years)
| yonrg wrote:
| dot files, configs and hosts are now managed in ansible.
|
| First solution a decade ago was to have a git repo and dotfiles
| were linked directly into the working dir. This was nuts. The
| dots were changed immediately, when checking out other branches.
| And slight differences between hosts were not easily manageable.
| A branch per host was not a solution.
|
| I learned from those mistakes and wrote an installer script for
| that repo which copied/rsynced files from repo into ~
|
| Still, slight changes between hosts were not easily manageable
| and I was thinking about a templating mechanism... but then
| ansible became a thing which I happily adopted.
|
| Might be too much for most users, but it helps me managing many
| machines.
| mathstuf wrote:
| Yeah, I started with the direct symlink long ago too
| ("declarative" lines that were just shell commands sourced at
| the top). I now have a more...complex setup that uses CMake.
| The basic setup is: group/ (e.g., "devel" or
| "pim") program/ (e.g., "vim" or "mutt")
| CMakeLists.txt (lists files and packages needed; I use Fedora)
| config/ local/
|
| repeat for each program, sorted into groups. Each program is
| added via a function that wraps `add_subdirectory` in an option
| asking if I want to enable that project. It also takes a list
| of dependencies (so, e.g., `mutt` is hidden if I turn off
| `msmtp` or `nvim` since it needs it in its configuration).
|
| Each program's CMake code declares what needs symlinked,
| directories to be made, permission bits, etc. This is used to
| also write out a "validation" script to ensure symlinks are
| accurate and to notice untracked config files and such. I then
| just configure, turn the programs I plan on using on in the
| project and then "build" it. It also generates a `dnf install`
| argument list for me to install anything needed for these
| configurations.
|
| The symlink setup is actually `$HOME/.path` (to avoid the repo
| from having hidden files; skippable if needed in the CMake
| code) -> `$builddir/group/program/path` ->
| `$srcdir/group/program/path`. This way, turning off a program
| nukes the build tree and then I can just go and look for broken
| symlinks in `$HOME` to clean up. Per-host bits overlay cleanly
| since I use split configs where possible (i.e., `include
| *.rc`).
|
| One nice thing about using CMake is that I can also have
| `add_custom_command` at hand to generate files if needed (I use
| it to generate `xcompose` combinations).
| caeruleus wrote:
| Last year, I started setting up a Qubes OS workstation. Doing all
| the intricate little steps manually seemed like such a waste of
| time that I started learning SaltStack, which is built into the
| Qubes management stack, to be able to automate and replicate the
| setup. This small itch exploded in such a way that I wrote a
| formula for almost every program on every system and server I
| use. For all other small programs, I just use one formula that
| syncs the appropriate dotfiles (I can also template them with
| Jinja).
|
| In hindsight, going with Nix would have been the most efficient
| way to reach most of that, apart from the Qubes-specific stuff.
| This will probably be the next step on my (ironic) odyssey of
| going all-in on configuration to finally stop worrying about it
| and reap the benefits of the beauty that is computing without its
| nasty warts.
|
| In essence, I would love a proper integration between Nix and
| Qubes OS.
|
| Edit: For anyone interested in an example of my current process,
| see https://github.com/lkubb/salt-tool-chromium-formula,
| https://github.com/lkubb/salt-tool-gpg-formula or
| https://github.com/lkubb/salt-tool-macos-formula.
| rgoulter wrote:
| > In essence, I would love a proper integration between Nix and
| Qubes OS.
|
| This sounds like it'd be interesting to you: https://spectrum-
| os.org/
| nunez wrote:
| I also started my dotfiles over ten years ago! First commit was
| in 2012. Use them every day. I thank the awesome folks at Jane
| Street for teaching me about both dotfiles and Mercurial! (Second
| job out of college.)
| pqs wrote:
| I started in 2009. :-)
| technothrasher wrote:
| 1990, and I've still got things in my .cshrc to fix quirks in
| SunOS 4 and Irix that I can't bear to remove out of
| nostalgia.
| zvr wrote:
| 1983, but not in a git repo ;-)
|
| Also stuff to distinguish between different Unix flavors
| and hardware ("if it's this host which is a sun3 with FPU,
| add -m68881 to CFLAGS") -- not removed but commented out.
| jchook wrote:
| > Prefer scripts over aliases
|
| I prefer aliases when possible because they inherit autocomplete
| rules. Also it's easy to "complect" things with custom scripts.
| yakshaving_jgt wrote:
| > It doesn't work for everything. For example, I have a boop
| command (which I mentioned above) that needs access to the
| previous command's exit status--as far as I know, that's
| impossible with a script.
|
| I got nerd-sniped by this. I can't see any reason why this
| wouldn't work. I tested this myself by writing a script called
| show-error.sh: #!/bin/bash echo $?
|
| And then I ran $(exit 5) . ./show-
| error.sh
|
| And this outputs 5
| SuchAnonMuchWow wrote:
| this only works because you are sourcing the file, and not just
| executing it:
|
| $(exit 5) ./show_error.sh
|
| outputs 0.
|
| Sourcing the file is the same as copying and pasting its
| content into the current shell. It is designed to allow this
| kind of things (accessing the caller execution context). But it
| is not what we usually call a script precisely because of this.
| throwaway41232 wrote:
| I cant really check this right now but doesnt
|
| $(exit 5)
|
| just spawn a subshell which exits with 5 which is visible by
| the parent script you just source your show-error.sh in?
|
| Try to subshell the source too like
|
| (. ./show-error.sh)
| faho wrote:
| Well, yeah, if you _source_ the file (for which `.` is a
| shortcut) it runs in the current shell so the environment is
| intact.
|
| If you just run it it won't work.
|
| So instead of running `boop` you would always have to `source
| boop` or `. boop`. A function or alias you could just run like
| normal.
|
| (and `export ?` complains about ? being an invalid identifier
| in bash, in zsh `export "?"` apparently "works", but will reset
| it before you get a chance to print it in another process)
| NegativeLatency wrote:
| You could also pass the exit status into the program being
| called
| kunalgupta wrote:
| luv murder
| francis-io wrote:
| No one asked, but I feel like I've been down this road before.
| Heavily customizing a system with obscure lines plucked from
| strangers dotfiles. These days I use VS Code and Firefox for
| almost everything.
| iRomain wrote:
| For my dotfiles [1] I use https://www.chezmoi.io which I really
| like using and stuck (as opposed to my previous dotfiles attempts
| which didn't stick). Albeit I have only been using it for a few
| months as opposed to the author's decade.
|
| I guess the idea is to find the one tool/methodology that sticks
| with you.
|
| [1] https://github.com/politician/dotfiles
| blueflow wrote:
| I find it odd that people use extra management software for
| their dotfiles. Most of the files are in `~/.config` anyways,
| so you can track this folder like a regular directory in git.
| And for the software that does insist on writing into `~`
| directly you can set up symlinks, with a script or manually.
| yunohn wrote:
| > I find it odd that people use extra management software for
| their dotfiles
|
| > you can set up symlinks, with a script or manually.
|
| So yeah... that's exactly what dotfile managers do with
| standardised scripts.
| twp wrote:
| Tracking `~/.config` as a regular directory in git only works
| if all your machines are near-identical. If you want to share
| dotfiles between, say, Linux and macOS, or between your home
| and work machines, then a dotfile manager makes it much much
| easier.
|
| For more reasons, see: https://www.chezmoi.io/why-use-
| chezmoi/
|
| Disclaimer: I'm the author of chezmoi
| vivab0rg wrote:
| Unrelated, but thank you for chezmoi, it's a clever little
| utility very well designed. I use it to manage many
| distinct Arch-based systems and soon will be moving my
| Ubuntu servers to it. Congratulations!
| twp wrote:
| Thank you <3
| vivab0rg wrote:
| I managed my dotfiles across many distros using a bare multi-
| branch Git repo. But eventually it became a chore to share
| snippets among them. Chezmoi is little thin utility wrapper
| over Git that handles this usecase beautifully. I switched to
| Chezmoi over the weekend and just shudder to the thought of how
| much time I could have saved had I found it earlier.
| e3bc54b2 wrote:
| This is a good one, I hope I'll have mine for that long (started
| 2019).
|
| Personally, I stopped worrying about dotfiles and GNU stow after
| joining the cult of Nix. While I gave honest attempt to
| everything else, Nix made it stick. Now I only have one single
| repo, where In write config for (almost) all of my applications
| in Nix, deploy them with Nix, rollback with Nix etc. Compared to
| hodgepodge of INI/YAML/TOML/XML/JSON/WHATHAVEYOU it is nice to to
| only have single tool to worry about.
|
| I wished Guix had the momentum and size of Nixpkgs. I'd much
| prefer a Lisp than the language contraption of Nix.
| doliveira wrote:
| Oh, I so wish to learn it, seems quite awesome. I literally
| made my own scripts to do exactly this management over the
| years. But the learning curve seems huge, not many good
| resources, etc... Honestly they all sound like those posts
| trying to explain monads
|
| And frankly, I barely have motivation to study more concrete
| stuff...
| e3bc54b2 wrote:
| Admittedly, it can be worse than sitting down and reading the
| manual front to back, but I did it the hard (or simple) way.
|
| I used the simple template generated during nixos-install and
| kept adding packages I needed. Configured them manually as
| usual and went about my business. It works out more often
| than people would realize. For services, development
| toolchains etc just google and copy-paste from other people's
| config. Simply add 'ext:nix' to google query and you should
| be good.
|
| I'm at almost 3 years, know just enough Nix to write some
| custom stuff, but nowhere close to the Wizard title. Its not
| as bad as people make it out.
|
| Remember, your target is not to master it on day 1. Target is
| to get VLC to play the media file (or some equivalent for
| you).
| klysm wrote:
| As soon as you get something weird though, the rabbit hole
| is forever
| ewuhic wrote:
| Can one use the benefits of Nix provisioning while using other
| linux distro, Debian specifically?
| PufPufPuf wrote:
| You can install Nix package manager on any system, but the
| packages will be separate from system packages. You can try
| it and switch to full NixOS if you like it
| mschwaig wrote:
| If you are talking about provisioning dot files and command
| line applications you want to have available on all you
| machines then take a look at home-manager.
|
| https://github.com/nix-community/home-manager
|
| I use it on NixOS. It should absolutely work on other distros
| unfortunately I don't have any first hand experience with
| that or with what the best way is to set it up on other
| distos (I think there are few options for how to do it).
| chrisweekly wrote:
| > "there are few options"
|
| I'm curious about your phrasing. In idiomatic English, this
| says "there are _not many_ options", IOW options are
| limited. It emphasizes the constraints. OTOH had you
| written "there are _a_ few options", it'd emphasize the
| existence of more than one option, with a positive
| connotation.
|
| From context I infer you meant the latter, is that right?
| mschwaig wrote:
| Yes sorry. This was a typo.
|
| I meant to write 'a few options'.
| rgoulter wrote:
| Yes. I think it's a good way to get started with Nix.
|
| e.g. with nix installed, you'll be able to use the nix-shell
| to get the development dependencies without having to install
| system wide, if a shell.nix or flake.nix has been written for
| it. (e.g. for repos like https://github.com/helix-
| editor/helix).
|
| You'll be able to use the `nix shell` command to try out a
| program without needing it installed system wide. Or you can
| figure out how to write your own nix-shells etc.
|
| I think Home Manager is worth trying only once you're
| otherwise familiar with Nix (or if you find a good config to
| copy-paste from, though), since Nix's error messages and
| debugging still aren't great.
| francis-io wrote:
| Currently I use Ansible to deploy my dotfiles, along with
| anything else needed to setup a workstation. I keep seeing
| people mention Nix. Would it give me anything that Ansible and
| Git can't give me?
| pmarreck wrote:
| Ansible : Nix :: using Javascript to lay out a webpage :
| using CSS to lay out a webpage
| colordrops wrote:
| There is no AnsibleOS, so you'll not have a reproducible OS,
| and as the base OS gets upgraded underneath, ansible scripts
| will break. Also, you have to put a ton of effort into making
| sure Ansible scripts are idempotent, and even then there are
| usually leaks. Nix (with flakes) is 100% reproducible and
| it's very difficult to do anything that isn't idempotent.
| What this all means is that there is more effort up front
| learning and setting it up, but a lot less effort and
| suffering in the long term.
|
| I personally switched for these reasons.
| noahmasur wrote:
| Mostly it provides guarantees about your system. It
| guarantees that anything not in your config is not on your
| system (for the most part). It guarantees that everything
| builds successfully before it applies any changes. Most of
| the filesystem is immutable so it forces you to use the
| configuration.
|
| There are some other advantages: rollback to a previous state
| at any time, enable complex system services with one line in
| your config file, install multiple versions of tools on your
| system without conflicts, install programs without root
| (using home manager), build VMs and Docker images, pin the
| versions and dependencies of all packages for
| reproducibility, patch software with your own tweaks
| natively. You can also put a Nix file in a code repo and
| easily share your build dependencies with other developers.
| francis-io wrote:
| This might show my ignorance, but can Nix replace something
| like asdf (https://github.com/asdf-vm/asdf)?
| noahmasur wrote:
| Yes, that's exactly the kind of thing it's great at.
|
| Nix stores all builds of its packages in a separate
| "store" on the machine, each identified by the hash of
| the build ("derivation"). When you activate your config,
| it basically symlinks the version you want into your
| PATH.
|
| If your project needs a specific version, when you
| activate a Nix shell or script it will check your store
| for that version and activate it. If it doesn't exist, it
| will fetch it (or even compile it from scratch if you
| need to).
| kcorbitt wrote:
| Part of the magic of asdf is that it reads a `.tool-
| versions` file from anywhere above your current directory
| and applies the correct version of each tool based on the
| listed value. (You can also configure a global default
| version for each tool in case your directory tree doesn't
| have a .tool-versions file with an entry for the tool you
| want to use.)
|
| Does Nix allow for a similar workflow? It's really nice
| to be able to move between projects and automatically
| have the correct tool versions configured without having
| to run any special command.
| noahmasur wrote:
| To add to what rgoulter said, you can use your default
| system configuration plus whatever the project says you
| need (and the project's shell will override any conflicts
| with your default).
|
| However, if you really want to make sure that you're not
| including anything from your system, you can have direnv
| pass the `--pure` flag, which will then include _only_
| the dependencies from the project and nothing else. This
| is helpful to make sure that you 're not accidentally
| relying on something already on your system when you
| declare the project dependencies.
| rgoulter wrote:
| Pretty much. You'd use Direnv to support this UX.
| https://direnv.net/
|
| I think the nice thing about project-specific tooling
| like this is it allows getting started with the project
| very easily. (Rather than copy-pasting "apt-get
| <whatever>").
| rgoulter wrote:
| I'd describe nix as "programmatic package management". Nix is
| a difficult tool to learn, but very powerful. A lot of nice
| UX use cases with Nix could perhaps be described as "like
| Docker, without the containers".
|
| In terms of applying configs, ansible is 'convergent', where
| Nix is 'congruent'.
| https://blog.flyingcircus.io/2016/05/06/thoughts-on-
| systems-... (ansible will make changes to get it closer to a
| target state, whereas nix will reach the target state by
| constructing the target state again).
| francis-io wrote:
| Thank you. As someone who uses containers a lot (even to
| run local programs, shout out to
| https://blog.jessfraz.com/post/docker-containers-on-the-
| desk...) this makes some sense to me.
|
| I'm a little way into the Nix Pills document
| (https://nixos.org/guides/nix-pills/why-you-should-give-
| it-a-...) which seems to start the explanation from a place
| where I can understand.
| ajvs wrote:
| X11 is pretty poor for security, you should use Flatpak
| as it has sandboxing and still stores all its files in
| one directory.
| rprospero wrote:
| The biggest advantage that I can give is that everything is
| together in a unified language. To give a trivial, but
| extreme example, my workstation's colour scheme is controlled
| via my Nix setup. This includes terminal colours, GTK theme,
| Emacs syntax highlighting, Matplotlib colours, CSS overrides,
| window manager, and more. Yet I can change a single line in
| my Nix file and update all of these without worrying about
| the myriad configuration languages that are involved. A
| single change on a different line will update the default
| font for all these applications as well.
| jeppesen-io wrote:
| yep! also what I find nice is you can just ref a package in
| a config and it just gets installed
|
| e.g. create a g zsh alias for git using the alias section
| of zsh module in home manager
|
| > g = "${pkgs.git}/bin/git";
| klysm wrote:
| I wonder if we can make nix into a library of sorts for other
| languages so we don't have to deal with its arcane-ness.
| a-dub wrote:
| i want to like nix, but the inconsistent naming and use of the
| language was a huge turn off.
|
| all the randomly named config options and the spotty coverage
| of them were like fingernails on the chalkboard for me.
| tylergetsay wrote:
| Any tips on places to get started with Nix?
| jeppesen-io wrote:
| I'd just install nix + home-manager on your linux or Macos
| box. That's not too hard. Then take one of your dotfiles
| supported by home-manager e.g. kitty term, and port it to nix
| + home-manager
|
| No need to boil the ocean, just start small. You can mix and
| match with what you're using now. If you like, port it all to
| nix over time
| e3bc54b2 wrote:
| If you're looking to learn Nix start-to-end, there manuals
| for Nix and NixOS, both are good.
|
| This is an extensive study at trying to 'understand' Nix,
| because is does so many things differently:
| https://ianthehenry.com/posts/how-to-learn-nix/
|
| If you're just looking to start building your system, follow
| NixOS manual up until you have a running system, then pace
| yourself as you will. You can also setup Nix on existing
| Linux distro or macOS and practice the ropes before plunging
| into NixOS.
| pmarreck wrote:
| > I wish Guix had the momentum and size of Nixpkgs. I'd much
| prefer a Lisp than the language contraption of Nix
|
| This is exactly my feeling as well. The fact that Guix uses
| Guile (which is basically Scheme, a Lisp) throughout the entire
| process (even from the preboot environment!) is kind of a big
| deal. Plus the commandline UI is just _better_ (at least if you
| prefer your package manager to look like "brew install
| <packagename>" instead of "pacman -Ssyyu <package>"). I know
| the "nix" command is making headway there but it's apparently
| also being rewritten at the same time and is basically still a
| buggy clusterfuck plus I hear there's an added complication of
| friction between the older nix devs and the newer committers
| working on the newer stuff.
|
| I almost wish there was a "declarative Bash" variant on a fork
| of Nix that would allow people to lean on Bash knowledge but
| would only permit declarative style operations, so you could
| get the underlying Nix goodness but would have a more familiar
| (to most) declarative command language on top of it... or even
| better, something like https://wryun.github.io/es-shell/
|
| ... but you'd still lose the nix momentum
| cassepipe wrote:
| How did you learn Guile ?
|
| Here is my experience so far :
|
| https://news.ycombinator.com/item?id=31558878
| akavel wrote:
| Notably, Nix with home-manager. Makes it pretty seamless for me
| to switch between Linux, Mac, and between employers. I love it
| even more since I got my home-manager config to be a Nix Flake
| - this way I have it 100% deterministic and can
| upgrade/downgrade the tool versions when I like without
| worrying too much whether I'll be able to go back if something
| breaks (having flake.lock versioned in git is kinda mandated
| and checked by Flakes).
| shreyshnaccount wrote:
| Does having one gh repo with everything on there count? Asking
| for a friend...
| asiachick wrote:
| So, not having heard of Nix, I go to their home page and watch
| the video. It shows "nix-shell -p nodejs". Hmm, sounds like
| it's using the apt-get version of node which is usually out of
| date. It then shows making a shell.nix that enables nodejs and
| commits it to a repo and suggests sharing it. This completely
| ignores the fact that my various projects requires specific
| versions of node. Maybe the first example shouldn't be one
| that's pretty clearly wrong?
| akho wrote:
| > sounds like it's using the apt-get version of node which is
| usually out of date
|
| It's using the Nixpkgs version, which unfortunately depends
| on which nixpkgs channel you're on. There's a `nodejs_latest`
| attribute, which is actually latest (18.2.0 right now), as
| well as `nodejs-12_x` or somesuch for past major versions
| (where required by other nixpkgs packages). Plain `nodejs`
| should be the LTS version.
|
| > This completely ignores the fact that my various projects
| requires specific versions of node
|
| Nix allows you to pin either nixpkgs or a particular package
| with commit-level granularity. I'm not sure this sort of
| video is the right place to introduce that.
| asiachick wrote:
| would have been all that hard for the video to show
| node-12.x instead of nodejs? I would have clearly shown
| choosing a version instead of wrongly showing bad
| unreproducible practices that makes anyone paying attention
| question if the devs actually get what they're doing
| akavel wrote:
| Notably, with Nix Flakes, everything managed by Nix gets
| automatically 100% precisely pinned to specific versions by
| hash.
| mekeor wrote:
| there's a lispy alternative to nix, called gnu guix, which uses
| guile/scheme instead of nix-lang.
| e3bc54b2 wrote:
| I know, I even mentioned it. Unfortunately and understandably
| Guix means my WiFi won't work and there will be less stuff
| supported OOTB. So I'll be on Nix for foreseeable future.
| sierkov wrote:
| https://gitlab.com/nonguix/nonguix ?
| turboponyy wrote:
| You can include community sources in order to use the
| standard, non-libre Linux kernel - though my Guix
| experience was a bit frustrating in part due to
| complications such as this one compared to what I'm
| currently experiencing with NixOS (thoroughly enjoying
| it!).
|
| There are a fair few very vocal former NixOS users who miss
| no opportunity to extol the benefits of Guix in the
| chatrooms I frequent, though. Not without merit either, I
| should say: the project and its UX does seem to be much
| more well-thought out; it's developed by GNU; the project
| takes software freedom seriously; many will surely enjoy
| hacking away at their config in Scheme. As it stands
| currently, though, there are more resources and it's easier
| to get things done with NixOS - you also get to use learn a
| (imo really great) packaging system that is in somewhat
| wide use.
| cassepipe wrote:
| I tried learning Guile some days ago because Guix seems so
| cool and I like the idea that the configuration is not done
| in a special purpose language.
|
| Had never lisped before.
|
| It seemed cool and I tried my hand with a tutorial that makes
| you embed guile in a C program to make it interactive. It was
| okay but it seemed like too much boilerplate to have to
| register functions individually but maybe it is standard when
| embedding. Never tried with lua or Janet before so I can't
| say.
|
| In general there is a lack of resources, it is quite hard as
| a beginner to get a start with the language past playing with
| the repl a little.
|
| Also tried to see if there was a Guile version of the famous
| SICP but ugh it was not straightforward.
|
| I gave up. Hope Guix will foster better resources on Guile
| Scheme.
| pmarreck wrote:
| wow, I didn't know about a lot of these useful tools, super cool!
| kuon wrote:
| I used to use stow to manage my dotfiles but this was a
| cumbersome step that didn't provide any real advantage.
|
| Now I just edit config files by hand and with zfs autosnapshot I
| can easily rollback if needed.
|
| I'd love to try something like nix, but I rely on many aur
| packages that are bleeding edge for my workflow, I fear it would
| be hard to be up to date with nix, but I have not tried yet.
| ninjin wrote:
| NixOS user here. My experience is that if you track unstable,
| you will have bleeding edge packages within a day or two from
| an upstream release. Likewise, due to how Nix works, you can
| pick and mix from stable, unstable, and your own custom
| expressions to your heart's content. My personal preference is
| stable, with a very small subset of packages from unstable that
| I try to peg back to stable once there is a new stable release.
|
| I will not pretend that there is not a learning curve though,
| Nix is a bit of a beast.
| superpope99 wrote:
| > You don't need to reload your shell when you work on it.
|
| For this point - I use an alias alias
| chalias="vim ~/.bash_aliases && source ~/.bash_aliases"
|
| auto-reloads the aliases when you exit the file
| MenaceInc wrote:
| Aliases all the way down
| sgiratch wrote:
| The site from wayback machine since it died from hug of death
| https://web.archive.org/web/20220529161019/https://evanhahn....
| lobocinza wrote:
| murder is similar to killall
| thejosh wrote:
| I have recently gone through mine when I finally changed to zsh
| after using Bash for the last 16 years (starting on Ubuntu and
| removed so many random commands I used. Now I barely need
| anything, as the tooling is really good and is going through a
| renaissance.
|
| Ripgrep (coming from silversearcher a few years ago) is one of my
| favourite tools I use constantly.
| dividedbyzero wrote:
| I use yadm (https://yadm.io/), very happy with it. It's a thin
| wrapper above a git repo rooted in the user home that is
| configured to ignore untracked files. yadm adds a bunch of
| helpful convenience feature on top (like "alt files" that symlink
| either one or the other file depending system tags or the OS, and
| secrets [which I don't use])
| mikewarot wrote:
| As a long time Windows user... I had no idea, nor knowledge of
| dotfiles. I found this introduction[1] which seems to explain it
| fairly well, as far as I'm concerned.
|
| I find the idea of having a file system full of links in it a bit
| odd.... but I only discovered the nest of them in my Windows 10
| system a month or so ago with the windows DIR /AL command. I'll
| have to get over the cognitive dissonance and adjust to this new
| reality.
|
| 1 - https://www.freecodecamp.org/news/dotfiles-what-is-a-dot-
| fil...
| akavel wrote:
| AFAIK, many Windows apps traditionally tend to use the registry
| for storing their configs. Which I believe is a similarly odd
| and foreign idea to most Linux users. On the other hand, before
| there was the Registry, there were .INI files on Windows too,
| so kinda similar like dotfiles.
| dimgl wrote:
| > I find the idea of having a file system full of links in it a
| bit odd...
|
| Windows has the same concept of a PATH, which is where your OS
| looks for binaries. The difference is that Windows development
| is, most of the time, not CLI driven, especially if you use
| Visual Studio and other GUI tools.
|
| Development in Windows is a completely different beast to
| Linux/Unix.
| tasuki wrote:
| > I find the idea of having a file system full of links in it a
| bit odd...
|
| Why?
| inetknght wrote:
| > _I find the idea of having a file system full of links in it
| a bit odd_
|
| I used to be a Mac user. Everything stored settings in resource
| forks and binary. When I moved to Windows, it was weird to have
| a registry for most things and some things used .ini files that
| were more useful. It was nice to have user-readable settings
| even if they were in obscure places and directories.
|
| When I moved to Linux, dotfiles all made a whole lot more
| sense.
|
| I've helped others learn how to Linux. Windows hides a _lot_ of
| things in order to make the user experience idiot-friendly. I
| 've had to un-teach them the crap that Windows teaches them.
| tomxor wrote:
| > Saying that I've been maintaining my dotfiles for a decade is
| like saying that I've been decorating my home for a decade.
|
| I think it's more like decorating your home for the first time
| (which is a lot of work), but then in the proceeding years you
| keep tweaking a few bits to your liking as you learn more about
| "decoration".
|
| The true benefits of the analogy break down a little, for
| instance one big advantage is persistence, stability and control
| - that some large corporation doesn't keep rudely breaking into
| your home every month and forcefully redecorate everything with
| the latest trend, or keep moving the furniture and light switches
| around while you are asleep, and inserting annoying store fronts
| into critical appliances like the fridge, or your toothpaste...
| The other benefit being that you can fairly effortlessly take
| your decorations with you to your next home!
| unboxingelf wrote:
| I've been decorating my home for a decade.
|
| I've been decorating my $HOME for a decade.
| tomxor wrote:
| I quite like to destroy my $HOME occasionally
|
| So I've been decorating my $XDG_CONFIG_DIRS for a decade.
| [deleted]
| bbkane wrote:
| I used GNU Stow for a several years and always found it difficult
| to tell what symlinks were actually being created, even in
| verbose mode.
|
| When I also ran into the stow bug with --dotfiles , I gave up on
| stow and wrote fling ( https://github.com/bbkane/fling ), which
| works quite similarly, but prints out what symlinks it plans to
| create and asks for confirmation before making them. Being
| written in Go, fling is also easy to install on Windows, which
| has come in real handy on occasion.
| asdfqwertzxcv wrote:
| Looks excellent! This is my major gripe with Stow as well.
| kkfx wrote:
| My personal sauce is Emacs with org-mode configs to be tangled,
| far more efficient than anything else tried before to manage
| dotfiles I care, ignoring those I do not care...
|
| NixOS (since unfortunately Guix System is still a bit raw for me)
| complete tha game allowing to easy tangle the whole system config
| and generate a custom iso with Emacs and all the rest.
|
| Zsh complete the game as shell, eshell honestly it's on my list
| but I still can't use it daily...
| jamesmstone wrote:
| hey thats neat! how do you build the iso?
| kkfx wrote:
| It's very simple, a basic NixOS config like
| https://paste2.org/E5IUKfs9 built with nix-
| build '<nixpkgs/nixos>' -A config.system.build.isoImage \
| -I nixos-config=iso.nix
|
| you can add anything else, for instance X config for
| interactive usage, perhaps with the same (nearly) EXWM used
| normally etc. Nix language is obscene but making iso is
| awesome easy, just a matter of download and build time.
| swyx wrote:
| i couldnt figure out what "sfx good" was in the boop command so
| in case anyone was wondering here is my mac osx equivalent
| 110 boop () { 111 local last="$?" 112 if [[
| "$last" == '0' ]]; then 113 afplay
| /System/Library/Sounds/Glass.aiff 114 else 115
| afplay /System/Library/Sounds/Submarine.aiff 116 fi
| 117 $(exit "$last") 118 }
| teodorlu wrote:
| I love `entr`, but I've recently moved a lot of my `entr` usage
| to `watchexec`. Entr requires a file list on stdin, watchexec
| watches the current folder.
|
| With entr: find . | entr COMMAND
|
| with watchexec: watchexec COMMAND
|
| Watchexec also gracefully handles new files and file deletions.
|
| https://watchexec.github.io/
| teodorlu wrote:
| I think entr handles some things more cleanly, though:
|
| 1. Some bash is allowed, which has been confusing me. I'd
| rather call 'bash -c "echo stuff > file"' myself. 2. Watchexec
| has its own interface for "filter which files to watch". Entr
| just relies on unix tools.
| fallat wrote:
| The point is that entr can then focus only on specific files...
| watchexec now has to add special behaviors for .gitignores and
| whatnot. It's way more flexible and you can alias this so you
| don't have to remember anything or save it to ~/bin/my-watcher-
| thing.sh (both of these things I find people are not using
| enough).
___________________________________________________________________
(page generated 2022-05-30 23:00 UTC)