[Destination Void]

[Stop Killing Games]

There are a few other visual changes here and there.

Additionally I have finally managed to coax [NAI] into another narration session. We have been holding off on releasing several items until there was a good batch for readings, altho some items were deemed high enough priority they went through to being published before the readings. New pages follow :

[crisys_touwynn]

[ira]

[samurai]

[psychic]

[oracle]

[backagain]

[fungus_amongus]

[digital_algebra]

The pages that were present but lacked audio and have been updated are:

[death_redux]

[mayo]

[vultures]

[gums]

[X]

Finally there are backgrounds added to a few pages, focusing mostly on the new and updated pages. This is going to be the biggest stress test of the new update system. As [backagain] states, if this update goes through well, we can say the new setup is "done"

the bad news is pushing the updates is as slow as i hoped it wouldn't be. like damn.

the problem comes from checking the files' modification time (pushing them all every time would still be slower, but only marginally). I do have a plan to make this much faster, but it is a hacky bullshit plan. I don't have anything better however, so it's what i'm going to do. but that is a problem for tomorrow's pilot.

edit: well, i was a bit overly optimistic about how minimal the effects of adding a single item are. for example, this page's body minimally updates muffet's page due to the new reference it adds to muffet. additionally it's existance as a feed entry changes [feed], as well as changes [tagrank] because the tag counts change. more damning it changes all it's siblings in the hierarchy as it changes their menu items. but the good news is it does limit the number of files updated substantially. a nice sideeffect of this is the static generation itself is much faster than previously. This is because I am now using a ramfs to build the final page rather than writing it straight to disk, so it only writes to disk the changed pages. but realistically compared to the network transfer of even a few files updates are going to take longer in general, like 5 minutes? (hopefully this isn't baseless optimism, and is instead gross exageration)

we are going to be fully updating the core infrastucture for both [myugii] and [temuorin], as such even the failsafe site will need to go down for some time. We will be handling myugii first and getting everything working there first, then temuorin, so ideally this will mean the site will be fully down for a shorter period of time. There is a bit of bookkeeping to do before we can start however, and it's not clear how long that will take. The next post will be to say either we gave up on this idea or we are done with the update.

for more detailed explaination. myugii and temuorin are both running quite old versions of [9front] myugii was based on the old mercurial build and temuorin was a short time after the switch to git. it's probably possible to fix things, but i have been banging around the source for quite some time trying to get things working properly without doing a fresh install and it'

s just not happening. This is all because i don't update often enough and 9front development kinda expects the user to keep up with things. as such I don't have the proper libraries to build the compiler, and don't have the compiler to build the libraries. I'll need to back everything up then do a fresh install to get back to head. hopefully this time i won't go a year plus without pulling updates (this first came to my attention like 3 years ago now, i've been able to update many of the programs but the core libs and kernel are all very very out of date)

anyway, migrations like this are very prone to missing things, for instance my sshkey for [gemini] may need to be reconfirmed as it's probably going to be easier to just generate a new one. the main stuff i need to get are the [slov] and [muffet] db and source, as well as the support files for the site. There are obviously other things which aren't public facing i'll be trying to not forget about as well. anyway. i've rambled on about this too much now. see ya on cybersavior(7) v4

illuminated be the green led of the ground fault plug on the wall, i grab the tooth brush in the cup at the left of the sink. Identifying the correct one by feel, passing over the soft bristle brush my roommate uses and grabing instead the metal handled brush. add a quantity of paste, probably enough based on pressure change of the tube.

brushing the teeth, right side top, right side bottom, outsides then inside. moving to left bottom, left top. something strange there. a protuberance on the gum between the penultimate and final tooth on that side. I had several days back in haste of flossing caught that spot in with the floss painfully. now it was swollen.

not just a little. I finished the ritual of brushing then rince in cold water. . . .

I already have backreference calculation for pages which I find to be nice, but I don't have anything that approximates the tag clouds seen on most blogs. I don't really care about grouping tags for closeness, but I do want a way to see the [tag usage frequency] and a decent way to start navigation through the [tag system]. Currently the way I use the site is find a page then go from there to a tag then to a new page, but I have to find that first page first.

