fsr help

 all because the gemhost disallows requests from http proxies

### software if we could design and fabricate our own hardware we could more or less do away with software, but its much easier and more flexible this way. the reason i make this statement is to point out that in the future, it will hopefully be easy enough to design and fabricate hardware that all of the things we hate the most about software will be things we have to consider in hardware implementation. a good example of this is keyloggers. while a keylogger that reports what you type to a 3rd party is generally software that you dont want, theres not much stopping a hardware manufacturer from adding a circuit that does the same thing and hijacking your network device to send that as encrypted data to whatever party they want. the cost might make it less than worthwhile, but if for example a state entity wanted to pay for it to be implemented it could even be profitable. which isnt said to seed paranoia, but hardware is much more flexible than people realise. i say this as someone who enjoys working with software more- or at least, used to enjoy more. its difficult to love working with software when every single piece of it is now developed on a platform owned and operated by a company you have passionately hated for decades. you can make your own software, but youre most likely going to be using programming languages and libraries that now participate in the largest monopoly on software in the history of computing. so that kind of sucks. but what sucks even more is the sheer apathy people seem to have towards this fact. we can talk about freedom with regards to software, but if you put software on my computer and i cant remove it and you laugh because you and your cronies have the upper hand, the license doesnt make me feel very free. i didnt spend years moving away from proprietary things, just to have the proprietary nature of them simulated with freely-licensed software. it used to be a LOT easier to remove what you didnt want and keep what you did. so whenever possible, i just stopped using operating systems that are now based on eliminating that option. you go ahead and sell out, ill go somewhere that hasnt. but lets start with the basics here, and say that there are (to the best of my knowledge) AT MOST, FOUR places where your operating system(s) reside. at least until further notice. this is stretching the concept of what constitutes "your operating system" because your operating system is on your hard drive, emmc or other boot media like a cd or usb drive or external. but you can more or less implement an operating system in uefi, and uefi is on your firmware so lets include your firmware- at least theoretically. whats more is that your cpu very likely has a core dedicated to some kind of nonsense and thats running minix, and i dont know where it PUTS minix but its either in the firmware or the core itself, so theoretically lets include your cpu. and finally, if you have a phone you have two operating systems, the user-facing os and the proprietary gsm stack, so by my count thats FOUR places your operating system(s) might (collectively) be located: 1. the boot media / installation 2. the firmware 3. possibly the cpu itself? 4. the gsm stack (if applicable- im sure theres an equivalent for cdma) most people will find the boot media / installation is the only operating system they can do anything about. as for the idea of minix being on the cpu, its probably in the firmware and MOST of it can be disabled from the firmware. but its insidious. anyway for the purpose of this chapter, being able to remove the operating system refers to the boot media or installation- the installed, primary, user-facing operating system. if only because its much easier to do on average. ive done this on a mac with efi, ive done it on many types of pc that shipped with windows installations, i may have even done this on a tablet using an install image on a microsd card. i dont know if lain has ever done this or not, because her earlier navis ran copland os and her later equipment may have also run copland. although the os with that name in the show is clearly fictional, copland was a real os made by apple in the 90s but never released. we are never given details as to whether lain has ever installed an operating system. i think its extremely plausible, but it isnt known and it isnt required. i have deliberately left out spoilers from later episodes, so there may be a great point to make about that but if i made it then it would be a huge spoiler. a side point we could make is that if all your computers are on a big network and all your computers are compatible with the image, its possible to just network boot. this isnt something i have any real ambition of doing personally, but it technically means lain could keep getting equipment without any operating system installed at all and just get her os (even copland) from the wired when she turns the equipment on. this doesnt seem terribly plausible to me, or terribly practical, but its possible. installing an operating system always means placing a system on or in a computer where it can see it and boot from it. the firmware sees the installed os and loads it. more specifically though, the firmware sees the storage device and the bootloader software, and loads that. the bootloader hands the machine over to the operating system. the most common way to install an os is to write the installer (or the live) boot image to a medium, then start the computer with that second medium instead of the drive and operating system that was already there. its often possible (and sometimes necessary, if you cant get a machine to boot from your other media) to remove the drive with the existing os, install to it from ANOTHER machine and the place the drive back in the machine that normally uses it. for example, if you were to physically remove all your usb ports (i dont know why, but lets say you did) and you wanted or needed to install an operating system from usb, the easiest way to do that would probably be to use a second computer and then move the drive back to the first one. there are more common reasons to have trouble installing from the computer youre installing to, but this scenario technically demonstrates the solution. operating system live images are a lot of fun. i used to automate grabbing an existing distro image, mounting or uncompressing the iso and then the filesystem on it, stripping out what i didnt want to save space or adjust it to other preferences, then put it all back together and make a new iso and used a tool to make it a hybrid image so it could also be written to usb. it wouldve been incredibly tedious to do this with python or a pure shell script, but it was easiest to do with a mix of python and shell code and other code i developed myself to sort of glue that together. all in a single script of course, so instead of uploading and then downloading (hosting or distributing) an entire image each time a change was made, you had the alternative of simply distributing the script which was MUCH smaller (and plaintext) and gave you a line by line receipt of every single change made to a more established and mainstream distro image. i basically continued doing this until i moved to openbsd. as far as i know, the bootloader loads the kernel of the operating system and the kernel loads the system image with all the other things it needs. i believe this is true of many systems at least and many installers and live images, but i dont know if its true of every os that installs to the drive and particularly an openbsd installation. the alternative would be just getting everything from the partition. but any partition that cant be handled natively by the kernel would require the additional kernel modules to be loaded from somewhere. linux at least, can dynamically load (and unload) modules that add capabilities to the kernel without rebooting. openbsd doesnt do that- if you want a module in the kernel, it needs to be in the kernel. but the initrd that accompanies the linux kernel doesnt only include kernel modules. initrd is short for "initial ramdisk". early on, control is handed to the init system (the init system in openbsd is called rc.d, which is the name of more than one init system as far as i know but rc.d in openbsd is my favourite init system for its very user-respecting and deliberately unassuming design specs) which runs all the various software that needs to be running for the system to be considered "ready" for you to make use of it. typically the init will load shells, and it will typically run shell logins. it will also load a graphical subsystem (the one in openbsd is xenocara, a fork of x11) or more likely a "display manager" (such as xenodm) which runs the graphical subsystem. wayland is a newer option that some software likes to have as a requirement, but i tend to think of it very much like this person from the netbsd foundation: => https://blog.netbsd.org/tnf/entry/wayland_on_netbsd_trials_and theo de raadt, the founder of openbsd was also a netbsd developer, and seems to also have feelings about wayland that dovetail with those of nia alarie. but mostly i dont want software to turn into a giant corporate blob, thats exactly what i worked for years to get away from. you may love wayland and you very likely have the option of running it, but its pretty demanding and not necessarily trivial to support from every platform. either way i prefer the option of not running it. when i have reason to suspect developers are trying to remove that option, i stay as clear of their wares as possible. sadly, or happily, that eventually got me away from the linux kernel itself. not that the linux kernel implemented any of these things i dont like, but there dont seem to be many viable or desireable ways to run the kernel without them. at least none that are up to my standards. with literally hundreds of actively developed distros, i did a fair bit of research over a number of years (and a fair bit of automated distro remastering) to rule out the possibility. besides, the only reason i wasnt already running openbsd is i didnt think it would be easy enough. whether you prefer xenocara or want to use wayland, and whether or not you use the linux kernel, your graphical subsystem will enable a variety of graphical shells- but these are generally referred to as window managers or desktop environments. a window manager is a piece of software that lets you open and move and maybe hide and unhide windows, and the choice can be an incredibly lightweight piece of software if you want. a desktop environment is typically a suite of tools, often including a choice of (one or more) window manager to suit your preferences and/or the preferences of the developer and this suite can add a lot more bloat than simply a window manager- but theres no law against a desktop environment being lightweight. i used to quite like desktop environments, particularly as a recommendation to others but sometimes even for my own use. most window managers are developed on github or, require wayland, otherwise i would name a few. openbsd comes with an atrocity called fvwm that i am obviously not terribly fond of, but i typically disable it by simply copying my preferred wm directly to /usr/X11R6/bin/fvwm. it will complain that the file is in use, you have to rm /usr/X11R6/bin/fvwm first. this method doesnt work with every single wm, but its easier to remember than properly setting the default wm in xenocara. it is possible to run a launcher thats separate from your wm, though many desktop environments include one of their own. im accustomed to starting programs only from a keyboard shortcut, or from the term window or similar shell (which is one of the keyboard shortcuts) and adding other features to the desktop would just be a distraction. for others (and in the past, for me) it could be a nice thing to have. there are analogues of most of these things in mac os and windows also. windows has gone from being a hideous atrocity to a dystopian nightmare, and i have nothing more to say about it. ive probably said everything i want to say about mac os too, but i dont consider it quite as much of a horror as what windows has become. at least, not in the same way. mostly im saying that overall, and whatever theyre called, youll find most of these concepts exist across platforms. described generally as "software", we have outlined a working system that is more modular than most things that support the linux kernel. we also talked about distros that do support it, which are similar in many ways. these are more or less the components that run and manage applications. they also run and manage small utilities, though the small utilities could possibly be classified as applications. in practice theyre a bit like that but theyre also support for things like that. these things can be discussed in another chapter: => applications.html applications => https://fsrhelp.envs.net/ (back to the main page) => https://portal.mozz.us/gemini/fsrhelp.envs.net/ (it wouldve been cooler to do it this way instead) license: 0-clause bsd ``` # 2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025, 2026 # # Permission to use, copy, modify, and/or distribute this software for any # purpose with or without fee is hereby granted. # # THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES # WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF # MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR # ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES # WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN # ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF # OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ```