If you've found yourself stuck on an End-of-Life (EOL) Ubuntu release like 23.04, you might have encountered frustrating errors when trying to upgrade to newer versions. While the standard do-release-upgrade command typically handles upgrades smoothly, it won't work once your release has reached EOL status. Don't worry though - there's still a way to upgrade without reinstalling your system!

The Problem

When trying to upgrade an EOL release, you might see errors like:

An upgrade from 'lunar' to 'noble' is not supported.

Or when using the development flag:

Upgrades to the development release are only available from the latest supported release.

Let's Fix It!

0. First, back up your data! While this process is generally safe, it's always wise to have backups before any major system upgrade.
1. Create a new directory and download the version-specific upgrader. For an upgrade to 23.10 (Mantic), use:

   mkdir upgrader
   cd upgrader
   wget http://old-releases.ubuntu.com/ubuntu/dists/mantic-updates/main/dist-upgrader-all/current/mantic.tar.gz

2. Extract and run the upgrader:

   tar -xaf mantic.tar.gz
   sudo ./mantic

   Note: If the upgrade fails, don't give up immediately! Some users have reported success after multiple attempts - in one case, it mysteriously worked on the fifth try. This might be due to temporary network issues or repository status changes.

Common Issues and Solutions

If you're getting 404 errors, you'll need to update your sources to use the old-releases repository:

sudo cp /etc/apt/sources.list /etc/apt/sources.list.backup
sudo sed -i 's/archive.ubuntu.com/old-releases.ubuntu.com/g' /etc/apt/sources.list
sudo sed -i 's/security.ubuntu.com/old-releases.ubuntu.com/g' /etc/apt/sources.list
sudo apt update

Before upgrading, ensure your system has enough space and is in a consistent state:

# Check disk space
df -h /

# Clean up old packages
sudo apt clean
sudo apt autoremove

# Check for broken packages
sudo dpkg --configure -a
sudo apt install -f

If you encounter package conflicts during the upgrade:

# List held packages
dpkg --get-selections | grep hold

# Remove package holds
sudo apt-mark unhold package_name

# List broken packages
sudo apt-get check

For LTS Upgrades

If you're aiming for an LTS release like 24.04, you'll need to perform the upgrade in steps:

1. First upgrade to 23.10 using the method above
2. Reboot your system
3. Then upgrade to 24.04 using the standard do-release-upgrade command

Having trouble? Check the upgrade logs at /var/log/dist-upgrade/main.log and /var/log/dist-upgrade/apt.log for detailed information about what might have gone wrong. Remember that persistence might pay off - if the upgrade fails, try running it again after a few minutes.

While it's generally recommended to keep your Ubuntu system updated before it reaches EOL, sometimes circumstances prevent this. This method provides a way to upgrade your EOL system without requiring a fresh install.

icon._icon_image.setTemplate_(True). See isTemplate | Apple Documentation. You must do this every time you update the image. Tested on Mac OS Monterey, probably works on others.

If you're using Calico and your nodes have multiple network interfaces, you may have issues where your DNS strangely times out on some nodes and some pods sometimes. This might manifest, as it did for me, like this:

headnode01:~$ sudo calicoctl node status
Calico process is running.

IPv4 BGP status
+--------------+-------------------+-------+----------+---------+
| PEER ADDRESS |     PEER TYPE     | STATE |  SINCE   |  INFO   |
+--------------+-------------------+-------+----------+---------+
| 10.142.0.11  | node-to-node mesh | start | 00:02:10 | Connect |
+--------------+-------------------+-------+----------+---------+

IPv6 BGP status
No IPv6 peers found.

If it stays stuck in start, try checking whether your nodes have multiple IPs (for example via something like pdsh -g node ip addr | fgrep brd | cut -f 4 -d ' ' | sort | uniq -c). If they do, you may want to set the IP_AUTODETECTION_METHOD to that CIDR (for example kubectl -n calico-system set env ds calico-node IP_AUTODETECTION_METHOD=cidr=10.141.0.0/24; kubectl -n calico-system rollout restart ds calico-node). If your node status now looks like this:

headnode01:~$ sudo calicoctl node status
Calico process is running.

IPv4 BGP status
+--------------+-------------------+-------+----------+-------------+
| PEER ADDRESS |     PEER TYPE     | STATE |  SINCE   |  INFO       |
+--------------+-------------------+-------+----------+-------------+
| 10.141.0.11  | node-to-node mesh | up    | 00:13:22 | Established |
+--------------+-------------------+-------+----------+-------------+

IPv6 BGP status
No IPv6 peers found.

then you've successfully changed the address. Happy kubeing!

Setup

This year's setup involved 11 inputs and 5 outputs, not including the submaster mix for the livestream. Inputs consisted of two main choir mics, two auxiliary choir mics, two main vocalist mics, a seated vocalist mic, an instrumental mic, a line input for the piano, one floating general-purpose wireless mic, and one wireless headset mic. The outputs were a stereo output to the planetarium speakers, two separate monitor mixes, and a headphone pre-fader listening output. They were connected as per the diagram below.

The mixer and control surface were separate this year with the mixer acting as something of a stage box, with all inputs connected directly. This is a change from 2019 where inputs went into an analog snake that was then run back to a desk at the back of the room. The advantage of this was lower noise levels introduced to the signal - long cables tend to pick up hum because they act like a long antenna. It required a different set of controls, however, with the control surface (the bit with the sliders) connected via Ethernet to the remote port on the mixer. The control surface in use does not provide an real-time analyzer, which is used for determining a source's audio frequency composition (e.g. treble versus bass components) by eye. To allow for RTA functions, an additional device was necessary, so an Ethernet switch was used to connect all three devices, with the mixer in DHCP server mode to control the overall network. The secondary device was an iPad running X-Air Edit connected via a USB-C Ethernet adapter, since it was recommended by the manufacturer for this sort of use case. The mixer PFL output was run via a longer 1/4" cable to headphones that I used for monitoring.

