Category: Relearning Linux

Posted on

How I Would Relearn Linux #7: Wandering

Good Morning from my Robotics Lab! This is Shadow_8472, and today I am back with another Linux-learning tip. Let’s get started.

This edition of How I would Relearn Linux will be a bit heavier on the story side, but I’ll try to make it as interesting as possible. If I totaly lose you, feel free to skip to the Takeaway before making your way back to where you left off.

DerpyChips, one of my two daily drivers, has had a longstanding problem with running Discord where the proper installation crashes after updating (if applicable). I have it installed as a Snap installation, which got it working, but costs me my KDE themed mouse pointer, which I’m quite fond of. I thought to fix it as a side project. For the record, none of these hammers work: restarting the program, rebooting, reinstalling.

When in doubt, launch a failing program from the command line. I caught an error and looked it up, which landed me on Reddit where one user had fixed the exact same problem by finding a better driver. Derpy has an AMD card, so I looked through AMD’s site for the proper proprietary driver. It took an hour or so, but I found a list of 32 and 64 bit drivers for my exact card – they were just seven years old! The card is about twice that.

Now, I faced a dilemma. AMD’s driver might be the most compatible, but will it work with KDE 6, which I expect Derpy may be running within a year barring any major hardware upgrades? I have doubts. Besides, I didn’t feel like cleaning up a driver bricking my installation anymore. I’ll probably seek out an open source driver at a future date once I gathered a bit more background knowledge.

Along the way, I noticed a couple abbreviations tied to the graphics system: EGL and GLX. A search brought me to a Hackaday post about Firefox 94 and above switching from GLX to EGL as window management transitions away from the legacy X11 window management system in favor of Wayland for lower overhead, better security, and closer access to the hardware [1]. The top comment lamented this transition finishing with, “Sadly the kids don’t want a fun OS that does cool things like let you run your program on one machine but display it on a second. I guess they just want an OSX that they didn’t have to pay for.” My surprise died down when I read the screen name: XForever. The comments in reply were a frenzy of reports claiming X11 remote display either “never did [work]” [X], “worked perfectly fine 20 years ago and still does” [Traumflug], “only ‘worked’ because network security was a joke 20 years ago” [Pat], and that slow network could make or break the experience [Guest]. One user [raster] went back to refute XForever’s complaint with a link to a Git for Waypipe.

While the conversation brought up other methods of graphical computing from another device, like VNC (Virtual Network Client) and RDP (Remote Desktop Protocol), SSH caught my attention [Redhatter (VK4MSL)].

ssh -CY user@remotehost x11client

The unfamiliar flags turn out to mean compressing the datastream and trusting something to do with X11. I had to try for myself.

Logging in to my father’s computer, I brought up FreeTube over SSH no problem. I then tried MultiMC’s start script, and something errored out and it came up on his screen. I thought that was it without making a custom script or at least an export command, but I tried running bash as my x11client. It came up without prompts or access to command history, but when I called up the script, I got a window. The game itself was a bit slow to play given how choppy the video was, but it was good enough to navigate to an AFK point – until I turned up the graphics with extra shaders, then it dropped to 1fps.

Takeaway

Allow yourself to wander. Poke at annoying, non-critical problems every so often. Even if you don’t get to where you intended, you can still end up learning something objectively cool. I can see this tool will be very useful

Final Question

What cool stuff have you found by allowing yourself to wander?

Work cited

[1] M. Carlson, “Firefox Brings the Fire: Shifting from GLX to EGL,” hackaday.com,Nov. 23, 2021. Available: https://hackaday.com/2021/11/23/firefox-brings-the-fire-shifting-from-glx-to-egl/ [Accessed Mar. 25, 2024].

Posted on

How I Would Relearn Linux #6: Bleeding Edge vs. Stable vs. Enterprise

Good Morning from my Robotics Lab! This is Shadow_8472 and today I have another installment in how I would relearn Linux. Let’s get started!

The Linux ecosystem has a lot of moving parts within easy view of the end user. Various distributions curate these often redundant parts in line with their respective goals. For example: how new do you like/want/need your software?

If “Cutting Edge” is the latest and greatest, then developers and enthusiasts willing to volunteer time and effort reporting bugs and provide feedback for new features belong on the “Bleeding Edge” – typically using a some sort of rolling release or compile-it-yourself based package manager.

On the hand, if the system’s goal is to not need sudo every few days, a stable system like Ubuntu or one of its many downstreams may be a better choice, but know that distros aimed at an Enterprise audience may leave you spending excessive amounts of time dumpster diving through backports for missing dependencies trying to compile source code when a two-year-old feature comes up missing (ask-me-how-I-know).

My pick is that I maintain a bit of everything. I have two computers I use as daily drivers. One runs EndeavourOS and another PopOS. EndeavourOS is Arch-based and on a rolling release while PopOS is Ubuntu-based with releases every few months. This way, if major changes break something with software I use across both devices don’t hit me all at once. Just this past week, I re-booted into KDE 6 on EndeavourOS and Discord immediately started having problems displaying messages as I draft them and occasionally the whole window would black out until interacted with. Turns out KDE 6 defaults to using Wayland instead of the old graphics display system, X (also called xorg, X11, x.org, etc). These are/this is [a] bug[s] that need[s] attention before X is retired from mainstream use. I now know to look out for it/them when KDE 6 comes to PopOS – probably sometime later this year. For now, X is still around in case a fallback is needed.

Takeaway

While my alert system to changing conditions is adequate for me at this time, another approach to consider is staying current on news regarding projects you use. I didn’t note his name, but I did come across someone saying he read about the KDE 6 Wayland. Time will prove the choice pioneering or foolish.

Final Question

Where do you balance on the innovation vs. stability scale?

Posted on

How I would Relearn Linux #5: Basic Scripting

Good Morning from my Robotics Lab! This is Shadow_8472 with another tip for how I would relearn Linux. Let’s get started.

Scripts

No serious system administrator has time to memorize long chains of commands taking minutes to type and might need fixing after the first try. When faced with a periodic task involving a long, involved [set of] command[s], it’s preferable to write them in a script to be run sequentially from file. While I did get by for a few years by using Bash’s (terminal shell, see section on shells) history functionality, a script is a much more sustainable way to “remember” commands.

To write a script, put your command[s] into a text document – one per line. The pound sign # at the start of a line turns it into a comment to clue future you or others into your thought process. Using a backslash \ character and additional whitespace for alignment, lines may be broken up at any point to increase readability. This becomes especially useful when dealing with half a dozen flags.

#this line is a comment
podman run \
    --name testpilot \
    --network podman \
    --ip 10.88.2.88 \
    -v ~/sandbox/testVolume:/root/vol1 \
    --rm \
    busybox:latest
#No interrupting commands – even with commented flags.
#    -v ~/sandbox/wrongTestVolume:/root/vol2 \

A script will then need permission to execute.

chmod +x <filename>

Lacking a proper explanation of the Linux permissions system, just know this is a fast way to ensure YOU have permission to EXECUTE your script.

Even understanding up to this point unlocks a powerhouse of possibility. These tools –sequential commands, comments, line breaks, and white space– are all I need to make scripts to stitch together more complicated programs I work with to build my home server. Most importantly: scripting commands allows me to clearly visualize the command I’m working on.

Shells

One slightly mind bending concept is the shell. In simplified terms, a computer shell is an operating environment. Open a terminal on a Linux workstation, and you probably have a Bash shell. Some part of desktop environment you opened that shell from is a graphical shell. From Bash, you can open another instance of Bash inside the last one like a Russian matrushka doll (nesting dolls). Connect to another computer with SSH, and there’s another shell (one one each machine working together, I think?). Other programs –such as a Python interpreter– may have a shell of their own.

Not all shells are intended for human interaction. Somewhere below the graphical environment is logically a shell either running directly atop the kernel (I don’t actually know if the kernel itself counts as a shell) optimized for running quickly.

Most important to this conversation: running a script will open a shell for its own use and close it afterwords. Fancier shell scripts can leverage many powers characteristic of typical programming languages. Flow control allows logic to branch and loop depending on the state of a whole assortment of variable types. And thanks to shell manipulation, variables can be isolated from one another in ways I’m totally unfamiliar with. And all this exposed power comes packaged directly into the operating system itself.

Takeaway

Shell scripting is a powerful tool. This single lesson is enough to unlock a wealth of potential, yet only a fraction of its total capabilities. Variables –for example– turned out more involved than I thought, so I scrapped a section them after writing about shells to support it. While it’s OK to run with only a partial knowledge, it’s also good to be aware of additional capacities when reading scripts written, polished, and published for use by other people.

Final Question

What projects have you designed with scripts?

Posted on

How I would Relearn Linux #4: Package Management

Good Morning from my Robotics Lab! This is Shadow_8472 with part four of How I Would Relearn Linux, where I answer the questions I had and offer the tips I wish I knew a few years ago when I started exploring Linux. Let’s get started!

Why Package Managers are Important

Linux software is often distributed in modular units known as packages be they applications, drivers, or kernel modules. If you’ve ever assembled a modpack for a game, there’s a chance you’ve had to chase down a dependencies or address conflicts before you could use it. Now imagine doing that for a full operating system, and you get the idea of what using Linux was like. A single packaged game might require tens or hundreds of prerequisite packages by the time you settle everything. This problem was quickly automated with package managers.

How to Use a Package Manager

Specific features of a package manager will vary, but their primary goal is to install, update, and remove packages. It will have a repository list telling it where to install software from. Android is Linux… kinda. Its default package manager is the Play Store. Its job is to install, update, and remove packages per user direction while making the process as invisible as possible. Unlike Android, a package manager in Linux is typically invoked using another program called Sudo (my preferred pneumonic is “Super User DO” even though I use the su-dough pronunciation).

When installing packages, a package manager has a list of repositories to contact. It will reach out to them with each package being installed and usually ask for clarification if multiple matches are found. It then does the same thing for all the listed prerequisites until it generates a full list of the missing packages needed to make your desired package run. On user confirmation, it begins download/installation.

Updating software is similar to initial installation. New versions may add features that rely on new or different library packages. A package manager will recalculate the missing packages and notify the user if any installed packages are either missing or no longer needed (This is true for the Debian/Ubuntu family’s package manager, apt. I’m not as familiar with pacman or dnf to speak for their specific behavior – as in they might just auto-remove them and I’d be none the wiser).

Uninstalling packages is similar to updating, only an explicitly installed package is being removed along with its unneeded dependencies. This may also be a necessary step if a conflict arises which the package manager cannot automatically resolve, though additional force may be required to bypass dependency checking.

Secondary Package Managers

Going back to Android for a moment, it is possible to “sideload” apps by downloading them from outside the Play Store. It’s even possible to download other app stores, such as F-Droid, which specializes in Free and Open Source Software and the Aurora Store, which uses the Play Store’s repositories, but with an emphasis on being privacy conscious. Similarly, there exist Linux package managers aimed at less-trusted community packages or packages that take care of more of their prerequisites. In this way, multiple versions of a program my be installed simultaneously, which may lead to confusion if a broken copy isn’t cleaned up in the hopes that an update will fix it.

Caution is often advised though when considering adding multiple primary package managers. I’ve not seen or looked for a solid explanation, but I can guess it’s so you don’t break your system by installing everything twice and having things call the wrong programs using twisted system links.

Takeaway

Whatever package manager your installed distro uses, you will get more out of your experience if you take the time to learn how to search for packages (a case where you don’t need sudo). When an exact version matters, you can usually extract that information from your package manager. If you cannot find a package, www.pkgs.org is also your friend. Your package may be in the repositories for the next or previous distribution, or in a repository you have to add special.

For example: in another project of mine, I found and looked up the version of Podman I had on Debian to learn it doesn’t support the Secrets feature I had been using on Rocky Linux: I had to adjust my approach accordingly.

Final Question

What package manager(s) came with your system(s)?

I look forward to hearing from you in the comments below or on my Socials!

Posted on

How I would Relearn Linux #3: Terminal Navigation

Good Morning from my Robotics Lab! This is Shadow_8472 with my third installment of How I would Relearn Linux, a series where I pick an entry-level skill I would want to re-learn first if I were to begin my Linus journey over again. The terminal is the heart of the Linux admin experience. Let’s get started!

Command Line Interface (CLI)

The most familiar paradigm of using a computer is the GUI, or Graphical User Interface. Before the GUI, computers more closely resembled increasingly fancy typewriters writing from left to right, top to bottom. Just as GUI’s are still here after VR has been on the market for years, so too has the Command Line Interface (CLI) endured. Modern terminal emulator programs are wildly customizable, but that is beyond the scope of this post as well as my capabilities.

Basic Navigation

I’ll assume you have experience with a GUI file manager. The Linux terminal can do everything those do, but instead of hitting buttons or double clicking folders, you use commands to jump around to directories. My experience is with a popular default shell known as bash.

The Command Prompt

Most beginner-level Linux distributions’ terminals display a prompt like this:

<username>@<hostname>:<directory>$ █

There may be variations like different colors or square brackets present. These are heavily customizable and often are by distribution authors. The point of the prompt is to display who is logged in to what machine and where it is working. For example:

[shadow8472@ButtonMash ~]$ ▯

In this case, username shadow8472 is logged in to ButtonMash. The ~ is a shortcut for the current user’s home directory. The hollowed out cursor means I clicked out of my terminal emulator to another window.

File Paths

Similar to other operating systems, Linux has a file system resembling the trunk, limbs, branches, etc. of a tree. Starting at the root directory, /, (often simply called “root”) absolute file paths list directories separated by additional /’s.

/home/shadow8472/Downloads/Games/TicTakToeStrat.sh

Relative paths the present working directory and work from there. So, if I were in my Downloads directory, the following path would point to the same:

Games/TicTakToeStrat.sh

A leading . (period) in a file name means a file is hidden. A lone . points to the present working directory, and a pair of periods .. points to a parent directory. These are mostly used when working with a file in the present working directory or moving the present working directory up one level, respectively, though if so inclined, a user can use them as part of a larger path:

/home/././shadow8472/Downloads/./Games/../Games/../../Downloads/Games/./TicTakToeStrat.sh

Spaces cannot be used in file names because the space character dictates the flow of control when working with commands. To get around this, the \ (backslash) may be used as in “\ ”, or the entire file path may be placed in quotation marks. I find it much simpler to use capital letters for new words.

Commands

Linux commands are special system programs accessible from anywhere. As a general rule, they follow the syntax (pattern):

$ <name> -<flags> <additional parameters>

If everything before the $ is who and where you are, everything after is what you do. I like to imagine myself as walking around on the file system as though it were a maze of rooms. More practically, pressing tab will complete a command or file name (or list the possibilities based on syntax if user presses tab multiple times).

Flag and parameter syntax will be specific to an individual command/program. In general, flags control the mode a program operates in; -h or –help is a common flag to quickly access a brief program description, acceptable syntax, other flags, and whatever the programmer thinks it is most important for users to know at a glance. Parameters are more about data – especially file paths. And if you weren’t confused enough, flags can have parameters of their own.

Point of clarification: 
With the exception of Java, multi-letter flags use two hyphens. WordPress's automatic conversion is wrong.
--help
ls (LiSt the contents of a directory)
cd <file path> (Change Directory)

When using the terminal, I will imagine myself walking around the file system as though it were a maze of rooms. I use ls to “Look Surroundings.” The command cd takes steps from one room to another – either by providing a name or using .. to take one step backwards, toward the root. While not a command per se, I envision using tab to complete directory names as of feeling around with my hands; three characters before using tab is usually enough to identify a name or otherwise save a lot of time and mental energy typing and spell checking an exact name.

cd -

I properly learned this trick specifically for this week’s post. It returns you to the previous present working directory. I’ve known about something like this for a while and I intend to use it more when “teleporting.”

pwd (Displays absolute path of Present Working Directory)
whoami (Who Am I? outputs who you are working as)

These commands may seem redundant with the prompt, but some Bash shells reduce clutter and omit the path leading up to the present working directory, which can get confusing when working around multiple instances of a program. whoami exists because some prompts only start at the dollar sign, $.

man <program name> (MANual)

The man command brings up the “man page[s]” for a program detailing exactly how to use it when -h or –help aren’t enough. If a program still eludes you, Internet search and hope your results aren’t just the man page all over again.

Takeaway

The Linux command line cannot be done justice in a single blog post. Manipulating it effectively can be considered a form of art at higher skill levels or on a VM/spare machine you can afford to break. Shell scripts effectively put the computer at its own terminal, and there exist command programs written specifically for this situation. I’m planning on a followup where I go over file manipulation. In the meantime, feel free to look up a cheat sheet and keep it somewhere safe.

Final Question

Are you familiar with the terminal? What assumptions would you say are safe make about people who have only ever used a GUI file manager?

I look forward hearing about them in the comments below or on my Socials.

Posted on

How I would Relearn Linux #2: Blogging

Good Morning from my Robotics Lab! This is Shadow_8472 with another installment of How I would Relearn Linux, a series where I drop tips about the lessons I’ve learned writing about Linux. Let’s get started!

Document Your Work

This blog has been invaluable to my self-studies of Linux. The weekly push has been vital to keeping my various projects alive. If I were relearning Linux, I would highly recommend blogging as one thing I got right early on.

At the same time, another medium might be right for you. The Linux community self-propagates through everything else from videos and books to forums and chat rooms. A private journal would not be inappropriate – as a matter of fact, if I were relearning Linux, I would write for a few months directly into a word processor and buffer it on a hard drive while I research a host, domain name, and blogging software. Whatever you medium or two are suitable to your talents will provide you a resource to look back on later.

Audience and Frequency

Let’s take a closer look at my own blog as an example, Let’s Build Robotics With Shadow_8472. My content is online for the world to see, but my primary audience is myself as I write. I’m of course excited to talk about my projects, but if I cared about having a constant stream of fans jabbering away about me, I would have either paid closer attention to audience building or given up long ago. My main purpose is to give myself a regular push to learn.

The one piece of advice I’ve followed closely is consistency. I’ve posted Mondays at noon (Pacific) with few accidental exceptions since learning to schedule posts. Not every post is my proudest work, but that’s OK. Progress is slow with projects outside familiar parts of my niche. When projects turn out to be much bigger than I judged, I can talk about what’s not working, call it “Part 1,” and hope someone has a solution. If all else fails, I’ve afforded myself the flexibility to switch to a smaller topic when I burn out. It will be there in a month when I return.

Takeaway

This blog remains one of the most important pillars of my continuing to develop my Linux skills. I would totally recommend something similar for anyone looking to learn a technology skill.

Final Question

How do you record your long-term progress?

I look forward hearing your answers in the comments below or on my Socials.

Posted on

How I Would Relearn Linux #1: Ventoy

Good Morning from my Robotics Lab! This is Shadow_8472, and today I am starting a new series where I drop a beginner-level tip whenever I have a project change direction last minute. Let’s get started!

Multiboot USB

The biggest barrier to entry for installing Linux is creating your first installation media and booting to it. These days, it looks like downloading a program like either Rufus or Balena Etcher and burning a USB thumb drive with a 1 to 4 GB .ISO file, almost always turning the rest of your 8 to 64 GB USB drive into dead weight. If you intend to continue exploring Linux, it’s easy to get in the habit, and soon you will have a collection of spent USB drives mucking up your search for the one drive you saved to transfer text files or pictures.

The solution is to get a large USB and multiboot it using a utility like Ventoy or YUMI. My experience was with installing Ventoy from Linux, and it was as simple as creating any other USB-based bootable media. Since then, whenever I am instructed to “burn” a .ISO file to disk, I just copy it to Ventoy and it shows up.

What’s more is while I was researching for this post, I learned that it even comes with a Windows installer. As usual, be sure to offload any files you wish to keep as they will be lost while setting up Ventoy.

Takeaway

I consider my Ventoy USB to be the most useful tool in my possession. I highly recommend it for anyone learning Linux.

Final Question

With the entire array of Linux distributions to try out, which ones do you keep around on your master USB drive?

I look forward hearing your answers in the comments below or on my Socials.

Privacy Policy