Straightforward from here
In a weird twist, it was always the plan.
If you haven’t been spoiled on my grand plans yet, I’m happy to inform you that it’s pretty straightforward from here:
Impeach Trump & Pence
Constitutional crisis
Arm the worker’s councils
Vanguard seizes power
Dictatorship of the proletariat
…just kidding.
The real story is a lot more mundane: the other day someone asked me what I was doing with my work, looking for an explanation into how it feeds into our loftier goals with computing chips thousands of times more powerful than anything else in existence. My response was kind of all over the place, with lots of hyperlinking, and I felt pretty unprepared to answer it cogently in retrospect. This article is a better attempt to explain it.
So anyway, here’s the list:
Alabaster Linux (pseudo-distro for programming)
Hinterlib (libc surrogate/kernel)
Oración (assembler)
Quindle (editor)
Feeble C Compiler / FCC (C compiler)
Sirius C* (C* compiler)
Codex (massive data bookkeeping library)
Shimmer (shmem library)
Precursor (version control tool)
Forerunner (project management system)
Inbound (build system, replaces Slick)
Rebound (software packing system)
Outbound (software distribution system)
Earthbound (software procurement system)
SLIP (implementation of ADP1)
Further explanation
Since that’s a lot to take in, I’m going to give each item on that list a section and briefly go over what they are for and why they are necessary. For the record, there are a lot more projects in queue that are not listed because this is the extent of plans that are both certain and absolutely general, regardless of any ultimate project or product at hand.
Alabaster Linux
This was originally conceived as a Debian-derivative pseudo-distribution, using a one-liner cURL/wget installation script. I needed a consistent and simple desktop environment that follows the Openbox/tint2 pattern I have used since my #! Linux days ten years ago. It is done and operational; simply visit alabaster.sh to try it!
It has also been expanded to support CentOS 7, albeit without any of the GUI tooling that comprises most of the installation script. This was added for the sake of Grovercomp, our petascale supercomputing project. In this case, it mostly amounts to compiling and installing the same version of git, as well as installing lzlib, plzip and tarlz, some awesome and scalable archival programs from the Lzip project. Think XZ without the footguns.
Hinterlib
This one is also in a stable and working state, and has had more work-hours poured into it than any other project so far, sans the Slick Makefiles. On hosted platforms like Linux and macOS, it serves as a libc surrogate, providing shims for all sorts of necessary things that are not available portably in ANSI C, including a lot of new tools such as containers and memory management.
All of these things have custom backings on the more bare machines Hinterlib supports, such as the IBM-PC with DOS, and the Nintendo Game Boy Advance. For example, when you call uni_die( ) in the pattern of crash-oriented programming, it will defer to abort( ) when available, but call a SWI to halt the CPU on the GBA.
Oración
This will be the assembler used by all of our software projects, eventually. Some forethought has went into the plan of implementation design, in that it will support both ARMv4T and i286 ISAs initially in tandem, expanding to handle successive ARM and x86 updates organically in the same order they historically appeared. I was always of the mindset that this can help tremendously in modelling a better assembler, since it will give us every opportunity to adopt the mindset the architects of yore had at the time they acted, but with the power of hindsight held close.
As a footnote, this also implicitly includes another tool, Gordian, which is something I have come to call a desymboliser. It performs the task that a linker would have done, but with far less cognitive overhead and in a different order of operation.
Quindle
This is our editor. Quindle actually had an MVP, but it was made with SDL2 and brought me to a point I had to abandon it due to the brittleness of that library’s event system and the apparent impossibility of replacing it with something mature like libev without trashing the entire codebase. The current plan is to re-implement it on i486-era IBM-PC compatibles, of which I have many, and bundle it into a DOS box of some variety for distribution on consumer PCs. I will implement rendering manually with a minimum graphics requirement of 640×480 at 256 colours. I have confirmed with data sheets that all i486 ThinkPads bear a graphics controller from Western Digital that supports this, and I strongly suspect my Compaq LTE Elites have the same chip.
Feeble C Compiler / FCC
This will be the ANSI C compiler to use with all of our software projects in time. It is specifically designed to be a non-optimising C compiler, unlike most C compilers in spirit. Many of our other tools will form a concert of deep data visualisation that renders automagical optimisation of C code more of a hindrance than a helping hand anyway.
As a side note, the developing of this also involves creating a data model for compartmentalising code and data from disk and active memory, which I have spoken of already. This will have some overlap with Codex, too.
Sirius C*
This is like FCC, but for C*. Having a working C* compiler is crucial as the complexity of our projects continues to grow, as we cannot realistically plug and pray our way towards stable systems. Hiring our way to technical solvency or relying on baroque systems of formal verification that no one really understands are also non-starters.
Codex
This is an idea I came up with following a need I saw to be able to read and write data in a more direct framework of octets instead of files in file systems. Instead of having a concept of files and folders in hierarchy, we simply use addresses and view portions of an ephemeral data space directly, taking slices of it at a time and applying lenses to transform it into something legible. The existing structure of file systems can be modelled this way, but so can many other forms of structure and data that are currently out of our reach as we are so boxed into that convention.
Shimmer
This one is my naming but Charles’ idea, and it will form a foundational part in our work with data visualisation in authorship tooling of all kinds. It is a relatively simple library that uses shared memory buffers to pass data back and forth between programs. This is the outcome of removing the UNIX modelling from inter-process communication, and we believe may prove to be far more versatile and scalable as a building block for more powerful applications of the future.
Precursor
I have a few gripes with Git:
It doesn’t respect file systems that don’t cater to UNIX norms
It keeps no ID of a given file, making history traversal a task in archaeology
Its conceptual modelling with branches and heads is nice-in-theory, but worthless-in-practise
So I intend to replace it with a version control tool that fixes those things.
As a side note, we will also be implementing an OpenPGP tool called Gauntlet, which does much of what GnuPG does, but with respect to the garden at hand here.
Forerunner
Providing all of the things that most software projects need for management, including issues, patch submissions, release management, authorship, and so on. Not a web frontend.
Inbound
The v2.0 of the Slick Makefiles will be called Inbound. It will generalise a lot of the concepts espoused in the project page, for the first time providing a serious semblance of usability in compiling projects that aren’t typical source-only ANSI C.
Outbound
Packing software is a task with many potential desired outcomes. In the interest of both pragmatism and neutrality towards cultural norms, we want to have a system that helps us put our software together in many different ways according to the varying needs of our users.
Rebound
Publishing software is a task worth separating from building, packing and procurement. To maximise reach, it is necessary to have a many-fingered approach into the varying ways users may encounter our software and may wish to install or run it. Like Outbound, this is done in the interest of both pragmatism and neutrality towards cultural norms of software.
Earthbound
Software procurement is separated from publishing, as it is not realistic or moral to expect everyone on Earth to adopt a universal model where they speak the same language. Wherever or however others may publish their code, we intend to create a tool that helps us obtain and use it.
SLIP
Structured Logical Interface Parser, or SLIP for short, is our documentation format. It is an ASCII format that neatly provides context to be fed into a source code intelligence system like IntelliSense, without conflating annotations in source code with proper documentation. Literate programming is the end-state of mature systems, and this is what provides the bulk of the English language substance to those books.
So, yeah… you could say we have our work cut out for us. If you would like to support me as I work on these things full-time, consider subscribing to this Substack for a cool $5.55/month, or take a free month for an annual commitment at $55.55/year. Every cent counts now.