cat Φ > /dev/wrld

Welcome to the on-line public archive of my notes and more comprehensive writings.

2019-raw.md

On program state

I think program state is an interesting thing. In my experience it isn’t thought much about by most software engineers/developers, but I believe that state is something that may be useful to consider more widely as a real property of a system. Not just as a fleeting moment in the execution of a program.

You may encounter isolated state in the form of complete model as state i MVC frameworks or the data property - as it’s used in Vue.js. I’ve started to think about state in the form of recorded state transition as is used in languages like clojure and other immutable, append only, collections of data. This does spark my imagination. When working with an arbitrary set of user interfaces the state of the whole system may be contained and thus be made addressable. In other words; Not isolated to one single application. This reveals some interesting properties. One might use whole system state as universal undo for large systems. This ties into the concepts by Jeff Raskin where people using machines has access to universal undo for everything. When elaborating the application of state transfer one might see the usefulness of sending whole system state or a subsection to someone or something else. In a way state for a single user interface surface, when transferred to a remote machine, is just the same as storing that piece of information in a storage service - such as a filesystem or a database. In that way all that’s involved in the process of running software and keeping track of information is in it’s entirety just state transition and transfer.

I’ve searched a lot for simple operating systems and in these searches I’ve found references to Plan9. Plan9 has a really neat idea when it comes to operating system borders and containment. Now a days, in 2019, all the dominant platforms out there run everything a “user” does on the local machine - except for software as a service - and no part of the system shares state with any other part horizontally. The Plan9 folks had a different idea. In Plan9 the operating system can be spread across many machines. A liberating concept really I believe. I imagine that this would free us greatly from the need to centralize computing resources locally to a single machine. For the operating system interface one might need graphics power - which is not available over network connections in a reliable and responsive way. For almost everything else one might use other machines, even shared machines to do everything else - except to run the display.

The separation of display and other resources reminds me of how things where done up until the 90s - and up to the 2000s in some enterprises. Time sharing systems or variations of systems which used terminals for interaction display+input devices. Except one important property, this variation of building systems could be decentralized from the bottom up. And with true decentralized systems all data is replicated and no machine makes a single point of failure.

Now, back to program state. If program state is distributed one might play with the idea that several people may share the complete system state, which makes collaboration a basic feature of the operating system. This could be really useful. How may collaboration systems haven’t you tried which does a half decent job and a really bad job at what hasn’t been tried by the ones who wrote that collaboration system?

I’ll be working this way of state handling into coming systems as a primary feature so they may leverage state distribution mechanisms without modification.

If you write software you might have a lot of ideas to try out now so I’ll let you get to it.

On system design

Systems are constructed of a software system and the configuration of host systems. Examples of host systems are machines, containers, web browsers and interpreters as well as combinations/composites.

Systems should be constructed to be beautiful. This makes systems pleasing to work with, think about, reason about and will in effect minimize the burden of maintenance.

Practice

Please

Tips: When writing working functionality, don’t stop when it’s working, stop when it’s refined and still working.

On sustaining an organization

On cyberpunk

Cyberpunk in its current form was largely formed by William Gibson in the 1984 work Neuromancer. Cyberpunk is a subculture, based in fiction, which uses and invents cutting edge technology combined with the punk mindset.

Cyberpunk and hacker culture has clear connections. The punk mindset of the hacker is clear through anti-authoritarian and subversive hacks/actions and general attitude. There’s been a lot of newly formed subcultures and movements with connections to cyberpunk. Subculture members like cypherpunks, bio-hackers and cybergoths all hold cyberpunk ideals high.

The subculture as genre has a number of books, film, movies and series all within the same theme. If there’s one series I’d like to point others to,who might have some interest in philosophy or psychology as well, it must be Serial Experiments Lain.

For me as a software developer it feels liberating to remember where my interest sparked from. Reading material like the blue and orange book, and having the feeling of constant discovery when exploring systems. For me it’s also a way to keep my sanity.

