lmemsm | Entries tagged with foss

Let's talk console based software and FOSS operating systems. First, some console based software resources I've liked over the years include:
https://inconsolation.wordpress.com/
https://termux.dev/en/
https://archiveos.org/rogue/
http://inx.maincontent.net/

I have some other resources and console program recommendations in other articles I've written here.

I've seen a lot of FLOSS projects try to convert Windows users to Free Software by sharing GUI based Free operating systems that look a lot like Windows. I really don't know if this is the best strategy to convert people to using something else. Wouldn't it be nice to offer something better and more intuitive rather than just copy what another system can do? I certainly do not think this a good strategy for getting die-hard Windows command line users to switch to FLOSS operating system alternatives. Users that started on DOS and graduated to Windows should be a great market to tap into. Many Unix and Linux systems emphasize console based interactions. However, when Free Software advocates try to reach Windows users and get them to switch, they often end up showing off Windows-like GUIs. They leave out a portion of the market. They leave out the Windows users who don't use Windows because of its GUI design.

What about those of us who still prefer a good old-fashioned command line and want to use console or terminal sessions to get the majority of work done? What kind of conversion path to a Free OS is there for us?

FreeDOS is a wonderful option if you just want DOS. Unfortunately, a lot of current hardware support and drivers are lacking. For years, I've had trouble switching to Linux due to hardware incompatibilities and driver issues. Of all the FOSS operating systems I've tried (BSD, FreeDOS, Minix, etc.), Linux has the best driver support. So, if Linux can't support someone's hardware, it's very likely other options like FreeDOS can't either. FreeDOS does do a very decent job of supporting legacy software and hardware though.

ReactOS is a great path for people who want to use a Free Operating system but want the familiarity of Windows. It runs many Windows programs natively. You can continue to write programs using a Win32 API and have them work on the system. Like FreeDOS, it also doesn't have the drivers and hardware support a commercial system does. Theoretically, when they have something fully compatible with Windows, Windows drivers should just work. It's not at that point of development yet. The biggest drawback I had when trying to use ReactOS was stability. Some Windows programs worked perfectly out-of-the-box. Some crash. I would have liked to get more involved with the project and possibly debug some of my issues. I didn't find it an easy project to join in on if you wanted to help with development.

Using Linux with Wine is another option for people who want to keep using their Windows programs on a Free operating system. I even read about a ReactOS side project where someone used Linux and Wine as a starting point for a ReactOS like system. I love the idea of being able to compile Win32 programs on Linux natively with winelib and have them work on Linux. However, the usual usage is to run Windows programs (closed source) with Wine which emulates a Windows system. They don't even encourage building programs from source with winelib. Personally, I've always found winelib hard to build from source and Wine hard to install on my systems. Some Linux distributions support working with it better than others and some Linux distributions come with Wine already installed.

The X Windows alternative nano-x also offers some Win32 support so you can compile some Windows programs and use them on a system with nano-x libraries. You can build nano-x like an X Windows alternative with client/server support. Projects like NanoLinux and XFDos have created desktop environments using it. You can also build everything into one application (the client and server support) and run applications without a separate nano-x based desktop environment. Most projects have used nano-x to build X11 applications without requiring X11 libraries. However, the potential to port some Win32 applications using the micro-windows part of nano-x is there. Also, nano-x works with a wide variety of operating systems and on a wide variety of hardware.

There are several options for Linux distributions that try to attract Windows users either with Windows look-alike GUIs or with WINE offering the ability to continue to run real Windows programs. However, what is there that's been designed to appeal to those of us who are command line users and want to make a switch? Other than distributions used for restoration or rescue systems like grml and distributions that target minimal systems such as Linux distributions you can run from a floppy or CD, there really aren't many distributions that emphasize a command line interface. There are even less if you're looking for active distributions. Termux is an exception and it targets Android users.

Shells like bash or ash may offer more functionality than batch files, but what competes with Powershell on Linux? At least Mono offers an alternative to .NET. Also, someone who works with a lot of batch files may not find the switch from batch to a shell script all that easy. Backslashes are replaced by forward slashes. Commands like cp and mv are similar to copy and move but don't quite work the same way. Type copy filename in a command line on Windows or DOS and it copies the file to the current directory. Try that in a bash shell with cp and no target file name and you could end up with a mess. Similar syntax that works on Windows may end up corrupting files on Linux/BSD/Unix. If a user isn't already familiar with bash, ash or some of the other shells used on Linux, it's not an easy switch. Just switching between a csh and bash can be a real nuisance to Linux users. Imagine switching from batch to bash.

