152
Permanently Deleted (reddthat.com)
submitted 1 year ago* (last edited 10 months ago) by PumpkinDrama@reddthat.com to c/linux@lemmy.ml

Permanently Deleted

top 50 comments
sorted by: hot top controversial new old
[-] just_another_person@lemmy.world 99 points 1 year ago
[-] Spore@lemmy.ml 18 points 1 year ago

Some have better ux, some support more platforms out of the box. I don't find it a good idea trying to replace everything though.

[-] folkrav@lemmy.ca 31 points 1 year ago

I only tend to replace if all of those are met:

  • there are neat additional features or a performance gain that's noticeable in regular use
  • there is some maintenance history
  • It doesn't completely break my workflow.

So far, only things I've actually replaced are aliasing ls to exa/eza, and switched to ripgrep for most of my uses of grep.

[-] Rustmilian@lemmy.world 5 points 1 year ago* (last edited 1 year ago)
[-] folkrav@lemmy.ca 3 points 1 year ago

Looks neat, but again, 99% of those utils I've never ever thought "this shit too slow" or "UX sucks". Replacing for the sake of replacing I'm not too keen on.

load more comments (4 replies)
load more comments (8 replies)
[-] pixelscript@lemmy.ml 56 points 1 year ago

If the current tools work fine, have decades of historic support and battle testing, and the alternatives offer little to no net benefit, uhh, why?

[-] noli@programming.dev 35 points 1 year ago
[-] snowraven@sh.itjust.works 16 points 1 year ago

Aye, I can't argue with that

load more comments (1 replies)
[-] ShustOne@lemmy.one 18 points 1 year ago

Battle hardened > new

Unless the new has a killer feature set worth the trade off in potential bugs

load more comments (2 replies)
load more comments (1 replies)
[-] intrepid@lemmy.ca 53 points 1 year ago* (last edited 1 year ago)

Like many others, I don't replace old tools with new ones, simply because it is written in Rust. For example, fzf is a very novel and useful tool that's written in Go. (FYI: Fzf has a Rust alternative called skim). I'm going to restrict the rest of the post to the context of this thread - Rust CLI/TUI programs that I like. But by no means are they the only new ones I like, or always a replacement for the old ones.

fd and ripgrep (rg) have 2 things in common that give them edge over their older counterparts. First is that both are extremely fast compared to their predecessors. Second is that both support a modern (perl-compatible) version of regex syntax that many programming languages support.

Zellij is a terminal multiplexer like Tmux. However, Zellij IMO has one huge advantage over Tmux and screen - you don't need to take a tutorial or read a user guide just to get started. Everything is discoverable and intuitive. Zellij has the potential to replace TMux as the dominant terminal multiplexer in the near future.

You may find zoxide, atuin and starship as good extensions to your terminal experience, depending on your tastes. Zoxide is a smart directory changer (alt for cd) with good integration all around - with a lot of shells, alternatives (data import), editors (emacs, nvim, etc), file browsers (ranger, nnn, etc) and even mail client (aerc). Atuin replaces the history part of GNU Readline. But lately, it has started gaining features not found in readline, like encrypted history and cross-device history sync. Starship may be a bit fancy for shell prompts - but I find its configuration format to be simpler than the old method. It also supports several shells giving you a uniform experience across shells.

GPG-TUI is a TUI frontend to GnuPG. It's useful simply because the GnuPG UI is terrible. Meanwhile, Sequoia PGP is a tool that aims to replace GnuPG altogether. It has some lofty ambitions and has forced the OpenPGP ecosystem to advance a bit. Some of their innovations aim to solve the drawbacks of old OpenPGP - like lack of PKI (instead of just WoT) and Perfect forward secrecy in certain modes. Its defaults are also more sane and modern compared to GnuPG.

Git-UI (Rust) and LazyGit (Go) are TUI frontends for Git - they have no alternatives. I can recommend either of them if you are a heavy user of git - especially interactive staging and interactive rebasing. Meanwhile, git-interactive-rebase-tool is a tool specifically designed to manage interactive rebases.

If you are into coding, you may find Tokei useful. It is tool for counting Lines of code (LoC) in your projects, segregated by language. Hyperfine, from the developer of fd, is used to benchmark applications over several runs, with a lot of configuration options. Bat is a terminal pager, again from the developer of fd. It supports syntax highlighting. I often find uses for that. I'm not aware of another tool with the exact same functionality.

Finally, nushell is showing a lot of promise as a shell with more modern features. It extends the structured data paradigm from powershell.

[-] intrepid@lemmy.ca 7 points 1 year ago

Forgot to mention stacked-git (stg). This is a tool to deal with patch stacks - much like the age old quilt tool often used by kernel hackers. Unlike quilt, stg uses git to manage a stack of patches. This tool was originally written in Python. It was recently rewritten in Rust by the same team.

Having used stg, it's like having multiple staging indexes in git. This allows you to craft a good commit history like the one you get from using interactive rebasing. Unlike interactive rebasing, you don't have to wait till finishing the feature, in order to achieve that result. If you are a git user and haven't given stg a try yet, I strongly recommend you do. It's a nice tool to have in your development tool chest.

[-] Spore@lemmy.ml 7 points 1 year ago

Note that skim performs worse than fzf. There's a new matcher in Rust called nucleo which is faster, but it currently doesn't have a cli and can only be used inside Helix editor (hx)

nu is probably the best shell for ad-hoc data processing, handling all my daily needs in one expression.

fd and rg have another thing in common, that they're both 50% shorter than their traditional alternatives /s

load more comments (3 replies)
[-] netchami@sh.itjust.works 4 points 1 year ago* (last edited 1 year ago)

