My filesystem DrainsFS is currently the most secure and foolproof model you can get, but overly extreme. Even BSD kids would make fun of me.
Firstly, it uses a database model rebuilt from NewtonOS fully addressable and with unlimited object trees, metadata tagging. Secondly this is human readable and would be familiar to anyone who built their own autoexec.bat or config.ini in MSDOS. Thirdly this has some network maths going on, like you can 'add' or multiplex packets.
It loads enitrely into RAM from two major sources. Hard coded into source like a GBA rom, or imported from a referenced file. And to offset the speed disadvantage of storing ascii numbers, such as bitmap resolutions, there's an almost instant conversion to decimal or hex built in, so usage of Drains isn't impoverished.
I say secure, because you ouput file streams in data format 'index' and then manually store this as backup, later put it back into the rom or ini file which you prune for size. This was of course derived from the standard methods of building a NES rom using assembler tools.
It improves on NES or general console development massively. Instead of altering the code for mario sprite, goomba, mushroom, you hold an object list as a drains index. And then reference this, as a file pointer. The length of such chains is endless and no major speed impediment. So you hack the rom by changing the pointed filename in about 2 seconds ... Mario is now Luigi. But this was designed for totally realtime editing of your videogame.
Point of this? Yeah so you can redraw say Mario while in the game, directly on the debug test play. Nice. And then... Neat part... You take the temp 'partition' of the ramdisk which is your temp test game, and then save as drains index. Can split apart, remix, fuse. Anything.
Oh and what else. How about micro routines on game elements which are independant threads? Mario jump animation is self contained program. You mean a Nintendo unix system at 60fps videogame standard? Yes, and works faster than expected.
Alright, so for more advanced Workbench evolution. The filesystem needs actual writeback. But NintendoUnix is then hackable? Alright so there's at bios level a borderline Sauron security wall with turrets. It's even more extreme. BSD will poop their pants at this. And also triple backup of the entire filesystem, entire ram savestates - possible due to object filesystem and networked compression of tree links. Yep, there's a lot of PND history in all this. Now even weirder is that it doesn't really recognise the outside file world as a friend. But it isn't a prison or airport terminal insanity, but called 'io circus'. My wisdom is that the other filesystem is a chaotic visitor and entertaining. Not a villain. The term circus is technically accurate in English language.
Binary files. Ah, so ascii can be compressed but still. So it goes into this large blob, now called ball or 'bll'. And this thing has pointer reference from the drainsfs master, but otherwise has no internal listing or header to corrupt. You manage it by scanning the whole thing, and delete unused gaps. Yeah there's a way to hide stuff in the bll which is good for easter eggs or secret cheat codes. Fun stuff.
[doublepost=1526642489,1526638874][/doublepost]In desciption of filesystem Sauron security:
The kernel is a circuit of 6 in a spec which can be made into chip roms or fpga, and is a massively cleaned up and ordered Sega Saturn type model; they built that for cheapness with affordable chips, but now useful for fpga machines etc. And Pyra boards of course.
Rom a is called COP and b is MAP (acronyms of course). Map is upgraded Amiga rom portion which ran half of Workbench but spec is now more like XP, or decent IBM sections. Between them is a unified RAM wall as used in Xbox. All your stuff is in this wall including maps to devices and network model. All of it. Although it can of course in hardware be merged with a splitter chip to make it smaller chips or bigger, or networked. So however, you have a sensible single memory map area like GBA.
Ah. But there are no fixed addresses whatsoever. Except for a default memory location called 'sanity', because it sanitised an overly dynamic design. So MAP has no ability to run code at all! And it has no idea where in ramwall where to put this or in what format. MAP is a perpetual noob and amnesia patient like Total Recall and accepts this fate. Or doesn't remember it doesn't remember.
MAP asks firstly for a cache by putting a request byte into the sanity location. And then COP slowly specifies or defines things via VMP-IRE-FNG (virtual machine profile internal resource exception fixed numbers gateway). MAP then has a virtual cache to remember or reference additional spec from COP. So it specifies areas such as execution areas, devices io, screen res, network switching. But... The conversation protocol of this conversation is learned. It isn't a fixed language like html or shell script but told from one side to the other, tested back and forth to establish understanding of how it works. And then they negotiate. MAP puts system level code into where it got told, but relies on the cache memory area it got taught.
COP watches what goes on like a sniper, and if it passes security model then sure, it will network packet across the internet. Or write to the main filestore, or execute the program on a secondary private copy of the ramwall... not useable to any other kernel on this.
If something happens which looks shifty or non standard, or just for debugging... The cache and general specified system to map is blanked. MAP is now dumb and asks that sanity byte for more info, but on secondary private dupe, COP is analysing what MAP was doing and will or will not kill the other kernel via override, or actually... Puts it through a total recall adventure of fakeness to check what it will and won't do. Reality sandboxing. And the cache, protocol stack can be insta switched unlimited amount, so very quickly COP can check if MAP is some sort of trojan copy or compromised or whatever. Often cases there's a logical trick set to confirm the program identity of the other side.
Like I say, almost Mordor. But it should be impossible to trojan, spyware or zombieddos hijack these kernels. Hence BSD are a bit scared of this. They would have to start their OS from scratch.
mabes.
Firstly, it uses a database model rebuilt from NewtonOS fully addressable and with unlimited object trees, metadata tagging. Secondly this is human readable and would be familiar to anyone who built their own autoexec.bat or config.ini in MSDOS. Thirdly this has some network maths going on, like you can 'add' or multiplex packets.
It loads enitrely into RAM from two major sources. Hard coded into source like a GBA rom, or imported from a referenced file. And to offset the speed disadvantage of storing ascii numbers, such as bitmap resolutions, there's an almost instant conversion to decimal or hex built in, so usage of Drains isn't impoverished.
I say secure, because you ouput file streams in data format 'index' and then manually store this as backup, later put it back into the rom or ini file which you prune for size. This was of course derived from the standard methods of building a NES rom using assembler tools.
It improves on NES or general console development massively. Instead of altering the code for mario sprite, goomba, mushroom, you hold an object list as a drains index. And then reference this, as a file pointer. The length of such chains is endless and no major speed impediment. So you hack the rom by changing the pointed filename in about 2 seconds ... Mario is now Luigi. But this was designed for totally realtime editing of your videogame.
Point of this? Yeah so you can redraw say Mario while in the game, directly on the debug test play. Nice. And then... Neat part... You take the temp 'partition' of the ramdisk which is your temp test game, and then save as drains index. Can split apart, remix, fuse. Anything.
Oh and what else. How about micro routines on game elements which are independant threads? Mario jump animation is self contained program. You mean a Nintendo unix system at 60fps videogame standard? Yes, and works faster than expected.
Alright, so for more advanced Workbench evolution. The filesystem needs actual writeback. But NintendoUnix is then hackable? Alright so there's at bios level a borderline Sauron security wall with turrets. It's even more extreme. BSD will poop their pants at this. And also triple backup of the entire filesystem, entire ram savestates - possible due to object filesystem and networked compression of tree links. Yep, there's a lot of PND history in all this. Now even weirder is that it doesn't really recognise the outside file world as a friend. But it isn't a prison or airport terminal insanity, but called 'io circus'. My wisdom is that the other filesystem is a chaotic visitor and entertaining. Not a villain. The term circus is technically accurate in English language.
Binary files. Ah, so ascii can be compressed but still. So it goes into this large blob, now called ball or 'bll'. And this thing has pointer reference from the drainsfs master, but otherwise has no internal listing or header to corrupt. You manage it by scanning the whole thing, and delete unused gaps. Yeah there's a way to hide stuff in the bll which is good for easter eggs or secret cheat codes. Fun stuff.
[doublepost=1526642489,1526638874][/doublepost]In desciption of filesystem Sauron security:
The kernel is a circuit of 6 in a spec which can be made into chip roms or fpga, and is a massively cleaned up and ordered Sega Saturn type model; they built that for cheapness with affordable chips, but now useful for fpga machines etc. And Pyra boards of course.
Rom a is called COP and b is MAP (acronyms of course). Map is upgraded Amiga rom portion which ran half of Workbench but spec is now more like XP, or decent IBM sections. Between them is a unified RAM wall as used in Xbox. All your stuff is in this wall including maps to devices and network model. All of it. Although it can of course in hardware be merged with a splitter chip to make it smaller chips or bigger, or networked. So however, you have a sensible single memory map area like GBA.
Ah. But there are no fixed addresses whatsoever. Except for a default memory location called 'sanity', because it sanitised an overly dynamic design. So MAP has no ability to run code at all! And it has no idea where in ramwall where to put this or in what format. MAP is a perpetual noob and amnesia patient like Total Recall and accepts this fate. Or doesn't remember it doesn't remember.
MAP asks firstly for a cache by putting a request byte into the sanity location. And then COP slowly specifies or defines things via VMP-IRE-FNG (virtual machine profile internal resource exception fixed numbers gateway). MAP then has a virtual cache to remember or reference additional spec from COP. So it specifies areas such as execution areas, devices io, screen res, network switching. But... The conversation protocol of this conversation is learned. It isn't a fixed language like html or shell script but told from one side to the other, tested back and forth to establish understanding of how it works. And then they negotiate. MAP puts system level code into where it got told, but relies on the cache memory area it got taught.
COP watches what goes on like a sniper, and if it passes security model then sure, it will network packet across the internet. Or write to the main filestore, or execute the program on a secondary private copy of the ramwall... not useable to any other kernel on this.
If something happens which looks shifty or non standard, or just for debugging... The cache and general specified system to map is blanked. MAP is now dumb and asks that sanity byte for more info, but on secondary private dupe, COP is analysing what MAP was doing and will or will not kill the other kernel via override, or actually... Puts it through a total recall adventure of fakeness to check what it will and won't do. Reality sandboxing. And the cache, protocol stack can be insta switched unlimited amount, so very quickly COP can check if MAP is some sort of trojan copy or compromised or whatever. Often cases there's a logical trick set to confirm the program identity of the other side.
Like I say, almost Mordor. But it should be impossible to trojan, spyware or zombieddos hijack these kernels. Hence BSD are a bit scared of this. They would have to start their OS from scratch.
mabes.