It'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.

14: Terminal

Being a child of DOS sometimes gives me an advantage and a bit of comfort whenever a project or a task that I have to do involves the command line. I still love a good Graphical User Interface (GUI), and I firmly believe that most applications these days are well-suited to having a GUI, even if it's basically a visual wrapper for three command line applications dressed in a trenchcoat. Having a GUI makes your application more accessible to the person who does not feel at home running cryptic commands and not understanding what they will do. I especially like the people who provide the GUI in a terminal (a TUI) when it makes the most sense for their application to be run from the command line and manipulated in such a way.

Others extol the terminal and the command line as the superior option for all things, because the terminal runs faster than the GUI does, needs smaller files to produce the same outputs, requires less clicking and typing, and because being able to run a thing from the terminal generally means it can run on a much wider variety of things, instead of being locked to those things that have enough horsepower behind them to run graphical environments.

Still others, the people who get the side-eye, say that the terminal is the superior option for all because it functions as a skill gate. People who cling to their GUIs are still n00bs and lusers who have not demonstrated sufficient computer touchery and geekery to be allowed access to this particular tool, and therefore anyone who wants to use this jewel has to git gud. Snobbery is not a good look on anyone, but technological snobbery can be particularly vicious, and there are more people than we'd like to admit who fall into the third category of "people who don't want the less technical 'polluting' their spaces with demands for things like accessibility or an easier-to-use interface or syntax."

It is a potentially scary thing to type in a command that someone has put on the Internet, or in a script, or to run as an executable, and hope that it doesn't do something awful to your machine. And even scarier when the potential for malice is not embedded in an executable program, but instead a script inside an innocuous-looking document, or even as things that may or may not require someone to do anything before their system is compromised. And unlike many GUI programs, the command line is a place where the assumption is that you know what you're doing when you type the command and press enter. Great power, great responsibility, great potential for disaster. Not everyone necessarily wants to learn how the syntax of the command works, what it does and any tertiary pieces of knowledge that go along with it, like how to construct regular expressions, how to pipe the output from one program as input into another for further manipulation, or how to construct Boolean logic to capture all the possible conditions and find the correct one for the situation. These people are still valid users and they should have access to tools just as much as the people who want to run everything through the terminal.

Some of the most common situations I had for working with the command line as a youngling were, naturally, in pursuit of playing games. As described in the first post, once I left the comforts and constraints of Automenu, I learned how to navigate around in DOS and do things with it. As games progressed and started taking up more and more memory, there had to be some tricks involved to ensure there was enough available memory for the game to successfully run. DOS in those days had what they called "TSR" programs (no relation to the company that developed Dungeons and Dragons) - Terminate and Stay Resident. Most of the time, these TSRs were drivers so that hardware attached to the system would function properly. Others might be ways of taking advantage of greater amounts of system memory, and setting things up for something like bank switching, so that from the "conventional" memory space, you could still address, store, and retrieve things from "high" memory or "upper" memory that wasn't subject to the 640k limitations of "conventional" memory. (The deep dive into how to store and retrieve information from a Game Boy cartridge was intensely fascinating, and also helped me understand a little more about clever solutions used in limited circumstances.) The difficulty with TSRs is that they had to stay in the "conventional" memory space, and while there were all kinds of solutions and methods to access and use the higher memory spaces, many of them relied on there being enough conventional memory space available in the right places to implement their tricks. So, as time went on, while there may have been enough available RAM and processing power to run Sierra family games, the setup wasn't distributed properly to work.

Thus, the boot disk. From the TUI of the game installer, there was always an option of creating a "boot disk." In those days and times, DOS progressed through the various drives available to determine what to boot from, and the floppy disk drives were always assigned letters earlier in the alphabet than hard disk drives., so they would always be earlier in the boot order than the hard disks. By sacrificing a floppy to the installer, it would craft a DOS boot environment where the bare minimum of TSRs would be loaded to make playing the game functional, with the assumption that after using the boot disk to load the correct environment, you'd then proceed through the directory structure to the hard disk and load the game that way. And they worked very well, loading the drivers for keyboard, mouse, sound card, and sometimes the CD drive, as well as the tools needed to access the higher memory blocks. Once I was done gaming, I'd reboot the system so that it could return to normal operations and access to things like Windows. These days, we don't need to fiddle around with such things, even as RAM requirements and availability have grown. And these days it would be something more like a boot image of some sort, a way of loading a specific environment and then booting directly into the game itself. I wonder what kind of game might take that on as their packaging method, trying not to allow installs, even if they might allow for the mounting and running of the image inside some form of container, but otherwise trying to keep the entire thing on the disc image created.

