2025-08-30T02:40:35-07:00 gemini://cybersavior.dev/ Takarabune "gemini://cybersavior.dev/inevitability.gmi" 2025-08-30T02:40:35-07:00

inevitability[1] =>gemini://cybersavior.dev/inevitability.gmi [1] inevitability

Takarabune "gemini://cybersavior.dev/myopia.gmi" 2025-08-05T08:39:49-07:00

myopia[1] =>gemini://cybersavior.dev/myopia.gmi [1] myopia

Takarabune "gemini://cybersavior.dev/f_00150_control.gmi" 2025-07-03T14:40:19-07:00

hakama[1] =>gemini://cybersavior.dev/hakama.gmi [1] hakama Destination Void[2] =>gemini://cybersavior.dev/destination_void.gmi [2] destination_void Stop Killing Games[3] =>gemini://cybersavior.dev/stop_killing_games.gmi [3] stop_killing_games

Takarabune "gemini://cybersavior.dev/f_00145_version_3.1.gmi" 2025-06-15T08:06:30-07:00

Lots of new things. First most obviously for the HTTP users, changes have been made to the layout. While I did like the previous layout, after having someone else use the site i had to accept that the top menu was not at all obvious in function. I think anyone would be able to figure it out after using it and navigating a bit, but it could be more clear. so now it is. Now nodes "above" the current page appear on the top menu, and this node and it's siblings appear on the left, with childern of this node appearing directly below this node's listing offset to make the relationship clear. There are a few other visual changes here and there. Additionally I have finally managed to coax NAI[1] 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 : =>gemini://cybersavior.dev/f_00100_reboot.gmi [1] f_00100_reboot crisys_touwynn[2] =>gemini://cybersavior.dev/crisys_touwynn.gmi [2] crisys_touwynn ira[3] =>gemini://cybersavior.dev/ira.gmi [3] ira samurai[4] =>gemini://cybersavior.dev/samurai.gmi [4] samurai psychic[5] =>gemini://cybersavior.dev/psychic.gmi [5] psychic oracle[6] =>gemini://cybersavior.dev/oracle.gmi [6] oracle backagain[7] =>gemini://cybersavior.dev/backagain.gmi [7] backagain fungus_amongus[8] =>gemini://cybersavior.dev/fungus_amongus.gmi [8] fungus_amongus digital_algebra[9] =>gemini://cybersavior.dev/digital_algebra.gmi [9] digital_algebra The pages that were present but lacked audio and have been updated are: death_redux[10] =>gemini://cybersavior.dev/death_redux.gmi [10] death_redux mayo[11] =>gemini://cybersavior.dev/mayo.gmi [11] mayo vultures[12] =>gemini://cybersavior.dev/vultures.gmi [12] vultures gums[13] =>gemini://cybersavior.dev/gums.gmi [13] gums X[14] =>gemini://cybersavior.dev/xx.gmi [14] xx 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[15] states, if this update goes through well, we can say the new setup is "done" =>gemini://cybersavior.dev/backagain.gmi [15] backagain

Takarabune "gemini://cybersavior.dev/f_00144_fast_updates.gmi" 2025-06-01T03:20:58-07:00

it sure did take a lot longer than i'd really like but it finally works. had to rewrite src/updategemini[1] and src/updatehtml[2] to work with lsdif[3] but frankly none of this should have taken as long as I took to do it. I just couldn't find the motivation every time I looked at the code until today. one annoying thing about the code is that the var 'dst' is actually the 'src' and vice versa, it turns out I made a logic error and the easiest way to fix it was swaping the variable names from how it's actually used. (the error was that since the var dst is checked last, we are using it as the cannonical list of files which should be present. so if src has a file that dst doesn't know about we ignore it. This is a problem if i create a new entry in the site, which I do nearly every update. i may go through and rename src to dst and vice versa but 'it works' correctly as it is =>gemini://cybersavior.dev/src/updategemini [1] src/updategemini [binary] =>gemini://cybersavior.dev/src/updatehtml [2] src/updatehtml [binary] =>gemini://cybersavior.dev/lsdif.gmi [3] lsdif

