Neofetch is over, but many screenshot system info tools stand ready
Dev behind a popular screenshot tool checks out, but the successors are good.
Almost nobody truly needed Neofetch, but the people who did use it? They really liked it.
Neofetch, run from a terminal, displayed key system information alongside an ASCII-art image of the operating system or distribution running on that system. You knew most of this data, but if you’re taking a screenshot of your system, it looked cool and conveyed a lot of data in a small space. “The overall purpose of Neofetch is to be used in screen-shots of your system,” wrote Neofetch’s creator, Dylan Araps, on its Github repository. “Neofetch shows the information other people want to see.”
Neofetch did that, providing cool screenshots and proof-of-life images across nearly 150 OS versions until late April. The last update to the tool was made three years before that, and Araps’ Github profile now contains a rather succinct coda: “Have taken up farming.” Araps joins “going to a commune in Vermont” and “I now make furniture out of wood” in the pantheon of programmers who do not just leave the field, but flee into another realm entirely.
As sometimes happens, the void was filled not by one decent replacement but many.
The neo-Neofetches
Fastfetch seems to have captured the default forum/thread/blog recommendation as a Neofetch replacement. It is under active development, with changes occurring just hours before this post was published. It’s highly customizable, available across most major platforms and distributions, and extensible through modules. It supports Wayland, provides more detailed memory and storage statistics, and, as the name suggests, is generally faster. It’s FOSS and has a tutorial on customizing and extending Fastfetch.
NerdFetch gives you the kind of icon customization you might expect if you’re the type who takes meticulously arranged screenshots of your desktop. By installing one of the glyph-packed Nerd Fonts, you can replace text inside your readout with icons readable at a glance. It’s available on POSIX-compliant systems (“Anything but Windows”). It lacks a lot of customization and module options, and it’s missing the big, custom OS logo (it seemingly shows a very abstract ASCII Tux in both MacOS and Asahi Linux). But it’s also compact and a bit different.
What else? There’s hyfetch, which is “neofetch with pride flags,” but it also contains inside it “neowofetch,” which is an updated neofetch sans pride coloring. The macchina system info tool is written in Rust and offers themeing, being “basic by default and extensible by design.” And cpufetch is, as you might imagine, a lot more CPU data, along with a logo. Curiously, cpufetch showed an “arm” rendering when I ran it under Asahi Linux on a MacBook, but then an Apple logo while inside MacOS. Works either way! Just interesting.
If you’ve put time into getting a Linux desktop just how you like it—or just getting Linux onto a device that really doesn’t want it—it follows that you’d want to show it off. These are not the last of the apps that will try to make fetch happen, but they’re a strong start.
You can compile on a big pi and copy the binary to your zeros. No need to compile on a zero lol
Ya know that never occurred to me that would work, going to have to try it
The Raspberry Pi Zero has a 32-bit CPU, the newer big RPI’s have 64-bit CPU’s. Wouldn’t that cause problems?
The term you want is “cross compile”. I’ve developed simple programs for the Pi on Windows and it’s simple enough to produce a static binary (using Rust, anyway). When extra dependencies come in it’s better to develop on the same OS, but targeting different architectures is the easy bit.
It’s also a lot easier to do so with Rust because you can easily statically compile it with the musl target so you don’t even rely on the system’s libc version.
Do you think a compiler always has to compile to the exact CPU it’s running on? You could target PowerPC on an x86 CPU if you just set the appropriate target flags (and had a compiler that supports it)
Speaking of which, you can compile binaries for 32-bit ARM on x86 as well; just run it on your desktop and then copy over the binary.
Of course not, but then there’s not really a point to using another Pi instead of your main machine, right?
Yeah, I’d just do it on whatever machine I’m developing on. You’ve got to transfer stuff from it anyway, so just include the compiled binary.
I was going to say this too, but I’ve never cross compiled a cmake project so I wasn’t sure how much overhead there would be