Boot disks were another way of helping me get comfortable with the command line, and with giving me an incomplete understanding of how a computer actually sets itself up to run and produces the environment that the user will be working in. That's all basically abstracted away, and we only see a little bit of it when watching the console output scroll by as my current machines load up. I'm glad of not having to make boot disks any more, and I'm glad that we have more sensible ways of managing memory and startup now, so that people don't have to do arcane things to set themselves up for playing games and running software. Terminal comfort can come from other sources than hacing to rearrange your entire environment just to play a game.

For some time after that, as Windows got better, and then became the way that most games were played, and DOS eventually found its way to emulation, rather than being a major part of everyone's lives, those command line skills didn't pick up a lot of use, although they also never really went away, because, as I was getting older, this somewhat new-fangled object called The World Wide Web had joined the scene (again, telling you more about how old I am than not) and the interconnectedness of computers was now not only possible, but achievable to people who weren't on defense or university networks. The early parts of this interconnectedness relied on a few different protocols to make it all work - HTTP for HTML document transfer, FTP for binary file transfer, there was Gopher around, and a few other protocols. (All of these protocols still exist, although not many people are maintaining FTP servers any more, I suspect, having found it easier, faster, and better on the bandwidth to seed large files through BitTorrent.) ECMAScript/Javascript/Typescript were promising new ways of doing things, and a lot of website addresses at the time had a /cgi-bin/ in their paths, so even at that time, there were attempts to bolt interactivity and responsiveness onto the more static HTTP protocol.

Since I missed the BBS scene entirely, and never had newsreader access, I don't have the experience of dialing in with a modem and using a program to peruse the bulletin boards and the newsgroups - that would come later, with things like phpBB and other implementations of forum software, before we all decamped for our individual blogs and tried to link them together through rings and RSS. What I do have, however, is that there was a…surge? resurgence? rediscovery? of the Multi-User Dungeon and the use of the telnet protocol to connect to such things and interact with them. I won't say I was any good at any of them at all, and a friend of mine wanted to have me build some things for their own MUD, but I didn't get very involved with that, and so I didn't contribute all that much to it, either. I could have possibly learned a few things about scripting and other such things if I had persisted with the building aspect of it, but I didn't have the time nor the always-available Internet connection, to do most of my building and scripting work with. A more involved me might have instead grabbed the ability to run a local server on a non-Internet-connected machine and put together all of the things that needed doing to make it work, before uploading all of that to the live instance when I had an Internet connection. Which very well may have required either exporting in some way or retyping everything that I did in the local copy onto the non-local copy.

As it is, I entered university days with some amount of telnet experience with the MUDs, and a little more from having used the earliest form of using computers to make requests from other locations in the library system. (With the added bonus of being able to use that same system to look up and make requests from home, instead of having to be at the library to do so.) This made me particularly well-suited to using whatever computers were handy to do things like work on assignments, check e-mail, and do the occasional bit of socializing or other such between classes. While the university provided us with a disc of useful programs to put on our personal computers in the dormitories, or off-campus, I don't remember how many, if any, of the machines that were in the shared computing labs had those same programs present. As a further not-really-complication, since most students were comfortable with Windows machines, that usually meant the available machines were on the Macintosh side of the lab. As someone who could get things done in both of those environments, it mostly meant that I was on the Mac side of the lab instead of the Windows side. (Even more so in graduate school, as the Macs had a good text editor with syntax highlighting that I could use when I was away from my own Linux machine and its syntax highlighting.) The University e-mail system had a command-line interface and interaction point, and I think that was accessed by telnet as well. (What I remember much more clearly about it was that all of the servers we could connect to were identified as being arcade games. While we used a single point of entry to connect, the server we were assigned at random always was a classic arcade game. Zaxxon, Xevious, Pac-man (and Ms. Pac-Man), Asteroids, Battlezone, etc. I liked being able to get the reference and wondered which game I would be working with every time I signed in.) Pine was the system, I remember that, and it was a perfectly serviceable TUI to check, manage, and respond quickly to various e-mails that had been sent out and I was looking at in the time between classes, or when I was in the lab. I felt smart and technologically awesome that I was able to use the terminal for this kind of purpose, and to do it well. And, yes, I did feel a little smug and superior that I could do this on whichever machine was available, instead of having to wait for a specific machine to come available or to trek to a specific laboratory where those machines were available. My university-aged self is still unlearning things as much as they are learning things, and so I have to treat them with patience and understanding.