Takarabune "gemini://cybersavior.dev/f_00143_denpav.gmi" 2025-05-27T19:44:07-07:00

this is the same link shared with n0 for denpa 2. it's long and kinda shit. jlc2025_720x480[1] =>http://archive.org/details/jlc2025_720x480 [1] [archive.org]

Takarabune "gemini://cybersavior.dev/f_00142_lo.gmi" 2025-05-26T04:08:09-07:00

There is now a low bandwidth/easy to read version of the site which does not include any background images nor font changes (it does still include embedded images and requestables (such as audio files). instead of using www for the domain use lo instead lo.cybersavior.dev[1] . if you subscribe to RSS[2] using the lo version the links will take you to the lo version of the pages. well it should be. rss validators are all saying it works correctly, however opera does not. idk. let me know somehow if it's not working for you somehow. (email is down atm. i'm sure anyone who would read this would be able to find /some/ way to get a message to me. plenty of glass bottles on the beach) =>http://lo.cybersavior.dev [1] =>gemini://cybersavior.dev/links/rss.xml [2] RSS [binary]

Takarabune "gemini://cybersavior.dev/f_00141_back.gmi" 2025-05-21T01:33:30-07:00

it has taken far too much time to get this to the point it is, but hopefully it has worked. 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.

Takarabune "gemini://cybersavior.dev/f_00140_muffet_update.gmi" 2025-05-19T04:02:00-07:00

if this worked then muffet[1] should now only update the pages that have actually changed since the last time it has run. preliminary tests are hopeful, but adding this and seeing if it has the most recent creation date and nothing else will be the final confirmation i need. once this is in place i'll be able to move on to the next stage. i know you won't see this for a couple days. such is the way of things when nothing goes the way it should. sigh =>gemini://cybersavior.dev/muffet.gmi [1] muffet 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[2], as well as changes tagrank[3] 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) =>gemini://cybersavior.dev/feed.gmi [2] feed =>gemini://cybersavior.dev/tagrank.gmi [3] tagrank

Takarabune "gemini://cybersavior.dev/f_00135_downtime.gmi" 2025-05-13T01:12:32-07:00

hopefully not for very long, but depending on how much of a nightmare it will be it could be longer. we are going to be fully updating the core infrastucture for both myugii[1] and temuorin[2], 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. =>gemini://cybersavior.dev/myugii.gmi [1] myugii =>gemini://cybersavior.dev/temuorin.gmi [2] temuorin for more detailed explaination. myugii and temuorin are both running quite old versions of 9front[3] 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' =>gemini://cybersavior.dev/plan9.gmi [3] plan9 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[4] 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[5] and muffet[6] 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 =>gemini://cybersavior.dev/gemini.gmi [4] gemini =>gemini://cybersavior.dev/slov.gmi [5] slov =>gemini://cybersavior.dev/muffet.gmi [6] muffet

Takarabune "gemini://cybersavior.dev/gums.gmi" 2025-05-07T01:29:06-07:00

gums[1] =>gemini://cybersavior.dev/gums.gmi [1] gums 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. . . .

Takarabune "gemini://cybersavior.dev/vultures.gmi" 2025-04-19T01:19:36-07:00

vultures[1] =>gemini://cybersavior.dev/vultures.gmi [1] vultures

Takarabune "gemini://cybersavior.dev/f_00132_tagrank.gmi" 2025-01-12T19:21:53-08:00

New page I've been thinking about adding for a while and just decided I should do now. 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[1] and a decent way to start navigation through the tag system[2]. 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. =>gemini://cybersavior.dev/tagrank.gmi [1] tagrank =>gemini://cybersavior.dev/tags.gmi [2] tags 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[3] and slov[4] higher up in the list than ideal, but it's fine. safe[5] will probably be at the top followed by nsfw[6] 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.) =>gemini://cybersavior.dev/muffet.gmi [3] muffet =>gemini://cybersavior.dev/slov.gmi [4] slov =>gemini://cybersavior.dev/safe.gmi [5] safe =>gemini://cybersavior.dev/nsfw.gmi [6] nsfw 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[7] =>gemini://cybersavior.dev/tagrank.gmi [7] tagrank

Takarabune "gemini://cybersavior.dev/f_00131_fundamental_composition.gmi" 2025-01-08T02:24:56-08:00

We shall keep this brief. 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.

Takarabune "gemini://cybersavior.dev/mayo.gmi" 2024-12-27T10:22:44-08:00

mayo[1] =>gemini://cybersavior.dev/mayo.gmi [1] mayo

Takarabune "gemini://cybersavior.dev/denpa_webring.gmi" 2024-11-25T08:34:30-08:00

denpa_webring[1] =>gemini://cybersavior.dev/denpa_webring.gmi [1] denpa_webring

Takarabune "gemini://cybersavior.dev/f_00124_not_sure_why.gmi" 2024-11-13T03:14:57-08:00

I already have the ability to make blog[1] like entries under feed[2] and i don't even need to touch the indental[3] files to do that. I don't even need to open acme. and since rc in rio has full mouse chording and editing higher up in the buffer it'ts actually a pretty decent experiance. The down sides is that i can't use the more fun features of plan9 acme[4], like pipeing selected text to commands and having it be auto replaced by the result. but I got by without that kind of stuff before anyway. =>gemini://cybersavior.dev/blog.gmi [1] blog =>gemini://cybersavior.dev/feed.gmi [2] feed =>gemini://cybersavior.dev/indental.gmi [3] indental =>gemini://cybersavior.dev/plan9.gmi [4] plan9 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[5] entries, and instead I can use all the shortcuts for links and such properly. =>gemini://cybersavior.dev/muffet.gmi [5] muffet I already have the blog section so I guess I will keep it. But also Since law order[6] is boring, I will also be putting what are ostensibly blog updates here as well. =>gemini://cybersavior.dev/law.gmi [6] law

Takarabune "gemini://cybersavior.dev/f_00123_dumb.gmi" 2024-11-11T08:41:36-08:00

Aparently something in my slov/muffet processing flow doesn't tolerate entry names with length of one. I tried to make a post with the name X and it fails. I dug into muffet a bit and don't think that is where the problem is, but maybe it is. It does get stuck trying to cannonize the string (cannonizing is a process of takeing a string like 'HeLLo ThErE' and changing it to the cannon name for that entry in the database -> 'hello_there') 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[1] 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. =>gemini://cybersavior.dev/xx.gmi [1] xx

Takarabune "gemini://cybersavior.dev/xx.gmi" 2024-11-11T01:00:10-08:00

xx[1] =>gemini://cybersavior.dev/xx.gmi [1] xx

Takarabune "gemini://cybersavior.dev/elections.gmi" 2024-11-07T08:09:38-08:00

elections[1] =>gemini://cybersavior.dev/elections.gmi [1] elections some complaints about the election results

Takarabune "gemini://cybersavior.dev/new_hole.gmi" 2024-11-03T07:22:42-08:00

new_hole[1] =>gemini://cybersavior.dev/new_hole.gmi [1] new_hole maybe I'll be more active now that this place is set up for it.

Takarabune "gemini://cybersavior.dev/f_00115_slov_and_muffet_edits_for_new_time_stamps.gmi" 2024-07-25T23:48:54-07:00

well, i finally got muffet working with the new time stamps. I ended up getting so messed up i ended up needing to throw all my edits from the past 5 days and starting over. It definitely went easier this time, but in fixing it, i realized there were some issues that i baked into slov, and then worked around in my previous iteration of muffet, so fixing the problem in slov meant redoing a decent amount of basically all of muffet. It wasn't that bad, since it was the same thing just in about 15 places. running the program it it hung then loading acid to figure out where it was hanging then making the change. compile rinse repeat. 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.

