Our favorite Linux replacements for antiquated open source tools

We asked our community of contributors what open source tools they are using in place of those that feel outdated or antiquated.
4 readers like this.
An arrow clicking a change button


Here at Opensource.com, we thought it would be interesting to survey some of our authors to get a feel for what tools they feel are antiquated (but perhaps still useful!) and what they think of the replacement utilities. What follows is a series of responses and a bit of fun, too.

We sent out the following prompt:

  • Have you discovered some of your favorite tools have become outdated or deprecated? Or maybe you just switched it up for something new?
  • What do you use now? Tell us a little about how you feel it is helpful to have made the switch.


A biggie for me is iptables. I sweated blood learning how to use iptables, and ebtables, and arptables, and how to manipulate MAC addresses, and more. I built dozens of firewalls around scripts to set up rulesets, and I eventually got pretty good at it. Now nftables makes all that obsolete. The fun never stops. I still think somebody with marketing clout could make software-defined boundaries work.

Greg Scott

+1 on iptables

I have been using iptables since I first learned Linux 25+ years ago. The newest tool is firewalld, but that and all other firewall tools I have seen for Red Hat-based distros are still based on and wrap around the kernel-level netfilter modules. I find the firewalld tool creates huge sets of rules that don't do anything more for me than the older iptables. I am sure some large environments need those complex rulesets, but they could also be implemented using iptables or scripts like Greg's.

I do like nmcli, but it is taking me some time to learn it. In fact, I prefer it to the old ifcfg and ip commands. It feels more integrated into the system than the older ones. But I do like the older ifcfg- interface configuration files. Those are easy to create and understand. They don't require the INI-style format that requires section headers. In fact, the old-style files are not even sequence sensitive.

David Both


To further underscore this example, are you sure you weren't using ipchains back then? (The ipfirewall and ipfwadm successor, ipchains wasn't supplanted by iptables until around 2001.)

Jeremy Stanley

^^ In response to Jeremy

My very first firewall was ipchains, circa late 1999. Everything after that was iptables. Back then, I had to build my own kernel to get all the netfilter modules I needed. Modern conveniences like flat-panel monitors and DSL were science fiction in those days. And don't even think about fiber. I had to ride a horse uphill through blizzards every day to visit customers. And then it was uphill back home, too.

Greg Scott

Text editing

I just have to ask—who's still using troff (groff) and who has moved on to... hmm, shall we say, LibreOffice or AsciiDoctor or...?

I have a dear friend who continues with a troff-based product on his Sun SPARCStation V.

Chris Hermansen

[ Related read Old-school technical writing with groff ]

Editing man pages

^^ In response to Chris

Anyone maintaining man pages! Though lots of people are probably generating those from other markup these days. Some folks (like me) do still compose or edit the troff files directly instead.

Jeremy Stanley

Markup stacks

There are always people who use older things, but there are superior tools nowadays. I wouldn't use LibreOffice for the kind of stuff you'd use troff/groff for—if you are writing at that level, you probably depend on a text editor you know well, source-control for managing your inputs, and you are comfortable with markup languages.

That means you want to use a markup stack. There are many, including:

  • Sphinx + ReST + GitHub Actions + GitHub Pages
  • MkDocs + Markdown + GitLab CI + GitLab Pages
  • Nikola + Jupyter Notebooks + Jenkins + (AWS S3 + CloudFront)

What is common to all the stacks is:

  • A thing that pulls different input files into one coherent whole (Sphinx/MkDocs/Nikola)
  • A reasonably high-level text markup language (ReST/Markdown/MD embedded in Jupyter Notebooks)
  • A CI pipeline to transform those into the output format (usually a tree of HTML files, but sometimes a PDF or something)
  • A place where people can download the published version (GitHub Pages, GitLab Pages, AWS S3 + CloudFront)

I'll note that these are pretty much orthogonal choices. Any reasonable generator can take any input (even MkDocs, for which it is least true, has the mkdocs-gen-files plugin so you can use Pandoc to convert stuff to Markdown). Any reasonable CI can run any generator and push to any target.

So even with the list above, there are 81 stacks available.

(Sphinx/MkDocs/Nikola) x (ReST/Markdown/Jupyter Notebooks) x (GHA/GitLab CI/Jenkins) x (GHP/GLP/S3+CF)

Because Pandoc understands troff (ms/man), you can plug troff+ms or troff+man into the "markup" slot if you really want to. You can probably install Jenkins on the Sun SPARCStation V and keep using the same machine and format. But why? :)

There's probably an article for Opensource.com there: "How I converted troff docs to a modern stack using mkdocs+mkdocs-gen-files and GitLab CI."

Moshe Zadka

Other groff examples