FreeDOS used to be able to run embedded with Linux systems much the way Windows used to allow users to switch between Windows and DOS. I don't know if that's still an option with Linux distributions and FreeDOS, but DOSBox can make a useful alternative if you want to run Linux and some form of DOS together. Using FreeDOS or DOSBox with Linux allows people to keep working with batch and already created batch scripts. The one drawback with DOSBox is that it doesn't allow for long filenames (beyond the 8.3 convention). There may be some patches to DOSBox that fix this. If so, I would love to find them.

I like the idea of using JavaScript at a command line. It makes an interesting alternative to a shell script. Windows offers this option as part of its wsh system. However, the JavaScript used by Windows is non-standard. It has several extensions not used by other JavaScript implementations such as commands to work with the file system. I looked into projects like TeaJS that work on both Windows and Linux systems as a scripting option. NodeJS seems to have become the de facto standard for command line JavaScript. Plus, it's a cross-platform solution. The main drawback I've heard regarding NodeJS is that the API changes rapidly. So, it's not a very stable system to create command line scripts that you want to be using for years to come.

What are some FOSS operating system options that might appeal to command line users? One could start with a minimal system like Debian netinst or AntiX or TinyCore Linux or possibly some of the musl based distributions. Distributions with large software repositories may have some useful command line applications. Inconsolation showcases many console based apps available from repositories. However, some applications may be dated, not actively supported or have such limited usage that they aren't easily found in a repository. In those cases, it may require building them from source if someone wants to work with them. So, no particular Linux distribution really stands out to me as the best migration path for console users who want to switch to a FOSS system.

For me, the easiest migration path is to have FLOSS programs that work on multiple operating systems. I can use them on a FLOSS operating system, but I can also use them at work where we are required to use closed and proprietary operating systems. If a cross-platform FLOSS program saves data in a particular format, it's likely to use the same format across multiple operating systems. It makes it easier to work with and transfer data. It also helps when the commands you learn, function the same in multiple environments.

Here are some command line tools I use on multiple platforms. I do a lot of my music creation using abc2midi and abcm2ps. I use TiMidity++ in console mode or via command line to convert midi files to wave files. I use diffh and a web browser to view file differences. lxsplit is nice for splitting and joining large files. I use lynx to check if a web page is browser-friendly and accessible. I use a lot of archive tools, communications tools such as curl and putty's plink and psftp, database connection tools, etc. from the command line. There are calendar programs like lcal, dictionary and grammar programs such as sdcv and diction, timer programs and more. There are even programs to draw or edit graphics such as gle, netpbm, imagemagick and graphicsmagick and programs to create DVDs such as dvdauthor.

There is a pattern I've seen with Linux for a long time now. There are great FLOSS program options that appeal to many types of users including those who prefer the command line. With software, having lots of choices can be a positive. However, with operating systems, choice isn't always so positive. There are so many Linux distributions and FOSS operating system options, it's difficult to find one that's user friendly and a good fit. With Windows, there's just one source for it and programs that work on one Windows system work on another Windows system. With Linux, it's not one size fits all. There are so many alternatives and often, none seem to be just right. It's hard to use software from one Linux distribution in another, let alone try to get your Windows executables to run properly. Maybe if more of the Linux community adopted the Linux from Scratch motto of your operating system, your way, it would be easier to switch. However, with lots of Linux operating systems, each with their own niche and their own emphasis on certain features and distinct avoidance of other features, it makes it hard for a user that doesn't fit a specific demographic to use a particular distribution. It's even harder for someone who wants to volunteer efforts to help out a distribution to find the right distribution that would accept the type of help he or she would like to offer.

FOSS is supposed to give users a way to get off the merry-go-round of continually needing to pay to upgrade hardware and software. However, it's not always easy to make that switch. Just offering an operating system that outwardly looks similar to a Windows solution so it will seem familiar isn't always desirable. It can be harder for users when software seems almost alike but certain parts don't work the same way or may potentially have devastating results. The cp command overwriting files that copy wouldn't is a good example. Offering GUI solutions to attract Windows users who primarily use the command line is just not an effective strategy.