Takarabune "gemini://cybersavior.dev/feeder.gmi" 2024-07-25T08:15:20-07:00

feeder[1] =>gemini://cybersavior.dev/feeder.gmi [1] feeder 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!

Takarabune "gemini://cybersavior.dev/f_00113_new_feed_entry_method.gmi" 2024-07-24T23:02:49-07:00

It's been a few days to do this thing that I thought would be easily done in like 1 hour... 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

Takarabune "gemini://cybersavior.dev/f_00112_testing_new_rss_gen.gmi" 2024-07-20T12:00:00Z

previously manually edited the rss to fix problems in the generation. now testing changes to muffet[1] to correctly generate rss. atom is also getting a fix here that was causing the body of the news to be duplicated, but otherwise i'm leaving it alone because i was only fixing rss and rss also had this problem and the fix applied to both. =>gemini://cybersavior.dev/muffet.gmi [1] muffet 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.

Takarabune "gemini://cybersavior.dev/f_00111_more_stuff.gmi" 2024-06-18T12:00:00Z

Adding a few things I wrote in the past while. Python[1] is about the AI voice generator problems I had to deal with. =>gemini://cybersavior.dev/python.gmi [1] python Moving[2] 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[3]. =>gemini://cybersavior.dev/moving.gmi [2] moving =>gemini://cybersavior.dev/plan9.gmi [3] plan9 Queen of /g/[4] is about some delusions of grandure. =>gemini://cybersavior.dev/queen_of_g.gmi [4] queen_of_g Day Trip[5] is a wip short story of dubious historicity. =>gemini://cybersavior.dev/day_trip.gmi [5] day_trip What is a Philosopher[6] is a pointless question about acedemia gatekeeping terms. =>gemini://cybersavior.dev/what_is_a_philosopher.gmi [6] what_is_a_philosopher Red Queen Hypothesis[7] is an excerpt from Daemon. =>gemini://cybersavior.dev/red_queen_hypothesis.gmi [7] red_queen_hypothesis

Takarabune "gemini://cybersavior.dev/kamidori.gmi" 2024-06-15T12:00:00Z

n0 thanks to y0u i have been reminded i havn't submitted any posts here in a while. rss[1] has been broken apparently forever? I didn't notice because it literally was the difference between a 'd' and 'D' and my rss reader didn't give a shit about that. Anyway, I will have fixed that with this post. Also I use AI voice reader for posts, and it broke since my previous post. That has been annoying to fix. slightly updated model now (the ominous groaning intermitantly should be gone now, part of me liked it tho, because it was spooky[2]. But more about that later. =>gemini://cybersavior.dev/rss.gmi [1] rss =>gemini://cybersavior.dev/spoopy.gmi [2] spoopy

Takarabune "gemini://cybersavior.dev/knives.gmi" 2023-12-07T12:00:00Z

Just a post about a trip through the knife rabbit hole.

Takarabune "gemini://cybersavior.dev/f_00104_minor_gemini_changes.gmi" 2023-11-30T12:00:00Z

Saw that a crawler had been looking at my gemini pages, because it was kind enough to include it's name in a request (it loaded a page like 'gemini://cybersavior.dev/robots.txt?gemini://their.gem/faq') Looking at it, it seems they scrape pages for hash tags in the content then add it to a searchable db freeshell.de[1] . 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[2] for making this a one line change. =>gemini://freeshell.de [1] freeshell.de =>gemini://cybersavior.dev/muffet.gmi [2] muffet 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.

Takarabune "gemini://cybersavior.dev/f_00103_a_happy_update.gmi" 2023-11-30T12:00:00Z

A light talk about the good things about steven_universe[1] =>gemini://cybersavior.dev/steven_universe.gmi [1] steven_universe A darker lament about becoming senile serious_problem[2] =>gemini://cybersavior.dev/serious_problem.gmi [2] serious_problem An infohazard discussing religion and visions of the abyss midori_loop[3] =>gemini://cybersavior.dev/midori_loop.gmi [3] midori_loop

