I realized that I can merge my OS with debian core and have everything that I want. I started my OS in 1975. I was my intent to make an English language interface to the computer using lists as the basis, without using the protected mode as a vehicle. I decided to implement protection within the OS core and simply execute the primitives there. It works and I have used it for years, but the biggest problem is that I must code each new method or interface for myself since it is different in structure.
The OS is stable and, in fact, it has run without fault for 30 years in some cases and only died because the hardware failed miserably in a fire. By avoiding the use of things which are inherently prone to fail it can be stable. It is obvious that if I code an OS in ROM that simply writes to CGA memory after initializing it and loops on itself to display a count in a register then it will be perfectly stable so long as it has no interrupts enabled. This is where I started in 1975. I wanted to have an OS which could control dangerous process, which was exactly my profession. I designed systems which controlled equipment that was inherently dangerous for many reasons. Some of the process was dangerous because of the chemicals and others for mechanical reasons.
I built on this framework to create an ever more complex system which could handle network traffic and complex hardware. It still remains stable and usable. I designed in a new coding interface which uses symbolic execution. Essentially it is a set of virtual processors that are lists that do exactly what the CPU does. Like, add two numbers.
It was my goal to make it completely processor independent by symbolics and not by compiler. By establishing a primitive which could be executed on any processor, I could move the OS from machine to machine and keep my entire code base, so long as the computer was able to add two numbers and select from a list. I am not aware of any digital CPU which cannot do that.
I was working on meta programming recently and just now realized that I can use a meta code interpreter to port every bit of open source to my OS and in the process make it English language code instead of contrived code. In my OS, the instruction to add is "Add this and that", where this and that are replaced with things like "The screen position of this window" and "The offset within the virtual screen". My problem was that it was too slow on a CPU running at 20mhz with 2 megabytes of ram. Now that CPUs are commonly 2 gigahertz and I can have as much as 4 gigabytes of ram, it is faster than Windows and Linux by a great stretch. The reason is that instead of dealing with the complexity at a level that it cannot be handled, I have designed it from its core to be completely virtual. Instead of compiling to an architecture, I have designed it to be architecture independent. After the initial code that is system dependent, the OS never ventures into the hardware again. It does not establish an Intel virtual protected mode, does not have task switches and does not have the overhead or complexity of asynchronous interrupt.
I am sure if you are an OS designer that you would wonder how I would avoid over-run and you would have hit on the key to its operation. The code is executed as symbolic streams. As a result I can check for asynchronous events in the APIC or directly at the hardware in real time at the CPU. With this CPU, I have a 200ns latency maximum to respond and this is sufficient and actually as good or better than the concept of task save and switch. There is no task switch time as there is no task and no physical protection enabled. The hardware layer is virtual code as well. So the service of a logical interrupt happens in parallel with all the other code. Flags are used to avoid conflict and allow parts to be synchronized.
It seems to me that I can create a meta code transport to facilitate export of utility to my OS and thereby complete this process on an OS that is designed for becoming a mitochondrial or nanomachine OS from its inception. What I have learned about compilers and language and so many other things these last 7 years will allow me to retrofit this easily I hope. The result will be that I will retain all the functionality of the programs that are made for Linux easily and have a new more understandable programming language that is faster than Java and definitely more readable and can be run on any machine that can do the most simple of CPU operations.
Security is inherent in the OS as it does not run machine code from others. It runs virtual code on a virtual CPU. In other words it cannot cause a stack overflow as my virtual CPU checks for stack errors on each execution, it cannot execute data as code as that is not in the same virtual segment and that is not a hardware enforcement it is designed into the virtual CPU. The list of data is in a different place than the code and so is the stack. Thus the code has no access to the physical hardware and I implement restrictions on the virtual disk writes such that critical data cannot be written on the disk or in the flash BIOS. Since all hardware is virtual the drivers must be open source. In the past I simply wrote my own, but with my new talents and the open source drivers available, I should have a complete English language operating system to access the net.
That sounds like great fun and I look forward to posting to the blog from my new OS. The original point of the OS was to be stable and easily extensible as I was the only person who understood the methods at its core. Now that CPUs are fast and memory is cheap and drives are terabytes and SSDs, I am going to have a great time with this. It seems that it would be impenetrable since code execution cannot be changed by even the OS. In order to make changes I need to use a tool that writes directly to the hardware. It seems that it would be impossible for it to be usurped, but I will consider that.
The OS is not safe from physical intrusion because that is impossible, but as far as penetration from an external source it seems it would be at least as safe as running from an Ubuntu CD.
One method I am considering is modifying gcc to use my virtual cpu as a processor type. In this way I can compile to virtual code. I am sure that there will be some interesting developments at the higher levels, but if it was easy, it wouldn't be any fun.
The reason I call it KOS is because it is named for personal reasons and just happens that it could be called Chaos. It makes no difference , what is in a name, except what it references?
This should allow me to do something more than I intended. At first I just wanted a better programming language, but now I may have my own complete operating system which is easily extensible by the AI meta code generator and easily understood. Fun ensues. I can't believe I have been maintaining this OS myself for 35 years. I get a great deal of fun from it and I have my own version of a blender like software that uses the framebuffer and VESA interface instead of a proprietary driver. It is slow compared to some hardware acceleration, but I have designed some tricks in the code to make it fast on a 20MHZ CPU. So you can guess what speed it runs on a 2 gigahertz processor. That is 100x from the design and utility point. I guess about a week before this works coherently and I can select and run it from my modified grub list and use it with Firefox. This is an interesting turn of events and that is what synergy does. I can see many other places where this will allow me to use specialized hardware and wetware that is cheaper and more flexible. For one I can use external CAM to access data in hash like methods. This should allow for a 1,000 fold increase in many functions. This means I can bypass Intel and others and accelerate my designs with FPGAs, CAM, and some hardware that I designed long ago that was rejected by the manufacturers because it was too fast. That might seem odd for them to do, but really it makes sense. The business requires income to be stable and if you make a CPU that is 10,000 times faster, it will be 10 years before you sell an upgrade. As a result you will be out of business. That doesn't mean it is the way that it should be, that is just the way a government token monetary system works in conflict. If it were an issue of real cooperation it would be the proper answer. The situation is that an economic system is designed to benefit a few and dispose of the rest. A kind of designed in eugenics. I am not saying it is evil in some absolute way , it is just the way I see it and it isn't efficient or productive.
The next step after this is to create an extensible hardware or wetware design that it can operate.
0 comments:
Post a Comment