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

41–50 of 219 posts

Re: Modern Linux tools

#41

Post by CaptainOfCoit »

bonoboTP wrote: post #22
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…

Some people spend the vast majority of their time on their own machine. The gains of convenience can be worth it. And they know enough of the classic tools that it's sufficient in the rare cases when working on another server. Not everybody is a sysadmin manually logging into lots of independent, heterogeneous servers throughout the day.

Yeah, this is basically what I do. One example: using neovim with bunch of plugins as a daily driver, but whenever I enter a server that doesn't have it nor my settings/plugins, it isn't a huge problem to run vim or even vi, most stuff works the same.

Same goes for a bunch of other tools that have "modern" alternatives but the "classic" ones are already installed/available on most default distribution setups.

Re: Modern Linux tools

#42

Post by IshKebab »

drob518 wrote: post #36
bieganski wrote: post #3

i wish there was an additional column in the table, that says "what problem does it solve". oh, and 'it's written in rust' does not count.

“It’s written in Rust” Actual LOL. Indeed. I was working for a large corporation at one point and a development team was explaining their product. I asked what its differentiators were versus our competitors. The team replied that ours was written in Go. #faceplam

That is a differentiator if your competitors are written in Python or Ruby or Bash or whatever. But yeah obviously for marketing to normal people you'd have to say "it's fast and reliable and easy to distribute" because they wouldn't know that these are properties of Go.

Re: Modern Linux tools

#43

Post by CaptainOfCoit »

abenga wrote: post #34
arccy wrote: post #5

Earlier quoted context omitted.

like good open source, it's now forked by a community instead of having only a single maintainer eza: https://github.com/eza-community/eza

The README has an ad at the top. Yeeeah, nope.

For a cloud-based terminal emulator that heavily focuses on AI none the less. And they have the stomach to call it "for developers".

Re: Modern Linux tools

#44

Post by drob518 »

lucasoshiro wrote: post #28
anthk wrote: post #15

Modern doesn't always mean better. A better replacement for mplayer was mpv, and in some cases mplayer was faster than mpv (think about legacy machines). - bat it's a useless cat. Cat concatenates files. ANSI colour breaks that. - alias ls='ls -Fh' , problem solved. Now you have * for executables, / for directories and so on. - ncdu it's fine, perfect for what it does - iomenu it's much faster than fzf and it almost…

> bat it's a useless cat I can't see bat as a "useless cat" or a replacement for cat except for reading source code in the terminal. It's more a like a less with syntax highlight or a read-only vim.

Part of the problem is “naming/marketing.” Bat compares ITSELF to cat, not to more/less. IMO, this confuses the issue.

Re: Modern Linux tools

#45

Post by demetris »

Many are available on Windows too.

I know I have hyperfine, fd, and eza on my Windows 11, and maybe some more I cannot remember right now.

They are super easy to install too, using winget.

Re: Modern Linux tools

#46

Post by account42 »

IshKebab wrote: post #42
drob518 wrote: post #36

Earlier quoted context omitted.

“It’s written in Rust” Actual LOL. Indeed. I was working for a large corporation at one point and a development team was explaining their product. I asked what its differentiators were versus our competitors. The team replied that ours was written in Go. #faceplam

That is a differentiator if your competitors are written in Python or Ruby or Bash or whatever. But yeah obviously for marketing to normal people you'd have to say "it's fast and reliable and easy to distribute" because they wouldn't know that these are properties of Go.

You can write slow unmaintainable brittle garbage in any language though. So even if your competition is literally written in Bash or whatever you should still say what your implementation actually does better - and if it's performance, back it up with something that lets me know you have actually measured the impact on real world use cases and are not just assuming "we wrote it in $language therefore it must be fast".

Re: Modern Linux tools

#47

Post by account42 »

oneeyedpigeon wrote: post #24
bieganski wrote: post #3

i wish there was an additional column in the table, that says "what problem does it solve". oh, and 'it's written in rust' does not count.

Many of the entries do include this detail — e.g. "with syntax highlighting", "ncurses interface", and "more intuitive". I agree that "written in rust", "modern", and "better" aren't very useful!

Some of this just makes me think that they are compared against the wrong tool though. E.g.

> cat clone with syntax highlighting and git integration

doesn't make any sense because cat is not really meant for viewing files. You should be comparing your tool with the more/less/most family of tools, some of which can already do syntax highlighting or even more complex transforms.

Re: Modern Linux tools

#48

Post by trebligdivad »

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…

Agreed, but some are nice enough that I'll make sure I get them installed where I can. 'ag' is my go to fast grep, and I get it installed on anything I use a lot.

Re: Modern Linux tools

#49

Post by mprovost »

imcritic wrote: post #39
andai wrote: post #10

Earlier quoted context omitted.

I wanted to say we should just stick with what Unix shipped forever. But doesn't GNU already violate that idea?

IMO this is very stupid: don't let past dictate future. UNIX is history. History is for historians, it should not be the basis that shapes the environment for engineers living in present.

The point is that we always exist at a point on a continuum, not at some fixed time when the current standard is set in stone. I remember setting up Solaris machines in the early 2000s with the painful SysV tools that they came with and the first thing you would do is download a package of GNU coreutils. Now those utils are "standard", unless of course you're using a Mac. And newer tools are appearing (again, finally) and the folk saying to just stick with the GNU tools because they're everywhere ignore all of the effort that went into making that (mostly) the case. So yes, let's not let the history of the GNU tools dictate how we live in the present.

Re: Modern Linux tools

#50

Post by drob518 »

IshKebab wrote: post #42
drob518 wrote: post #36

Earlier quoted context omitted.

“It’s written in Rust” Actual LOL. Indeed. I was working for a large corporation at one point and a development team was explaining their product. I asked what its differentiators were versus our competitors. The team replied that ours was written in Go. #faceplam

That is a differentiator if your competitors are written in Python or Ruby or Bash or whatever. But yeah obviously for marketing to normal people you'd have to say "it's fast and reliable and easy to distribute" because they wouldn't know that these are properties of Go.

No. The differentiator is whatever benefits such an implementation might deliver (e.g., performance, reliability, etc.). Customers don’t start whipping out checkbooks when you say, “Ours is written in Go.”
Post reply on HN