Jak powstała pierwsza wersja OUX
Kompletnie zintegrowany prototyp ‟tracon” powstał w jednym podejściu w listopadzie 2010. Powstał oczywiście na podstawie wcześniejszych wieloletnich rozwiązań przypisywanych do laboratorium opRWTng, które nigdy nie zostały wcześniej (w tym laboratorium) zaimplementowane w sposób jednoznaczny. Podstawowym problemem implementacji opRWTng był sposób przełączania ‹zadań› możliwy do uzyskania bez opierania się na ‘kernelu’ systemu osadzenia.
Pewnego dnia przed południem wiedziałem, że to jest ten dzień, i postanowiłem naprawić ‘dosową’ grę ‟tracon”. Po krótkiej analizie projektu okazało się, że napisanie takiej gry jest proste, ale tylko jeśli nie zastosować zasad i technologii zawierających się w opRWTng. Nie zaakceptowałem tego, ponieważ gra byłaby zbyt często używana, a opRWTng był zbyt uzasadniony. Więc ostatecznie postanowiłem niejawnie zaimplementować opRWTng z możliwością powstania gry ‟tracon”, ale ze świadomością niepowstania. Tak powstał OUX. To ukazuje wam, w jaki sposób powstają rzeczywiste technologie, które nie są naśladownictwem: powstają w trakcie robienia czegoś, czego wie się, że się nie zrobi, ponieważ nie ma się mocy wytworzyć tego zgodnie z własną integracją, bez ulegania istniejącym błędnym i powszechnym rozwiązaniom technologicznym, i jednocześnie wtedy, gdy to, co się robi, jest dobrze znane, ale z innej strony.
Tymczasowa nazwa ‟safeos” (w jej znaczeniu pełnym jednocześnie z poszukiwaniem ładnie brzmiącego skrótowca) powstała w mniej niż miesiąc później.
Jakie były inne implementacje przynależące do opRWTng?
Powstawały zwykłe narzędziowe programy komputerowe opierające się na algorytmach struktur danych technologii opRWTng bez uwzględniania wymaganego tą technologią zarządzania pamięcią i czasem. Powstał też prototyp automatycznie tworzący biblioteki importu wszystkich funkcji ‘api’ wybranych bibliotek OpenBSD dla własnej konwencji (asemblera) wywołania procedur niezabezpieczonych, ale z argumentami chronionymi przed nadpisaniem i sprawdzaniem, czy funkcja wróciła w miejsce tuż po instrukcji wywołania właśnie z tymi danymi na tym samym miejscu. Oraz prototyp ‘kernela’, w którym kontynuowałem rozwój modułu obecnie zawartego częściowo w pliku “mem_tab.cx”, czyli od dawna ściśle opisanej technologii zarządzania danymi tablicowymi dwóch rodzajów.Wtedy – “Tabc” i “Tabv” czyli tablica o elementach o stałym albo zmiennym rozmiarze, ale w trakcie konkretnego projektowania ta ostatnia utraciła uzasadnienie jako koncepcja niepotrzebnie oderwanego indeksu (wskaźników) elementów, a następnie “Tabc” okazało się bardziej uniwersalne w rzeczywistości, ponieważ będące w istocie podstawą jakiegokolwiek użycia pamięci niestatycznej, i obie idee utraciły potrzebę istnienia wobec powstałych implementacji uniwersalnych wypełniających skończenie fundament zarządzania funkcjonalnością pamięci operacyjnej.
Czy akronim ‛safeos’ ma związek z koncepcją ‟SafeOS” dobrze znanej firmy lub innymi koncepcjami o podobnych nazwach?
Nie.
- ⁃ OUX powstał bez jakiejkolwiek współpracy z tymi firmami.
- ⁃ Koncepcje OUX i tych systemów są sprzeczne.
- ⁃ OUX jest niekompletną otwartą implementacją znanej — wcześniej powstałej — koncepcji prototypowej opRWTng. Nie jest koncepcją.
- ⁃ ‛safeos’ jest akronimem pełnej, opisowej nazwy oficjalnej.Signal‐integrated Atomic Functional Execution Objects System Jest pisany tej samej wielkości literami: “os” nie oznacza “operating system”.