On freedom

Everyone should rightly be free. By free I mean free in its largest extent.

I believe that everyone should at least have the following freedoms.

Freedom to choose:

Freedom to do:

Freedom to be:

On reuse

I try to reuse rather than throw away. This is most apparent in the form of furniture, used and repurposed but also in my projects of many sorts. When I don’t reuse or re-purpose I try to reuse by deconstructing and using the materials. Since the country I live in, Norway, has limited supplies for DIY-projects I keep disassembling things and storing materials for later use.

Tools are important when you’re reusing a lot and building things. I find hand tools like planes, chisels and Japanese razor saws essential. I also have power tools to help out when the manual labor would be troublesome. Since I live in a block with a lot of neighbors I often try to keep power tool usage to a minimum. Anyways; Using hand tools is often rewarding in itself.

On imperfection

I’ve been a perfectionist as long as I can remember. In recent years I’ve learned to see perfection in imperfection.

Ever since I discovered Japanese wabi sabi, had contact with weathered wood and building material I’ve discovered that it too can be perfect in the sense of beauty. My perfectionist lean is in a sense more about aesthetics and beauty than “newness”/“prestinety”.

Imperfections often appear by use and general ageing. They often hold stories and further a history. I value history and thereby I value imperfection.

On “béton brut”

“Béton brut”, or brutalism, is an architecture style that you either hate or love. I, myself, most of all - love it. I don’t know if it’s my love for Utopian/dystopian aesthetics that shine through or my love for minimalism that makes me have fuzzy feelings for it’s rawness, either way - the love’s there.

Yes, I know, it’s not environmentally sane to make huge concrete structures. Often than not far greater than necessary. But I find it aesthetically pleasing. I see its history and sort of optimism and I value it. Its greatness, I think, is on par with the grand buildings of Albert Speer - which is an architect that has inspired many after him.

Recently I’ve looked into brutalist web design and I find it in line with my own opinions on web design. Do it yourself, keep it to a minimum and make it solid and consistent. The only part that I find a bit off right now is the introduction of more than a couple of strong colors and to introduce unnecessary messiness in grids where elements are made to overlap - as if by accident.

On hardware

On the use of computing devices

So many have forgotten what actions computers are able to perform. The move to mobiles and other locked down devices like chromebooks, tablets and light laptops have taken away the power of a general computing device and replaced it with service consumer interfaces. In the perspective of liberty, device adaptability and owner control the current situation is dire.

When everything tries to be everything you’ve got 4 devices at a minimum which needs to cross sync and you’ve probably wasted a heap of money paying for 3-5 cameras, 4 flash based memory devices for storage and 3 incompatible operating systems when you really only need one of each. When it comes to operating systems it is always preferable for the one or a small set to be completely compatible. It’s convenient for large scale device producers that everyone has gone alone with their plan, since they get to sell a lot of electronics, but it might not be what we really want.

I’ve gone to some length simplifying what devices I own to escape all the problems most people I know struggle with. I’ve got an old thinkpad as my computer, running GNU/Linux-libre with a minimal setup that doesn’t get in my way. The phone I’ve got is a simple candy-bar phone, I use it to call and send SMS-messages. I need a single good camera to document projects I’m doing and one that supports video over USB to I may use it for video-calls. I will acquire a camera sometime in the near future. If it’s possible to also control capture via software that would be the ideal solution for me.

I’m not on centralized social media. For those who don’t know, centralized social media is a trap. They make money off your uploads and sell off their surveillance data of you and your internet browsing. I’ve deleted my google-account since they signed the pentagon drone AI contract and I don’t use their search engine, not bing’s and not yahoo’s.

I guess I’ve opted out of what most people swear to as their “digital life”. I’m involved with and develop free libre software, spend my time writing without a connection to the internet and I communicate with others over decentralized platforms.

I believe that a whole lot of people would be happier if they where in control of their own data, without surveillance and able to publish what they with without consent or fear of being taken down blocked out of the “public space” (in their world centralized platforms like YouTube, Facebook and so on).

