![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
I've been investigating some of the lightweight, command line utilities that are often used to check the status on a system. In some cases, it was hard to track down the packages they were in. It's difficult to search when some of the names are so ubiquitous. Just try running a search for the free utility.
I knew that many of the utilities were in the GNU coreutils package. I found out that many others were often supplied by the procps or the newer procps-ng packages. The procps and procps-ng packages are fairly Linux specific. So, it's not likely you'll find the code ported to other operating systems. While GNU coreutils ports to many platforms, I typically prefer GNU alternatives. They tend to be more lightweight with not as many features. Also, many GNU developers don't particularly like programming for portability and often won't accept patches for their code when there are portability issues. Many of the utilities I considered have been on Unix systems for a long time and are also available on BSD systems. The GNU versions tend to add more features and functionality. BSD systems don't use coreutils, so most of the programs are part of the operating system code.
Busybox and Toybox provide a lot of the utilities as well. Both Busybox and Toybox are designed as one monolithic program that can be accessed through links to the various utility names. That's convenient because there can be a lot of repetition between what some of these programs do. Having the code in all in one place means less maintenance for repetitive tasks. In a few cases, more standard versions of some utilities took this approach as well. For instance, the w program on a BSD system is also the who program.
It seems almost random as to what stats some of these programs cover. For instance, uptime not only gives you how long the machine was up, it also gives you how many users are on the system and system load averages. Sometimes seemingly non-related information may all be returned by the same function on a particular operating system, but sometimes it requires different functions to check each statistic. So, why put it together in this particular presentation? Likely, it's just because that's how it's historically been done and changing too much could break a lot of scripts out there. Some lightweight implementations don't always show all the information of the more common versions of the utilities either. For instance, some versions of uptime just show the boot time and don't bother with the other statistics.
Command line options for invoking a program may not be the same for different versions of a program. Also, since many of the programs have been around a long time, the command line options may not be that intuitive. For instance, I typically see -h reserved for help, but in some cases, it's being used for printing a human readable format. Some other utilities use -H for human readable. Some use both lowercase and upper case for human readable but use factors of 1024 bytes for one instance and factors of 1000 for the other. Personally, I would prefer to use -h for help and -B with a blocksize to indicate what factor I might want to divide by. That way you don't need separate command line options for kilobyte, megabyte, gigabyte and kibibyte, mebibyte and gibibtye. Many programs don't even offer options for terabyte which has become much more standard. As memory sizes go up, the older hard-coded options won't adapt as well. As mentioned, one of the issues with changing command line options to make utilities more uniform is that it could interfere with backward compatibility and cause other programs depending on that functionality to fail. However, all the various implementations aren't exactly standardized to begin with. The Open Group has some standards for utility conventions. Many programs use getopt or getopt_long to help standardize parsing of command line. However, it's not enough of a standard to prevent all the differences between different implementations. So, it's not like scripts can rely on all the same options to be there on different platforms or with non-standard software choices anyway.
I was interested in tracking statistics on memory usage, disk space, CPU usage, process and user related information and when a machine was rebooted. The tools I investigated included free and vmstat which show memory usage, df and du for disk space usage, uptime for CPU usage and boot time, nproc shows number of CPUs, ps and top for process information and utilities such as w, who and whoami for user related information.
I wanted to find lightweight alternatives that I could use on multiple platforms and not just Linux. Minix 3 uses a lot of the BSD utilities, so going with those might be one alternative. However, many still have a lot of code to implement them and the code is often very specific to BSD style operating systems.
One place to find lightweight versions of some of these utilities is ubase which was designed with the suckless.org philosophy in mind:
https://git.suckless.org/ubase/files.html
The code is very readable, but can be very Linux specific. Another alternative is nbase:
https://github.com/cheusov/nbase
This is a port of NetBSD tools to POSIX systems so that makes it a more portable option. Earlier versions of Minix had some lightweight versions of various utilities in their commands/simple directory before they switched to the BSD versions. PicoBSD also had some interesting lightweight utilities programs including aps and sps which are ps alternatives and vm which is a vmstat alternative.
There are also Windows ports of utilities such as ntop:
https://github.com/gsass1/NTop However, while some of these programs look like common Unix/Linux/BSD utilities, many are completely rewritten from scratch and would not port well to other operating systems besides Windows. Alternative operating systems such as hobby OSs that some developers create may have some of these utilities as well. After all, they're simple, command line based and useful. However, since many of the hobby OSs don't support POSIX or have large differences in kernel design, their implementations probably don't port well to other platforms either.
I'm currently in need of utilities that work on Linux, AIX and Windows. I've been investigating writing some of these utilities from scratch in a more portable manner so I can use them in a consistent way on whatever operating system I may need them. Unfortunately, they can be difficult to write, since the underlying functions are not part of the C or POSIX standards and are very platform specific. They can even change with the version of the operating system. Nevertheless, I'm going to continue to work on implementing more portable alternatives for some of the more common utilities. They're useful and their functionality is sorely missed on operating systems where they are not native. It would be really interesting to discuss design issues and trade-offs further with any developers who may be working on similar projects or with users testing out these types of utilities.
Would love to compare notes on this subject. Are there other simple command line utilities that I haven't mentioned that you use to check the status of your operating system? Do you know of other alternative implementations for some of the more common utilities mentioned? Are you interested in using some of these utilities on an operating system where they may not be as readily available? Let me know about your experiences in this area.
I knew that many of the utilities were in the GNU coreutils package. I found out that many others were often supplied by the procps or the newer procps-ng packages. The procps and procps-ng packages are fairly Linux specific. So, it's not likely you'll find the code ported to other operating systems. While GNU coreutils ports to many platforms, I typically prefer GNU alternatives. They tend to be more lightweight with not as many features. Also, many GNU developers don't particularly like programming for portability and often won't accept patches for their code when there are portability issues. Many of the utilities I considered have been on Unix systems for a long time and are also available on BSD systems. The GNU versions tend to add more features and functionality. BSD systems don't use coreutils, so most of the programs are part of the operating system code.
Busybox and Toybox provide a lot of the utilities as well. Both Busybox and Toybox are designed as one monolithic program that can be accessed through links to the various utility names. That's convenient because there can be a lot of repetition between what some of these programs do. Having the code in all in one place means less maintenance for repetitive tasks. In a few cases, more standard versions of some utilities took this approach as well. For instance, the w program on a BSD system is also the who program.
It seems almost random as to what stats some of these programs cover. For instance, uptime not only gives you how long the machine was up, it also gives you how many users are on the system and system load averages. Sometimes seemingly non-related information may all be returned by the same function on a particular operating system, but sometimes it requires different functions to check each statistic. So, why put it together in this particular presentation? Likely, it's just because that's how it's historically been done and changing too much could break a lot of scripts out there. Some lightweight implementations don't always show all the information of the more common versions of the utilities either. For instance, some versions of uptime just show the boot time and don't bother with the other statistics.
Command line options for invoking a program may not be the same for different versions of a program. Also, since many of the programs have been around a long time, the command line options may not be that intuitive. For instance, I typically see -h reserved for help, but in some cases, it's being used for printing a human readable format. Some other utilities use -H for human readable. Some use both lowercase and upper case for human readable but use factors of 1024 bytes for one instance and factors of 1000 for the other. Personally, I would prefer to use -h for help and -B with a blocksize to indicate what factor I might want to divide by. That way you don't need separate command line options for kilobyte, megabyte, gigabyte and kibibyte, mebibyte and gibibtye. Many programs don't even offer options for terabyte which has become much more standard. As memory sizes go up, the older hard-coded options won't adapt as well. As mentioned, one of the issues with changing command line options to make utilities more uniform is that it could interfere with backward compatibility and cause other programs depending on that functionality to fail. However, all the various implementations aren't exactly standardized to begin with. The Open Group has some standards for utility conventions. Many programs use getopt or getopt_long to help standardize parsing of command line. However, it's not enough of a standard to prevent all the differences between different implementations. So, it's not like scripts can rely on all the same options to be there on different platforms or with non-standard software choices anyway.
I was interested in tracking statistics on memory usage, disk space, CPU usage, process and user related information and when a machine was rebooted. The tools I investigated included free and vmstat which show memory usage, df and du for disk space usage, uptime for CPU usage and boot time, nproc shows number of CPUs, ps and top for process information and utilities such as w, who and whoami for user related information.
I wanted to find lightweight alternatives that I could use on multiple platforms and not just Linux. Minix 3 uses a lot of the BSD utilities, so going with those might be one alternative. However, many still have a lot of code to implement them and the code is often very specific to BSD style operating systems.
One place to find lightweight versions of some of these utilities is ubase which was designed with the suckless.org philosophy in mind:
https://git.suckless.org/ubase/files.html
The code is very readable, but can be very Linux specific. Another alternative is nbase:
https://github.com/cheusov/nbase
This is a port of NetBSD tools to POSIX systems so that makes it a more portable option. Earlier versions of Minix had some lightweight versions of various utilities in their commands/simple directory before they switched to the BSD versions. PicoBSD also had some interesting lightweight utilities programs including aps and sps which are ps alternatives and vm which is a vmstat alternative.
There are also Windows ports of utilities such as ntop:
https://github.com/gsass1/NTop However, while some of these programs look like common Unix/Linux/BSD utilities, many are completely rewritten from scratch and would not port well to other operating systems besides Windows. Alternative operating systems such as hobby OSs that some developers create may have some of these utilities as well. After all, they're simple, command line based and useful. However, since many of the hobby OSs don't support POSIX or have large differences in kernel design, their implementations probably don't port well to other platforms either.
I'm currently in need of utilities that work on Linux, AIX and Windows. I've been investigating writing some of these utilities from scratch in a more portable manner so I can use them in a consistent way on whatever operating system I may need them. Unfortunately, they can be difficult to write, since the underlying functions are not part of the C or POSIX standards and are very platform specific. They can even change with the version of the operating system. Nevertheless, I'm going to continue to work on implementing more portable alternatives for some of the more common utilities. They're useful and their functionality is sorely missed on operating systems where they are not native. It would be really interesting to discuss design issues and trade-offs further with any developers who may be working on similar projects or with users testing out these types of utilities.
Would love to compare notes on this subject. Are there other simple command line utilities that I haven't mentioned that you use to check the status of your operating system? Do you know of other alternative implementations for some of the more common utilities mentioned? Are you interested in using some of these utilities on an operating system where they may not be as readily available? Let me know about your experiences in this area.
![[community profile]](https://www.dreamwidth.org/img/silk/identity/community.png){kind=small}