After researching open-source licensing further, I've adjusted the licensing in the #SubSky project.

• The CPU library and the SubSky stdlibs are under the LGPLv3
• The examples are under the CC0 1.0 (basically public domain).
• Everything else (emulator, compiler) are under the GPLv3

Before, everything was licensed under the LGPLv3.

I know no one would want to use this project for something commercial, at this time anyway, but I suggested in the README the possibility of paid non-GPL licensing. Just in case ;)

https://gitlab.com/golemwire/subsky/-/tree/itemsys?ref_type=heads#licensing

#FoundationProject

More work towards a functional #FoundationOS #Itemsys -based syscall interface.
After a lot of work redoing the data structures behind items and actors (Unix: files and processes), I got the (currently userspace) kernel starting again, and could run my debug shell under it.

(See: alt text.)

#OSDev #FoundationProject

Working on item interface methods for inserting, deleting, and clearing data in item byte arrays. [Unix terminology approximation: working on syscalls for file truncation and more]

The first idea was:
Delins(offset uint64, delete_count, insertcount uint64, byte byte)
From my notes:
It does the same thing as deleting delete_count bytes at offset, then adding insert_count byte_ bytes at offset.
* Affects the data AT and to the right of offset.
Note: you can insert bytes at arbitrary offsets. Think about how filesystems would work with that. File fragmentation is already a thing! And for RAM-resident data, virtual memory could be used to minimize the amount of data that needs to be shift-copied over.

#Itemsys #FoundationProject #FoundationOS #OSDev

#Itemsys #FoundationProject

What I'm working on presently is issues with item driver singletons. Foundation allocates one item driver per open item.
When an item tries to open another item at a given path, the system will start the driver process if it doesn't exist already, and ask the driver to create a virtual item to hand over to the requesting item ( singleton pattern ).

When opening an item, you provide a Type (Class & Format) to open the item as. The problem is, drivers are logically selected based on the Type, so if you open a single item multiple times as different Types, how many drivers need to run?

My solution is to tie an item's Type to its identity.
Ever stopped to think about the odd convention of putting a file type in a filename? You know, filename extensions?

You can't open data.json by calling open("data", O_RDWR). You call open("data.json", O_RDWR).

If I tie the Type of an item to its identity in this sort of way, then I can make it so that you simply cannot open the same item at a given path as different Types!

#OSDev

I am going to start posting more about my projects.

#FoundationProject -- a project to rethink, rework, and rebuild the computer technology behind the scenes.

#SubSky -- A minimalist CPU architecture and computing environment. https://gitlab.com/golemwire/subsky

#Itemsys -- an object-capability model which defines how data and actions work.

#FoundationOS -- The OS of the Foundation project; Itemsys as an operating system. #OSDev

#BeingsOfIsness -- an action-adventure story game with fighting-game mechanics, in development for SubSky. #gameDev