Live data from Hacker News

A cross-platform multi-target dotfiles manager written in Rust

github.com

71–80 of 87 posts

Re: A cross-platform multi-target dotfiles manager written in Rust

#71
post #33

Earlier quoted context omitted.

After years navigating this issue, I think the common understanding of "static" binary is just "something that won't give me a dll / dylib error on startup when I copy it to my friend's computer"

Which is a possibility, given that ldd/Dependency Walker result won't be an empty list. Even shipping the whole computer on a container, might not do it, because most containers are leaky abstractions the way their Dockerfiles are written.

Yet in practice this works fine for all intents and purposes.

Sure, you might get a loading error if you try to run your Ubuntu 24.04-compiled executable on Ubuntu 18.04 if you use the default toolchain. tTat’s exactly the same as C or C++, only much easier to fix in rust by rustup-installing the right tool chain.

Compiling on Ubuntu 18.04 and running on 24.04 is absolutely not an issue. Same for windows.

In practice this is really not a problem, especially for cargo libraries that you anyway build from source.

Re: A cross-platform multi-target dotfiles manager written in Rust

#72

I just use a “dotfiles” folder that is a git repo and then hard-link the files in there into the home directory. One for unprivileged user and one for root on each platform. Simple enough and doesn't require an extra tool.

How do you handle differences between machines? I use cheznoi to manage my dotfiles and share them between 6 different devices, 2 of them are work machines. On my work machine I have maybe a 15% difference in config, primarily my hotkeys through keymapper, my SSH config files, and also the applications I have installed. Chezmoi let's me add logic to my source controlled config files that, based on the hostname/domain/network, etc let's me ouput different settings to the .config files, which I cannot do in the config files themselves.

For example: On my home machine I have the following keymapper hotkey: Windows + T: Activate Telegram On my work machine that's mapped to: Windows + T: Activate Teams

Re: A cross-platform multi-target dotfiles manager written in Rust

#73

Earlier quoted context omitted.

At least on Linux they do yes. But this is cross platform. A Normal total number of dotfiles on a windows system is about 0 or 1.

This is not true. Open your user folder and there will be tons of dotfiles. If you use git with ssh or Rust (.cargo) or C# (.nuget) and many other tools. In fact, even .config is started to show up now. I guess devs are tired of %APPDATA% ?

Yes, I have 2 (nuget and git). But I obviously have many more text based configuration files than those. They just happen to have a name with a dot.

Re: A cross-platform multi-target dotfiles manager written in Rust

#74

Completely unrelated, but I recently switched to using nix with home manager and nix-darwin to handle my entire dev setup and dotfiles. If you work a lot in remote dev environments (I use coder a lot at work) that really does the trick.

Likewise. I have two Mac laptops, three home servers, and a Windows desktop managed by Nix.

The home servers are nixOS, the rest basically have the CLI environment managed with nix-darwin and nixos-wsl, all with one flake (Git repo) containing all the configuration.

Case in point - this morning I’m rebuilding one of the servers onto new hardware, and the longest time spent was getting the flake config onto the server with git clone. Now just watching the rebuild switch command output, after which it’s good to go.

Re: A cross-platform multi-target dotfiles manager written in Rust

#75
post #71
post #33

Earlier quoted context omitted.

Which is a possibility, given that ldd/Dependency Walker result won't be an empty list. Even shipping the whole computer on a container, might not do it, because most containers are leaky abstractions the way their Dockerfiles are written.

Yet in practice this works fine for all intents and purposes. Sure, you might get a loading error if you try to run your Ubuntu 24.04-compiled executable on Ubuntu 18.04 if you use the default toolchain. tTat’s exactly the same as C or C++, only much easier to fix in rust by rustup-installing the right tool chain. Compiling on Ubuntu 18.04 and running on 24.04 is absolutely not an issue. Same for windows. In practice…

I would say the same regarding dynamic linking, which is why most OSes have moved away from being static linking only executables, except embedded in the cases where it is a single blob uploaded into the device.

Not even modern 3D graphics APIs, none of them, work with static linking, yet another area static linking advocates have to accept the industry has moved on.

Re: A cross-platform multi-target dotfiles manager written in Rust

#76
post #4

why something so specialized needs a configuration file? my dot file scripts just have very opinionated dir/file naming conventions and things just fall into place. it's not like you need to give tune much... even adding the template thing which i think is overkill (time would be best spent with a way to validate code cross platform of you ask me.. templating makes this more difficult while pretending to remove the n…

So you can manage your dotfile manager with a dotfile manager! Nothing against the project, this part just seems pretty amusing

almost spilled my drink. thanks for nailing the joke i missed

Re: A cross-platform multi-target dotfiles manager written in Rust

#77
post #69
post #60

Dumb yet serious question : what problem is a dotfile manager even trying to solve? Personally I have a git repo in my home directory and just commit dotfiles to it. The only drawback is that git always think there’s a git repo no matter where I am in my home, so I usually rename the .git folder to .git_hidden. And on the (rare) occasion that I want to update one of my dotfiles I just rename the .git_hidden directory…

FWIW, you don't have to do that rename dance; git allows specifying the name of the .git metadata directory via `git --git-dir=$HOME/.git_hidden ...` or `GIT_DIR=$HOME/.git_hidden git ...` I don't know how big your .gitignore must be when trying to use a tool that wants to own every file and directory to manage your /home but if that works for you, more power to ya

Start with ls -a -w1 > .gitignore, then edit it and delete everything you want to track.

Re: A cross-platform multi-target dotfiles manager written in Rust

#78
post #69
post #60

Dumb yet serious question : what problem is a dotfile manager even trying to solve? Personally I have a git repo in my home directory and just commit dotfiles to it. The only drawback is that git always think there’s a git repo no matter where I am in my home, so I usually rename the .git folder to .git_hidden. And on the (rare) occasion that I want to update one of my dotfiles I just rename the .git_hidden directory…

FWIW, you don't have to do that rename dance; git allows specifying the name of the .git metadata directory via `git --git-dir=$HOME/.git_hidden ...` or `GIT_DIR=$HOME/.git_hidden git ...` I don't know how big your .gitignore must be when trying to use a tool that wants to own every file and directory to manage your /home but if that works for you, more power to ya

Oh, interesting, thanks!

And I don’t even bother with ignoring files! I just git add the ones I want to track :)

Re: A cross-platform multi-target dotfiles manager written in Rust

#79
post #68

Earlier quoted context omitted.

> Rust executables are only 100% static on OSes that expose system libraries as static libraries This seems to be a weird hair to split. GP clearly means “a single executable you can run on any install of the target OS without dependencies.” Whether it’s a truly honest-to-goodness static binary that don’t link to libc or libSystem or whatever is important to approximately zero people, outside of internet pedants.

It is, because so many folks make such a big deal of how using computers as they used to be until early 1980's, with single static linking model. Ironically the same folks don't see to appreciate how object files and binary libraries work in static linking, lets make it even better compiling always from source.

Nobody’s making a big deal about in it in this thread but you.

Re: A cross-platform multi-target dotfiles manager written in Rust

#80
So, I'm usually the huge Rust promoter, but we already have a lot of dotfiles managers, and Chezmoi, although written in Go, is right there.

What can this one do that the other ones don't?

The README lists features that, well, I'd already expect modern dotfile managers to be able to do.

Post reply on HN