Thanks for your comprehensive comment!

load more comments (1 replies)
[-] kevin@mander.xyz 52 points 1 year ago* (last edited 1 year ago)

Yes. The only things I use regularly that aren't aliased to or replaced by a rust-built tool are mkdir, ln, and rsync.

  • cd: zoxide
  • ls: eza
  • cat: bat
  • grep: ripgrep
  • find: fd
  • sed: sd
  • du: dust
  • top/htop: btm
  • vi: helix
  • tmux: zellij (or wezterm mux)
  • diff: delta
  • ps: procs

Probably some others I'm forgetting

[-] sxan@midwest.social 15 points 1 year ago* (last edited 1 year ago)

I have a strong bias for staying with tools that are installed by default. After this many years working with new systems of my own, containers, and systems where I'm not root, the added value of an alternativehas to be quite high for me to switch a core utility.

Thay said, I've found fd, ripgrep, and helix to meet that criteria. The others, not so much; they either don't improve upon or add functionality that's not available, or simply add eye candy. Gaining pretty colors is nice, but not worth losing familiarity with ubiquitous tools.

git-delta is an exception where the syntax highlighting can make a functional difference in code diffs. Not so much that I think about installing it, or using it outside of indirect VCS configuration, but it is a good example of using style for more than just eye candy. I prefer difftastic, but they do much the same.

While it's not a replacement for an existing tool and isn't in your list, nnn is very helpful in many cases, especially bulk renames and reorganizations.

[-] kevin@mander.xyz 4 points 1 year ago

they either don't improve upon or add functionality that's not available, or simply add eye candy. Gaining pretty colors is nice, but not worth losing familiarity with ubiquitous tools.

The thing I like about a lot of these is that I don't lose familiarity with existing tools. When I end up on a cluster that doesn't have them, I'm a bit annoyed, but I can still operate just fine.

The principle exception to this is actually fd - I now find find (har!) almost unusable without having a man page open in a separate terminal. But that's because fd is so much more ergonomic and powerful, I would never give it up unless forced.

load more comments (2 replies)
load more comments (3 replies)
[-] dessalines@lemmy.ml 7 points 1 year ago

Nice, I use almost all these! helix, btm, exa, and delta are wonderful.

[-] SuperIce@lemmy.world 12 points 1 year ago

Maybe sure to replace exa with eza. Exa has been unmaintained for a while and eza is the maintained replacement.

[-] dessalines@lemmy.ml 3 points 1 year ago* (last edited 1 year ago)

Ah hadn't realized. Looks like arch AUR was smart about it and yanked exa, and eza had an automatic alias to it.

[-] flakusha@beehaw.org 3 points 1 year ago

Please give a try for btop - not Rust based, but pretty good and seem to be superior to btm.

load more comments (1 replies)
load more comments (5 replies)
[-] dinckelman@lemmy.world 34 points 1 year ago

I've not replaced anything just because it's Rust, but I have replaced a fair share of tools, just because their newer Rust equivalents are much better

[-] StrangeAstronomer@lemmy.ml 31 points 1 year ago

What for? Even if they have improvements in some areas, the original POSIX standard utilities will continue to be needed for script compatibility. You're not going to swap them out - at best you can add them and then you just have an additional code base to support with additional attack surface to protect.

[-] Decker108@lemmy.ml 21 points 1 year ago

The uutils project is aiming for full compatibility though, so eventually you will be able to just swap them out.

load more comments (1 replies)
[-] snowraven@sh.itjust.works 30 points 1 year ago

I don't know man, those tools - they seem rusty to me.

[-] PseudoSpock@lemmy.dbzer0.com 6 points 1 year ago

The thread needed the joke. Had you not done it, I'd have offered some flavor of it. Bravo!

[-] gerdesj@lemmy.ml 27 points 1 year ago

No. Those tools are tried and well tested. Yes there may still be bugs lurking but simply rewriting in Rust does not guarantee safety. I do hope that this: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html doesn't get used in that repo.

That said, I'll take a look in say five years and see how they are getting on.

[-] Perroboc@lemmy.world 18 points 1 year ago

I’m really looking forward to using something like rust coreutils, but only once the testing passes the gnu test suite (https://github.com/uutils/coreutils-tracking)

[-] db2@sopuli.xyz 10 points 1 year ago

Sounds dumb. Like when Java was supposed to be able to do everything, but this is faster. Doesn't make it not dumb.

[-] 520@kbin.social 38 points 1 year ago

I wouldn't necessarily call it dumb.

Rust is much more of a drop in replacement for C/C++ than Java ever was, and it carries some serious benefits over C/C++ like proper memory management and a modern library and packaging system.

Rebasing to Rust might genuinely be a good idea for some of these tools.

load more comments (1 replies)
[-] MonkderZweite@feddit.ch 9 points 1 year ago* (last edited 1 year ago)

What alternatives? Most of them do different things, often optimized for interactive usecase but lacking in scriptability.

And just because it's in Rust, doesn't mean it's better in code quality or even safer.

I do like fd though.

[-] morrowind@lemmy.ml 8 points 1 year ago

nushell, since it uses more structured data, is basically moving in this direction.

[-] dino@discuss.tchncs.de 6 points 1 year ago

I am using alacritty for years, just recently discovered helix. So I guess I am a natural convert.

[-] GustavoM@lemmy.world 3 points 1 year ago

No, but I'd gladly do so if it shows a considerable performance improvement compared to their "standard" counterparts.

load more comments
view more: next ›
this post was submitted on 30 Oct 2023
152 points (89.2% liked)

Linux

48073 readers
759 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS