December Days 02025 #27: Sysadmin
Dec. 27th, 2025 11:20 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
silveradeptIt's December Days time again. This year, I have decided that I'm going to talk about skills and applications thereof, if for no other reason than because I am prone to both the fixed mindset and the downplaying of any skills that I might have obtained as not "real" skills because they do not fit some form of ideal.
27: Sysadmin
Not, like, in any professional way, thank goodness, because it should be painfully obvious at this point that I am, at beset, an amateur who rummages around in other people's scripts and objects to do things. That situation often means that when it comes to troubleshooting my own problems, I'm not always as skilled as I am when troubleshooting other people's problems. I would say that I'm not that great at it, but considering that I do know how to run the update scripts regularly, and I can be a decent hand at the search engines, it's more that if the solution exists, and I can find it, and then understand what it's doing, I can usually fix things, or at least reset them back to a known good state and then try again.
I have certainly spent some amount of time knuckles to elbows deep in systems, trying to get them to unfork themselves, sometimes while in the system, other times through the use of recovery utilities and live-booting Linux systems that can unbollox bad configurations and delete problems. I have soft-bricked GRUB at least twice, not that it's particularly hard to do so, but with the help of the Internet, I managed to find a boot path and then fix the issue so that GRUB would stop complaining about not having found anything to boot, despite the partition being right there. When I was transferring hard drives from one system to another, The Windows install on the hard drive started complaining and not booting. Thankfully, the error message was actually helpful, and the Internet told me that what I was looking at was a driver issue - there were some proprietary drivers installed for one type of video card, and the new machine was using an entirely different type of video card, so there were conflicts, and I had to pull out my install disc to boot to a recovery session, then get to the hard disk in question and delete the offending driver files and then uninstall the program that was providing them. It's stuff like this that makes me appreciate the way that a lot of Linux things are configured in text files and there are package managers that handle most of putting files in their proper places, and those package managers can be used to install, uninstall, and reinstall things if they get off of true. There's still a lot of complexity involved in making sure that dependencies are met and the software will run true, but the people who have made the the package management tools have mostly abstracted that away, to our benefit.
[Slight diversion: There are now things in Linux packaging that are taking things one additional step further and creating standalone executables that contain all of the necessary libraries to work, and in the specific versions that the application was built with, to prevent situations where a system is running libraries taht are either too old or too new for the application. Snaps, Flatpaks, and AppImages try to make Linux computing more like an app store experience, akin to what might be on a phone, tablet, or iProduct, including with centralized app stores and web frontends that then get things installed on a system with a few clicks. The user community appears to be divided about the use of hese kinds of packages, because an item with all of its dependencies is a significantly weightier package than without, and depending on how those packages are managed, that might mean these self-contained applications have several different versions of things running, as opposed to using the system's already-installed libraries and programs to achieve the goal. Self-contained programs have the advantage of running mostly platform-independently, so you can put them on any machine and they'll work, often because they carry with them what the machine that compiled those programs was running at the time of it being compiled.
Some of the objections to those packages include the cruft that comes with them, and how that cruft interferes with a smooth working system or introduces issues of their own from having all of those different programs present and working on a system. (I'm not sure there's quite as strong of objections to Docker and other container programs that generate sandboxes or virtual environments of a sort for programs to run in without necessarily having access to the system running the container, except as what's permitted by the container itself. I don't doubt somehow that Docker containers make things more secure than Snaps, Flatpaks, or AppImages, but there's definitely much more enthusiasm for Docker among the users that I have heard. This leads us into…]
There are definitely some users for all operating systems that like to gatekeep and insist that you have to be a certain amount of intelligent to ride the ride, and they bemoan things that make using their operating system easier and more streamlined. Because of the way that Linux focuses on the terminal for much of its power and work, with GUI as a second, or maybe third, thought (where, indeed, is the on-screen keyboard?), Linux has developed a reputation for being "techie," and that brings the gatekeepers out to the yard. There are gatekeepers in every fandom, but you'll find more of them in the places where white, straight, men believe that fandom should be their exclusive domain. And in those spaces, you'll find the kind of people who like to measure the sizes of their e-penises and fence with each other for dominance. Unfortunately, those kinds of people are also maintaining software and having opinions about which software is better for the job.
Calling myself a sysadmin is technically true, since I have superuser privileges and access to root accounts on several of the systems that I use regularly, but is another example where the thing that I think qualifies as being a sysadmin is much higher than the puttering that I do. Mostly, I try to keep the systems updated on the regular, and when there are configuration files that are changed, I usually examine them to see what's going on, even if I don't fully grok the changes. I wouldn't know how to do intrusion detection or countermeasures, and while I think I can file a decent enough ticket, I'm not the person who goes in after the ticket is filed to look around and fix the issue. Heck, people in my household know more about the way to set up a network than I do. I learned from them about why it's a good idea to assign static IP addresses to certain points on the network ,rather than trusting that the router would always assign the same device the same IP on release and renew. I run ad-blocking extensions and DNS black-hole software for ads because I don't like them and I don't want them intruding while I'm doing other things, but that's still running other people's code instead of doing packet analysis on the traffic and figuring out how to denylist them. Specialized expertise (and possibly a few certifications) seems to be where I've staked the peg of "real system administrator," which is material that I do not currently want to learn and do not see much need to learn how to do.
Yet, here I am, still typing this on a Chromebook that I converted into a proper Linux laptop after it had reached end-of-life (with other people's code, playing about with the Home Assistant, (which is mostly other people's code, but also has been doing a lot of work to try and make it so that people don't have to dive into Python and YAML and Jinja2 to use the Home Assistant on whatever hardware they want to run it on) and trying to block as many ads as possible from getting to the machines that I surf the Internet with, both as protection against malicious payloads and because most advertisements on the Web are for things I neither want nor need, and they use deceptive patterns and tricks to make their advertisements seem like genuine things, or urgent messages leading to scams. These are the sorts of things I do because I want good hygiene for my devices, and other people have contributed code to the community to make this happen. Sure, there will be people who wag their fingers at me and say that I should audit every piece of code that I run to make sure it's safe before doing so, but that requires programming skills that I don't have, and the ability to either inspect source code or reverse-engineer binaries and decompile them to examine source code. That's not skills that I want to invest time or money in, either, and they would not be very helpful for me in my current profession, plus that doesn't sound like a very exciting job to me. I'd rather play at being some kind of technical wizard with my games and their minigames or their locks to foil, rather than putting in the time and effort to really become one.
Playing these games isn't really teaching me how to, like, code a website and use Javascript that way, but I am learning how to do scripting things for various puzzle-solving activities, or I am learning how to think through problems logically, including those problems that have incomplete information or that require some digging to figure out how to approach and solve them. Or that trial and error is important an that the information you glean from being wrong about something is sometimes just as important as the things you glean from being right about them. Much like library school, I think I'm learning things by doing what I'm doing, both at play and at work, that have broader applications than the contexts I've learned them in, I just haven't been presented with the broader context for some of them.
There are a lot of things where I have some skills in those things, or where I might technically have a title because I'm the person who's doing the work, but most of the time, if you asked me about that title, I'd tell you that I don't have it, because I am not at a tier of skill and ability that I would consider to be deserving of the title. Most of the time, that restriction only applies to me: other people can call themselves whatever they want to, with whatever amount of experience they have in that situation, including now. It might mean I don't trust them to do the things they say they can do, until they demonstrate it, but they can certainly go about calling themselves whatever they'd like. I've been trying to poke at some of them in this series, and see whether or not I think the restrictions still apply, or the title does, and to take the temperature of myself about what I think is the bar for succeeding or considering myself successful at those skills. These introspective looks often find that I have unexamined ideas about what qualifies as being high enough on the bar, and so I often end up needing reality checks from the people around me about what does work. Like "Hey, you're totally a sysadmin, I couldn't keep that many devices juggled," or maybe a "No, on this one, you're right, you're not really a sysadmin, but you're definitely doing plenty of system administration." Whatever the case may be, because I know that my viewpoint is often skewed in one direction and can do with some reality assistance at all times.
27: Sysadmin
Not, like, in any professional way, thank goodness, because it should be painfully obvious at this point that I am, at beset, an amateur who rummages around in other people's scripts and objects to do things. That situation often means that when it comes to troubleshooting my own problems, I'm not always as skilled as I am when troubleshooting other people's problems. I would say that I'm not that great at it, but considering that I do know how to run the update scripts regularly, and I can be a decent hand at the search engines, it's more that if the solution exists, and I can find it, and then understand what it's doing, I can usually fix things, or at least reset them back to a known good state and then try again.
I have certainly spent some amount of time knuckles to elbows deep in systems, trying to get them to unfork themselves, sometimes while in the system, other times through the use of recovery utilities and live-booting Linux systems that can unbollox bad configurations and delete problems. I have soft-bricked GRUB at least twice, not that it's particularly hard to do so, but with the help of the Internet, I managed to find a boot path and then fix the issue so that GRUB would stop complaining about not having found anything to boot, despite the partition being right there. When I was transferring hard drives from one system to another, The Windows install on the hard drive started complaining and not booting. Thankfully, the error message was actually helpful, and the Internet told me that what I was looking at was a driver issue - there were some proprietary drivers installed for one type of video card, and the new machine was using an entirely different type of video card, so there were conflicts, and I had to pull out my install disc to boot to a recovery session, then get to the hard disk in question and delete the offending driver files and then uninstall the program that was providing them. It's stuff like this that makes me appreciate the way that a lot of Linux things are configured in text files and there are package managers that handle most of putting files in their proper places, and those package managers can be used to install, uninstall, and reinstall things if they get off of true. There's still a lot of complexity involved in making sure that dependencies are met and the software will run true, but the people who have made the the package management tools have mostly abstracted that away, to our benefit.
[Slight diversion: There are now things in Linux packaging that are taking things one additional step further and creating standalone executables that contain all of the necessary libraries to work, and in the specific versions that the application was built with, to prevent situations where a system is running libraries taht are either too old or too new for the application. Snaps, Flatpaks, and AppImages try to make Linux computing more like an app store experience, akin to what might be on a phone, tablet, or iProduct, including with centralized app stores and web frontends that then get things installed on a system with a few clicks. The user community appears to be divided about the use of hese kinds of packages, because an item with all of its dependencies is a significantly weightier package than without, and depending on how those packages are managed, that might mean these self-contained applications have several different versions of things running, as opposed to using the system's already-installed libraries and programs to achieve the goal. Self-contained programs have the advantage of running mostly platform-independently, so you can put them on any machine and they'll work, often because they carry with them what the machine that compiled those programs was running at the time of it being compiled.
Some of the objections to those packages include the cruft that comes with them, and how that cruft interferes with a smooth working system or introduces issues of their own from having all of those different programs present and working on a system. (I'm not sure there's quite as strong of objections to Docker and other container programs that generate sandboxes or virtual environments of a sort for programs to run in without necessarily having access to the system running the container, except as what's permitted by the container itself. I don't doubt somehow that Docker containers make things more secure than Snaps, Flatpaks, or AppImages, but there's definitely much more enthusiasm for Docker among the users that I have heard. This leads us into…]
There are definitely some users for all operating systems that like to gatekeep and insist that you have to be a certain amount of intelligent to ride the ride, and they bemoan things that make using their operating system easier and more streamlined. Because of the way that Linux focuses on the terminal for much of its power and work, with GUI as a second, or maybe third, thought (where, indeed, is the on-screen keyboard?), Linux has developed a reputation for being "techie," and that brings the gatekeepers out to the yard. There are gatekeepers in every fandom, but you'll find more of them in the places where white, straight, men believe that fandom should be their exclusive domain. And in those spaces, you'll find the kind of people who like to measure the sizes of their e-penises and fence with each other for dominance. Unfortunately, those kinds of people are also maintaining software and having opinions about which software is better for the job.
Calling myself a sysadmin is technically true, since I have superuser privileges and access to root accounts on several of the systems that I use regularly, but is another example where the thing that I think qualifies as being a sysadmin is much higher than the puttering that I do. Mostly, I try to keep the systems updated on the regular, and when there are configuration files that are changed, I usually examine them to see what's going on, even if I don't fully grok the changes. I wouldn't know how to do intrusion detection or countermeasures, and while I think I can file a decent enough ticket, I'm not the person who goes in after the ticket is filed to look around and fix the issue. Heck, people in my household know more about the way to set up a network than I do. I learned from them about why it's a good idea to assign static IP addresses to certain points on the network ,rather than trusting that the router would always assign the same device the same IP on release and renew. I run ad-blocking extensions and DNS black-hole software for ads because I don't like them and I don't want them intruding while I'm doing other things, but that's still running other people's code instead of doing packet analysis on the traffic and figuring out how to denylist them. Specialized expertise (and possibly a few certifications) seems to be where I've staked the peg of "real system administrator," which is material that I do not currently want to learn and do not see much need to learn how to do.
Yet, here I am, still typing this on a Chromebook that I converted into a proper Linux laptop after it had reached end-of-life (with other people's code, playing about with the Home Assistant, (which is mostly other people's code, but also has been doing a lot of work to try and make it so that people don't have to dive into Python and YAML and Jinja2 to use the Home Assistant on whatever hardware they want to run it on) and trying to block as many ads as possible from getting to the machines that I surf the Internet with, both as protection against malicious payloads and because most advertisements on the Web are for things I neither want nor need, and they use deceptive patterns and tricks to make their advertisements seem like genuine things, or urgent messages leading to scams. These are the sorts of things I do because I want good hygiene for my devices, and other people have contributed code to the community to make this happen. Sure, there will be people who wag their fingers at me and say that I should audit every piece of code that I run to make sure it's safe before doing so, but that requires programming skills that I don't have, and the ability to either inspect source code or reverse-engineer binaries and decompile them to examine source code. That's not skills that I want to invest time or money in, either, and they would not be very helpful for me in my current profession, plus that doesn't sound like a very exciting job to me. I'd rather play at being some kind of technical wizard with my games and their minigames or their locks to foil, rather than putting in the time and effort to really become one.
Playing these games isn't really teaching me how to, like, code a website and use Javascript that way, but I am learning how to do scripting things for various puzzle-solving activities, or I am learning how to think through problems logically, including those problems that have incomplete information or that require some digging to figure out how to approach and solve them. Or that trial and error is important an that the information you glean from being wrong about something is sometimes just as important as the things you glean from being right about them. Much like library school, I think I'm learning things by doing what I'm doing, both at play and at work, that have broader applications than the contexts I've learned them in, I just haven't been presented with the broader context for some of them.
There are a lot of things where I have some skills in those things, or where I might technically have a title because I'm the person who's doing the work, but most of the time, if you asked me about that title, I'd tell you that I don't have it, because I am not at a tier of skill and ability that I would consider to be deserving of the title. Most of the time, that restriction only applies to me: other people can call themselves whatever they want to, with whatever amount of experience they have in that situation, including now. It might mean I don't trust them to do the things they say they can do, until they demonstrate it, but they can certainly go about calling themselves whatever they'd like. I've been trying to poke at some of them in this series, and see whether or not I think the restrictions still apply, or the title does, and to take the temperature of myself about what I think is the bar for succeeding or considering myself successful at those skills. These introspective looks often find that I have unexamined ideas about what qualifies as being high enough on the bar, and so I often end up needing reality checks from the people around me about what does work. Like "Hey, you're totally a sysadmin, I couldn't keep that many devices juggled," or maybe a "No, on this one, you're right, you're not really a sysadmin, but you're definitely doing plenty of system administration." Whatever the case may be, because I know that my viewpoint is often skewed in one direction and can do with some reality assistance at all times.
