Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern Linux tools

ikrima.dev

Post reply on HN
Print view View original

101–110 of 219 posts

Re: Modern Linux tools

#101

Post by dankobgd »

0x37 wrote: post #9

These may be objectively superior (I haven't tested), but I have come to realize (like so many others) that if you ever change your OS installation, set up VMs, or SSH anywhere, preferring these is just an uphill battle that never ends. I don't want to have to set these up in every new environment I operate in, or even use a mix of these on my personal computer and the traditional ones elsewhere. Learn the classic to…

i learned ansible and i run 1 command and wait 10 minutes and configure new linux machine with all the stuff i want

Re: Modern Linux tools

#102

Post by carlosjobim »

sigio wrote: post #68

As someone who logs into hundreds of servers in various networks, from various customers/clients, there is so little value in using custom tooling, as they will not be available on 90% of the systems. I have a very limited set of additional tools I tend to install on systems, and they are in my default ansible-config, so will end up on systems quickly, but I try to keep this list short and sweet. 95% of the systems I…

You're again confusing this website with your personal email inbox. This is a public message board, all messages you see haven't been written for you specifically - including this blog post.

Re: Modern Linux tools

#103

Post by actinium226 »

lucasoshiro wrote: post #23
0x37 wrote: post #9

These may be objectively superior (I haven't tested), but I have come to realize (like so many others) that if you ever change your OS installation, set up VMs, or SSH anywhere, preferring these is just an uphill battle that never ends. I don't want to have to set these up in every new environment I operate in, or even use a mix of these on my personal computer and the traditional ones elsewhere. Learn the classic to…

> that if you ever change your OS installation apt-get/pacman/dnf/brew install You'll need install those and other tools (your favorite browser, you favorite text editor, etc) anyway if you're changing your OS. > or SSH anywhere When you connect through SSH you don't have GUI and that's not a reason for avoiding using GUI tools, for example. > even use a mix of these on my personal computer and the traditional ones e…

> apt-get/pacman/dnf/brew install

If only it were so simple. Not every tool comes from a package with the same name, (delta is git-delta, "z" is zoxide, which I'm not sure I'd remember off the top of my head when installing on a new system). On top of that, you might not like the defaults of every tool, so you'll have config files that you need to copy over or recreate (and hopefully sync between the computers where you use these tools).

That said I do think nix provides some good solutions for this. It gives you a nice clean way to list the packages you want in a nixfile and also to set their defaults and/or provide some configuration files. It does still require some maintenance (and I choose to install the config files as editable, which is not very nix-y, but I'd rather edit it and then commit the changes to my configs repo for future deploys than to have to edit and redeploy for every minor or exploratory change), but I've found it's much better than trying maintain some sort of `apt-get install [packages]` script.

Re: Modern Linux tools

#104

Post by samtrack2019 »

kokada wrote: post #35
0x37 wrote: post #9

These may be objectively superior (I haven't tested), but I have come to realize (like so many others) that if you ever change your OS installation, set up VMs, or SSH anywhere, preferring these is just an uphill battle that never ends. I don't want to have to set these up in every new environment I operate in, or even use a mix of these on my personal computer and the traditional ones elsewhere. Learn the classic to…

One of the reasons I really like Nix, my setup works basically everywhere (as long the host OS is either Linux or macOS, but those are the only 2 environments that I care). I don't even need root access to install Nix since there are multiple ways to install Nix rootless. But yes, in the eventual case that I don't have Nix I can very much use the classic tools. It is not a binary choice, you can have both.

are you going to install nix in a random docker container?

Re: Modern Linux tools

#106

Post by samtrack2019 »

actinium226 wrote: post #103
lucasoshiro wrote: post #23

Earlier quoted context omitted.

> that if you ever change your OS installation apt-get/pacman/dnf/brew install You'll need install those and other tools (your favorite browser, you favorite text editor, etc) anyway if you're changing your OS. > or SSH anywhere When you connect through SSH you don't have GUI and that's not a reason for avoiding using GUI tools, for example. > even use a mix of these on my personal computer and the traditional ones e…

> apt-get/pacman/dnf/brew install If only it were so simple. Not every tool comes from a package with the same name, (delta is git-delta, "z" is zoxide, which I'm not sure I'd remember off the top of my head when installing on a new system). On top of that, you might not like the defaults of every tool, so you'll have config files that you need to copy over or recreate (and hopefully sync between the computers where…

it take less than a sec or less than 10s with a google search to adapt...

Re: Modern Linux tools

#107

Post by saghm »

lucasoshiro wrote: post #23
0x37 wrote: post #9

These may be objectively superior (I haven't tested), but I have come to realize (like so many others) that if you ever change your OS installation, set up VMs, or SSH anywhere, preferring these is just an uphill battle that never ends. I don't want to have to set these up in every new environment I operate in, or even use a mix of these on my personal computer and the traditional ones elsewhere. Learn the classic to…

> that if you ever change your OS installation apt-get/pacman/dnf/brew install You'll need install those and other tools (your favorite browser, you favorite text editor, etc) anyway if you're changing your OS. > or SSH anywhere When you connect through SSH you don't have GUI and that's not a reason for avoiding using GUI tools, for example. > even use a mix of these on my personal computer and the traditional ones e…

Stronhly agreed. I don't understand why I'd want to make >99% of my time doing things less convenient in offer to try to make my usage in the <1% of the time I'm on a machine where I can't install things even in a local directory for the user I'm ssh'd into feel less bad by comparison. It's not even a tradeoff where I'm choosing which part of the curve to optimize for; it's literally flattening the high part to make the lower overall convenience level constant.

Re: Modern Linux tools

#108

Post by lucasoshiro »

Hackbraten wrote: post #81
lucasoshiro wrote: post #23

Earlier quoted context omitted.

> that if you ever change your OS installation apt-get/pacman/dnf/brew install You'll need install those and other tools (your favorite browser, you favorite text editor, etc) anyway if you're changing your OS. > or SSH anywhere When you connect through SSH you don't have GUI and that's not a reason for avoiding using GUI tools, for example. > even use a mix of these on my personal computer and the traditional ones e…

> When you connect through SSH you don't have GUI and that's not a reason for avoiding using GUI tools, for example. One major difference can emerge from the fact that using a tool regularly inevitably builds muscle memory. You’re accustomed to a replacement command-line tool? Then your muscle memory will punish you hard when you’re logged into an SSH session on another machine because you’re going to try running you…

> You’re accustomed to a replacement command-line tool?

Yes.

> Then your muscle memory will punish you hard

No.

I'm also used to pt-br keyboards, it's easier to type in my native language, but it's ok if I need to use US keyboards. In terms of muscle memory, keyboards are far harder to adapt.

A non-tech example: if I go to a Japanese restaurant, I'll use chopsticks and I'm ok with them. At home, I use forks and knives because they make my life easier. I won't force myself to use chopsticks everyday only for being prepared for Japanese restaurants.

Re: Modern Linux tools

#109

Post by 149765 »

maeln wrote: post #62
Izkata wrote: post #60

Earlier quoted context omitted.

> But the killer feature for me is the `-x` argument. It allows calling another command on the individual search result, which `find` can also do with `xargs` and co. But `fd` provide a very nice placeholder syntax[0], which remove the need to mess with `basename` and co. to parse the filename and make a new one, and it executes in parallel. For example, it makes converting a batch of image a fast and readable one li…

`find` only support `{}`, it does not support `{/}`, `{//}`, `{.}` etc, which is why you often need to do some parsing magic to replicate basic thing such has "the full path without the extension`, `only the filename without the extension` etc

I think GNU parallel has similar placeholders, but I do prefer to just use `fd`.

Re: Modern Linux tools

#110

Post by MontyCarloHall »

robenkleene wrote: post #80
MontyCarloHall wrote: post #74

Earlier quoted context omitted.

Depends on how big the directory is. If it only contains a few files, I'd just enumerate them all with `find`, filter the results with `grep`, and perform the actual `grep` for "bar" using `xargs`: find . -type f -name "*.foo" | grep -v '/\.' | xargs grep bar (This one I could do from muscle memory.) If traversing those hidden files/directories were expensive, I'd tell `find` itself to exclude them. This also lets me…

Thanks yeah this is a good example of why I prefer the simpler interface for `rg` and `fd`. Those examples would actually be fine if this were something only did once in awhile (or in a script). But I search from the command line many times per day when I'm working, so I prefer a more streamlined interface. For the record, I think `git grep` is probably the best builtin solution to the problem I gave, but personally…

>Those examples would actually be fine if this were something only did once in awhile (or in a script). But I search from the command line many times per day when I'm working, so I prefer a more streamlined interface.

Makes sense. If I had to do this frequently, I'd add a function/alias encapsulating that `find` incantation to my .bashrc, which I keep in version control along with other configuration files in my home directory. That way, when moving to a new environment, I can just clone that repo into a fresh home directory and most of my customizations work out-of-the-box.

Post reply on HN