So when it comes to the terminal and the command line, I have decades of experience in using it, in having things blow up in my face, in having to use it because various utilities, servers, and tools run best (or at all) from terminal, and in using it because I want to see what a piece of software does, and whether I can get things to go faster from there than from other methods. I'd say that comfort with the command line is a second-order comfort when it comes to computers, because you can't really get comfortable with a command line until you are properly comfortable with the machine itself, and feeling competent and curious enough to try things, have them explode, recover from them, and otherwise recognize that many things that wreck a computer can be recovered from, although what form the recovery takes is different depending on how big of an explosion happened, and that most systems with a GUI will ask if you're sure before they do something destructive. This is the kind of thing that a spare machine is perfect for, because spare machines are what you do things that are destructive or explosive on, and then when they do explode or do unwanted things, you have gained knowledge about what to do or what not to do, or that the thing you tried to do was not properly formed, even if it was accepted as valid. Sometimes you discover some really cool things you can do and then take that knowledge back to the main machine to make it run better and more according to your needs.

Once you have the willingness to experiment and see what happens, and the knowledge backstopping you that you can get out of most common bad situations, and perhaps even the knowledge of how to reconstruct a system from scratch and start again, then you can start getting more comfortable on the command line and using the terminal when it seems appropriate or useful to do so. Because, again, many terminal commands don't ask if you're sure, they just do what you told them to do. (More of them probably should ask, but most of the core utilities and commands on any operating system were developed and used by people who did know what they were doing, and they probably found it annoying to have to confirm it every time they wanted to do something. For Linux specifically, even though many distributions of Linux are better about not requiring the use of the terminal or the command line, there's still a certain assumption baked in that the terminal is the real heart of using Linux, and everything else is eye candy, abstraction, or concession made to those who don't want to do everything from the terminal. The terminal-centric focus of Linux makes it both very powerful and very portable, since the terminal itself, and the core utilities don't require a lot of fancy anything to work, and can be put in embedded or underpowered systems to provide functionality and flexibility to their operation. Terminal commands and abilities are also part of creating scripts and programs that will chain together commands to produce useful output, which is the part where the possibilities expand outward exponentially.

I'm trying not to make the terminal sound completely intimidating, and that you need all the time and experience that I have with it to produce useful things and be comfortable with it. But especially in Linux systems, grasping the terminal and what you can do with it is almost a prerequisite for unlocking the full potential of such a system. And I don't fully know everything that I can do with the terminal, because I haven't had to learn it yet, so you don't have to know everything and read all the man pages before you can start using and experimenting with it. I do think, though, that having grown up in an era where the command line was the primary method of accessing programs and using the computer has made it easier for me to re-adopt a terminal, now that I've chosen an operating system that relies on it. I'd still rather that people took the time to put in interfaces and help for people when they release programs to users, or that, if it makes sense, they build a GUI component for their program so that it's more widely accessible, but that is not always the case.

I guess the point is to say that computer touchery does not have to involve terminals and text editors, and that there are several fine programs that require neither to run admirably and well. And that for as much as I have experience with it, there's still plenty that I don't know and may never know. It's one of the places where I can have a growth mindset about myself, and I think it's one of the places where others can, as well, so I'd encourage you to dive in, in whatever way that you can. There will be gatekeeping jerks, there will be unhelpful StackOverflow answers, and sometimes the thing that's the best and most useful response for you will be a blog post from decades ago, but there is a certain satisfaction, at least for me, that comes from accomplishing a task through clever program use or even writing the script yourself and seeing the output that you wanted to have happen scroll by in the console. I am unlikely to claim that I'm good at any of this, but I could venture forth that I am at least semi-competent.

It'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.

00: Fool

The Fool, in all his forms, represents unlimited potential. The Major Arcana places him at 0, the number that requires some other number than itself to provide the context of what zero means. Zero is cyclical, and represents both start and end of journey at the same time, ready to embark upon new adventure and learn, and returning and integrating what has been gathered so that the next loop goes with more information and knowledge. Zero is the first index value, which is a thing you have to learn and remember when working with computers. Humans generally start from one when they count, because zero holds no intrinsic value to them. (Zero is actually a fairly abstract mathematical concept, despite being crucial to most operations. I think its only rival for importance and many-faceted-ness in mathematics is one.)

Unlimited potential describes infants and children very well, since their brains are in their most plastic states, learning and absorbing the world, language, society, and how to operate their bodies in space at a phenomenal rate. Eventually, that learning rate tapers off as decisions get made about what to practice and obtain skill in, sacrificing plasticity for efficiency, but it never goes away entirely. We get all kinds of "human-interest" stories in the media about someone of a somewhat advanced age picking up and obtaining great skill in a discipline that they had no knowledge or practice in not that long ago. The entire system of athletics, whether for Olympic prizes or lucrative sport contracts, starts very young and demands both skill and discipline to rise in ranks where someone might challenge for those same athlons. And in other tracks, we see stories all about smart people doing smart things (and a fair number of stories about smart people doing things they believe are smart, but have consequences that are clear and obvious to people outside of their specific discipline.)

Carol Dweck, in the early 2000s, published a book called Mindset: The New Psychology of Success that introduced to us two new concepts to work with: a fixed mindset, where someone believes their intelligence is finite and there is no way of developing it further, and a growth mindset, one that believes there is development potential skills, abilities, and intelligence. This became simplified in the popular parlance and spawned a fair number of ideas about how to keep people, and especially children, out of the fixed mindset, usually centering around the idea of praising students for the effort they've put into their work rather than suggesting that they lack smarts or other fixed qualities that would make them good at things like schoolwork and the various subjects. Dweck came back to revisit these ideas with clarifications and to squash the idea that effort was the only quality that was praiseworthy in helping someone develop a growth mindset in a 2015 Education Week article. And to say that most people have a mix of fixed and growth mindsets about their skills, abilities, and applications of intelligence.

I'll say that mathematics is one of the spots where there's the easiest contrasts of fixed and growth mindsets, although there's some confounding coming from xkcd 385 that contributes to some students being steered heavily toward fixed mindsets. I mostly mention this in the context that I didn't hit my math wall until integral calculus, where I didn't fully understand how I was supposed to go about transforming an equation into forms that I could apply rules to by using the various exotic and trigonometric properties of one, as well as the occasional shuffling of various components to one side of the equation or other so that I could, again, put things into forms where rules could be applied. This makes a little more sense, because geometric proofs were the thing I disliked the most because of the way they made me go through logic and fill out what I knew from what was provided. Despite the fact that I like playing games and solving puzzles, which is the same kinds of things, just with different visuals.

But until that, and with a fair number of other subjects, I was cruising with absorption of knowledge and doing well on tests, and all was well, at least in the realms that can be measured and quantified. My second grade teacher thought I might have a learning disability, because she never saw me do work in class. She saw that the work was good and done well, but she never saw me go to work on the worksheet and finish it while she was explaining and demonstrating the concepts and procedures on the board, such that I was done and quietly reading by the time she turned back around to give us time to work on our sheets. The tests came back that my weak spot was at least one grade level above my current space, and the opportunity to pick up that I did have something affecting me was lost, because that's not what was being tested. They wouldn't have diagnosed me then, anyway, because I presented atypically for my gender presentation at the time, and there wasn't any reason to test for it. These days, I think that if someone comes back as some sort of savant or "gifted" student, you should run them through a battery to see if they have any accompanying neurospice that could cause them great grief in their future.

This ease at things that others considered difficult meant painful emotional experiences when the perfect child turned out to be human after all. And I also had at least one physical altercation in my life because I saw something as simple that someone else found difficult, and they didn't like my attitude about it. (I'm not surprised that I would have come across as arrogant about it or similar. I wasn't intending to do it that way, but I'm definitely a poster child for "What I intend and how it's received are two different things, and I'm not great at accepting that it was received differently than I intended it to be.") It makes me sensitive to the disappointment of others, and it also makes me want to avoid situations of consequence or importance, because if it's important and I fail, then the fallout is both deserved and all my fault, regardless of how the failure happened, and someone will be by to punish me for failing soon.

