The course of the world through directory names

Although I often tend to praise the PUNTER protocol and likely ran the first ever IEEE 802.11# file transfer using said protocol in this home last decade, I believe it is appropriate to give similar accolades to ZMODEM. This year it is 40 years ago since it was developed by Chuck Forsberg (R.I.P. - no known relation) and the ZMODEM transfer protocol was regarded by many as a game changer.

Anyhow, the public demand to understand how a new directory is created in the Cyborg/HM*Mod of C*Base running on c64 Original ChipSet is quite high (that is, Harzilein and Dr.Doom asked). Thus, before I likely migrate the Boar's Head Tavern to the Larry*Mod of C*Base and run it on an Ultimate64 (Gideon Zweijtzer), I was asked to document it. The reason for that expected migration is mainly because the soon 45 year old chips are getting increasingly unstable running 24/7 (firsthand especially from temperature/seasonal changes), and because of the daily time consuming labour of managing uploads due to the "clusters interpreted as blocks on SD2IEC"-issue in the old C*Base. That manual work of zen routine could have be explained elsewhere (but might probably be deduced from what is written a few paragraphs further down).

One needs to understand that when the user reads the directory in C*base ("$") they are not shown the actual files in the partition/folder, but rather a file that is created by C*Base which does not include certain hidden things. That file, UD-#, is regenerated* after each upload. The SysOp (and CoSysOp) can venture behind the scenes though, and access the real directory with the actual files, going into Exchange Mode. Totally doable on a 1MHz and 64K of RAM machine, also at 2400 baud if necessary.

The bigger and longer that UD-#-file becomes, the clumsier the system gets. For that reason, since I launched the bulletin board and resurrected the Boar's Head Tavern, I have needed to clear the directory for fresh stuff every 9-12 months or so. This time dir#1 (called Young Malts) had reached 617 files since July last year, and the daily zen routine was getting very slow. Consequently Young Malts needed to become "emptied into" dir#9 (Hormuz):

First the entire system gets a backup and then a new partition is created. Back in C*Base a few lines in STATS need to have their parameters rewritten and pointers to the new directory added. As I have had the old c64 system crashing numerous times (ofttimes with the need for rehacking) I now know STATS by heart, but otherwise I would suggest the C*Base v3.1 Holy Moses Mod Guide for SysOps. Files can easily be moved from the Young Malts- to the Hormuz-folder, and protocol-files copied from the other partitions, but the HM*Mod will not accept that the UD-#-file just gets renamed (i.e. UD-1 to UD-9), at least not under SD2IEC (and likely because of a similar interpretational error - fixed in Larry*Mod I am told). One needs to regenerate a new directory-file (both in dir#1 and in this case, in dir#9) with the correct command. Where dir#1 is empty as it should be, and ready for fresh and hot warez, dir#9 also seems empty for the common user. That is because UD-9 has not been populated.

Alas, now this old beauty really does show its turpitude. 617 files via Exchange Mode to UD-9, and experience has told me that more than 60 files at a time causes the system to crash. Initially the process goes quite fast, a few seconds per file, but soon 15 and 30 and 45 seconds per file. When the final batches of 60 files/sizes are added to the UD-file, they usually take an hour or so each.

Meanwhile, this one-node SoMe is of course down and no carrier is available. Plentiful eager nerds (including Cjam) do not fret though, they will have a few pints and try again later.

The Boar's Head Tavern is now invigorated and ready for another summer of 64.

*Update 230526: Larry informed me that if a person uploads a file to any of the BBS directories, information about that file is written (added!) to the corresponding sequential file called UD-#. Thus it is not rebuilt each time a new file is added. Any 3.x C*BASE version adds the following info to the file per new upload: call number, current date, filename, filetype (PRG or SEQ), file size in blocks. Some versions also add an optional file description to be written by the user uploading.

Fun fact: The amount of disk blocks for a file is calculated in the BBS by subtracting free blocks after successful upload from free disk blocks before upload (stored in a variable). For this reason it will not work on media which does not report free blocks. This is changed in his modification to what CoSysOp and myself currently perform by hand as the zen routine.

"AI" bots grasping at straws in a confident manner

From a recent pluralistic-post: "AI is the asbestos we're shoveling into the walls of our high-tech society". 

The past month I have come to understand that not only my usual ranting on how "AI" is dumbing down the population and seems to surgically remove analytical thinking from people holds true, but that we are soon running into a situation where one cannot get actual assistance for an issue one is seeking help for. 

Let me elaborate. The background of the story is that the domain registrar and host of an old webspace of mine did some internal migration/change of infrastructure. A lot of the things on my page stopped working. They were still in the file manager, some of them untouched for twenty-five years, but the web addresses did not work. I will admit that back then it was perhaps an odd thing to "merge" my homepage with a blog, and have the icons point to what is on "my page" from a front mainly being on blogger, but not rocket science. I reckoned back then that it was merely web addresses I kept under control. It worked and had done so up until a month ago. 

Together with unnamed old friends in the nerdy hacksquad some things could be deduced: Subdomains did not work anymore, but did as subdirectories - remedied by me retouching code from 2000 to 2008, changing hundreds and hundreds of lines, HTML programming 90s style. Other things were due to snippets on blogger that needed to be fixed in order to run security protocols. Etcetera. 

Regarding the main issue however, we were clueless. I asked the technical support of the mentioned web hotel (whom had hosted my page since two decades, before then I had it at a UK-based firm and some of it even came from an old one at geocities - remember those?) and got advice all over the place - and I trusted it as I would if talking to a real person. PHP needed updating, DNS redirection faulty, CNAME pointing the wrong way - all with the assertiveness that if I change this and that, things will for sure work again. The problem was that each time I listened to their advice it either made things a little bit worse, or stopped the page from working altogether. 

The thread grew longer, back and forth. Sometimes I got a message that actually seem to come from a human being and was helpful, but other times it just seemed to be "AI" grasping at straws in an assuring manner. The main issue is still there though. I believe the problem might lie in a configuration file I do not have access to under file manager which manages directories (analogous to the blocks/cluster-issue on my c64 bbs). It redirects incorrectly and I get the notion that the computer running the bot is incapable of introspection. The last response I got had literally nothing to do with the very specific question I asked and exemplified - and seemed to have nothing to do with what was touched upon earlier in the thread. 

I guess "AI" support bots are only useful if they can use the documents they are trained on for answers, and they are unable to help with a real issue. They come with unfocused brainstorming at best, but often choosing random keywords and explaining from that with extreme confidence (albeit contextually erroneous). It is very often totally irrelevant and not at all addressing the issue we are trying to solve. Perhaps it is the lack of "we" that is the issue, as I am a human and am communicating "with". 

Now I am not a programmer, but a neurologist. Nerding around with geezers into low-level programming for more than three decades has left some traces in me though - but imagine if I was oblivious. Then please extrapolate the moral of this story to everyday internal medicine or my own field - or any other area of expertise for that matter. I am glad that I am using energy to communicate "with" my patients. 

From the same earlier mentioned pluralistic-post: "Code is a liability (not an asset). Tech bosses don't understand this. They think AI is great because it produces 10,000 times more code than a programmer, but that just means it's producing 10,000 times more liabilities. AI is the asbestos we're shoveling into the walls of our high-tech society". 

My Datagubbe friend has expounded more on the matter under Jonesing For The Next Disruptor. 

Keep thinking for yourself! A few years ago I wrote that when disruption trumps proven experience stupidity reigns. It creates impractical and often absurd scenarios but is fabulous for imagining fantastic promises no one can fulfil - because fantasy is not knowledge.