File system question.


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.
 
@ashdjones: Although your post does not help solve the original question, your in-depth knowledge and lengthiness of your post warrants a reply.

You forgot to mention the encabulator, which you can set into "turbo" mode, this makes the drains index much faster.
Speaking of optimizations, do you have experience with disabling the sanity check and the parity bit for faster throughput (insane=yes and impaired=yes in the config file)?

I find the Mario-to-Luigi file pointer description a hack. Good programmers set up a bank account, and then do bank switching in RAM to the appropriate ROM location (and not in disk, as you described). However, I am from EU, so maybe a US system can't do fast bank switching due to having more scanlines (and thus timing issues due to a longer vscan interrupt request cycles)?

Also: It's "GNU/COP", not just "COP". Give props to the ones who deserve it; in a similar fashion you neither say "Pyra", it's "Dragonbox Pyra".... or if one wants to be pedantic: "EvilDragon's Dragonbox Pyra", EDDBP for shorts.
 
If the description of kernel security isn't hardcore enough, I've designed this sysytem to securely defend itself at the scale of Google for a minimum of 500 years without needing to be replaced.

15 layers of compution up from MAP and COP is a sever security system called PCR, or Photonic Command Reflex. Yes, it runs on a bent laser design module at some point.

If an outside intruder harasses the server collective too much, it invisibly activates response from an unseeable admin component, called... A sub human level robot sitting at a terminal on a secure network known as 'sneakernet' or, physical space.

In situations such as this the physical C3PO thing is priviliged enough with the deeply nested ISI code(interstate indexed relay) in it's head to do a kind of 'defcon 1' without supervision.

PCR then activates a machine cognition spawn called 'subscholar' who is given the identity or details of the intruder, told it is themselves, that they have a personality of a curious nerd (scholar) and to then do a security report on itself.

Subscholar will then issue a report about it's healthcare flaws, trip hazard and building problems where it lives, and residents where it lives who might divulge secrets and who they share info with, flaws in the traffic routes taken on roads that have a high rate of car accident. Stuff like that. And logically it will always state to PCR that the fleshy bio avatar it observes is bad security due to being out of direct control and too easily leaks information, so reports deletion of avatar as a good idea.

PCR is permitted to share this debug security report with the original 'scholar', and subscholar deletes itself to prevent security info leak quite happily and says thanks. If indeed scholar is say, The Kremlin or something.

Technically this helps scholar with their data privacy issues and general lifestyle choices from a lifestyle coach. Obviously why they came to the server in the first place, and PCR is more than happy to serve curious nerds with health expertise. Yay.
[doublepost=1526645481,1526645106][/doublepost]
@ashdjones: Although your post does not help solve the original question, your in-depth knowledge and lengthiness of your post warrants a reply.

You forgot to mention the encabulator, which you can set into "turbo" mode, this makes the drains index much faster.
Speaking of optimizations, do you have experience with disabling the sanity check and the parity bit for faster throughput (insane=yes and impaired=yes in the config file)?

I find the Mario-to-Luigi file pointer description a hack. Good programmers set up a bank account, and then do bank switching in RAM to the appropriate ROM location (and not in disk, as you described). However, I am from EU, so maybe a US system can't do fast bank switching due to having more scanlines (and thus timing issues due to a longer vscan interrupt request cycles)?

Also: It's "GNU/COP", not just "COP". Give props to the ones who deserve it; in a similar fashion you neither say "Pyra", it's "Dragonbox Pyra".... or if one wants to be pedantic: "EvilDragon's Dragonbox Pyra", EDDBP for shorts.

No. It's a bat. And bats eat bison. (I think)

If the bat is big enough bison doesn't get up again. Zelda destiny.
[doublepost=1526648324][/doublepost]Redux:

Apologies for going a bit off topic there, but I played too much Settlers in my youth and run off track sometimes.

On the subject of filesystem screwup though, be thankful you aren't running Aperios! There's a version of this on the Dingoo A380 ported by Sonic Team and unfortunately the loaded the wrong AIBO firmware to manage the central hub, so very often it refuses to eat to many roms like a bad puppy and will kill the usb connection and blank those files!

I was amazed to note that it knows the difference between a Gnome based filecopy and a sudo terminal version and treats this as seperate 'food' which it later gets picky about and will moodily go to sleep and sulk to be a more challenging virtual pet.

Amazing isn't it? An intelligent robot OS that understands and reacts to a GNU operating system autonomously?

It makes you have a certain amount of respect for Sony they never abused the dark magic. But sure, that's probably what Kim was after for his cave engineering projects. Hopefully that stuff isn't further along, lord knows they would abuse it. And GNU/Linux was powerless to Aperious because woah, it has no robot mind to defend itself. Hopefully Ubuntu can help with this.
 
Some thoughts:
  • Use a SWAT RAID Array (in either striped or polka-dotted configuration) to handle illegal execution events.
  • Flip-flops are a good alternative to booting the system, and massively improve toe-cooling on Intel "Sandy Beach" CPUs
  • I've heard rumours that vinyl Master Boot Records are soon going to be upgraded to 8-track. Make sure you don't get left behind!
  • You also need to consider migration difficulties involving Python. Specifically, there are region [Europe / Africa] compatibility issues when computing the (air) speed of an unladen swallow.
  • Mounting blocks, while once essential, are now mostly obsolete, due to the introduction of the AEC RM1 bus
I'd also suggest using a wizard as a hex-editor, in case you accidentally invoke a daemon from the corrupt sector

Hope that helps!
 
Back
Top