5 ms·

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 d

by hp50g 14y ago

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.

bgar 14y ago
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 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.
- hp50g 14y ago
  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.
  - twe4ked 14y ago
    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 https://github.com/freshshell/fresh [freshrc]: https://github.com/twe4ked/dotfiles/blob/master/freshrc https://github.com/twe4ked/dotfiles/blob/master/freshrc
pekk 14y ago
It is strange to forgo the improvements that customized dotfiles allow just because you don't want a system to manage those dotfiles.
- hp50g 14y ago
  Is another system an improvement? That is my question.
  - pekk 14y ago
    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
    - hp50g 14y ago
      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.

by hp50g 14y ago

bgar 14y ago

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

hp50g 14y ago
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.
- twe4ked 14y ago
  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 https://github.com/freshshell/fresh [freshrc]: https://github.com/twe4ked/dotfiles/blob/master/freshrc https://github.com/twe4ked/dotfiles/blob/master/freshrc

pekk 14y ago

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

hp50g 14y ago
Is another system an improvement? That is my question.
- pekk 14y ago
  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
  - hp50g 14y ago
    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.