No back doors now

NSA are the first to have access to the backdoors.

Been thinking about this kernel a bit more and I've chosen a few things I will try to implement in it, although lets face reality I most likely won't ever come close to doing it. A working kernel with all these features take many hundred of thousands of hours of work to put to complete.

For sake of easiness to implement I will be attempting to create a monolithic kernel. This means that any software running on the operating system will directly communicate with the kernel, and it will be the kernels job to communicate with the hardware at a lower level. There are good and bad things about this, a good thing is that if designed right it is one of the more responsive/faster running kernel implementations, but a bad side to it is that if the kernel crashes the entire operating system crashes. If compared to a micro kernel structure where all software interacts with user land servers which communicate with the kernel which communicates with the hardware, the benefits are that if a server crashes in user land (say the networking server module) the kernel can recover and simply relaunch the networking module instead of bringing the entire operating system down. It is said though a micro kernel structure is indeed slower because of all the overhead of the software first communicating with the servers which relay to the kernel.

Here is a simple monolithic kernel structure. As you can see it is fragile as per if the kernel fails there is likely no recovery from that failure.

http://i.imgur.com/EHBxLP7.png

Now the Task managing schema I will try to implement is that of a time sharing type. Essentially each process has the right to use the CPU for a predetermined amount of time and then once its time is up, the kernel will put it back in a "last in last out" queue and grab the next process awaiting its turn to use the processor. This is slightly more complex then the simpler version which is just a mono tasking scheme where only one process can run at a time including the kernel. With a multi time sharing system you have to save the states of the current process and where it has left off and when it comes its turn again you must find its data and load it back into memory so the process can carry on its processing. The type of CPU sharing scheme as stated would be a "last in last out" queue in which once a current processes time is up it will be put to the back of the queue and the first in line will get its chance, then will be added to the back in a repeating motion.

For the file system, instead of reinventing the entire wheel, I will use a fast simple file system that has been in draft for a long while, but has never been updated or used. The file system is SFS "simple file system" and is pretty simple to implement, or at least the documents read like it is. The file system as per the documents supports very large files, as well as long file names which includes every keyboard printable letter expect for the forward slash "/" which is reserved for folder separation.

As for memory allocation there are many algorithms to choose from and I am not really decided as to what to use. One is the "first fit" algorithm which simply starts at the beginning of your page file/memory and looks for a continuous free blog of space which will fit the requested amount of data + the header which allows the kernel to know how large the block is, how to remove it, or if it is even in use. Another method is "best fit" which you maintain a list of all free areas in your memory map and search for one that fits the best for how much data is being requested. From my reading it would work as so: If you request 27 bytes of memory, and it finds a [in use memory] [30 bytes free] [in use memory] instead of giving you 27 bytes and leaving 3 bytes free, it will just give you the entire 30 byte block to fill in the entire area.

There are a fuck ton more details and the more I read the more I go "meh I'll just stick to hardware/software reversing and leave this to the neck beards"

It is simple enough to start a basic minimal operating system which simply prints to the screen, but once you try comprehending all these algorithms and attempting to write them in protected mode for the processor... it becomes a bit complicated. Must be why it takes years of work to develop an even basic operating system.

What are you going to call your new OS?

Inquiring minds want to know

Ghot OS: because it's stuck in old ways and old technology.

Look who's talking, Mr. Dban


I was thinking something like ....

DuckOS

LinDux

DuxOS

Etc...

cmon man..

Not going to write an OS any more. As much as I'd like to, I don't have the time to dedicate to such a overly large project even though I am highly interested.

Do it little by little on the side. Why not, you might be the next Bill gates