2 ms·

Counterpoint, deciding not to put up with old things that are a pain in the ass is part of unseating the existing momentum so we can finally move on to better t

• mongol 4y ago
  What I would like to see in that case is a "next gen utils", a bundling that makes it likely to find a number of these tools together in future servers.
  • jrm4 4y ago
    YES. That isn't a completely new shell. I keep trying the fishes and z-shells of the world and I keep coming back to "my own hacked up bash" because of muscle memory on random edge case things.
  • kristopolous 4y ago
    Really the "right" way to go about it would be to employ an existing package manager (there's enough already, we don't need another) and some magic glue on top that makes it easy. For example, you have your configuration of packages, in the ephemeral cloud somewhere, and you do the really dangerous no good thing of piping through bash with some kind of uuid that's assigned to your account, something like (totally made up url) curl packman.info/users/aed1242faed60a | bash And it sniffs the architecture, version of binaries to install, which ones are there, and then puts it into an install directory configured by you. This is like 97% existing things with a little glue and interface polish so you can easily bring in an environment. There's certainly other ways but the idea remains the same
    • Frotag 4y ago
      Yep, I've started keeping a github repo of install scripts / dotfiles / etc that basically amounts to the workflow you described.