today's PsychOS bullshit: library that proxies a 'drive' component (raw block device) to provide partitions
@lucifargundam you thought that was bad, I'm implementing online defragmentation and index compacting by modifying the file handles in memory while the program runs

@izaya@social.shadowkat.net wondering how easy it would be to write a simple C wrapper around the BIOS and port PsychOS to real hardware as the world's first functional Lua OS

@melicious plain BIOS? you'd need malloc and free, and a method to interface with each different hardware attachment system, then you could write Lua-side drivers for them. UEFI or OpenFirmware give you a lot more for free.
ayyy, got the whole system on there now

next steps include:
- bootloader EEPROM for raw disks
- util to copy a file to a separate kernel partition
- util to make a kernel partition point to the area of the disk the kernel is already on(???)

@izaya but what does this mean? you already had filesystems and devices... why a virtual os?

@efi I don't know if you mean "why is OpenComputers" or "why are you making a filesystem for OpenComputers"

@izaya the latter
I agree with doing it just because, but does it have a practical use?

@efi it does! several, even
originally I wanted to do this because a server I played on had HDDs and FDDs be Very Expensive but tape drives were super cheap, which resulted in an "I-can't-believe-it's-not-tar" filesystem that ended up used for storing immutable packages.

The other part is that it's a lot easier to tape multiple block devices together to make a bigger one than with a filesystem, and it's straightforward enough to treat a Computronics tape as a block device - and those tapes are much bigger than hard drives and aren't much slower for sequential access - which this filesystem is very good at.

@izaya huuuuh never figured the space limits were a problem, since I only used it for inventory management and machines which needed no persistent data...

@efi admittedly I don't often run into space limitations but it's something worth keeping in mind

the big one was storing an index of all the recipes in the modpack, had to store them compressed on a T3 HDD to fit
@efi plus if I wanted I could extend this with, for example, a tag system, now that I have a functioning filesystem

@izaya I hope you use this to do many AE2 spatial chamber shenanigans

@efi AE2 is too magic for my tastes, all my storage is StorageDrawers-based

I have been known to run racks of OC machines inside a pocket dimension though.
Show newer
need to write some sort of actual shutdown behavior, so open files will be flushed to disk and the reference to the kernel in the filesystem is updated on a clean shutdown/reboot, because if you modify your kernel it gets moved and then the reference in the partition table no longer makes any sense
okay so I have this logic implemented as module/findroot.lua, but it only deals with rtfs volumes on mtpt partitions

thinking maybe the idea would be to make a module/fs/<name>.lua which would pull in relevant libraries and implement boot support from a given filesystem

thoughts?
as a sidenote, you may note that the "init.lua" boot partition overlaps with the actual filesystem

this is correct, as the bootloader is actually loading the kernel from within the filesystem despite having no understanding of the structure of the filesystem

one has to run a command to update the partition table any time the kernel is modified, but that seems like a reasonable price to pay
@izaya I'm sorry are you using an OS inside of Minecraft
"new sector" it's a partition dumbass
maybe I've been looking at this for too long today
as a sidenote, the size of the filesystem in df decreases over time because the index is growing and it's not counted as free OR used space
should probably add it to the used space, but
@melicious it's a bad clone of the Haiku packagefs, it presents the contents of the (compressed or otherwise) packages in /boot/pkg as a filesystem
this got implemented because someone in #oc asked me about network filesystem performance, so I told em it wasn't great but it could be worse
the channel then ended up on a tangent about implementing async constructs to make using network filesystems as painless as possible

while they were talking I wrote the daemon to automate the dumber-than-rocks filesystem sharing that PsychOS has had for years
Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.