Dweck is trying to encourage instructors and people who are working with others to adopt the idea of the growth mindset and try to foster it in others. Not just a matter of changing feedback so that it focuses on qualities and items that can be improved or the effort put into the situation (and avoiding feedback that references fixed or intrinsic qualities like "smart"), but also providing the scaffolding and feedback that allows for growth and learning, so that the skill can be not only practiced, but practiced correctly and well. It's not enough to praise effort if the answers are still coming out wrong and there's no understanding of what's going on and where the mistakes themselves are coming from. Humans are capable of learning and doing all kinds of things, many of them remarkably complex. Instruction and repetition and refinement are generally the ways that this works, and if we're going to require all of our small humans to go to school for twelve-thirteen years of their lives, we may as well make the environment as rich in opportunities to grow as we can. (There is an entire separate post here about the ways many educational systems provide the exact opposite of this growth-rich environment, and not all of it is the fault of the instructor and the feedback they give.) While that sometimes gets tritely summed up as "Whether you think you can, or you think you can't, you're right," that reduction makes it seem much more like it's a matter of willpower rather than one of opportunity.

Many of the creative arts, and several of the scientific ones, are less about people of great inherent talent having an inspired burst and then created a masterpiece out of whole cloth using nothing more than their raw talent. Musicians rehearse, writers compose, artists have references and practice works, dancers and athletes train and practice. The skill-taste gap is real, and while some things may be easier to pick up than others, the actual limitations of the brain and body are about whether the brain can translate verbal or demonstrative instructions into body movements, and whether the body in question can perform those movements at the desired level of skill and speed. Where I think a lot of our childhood pathways fail us is that we get told early on to focus on what we're good on, and our feedback tends to be in that form. The point of the schooling system (and the university system beyond that) is to get us in a state where we can perform labor for wage, unless we are one of the lucky few capitalists where we have enough for ourselves and our work is instead making others perform labor for us for wages. Creative arts and other such pursuits might be where our desire lies, but the necessities of not starving often prevent us from fully exploring those arts and pursuits, or they twist it into something that is used for not starving instead of for exploration, practice, and attempting to grasp a little of the numinous. The messaging about doing what you do well, combined with the artificial scarcity of capitalism, can often put us in fixed mindsets about creative arts, because the standard warps from "will doing this make me feel like a fulfilled and whole human being?" to "can I do this well enough for other people to give me money so I don't starve?"