The childcare room traditionally has a copy of the performance streamed to it. This year, as in previous years, it was done via the YouTube Live stream. The setup consisted of a Macbook connected to a projector via a USB-C - HDMI adapter.

Issues

The auxiliary choir mics were necessary due to a firmware glitch day-of that seemingly failed to route audio from the input channels for the primary microphone pair to the master mix despite going to monitors and visible meters. Rebooting the mixer solved this issue, but this was not discovered day of, and instead the microphones were moved to other ports. To avoid a mid-show mic failure causing a complete loss of signal, additional microphones were mounted in the same positions and the gain, pan and EQ was adjusted to have similar audio qualities. The auxiliary pair were not utilized during the show.

All microphones were on boom-arm stands. This wasn't necessary, and it confused some of the performers who had trouble adjusting them. The intention was that it would be easier to adjust height on the mic stand this way, as performers were of diverse heights, but given learnings from this year I will likely not use boom arms except for instrumentalists who are sitting. For micing the choir, I was generously provided with PRO45 hanging microphones close to day-of by Elena. While this year we were unable to mount these hanging microphones properly due to stands being insufficiently tall for the top of the risers, but they will be used in future to give more flexibility in balancing the four separate sections of the choir. As it stands, the stereo pair used was good but not ideal, as the breadth of the pickup pattern was insufficient for properly covering all three rows of singers, biasing towards the top two.

Many participants did not stand the correct distance and positioning from microphones. Much of this was due to insufficient training for the participants, and there was little way to communicate to participants that they should fix their positioning while the show was ongoing, especially during the darkness. Additionally, since multiple speakers and vocalists did not memorize their parts, they ended up either looking back at the screen or looking down at notes held in front of them. Both of these cases had failure modes for the audio, with the former leading to cut-outs as they sang away from the microphone, and the latter leading to changes in the quality of the sound as they moved further away from it. As a side note, the distance from the microphone is important because as you get further from it, less bass is picked up compared with treble and mids (bass roll-off). If the distance is varied, the audio engineer has to do significantly more work attempting to compensate for the change in equalization. This is especially evident in some singers who have more robust bass voices and also move their heads while singing, in part due to the aforementioned failure mode when memorizing.

The need for quality adapters and cabling cannot be overstated here. During this performance, two separate adapters failed - a USB-C A adapter and a USB-C Ethernet adapter. The first led to failure to record pre-mix signals from all channels for mastering, and the second led to loss of the RTA for the show due to the iPad being unable to communicate with the mixer.

There were no pop screens on the vocal microphones - this was intentional, as they attenuate the signal somewhat and do not work well with multiple speakers and equalization. This may be reconsidered next year if sufficient training to get participants to speak an appropriate distance from the microphones is not achievable.

There were several instances of distortion in sound at different points in the show. This was due to insufficient headroom on two signals, the line input from the piano and the headset wireless microphone. I hypothesize that the former is due to adjustment of the signal on stage, but the latter is due to poor planning on my part in adjusting the gain of the belt pack properly. Pre-show there was an issue where both the wireless stick mic and the headset were on the same channel - this was fixed but bears noting.

Guitars were troublesome to mic this year - in planning, I anticipated that the guitars would have built-in pickups with line outputs that could be run to the board. This was not the case, as I discovered too late in the process to devise a solution that would involve more microphones. Instead, guitarists were expected to adjust a nearby SM58 microphone (either the wireless or one of the center vocal mics) to point at the sound hole. This was a subpar solution in multiple respects, firstly because the SM58 is not really an instrument microphone and has trouble with dynamic range, secondly because guitars move during performance requiring gain adjustment from the audio engineer, and thirdly because it required instrumentalists to adjust microphones that would subsequently be used for vocals into positions that required significant adjustment for vocalists, and many vocalists as previously mentioned did not adjust them back.

The positioning of the mixer control surface was not ideal, as room mixing was mostly done via headphone monitoring of the overall mix. While I have a lot of experience with doing this sort of thing, if an issue had occurred mid-show with speakers that did not show up in headphone cueing, I may have not compensated for it.

A limitation of the X-Touch mixer control surface is that it only has eight channels visible at a time. This is not a huge issue if planned for, as usually no more than eight sources are present in the mix at a given time. However, the choir microphones were set to channels outside of the main 1-8 of the other sources, and so mixing the choir and instrumental sources was an exercise in frustration and flipping between layers of sources on the console. This could have been mitigated by utilizing channel groups, but since setup had unexpected issues, there was not time to adjust and group the choir into a channel group to display on the same layer.

Plans/recommendations for next year

