Silly software wishlist

This is an utterly pointless extension of the lion kingdom's regis protocol note.

https://hackaday.io/project/138050/log/157025-graphics-in-an-xterm

The idea is a simple 3D animated demo with a cube bouncing around.  There's no double buffering, so it would be a real clunky blinking cube.

Instead of recompiling xterm with the regis protocol, running xterm with the -ti vt340 flag, & not running screen, the same thing could be done more simply with a python library.  The only conceivable benefit to the regis protocol is displaying graphical data from a microcontroller without the hassle of making a new serial protocol with parser on the host side.  Having all the software self contained on the microcontroller would be a benefit.

There was once a real need when trying to display 2D graphics from a lidar sensor.  Normally, when lions need to visualize data on a microcontroller, the data comes out faster than the serial port can go.  Maybe it could visualize an IMU.  Microcontrollers normally want to show a voltage graph over time.  

The most obvious win would be a microcontroller oscilloscope over regis.  The lowly Rigol had only a 320x234 screen which could easily be drawn over serial port bandwidth.  The biggest challenge in a microcontroller oscilloscope is making the host software & serial protocol for drawing the waveform.

Revisiting the lion kingdom's ancient, dusty, unused thrustmaster, the thought has returned of giving it a different brain.  It was $40 at the time.  Today, it's $65, massive inflation in 3 years.  Despite it being purely a currency collapse, having something worth a lot more doll hairs after 3 years makes it feel more valuable.  Its mane problem was not working with goog Earth flight simulator or anything else.

Now that lions have implemented a HID driver for PIC & the price of joysticks is rising so fast, the idea of swapping the thrustmaster brain is a lot more tangible.  It's mane mode of operation for goog Earth would be as a keyboard.  It would require 14 digital & 5 analog pins.  A HID driver for ARM might be required.

Despite the existence of a hardware hack, there is a way to translate HID reports to a virtual HID device in software.  Linux has the https://www.kernel.org/doc/html/latest/usb/gadget_hid.html HID gadget driver.  Win has the https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/virtual-hid-framework--vhf-  Virtual HID framework.  That would require a lot of effort for Windows.  Lions would really want to use it for windows games.  

There would be more hacking to get programs to ignore the real HID driver.  X11 has option lines which keep the device around but cause the X server to ignore it.  Windows has only the disable option in its control panel, which might prevent a virtual HID driver from using it.  Games also have options to select an HID device.  On the other paw, Windows flight simulator would probably work without any hacks.  A game which didn't work was Titanic honor & glory, but it has since been pulled.

Another way is a USB host to device bridge.  That might be the best way, given the operating system variations.

A 20 year old lion with no hardware experience would have focused entirely on a software solution.

Continuing the theme of downloading segmented files

https://hackaday.io/project/138050/log/178403-download-a-segmented-video-file

The original segment downloader got updated to take a formatting code in the filename.  It replaces the formatting code with the number.

https://cdn.hackaday.io/files/1380505906331200/segments2.c

But once the segments are downloaded, you have to cat them into a single file.  The problem is numbered files get sorted with 1000 before 10.  This is a job for another program which takes another formatting code in the filename.  It cats all the files in a numerical range, replacing the formatting code with the number.

https://cdn.hackaday.io/files/1380505906331200/catnums.c

This project is over 85 logs, so it's definitely time.  Even a search engine for all the projects of a single user would be an improvement.  Of course, a simple feature like searching now requires getting bought out by google, inventing a new programming language & it has to be based on neural networks instead of strstr.

Alphabet corporation has a custom search engine service:

 https://programmablesearchengine.google.com

This one searches all mclionhead projects. It doesn't work at all:

https://cse.google.com/cse.js?cx=f89abf91874563cd5

This one searches the logs in this project. It sort of gets close, but still is a piece of $4 trillion trash:

https://cse.google.com/cse.js?cx=d6621edbd78f81ec1

It might end up being a page on a local server which loads every single log page to search for the text, just as a lion would do.

Lions have done a lot of text editing on remote consoles, manely using vi because running a graphical text editor over a network X11 connection is super slow.  There should be a way to have a persistent, graphical text editor server on the local screen.  Then a text editor client could be run remotely with a real fast shortcut like "e".  It would send the contents of the file to the server for editing.  The server would send incremental updates to the client only when the user saved the file.  This would use a lot less bandwidth than sending drawing commands to the server.

There might be a way to do it with a plugin for sublime.  Writing a text editor from scratch is a big deal.  The most important aspect for lions is speed, which makes python, javascript impractical.

Editing source code on a headless raspberry pi, with a graphical editor that runs as fast as if it was on the raspberry pi's HDMI port, would be a game changer.  Maybe there's a way such a text editor could communicate over a serial port as well as a network.  The terminal emulator would have to multiplex network packets with the console.  Multiplexing network packets with a console on a serial port could be a separate game changer.   The key is setting up the network connection quickly & automatically.

