- wlug - list.wlug.org.nz

“7 deprecated Linux commands you need to stop using - and what to use instead”
by Lawrence D'Oliveiro 15 Jan '26

15 Jan '26

Jack Wallen’s list <https://www.zdnet.com/article/linux-commands-deprecated-why-do-not-use/> of commands you shouldn’t be using any more, and what to use instead, is a mixed bag. ifconfig/iwconfig vs ip/iw -- the latter newer ones (part of the Linux “iproute2” suite) offer greater access to all the features of the Linux network stack than the former, older ones, and so are preferable in lots of ways. It is already possible to find setups which don’t have the old commands installed by default; I’m not sure if any distros have actually dropped the option for installing them altogether, but no doubt that will happen at some point. scp -- wrong. rsync, scp and sftp are all different ways of transferring files securely over SSH. scp did use to use its own protocol at one point, but it has been upgraded to use the same underlying protocol as sftp, so it’s perfectly fine to continue using the same command, if that’s what you’re used to. There is no sign that the scp command itself is going to be deprecated at any point, though no doubt the option to fall back to the old protocol for compatibility’s sake is likely to be removed eventually. egrep/fgrep -- it has been true for decades (possibly has always been true for the GNU utilities?) that egrep and fgrep are just synonyms for “grep -E” and “grep -F” respectively. And it is true that the alternative names are finally being deprecated after all these years, so it behooves you to learn to use the “grep” command for all forms. netstat vs ss -- yes, another case of the newer iproute2-based command taking over from the older, traditional command, and offering more features besides. Same remarks as above apply. route vs ip route -- iproute2 again. arp vs ip neighbour/neighbor -- more iproute2.

1 0

RISC-V PC Motherboard
by Lawrence D'Oliveiro 14 Jan '26

14 Jan '26

Here’s a mini-ITX motherboard with most of the usual trimmings (no integrated graphics or audio, though), but with a RISC-V CPU. So you’ll be using that single PCIe-x16 slot for a graphics card. Known to run Ubuntu. It’s available for pre-order <https://www.tomshardware.com/pc-components/cpus/milk-v-titan-mini-ix-board-…>. At this stage, it seems more targeted towards developers and early adopters, not (yet) the mass market.

2 1

How Long Does It Take to Fix Linux Kernel Bugs?
by Peter Reutemann 13 Jan '26

13 Jan '26

'A report from It's FOSS: Jenny Guanni Qu, a researcher at [VC fund] Pebblebed, analyzed 125,183 bugs from 20 years of Linux kernel development history (on Git). The findings show that the average bug takes 2.1 years to find. [Though the median is 0.7 years, with the average possibly skewed by "outliers" discovered after years of hiding.] The longest-lived bug, a buffer overflow in networking code, went unnoticed for 20.7 years! [But 86.5% of bugs are found within five years.] The research was carried out by relying on the Fixes: tag that is used in kernel development. Basically, when a commit fixes a bug, it includes a tag pointing to the commit that introduced the bug. Jenny wrote a tool that extracted these tags from the kernel's git history going back to 2005. The tool finds all fixing commits, extracts the referenced commit hash, pulls dates from both commits, and calculates the time frame. As for the dataset, it includes over 125k records from Linux 6.19-rc3, covering bugs from April 2005 to January 2026. Out of these, 119,449 were unique fixing commits from 9,159 different authors, and only 158 bugs had CVE IDs assigned. It took six hours to assemble the dataset, according to the blog post, which concludes that the percentage of bugs found within one year has improved dramatically, from 0% in 2010 to 69% by 2022. The blog post says this can likely be attributed to: - The Syzkaller fuzzer (released in 2015) - Dynamic memory error detectors like KASAN, KMSAN, KCSAN sanitizers - Better static analysis - More contributors reviewing code But "We're simultaneously catching new bugs faster AND slowly working through ~5,400 ancient bugs that have been hiding for over 5 years." They've also developed an AI model called VulnBERT that predicts whether a commit introduces a vulnerability, claiming that of all actual bug-introducing commits, it catches 92.2%. "The goal isn't to replace human reviewers but to point them at the 10% of commits most likely to be problematic, so they can focus attention where it matters..."' -- source: https://it.slashdot.org/story/26/01/12/0443201 Cheers, Peter

1 0

DMCA Takedown On Free Software
by Lawrence D'Oliveiro 07 Jan '26

07 Jan '26

Just read this report <https://www.tomshardware.com/software/chinese-semiconductor-outfit-has-linu…> about a DMCA takedown on a GitHub repository belonging to Rockchip. The copyright takedown was requested by the FFmpeg project. Their code is open source, of course. As is the code in the Rockchip repository. But the company took their code, removed the original attribution and licensing (LGPL), and put the result under an Apache licence, which is not compatible with the LGPL. Given that LGPL is a copyleft licence, and Apache is not, this could lead others to believe they could in turn take the Rockchip version of the code and develop it further and incorporate it into proprietary products without making any source available -- which is something copyleft is designed to prevent. Of course this action did not come out of the blue. The FFmpeg project had raised the issue with Rockchip back in 2024, but in the absence of any progress since that time, they felt that action had to be taken.