For those of you who are curious please take a look at these sites so you might learn more in depth about decentralization and control of your own computing:

https://beakerbrowser.com
https://www.gnu.org
https://datproject.org
https://protocol.ai
https://joinmastodon.org
https://gnu.io/social
https://liberapay.com
https://freenode.net

On workstation software and configuration

As in everything regarding system configuration I keep my work station configuration minimal and clean. I use software and tools that do what I want them to do, and not much more. I keep my data, backup of online data and what I’ve produced myself, backed up and what I use from day to day as a local copy.

General software I use:

Specialized software I use:

On free software

Since I seek freedom in every area the most natural choice in the world for me is to use free libre software. Even though I formulate words wisely and argument somewhat concisely I leave all explication of the benefits of using free libre software up to the GNU foundation. Please see gnu.org and in particular gnu.org/philosophy.

On system composability

When designing systems you will save yourself a huge amount of work if you design for system composability. Large systems becomes more manageable when they are composed of loosely coupled parts instead of duplication in its many forms. If there is a need for deviation from normal input and output of a function/service the service could easily be wrapped in a workload pre- and post-translator and you are still able to reuse the underlying service unchanged.

On custom software in medium to large organizations

The software world is packed full of special case usage and duplication’s. I’ve seen custom software in large organizations duplicating the same functionality many times over in a variety of systems just because there are different “solution” providers involved. Whenever you’ve got someone developing software and not talking to each other you as a customer/contractor will pay for the same functionality many times over.

On code generation

Most systems based on the same system architecture involves roughly the same static and movable parts. These parts are often largely generic, but still a lot of developers insist in writing their own implementation for everything. As the one writing the code you should also be somewhat fluent in the possibilities in system configuration and possible setups for functionality like file system replication and deduplication so you’ll know there is no need for you to implement such hard to design functionality solely in your software. Generic services are perfect to adapt to systems via configuration or code generation. Code generation could be done when systems start up or as a implementation step in advance of normal system runtime. Some data set or configuration must be read and the code is generated from a interaction using a set of rules for the generation. Code generation allows for service regeneration and adaptation due to changes to data set and configuration. This can be taken further as to include things like service and interface descriptions so a system may be updated to adhere to a new standard without changes or in the worse case rewrites. You drop in the new specification and tell the service to update, there you have it - system confines to the updates in the standard.

There are a whole lot of software available to make adaptable systems. LISPs are good at this. The only code needed for a generated service should be the parts that generates code and launches the service. This is somewhat counter intuitive to most software developers, it’s not a part of the standard curriculum for those with engineering backgrounds and it’s not that common to end up in a job that require a huge portion of creativity and out-of-the-box thinking.

On the illusion of (the tiny) self

The false/tiny self is in psychology the illusion of self hood. Apposed to the real/higher self it sits as the concept most people in western society identify as themselves.

It’s so common now a days, even more after the advent of the selfie-mindset, that people don’t even see their real self. Advertising and other outside influences makes people less in contact with their path in life and leads them away from feeling true purpose. I believe that this has devastating effects for people as well as society and our civilization.

On propaganda (also called public relations (PR) / advertising)

If you have little knowledge about it and look into its history I bet you’ll be surprised. The propaganda of the start of the 19Th century (and a bit before, as it always is with history) was formed to influence people as much as possible to your own (the propagandist) gain. If that’s government/nations or companies the same means have been used to influence. Companies have called it public relations (PR) as a less off-putting term than propaganda, but it’s the same thing.

When everything was devised Sigmund Freud was hired in to consult in forming peoples opinions to gain leverage. In its essence propaganda was made to appeal to our primary desires/urges, because of the work done by Freud at the time it seemed like a sure bet. This is why advertising appeals to peoples wish to be beautiful (vanity) and rich (greed) among the other obvious connected ones like playing on sex. Makers of music videos has taken the same road. If you really see ads you’ll see it very clearly. In addition to appealing to primary desires/urges ad-makers also appeal to the lowest common denominator as to make sure the message reaches as many as possible.