Another key feature is not keeping any file handles open.  

Since using screen, the lion kingdom has flashed back to a time when cursoring to any part of the screen was the accepted way to repeat a command or copy a line of code in BASIC. When users could no longer cursor around the screen in DOS, lions found it crippling. UNIX brought back at least a command history in the 90's, but it still wasn't the same. Screen brought back most of the functionality of the original Commodore 64, allowing cursoring anywhere in the screen. Helas, it still requires copying & pasting to repeat a command. True C64 emulation would repeat a line of text just by hitting enter on it & show the output below the current cursor position.

There is still somewhat of a desire to make an enhanced C64 shell, postfixing the UNIX prompt with "Ready.", executing commands by cursoring up & hitting enter, showing output wherever the cursor was, definitely using the original C64 font, maybe even wasting screen space on a border. It would default to 25 lines instead of 24, of course.  The optimum width for lions is 135 characters, though.

There's no useful answer for this on the internet, so the lion kingdom finally wrote a python script to do the job.  The mane reason for doing it is when the systemd scripts don't work.

#!/usr/bin/python


# start up wpa_supplicant, wait for a connection, then start up dhclient


import os
import sys
import subprocess


p = subprocess.Popen(['wpa_supplicant', 
        '-iwlan0', 
        '-c/etc/wpa_supplicant/wpa_supplicant.conf'],
    stdout=subprocess.PIPE)


while True:
    line = p.stdout.readline()
    print 'Got: ', line
    if "CTRL-EVENT-CONNECTED" in line:
        # start DHCP
        subprocess.call(['dhclient', '-v', 'wlan0'])

When this hit the news, lions thought how neat it would be to assign unique ownership to any arbitrary piece of data instead of that which is strictly a coin & to do it with no central authority.  Apparently, this utopia doesn't exist even though every crypto currency & token has been marketed as something which lacks a central authority.

NFT's are currently all managed by 1 company, rarible.com.  They manage the NFT blockchain & charge fees to convert data into an NFT.  The ownership of every NFT is logged in the etherium blockchain & there's only 1 blockchain.  The logging of all tokens in a single authoritative blockchain is what establishes ownership.  If anyone could create a new authoritative blockchain, they could define any ownership of the tokens.

The data types they support are currently just image & sound files.  More importantly, the NFT blockchain doesn't contain the full content.  It doesn't even contain a hash of the content, but contains metadata like a filename or a description.  It's all kind of a shell game.

There's no out of box software for anyone to create their own NFT blockchain & sign their own arbitrary type of data.  There are guys who show how to do it with a bunch of tools on the goo tubes, but no turnkey NFT script.

NFT's seemed a lot more practical to lions than cryptocurrencies.  It seemed like the natural evolution of cryptocurrencies was for everyone to create their own blockchain, leading to 10 billion different blockchains for new currencies with no monetary value.  An NFT in contrast, could always have some value in the form of the digital content that was originally made non fungible.

The only piece of data so far which truly can be assigned ownership without a central authority is a public/private keypair.  No matter how hard anyone tries, they can never decrypt data encrypted by the public key unless they own the matching private key, thus ownership is possible without a central authority or a blockchain.  If public keys alone were artwork & animals enjoyed staring at 2048 random bits on their screens, ownership of artwork could be easily established without a central authority.

It's not so easy to declare ownership by signing data with a private key.  Anyone else can sign the same data & declare ownership.  Only allowing the data to be viewed on a special player with a special public key has been tried before.  Even the encryption gootube uses has long been hacked.  A watermark can be taken out or 1 bit can be changed to change the owner of the watermark.

 An NFT scheme can't decide how much of a change to a piece of data constitutes a new unique piece of data.  Anyone can change 1 bit & declare ownership of the data with the changed bit.

What makes NFT's possible may be a generational shift more than a technological capability.  Generation X would say no self proclaimed authority like rarible.com or the etherium blockchain can be absolute.  Millennials view any self proclaimed authority as absolute.

Basically, a 3rd party cookie is a cookie from another website that your website is allowed to access.  Every time you go to a website, if it creates its own cookie to persistently store any data, every future website can look up all the cookies from the past websites to determine your browsing history.

These were phased out & replaced with federated learning of cohorts, which is basically a server based 3rd party cookie where goog is the only server.  The browser sends its history to the goog & the goog returns advertisements based on the history that you sent, but individual websites besides the goog don't have access to the history data.  Only the goog does.  The other twist is that the goog doesn't store any ID which uniquely ties a user to each browser history.  

This only works if the browser resends its entire history in every page load.  They could also try compressing the history locally on the browser, into some kind of hash value.  The hash value would contain enough for the server to match your history with similar histories.

It's using the power of monopolies to create some sense of privacy.  There's no reason anyone can't create a server based 3rd party cookie.  Every website can send its location & some kind of ID that uniquely identifies the user to a common server.  The server can build up the history of the ID & return it to anyone who requests it.