What techniques or features would make the switch from another operating system easier for you? If you're like me and prefer working in a console based environment, what would your ideal operating system look like? Have you found a FLOSS distribution or FLOSS tools that fit well for you? Please feel free to share some of your more useful FLOSS finds with me on Mastodon.

I recently had an issue doing an upgrade of AIX Toolbox on an AIX machine and it caused the sudo program to fail because it couldn't find dependencies it needed to execute successfully. I started searching to see if there were simpler alternatives that could do a job similar to sudo and would not have so many dependencies. Of the various options out there, I found three that were interesting.

Doas was created for OpenBSD. There are different versions of the program, including a portable fork called OpenDoas. I tried this version, so I can't say much about the others at this point:
https://github.com/slicer69/doas
The program does build on Linux as well as on the BSD systems. It can use BSD functions on BSD systems for authentication but uses PAM on Linux and other systems. The pam_start function needs struct pam_conv to initialize and part of pam_conv points to a function that handles input. Linux, Solaris and some systems provide functions as part of their PAM library. However, not all systems have a library function to pass to pam_start. I wasn't able to find a supplied function on AIX. OpenDoas appears to have a function as part of the OpenDoas program itself. There are also some simple examples of a function that can be used with PAM available online if you're on an operating system that doesn't have one readily available.

Another option I came across was called please. It only offers the option of PAM authentication. It has the same issues for portability with regards to the function needed by pam_conv. You can find the source code for please here:
https://github.com/gblach/please

The last alternative I experimented with is sup. It's on the recommendations page at suckless.org. The interesting thing about this program is that it doesn't require PAM to work on various systems. That's a nice feature if you're building a minimal operating system and don't have the PAM library built and installed. It has an option to use a hash function to make sure that the user is running the program they're supposed to and not a program with the same name that has been substituted for it. The hash function has a less lenient license than the program on its own. I was thinking it would be nice to use a system library with a hash function instead of needing to use the one provided by the program. However, that would increase the number of dependencies the program requires. The sup program also has a feature to run a program with a fork. As I'm not a fan of the fork function and how many resources it uses and its lack of portability, I avoid that option at all costs. I remember the topic of fork coming up on the musl mailing list. The spawn function was mentioned as a more efficient alternative. Another difference between this program and the other two is that it uses hard-coded settings rather than needing external settings files. This requires recompiling to change options, but it makes it harder for someone else to modify the settings from a security standpoint. Source code for sup is available at:
https://github.com/dyne/sup

Upon further investigation, the sup that the suckless.org site recommends is the earlier version found here:
https://oldgit.suckless.org/sup/files.html
It does not include the hash and fork options and offers a more minimal implementation with straight-forward code.

I've seen some complaints that using sudo or operating/logging in as root can be more insecure. Alternatives may be more secure when they have less code and are easier to maintain and debug. That's one reason they may be attractive. However, the alternatives need to be well written or well tested and debugged or they can be more insecure than the standards. There's also the advantage of security through obscurity. If exploits use sudo, they may not be expecting or looking for an alternative like doas on a system. Many people prefer using whatever's standard assuming that it's secure enough or so many other people wouldn't be using it too. Just as having less code can be more secure, requiring less dependencies can also have security advantages. It's another way to limit the amount of code in a program. Using a shared library can also create security issues for a program that may need to be addressed.

As a cross-platform programmer, I always look for programs that will work on a variety of operating systems. The sudo alternatives port to many systems but many of their concepts won't transfer well to Windows or DOS operating systems. While you can have multiple users on some DOS variants, it's more of a single user operating system and restricting who can run things is not typically an issue. On Windows, this can be important. However, Windows has a completely different way of handling permissions and rights from Unix and Linux systems. I did run across some samples of sudo-like alternatives designed for Windows. However, they work very differently.

It was interesting to find out how programs like sudo or the alternatives I've mentioned function. A sudo-like program is owned by root and has a special permission set on the program file. By setting the suid bit on the file permission of the program, a non-root user can run the program as if they are the root user. A technique like this would not work natively on Windows. One can elevate permissions in Windows using the Windows API. However, it doesn't work in all cases. There's a way to use SeDebugPrivilege to elevate permissions in a program but some organizations turn that privilege off for their users.