I’ve seen old advertising videos where the goal wasn’t to sell more products than your competitor but to pass on public information - which to me makes sense. One example is the early advertising of soap where the message is loosely something like “Use soap, it makes you clean and prevents you from getting sick” - makes sense yes?

On a system design concept

Systems as nature intended

To follow the tendencies of nature in designing systems

This concept includes decentralization (little in nature in under central control), separation of concern (animals don’t need to control their heartbeat), decoupling (evolution selects against coupling, coupling makes things brittle), generalization/abstraction and compatibility (natures inventions is used everywhere, cell factories and biological machines), design for composability (programs and services may be combined into larger ones and observed behavior may resemble that of self organizing criticality) and peer to peer communication (information exchange (example; incorporation of gene-expressions) happens directly - not via third party approval).

The same design concepts seems to work great for social systems as well as software and hardware systems. This leads into my thinking about the ideal structures for organizations.

On fractal system design

The same function/component/program/system may be used for a variety of tasks in different levels. When scaling large systems the composition may resemble fractals.

On forgetfulness

We have limited and unreliable memory. Memory has been a field of study for a long time and it’s reliability seems to be the latest thing to go - according to recent studies. In addition to “lost” memory (really just inaccessible), memories that we do have change with time - in fact every time you recall them. This problem, really only a problem because people think that memory is reliable, is orders of magnitudes larger when you consider organizations which does not record its activity wisely. A whole lot of organizations seems to be more forgetful than the individuals that comprise it. Remember that it doesn’t help to write things down if you’re unable to find it at a later time (recall).

Why I don’t categories and make clear separations

I don’t because of the same reason I don’t believe that specialization in fields of endeavor and limitation of responsibility is a good thing. You may end up with the wrong diagnosis from a specialist doctor or that your case in/against an institution/organization halts and ends up nowhere - because specialization and limitation of responsibility is so narrow. In fact so narrow that a large amount of the total field of endeavor or the responsibility of an organization is not covered at all. For those outside it might make the field or organization seem dumb or naive.

Seeing tendencies, events or anything else in isolation makes you blind to the reason behind something and blind to all the vital connections and similarities which makes up everything. I believe in emergence; not the overused term in tech-miljoe but the fact that there are laws and structures that appear in unconnected fields - laws and structures that really are the exact same. They may be made of pure mathematics and/or information if you will. I write and make reference to all that I see as connected or related so that you may see the same as me. To expose such connections makes you able to see the reason why something would be a wise thing to do and maybe even make you better suited to predict the outcome of a decision or an event that you have not encountered before.

My love for seeing correctness is also why I firmly believe that connections are so important for understanding and that every piece of writing should be riddled with connections to other writing.

Links: zzstructure, ted nelson, transliterature, nexialism

The generalization of microservice systems

I’ve seen a lot of microservices. Most of which have some REST API that transforms some data then process it with some GNU+Linux program or tool, then transforms the programs output to some return format. The interactions between most microservices out there are explicitly defined in the code or service configuration.

Improvements

With the advent of function as a service (FAAS) type systems it’s common to define interactions as a directed acyclic graph (DAG). This adds the advantages of loose coupling and scalability. However, it does not often address the need for transforming input and output inside each service. If transformations are done as separate functions to allow function interoperability we’re closer to pure implementations of functions.

If we take a step back and examine the need for data transformation, most of the transformations are done from and to JSON so that a REST service consumer stays happy. With microservices calling microservices most of the need for transformation via JSON and the HTTP overhead adds quite a bit of unnecessary bloat and CPU cycles. To keep loose coupling via DAGs and to define functions on a lower level that via REST APIs should better the situation.

Implementation details

