Hacker News Reader

Comment by hp50g | Hacker News Reader

I think worse is better here. This just sounds like another layer of abstraction and complexity i want to avoid dealing with as it will consume head space and detract from actually solving the problem i am there to solve.

I tend to make do with defaults as well i.e basic vi and ksh as i move between BSD and Linux regularly (and rarely Solaris 2.5 still!). No surprises and very few dotfiles.

View on HN

I have a similar opinion, although I don't usually stick to defaults.

Apparently this is targeted to teams of developers, so there might be more of a need to "modularize" things.

Having dealt with teams of developers and existing within them, I doubt this would impact them in any positive way. It would in some animal-farm-esque way empower an individual rather than everyone. People have so many differing opinions on such things, standardisation is hard.

The idea with modularizing things is it makes it easy to share the parts that people do want the same. Where I work we have slowly but surely come to an agreement on most of our git aliases. That's why we built [fresh] a similar tool to allow us to share the parts we want to. [fresh] allows us to easily override anything we don't like and keep the parts we do like up to date. My [freshrc] file is an example of mixing other peoples aliases and bin files with a collection of my own config.

[fresh]: https://github.com/freshshell/fresh

[freshrc]: https://github.com/twe4ked/dotfiles/blob/master/freshrc

It is strange to forgo the improvements that customized dotfiles allow just because you don't want a system to manage those dotfiles.

Is another system an improvement?

That is my question.

Putting a few dotfiles in a repo and cloning it for each new machine is a useful way of getting the advantages of dotfiles, which are many. Avoiding all customization just so you don't have dotfiles, just so you don't have to manage dotfiles (which is not hard, there are any number of simple techniques if you don't like this project) is counterproductive

That's fine until you find one damn machine which has a buggy version procmail or a vim version which is too old for your filetype/feature plugins, 5 versions old emacs or an old version of bash etc. It's never "just that easy".

Past startups with heterogeneous kit, keep it simple.

Reply on news.ycombinator.com