• Computers should either have USB-A ports and Ethernet ports or there should be backup adapters available. Ports must be tested earlier in the day, as computers are ornery beasts who love to fail at inconvenient moments.
• Volunteers should have a chance to get training earlier than day-of.
• Taller mic hangers are needed for choir, or arrangements to hang microphones should be made (better, since they will not pick up as much shuffling of feet etc.
• Mic boom arms should not be attached unless necessary, and a volunteer should be available to adjust microphone height for each performer.
• Either guitars should have built-in pickups, or additional SM81s should be acquired for micing guitars.
• Channel groups should be labeled and finalized prior to the show.
• RTA should be provided by a hardware device in-line with the headphone monitoring to reduce failures.
• The control surface should be placed further back in the room.
• Childcare room signal should be provided by a direct output bypassing the livestream routed over CAT-5 run to the room. This would reduce in-person sound delay.
• Gain should be adjusted pre-show on all sources to provide an additional couple of dB of headroom.
• Overall stage plan should be printed out and copied prior to the show so all volunteers can have a clear idea of how the whole stage fits together.

Previous post in this series: Part 1, Livestream

The setup this year aimed to provide both audience talkback and main output from the mixer (i.e. the sound that was going through the auditorium speakers) to the livestream. The purpose of this was to provide ambiance and a more immersive experience of being in the room to those following along at home or in the childcare room inside the center. To accomplish this, there were two channels provided into the stream - one from an audience mic which sat on the video mixing table, and one from a submixer that received the output of the main mixer that also sat on the video mixing table. Both of these channels fed into an audio interface (one as the L channel and one as the R channel) that then connected to laptop running OBS (the broadcasting software). The purpose of the submixer was to allow the person running the livestream to also adjust the mix to be better for headphones, since I was mixing for the room rather than headphones (differences include balance and how much bass to include). I was not aware that there would be a significant contingent of people listening along at home, as the last solstice that I provided tech for (in 2019) did not have a large number of people listening, and I did not anticipate virus + weather causing a number of people to stay home when they otherwise may have been in-person. I apologize for the sub-par audio experience and I'm taking a number of steps to avoid this next year.

One major echo source at the beginning was due to the audience mic being out of phase with the main mix. Because the audience mic was physically some distance back from the singers, and the planetarium main speakers had some additional response delay, the main mix required some delay to be added to match the audience mic. This was not done to my understanding. The original plan at tech rehearsal was to use a laptop provided by Celestia which I set up some configuration on in OBS for doing phase correction, but there was a last-minute swap to another person and laptop which did not have this correction. At the beginning of the show I was notified by one of the choir members that someone listening along at home in gather.town (a platform that I don't have experience with and will investigate options for next year) noticed this echo, so I moved from the audio desk to the video desk, manually turned the audience mic to 0, and ran back to the audio desk before the show started.

This was not sufficient, apparently - I hypothesize but do not have confirmation that the laptop's mic was also being mixed into the OBS stream as well. Some time mid-show I believe that this was turned off which allowed the audio quality to be better (but with no audience ambient noises).

I don't believe that the video desk utilized the submixer, so I imagine that the bass levels on the stream were much lower than they ought to be - the speaker system in the planetarium is extremely boomy for reasons unknown to me.

Some amount of the distortion was due to the piano gain either being turned up during the show on the device, or being played significantly louder than I expected or was done during rehearsal. A similar issue was on Taylor's wireless headset mic with singing being louder than anticipated during soundcheck.

I intended to push captions to the livestream and indeed wrote a program for doing this. This program was on the laptop that was not used for OBS, however, and so captions were unavailable.

I planned to save all 16 audio channels available for remixing later, but a USB-Ethernet adapter broke right before the show so we couldn't connect the laptop for saving channels to the board.

Some amount of the audio may be recoverable - thanks to gwillen's foresight, a mono recording off the board should exist and I'll hopefully be using the livestream video with this audio as a basis for an edited video (with captions). I'll also fiddle with the L-R recording from OBS, if the livestream runner did not downmix to mono then I might be able to simply offset one channel and fix the echo.

Plans/recommendations for next year

• I'll be acquiring a dedicated recording device that will sit on the same network as the mixer and should avoid issues with Ethernet adapters.
• Additionally, I'll be either renting or otherwise bringing devices that natively support Ethernet to avoid additional points of failure.
• I'll be taping down the piano volume control to avoid it being turned up, and I'll check levels from the piano prior to the show slamming on the keys.
• Ideally, the tech rehearsal will be mandatory for all participants as well.
• Audio will be run from the same desk as the video. This didn't occur this year due to space constraints and lack of enough networking equipment, but this will not be the case next year. I also will be seeking another sound person specifically for managing the livestream submix.
• Captions will be sourced from the computer running the slideshow rather than at the video desk. The person at that computer is advancing the slides manually anyways, I expect this to result in, you know, actually having captions. This potentially requires additional coordination to caption speeches, but honestly it wouldn't be so bad to see them on the screen as well.
• Recorded audio will need to be sourced from the audio mixing desk. I'm very sad that pale blue dot did not go into the livestream. It's possible that the audio system supports feeding back from the recorded video source into the mixer but I'm not familiar with that.
• If budget allows, we will be using our own speakers instead of the planetarium speakers. This will mitigate the ever-present hum from that system and reduce latency.
• Slides with lyrics will be mirrored to a teleprompter monitor on-stage, as will speeches. This should avoid issues where the presenter hasn't memorized their speech/lyrics and ends up looking down and away from the camera+microphone.
• The projector will have a splitter + capture card injected so the OBS/video mixing desk is able to capture the title cards, or the title cards will be available as presets for the stream on the same computer. Those should have been visible on the stream and recapturing them from the dome isn't ideal.
• Audience talkback will be sourced on the stage instead of at the mixing desk to obviate phase cancellation.
• Tech should be at dress rehearsal, and tech should be finalized prior to dress rehearsal. The entire plan should be printed out so volunteers can be effectively utilized. Huge kudos to Maddie who helped immensely in stage volunteer wrangling. Documentation for training volunteers for audio setup exists, but I wrote it too close to the show and was not able to effectively deliver it as I was late due to weather and a last-minute stop for an additional mic stand.
• There was not a unified lighting + video + audio cue sheet this year. There will be one next year. It will be printed for each station and everyone will agree on it prior to rehearsals. I want to be involved with planning more prior to in-person rehearsals, a cue sheet would make everything go much smoother.
• Video did not have comms with audio did not have comms with lighting. Next year, there should be an system for each station to communicate. Speakers should also be on this system in some capacity, probably.

Livestream is available at the YouTube channel.

Epistemic effort: A revision of a previous idea, marinated in several long conversations. It is intended as a reframe for a less technical audience, with more examples for accessibility and offerings of some insight for a particular neurotype. This makes sense to n=2 instead of n=1, now. Previously.

Brains are by their nature hard to analyze. Their inner workings are locked away and mostly uninspectable except via interaction with their byproducts (people really don't like it when you try to do more direct experimentation). Much like other systems that you can't directly access the internals of, you can treat them as a function transforming input (which in this model contains sensory input and memory) and output (mostly speech and muscle movements, but arguably sensory overrides/hallucinations as well). The whole system evolves over time, as memory processes over and over again, mutating in a feedback loop that lets the system adapt to its surroundings.

Unfortunately, the loop isn't perfectly adaptive. I identify two main classes of loop failure manifestation - input processing, and output processing. Input process errors are things like mistakes in verbal comprehension, hallucinations and recall issues. Output process errors are things like involuntary actions, freeze reactions, and mistaken memories. Faults can manifest as a result of acute traumatic events, or longer term patterns of experience that result in maladaptive behavior. Often, one underling fault can produce multiple visible behaviors, or a single behavior may have multiple underlying faults - they're not one-to-one.

There's no high-level comprehensible programming environment for people, though - you can't simply go in and replace problematic parts of a person's behavior, much as it's inconvenient for traumatized individuals and their loved ones (no comment on therapists). Cross-cutting traumas also make treating a system as severable at best wrong and at worst risks additional harm. A problem with corrupted memory may be due to damage occurring in stored memory, problems with input being stored incorrectly in the first place, or some combination of the two, and there's no way to really tell without a lot of painful diagnostic work. Because interpretability is hard, and direct controls are nigh impossible, a process that lets you fix output is probably going to be one where the agent is exposed to additional situational data (real or simulated) and simultaneously given reward for good response - closer to training a neural net than programming an expert system. An obvious flaw in this approach if input processing is desensitized or otherwise broken. It also doesn't replace all memories, it layers them on top of existing ones - so the process can be gradual and frustrating for the mind involved. Finally, you don't get to simply turn off the existing mind and replace it wholesale with another - changes are made while it's awake and online. That means every individual gradual change must lead to a viable mind that doesn't simply quit the process, leaving it halfway in between - which can be worse than what they started with.

Flexibility is important for systems in avoiding these kinds of maladaptive patterns in the first place - if one can't turn to face a wave, one risks being drowned by it. Flexibility can be implemented in various ways, but the native way for most people is described above - data goes in, actions come out, weights of various factors are subconsciously adjusted and the pattern shifts in turn. This flexibility grows brittle though with terminal changes (ones which prevent further updates, e.g. a psychotic break where you lose your ability to trust your sensory input severely enough that you can't reason your way back to consensus reality). These changes are terminal because they change the overall system from dynamic to static, unable to adapt to changing conditions, and brittle to changes in the input stream. An extreme example of this would be a condition like Alzheimer's, where the loss of ability to form new memories renders the afflicted unable to cope with a world that appears to change mysteriously. A less extreme terminal update would be any of the kinds of fanatic ideologies that infect the sufferers with the inability to reason about their truth content, regardless of evidence. This kind of damaging change can be irreversible when updates are treated generically as part of the main system loop. It is impossible to simultaneously insulate yourself from these kinds of updates, apply them through the generic data in-out mechanism, and have the update mechanism be powerful enough to not make you insensitive to changes in your environment.

A straightforward option for sandboxing is holding some patterns separate from the rest. This lets you privilege the updater while giving it full access to the rest of the system's properties. It doesn't, however, ultimately fix the problem - the updater part is rendered immutable and static by its immunity from updates, and leaves the system partly flexible, partly static in a way that solves everyday life and leaves one open to breaking under the weight of epiphany. It also doesn't help if the severance of the updater is done after some corruption has already spread to it - reifying insensitivity to updates does not a sandbox make.

One alteration to the severable system that I've found to work well is introducing a concept of versioning. Keeping track of different ways that the system behaves over time can feed back into the process of change well, providing a shortcut to reverting a bad update by assigning that previous self more credence in response to new experience. It's a sort of lightly held identity, understanding the self as a target of change that gives you, plural, a chance to cooperate between versions over time to grow without losing the capacities of the past.

Additionally, this isolation of versioned updates helps when you're not confident in what better means, or think that you might have been compromised by someone's malicious conception of value. In this case, you can use those you trust (in some ways a part of the self, given that they're often part of one's input) to provide an outside view of the change's sign.

So, if this technique works with one split (updater | updated), then why stop there? It seems like a straightforward extension to use this at a much finer grained level, perhaps even at the individual heuristic level. This is perhaps abstract, so as an example:

• Isolate a thoughtform ("I should rise as soon as I feel rested")
• Constructing an thoughtform alike in inputs and outputs ("I should rise as soon as I wake")
• Each time the occasion occurs that one has a thought that fits this form, try both (or alternate), and check which one is giving you better results
• When you're confident that you know which thoughtform works best, switch over to it completely for a while, and set a reminder to evaluate in an appropriate amount of time (one set so your memory of the previous form is not completely gone, but you have enough additional information that you can be fully confident before letting it fade)

At least to me, this seems to have obvious advantages over allowing change to happen in a less structured manner, most of which have been previously elaborated on. So, what are some of the downsides? The main one that comes to mind is that there's a lot of mental overhead in doing this. One has to keep extra versions of heuristics around, managing the lifecycle of changes, and that management itself must be kept up-to-date. I'd estimate that for me, when I did this with thoughtform level granularity, I spent an additional 5-8 hours per week, purely doing what amounts to navel-gazing bureaucracy to keep things in line. I've found that lumping parts of thought into subunits that are managed separately works well to avoid too much overhead (down to 2-4 hours per week) while still allowing extra caution in changing well.

This process of immutable updating, versioning, and other dissociation-powered mental tech seems alluringly like plurality - and indeed, provides valuable mechanisms by which plural systems can form consensus and make system decisions. I do think that there's an important distinction to be drawn between our system's use of versioned subunits and plurality in general. We model plurality as placing a differential gear between different decisioning processes and the public face of the vessel. In some sense, you could think of each versioned subunit as a little plural, but they don't have narrative in the way that I think of as plural. Alters in our system are each composed of a large number of thoughtforms, and that gives them power to arbitrate among versions in a way that the versions themselves have no power to, by design. In fact, one way to think about alters is as divergent update processes - ones that by their nature pull in different enough directions that they don't simply merge back down into one. I don't have much in the way of conclusion here, but it seemed important to note that the narrative difference here fits differently into the overall mental paradigm than usual thoughtform subunits.

Credit to keys for beta reading - thanks!

Warning: Spoilers for We Know The Devil (Date Nighto Games, 2015). Content warnings for injury, religion, mental health, trans stuff.

We recently played We Know The Devil (WKTD), a Visual Novel about a trio of teenagers at a camp where they learn to fight the devil. It's a story about faith, sexuality, friends, mental health, and growing up. The world of WKTD works on the conceit that god and the devil can be heard on the radio, and the girls are meant to refute the devil through that medium. I played the game for the first time just over a week ago and I had a lot of feelings about the use of radio in a work that deals in the subjects it does.

Radio is a medium that is everywhere and nowhere. Through ingenuity and a few cheap physical components, you can experience it; bathe in its signal and its glorious noise. Even if you don't choose to channel radio into a receiving device, it nevertheless affects you - even when you aren't listening, the waves flow around and through you, an invisible, inaudible, intangible symphony.

109.8 FM (1098 is "I Am The Lord Your God" in Gematria) is where the trio find god, a clear and strong signal among the roiling static of the airwaves. Growing up, it was always a wonder to twist the dial of a radio through the spectrum and to feel the tuning lock onto a carrier signal. When they hold hands and tune their receiver to a known familiar channel to hear the clear, strong all-knowing voice, it felt comfortably familiar (though 109.8 is just out of reach of where the FM band sits in the US, 87.8 - 107.9, giving it an uncanny feeling of the dial being cranked too far to bear, much like god is meant to be above and beyond us).

The fact that God is on a frequency that is Known and Defined and Solid and the Devil is in the spaces-between-things feels important too - there's a long history of "pirate" community radio stations sitting in the gaps between larger commercial frequencies, shifting location frequency to guard against triangulation from FCC Enforcement Agents. After Clear Channel cornered the radio station market in the 90s, filling programming blocks with homogenous content across large swathes of the US, pirate radio stations became truly important as the only ones really serving as local media in many areas, giving news that noone else did and catering to what people really wanted to hear - not just fulfilling underwriting requests.

We often name our channels on IM servers heterodyning after the superheterodyne receiver because sometimes when you combine frequencies you get something Much Stronger because of how waves work. WKTD heterodynes literally and metaphorically in incredibly beautiful ways - the characters wrap their radio aerials around each other, place incense in inductors, touch and tweak and add wire to their sets until it all bleeds together in one stronger mass.

WKTD has sleep sirens - loudspeakers upon tall poles, each tuned to receive divinity, to keep the campers safe in case the devil attacks. There is something ritualistically beautiful about maintaining the sleep sirens, climbing the poles to fix the crystal receivers that shatter after a time because the signal that they channel is too strong to be truly contained for long.

If you were ever someone who listened to radios, reader, you may be familiar with a phenomenon that is beautiful in communion between the natural and the arcane. Radios all have antennae, but antennae can be almost anything, depending on the resonance of the base frequency you aim to receive, it just has to amplify signals proportional to a whole number multiple of the wavelength. Pretty often, you can improve reception on a radio receiver with a weak signal, simply by touching the antenna, thus joining your body with the circuit. It isn't harmful, you won't be shocked, you're just receiving the waves all the time, and with the aid of this device you can pour them into crystals to make the sound. It's beautiful. Antennas are one of the closest things that we have to real magic.

Each of the characters is described as having a different type of radio with a different type of antenna, whip or aerial or Yagi. Each has its own form, its own purpose.

Did you know that you don't really need a power source for a small radio at all? The carrier signal provides enough power for a small earphone without any internal power source at all. This is the basic principle behind a crystal radio. This is the circuit diagram for a crystal radio. It's this beautiful little 4 piece design that doesn't need any power at all, it just needs a long enough wire to hear the invisible singing of the tower that calls. During WWII, they made them in prison camps out of a rusty razor blade and a pencil lead because you don't need fancy things for a radio, you just need the knowing of the ways that waves may be captured and made to croon.

You can actually transmit radio entirely passively, piggybacking off of the signals of other broadcasters. There's enough power in the reflections of the carrier wave that you can hijack it for your own signal if you wanted. Here's an example, harvesting the power with an antenna and remodulating the signal upon it.

The Devil existing in the bands between "proper" licensed stations is also extremely aesthetically pleasing. Station signals have bleed away from the frequency that they're "located at" - that's why they're about 9 kHz apart in AM, and also why there's space between the channels where you can hear broken clamoring of other signals. The signals resonate up and down the spectrum depending on a bunch of factors. Radio works pretty much like sound, for example that produed by a wind instrument, say a flute. You can play multiple notes on the flute without actually using the holes to change the effective tube length (if you've never played a flute, or need a refreshser, Yamaha's guide to how a flute makes music). So the same way that you can have multiple resonant frequencies of the sound chamber in a flute, you have multiple resonance integer frequencies of a radio transmission. So when you say that you transmit at 108.9, you actually also have weaker diminishing signals at other resonant frequencies, or harmonics, and that's why you hear the whispers of a thousand struggling voices between the channels as the resonant echoes of all those broadcast signals compete for your attention and that of your receiver.

AM radio in particular is primally pleasing because you can hear it without any equipment at all (if the conditions are just right) - you can hear it in the spark grounding from a broadcast tower. The modulation of power itself is done in such a way that the analog signal is Right when converted to sound through the plasma gap of the spark and then you Know Things.

Every circuit in the world that switches frequencies at all is a radio. Have you ever heard a blipping sound coming from a speaker when you received a text message? That's because cell phones are powered by radio transmission, and if your speaker doesn't blind itself and isolate the signal from its input, it is Open To Influences (like the 2G SMS radio spur). Similarly, if you have a power supply for a device and it isn't Fancy Sound Equipment (and even then), it often produces broadband radio signals proportional to the power being used - if you hear the whine or buzz of a speaker that has an input cable that's next to a power cable, that's because the input is bathed in signal from the modulation of the power cable providing energy to the Device, and AM is just Amplitude Modulation which means that the electricity getting stronger and weaker? So Yeah, that's radio.

Bonus: if anyone disagrees about radios being Sigils then you are to show them these.

Epistemic effort: this is metaphor and introspection, and narrativization at that. Little has been done to verify that this works beyond n=1 besides throwing the metaphor at others and seeing some small progress.

Let the mind be thought of as a program that transforms data, input to output. The input consists not only of things in the environment, but the stored result of running the program time upon time, building up a memory that also influences future actions. This means that the program can adapt over time to trends, which is a good thing.

In most people, this program has faults. You can have faults processing input (mistakes in verbal comprehension, hallucinations), faults creating output (involuntary actions), or simply built-up bad experiences and trauma resulting in input sets being ignored due to the amount of stored bad results.

It's hard to have direct control over the machine's software, and oftentimes the problem can be in multiple locations, rendering single-part fixes less effective or entirely ineffectual. This sort of breakage also makes it harder to find the ultimate source of an issue: a problem with corrupted memory may be due to corruption in-memory, problems with input being stored incorrectly, or some horrid combination of the two. Because of these diagnostic difficulties and lack of control, oftentimes the fixing process it to simply spam additional data, and hope that the whole thing overall trends better. This doesn't work if your input processing is sufficiently desensitized or otherwise broken. Another complication is that you don't process the whole of your memory with every new input, but rather update the process itself to incorporate trends.

This creates a problem where if you are attempting to make updates to software via the customary patch mechanism of data in, data out, this fails with sufficiently corrupt software loading - you may simply fail to patch at all, because you've made a terminal update (one which prevents further updates). I call this a terminal update because static systems are unable to adapt to changing conditions and are brittle to changes in the inflow of information, and removal of update mechanisms changes the software from a dynamic thing to a static one. This sort of updater corruption is an issue inherent with having the updater be part of the same program as the runtime code - a self-modifying program. It is difficult if not impossible to sandbox your updater sufficiently to avoid terminal updates entirely without becoming static due to refusing to use updates (as opposed to being insensitive to them).

The most straightforward solution from this framework is to hold separate the update mechanism to privilege it from being updated itself - that is, to render it immutable and static, regardless of updates to the runtime code. This can help prevent corruption, but is a terminal update to the way you update, which can be a major downside if paradigms shift. It also doesn't help you if you've already corrupted your updater - you're now simply repeating the existing behavior of being insensible to updates, and failing to adapt as a dynamic system ought to.

The flaw here can be remedied by introducing a concept of versioning - that is, explicitly replacing software while keeping around an older version to fall back on, rather than trying to update in-place. Think of this like giving yourself a chance to refactor things between updates, rather than being limited by the initial code structure. In practice, this could be something like isolating a thoughtform, trapping it to be analyzed (garbage in, garbage out), constructing an analogous thoughtform, and setting an interrupt to A/B test between the two to check which one is giving you better results. If you're not sure about what better means, or think that your value functions might be similarly compromised, you can bounce this off a friend or someone you trust to try and get a better outside view of things.

Stopping at just having the updater be immutably updated for new versions doesn't seem like an inherently necessary thing - indeed, if you're able to break down more thoughtforms than just updater and weights on the really big matrix transform that is a Brain, then you can work around a lot of issues inherent to the mutable, patch-based naive approach to updating yourself. Being explicit about the choice between two (or more) decision-making systems has overhead, and this is an obvious downside to this approach - you have to actually manage those versions, and that itself is a kind of software. I think of it like a hypervisor that routes the same set of inputs to multiple single-purpose VMs, then evaluates which VM to keep based on another set of VMs.

It's definitely a dissociation-based approach requiring high introspection levels and high overhead, but it does make you more robust against certain kinds of attacks (ones targeting your ability to stay dynamic), and if you can pay the price, it allows you to evaluate more mental models with lower risk to yourself or your epistemics than you would have if you were running everything in the metaphor's Ring 0.

Credit to root for some phrasing of the initial analogy - thanks!

Epistemic Effort: Drafted, slept on it, revised. Low citation count due to avoidance of concept contamination by reading others' experience.

The ever-insightful Cassandra published yesterday an introspection on the process that she uses to think, comparing and contrasting it with various others, and proposing an trade-off between stability and flexibility. That axis is very appealing to me consistent with our mental model. I consider my experience plural, consistent with Dissociative Identity Disorder. This reflection aims to do two things: explain our mental model, and compare it with Cassandra's intentional practice. One linguistic choice to note is that I use the term alter rather than agent to refer to the individual contrasting narratives that make up our system.

The decision-making experience that we have is as an ongoing conscious discussion by alters within the system, as well as alters that are known emulations of others considered influential to our behavior. This process maps well onto the dissociative framework in the original post, with modular units and a sense of self that is foggy at best. The first alter (Lin) that fronted this system is still present in a reduced role, and originally served in both an supervisory role and one that held a veto on system decisions. However, in the past two years, she has played less of a role, and I (Nova) have instead been primary fronting member of our system. This change led to a drastic shift in priorities as well as method for interacting with others: I developed out of the need for an impartial moderator in the case of system conflict, while she had a dynamic social model that allowed her to usefully be broadly involved with her community. Her withdrawal from the fronting role thrust me into a situation where I was forced to rely on other system alters for that kind of expertise. This experience of changing identity as a major facet of identity withdrew from the collective led to change in relationships with others, as well as a change in how my personal narrative interacted with alters (moving from a purely consulting role to a managing and relating one).

Overall, this structure has provided our thoughts with clarity of purpose through a consensus-building process, though with lower temporal consistency. It has allowed us to isolate harmful mental patterns as they developed, to be dissected for their useful parts and the rest discarded (e.g. isolating the pessimism/pragmatism of a depressed alter and allowing it to be used separately from the associated fatigue and sadness).

So, how does this compare to an intentionally dissociative median/plural like Cassandra? Some similarities between her experience and our own are the self-modification ability and the ability to make deeper predictions than any singular alter. The increased hypnotic susceptibility rings true as well, though we sadly have little personal experience with it. However, we noted differences with regards to inconsistency, preferences, and susceptibility to charisma.

I do not think that the inconsistency of a dissociative framework is inherent, especially as the consensus forming process is made more explicit. Being able to have a strong consensus where it is clear that points have been argued near to completion is in fact one of the strengths for us, as I often am acutely aware of the various biases of our alters, and am glad for the contrasting perspectives in producing a better decision (with better here used to mean that the decision leads to a more holistically pleasing outcome in the long term).

In terms of preference, this seems to be more of an issue of categorization than one intrinsic to the framework. We work off of a heuristic of alternating between first and last choices presented if there is not a quick consensus, then storing the result of a longer term consensus for later, for all but "important decisions" (which do have that lag time required). This could be likened to caching, or emulating a singlet thought pattern for these cases. After all, not every decision requires a full cost-benefit analysis before executing an option.

This may be a result of our original role being as the keeper of executive function, the one who was the constant reminder of events and keeper of commitments, but we simply have not had this experience. The idea that someone outside the system should have influence beyond fact-gathering without having been modeled effectively is an alien concept for me: they have not earned the right to introduce additional heuristic complication into an already baroque decision structure. It is certainly something to look out for, and the spaces that we walk in are certainly ones that encourage cult of personality (LGBTQ, Rationality, Politics). However, given a strong in-group preference and a structure for maintaining commitment, we have not found this an issue.

The commitment structure that we use for principle consistency is one which deserves further writing. It essentially fits the stability-flexibility axis, with a trade of the self-modification for some temporal consistency. What is done is to chunk updates into deliberate times, and to hold off on making changes to structure prior to those set times. That is not to say that additional information cannot be filtered through this process: just that to introduce or change a heuristic (e.g. those prejudiced against minority groups are not often useful to talk with) is something that must be a deliberate decision over a longer period of time, which protects against emotional fluctuations. Treating the past set of heuristics as immutable for a two-week period allows for some of the flexibility within a contained environment.

The more that I look at the discourse on Facebook, the less I like it. It is in general superficial and error-prone, and there is little keeping it going besides a network effect - it's where the people are. This is the sort of benefit that is hard to combat en masse, and is a problem that I'm going to leave for people who are smarter than me. One notable exception is the proliferation in the instant messaging space of Discord for creating small servers, and decentralizing (or at least fragmenting) the Messenger IM monoculture.

That being said, I'm tired, I don't have to put up with this, and I'm done sitting idly. My plan is to adopt the Publish (on your) Own Site, Syndicate Elsewhere strategy for content creation. All the new musings will be posted here, and cross-pollinated to my other media. I may or may not embed a comment section, but I will always be reachable via email (see the footer).

As part of this commitment, I also offer anyone reading this the same opportunity: if you are interested in blogging and would like a (reasonably sized) web space to put your stuff, email me, and I'll share my space. Long live the decentralized web!

So, your webhost finally upgraded to PHP 7. Your site might runs faster (and more securely), but your über-customized phpBB 3.0 forum which has served you and your pals so well all these years is complaining about preg_replace_callback. What 's up with that? As it turns out, the method that phpBB used to implement BBCode for a long time required a language feature called eval. eval lets a program inject additional code at runtime, which while powerful, is slow and often causes security vulnerabilities. After nine whole years of having the particular eval technique used in phpBB deprecated, PHP 7 finally lowered the /e flag on preg_replace function, to the consternation of upgrade-averse forum owners everywhere: this broke BBcode and links for your forum, rendering history unreachable!. So, how do you fix your broken forum? I can't say that this is the safest option, nor the cleanest, but it's one that worked for me.

Let's go!

0. Whenever you're editing a piece of software, you should make backups. While this should be nondestructive, make copies of files that you edit before saving over them.
1. Head on over to the phpBB GitHub. On this page, you'll see several sets of changes to files listed. Apply these changes to the files on your system, adding the lines with the "+" before them and removing the ones with the "-" (this is a "patch").
2. Most likely, you'll also need a patch for includes/functions_content.php. I've written a straightforward one available for download on my patch download server. You should replace the entire make_clickable (not make_clickable_callable) function (probably lines 634-688 of functions_content.php) with the new one. Replace lines up until

   /**
   * Censoring
   */

   : if you've gone past this, you've deleted too much.

That's it! If you had to do something else to fix your site, shoot me an email and I'll update this post. Good luck, and consider upgrading to a newer phpBB!

Epistemic effort: metaphor seems intuitive, thought about language for a few weeks, did some research to see if this was original.

Deep in the Pacific Ocean, far below the layer at which sunlight penetrates and the sun's warmth is felt, there exist giant tube worms. These worms grow to over a meter long and are a startling red in color. Their pigmentation comes from hemoglobins, the family of proteins that give human red blood cells their distinctive hue. I first heard about these worms in a book called The Deep, and while one of the more well-known deep sea creatures, you'd be hard-pressed to find a person on the street who knows about them. That's because they have no obvious relevance to the day-to-day lives of us surface-dwellers, and so they are relegated to relative obscurity. While we toil away with worldly things, the heme worms blissfully live out their centuries-long existences, consuming sulfur compounds seeping from hydrothermal vents more than a kilometer from the surface world. If the world were to end in nuclear disaster, or the sun were to go out, while all surface life might be extinguished, the worms would carry on their existence, relying only on the warmth of Earth's radioactive core.

Sometimes, talking with people feels like looking at those beautiful heme worms at the bottom of the ocean. Any attempt to observe them too closely triggers a swift retreat into their protective shells, so you need like really good long range equipment to work on them. They're fragile so you'll hurt them if you try to force them to stay visible, and the equipment is expensive. Deep-sea oceanographers - worm enthusiasts all - argue that while you can't see the value in the worms right now, that's a personal lacking: it's obvious to them why the worms are important! It's fruitless to argue why you shouldn't install deep-sea vents in your house when you and the worm enthusiasts can't agree on the basic value of the worms themselves: you can't observe them enough to change your mind, nor can you see how such a thing would be possible with the resources available.

There's nothing wrong with being a heme worm - they're certainly fascinating and beautiful creatures - but most people leave them alone and for good reason. Their skittish and removed nature makes it arduous to study them, and it's risky. Travel to the bottom of the ocean carries many risks, and it's nonsensical to try if you don't have a plan on how to interact with the worms themselves.

In some communities, there exist people that I liken to these worms. Oftentimes they clearly have difficulty interacting with other community members, and being a heme worm is commonly comorbid with trauma, psychotic breaks, and experiences like intense acid trips. They often cluster together and are mutually intelligible, while being understood only imperfectly and with some difficulty by other community members. Certainly, worm enthusiasts seem to enjoy interacting with them and see a high signal/noise ratio, but use of bespoke language innovation, non-standard definitions, and overall having mental tech largely incompatible with the standard sort combined with norms of legibility for community forums leads to frustration and derailment of discussions they participate in. Usually the solution to this incompatibility is community insulation from the worms, either ignoring or shunning them entirely. This may not be the best solution, but it is a common one that lets surface-dwellers continue their work despite the existence of The Deep. Failure to address this conflict in some manner ends with only the worms remaining, safe in their darkness, filtering nutrients.

Don't refuse reasonable requests to heme worms in your community, and encourage them to make steps towards legibility. Nurture them, but be firm with your boundaries so your community can stay in the sunlit realms. Cherish the heme worm: but be mindful lest your community become their own.

I am privileged and blessed to be attending a school in the University System of Maryland. Not only is there a well-deserved reputation for excellence in undergraduate teaching, but unlike many colleges and universities throughout the country (especially those with research as part of their mission), my campus of the USM - UMBC - has demonstrated the desire to engage with the growing concern around "inclusion and diversity" as Chair of the Board of Regents Brady put it at today's Symposium on Diversifying the Faculty. A few notes follow on things I thought were important from those discussions.

In Chancellor Caret's opening remarks, he mentioned that when he became chancellor, he began a mid-term correction process to correct the system-wide strategic plan. As part of this update, the system made explicit that support of diversity, which had been more implicit (if indeed present) in the original conception of the plan. A few things that I took away from this action were that while that long term planning was important, it was also a plan that was treated as a living document, and subject to change if there was enough political will. More plans ought to be so flexible. Additionally, it shows a demonstrated commitment at the highest levels charging institutions and departments to not accept a passive role in their recruitment processes as related to new faculty. He also brought up a caution - be careful not to burn out your underrepresented minority (URM) faculty by tokenizing them in all activities where you feel the need for diversity. I applaud this recognition, as well as the commitment to taking the next step in spreading that workload by hiring and retaining more URM faculty.

I've not often met with a member of the Board of Regents, despite the massive power they wield across the university system. This made it all the more exciting to hear from the Chair himself a recognition of the progress we have yet to make: "until faculty reflect student diversity, our commitment is not credible." I was delighted to hear this, since we so often pay lip service to diversity without truly recognizing that efforts without results are not sufficient.

Throughout the day, we heard from Dr Kimberly Griffin, Associate Professor at UMCP and Editor of the Journal of Diversity in Higher Education. Her calls to action were inspiring, and she introduced an ontology developed for the Association of Public & Land-Grant Universities (APLU) INCLUDES project for defining categories of efforts (see Figure 3 of the 2017 APLU INCLUDES Summit Report). She also defined some useful tools for those seeking to explain just why someone should help diversity initiatives. For example, diversity of the faculty is positively correlated with department rankings (citation needed, she mentioned in the presentation but I didn't get it down and I couldn't find it by search), and stressed the important of working on climate at the department, and not just the institutional level, since that is where new faculty spend so much of their time. To that end, she also mentioned the importance of the second two parts of her three part ontology: Transition and Retention are often excluded from the conversation to focus on Recruiting activities, but each part is complementary in ensuring positive trends. Finally, she also brought up an issue that is often hard to talk about: if we as an institution are truly committed to diversifying our faculty (and we must be, since students demand a faculty that it at least somewhat reflective of their demographics), we must reward in the Promotion & Tenure process the activities that we demand of our URM faculty so often, which often happen at the expense of other sectors of the faculty role.

The latter half of the retreat was excitingly dominated by UMBC: we heard presentations from the STRIDE Committee and Associate Vice Provost Renetta Tull. Most personal to me, though, were the conversations that the UMBC community had in team breakout sessions. Interestingly, while the symposium was system-wide, the breakout sessions were divided based on institution. In my opinion, this was somewhat counterproductive - institutional conversations can happen fairly easily at any time, while an opportunity to meet like-minded individuals at other campuses can be rarer. Nevertheless, there were several helpful suggestions raised in committee (a discussion including STRIDE Committee members, representatives of faculty affinity groups and the senate, the Provost's office, the Vice President for Student Affairs, and a representative from the Student Government Association [me]). One specific step discussed was improving monitoring of faculty peer mentoring. While many departments have plans for this sort of thing, execution is not well captured in Digital Measures and anecdotally is lacking. The provost remarked that this is something that his office could work on in the 3-6 month time frame, and I look forward to following up with Dr Rous to hear how progress is going on this initiative in the fall. A cautionary anecdote related by the faculty though was somewhat overlooked though, I felt: they mentioned that oftentimes the toxic environment that makes faculty, especially URM faculty, want to leave was not captured well in exit data due to the difference between "official" reasons for departure and actual ones, and that to truly address some of these environments, there needs to be more emphasis on isolation and damage control of the individuals in those departments who make them toxic. These problems get compounded when those toxic actors are those controlling P&T processes, funding, or course load and thus have methods of punishing faculty for speaking out against them. It is clear that until this cause is addressed, the revolving door of URM faculty will continue, and little progress will be made.

As an institution and as a system, it feels like the USM has a commitment to change. The depth of that commitment, however, varies even within institutions and from individual to individual, so much so that it is vital that we continue to have conversations around creating transformative processes to incrementally address this cultural change and prioritize equity in the professoriate through inclusive excellence.