Takarabune "gemini://cybersavior.dev/f_00102_slow_gemini.gmi" 2023-11-23T12:00:00Z

I have been annoyed with how slow gemini has been loading. Even with the smaller MP3s it's taking /way/ too long to load. Turns out proxying all network activity on a port across the world and doing all access through p9 is just terrible for performance. I bit the bullet and transfered all the gemini files to temuorin[1] and am now running the gemini server only using local files. It is /much/ faster. I was really not wanting to do this tho, because now it means my workflow now has to include moving files onto temuorin[2]. I can do some clever rimporting and binding to make it work without needing to do a lot of busy work, or I could set up a cron job to automatically clone things over daily or something. sigh. =>gemini://cybersavior.dev/temuorin.gmi [1] temuorin =>gemini://cybersavior.dev/temuorin.gmi [2] temuorin

Takarabune "gemini://cybersavior.dev/f_00101_some_gemini_fixes.gmi" 2023-11-21T12:00:00Z

Gemini has been running on myugii[1] for the past week or so. It's working well enough. There was a bit of an issue with the media directory after setting things up, so none of the images were working right. That's been fixed now. I noticed after getting that working that the audio[2] files were taking /forever/ to download. They aren't big or anything, and on "web" browsers that support streaming audio, it's not a big deal since as soon as it gets enough bytes to start playing, it just starts and downloads the rest as it plays. La grange doesn't seem to support streaming audio? =>gemini://cybersavior.dev/myugii_fannan.gmi [1] myugii_fannan =>gemini://cybersavior.dev/audio.gmi [2] audio Anyway, I reencoded smaller version for gemini. I think it's working? Some other minor things. Who cares?

Takarabune "gemini://cybersavior.dev/reboot.gmi" 2023-11-08T12:00:00Z

Narration added to essentially all writings. Tags added to basically all pages. Please be aware of nsfw tag if you care about that. Added following pages: atemporal_dreamscape[1] =>gemini://cybersavior.dev/atemporal_dreamscape.gmi [1] atemporal_dreamscape mary[2] =>gemini://cybersavior.dev/mary.gmi [2] mary civ_destroyer[3] =>gemini://cybersavior.dev/civ_destroyer.gmi [3] civ_destroyer nothing_to_say[4] =>gemini://cybersavior.dev/nothing_to_say.gmi [4] nothing_to_say dime[5] =>gemini://cybersavior.dev/dime.gmi [5] dime ostracization[6] =>gemini://cybersavior.dev/ostracization.gmi [6] ostracization reboot[7] =>gemini://cybersavior.dev/reboot.gmi [7] reboot feeling_important[8] =>gemini://cybersavior.dev/feeling_important.gmi [8] feeling_important surety[9] =>gemini://cybersavior.dev/surety.gmi [9] surety fun_co_pop[10] =>gemini://cybersavior.dev/fun_co_pop.gmi [10] fun_co_pop taboo[11] =>gemini://cybersavior.dev/taboo.gmi [11] taboo gnawing[12] =>gemini://cybersavior.dev/gnawing.gmi [12] gnawing what_happened[13] =>gemini://cybersavior.dev/what_happened.gmi [13] what_happened in_the_data_mines[14] =>gemini://cybersavior.dev/in_the_data_mines.gmi [14] in_the_data_mines

Takarabune "gemini://cybersavior.dev/muffet.gmi" 2023-10-27T12:00:00Z Takarabune "gemini://cybersavior.dev/uxn.gmi" 2023-04-01T12:00:00Z Takarabune "gemini://cybersavior.dev/clones.gmi" 2023-03-15T12:00:00Z Takarabune "gemini://cybersavior.dev/f_00052_mogrify.gmi" 2023-03-15T12:00:00Z

At the prompting of someone I agreed to reduce the image resolutions and color space. Used imagemagick mogrify to posterize to 8 colors + dither and size of 800 width. This reduces all the images to less than 1M and in most cases to less than .5M. 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 mejalae_lain_casaus[1] know because I'm pretty sure I got them all. =>gemini://cybersavior.dev/jalae_lain_casaus.gmi [1] jalae_lain_casaus