The Fool and the concept of Beginner's Mind are intertwined with each other. Approaching any situation, including existing in a body of matter, with the curiosity of someone who doesn't know anything about the situation, but is interested in learning about it, or observing it and letting it move on, is to approach something with the greatest potential for growth. By shedding as many preconceptions as possible about the thing being approached, the full realm of possibility opens up before you. Admittedly, sometimes conceptions of things come with experience, and that's useful to bring in. Not approaching something with an expectation of how it will turn out, but being prepared in case it does go a way that you have experienced before. Zen, and its famed koans, and much of the practice of it revels in contradiction. Practicing meditation is so that you can get to where you already are. Sitting and observing the world as it goes by, without chasing after any one thing, lets the mind realize the impermanence of all things, the great constructions that take place within our very selves. Knowing about it makes it easier to jettison the whole thing and to practice approaching each moment of life as it is, rather than what it will be, or what it was, and without the structure of preconceptions clouding reality. It always seems impossible until it is done, and Zen tends to work toward the sharp flash of insight when it stops being a theoretical and starts being a practical. In response to another person saying they wanted to become a monk to "deepen their practice," a monk starts laughing and says the person seeking to become a monk already is one, and that there is no deeper to the practice of Zen, just the one level. The one, seemingly-impossible-until-insight level.