Basically any of these types of sudo like programs uses a function such as execute or spawn or CreateProcess to run other programs. They allow a user who typically doesn't have permission on a particular operating system to have that permission by starting another program or process through that program. In some form or other, that program needs to have special rights to run other programs whether the user has the rights to or not.

I find it interesting that root automatically has permissions to copy, move or remove files, no matter what directory. On POSIX systems, running as root really solves a lot of permission issues especially when building and trying to install programs. While Puppy Linux embraces the idea of running as root and some small, single user systems work fine this way, many Unix and Linux systems highly discourage running as root. While it's nice to be able to easily install a program you built, it's not helpful if you accidentally install something over another library or program and cause your system to fail in the process. It's also easier to accidentally remove needed files in a critical directory when you have the permissions to remove anything. For instance, a misbehaving install script could easily wipe out files needed for the system to operate properly. I do feel that critical programs with dependencies, if built statically, have several advantages to programs using shared libraries. They won't fail if there are issues with finding or loading a shared library on the system. Also, someone can't hack the system by having that program load the wrong library with a function that doesn't do what's intended. At this time, static building isn't widely embraced on Linux systems and the GNU glibc library cannot be used to build static programs. One would need to use a C library such as musl if static builds are desired. I personally happen to think there are many advantages to using musl over glibc. However, at this point most Linux operating systems still use glibc. Both using alternatives to glibc and running as root are not mainstream practices and both can be controversial in many sectors. There are pros and cons to running as root versus running as another user. That's what makes programs like sudo and similar alternatives so useful. They give the power of root but can limit what you can do with it to make sure you don't accidentally run commands that could disrupt or cripple the operating system.

Personally, I'd like to see a cross-platform sudo alternative that would work with Windows as well as Unix (including AIX) and Linux operating systems. It would be nice to have a small, simple program that would work for most multi-user operating systems available. I prefer the idea of a more compact program with very limited dependencies. A static build or no extra libraries would have avoided my shared library issue on AIX which caused sudo to fail.

I'd be very intrigued to hear about other sudo alternatives that are available. I'd also be interested in hearing about the pros and cons of security with regards to use of some of these programs. What do you regularly use on your system? What alternatives to root or sudo have you found? What works well on multi-user operating systems beyond Linux and Unix? What are your security concerns using sudo or some of these alternatives and how do you work around them? Feel free to share some of your comments on the topic on Mastodon. I'll be updating this article with more information if I find other lightweight, low dependency sudo alternatives that I like.

Slow Android emulators to test Android programs may be a thing of the past on my current Windows system. I downloaded and installed Windows Subsystem for Android. It's a convenient way to test out apps you've created without having to resort to installing VirtualBox and Android x86 or using other alternatives such as Qemu or some of the very slow Android app emulators.

If you want to try out other Android apps on your Windows system, you can do that as well. It may not look like there's a wide variety of apps to choose from at first glance. Windows Subsystem for Android comes with Amazon Appstore instead of Google Play store. I've seen some reports of getting Google Play store working but it doesn't seem worth the effort and really isn't necessary. If you're just going to test your own apps, you don't need an entire app store. However, it is fairly easy to get F-Droid installed on Windows Subsystem for Android. Most of the apps from F-Droid work very well in an emulator. F-Droid had more than enough apps for my needs. Also, there are other repositories such as IzzyonDroid that can be added to F-Droid giving even more options to choose from. Finally, there are sites, such as APKPure, that will allow you to download apk files directly. Once you have the apk file, you can install the app yourself.

The basics for installing apk files in Windows Subsystem for Android follow. First, download a copy of the Google Android platform tools for Windows. adb is the program that is required from the platform tools. Start up an Android app, any Android app, in Windows Subsystem for Android. This makes sure that Windows Subsystem for Android is currently running. At the command line, type:
adb connect 127.0.0.1:58526

Once a successful connection is made, most apk files can be installed from the command line using a command similar to the following:
adb install file.apk
Substitute the actual name of the apk file for file.apk in the command.

What if you have an xapk file instead of an apk file? Rename it to a zip extension. Use a tool like unzip to extract the files in the xapk. Use the command adb install-multiple with a list of the extracted apk files.

