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.
Firewalls
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.
+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.
ipchains?
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.)
^^ 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.
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.
[ 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.
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."
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.
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}
^DAnd then:
$ cat /tmp/fAnd then copy and paste the result into my email.
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.
[ 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!
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.
3 Comments