We see breakthroughs like this happen all the time with small ones and ourselves. It doesn't make sense, it doesn't make sense, it doesn't make sense, and then it does. With enough time, practice, and instruction, some things that were thought to be limits aren't, and it's not that the person is stupid, it's that they didn't have the right frame to work with. Or not enough opportunity to practice and refine. Or a low-stakes situation where they could get over the anxiety about it needing to be perfect or sale-worthy and instead focus on doing the actual practice.

There are going to be limits, where some things just won't happen, or be comprehensible, no matter how much good instruction and practice we get. I suspect, however, that most people don't actually reach their true limits on most things in their lives, because they don't get the opportunity to see where those true limits are. Many of the stories that appear in this and other series where I talk about myself are stories where I thought I wasn't "good at" something, but I could practice it and approach it in a Fool-ish way, and now it's (marginally) better than it was before. Because of the experiences my brain has had around praise and punishment, saying I have expertise in things is unlikely, but demonstrating that I have it is routine. And it's tempting to have a fixed mindset about things that are difficult, because I spent so much of my life with things that were not difficult to me. Letting myself overgeneralize into the belief that I used all my skill points on these things and there are none left over for anything else is an easier thing to believe, rather than it being a matter of time and practice. You'd think that being an information professional, where the formal training you go through is much more about learning underlying concepts and methods that then get put to use in specific situations, would make it easier for me to recognize and dismiss the fixed mindset, but, alas, brains. The best I can do is continue to be a Fool when I recognize the need for it.

It'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.

12: George

I call it a habit of mine that I can make outdated hardware do things it may or may not have ever intended to do. "I" is not quite right in this statement, because much like how my cooking is following recipe and then being surprised that it turns out delicious, much of my computer touchery is following recipe that others have developed, and occasionally deviating from it if I need to for troubleshooting, or to mess about in the thing that the original creator said could be messed with or customized to meet the needs of the person using the software.

Much of the confidence and practice I have with computer touchery comes from having had a machine to experiment on, one specifically designated as the one that if things explode, I can reset back to a working state and then go forward from there. I don't actually want to have to do that kind of thing, because resetting an exploded machine usually means losing progress or having save files get nuked that I want to preserve, but there is a certain amount of risk affordance you can put on your spare machine that your main machine won't get. Spare machines are the best kinds of machines, usually put together from spare parts, or specific small parts that have been purchased to swap out from one thing to another. They're great for people who want to experiment or to learn how to assemble their own machines, or who want to try some other operating system. Everyone should have a spare machine somewhere along the way, preferably one they've assembled or that they've changed some components on, but single-board machines and spare phones are also ways of doing some amount of experimentation, even if you can't change their components quite so easily.