Actually, I'm writing an article right now about "Old school technical writing with groff" (part of a larger series I'm writing about tech writing tools). I don't use groff for serious tech writing, but it's in my toolkit of things I learned and will probably never forget. And I review groff when I teach "Writing with Digital Technologies."

While writing the article, I recalled that when I installed Linux in 1993, there weren't any writing apps on Linux. No word processors, just groff and LaTeX. I used LaTeX to write my physics lab reports (because it could do math easily) and groff to write papers for other classes (because I could opt to print to a line printer instead, which I thought was a clever way to make my paper look longer). If I wanted to write with a word processor, I had to dual-boot back to DOS to run WordPerfect or Galaxy Write. StarOffice came out for Linux in 1996. I bought StarOffice.

Interestingly, Brian Kernighan still writes all his books in groff. "Unix: A History and a Memoir" (2020) and "Understanding the Digital World" (2021) were both completely processed in groff.

Jim Hall

Revisiting the fmt command

I use the fmt command a lot these days. It's really handy for a ton of stuff. If you write Readme documentation (or other docs) in plain text, you know the pain when you insert some new text in the middle of a line, and then the lines don't end at the same column. You can run fmt to clean that up.

More commonly, I'm on an email list where list members prefer to receive emails in plain text, so my email client is set for plain text most of the time. If I need to reply to someone's list email (and they didn't send it in plain text), a paragraph is usually just one long line, and my email client doesn't correctly line-wrap when I reply. It's just > at the start of a long sentence.

So I do this:

$ fmt -p '>' > /tmp/f
{copy & paste ">" quoted text}

And then:

$ cat /tmp/f

And then copy and paste the result into my email.

Jim Hall

Changes to bootloaders

Just when your foo is sufficiently sharp, there are reasonable odds the tools will be replaced.

LILO to GRUB was painful until my GRUB-foo reached a sufficient level. GRUB2 is awesome, but a new learning curve.

Muscle memory is also an issue — ipconfig, nslookup, and netstat are on auto-pilot. Plus, if you're using other Linux environments, like Tiny Core Linux, you might not always have the latest and greatest tools.

Switching from if-cfg-style scripts to nmcli is the new learning curve, so this never really ends.

Steven Ellis

[ Related read 6 deprecated Linux commands and the tools you should be using instead ]

Quick FIPS set up

Often things change for the better; my two cents. The question was asked, Have you discovered some of your favorite tools have become outdated or deprecated? Or maybe you just switched it up for something new?

A colleague recently asked me how to enable FIPS on Linux, and it's something I had not done in a while. I remember how arcane this process was, which involved enabling a repo, installing a package (dracut-fips), running commands (dracut) to regenerate initramfs, modifying the GRUB bootloader config file (fips=1), etc.

Also, What do you use now? Tell us a little about how you feel it is helpful to have made the switch.

Luckily on RHEL9, the above has been replaced by the fips-mode-setup command with two handy flags, --check and --setup. That's it! Run those commands, reboot the system, and your machine boots up with FIPS enabled. Super easy!

Gaurav Kamathe

Old and comfortable

Clearly, both the fun of open source and the strong opinions are still present, as is the variety of tools and the freedom to choose what works best for you. Perhaps these tools and others like them are old—even antiquated—but they may still serve a purpose. Some of these older utilities inspired more modern solutions without losing their own inherent value. Finally, there's something to be said for user comfort and familiarity. With open source, all those hours spent developing your foo need not be lost just because some vendor decided it was time for a new release.

User profile image.
Opensource.com publishes stories about creating, adopting, and sharing open source solutions. Follow us on Twitter @opensourceway.


I used t/groff Memorandum Macros (mm) since college and my first years at work. I continue to use it to this day for quick documents. Although I enjoy writing with the MM set, it is hard to ignore the tools available in modern word processors.

Both have its use in my tool box although nowadays most of my writing at work is done in wiki like tools.

The Mac has an awesome text editor (text wrangler) that I'd love to see ported to Linux. Low resources, lots of features. Works great for just text and simple coding projects. The interface is intuitive and has pretty much any feature I'd want for something not better opened in a word processor. I actually found myself using my Mac as my primary text editor because of Text Wrangler and bought the upgraded version. BBEdit is the free version.

Text editing is a bit of a mess on Linux. You have wonderful word processors like Libreoffice, Kword, and others. Problem is they are very resource heavy. Leave one open for a few days and they'll suck gigs of RAM dry. Kate has a nice interface but is full of memory leaks. So bad that it becomes as resource intensive as a word processor in a day or two. The Gnome Kate imitation is useless. Gedit works mostly, though it likes losing changes if you reboot, accidentally close the editor or similar problems.

Kedit I loved beyond words when it was part of the KDE suite. I could have literally hundreds of Kedit windows open at the same time and leave them open for months and not see any memory leaks or issues. If I rebooted every edit was preserved. It had all the basic editing features I needed for most tasks. I used Kedit heavily as a Sysadmin for config files, keeping schemas open for DBs I maintained, quick code edits, and as an author I was able to keep dozens of char sheets open and arranged for easy access. Kedit only exists now under Trinity and is a bit more resource intensive than the old Kedit. Still it's my go to for editing.

I rarely edit in the CLI any more. If it's more than a couple lines and on a local machine I just pull it up in the GUI. I never found anything but hatred for VI. Just way too much memorization. While there are some good CLI editors out there, they do not come default with most distros. So basically I'm left with Pico/Nano or struggling with VI's obtuse keystroke combos. So I just don't mess with any edits in the CLI anymore.

Linux still lags badly in IDEs for languages. A lot of text editors allow for syntax completion but I am spoiled. I spent years using Borlands IDEs, then I spent a grand and worth every penny of it on a high end multi-language coding IDE, can't remember the name, but I loved that IDE. I have never been a M$ fan, but the IDE in visual studio rocked. Too bad the compiler was such garbage. Gambas has a great IDE but it only works for a VB clone. I'd love to see the Gambas IDE for languages like Python, C++ and PHP. Gnome has a couple visual builders that work great for designing screens but lack any teeth when it comes to adding code to them. They also lack the ability to create Desktop independent code or use other desktops libs for the visual parts of the code. It'd be really nice if things like Web, Android, Mac and Windoze compiles.

What I like about a good IDE is it helps but doesn't get in the way. That way I can focus on the code and program flow. Design the GUI using a GUI instead of having to compile and tediously move locations around in code or just trust the OS to put things in a way that the users can use the code. You see so many people today using Wordpress just because it makes designing web interfaces easy. Problem is it carries with it so many severe limitations on what you can do code wise. What's the alternatives? You can buy a propitiatory expensive IDE that only runs on the web itself and leaves your HTML piled knee deep in garbage you have to take out, or something absolutely primitive like Bluefish. That or hack it out in a text editor and spend 90% of your time dinking with CSS and javascript and still not getting it just how you wanted it and having to have 3 different code bases as what shows up on android is totally different from a PC browser and different still on an Iphone.

Efforts to do it all are abysmal failures. Sure you can laboriously hack out stuff on something like Emacs, but I don't have time for the kind of work involved with configuring Emacs to something usable and the very manual nature of coding with something like Emacs. I'm spoiled, I want my editor to have color syntax so I can quickly and easily spot missed brackets, parms, etc, I want to edit, compile and debug in the same interface. In particular to be able to step through the code and look at the contents of variables. Sure you can dump that to a log file or screen display but why? It's code you'll need to pull later and IDEs since the 90s have been capable of this. Makes it so much easier to debug when you don't have to switch between 4 or 5 windows to edit, compile, run and debug your app as you are working on it. Other than Gambas I've not found anything on Linux you can do this with.

Writing software just doesn't exist. So much so that Piers Anthony had custom software written for him on his Linux system so he could write the way he wants too. Some authors cover their walls with character sheets, storyboards, timelines, etc. My I cover a desktop with it using Kedit, but that's really lacking in important features. Kate and Kate clones really don't do what I need. They are more of a primitive coding IDE and resource heavy. When you have literally 200 char sheets you want to switch quickly and easily between without losing your writing momentum they are just not practical. Me I keep a stack of Kedit windows with places, another stack with people, and in seconds I can look up say the history of a person or place as I've built it, or if I'm writing non-fiction I can have my references and snippets open in layers of windows for rapid access. If I have to stop, open a file, scroll to the place in the file I need, I might as well go take a break as I've lost all momentum. I'm so ADD I might have forgotten what I'm looking for by the time I get the file open lol.

Then there's the matter of script editors. I was going to try to port one of the 3 that Hollywood will accept from the Mac to Linux but the Python mess combined with personal emergencies shelved that idea. Linux has no editor that Hollywood, agents, etc will accept the output from. That in spite of there being an open source editor in Python for the Mac that Hollywood does accept. No Linux editor that I'm aware of will output in the formats that Hollywood and similar places accept.

Then you get the odd stuff that things like Word Perfect used to do nicely in the 80s. There was even a Linux version of Word Perfect at one time. No idea why none of that was incorporated into something else. People like law offices, creating custom reports, and a dozen other uncommon but important if you need it features that sort of fell out of use in WPs. Linux could support that since Linux doesn't force a complete rewrite every few years for the latest version of Windoze.

Anyway that's my 2 cents on editors.

An oldie but surprisingly useful: pr. pr will break large texts into pages or columns for printing. My main use case is converting a single column into multiple columns. Adding the -a flag causes the columns to go across, rather than down. If you're not printing the results, use -t to skip the print header and footer.

A common idiom I use is:
Generate a list | sort | tr -a -t -4 > tee file

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.