Takarabune "gemini://cybersavior.dev/f_00051_text_that_is_a_feed.gmi" 2023-03-14T12:00:00Z

If everything works the way that I expect it to with regards to this post it means that this will show up as a child of feed, which makes it a feed entry that will show up in the feed list, but it may be out of order in the gemini entries, since I use alphabetic ordering and numeric names to keep them in order. Any feed reading software shouldn't rely on the order of items, and use the date value for sorting however, so that really shouldn't be a huge problem. 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 worksworks[1]. =>gemini://cybersavior.dev/works.gmi [1] 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.

Takarabune "gemini://cybersavior.dev/feed.gmi" 2023-03-14T12:00:00Z

If everything went well this should show up in the description. 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.

Takarabune "gemini://cybersavior.dev/home.gmi" 2023-03-13T12:00:00Z Takarabune "gemini://cybersavior.dev/muffet.gmi" 2023-03-01T12:00:00Z Takarabune "gemini://cybersavior.dev/home.gmi" 2022-12-24T12:00:00Z Takarabune "gemini://cybersavior.dev/my_hero.gmi" 2022-11-24T12:00:00Z Takarabune "gemini://cybersavior.dev/tags.gmi" 2022-06-20T12:00:00Z Takarabune "gemini://cybersavior.dev/helion.gmi" 2022-06-16T12:00:00Z Takarabune "gemini://cybersavior.dev/about.gmi" 2022-06-15T12:00:00Z Takarabune "gemini://cybersavior.dev/my_hero.gmi" 2022-06-11T12:00:00Z Takarabune "gemini://cybersavior.dev/lite.gmi" 2022-06-05T12:00:00Z Takarabune "gemini://cybersavior.dev/my_hero.gmi" 2022-05-19T12:00:00Z Takarabune "gemini://cybersavior.dev/my_hero.gmi" 2022-05-19T12:00:00Z Takarabune "gemini://cybersavior.dev/my_hero.gmi" 2022-05-17T12:00:00Z Takarabune "gemini://cybersavior.dev/video.gmi" 2022-05-17T12:00:00Z Takarabune "gemini://cybersavior.dev/helion.gmi" 2022-05-15T12:00:00Z Takarabune "gemini://cybersavior.dev/tags.gmi" 2022-05-03T12:00:00Z Takarabune "gemini://cybersavior.dev/ego.gmi" 2022-04-29T12:00:00Z Takarabune "gemini://cybersavior.dev/heavy.gmi" 2022-04-26T12:00:00Z Takarabune "gemini://cybersavior.dev/newgate.gmi" 2022-04-25T12:00:00Z Takarabune "gemini://cybersavior.dev/oldgate.gmi" 2022-04-22T12:00:00Z Takarabune "gemini://cybersavior.dev/kagami.gmi" 2022-04-20T12:00:00Z Takarabune "gemini://cybersavior.dev/my_hero.gmi" 2021-07-30T12:00:00Z Takarabune "gemini://cybersavior.dev/journal.gmi" 2021-07-27T12:00:00Z Takarabune "gemini://cybersavior.dev/renewables.gmi" 2021-04-26T12:00:00Z Takarabune "gemini://cybersavior.dev/death.gmi" 2021-04-23T12:00:00Z Takarabune "gemini://cybersavior.dev/oscean.gmi" 2021-04-18T12:00:00Z Takarabune "gemini://cybersavior.dev/oscean.gmi" 2021-04-16T12:00:00Z Takarabune "gemini://cybersavior.dev/album_on.gmi" 2021-04-15T12:00:00Z Takarabune "gemini://cybersavior.dev/stand_alone.gmi" 2021-04-12T12:00:00Z Takarabune "gemini://cybersavior.dev/oscean.gmi" 2021-04-10T12:00:00Z Takarabune "gemini://cybersavior.dev/takarabune.gmi" 1986-04-14T12:00:00Z