Spare machines are great for working through problems that arise when you do things. Like when I finally saved up enough money to purchase a 3dfx Voodoo2 3D rendering card. I thought I was going to be blazing hard through various games now, with my relatively unimpressive machine (it barely met the specs for Final Fantasy VIII!), but after I'd dropped it in, and tried to boot up my machine, having hooked it all up, the motherboard beeped at me and refused to boot. After a certain amount of troubleshooting, I finally figured out the thing that hadn't been obvious to me at the start: the 3dfx card was a companion to the video card I already had installed, and that other port on the 3dfx card wasn't for show - I needed a specific cable to take the output from my video card and feed it into the 3dfx card, and then after they'd daisy-chained their way merrily through the requirements, they gave me the output I desired. Which made Final Fantasy VIII playable. (And then I would have a bit of a time with the game wondering why I was seeing things like "B6" during Zell's Limit Break instead of the keyboard controls I wanted. Eventually I figured out that I needed to unplug the gamepad that I had connected to the machine and that it was detecting and assuming that I was playing the game on the gamepad primarily. This was back when discrete sound cards were a part of your rig, and they often also had a port on them for gamepad input.)

So I've done a lot with spare machines, tinkering, experimenting, and trying things with them that I wouldn't do to the "family computer" and that I wouldn't do to my work computer. My "spare" machines have proliferated in my adult life, as I continue to move things around and new machines enter my life. But also, so have my appliance machines. Instead of a full tower desktop running in the bedroom, I have a singe-board machine there. Much quieter and less of a power draw, still does all the desktop environment things I want (as well as some other things, like allowing me to remotely control the TV it's attached to, the one without a working IR receiver.) I definitely had a second machine for much of my time in the bad relationship, and for a time, I used a cell phone dock and some nice cabling to turn a single-board machine in to much more of a laptop. It could at least run XChat at a few other things at the time. A secondhand Surface I'd gotten from someone served as my "work" machine during the shutdown, before receiving an official work laptop. (That Surface eventually suffered from the batteries trying to burst forth from the casing and had to be retired, but we salvaged the SSD from it for purposes.) And I kept two desktops working side-by-side as soon as I reclaimed my house, so that one machine could be used for media purposes and Windows stuff, and the other could be used for Linux purposes and handling all the things I was doing with Android phones and other things where it turns out to be easier to do things from a terminal on a Linux box than it is in Windows. And since nothing "vital" was on the Linux box, I could experiment with it, change distributions, and otherwise use it as the spare that it was. This combined with the experience I had from using Linux as a driver since graduate school to make me comfortable enough to use Linux as the driver on my main machine as well. Something that started because one of my classes meant learning a little Ruby on Rails, and it's way easier to run a local Rails server from Linux than Windows. My main machine has now come around to being a machine that I can watch streams on, game on (all hail Proton), and otherwise continue to give life to by running a Linux on it. Since I wanted a machine that I could buy and hold as much as possible, instead of thinking I needed to change it from one thing to the next, this pleases me greatly.

After purchasing my first phone with an aftermarket OS on it, I have basically been doing the same thing to every phone I've owned since, especially because those phones would otherwise have reached the limit of their manufacturer OS updates, and instead, I can merrily roll along on old hardware until the things physically give out themselves. They do sometimes complain when I try to do things like play Pokemon Go on them, but it's fine. And by the time I have to be in the market for a new phone again, so many of the flagships of a previous time will have come down in price to the point where I might consider them, or consider asking for them as holiday gifts from people who like to spend money on me, despite my clear failures at capitalism.