That's all there is to it. Once that's done, you can easily install Android apps and run them on Windows. I found some actually run better on Windows than on a phone. However, some did not fit the screen well and some required Bluetooth which is not yet supported in Windows Subsystem for Android. Still, you can run quite a nice selection of apps and you can use it to test your own Android apps as you develop them.

I've continued my search for organizing software ( https://lmemsm.dreamwidth.org/25452.html ). I've tried several options available from F-Droid and Google Play. I've run across interesting concepts such as using gamification and rewards systems to encourage new habits or complete large tasks. There are also tools to help set goals (such as Specific, Measurable, Achievable, Relevant and Time-Bound SMART goals), break down tasks, remind when to do a task and track what's completed. With all those apps and even some FLOSS programs out there, I've yet to find anything I'm comfortable working with. Some of the commercial mobile apps have wonderful concepts behind them. However, they also have fees or ads or require you to sign up for a service on the Internet. The F-Droid apps are typically more friendly when it comes to privacy. They don't have ads and most don't require sending personal data over the Internet. They're typically simpler than the commercial apps which can be a good thing. However, it's a matter of finding one that does what you need in a way that's comfortable to you not just what the developers and core users need.

I've been reading a lot lately about flow states and the psychological inertia many experience when they're trying to break out of the flow and do something else. Writers may get lost in writing and forget to break for a meal. A programmer may be so engrossed in a coding project, he or she may not notice the clock and the fact that it's time to go home. Who really wants to miss that? Inertia can also make it hard to start a new task. So, I tried to narrow my search to alarm programs that could notify me when to change focus and switch tasks. There are several timer programs that can time tasks for you and fire off an alarm when the interval to work on a task is over. I decided I wanted something more along the lines of an alarm that notified me at a specific time every day. It was suggested I check out the Google clock program which has an alarm. The alarm certainly got my attention. However, I couldn't turn it off without turning off my phone completely and it could easily annoy people around me.

I finally decided to overcome my own inertia and stop searching for a solution and just write one. I used SDL because it ports to a number of platforms including mobile devices. I broke the job up into tasks and started with the most crucial pieces I needed. I figured it would be more difficult to come up with a file format and source code to decipher multiple alarm times, so I started by hard-coding the time. Then, I switched to passing the time via the command line. Once I got that working, I realized, I don't really need to store several alarm times in an initialization file for the program. Using the Unix philosophy of doing one thing well, I decided to leave that task to another program and call this one just to display one alarm. So, one could combine this program with another program like remind or one could use cron or Windows task scheduler to start this program when needed.

What I really wanted was a way to gradually shift gears when I'm heavily concentrating on something. I did not want a jarring alarm. I wanted something that would give me time to complete what I'm doing and transition to something else. I really liked the Toastmasters concept of using green, yellow and red signaling to decide when to end an ongoing talk. So, I started with the color concept. I added a way to play an optional wave file with it. By limiting what the program did to just handling the alarm related tasks, I was able to get it done in a fairly reasonable amount of time.

While I was searching for useful organizing and scheduling programs, I experimented with remind. I found it very promising, but it takes some work to create the entries you want to be reminded about. The main drawback is that its designed for Linux and the developer would prefer that it not be ported to non-Free operating systems. While it can be ported, I'd prefer to work with software created by developers who want to support multiple platforms. I do like the idea that it's a command line tool and can be customized using a text file. Instead of using todo programs, I've been using simple text files to keep track of my lists. I've found that more effective. Something like the todo.txt file used by todo.c and other programs might be an option at some point in the future because it combines the idea of a simple text file with a more programmatic tool. It would be nice to see a todo tool and an alarm tool combined. Possibly if a time is part of each task, a program could parse out times and activate an alarm when needed. So, I'm still searching for the right tools to use together to help improve organization. However, I'm happy to finally have an alarm that offers the features I most wanted.

I'd be very interested to hear how others organize and switch or begin new tasks when they're experiencing inertia. What tools and programs do you use? What works? Also, if anyone is interested in brainstorming putting together different simple tools that each do one task well to help improve organization and efficient use of time, feel free to contact me. Discussion is welcome via Mastodon (https://fosstodon.org/@lmemsm) or the distasis mailing list on groups.io.