Anyway the intention is finding that first page by "tag" rather than by host. Because I don't really have any special treatment for tags (they are just nodes in the tree which I use not as a content leaf node, but a psudo branch, If I ignore the nomenclature and allow any node to be considered, then I can use the back reference count as number of times it has been used as a tag.

This will probably have some affect of pushing [muffet] and [slov] higher up in the list than ideal, but it's fine. [safe] will probably be at the top followed by [nsfw] since I try to use either one or the other on all content pages (I feel I may have been a bit slacking on this now that I think about it.)

It will also tell me which tags haven't been used as much.

Anyway, it's not a huge update, but the new code is in the muffet archive and the page is live at [tagrank]

On the whole we have little in the way of rebuttal to this line of inquiry. On the whole the theory appears to be sound. We do however have some more practical things to discuss regarding these parallel worlds and more specifically dormant world.

Professor Imagawa describes worlds as having various levels of potential energy, but that the whole system of worlds maintains a fixed energy level, thus posits a system of world annihilation without going into detail about this process. Again, we do not fully disagree with this notion. Indeed, we believe that the effects of this are noticable through what has been termed the gravitational effect of "dark matter". This leads us to our first quibble. The energy of the system, or at least the system as viewable from "current reality" is not fixed; it has increased quite dramatically since the "creation of the universe" and appears to still be increasing. Thus, we believe that while there is some annihilation effect it is not as described in the inquiry.

Based on the research we have undertaken we are of the belief that worlds are "annihilated" by degrees, first becoming detached then as they lose energy dropping through distict levels of causality until eventually they have completely faded from having any causal effect on reality. This can be termed annihilation. We don't believe there is a fixed point of view, however, so this effect is mutual from any observer in the "annihilated" world.

Speaking practically we are all familiar with this process, and this is the core of why we have decided to release this. The form it takes is entirely dependant on the causal nearness to the receiver.

Those works which are termed "fiction" (or even "non-fiction" for that matter) are, in reality, the result of the folding in of these parallel worlds in a form in-line with that world's potental causal energy. An unread text document having low potential energy, a story you hear about from a group of friends, much higher, something you experienced yesterday, higher yet. Feel free to consider the works which inhabit your present reality and their relative potential causal energies.

It is tempting to say that we all share a reality, which exists at a specific time, however consider the causal potential energy of some man camping in the woods of Germany to a child living in a village in Uruguay. They may as well not exist to each other. Indeed they /do not/ exist to each other, except in very abstracted form. Perhaps the man in Germany, is one of the gnats which was on a leaf of a tree they passed as they went about their daily routine. Unnoticed entirely, existant only in that the child /could/ have taken notice, if they chose to. Likewise, for the man in Germany.

We may be propmted to say more on the subject. However, we promised to keep this brief.

the main down side is that i need to type with a quirk here. i need to double my apostrophies in order to escape them. enevitably I will forget one or two and then feeder will happily progress and fill in the incorrect information to the feed.ndtl file. But upside is if I put them here, It's easier to not make them [muffet_text text] entries, and instead I can use all the shortcuts for links and such properly.

I already have the blog section so I guess I will keep it. But also Since [law order] is boring, I will also be putting what are ostensibly blog updates here as well.

I think the problem is more likely with slov reading the names from the ndtl files. But it could also be a bug in the slov-muffet communication protocol. names of other lengths don't get truncated by one which would be a clear indication of an off-by-one in the cannonize function, the only reason why cannonize would have a problem is if it is given an empty string, or an address that simply isn't a string. (yes I know I should probably have a way to detect that the string is empty in cannonize. But unlike actual consumer software where you have to have a billion little checks for all the ways a user might try to break things, I'm the only user of this software, so I just don't purposefully try buffer overruns on slov or something. But this is a bug. This one post aside, there is plenty reason to fix names with length of one. I've already tried to make x.html, and who knows how long before I find a reason for g.html, or l.html.

Anyway. I just changed the name to [xx] rather than X, and then copied XX to X. It's not perfect. Because I had to manually edit the file and when I regenerate the site next time It will just overwrite the change, and X isn't in the database as a known name. so ya. gotta fix it. bleh.

some complaints about the election results

maybe I'll be more active now that this place is set up for it.

then i had to re add the changes for the rss validation i added before.

anyway. it seems like it's working now.

i sware to god if it's not i'm going to blow something up with a kilo of thermite.

Took longer than I wanted it to, and decided to use rc rather than a c program with plan9 gui control.h

but it works if you are seeing this, because i'm using it to make this entry!

but I did finally get this working if this shows up.

altho, i still need to setup muffet to be able to handle the new date codes still so not quite done.

but this entry should still exist in the database logging when I finished this part at least

edit: looks like it mostly worked, but also has weird sideeffects.

rss "validates" now, but previously ids weren't unique and needed to be, so i changed what im using as id, and now all old posts are duplicated in newsboat. any new subscriber to the feed won't get duplicated entries, but newsboat stored the old ids. oh well.

[Python] is about the AI voice generator problems I had to deal with.

[Moving] discusses random happenings in daily life over the past while. Essentially explaining part of the recent hiatus, the rest of which had been entropy after getting out of the habit of [plan9ing].

[Queen of /g/] is about some delusions of grandure.

[Day Trip] is a wip short story of dubious historicity.

[What is a Philosopher] is a pointless question about acedemia gatekeeping terms.

[Red Queen Hypothesis] is an excerpt from Daemon.

Looking at it, it seems they scrape pages for hash tags in the content then add it to a searchable db [gemini://freeshell.defreeshell.de] . Pretty cool stuff, but the way I use tags wouldn't get picked up. So, for the purposes of gemini, I didn't really have anything for them. But, I do have a taging system, and it was an easy enough task to change how I generated the pages to make my tags "hash tags", thank [muffet] for making this a one line change.

But since I was perusing the code, I decided to fix something that had been bothering me about my gemini files for a while. I had been doing links such that when they were read out they didn't include their text in the main body. So the muffet link above would just read [2] instead of muffet[2] in the gem file. I had been dreading changing this because I thought it would be a complicated fix, but it was rather easy to do and I feel silly for putting it off. Anyway. There are some other minor things, like letting you know if a link is to an audio file or image on the link rather than it just being a blind link.

Hopefully that makes it a nicer experiance.

A darker lament about becoming senile [serious_problem]

An infohazard discussing religion and visions of the abyss [midori_loop]

Anyway, I reencoded smaller version for gemini. I think it's working?

Some other minor things. Who cares?

Tags added to basically all pages. Please be aware of nsfw tag if you care about that.

Added following pages:

[atemporal_dreamscape]

[mary]

[civ_destroyer]

[nothing_to_say]

[dime]

[ostracization]

[reboot]

[feeling_important]

[surety]

[fun_co_pop]

[taboo]

[gnawing]

[what_happened]

[in_the_data_mines]

Personally the aesthetic of the conversion is not exactly my jam, much prefering the originals, but it does get the idea across and now all the images in size add up to less than what some of them were on their own, so I can't complain about it too much when gemini is all about smol.

If you find an image that happens to be bigger than 1M you can let me[jalae_lain_casaus] know because I'm pretty sure I got them all.

It's just a little bit weird is all. There is also a problem with how feed pages generate since we are using more keys for storing metadata and the generator assumes that every key other than the main keys are links. We'll have to add in skips for the new entries.

I should also be able to put references here and they will work fine for the main article. Link to works[works].

I should also be able to make the entry type text rather than article to include an external document, and we are testing that now apparently.

Looks like the initial test does work. Well not entirely. I forgot that I am overwriting the feed.gmi that's generated automatically with one specificly formated to just include links to the feed entry pages to be in line with the gemlog format. The fact that this entry is out of order does make the gemlog look weird in a way I don't love, but it /does/ work for my feed reading software atleast, which is kinda the only point that matters for that page.

References don't work here, and we don't see any reason why we should add it, since there's little reason to include them here, rather than in the main article.