So as a cheapskate with regard to technology, it's always nice when I can take the old things and make them run smoothly and swiftly with new software or by respecting their limitations enough to not tax them with software that's not suited to them. (One of my next projects, whenever I have actual need to do so, is to do some exploration of software that can be run from the terminal, so that my spare Model B won't feel left out from the fun and can contribute to some important part of house functions.) That cheapskate nature meant that when I got to examine the original model of Chromebook, and was told that I could do what I wanted with it, since the original model Chromebook stopped receiving updates at Chrome 65, I consulted the Internet, and while there wasn't much information available, there was a website that was dedicated to the prospect of converting such a Chromebook into a fully-fledged Linux machine by replacing the firmware on it with a specific kind of compatible BIOS, and then from there making it possible to put a Linux on it. (It's a very nice machine, actually - 64-bit, a couple gigabytes of RAM, and a 5GHz-compatible network card internally.) Well, I should say the website existed at some point in time, but didn't actually do so at the moment I set my mind to it. Thankfully, the Internet Archive had crawled the entire thing, and I could download it into a zip file, giving me the opportunity to follow the instructions and examine the pictures. I was initially stymied by the first instruction of turning the developer switch on, because I couldn't see a developer switch in the spot where the pictures said it was, but once I discovered that it was behind a small bit of electrical tape, we were ready to go. (That piece of electrical tape would come in handy later, as the thing that was used to disable the write protection on the firmware on the laptop.)

Again, low stakes project, no worries if things didn't go according to plan, because it was otherwise not being used, and great potential for use if it succeeds. Which it did! I followed the recipe exactly as the website archive instructed, got the new BIOS in it, and then put a Chromebook-related Linux on it, boggling the developers of it, because their Linux was not meant for a Chromebook that old. They weren't even sure it would run on it, despite me showing up with such a thing. Eventually, I scrapped that project, since it hadn't updated in a very long time, and instead went with the distribution that was powering one of the "spare" work machines that had been designed with Windows XP in mind and had fallen out of use as a mobile reference tool. I had been using those machines for all kinds of shenanigans and other material that official machines were not being used for, and they have served me well, even if only one of the original pair survives.

That Chromebook still runs BunsenLabs, and does so wonderfully. So long as I don't try to tax it too hard by running too many tabs on it, it rewards me with snappiness and speed, and most importantly, a system that can be updated and kept patched against security vulnerabilities. (When the second of the pair of netbooks finally refuses to boot, this Chromebook will likely take its place as machine-outside-of-boundaries.) And having done it once, when I was alerted to the possibility of getting another Chromebook of a later parlance for a little bit of nothing and doing the same thing to it, I jumped at the chance, and with a similar sort of process, and using some scripts developed by others, I now have a compact and useful Linux laptop that I do a lot of composition on, and that I can take with me to events like the local GNU/Linux conference so I can do interactive bits, or run programs, or just hang out in the chat rooms and post on social media my running commentaries about the sessions that I'm listening to. I've also used it as a presentation machine for such things, when I'm the one doing the presenting instead of listening. After trying to run a form of Arch on this Chromebook, and eventually running into the problem of install creep and strict size limitations (as well as the nasty tendency for it to hard freeze at some point when it ran out of memory and swap), I put BunsenLabs on it during this last update cycle, and it's much happier with me and seems to function better. We'll see what happens when BunsenLabs finally makes the jump to a Trixie base instead of a Bookworm one, but I feel pretty confident I'll be able to get all of that to work, and it'll be nice to have old hardware running modern systems.

I'm doing this because of the work that other people have done to port boot systems to Chromebooks and other machines, and to automate the process of installing things to the right places, and the people who build and maintain the packages and the installers so that all I have to do is download the image, run it, install, and then run the update commands on first boot to get to a system that's ready to work. It doesn't feel like computer touchery to do this, because it's just using other people's stuff, but there's the tale of knowing where to make the chalk mark as one side of it, and the other being whatever arguments you want to bring to bear about how "not invented here" is terrible as a practice, and therefore if someone else has created the thing that you want to use, use the thing they've created and spare yourself the turmoil. (Or, in my case, use the thing because you couldn't create it yourself anyway, and be grateful to the people who are using their time and knowledge to make it so that you can do this thing.) Doing things in userspace is still valid, and as an information professional, a lot of my skills are in finding and surfacing the thing that will be useful for the situation, rather than in trying to create the thing completely from scratch, or in trying to get the person I'm helping to do the same. The world is too large and complex for any one person to understand, or even to necessarily understand the entirety of their discipline, and so it should not be a mark of shame to rely on the work of others and to trust that their work will be accurate and not malicious. (It just makes me feel much more like a script kiddie playing in the kiddie pool instead of a Real True Technologist, even if this is another one of those situations where if you press me on the matter and start making me tell stories and explain myself and solve problems, the claims I'm making look flimsier and flimsier, a fig leaf of modesty because I'm still afraid of the reaper looking for tall flowers.)

There's a lot that I have done, and that I can and should justly consider as achievements and Cool Things. Doing things like December Days and the Snowflake / Sunshine Challenges and other such writing prompts are my way of indirectly getting at those and showing them to others. If I came out and said it directly, I'd be worried about it sounding like boasting or penis size comparison, and someone else would come along to put me in my place. But if I'm talking about how there's a wealth of software and instructions out there to extend the life of old technology, and I'm a cheapskate who's willing to invest the time in following those instructions and prolonging the life of that old technology, it doesn't sound like I'm boasting about anything other than getting some extra cycles out of my machines, and that is something I can safely be proud of. (Why? It's not saying I have any particular skills or capacities, just that I know where to look and how to follow recipes.) Indirectness is one of the best ways to get me to show you my actual potential and abilities, and I can do it to myself just as well as anyone. Full understanding may need a little bit of either reading between the lines or knowing me well enough to see what I'm doing, or to ask the right question that makes me squirm or tell stories. (Please do.)