1 0

RIP Stewart Cheifet
by Lawrence D'Oliveiro 06 Jan '26

06 Jan '26

Those who spent their formative years back in the 20th century may or may not remember Stewart Cheifet, long-time presenter and executive producer of a US TV program called “The Computer Chronicles”, which was mainly produced through the 1980s and 1990s. I don’t recall that ever being shown here in NZ, but I later came to discover him through compilations of the shows on YouTube. And it turns it he has been instrumental in ensuring that records of all 400-odd episodes, as far as possible, have been preserved at the Internet Archive, as a valuable snapshot of the computing scene back in that era. Also of note, his co-presenter for the first several years was Gary Kildall, of CP/M fame, until the death of the latter. Now we hear Cheifet himself has passed away at the age of 87 <https://arstechnica.com/gadgets/2026/01/stewart-cheifet-pbs-host-who-chroni…>. (Oh, and if you’re wondering, he always pronounced it like “shuffay”).

1 0

pv - monitor the progress of data through a pipe
by Peter Reutemann 06 Jan '26

06 Jan '26

Hi everyone It's not Easter, but I love finding nifty little tools... :-) While looking up stackexchange for importing gzip-compressed MySQL dumps, I came across "pv", a tool for monitoring progress through pipes. Allows you to monitor how long, e.g., the import of a database dump will take. Example import command: pv mydump.sql.gz | gunzip | mysql -u root -p <database name> You will then see something like this: 1.73GiB 0:05:26 [6.54MiB/s] [=> ] 5% ETA 1:31:51 Here is the man page for pv: https://www.man7.org/linux/man-pages/man1/pv.1.html -- source: https://serverfault.com/a/445130 Cheers, Peter

1 0

2025 might have been the year for Linux gaming, but there's still a way to go until I switch from Windows
by Lawrence D'Oliveiro 30 Dec '25

30 Dec '25

Here is an article full of praise for the success Linux has been enjoying in handheld PC gaming, being able to run most Windows games better than Windows itself can manage <https://www.pcgamer.com/software/linux/2025-might-have-been-the-year-for-li…>. The writer mentions the one big obstacle to Linux enjoying greater success in this area: kernel-level anti-cheat mechanisms. The vast majority of these are Windows-specific, and many vendors are not only reluctant to support Linux as an alternative platform, they are downright hostile to it. Ultimately, though, I am going to put my bet on free-market Capitalism winning out. The customer is king. It is the game vendors who have to entice the buyers to part with their money in return for something worthwhile, the customers have no obligation to simply hand it over. If the only ace the Windows products have up their sleeve is obnoxious anti-cheat mechanisms, that may not be enough to keep customers flocking to them in droves. In other words, if the Linux-based handhelds continue to offer a superior user experience to the Windows-based ones, then those last remaining holdout vendors will be forced, purely by market forces, to go where the money is: they will ultimately be dragged, kicking and screaming, into supporting Linux gaming in some form.

1 0

Unix V4 Recovered
by Lawrence D'Oliveiro 25 Dec '25

25 Dec '25

A tape containing the only known copy of Bell Labs Unix version 4, dating from 1973, has been found at the University of Utah <https://www.tomshardware.com/software/linux/unix-v4-recovered-from-randomly…>. This was the first version of Unix in which the kernel and core utilities were (re)written in C. This particular tape had been sent to Martin Newell, he of the famous teapot. And yes, the recovered code is now available for you to try running for yourself.

1 0

The Linux Kernel Is Just A Program
by Lawrence D'Oliveiro 24 Dec '25

24 Dec '25

Came across this nifty little article <https://serversfor.dev/linux-inside-out/the-linux-kernel-is-just-a-program/> (found on Bluesky <https://bsky.app/profile/steveklabnik.com/post/3mapj6kf76k2d>) showing that you can run the Linux kernel directly from within a VM in qemu, without installing a distro or anything. It will boot, and then die because it wants to mount a root filesystem and start an init process; so then it’s easy enough to set that up with a few more commands, try booting it again, and there you go -- you have a running VM.

1 0

Linux Kernel Rust Code Sees Its First CVE Vulnerability
by Peter Reutemann 18 Dec '25

18 Dec '25

'Longtime Linux developer Greg Kroah-Hartman announced that the Linux kernel has received its first CVE tied to Rust code. Phoronix reports: This first CVE (CVE-2025-68260) for Rust code in the Linux kernel pertains to the Android Binder rewrite in Rust. There is a race condition that can occur due to some noted unsafe Rust code. That code can lead to memory corruption of the previous/next pointers and in turn cause a crash. This CVE for the possible system crash is for Linux 6.18 and newer since the introduction of the Rust Binder driver. At least though it's just a possible system crash and not any more serious system compromise with remote code execution or other more severe issues. ' -- source: https://it.slashdot.org/story/25/12/17/2034233 Cheers, Peter

1 0