The platform must have the necessary tools of the trade in the form of GNU+Linux programs. A configuration based and graphical DAG system could be made to rely on program blocks and then make larger program flows work by running the flow through an equivalent of UNIX pipes. Functional blocks could be composed of many program blocks and DAGs. Large systems could be build in this way by composition. Frontends could get an API that is a collection of the platform endpoints. Storage of data in the form of data structures and binary data could me managed for a platform or refer to a local machine (data ownership). The result of a endpoint request might be returned as a rule so the service consumer or frontend get to decide what to do with the data.

Platform service: Backend based on python and a REST framework like hug.rest. The whole functioning system is stored as DAG configuration with each single node representing a GNU+Linux program with defined options. A graphical frontend may be written in the form of a web UI, using vis.js to display and manipulate DAGs and JSON based configuration editing. Frontend may define program options (in DAG nodes) in the form of a JSON-schema based HTML forms. Additional DAG node templates (the F in FAAS) should be made for things like monitoring outside endpoints to spot changes in replies, for file changes in the file system or in decentralized storage and for listening to queues and messages via DHT. Nodes to broadcast DHT-messages might also be useful.

Note: Input parameters to endpoints may be stored as environment variables for flow execution. This allows ease of sending input parameters to some node inside a DAG.

Computing freedom

Platform nodes and graph should be available to everyone at an endpoint or in a distributed archive (dat archive or equivalent). Is most ways this system is the antidote to Service as a Software Substitute in the way that everyone could download this platform software and the platform service configuration to run a clone of a provided platform for themselves. Since the platform composes GNU-tools into services and is a possible free, as in libre, answer to the problems with SASS the platform should be named GNU as a Service or GAS. The term GAS also reflects the extreme fluidity of composition.

The other FAAS

Frontend as a service could also be modeled in the same fashion. The platform software could provide arrangeable components that calls each other via local broadcast messages for the domain (see implementation). The component connections would be defined as a DAG, in the same way that the Backend is composed. Component code with handling of an equivalent of standard input/output should be saved as node content. Components should be available for the frontend as templates, in the same way as nodes for backends are.

This way of building frontends tend well to loose arrangement of components to suite workflows. With rearrangeable frontends everyone is free to pick and choose.

Reuse

Tools made to extend the platform with programs benefits the larger software community as well since they are simple and reusable small programs adhering to the Unix philosophy.

Process

Organization of thought through project may be divided into the following steps:

  1. Thought
  2. Opinion (thought combinations)
  3. Concept (opinion combinations)
  4. Project (concept combinations)

Whole system thinking, software and social systems that is, may also arise on the project level even though it may be seen as a level above combining projects.

2023-raw.md

X from containers

Using Xephyr

For a seperate nested X session on the host machine run Xephyr:

$ Xephyr -br -ac -noreset -screen 800x600 :1

Run containers with the following options to display applications inside the nested session:

$ podman run -it --rm -e DISPLAY=:1 -v /tmp/.X11-unix:/tmp/.X11-unix:rw alpine sh

Using host Xorg

Use xhost on the host machine to add permissions:

$ xhost +"local:podman@"

Run containers with the following options to display application on the same DISPLAY:

$ podman run -it --rm -e DISPLAY="$DISPLAY" -v /tmp/.X11-unix:/tmp/.X11-unix:rw alpine sh

To remove permissions again, issue:

$ xhost -"local:podman@"

Remote VM access with Spice

Qemu has support for the Spice protocol. Start a VM using qemu with the following options to enable it:

-spice port=5900,disable-ticketing=on

To set a password replace “disable-ticketing” with “password” and set its value. You may connect now with for example remmina (install remmina spice plugin). Issue the following to connect:

$ remmina spice://localhost:5900

about.md

Øyvind Jensen
Alta, Norway
oyvind -A-T- kreativtrom.net

Education

Thoughts, sketches and implementations

Memberships

Spoken and written languages

Programming languages

Programming taste in general

Favorite programming libraries

Favorite software

Favorite operating system distribution

Favorite artists

Favorite artistic movements / styles

Interests

Values

bookmarks.md

music.md