• blockchain technique,

and

we would like to give the reminder once again that

• open source to open source protected by a license accredited by our Society for Ontological Performance and Reproduction (SOPR) and
• other systems to our OS, specifically those that are related to
  • the field of SoftBionics (SB),
  • cloud computing (e.g. Blockchain as a Service (BaaS)), and
  • the so-called big data analytics.

There will be no more concessions.

In this relation, we would also like to note that we cannot remember to have seen the combinaton of the fields of CPS 1.0, IoT 1.0 and NES 1.0 with FTRTDSs before the year 2006, specifically such a combinaton based on the techniques of the smart contract protocol and the blockchain.
But nevertheless, we already are over this point, because virtually every such combination is already combined further with one or more properties of our OS so that we can also assume in this case that the exception proves the rule.

05.May.2018
Clarification
We looked once again at our reflective, validated and verified, and by the reflective property validating and verifying singularity included in our Ontologic System (OS) and the fact that it is the first realization or implementation of it and much more.
This fact is also relevant in relation with the facts about the field of SoftBionics (SB), specifically its subfields of Recurrent Neural Network (RNN) and Deep Neural Network (DNN) frameworks (see also the Website review of the 2nd of February 2018).
Despite it has become needless to say, we would like to note that these facts also prove the originality and uniqueness of our OS once again. :D

For sure, especially exciting for an artist in this relation are the relations with the fields of

which somehow are included in our OS as well. This should not be misunderstood as meaning that the OS has a relation with a specific religion or even is a religion despite we call it a belief system having a computing, cybernetic, or ontologic aether or spirit.

Ontonics Further steps
We developed another variant of one of the electric energy storage device mentioned in the Further steps of the 3rd of May 2018, which might not be the most efficient variant but has a unique property that might be advantages in specific cases of utilization.

OntoLix and OntoLinux Further steps
We updated the webpage about the Virtual Object System by substituting the section:
"As an overall system for the visual part we have the OntoScope component, as well as the Ontoverse with the OntoSpace and the OntoGlobe/OntoEarth, and all of the related software."
whereby the Ontoverse was linked with the Ontologic Collaborative Ontologic Virtual Environment (OntoCOVE),
with the section:
"As an overall system, we have the

for the multimodal mixing, augmentation, immersion, mapping, (re)presentation (e.g. visualization), simulation, and synthesizing of the reality and the virtuality."
and the related links.

07.May.2018
Ontonics Further steps
We developed another variant of the device mentioned in the Further steps of the 29th of April 2018 and 2nd and 3rd of May 2018, which might be an improvement.

OntoLix and OntoLinux Website update
We updated the webpage of our OntoLedger component, because we missed to make explicit that the Practical Byzantine Fault Tolerance (PBFT) protocol is also included, which is also given with our network of telescopes (see also the OntoLix and OntoLinux Further steps or Clarification of the 18th of April 2018) and is obvious since we explicitly referenced the Peer-to-Peer (P2P) Virtual Machine (VM) Askemos in the Website update of the 5th of July 2017.

SOPR #116
Since many years we are observing that entities filed patents for various devices, applications, and services that are related to our Ontologic System (OS), Ontologic Applications (OA) and Ontologic Net (ON), Ontologic Web (OW), and Ontologic uniVerse (OV) Services (OAOOOS) or simply Ontologic Applications and Ontologic Services (OAOS), and Ontoscope (Os).
The latetst three patent applications are related to distributed ledgers, specifically those based on the blockchain technique, with the

First of all, we note that we cannot imagine that these utilizations have not been discussed by experts and enthusiasts in the field of distributed ledgers, while the third one is even an essential part of our original and unique OS, obviously and doubtlessly.
Furthermore, we have this little problem that our OS already includes

• Artificial Intelligence (AI),
• Machine Learning (ML), including again
  • Artificial Neural Networks (ANNs),
  • Recurrent Neural Networks (RNNs),
  • Deep Neural Networks (DNNs),
  • etc.,
• Computer Vision (CV),
• Semantic World Wide Web (SWWW),
• Cognitive Agent System (CAS),
• Multi-Agent System (MAS),
• Swarm Intelligence (SI) or Swarm Computing (SC),
• Evolutionary Computing (EC),
• etc.,

(see for example the OntoLix and OntoLinux Further steps or Clarification of the 5th, 6th, and 18th of April 2018).
In addition, we have this other little problem that in the course of a transformation process happening now virtually every stationary and mobile device has already become or will become

which implies that all utilizations of a distributed ledger

The question is now how to handle these developments.
First of all, we repeat once again "that the platform is as decisive as the way of operating and utilizing it" and therefore our Society for Ontological Performance and Reproduction (SOPR) rules. Indeed, it is that plain and simple. :)
Furthermore, members of our SOPR, who implement their system based on the operating system functionality and other functionalities of our Ontologic System Components (OSC) or are operating an app store or both, have to respect the Articles of Association (AoA) and the Terms of Service (ToS) of our SOPR, which demands the ban of a device, an application, or a service if it does not comply with the AoA and the ToS.
Consequently, this provides us the arguments for various options. For example, the members of the SOPR could demand a patent holder to

Btw.: The copyright law is an international law that is also valid in California, U.S.A., U.K., F.R., B.R.D., Italy, Sweden, P.R.China, Japan, India, Singapore, and in all the other areas on planet Earth.

Investigations::Multimedia

From a first report published on the 28th of April 2018 by an online magazine we got the following informations about its affiliate based in India:
"Zebi Data India Pvt. Ltd. (Zebi) is excited to announce that its Blockchain based Artificial Intelligence (AI) solution is now being implemented in the Hospitality Industry. [We already noted in the comment made to the second quote of its website content above that on the one hand this combination or integration is an essential part of our OS. Furthermore, such an system, application, and service is only allowed for members of the SOPR and only anonymously in the 5th ring of the IDentity Access and Management System (IDAMS) structure of our Ontologic Net (ON), Ontologic Web (OW), and Ontologic uniVerse (OV) sketched in the Ontonics Further steps 10th of July 2017.]",
"Zebi just announced end of April that its Blockchain based Artificial Intelligence (AI) solution is now being implemented in the Hospitality Industry. [Such an application is only allowed for members of the SOPR and only anonymously in the 5th ring of the IDAMS structure of our ON, OW, and OV.]",
"Top brand hotels in Vizag, Andhra Pradesh, India, [...] use Zebi AI Chain, not only to protect their guest data, but also to help law enforcement officials in proactive identification and prevention of criminal activities. [Here we got the next undeniable evidence that it is an Ontologic Application, as can be seen easily with the proactive functionality. Furthermore, such an application is only allowed for members of the SOPR and only anonymously in the 5th ring of the IDAMS structure of our ON, OW, and OV.]",
"Zebi AI Chain solution is currently deployed at more than 200 hotels and we are preparing for full scale deployment across all the hotels in India. [... We highly recommend to become a member of our SOPR and comply with its Articles of Association (AoA) and the Terms of Service (ToS).]",
""We made it mandatory for all the hotels under Vizag city limits to use Zebi AI Chain", said Dr Fakeerappa Kaginelli, IPS, Deputy Commissioner of Police [...] [And the international copyright law made it mandatory to pay royalties for our OS even when the police in India uses our Intellectual Properties (IPs). In general, if a government of a state thinks that it would be allowed to use our IPs for free, then we cannot allow the companies based in said state to make businesses with the members of our SOPR.]",
"Zebi brings both privacy and security while automating the whole data transfer activity. All of private and sensitive data of individual hotel guests is stored in the Blockchain and any access or updates to the data are part of the immutable records on the Blockchain. [But we cannot see any reason why immutability is required for such data, like e.g. hotel guest data, and why it has to be handled like critical records. See also the related note given below.]", and
The individual remains as the full controller of their data as consent of the individual is taken before every use of the data. [At this point we are wondering how this hotel system is working, because "all of the private and sensitive data of individual hotel guests is stored in the Blockchain", but the law enforcement officials have access to these hotel guest data, despite it is protected against access by its blockchain-based system. In addition, because all of the individual hotel guest data is "private and sensitive data" and "[t]he individual remains as the full controller of their data as consent of the individual is taken before every use of the data" the individual consent of each hotel guest is required everytime a law enforcement official asks a hotel for this data and wants to access and use this data, so that this blockchain-based system and all the related claims about data privacy and data democracy make any sense at all. At this point we ask once again the question what the use case is or if the marketing unit has mixed every trendy item (found on our website) into its promotional material.]".

From a second report published on the 2nd of May 2018 by the same online magazine we got the following additional informations:
"Revenue Model: Zebi Chain is being offered as an on-premise software in either License + Annual Maintenance Cost (AMC) mode or monthly subscription mode, depending on the comfort and choice of the Data Provider. Zebi Data Gateway shall charge transaction fees for every transaction made through it from the Data Requestors. The revenue from Data Requestors is shared with Data Providers and Individuals as an incentive to enable seamless transaction processing. Zebi will add more features to its products such as enabling blockchain secured seamless payments (FIAT as well as Crypto currencies) for all the transactions processed on its Blockchain solution. [Sublicensing our IPs without the accreditation of our SOPR is prohibited by the copyright law. In addition, such a blockchain secured payment system is only allowed for members of the SOPR.]",
"Token: Zebi Coin (ZCO), is an ERC20 standard token based on Ethereum Blockchain powered smart contract. It is a utility token which will be used as mode of payment for all Zebi services including settlement of transactions within the ecosystem. [With this link to the P2P VM Askemos, also called a distributed settlement, we got the next evidence that proves the causal link with our OS.]", and
"The ZCO paid by Requestor for a data transaction will be distributed among Data Provider, Individual and Zebi as a reward for making the transaction happen. The proportion in which this sharing will happen will be governed by a smart contract which can be adjusted by consensus among the participants. ZCO will incentivize all participants to use, contribute and grow the Zebi Data Ecosystem, Thus ZCO will be the fourth member of the Ecosystem which will keep all the members bonded with each other in their collective growth journey. [We would like to note that its Initial Coin Offering (ICO) time was between the 5th and 31st of March 2018.]".

We also made a quick look at its whitepaper dated 17th of February 2018 and found the same content, which is relevant for this investigation.

As we said already, we are wondering why a blockchain-based system is used for many of these applications at all, when for example a Content-Addressable Storage (CAS) system or a state-of-the-art DataBase Management System (DBMS) with a secure access is already sufficient to realize a use case. In addition, utilizing a distributed ledger makes no sense at all or is contradictive in some use cases, as we have shown with its hotel guest data system.
But what makes this case also very curious are the facts that it has also based its system on the Ethereum platform, has connections to companies in California, U.S.A., promotes of data privacy and data democracy by a company from Singapore with an affiliate in India, and attacks our Society for Ontological Performance and Reproduction (SOPR) by following the same strategy, which is also applied in the cases of the companies investigated in the Investigations::Multimedia of the 25th of April 2018, that is reacting on our publications, copying all items from us required for an individual business plan and strategy, and connecting it with the Ethereum platform, while disrespecting our regulations.

Also important to note are the facts that this company has followed nearly all provisions of our SOPR, for example by providing its solution with a DaaS API, but it has also conducted a gatecrash deliberately in a way that is questioning the competence, disturbing the goals, and even threatening the integrity of our SOPR, like other companies.

We would also like to say the following in relation with this case once again:
In accordance with the international copyright law sublicensing our original and unique Intellectual Properties (IPs) without the accreditation of our SOPR is prohibited.

In accordance with the regulation given in the Ontonics Further steps of the 20th of October 2017 and 29th of April 2018 such a blockchain platform is only allowed in the 5th ring and assigned ID spaces of the IDentity Access and Management System (IDAMS) structure of our Ontologic Net (ON), Ontologic Web (OW), and Ontologic uniVerse (OV) (see once again the Ontonics Further steps 10th of July 2017). Especially, this regulation prohibits OAOS that are

wherever identification of a person and data privacy are relevant, as it is the case in the

• healthcare,
• education,
• controlled or managed finance,
• travel,
• lodging, and
• many public sectors

respectively this regulation allows only anonymous systems, applications, and services based on a distributed ledger and a cryptocurrency of an entity other than the SOPR, though this has to be decided individually from case to case.
Maybe, a decision of the Steering Committees of our SOPR allows such OAOS also in the other rings and ID spaces at a later time.

In accordance with the Articles of Association (AoA) of our Society for Ontological Performance and Reproduction (SOPR) we are allowed to

if a member of our SOPR might be

• disturbing the goals or
• even threatening the integrity

of our SOPR comprehensively, substantially, profoundly, seriously, and existentially.

In accordance with the Articles of Association (AoA) and the Terms of Service (ToS) of our SOPR members of our SOPR and licensees (here the company Zebi) also have to inform their business partners and customers about potential costs of licenses related to their devices, applications, and services if they reproduce our OS and Ontoscope (Os) in whole or in part, or/and perform our OAOS in whole or in part, which seems to be always the case in this context when customer front-end or/and back-end systems are OAOS.

In accordance with the AoA and the ToS of our SOPR the following royalties will be due or are already due:

It should be obvious that we also have the combination of this distributed system and much more included in our OS, specifically

• distributed ledgers based on a
  • Directed Acyclic Graph (DAG),
  • linear graph (e.g. blockchain technique)
• cryptographically chained or interlinked records (see also Content-Addressable Storage (CAS) systems and the blockchain technique),
  • cryptographic hash chain (compare also with the fault-tolerant, reliable, and distributed operating system Apertos (Muse) and the Peer-to-Peer (P2P) Virtual Machine (VM) Askemos in relation with the smart contract transaction protocol and in combination with the blockchain technique) and
  • cryptographic hash tree or Merkle tree,

• Peer-to-Peer (P2P) computing and
• cloud computing,

• validated, verified, validating, and/or verifying transaction logs,
• secure logs on the basis of cryptographically chained or interlinked records (see also the blockchain technique), and
• Content-Addressable Storage (CAS) systems,

• Industry 4.0,

and

which all are combined and integrated by our integrating Ontologic System Architecture (OSA) (see also the Ontonics Further steps of the 4th of May 2018).

In general, governments, companies, and private persons should not fall prey to clever but often illegal marketing and other fraudulent activities of plagiarists. With a high potential illegal implementations risk incompatibility with the rest of the world and might require a very costly transformation in the near fututre. Eventually, our orginal and unique Ontologic System is the only legal way to go. This is no joke and no marketing blah blah blah, but just fact.

08.May.2018
Blockchain fraud will come to an end #1
When we created the Ontologic System and the Ontoscope, we had an utopia in mind. In fact, the paradise of the modern man was the guiding thought and central theme.
When creating the Articles of Association (AoA) and the Terms of Service (ToS) of our Society for Ontological Performance and Reproduction (SOPR) we had the principles and values of fundamental freedoms, human rights, democracy, and rule of law in mind. In fact, the constitutions of democratic states with modern and free societies where the guiding blueprints.
When we are looking at the outcome since 2 decades, then we have to conclude that we are getting again and again, and even more and more a zoo of outlaws in the World Wild Web (WWW) in particular and in the industries in general.

Specifically, the whole Ethereum platform is a plagiarism from its planning over its introduction and further development to its latest utilizations. Its "ERC20 is a technical standard used for smart contracts on the Ethereum blockchain for implementing tokens. ERC stands for Ethereum Request for Comment, and 20 is the number that was assigned to this request. ERC20 defines a common list of rules for Ethereum tokens to follow within the larger Ethereum ecosystem, allowing developers to accurately predict interaction between tokens. These rules include how the tokens are transferred between addresses and how data within each token is accessed. [...] This token protocol became popular with crowdfunding companies working on initial coin offering (ICO) cases."

Honestly, we will not tolerate much longer all those blockchain frauds and their attempts to threaten the integrity of our SOPR. We have seen that there were and still are 3,000+ Initial Coin Offerings (ICOs) of start-ups with

Somehow, we have the impression that adult script kiddies not only throw an app with some trendy buzzwords into the market but an app with a cryptocurrency and the buzzword blockchain now.
Hopefully, nobody thinks that we will run after each of them instead of solving it in a much more effective way.

Furthermore, venture capital has become an annoying issue in the last decade but now it is misused to increase that mess exponentially.
Eventually, that whole blockchain thing has gone out of control of its originators. There is no way that this will going to happen any further with us. Do you really think that we are nuts?

So we suggest as potential solution that either

In this relation, we are still thinking about the options to

Our investigations and additional research have shown that we were already there since the official start of our OS where the fraudulent blockchain platforms want to be and as a matter of fact our OS is the only legal platform and therefore our SOPR with its Articles of Association (AoA) and the Terms of Service (ToS) is mandatory.

10.May.2018
Dump that island system
Our Ontologic System (OS) is much more flexible and advanced than any distributed ledger and therefore the way to go. As a matter of fact, to use the blockchain technique, similar techniques, and other types of distributed ledgers for everything is utter nonsense and often a reinvention of a secure

• declarative role-based permission management system,
• grid computing system, as well as
• mobile game based on Augmented Reality (AR), geopositioning, and guess what, Artificial Intelligence (AI) in addition to, mind you, a blockchain.

Tock, tock, tock. Hello, hello! Good morning! Anybody home? Huh? Think, blockhead! Think!

Indeed, the first main problem is

• on the one hand reminds us of the good old ticker tape, that is now improved to become a punched tape, and
• on the other hand will not become the foundational infrastructure of our OS with its Ontologic Net (ON), Ontologic Web (OW), and Ontologic uniVerse (OV) for many very good reasons, as it is the case with every single distributed ledger of an external entity, that is not managed by our Society for Ontological Performance and Reproduction (SOPR), due to the fact that such an infrastructure and all of its foundational elements are parts of our OS, which is under the control of our SOPR and remains under the control of our SOPR,

and

because some entities want to stake their claim not with or in our ON, OW, and OV, but of our ON, OW, and OV, no matter that they cannot succeed in doing so.

The second main problem is that many distributed ledgers are

• is included in the OS, such as the foundational elements of Fault-Tolerant, Reliable, and Trustworthy Distributed Systems (FTRTDSs), and more importantly
• belongs to the OS, such as the original and unique integration of all of these foundational elements by C.S.,

In fact, it is this integration that made FTRTDSs a success eventually recently, because FTRTDSs based on the Byzantine Fault Tolerance (BFT) protocols or the Byzantine-Resilient Replication (BRR) method, like for example the Secure INtrusion-Tolerant Replication Architecture (SINTRA),

• distributed file system,
• distributed data store or distributed storage system, such as e.g. the global data store OceanStore,
• distributed database based on cryptographically chained or interlinked records, such as e.g. a blockchain-based database, and
• distributed virtual machine, such as e.g. the Peer-to-Peer (P2P) Virtual Machine (VM) Askemos,

and

Eventually, implementing this approach on such a large scale, as proposed by the blockchain fangirls and fanboys, is a waste of space and time, and hence of money, and therefore one can already begin with dumping that island system and vaporizing all those distributed ledgers and what is based on them, and giving all the funders their money back. Read once again the Comment of the Day of the 5th of April 2018.

We are sorry to say, but we have discussed all relevant aspects related to distributed ledgers in the last months and as longer we discuss the existing distributed ledgers as more it turns out that we are

so that there is really no need for further discussions.
Indeed, we have let go that development at first, because we thought that

11.May.2018
Clarification
For finding the legal ground and drawing more exactly the white, yellow, or red line in relation with the copyright protection of our original and unique work of art titled Ontologic System and created by C.S. we read the following documents about the field of decentralized security, specifically about the smart contract transaction protocol and the combination of the Byzantine Fault Tolerance (BFT) protocols, the Byzantine-Resilient Replication (BRR) method, and the cryptographic hash chain data structures, including the hash tree or Merkle tree data structures:

The first document introduces the concept of the smart contract protocol:
"Whether enforced by a government, or otherwise, the contract is the basic building block of a free market economy. Over many centuries of cultural evolution has emerged both the concept of contract and principles related to it, encoded into common law. Algorithmic information theory suggests that such evolved structures are often prohibitively costly to recompute. If we started from scratch, using reason and experience, it could take many centuries to redevelop sophisticated ideas like property rights that make the modern free market work [Hayek]."
"The success of the common law of contracts, combined with the high cost of replacing it, makes it worthwhile to both preserve and to make use of these principles where appropriate. Yet, the digital revolution is radically changing the kinds of relationships we can have.",
"Furthermore, computer scientists and cryptographers have recently discovered many new and quite interesting algorithms. Combining these messages and algorithms makes possible a wide variety of new protocols.
New institutions, and new ways to formalize the relationships that make up these institutions, are now made possible by the digital revolution. I call these new contracts "smart", because they are far more functional than their inanimate paper-based ancestors. No use of artificial intelligence is implied. A smart contract is a set of promises, specified in digital form, including protocols within which the parties perform on these promises.",
"Smart contracts reference that property in a dynamic, proactively enforced form, and provide much better observation and verification where proactive measures must fall short.",
"The field of Electronic Data Interchange (EDI), in which elements of traditional business transactions (invoices, receipts, etc.) are exchanged electronically, sometimes including encryption and digital signature capabilities, can be viewed as a primitive forerunner to smart contracts.", and
"One important task of smart contracts, that has been largely overlooked by traditional EDI, is critical to "the meeting of the minds" that is at the heart of a contract: communicating the semantics of the protocols to the parties involved. There is ample opportunity in smart contracts for "smart fine print": actions taken by the software hidden from a party to the transaction. [...] To properly communicate transaction semantics, we need good visual metaphors for the elements of the contract."
Nick Szabo first proposed the term in his document titled "Smart Contract" and published in 1994.
As we said in the OntoLix and OntoLinux Further steps of the 5th of July 2017, smart contracts are included in our OS, as can be seen by the facts that for example the Electronic Data Interchange (EDI) format is used in business-to-business transactions and designated as XML/EDI (see also the format XML/EDIFACT) and also listed in the section E-Commerce on the website of Ontologics.info, and Ontologics.info is a part of our overall OS, obviously.
See also the chapter 3 Kolmogorov-Komplexität und algorithmische Informationstheorie==Kolmogorov Complexity and Algorithmic Information Theory of The Prototype and the document Comments in relation with the field of Algorithmic Information Theory (AIT), which is "the result of putting Shannon's information theory and Turing's computability theory into a cocktail shaker and shaking vigorously."

The second document is about a secure, distributed title database and mentions replicated and distributed databases, BFT, and the following in relation with such a database in a very general sense:
"All three attributes - decentralized, secure, and human-meaningful - must be provided if people are to communicate and be communicated about securely over the Internet, and this paper along with the article Advances in Distributed Security [(here the fourth document)] shows how to provide all three.",
"New advances in replicated database technology will give us the ability to securely maintain and transfer ownership for a wide variety of kinds of property, including not only land but chattels, securities, names, and addresses. This technology will give us public records which can "survive a nuclear war", along the lines of the original design goal of the Internet.",
"The property is represented by titles: names referring to the property, and the public key corresponding to a private key held by its current owner, signed by the previous owner, along with a chain of previous such titles.",
"To implement a property club, we set up a replicated database so that the club members, hereafter "servers", can securely maintain titles of ownership, and securely transfer them upon the request of current owners. [...] The purpose of the replicated database is simply to securely agree on who owns what. The entire database is public.",
"The ideal title database would have the following properties:
1. Current owner Alice should be able transfer her title to only a single relying counterparty (similar to the "double spending" problem in digital cash)
2. Servers should not be able to forge transfers
3. Servers should not be able to block transfers to or from politically incorrect parties.
We cannot achieve ideals (1) and (3), so we introduce "voting" [...].", and
"They then may choose to subdivide, sell, give away, etc. property. Each conflicting root grows like a tree into an allocation of all property."

Somehow it is not clear by this vague description how the proposed distributed title database works, because we can only see a single property having a chain of titles. Also, a public-key cryptography or asymmetrical cryptography system is based on mathematical problems that have no efficient solution, such as integer factorization, discrete logarithm, and elliptic curve relationships, and merely uses a cryptographic hash function to accelerate the encryption of a document or a file.
But in the fourth document referenced by us the author explains that it "uses cryptographic hash functions and digital signatures (without the need for a [Public Key Infrastructure (]PKI[)]) on top of a Byzantine-resilient replicated object service to maintain the integrity of chains of property titles".

The third document is about the Peer-to-Peer (P2P) Virtual Machine (VM) Askemos, which we have read at least three times in the last months and therefore we are sure that the author of Askemos has not described such a combination in 2002. We quote the relevant text passages:
"This paper presents Askemos, an autonomous, distributed operating system on top of peer to peer networks which significantly raises the level of abstraction in comparison with today's operating systems.",
"Askemos is an attempt to define a special purpose operating system, machine independent and distributed, with strong emphasis on trustworthiness.",
"Integrity is being assured using appropriate cryptographic algorithms and protocols. [(see the fourth document)]",
"The data is currently held in two storage medias: a) A persistent store, which keeps the tree structures, hash tables etc. in the internal form as accessible by the executable code. The technique is called "pointer swizzling at page fault time". And b) in a file system representation.", and
"For each place there is a globally unique object identifier. In the interest of liability, the identifier should be somehow a function of the content and meta data of the place, this way forgery would be impossible or at least detect- and traceable, as the documents leave their place, i.e., change identifier, whenever the content changes. Such behavior appears to be imperfect for processes, as they become practically inaddressable. Hence, it was decided to keep such an invariant only for authentic documents in the meaning of constant, unforgeable facts. In practice the object identifier happens to be a cryptographic checksum from those properties of the place, which, when kept constant make it a deed. These are the object identifier of the creator, the date of creation, the content of the created document (so far it is analogous to paper certificates) and the dynamics of the process - another document, which plays the role of code in object oriented computer science."

The P2P VM Askemos merely implements the concepts described by N. Szabo in the second and fourth documents but only referenced the Secure INtrusion-Tolerant Replication Architecture (SINTRA). More importantly, Askemos integrates distributed security on the basis of a specific capability-based or right-based system, and a message-based system with only unidirectional and asynchronous process communication, though its description and implementation is relatively rudimentary and on the level of a P2P VM but not the level of an underlying operating system, and "considers [Remote Procedure Call (]RPC[)] a broken design", which also excludes for example the Common Object Request Broker Architecture (CORBA) and other middleware based on the RPC request-response protocol for Inter-Process Communication (IPC) and the Remote Method Invocation (RMI) protocol, which is the object-oriented programming analog of RPC.
Furthermore, one could say that Askemos is a distributed operating system. But in the related document only its utility as a "global user identity and data repository" is mentioned, from a webpage about the smart contract protocol we got the information that Askemos was combined with SQLite in 2009 and 2010, from a webpage about the blockchain technique we got the information that Askemos was also combined with Bitcoin or another blockchain platform based on a cryptographically chained or interconnected data structure after the end of 2008, and from the website of Askemos we got the informations that it is based on the actor model and was combined with cloud computing, which has been related to an avatar somehow. We already said that the latter was done following us with our OS, which integrates the object-oriented, reflective, and distributed operating system Apertos (Muse) with our Evolutionary operating system (Evoos) described in The Proposal and based on the reflective and distributed operating system TUNES OS.

The fourth document discusses the transformation from perfect security to security with very high probability, the utilization of cryptography, and partial and total orders as part of distributed security, and also gives a list of various implementations of different approaches:
"The last decade has witnessed a revolution in distributed security. Old, pessimistic proofs that security and fault tolerance were "impossible", based on assumptions that protocols had to be deterministic and security and fault tolerance properties had to be absolutely certain, have given way to new proofs and implementations of provable security based on the assumption of cryptography and other randomized protocols that achieving security with very high probability is sufficient. The old view "proved" that the integrity properties of a wide variety of services on which civilization depends, whether synchronized clocks, public directories, censorship-proof file sharing and publication, or issuing money or securities were "impossible" on asynchronous networks like the Internet unless we put unlimited faith in a third party to enforce many of the rules of the service.",
"A given property of a system has perfect security if its access structure is any participant and its attack structure is the empty set. An example of a property with perfect security is the use of a spinning neutron star called a pulsar as a clock. Its access structure is any party that can receive its natural broadcasts, and its attack structure is the empty set - given the reasonable presumption that there are no aliens out there who can and want to manipulate the very high energy outputs of pulsars in pursuit of some human ends they have learned about.",
"Another perfect security property is that of encryption against third parties, assuming the encryption is unbreakable. However, if we take into account the receiver of a message as a possible attacker, the broader privacy property is not secure - the receiver is an attack structure of one who can compromise privacy of the entire message encrypted to him.",
"Such a network, called an asynchronous network, lacks an accurate and secure global clock time by which computers can determine the order in which events, which might be messages sent or instructions executed on a particular local machine, have happened. [...] Lamport's answer to the event ordering problem was to show that parties (or, we use the terms equivalently here, nodes on the network) can agree on a partial order of events based on causal relationships between these events - or at least the subset of events where we can determine that causation could occur. On a network, parties influence each other by talking to each other - in other words, by sending each other messages. Lamport used these messages as the basic building block for constructing his partial order, according to the following rules:
1. If an event is local to node P, every nonfaulty node agrees on P's opinion of it.
2. Every correct node agrees that every message was sent before it was received.
3. If we agree that event A occured before event B and that event B occured before event C, then we agree that event A occured before event C. In other words, this partial order is transitive.",
"A common kind of a one-way function is a cryptographic hash function [(said in relation with the technique of the bit commitment.].",
"The ideal protocol would have most trustworthy third party imaginable - a diety who is on everybody's side. All the parties would send their inputs to God. God would reliably determine the results and return the outputs. God being the ultimate in confessional discretion, no party would learn anything more about the other parties' inputs than they could learn from their own inputs and the output. Network security theorists have recently solved this problem to an astonishing extent. They have developed protocols which create virtual machines between two or more parties. Multiparty secure computation allows any number of parties to share a computation, each learning only what can be inferred from their own inputs and the output of the computation. These virtual machines have the exciting property that each party's input is strongly confidential from the other parties. The program and the output are shared by the parties. [...] More information on this exciting breakthrough can be found in the accompanying article "The God Protocols" [published in 1997]. Often [...] the resulting protocol would be very slow. We will now discuss a special efficient kind of multiparty secure computation - threshold cryptography. [...] Threshold cryptography has been used to help achieve Byzantine-resilient replication in Rampart, Fleet, SI[N]TRA, and several other distributed service or filesystem architectures [and also in for example Askemos].",
"Fair coin tosses can be used to create a fair total order of events out of a partial order of events, defined by sending and receiving times for messages, in an asynchronous distributed system. They can similarly be used to achieve atomic broadcast, and thus Byzantine agreement and replication [(see for example SINTRA once again and the OntoLix and OntoLinux Further steps of the 24th of April 2018)]. [...] The threshold coin-tossing system developed by Cachin, Kursawe, and Shoup solves the fair coin tossing problem by implmenting a cryptographic pseudorandom number generator (PRNG) is in a distributed manner using threshold cryptography. They use their protocol to solve the Byzantine generals problem for asynchronous networks.",
"These protocols [for committing to an unforgeable, non-repudiable time-stamp] work by users sending a cryptographic hash (a.k.a. message digest) of their document to the time-stamping servers. The servers chain messages and click ticks together by order of arrival. Replicated servers can break ambiguities in order of arrival with a protocol such as fair coin tossing to achieve a fair total order.",
"Where we choose not to implement such a global clock (because, for example, the price of retrofitting services with a radio time synchronization service as described above), we have another option for creating a fair total order - the fair coin flipping methods described above. The result is a logical broadcast with the same basic security properties as an unjammable physical broadcast.",
"Several Byzantine-resilient replicated service infrastructures have been implemented. They use techniques such as threshold cryptography and fair coin tossing to achieve logical broadcast on asynchronous networks like the Internet [...] See Appendix A below for sources of more information. A wide variety of Byzantine-resilient services can be built on top of logical broadcast.",
"A Byzantine-resilient replicated object library, for implementing online services with distributed trust in the CORBA distributed object system is described [...] Note that the "voting" implicit in Byzantine resilient protocols like that used here protects the integrity of a particular remote method call.",
"This author's design for a secure property title service [(here the second document)] uses cryptographic hash functions and digital signatures (without the need for a PKI) on top of a Byzantine-resilient replicated object service to maintain the integrity of chains of property titles [(see the second document for more details)]. It's also suitable for property-like directories such as the Internet's Domain Name System (DNS).", and
"Appendex A - Implementations
Byzantine-Resilient Replication

[...]
Hash Chain Structures and Secure Time-stamping

[...]
Oblivious Transfer and Multiparty Secure Computation

Capabilities / Smart Sandboxes

Important to note in relation with the listed capability-based systems is the fact that "it is not known whether the [Extremely Reliable Operating System (]EROS[) ...] implementation was careful enough [to be safe and hence secure]. One goal of the [succeeding] Coyotos project is to demonstrate that component isolation and security has been definitively achieved by applying software verification techniques [based on type safety]. [...] In 2003, some very challenging security issues were discovered [7 [Vulnerabilities in Synchronous IPC Designs] that are intrinsic to any system architecture based on synchronous IPC primitives (notably including EROS and L4). Work on EROS halted in favor of [the successor system] Coyotos, which resolves these issues [... and] architectural deficiencies of EROS."

Indeed, the fourth document teaches the combination of some approaches in relation with distributed security, but not all combinations.
Particularly, missing are a suggestion or a motivation for an integration of approaches and systems that belong to the

Most importantly, the combination and integration of different types of distributed legers is missing, like for example systems based on a cryptographic hash chain data structure (e.g. pure blockchain platforms) on the one side and a distributed Virtual Machine (VM) or Virtual operating system (Vos) (e.g. Askemos) on the other side, which was our initial assertion. N. Szabo's system is only a database and Askemos is only a distributed VM or Vos utilized for the execution of smart contracts, which both are described independently from each other by N. Szabo on the basis of SINTRA. Only some years after us Askemos came from the one side and has added a blockchain technique, while a blockchain platform came from the other side and has added a Turing complete VM to its cryptographic hash chain data structure (e.g. Ethereum derived from Bitcoin).

As we said, the integration of the various techniques and technologies made the success and one reason for this is synergy, as can be seen with the combination of a BFT or BRR protocol and a hash chain structure to create and secure a database based on cryptographically chained or interlinked records and its further integration with a Turing complete VM or even an operating system.
Our OS has all these principles generalized to gain synergies wherever possible, reasonable, and advantageous, which shows once again that it includes all of such combinations and integrations based on

which again are handled by other features and elements of our OS, like for example our OntoCore and OntoBot software components based on SoftBionics (SB).
In addition, our OS also

• reflective operating system Muse, its new implementation Apertos, and the Cognac system based on Apertos, which provide
  • distributed systems
    • distributed operating systems,
    • distributed computer networks,
    • distributed programming system,
  • resilience or robustness, including fault tolerance and reliability,
  • the active object model and the actor model, and
  • a persistent object storage,

  and

• Systems Programming using Address-spaces and Capabilities for Extensibility (SPACE) approach, which can achieve "[r]obustness in kernel-less operating systems [...] by executing groups of services in protected domains - each with appropriate restart mechanisms to recover from internal errors",

and

Moreover, our OS is not only stacked on top of a Peer-to-Peer (P2P) network but also the operating system (OpS or os) of the P2P network and hence the P2P network itself as well.
Furthermore, neither the smart contract protocols and cryptographically chained blocks or records nor the Byzantine Fault Tolerance (BFT) protocols and the Byzantine-Resilient Replication (BRR) method are the foundation but messaging, and our OS, specifically the OntoCore, is developed for this as well in addition to the system elements listed above.
Eventually, the result is a system, which is much more flexible, safe, secure, and faster.

Besides these facts it might be interesting to know that the property of the security with very high probability also is one of the reasons why we put the term mostly in parenthesis in the section Basic Properties of the webpage Overview of the website OntoLinux, because very high probably and mostly does not mean entirely.

In the overall summary we

• integration of Apertos (Muse) with Evoos, and
• improvement of the resulting integrated system with the basic properties of a validated and verified, and by the reflective property validating and verifying system,

and

• link to the Domain-Specific Language (DSL) and eXtensible Markup Language XML/EDI,
• relation to the Algorithmic Information Theory (AIT),
• perfect security concept of us, which uses the universe as a space and time indicator, has as access structure that any party can observe its constellation with for example a telescope, which leads us directly to our network of telescopes and the section Space Simulation of the webpage Links to Software, and has as attack structure the empty set, whereby we have to note that our network of telescopes itself does not provide this perfect security, but the distributed security with very high probability based on Byzantine techniques and any manipulation of a telescope and its connection with the network is very easy to find, and
• designation of an Ontologic System in relation with the ideal protocol,

and in addition even developed and improved them much further, specifically in relation with

• grid computing,
• cloud computing, and
• mobile computing.

In this way, we also have drawn the white, yellow, or red line in relation with our copyright and correspondingly there is only a very limited area of legal systems. But the smallest addition of another feature of our OS will provide us a causal link and prove a copyright infringement. For example, the blockchain platforms

• integration of a cryptographic hash chain data structure and a Turing complete VM and
• verified smart contracts (see also the related section of the OntoLix and OntoLinux Further steps of the 5th of July 2017),

have already crossed the line and are convicted, as it is the case with many other blockchain-based systems.

In this sense Trust as a Service (TaaS).

13.May.2018
OntoLix and OntoLinux Further steps
In the last days we continued the work on our utilization of the Chord# and XArray data structures and algorithms for Fault-Tolerant, Reliable, and Trustworthy Distributed Systems (FTRTDSs), specifically distributed ledgers, respectively our integration of the related parts of our OntoBase, OntoFS, OntoNet, and OntoLedger software components (see also the OntoLix and OntoLinux Website update of the 13th of February 2018).

We also continued the work on our exploitation of the formal modeling and formal verification of Fault-Tolerant, Reliable, and Trustworthy Distributed Systems (FTRTDSs), specifically distributed ledgers. The interesting point is that mathematics,

• capability-based approach, and
• encrypted or/and contract-based channel, and
• trusted path,

In view of the second point, mathematics, specifically formal modeling and formal verification, is the third party we can put unlimited faith in, so that the disadvantages of the distributed security with very high probability can be eliminated with perfect security (see also the Clarification of the 11th of May 2018).

SOPR #117
After the fact could be seen in the last weeks, who is collaborationg with whom, we would like to recall the following informations:
In accordance with the international copyright law sublicensing our original and unique Intellectual Properties (IPs) without the accreditation of our Society for Ontological Performance and Reproduction (SOPR) is prohibited.
This covers open source licensing as well.

Furthermore, a copyright infringement is given with the combination or integration of a distributed ledger of a non-member of our SOPR and for example

• Artificial Intelligence (AI),
• Machine Learning (ML), including
  • Artificial Neural Networks (ANNs),
  • Recurrent Neural Networks (RNNs),
  • Deep Neural Networks (DNNs),
  • etc.,
• Computer Vision (CV),
• Semantic World Wide Web (SWWW),
• Cognitive Agent System (CAS),
• Multi-Agent System (MAS),
• Swarm Intelligence (SI) or Swarm Computing (SC),
• Evolutionary Computing (EC),
• etc.,

• reflective knowledge-based or ontology-based middleware,
• ontologic middleware,
• standardized and unified blockchain based system,
• Content-Addressable Networking (CAN or ConAN),
• Content-Centric Networking (CCN),
• etc.
• Ontologic Net of Things (ONoT), including
  • Cyber-Physical Systems (CPS), Internet of Things (IoT), and Networked Embedded Systems (NES) (most potentially also 1.0 and definitely 2.0), including
    • smart city,
    • Industry 4.0,
    • etc.

• Semantic Web of Things (SWoT), including
  • Semantic Sensor Web (SSW),

• Augmented Reality (AR),
• Virtual Reality (VR), and
• Mixed Reality (MR),

• autonomous car,
• etc.,

• SternTaler, StarCoin, StarTaler, Star Money, OntoCoin, and OntoTaler,
• Electronic Funds Transfer (EFT) and exchange service, including
  • Peer-to-Peer (P2P) matching EFT,

Transactions with government agencies (e.g. tax authorities) and businesses have also been discussed and actually are covered by our regulation given in the Ontonics Further steps of the 29th of April 2018 (see also the Clarification of the 4th of May 2018 for example).

In relation with various non-profit foundations and consortiums that have been established in the field of Fault-Tolerant, Reliable, and Trustworthy Distributed Systems (FTRTDSs), specifically distributed legers and blockchain-based systems, after we mentioned our Society for Ontological Performance and Reproduction (SOPR) the first time we would like to recall that they

We also would like to mention that we will not be very amused about an expansion of the technological basis of various foundations and consortiums, specifically of the non-profit ones, because this would disturb the goals or even threaten the integrity of our SOPR.
This simply means if

• like the ones listed above,
• healthcare,
• education,
• controlled or managed finance,
• travel,
• lodging,
• many public sectors,
• and so on

then we suggest to think about the possibility to resolve and merge them into our SOPR, including their distributed ledgers, cryptocurrencies, and potentially other IPs.
See also the sections before once again.

In relation with open source licensing we came to the following conclusions:

• that no (copy)rights for the Ontologic System (OS) or/and the Ontoscope (Os) are transfered and
• how the compatibility with other open source licenses is regulated.

In the next step, we will simply take one of the open source licenses that fits best as a blueprint and transform it in a way that fits best for our SOPR. Then we will look at the result to see how to proceed.

14.May.2018
Ontonics Further steps
We worked a little on our newest electric energy storage technology (see the Further steps of the 3rd and 5th of May 2018), specifically on its (re)charging process and its transformation into final products. The problem is that we are not able to determine its capacity actually, because the physical specifications of the parts of our devices do not match the many and various experimental observations.

SOPR #118
The last weeks and especially the last developments in relation with foundations and consortiums as well as manufacturing processes showed that some sections of the Articles of Association (AoA) and the Terms of Service (ToS) with the License Model (LM) of our Society for Ontological Performance and Reproduction (SOPR) require an update or an extension.
Accordingly, the members of our SOPR, actually only one with the supervisor, have decided unanimously with a sufficient majority of 100% of the eligible voters to update or/and extend the AoA, ToS, and LM where required and reasonable to address:

• non-profit and
• for profit,

and

• manufacturing
  • generative design,
  • rapid prototyping, and
  • automated fabrication
    • thermoforming
    • continuous fabrication,
    • nD (e.g. 2D, 3D, and 4D) printing,
    • electric deposition,
    • selective laser melting and sintering,
    • etc..

We would like to thank every entity for the highly valuable exchange of opinions and inputs.

15.May.2018

Investigations::Multimedia

*** Review - comparison with matter of Muse, Apertos, Cognac, and Exokernel, and discussion of matter referenced in KLOS and SPACE ***

As we already explained in some comments made to the quotes, simply

• the Kernel-Less Operating System (KLOS), which also utilizes hardware-based virtualized resources, and
• a kernel-less operating system based on the Systems Programming using Address-spaces and Capabilities for Extensibility (SPACE) approach, which utilizes no virtualized resources but hardware-based (protection for) cross-domain calls, and capability-based portals between domains for the realization of application-specific operating system services and kernel-less operating systems for example,

• capability-based microkernel L4 and the related hypervisors listed on the webpage Ontologic System Components (OSC), and
• Exokernel with library Operating System (libOS) for example,

and then

to get some kind of an operating system, which includes operating systems like VirtuOS.
In this conjunction, also note that our

• basic property of (mostly) being kernel-less reflective/fractal/holonic and also
• complete range from microkernel or nanokernel based to monolithic operating system architectures (see also for example the Clarification #1 of the 4th of May 2016),

• synchronous and asynchronous modules and therefore synchronous and asynchronous system calls, and
• exception-less modules and therefore exception-less system calls through the integration of the KLOS and SPACE system as well,

and

In fact, the authors of VirtuOS have merely described a specific implementation of the related integrated part of our OS comprising the kernel-less MABOS based on a microkernel, hypervisor, Exokernel and libOS, and also kernel-less operating system in other words and with more technical details (see also the Investigations::Multimedia, AI and KM of the 27th of February 2018).

OntoLix and OntoLinux Website update
In correspondance to the Investigations::Multimedia of today we marked the link to the operating system VirtuOS in the section Exotic Operating System of the webpage Links to Software with **, meaning convicted of copyright infringement.
We will also add the explanation given above to the description of our OntoCore.

17.May.2018
Clarification
Maybe there is some more room for some very specific operating systems by the utilization of the Software Isolated Process (SIP) approach implemented in the operating system Singularity for example to get the advantages of the exception-less mechanism, though

Also, adding only the SIP technology to existing operating systems makes no sense, because such operating systems must change more and more of their foundational properties and elements, specifically the memory management and the scheduler, to integrate it in an efficient and harmonious way, so that

In a more general context related to isolation, we quote a summary in relation with the operating systems Extremely Reliable Operating System (EROS) and Coyotos, which is one of its successors:
"Protection in capability[-based] systems is achieved by restricting the propagation of capabilities from one component to another, often through a security policy known as confinement.
[...]
Pure capability architectures are supported by well-tested and mature mathematical security models. These have been used to formally demonstrate that capability-based systems can be made secure if implemented correctly. The so-called "safety property" has been shown to be decidable for pure capability systems (see Lipton [and Snyder: A Linear Time Algorithm for Deciding Subject Security]). Confinement, which is the fundamental building block of isolation, has been formally verified to be enforceable by pure capability[-based] systems, [1 [Verifying the EROS Confinement Mechanism]] and is reduced to practical implementation by the EROS "constructor" and the KeyKOS "factory". No comparable verification exists for any other primitive protection mechanism. There is a fundamental result in the literature showing that "safety" is mathematically undecidable in the general case (see [Protection in Operating Systems about the computer security model of Harrison, Ruzzo, Ullman (]HRU[)], but note that it is of course provable for an unbounded set of restricted cases [2 [Proof-Carrying Code]]). Of greater practical importance, safety has been shown to be false for all of the primitive protection mechanisms shipping in current commodity operating systems (see HRU). Safety is a necessary precondition to successful enforcement of any security policy. In practical terms, this result means that it is not possible in principle to secure current commodity systems, but it is potentially possible to secure capability-based systems provided they are implemented with sufficient care. Neither [the] systems has [have] ever been successfully penetrated, and their isolation mechanisms have never been successfully defeated by any inside attacker, but it is not known whether the EROS or KeyKOS implementations was [were] careful enough. One goal of the Coyotos project is to demonstrate that component isolation and security has been definitively achieved by [using language type safety and] applying software [respectively language-level] verification techniques."

When we look at our OS based on cryptography, capability, type safety, validation and verification, certification, manifest, and so on, then we conclude once again, as we did around 18 years ago, that perfect security is not so far away even in a distributed system and we also raise the question once again if distributed security is truly required at all, especially in such a broad, slow, and complex way as promoted.
In fact, by the complexity, virtually perfect integration and utilization, and resulting synergetic effects of the fault tolerance, reliability, security, and safety related elements of our OS we might have contradicted already Nick Szabo and others with their statement that perfect security in an asynchronous, distributed system is impossible (see the Clarification of the 11th of May 2018).

18.May.2018
Clarification
In the course of drawing the white, yellow, or red line in relation with the part of our Ontologic System, which is related to operating systems, we looked once again at the Inter-Process Communication (IPC) mechanism of the microkernel-based operating system Spring called door.
We simply quote the original document titled "The Spring nucleus: A microkernel for objects":
"2.2 Doors
Doors are a Spring IPC mechanism resembling in many aspects the gates mechanism of Multics [Organick 1972] or the cross-address space-call mechanisms of Taos [Bershad et al 1990], and in other aspects the communication endpoint notions of sockets in BSD UNIX [Leffler et al 1989] or ports in Mach [Acetta et al 1986].
[...]
Therefore, we extended the notion of doors to reflect our object-oriented call and return model. A door now represents an entry point for a cross-domain call. Associated with the door are both an entry point PC and an integer datum that can be used to identify a particular object in the target domain.
If a domain is granted access to a door, one of its threads may subsequently issue a cross-domain call through the door. This causes a transfer of control into the domain that created the door at the PC specified by the door and with the door datum in a specified register. When the nucleus executes the door call it also records some return information within the nucleus. This return information consists of the caller's domain, the PC to which to return to after the call, and the stack pointer of the caller at the time it issued the call. Then after the call has completed, the called domain will execute a door return. In executing the door return, the nucleus will use the return information that was recorded during the call and return to the callers' address space at the recorded return PC, with the recorded return stack pointer.
When a door call arrives in a server's address space, the server will typically use the datum value to locate the target object and execute an object call. (In practice, there is typically a level of indirection between the datum and actual language level objects in order to permit dynamic interposition on objects for debugging and performance analysis.)
2.3. Door tables
Doors are pieces of protected nucleus state. Each domain has a table of the doors to which the domain has access. A domain references doors using door identifiers, which are mapped through the domain's door table into actual doors. A given door may be referenced by several different door identifiers in several different domains.
[The figure 1 shows clearly that a system call is initiated in respectively an invocation request is sent to the given door by the client process respectively source domain in user mode, enters the kernel service that manages the doors for handling the request in the kernel mode, and finally ends in the server process respectively the target domain in user mode. So we have at least two mode switches.]"
[...]
4.1.1. The fast-path on SPARC V8
Clearly, the details of the fast-path code will vary from machine architecture to machine architecture. On SPARC V8, one of the main considerations was managing the hardware register window set. To keep cross-domain calls cheap, we did not want to flush all the active register windows to memory when we carried out a call. On the other hand, for security and integrity reasons, we wanted to avoid letting the target of a call access any register windows belonging to the client.
Fortunately, the SPARC V8 architecture provides a Window Invalid Mask (WIM) that allows the kernel to prevent user-mode accessing any given register windows. So during a cross-domain call we merely mask out access to the caller's windows. As we take window overflows and write the windows out to the caller's memory, we make these windows available for the use of the called domain. A little care is required during the return sequence to ensure that the WIM is cleared correctly, and that the caller is in fact returning into the correct window.
[...]
On SPARCstation 2, both the trap entry and trap return sequences are fairly cheap, at about 7 cycles each, which is roughly the same as a cache miss. The actual instruction for switching the hardware VM context is slightly more expensive at about 14 cycles, but this still only constitutes a very small percentage of the overall cycle count. The main non-obvious cost is that saving the return information and writing the new thread/domain information both saturate the CPU's write buffer, causing stalls on store instructions until earlier writes are flushed.
We expect it should be possible to obtain similar instruction counts on most modern RISC CPUs. The main imponderable is the cost of switching the MMU context, which happens to be fairly low on SPARC."

For additional valuable informations we also quote the document titled "An Overview of the Spring System":
"5 The nucleus
The nucleus is Spring's microkernel. It supports three basic abstractions: domains, threads, and doors [1 [The Spring Nucleus: A Microkernel for Objects (here the first document)]].
Domains are analogous to processes in Unix or to tasks in Mach. They provide an address space for applications to run in and act as a container for various kinds of application resources such as threads and doors.
Threads execute within domains. Typically each Spring domain is multi-threaded, with separate threads performing different parts of an application.
Doors support object-oriented calls between domains. A door describes a particular entry point to a domain, represented by both a PC and a unique value nominated by the domain. This unique value is typically used by the object server to identify the state of the object; e.g., if the implementation is written in C++ it might be a pointer to a C++ object.
5.1 Doors
Doors are pieces of protected nucleus state. Each domain has a table of the doors to which it has access. A domain refers to doors using door identifiers, which are mapped through the domain's door table into actual doors. A given door may be referenced by several different door identifiers in several different domains.
Possession of a valid door gives the possessor the right to send an invocation request to the given door.
A valid door can only be obtained with the consent of the target domain or with the consent of someone who already has a door identifier for the same door.
As far as the target domain is concerned, all invocations on a given door are equivalent. It is only aware that the invoker has somehow acquired an appropriate door identifier. It does not know who the invoker is or which door identifier they have used.
5.2 Object Invocation Via Doors
Using doors, Spring provides a highly efficient mechanism for cross-address-space object invocation. A thread in one address space can issue a door invocation for an object in another address space. The nucleus allocates a server thread in the target address space and quickly transfers control to that thread, passing it information associated with the door plus the argument data passed by the calling thread.
When the called thread wishes to return, the nucleus deactivates the calling thread and reactivates the caller thread, passing it any return data specified by the called thread.
For a call with minimal arguments, Spring can execute a low-level cross-address-space door call in 11 μs on a SPARCstation 2, which is significantly faster than using more general purpose inter-process communication mechanisms [1 [The Spring Nucleus: A Microkernel for Objects]].
[...]
5.3. Performance discussion
In traditional IPC systems, such as Berkeley sockets, there are three major costs:
First, there is the cost of making scheduling and dispatching decisions. Typically, the thread that issued the request will go to sleep, and the OS kernel will make a careful and objective decision about which thread to run next. With a little luck this will actually be the thread that will execute the request. [...]
Second, there is the cost of performing the context switch between the calling address space and the called address space. At its worst, this will involve a full save of the CPU registers (including floating point registers), a stack switch, and then a restoration of CPU state.
Third, there is the cost of moving the argument and result data between the caller and the callee. Traditional kernels tend to use buffer management schemes that are optimized for passing moderately large amounts of data.
Recent microkernel IPC systems have pushed back on all three of these costs. By assuming an RPC call and return model, it is possible to perform a direct transfer of control between the caller and the callee threads, bypassing the scheduler. Given such a direct transfer, it is also possible to avoid the full costs of a context switch and only save the minimal information that is necessary for an RPC return. By exploiting the fact that most argument sets are small (or that if they are large then they are passed through shared memory), it is possible to avoid buffer management costs.
Different systems vary in the degree to which they have succeeded in minimizing these costs. For example, the Taos LRPC system modelled a cross-domain call as a single thread of execution that crossed between address spaces, thereby avoiding and dispatching or scheduling costs. However, both Mach and NT model the callee threads as autonomous threads which simply happen to be waiting for a cross-process call. This leads to a certain amount of dispatcher activity when a cross-process call or return occurs.
The Spring nucleus has attempted to minimize all three costs. The nucleus' dispatcher works in terms of shuttles, which do not change during cross-domain calls. There are, therefore, no scheduling or dispatching costs during a cross-domain call. Only an absolutely minimal amount of CPU state is saved (basically a return program counter and stack pointer). We do not attempt to save the current register window set, or attempt to switch to a different kernel stack. The fast-path is optimized for the case where all the arguments are passed in registers or shared memory, so the nucleus need not concern itself with buffering arguments or results. In addition, the fast-path code is executed directly in low-level trap handlers and avoids the normal system call costs.
A more mundane factor in our IPC performance is that our nucleus data structures have been tailored to optimize their performance for cross-domain calls. For example, during a cross-domain call there is no need to check that the target door identifier is valid. Instead, a simple mask and indirect load is performed."

Btw.: Now our fans and readers also do know why a developer of a company fiddled around with the cpumask and a single process or user-mode execution context per CPU core, and still has problems with the TLB in accordance with the statements of developers of the companies ARM and Intel as well as a developer who had a related problem with AMD.
This also strenghtens our allegation because the Systems Programming using Address-spaces and Capabilities for Extensibility (SPACE) approach, the operating system Spring, and the partial plagiarism VirtuOS are listed in the OntoLix and OntoLinux Further steps of the 29th of August 2017.
Indeed, it is a tightrope act and the ice is very thin, but maybe the company finds an efficient and elegant way to reimplement Doors/Linux that follows the fast-path concept of Spring, takes from Taos, VirtuOS, and FlexSC some very few details, which are harmless and avoid a causal link from our point of view (e.g. one thread or user process per core and some cpumask flags but no exception-less system call), and improves user-mode file systems, but on the one hand we are still looking at this combination resulting in a door file system, so to say, and on the other hand the next one also wants an asynchronous IPC mechanism, then a homogenous, system-wide solution, and so on.

OntoLix and OntoLinux Further steps
Let us talk about ... no, not flying cars here but about operating systems and microkernels once again.
We reduced the Application Binary Interface (ABI) of operating system primitives even more than others respectively removed them practically mostly and conceptually completely with a kernel-less microkernel, so that a Haven is already the Heaven.
To show this, we recall the relevant features of operating systems that are referenced in the section Exotic Operating System of the webpage Links to Software.

In this relation we quote the following informations given in a document, which is about the SPACE system and was published in July 2005:
"[...]
SPACE
Systems Programming using Address-spaces and Capabilities for Extensibility
- name 'inspired' by Clouds[/Ra distributed operating system]
- a reaction to distributed-shared virtual memory research

Key observation: extending core OS functionality difficult because existing kernel abstractions get in the way (e.g. threads, processes, inter-process communication)
SPACE uses lower-level abstractions:
control flow, address spaces/domains, portals
- represent hardware abstractions
i.e. [Central Processing Unit (]CPU[)], Memory Management Unit (]MMU[)], trap-vectors
- then threads, processes, [Inter-Process Communication (]IPC[)] built on top
Monolithic kernel is not necessary => fundamental extensibility

Kernel-less Operating Systems

SPACE Principles

Kernels: special case of SPACE
Kernel-mode memory mappings (mostly) shared in all spaces
spaces used to build processes
[...]

General SPACE advantages
improved threading
- services without having to synchronize multiple threads
- domains can choose on thread models
e.g. co-routines, or synchronization aware
- potential for higher performance: threads can be very lightweight
separation of resource management from abstractions
- physical resources must still be managed with SPACE
- resources already separately managed in mono-kernels
- SPACE makes resources available with thin abstractions
portals more general than traps
- trap-vector (and MMU) provide hardware-enforced capabilities
- general portal handlers provide fundamental extensibility
- services can be easily filtered

Why don't 'real' OS's use SPACE?
There are hardware architectural issues
- Crossing kernel-boundary is expensive *

There are intrinsic costs
- modularity is expensive **

As the points marked with a * show obviously, the approach of kernel-less operating systems has not been understood completely despite their discussion here.
As the point marked with a ** shows obviously, the design of modern microkernels has not been understood completely despite their discussion here.
As the point marked with a *** shows obviously, the approach of extensible operating systems (including SPACE) has not been understood completely despite their discussion here.
These statements and deficits of one of the authors of SPACE, who is also one of the developers of the Windows kernel, prove obviously, that the related parts of our Ontologic System are original and unique, specifically the following ideas of us, which show that it is possible to use SPACE and similar operating systems in real operating systems on the one hand and have to be seen with integration and synergy in mind on the other hand:

Some clever Linux developers want to ditch the NOMMU port. So let us see who laughs last.

Investigations::Multimedia
*** Work in progress - second document, better comments where needed, epilog ***

We quote a second document:
"Event-driven architectures are currently a popular design choice for scalable, high-performance server applications. For this reason, operating systems have invested in efficiently supporting non-blocking and asynchronous I/O, as well as scalable event-based notification systems.
We propose the use of exception-less system calls as the main operating system mechanism to construct high-performance event-driven server applications. Exception-less system calls have four main advantages over traditional operating system support for event-driven programs: (1) any system call can be invoked asynchronously, even system calls that are not file descriptor based, (2) support in the operating system kernel is nonintrusive as code changes are not required for each system call, (3) processor efficiency is increased since mode switches are mostly avoided when issuing or executing asynchronous operations, and (4) enabling multi-core execution for event-driven programs is easier, given that a single user-mode execution context can generate enough requests to keep multiple processors/cores busy with kernel execution. [This is exactly the matter we mean. If this is truly new, then it belongs to our OS and hence is copyrigted. By the way, "[t]he primary hardware platforms being targeted by the [object-oriented programming] language [X10, which is based on the Partioned Global Address Space (PGAS) and Asynchronous Partioned Global Address Space (APGAS) parallel programming models] are clusters of multi-core processors linked together into a large scale system via a high-performance network."]",
"Libflexsc makes use of exception-less system calls through our Linux kernel implementation [...] [If this is truly new, then it belongs to our OS OntoLinux and: Bingo!!!]",
"With exception-less system calls, instead of issuing system calls in the traditional way using a trap (exception) to switch to the kernel for the processing of the system call, applications issue kernel requests by writing to a reserved syscall page, shared between the application and the kernel, and then switching to another user-level thread ready to execute without having to enter the kernel. On the kernel side, special in-kernel syscall threads asynchronously execute the posted system calls obtained from the shared syscall page, storing the results to the syscall page after their servicing. This approach enables flexibility in the scheduling of operating system work both in the form of kernel request batching, and (in the case of multi-core processors) in the form of allowing operating system and application execution to occur on different cores. This not only significantly reduces the number of costly domain switches, but also significantly increases temporal and spacial locality at both user and kernel level, thus reducing pollution effects on processor structures. [So this is an abstraction of an operating system in accordance with SPACE by using threads instead of processes. Has Space asynchronous system call mechanism? If not, then we do have it in our integrating architecture. Has "Modular Integration of Connectionist and Symbolic Processing in Knowledge-Based Systems" (MIX) "A Multiagent Architecture for Symbolic-Connectionist Integration" for Multi-Agent System (MAS) with shared knowlege and communal knowledge and fusion of several agents respectively processes implemented using threads and shared memory in kernel space? No, as shown with "Redesigning the MIX Multiagent Platform with Threads", because agent services are user space services, but not kernel services, but we do have it in our integrating architecture as well.]",
"Our implementation of exception-less system calls in the Linux kernel [...] was accompanied by a user-mode POSIX compatible thread package, [...] that transparently translates legacy synchronous system calls into exception-less ones. [See once again our statement given on the webpage of the website of OntoLinux: We at OntoLinux, transform operating systems based on Linux into Ontologic Systems. ]",
"4. Simpler multi-processing. With traditional system calls, the only mechanism available for applications to exploit multiple processors (cores) is to use an operating system visible execution context, be it a thread or a process. With exception-less system calls, however, operating system work can be issued and distributed to multiple remote cores. [An implication of this explanation in conjunction with the properties of our OS could be that the attempt to reimplement for example Doors/Linux as a zero-copy user-mode file system in a legal way is impossible if it is not already included in our OS (see once again the OntoLix and OntoLinux Further steps of the 1st of February 2018).]",
"To avoid the overheads of threading, developers have adopted the use [of] event-driven programming. In an event-driven architecture, the program is structured as a state machine that is driven by progress of certain operations, typically involving I/O. Event-driven programs make use of non-blocking or asynchronous primitives, along with event notification systems, to deal with concurrent I/O operations. These primitives allow for uninterrupted execution that enables a single execution context (e.g., thread) to fully utilize the processor.",
"",
"",
"",

In fact, the authors of FlexSC have merely described an implementation of the related integrated part of our OS and showed that our assumptions and estimations about the improved flexibility, adaptability, and performance where absolutely correct and some few cases even over 100% correct.
By the way: Implementation details are irrelevant.

Our transformation of existing monolithic operating systems with for example a kernel-less or/and exception-less approach or/and features of microkernel-based operating systems is not a common progress or improvement, but from our point of view and also from the technical point of view a very foundational step in the evolution of operating systems.
In addition, we already said the following in this context two days ago to show a further time that these features also are parts of our overall work of art titled Ontologic System and therefore the situation is different in this relation as well:

Zero Ontology <-> kernel-less exception-less
plus

Also keep in mind, that our OS

• SoftBionics (SB) (AI, ML, EC, etc.) and
• (smart) molecular or liquid system composition approach as part of our Ontologic(-Oriented) (OO 3) paradigm at design time and also at run time with on-the-fly reconfiguration and so on,

and also includes

• Fault-Tolerant, Reliable, and Trustworthy Distributed Systems (FTRTDSs) in general and
• distributed ledgers in particular,

which all can interact with each other if reasonable and advantageous.

We remember exactly the moment, when we created the content of the webpage Overview and thought about the reactions, specifically when we wrote synchronous and asynchronous in relation with the basic properties of our Ontologic System. We were sure, that every expert in the field of operating systems would declare us as mad and our Ontologic System Architecture as totally ridiculous, and also rip off our heads. But somehow we saw asynchronicity at some places and decided that our OS would not be complete and perfect without it, and obviously and eventually, our concerns have not proven true.

20.May.2018
SOPR #119
We continued with the authoring of the SOPR license or the SOPR license extension for open source hardware and software. This SOPR license or the SOPR license extension could or even should include points like the following:

• AoA = Articles of Association,
• C.S. = Christian Stroetmann,
• C.S. GmbH = Christian Stroetmann GmbH,
• LM = License Model,
• OS = Ontologic System,
• Os = Ontoscope,
• OSA = Ontologic System Architecture,
• SOPR = Society for Ontological Performance and Reproduction,
• ToS = Terms of Service,
• ...

• include the OS or/and the Os in whole or in part,
• be an editing of the OS or/and the Os in whole or in part, or/and
• be any other kind of copy of the OS or/and the Os in whole or in part.

23.May.2018
Website review
Maybe somebody has seen it already. Before we will finish the investigation of the plagiarism FlexSC we started a review of the case of the plagiarism VirtuOS in the Investigations::Multimedia of the 15th of May 2018, because

In detail, the Systems Programming using Address-spaces and Capabilities for Extensibility (SPACE) approach generalizes exceptions for the realization of spaces, domains, and portals, which are also used for the realization of kernel-less operating systems, but still utilizes extended privileged modes and vertical context switches through up- and down-calls as part of the common ring transition.
In a discussion of the costs of crossing hardware domains it is said that "[i]f taken to the extreme, the software protection approach would run all applications in a single hardware protection domain. Systems like the B6700 directly supported this approach in the context of a segmented architecture. However without segmentation, single-address space systems have problems [...]. [...] Short of building single-address space systems, hardware domain crossings will continue to occur." and "Where software protection domains attempt to minimize the frequency of crossing hardware domains, the kernel-less approach assumes that the costs of crossing hardware domains can be dramatically reduced." Also "[s]everal recent systems use protection domains. Opal [15] is an investigation into using a single large address space for running complex applications. Privilege domains are used to manage sharing and protection. Portals between domains are implemented using an explicit capability mechanism rather than an abstraction of the exception mechanism [using an address-based capabilities], as in SPACE." Nevertheless, it is suggested to replace cross-domain calls with procedure calls respectively the vertical mode of interaction with the horizontal mode of interaction.
Exactly this is also done by the KLOS in the context of a segmented architecture. The KLOS has no privileged mode and only a vertical context switch through an up-call of the event handler: "Our architecture, at its heart consists of an event core that is responsible for acting upon external events (hardware interrupts and processor generated exceptions). Events are the only means of vertical up-calls to the unprivileged domain. There are no down-calls to the privileged domain resulting in no context switches during normal program flow. All the components of a typical OS like the memory manager, process manager, device drivers etc. run in the unprivileged domain and have a horizontal mode of interaction." and "We are working towards doing away with the event core and handling interrupts and exceptions at the unprivileged level."

This means that kernel-less operating systems do not utilize the exception-less system call mechanism in general. Or is the term exception-less only stupid marketing to have a term that sounds similar to the term kernel-less? According to the authors of FlexSC "[a]n exception-less system call is a mechanism for requesting kernel services that does not require the use of synchronous processor exceptions. [...] The actual execution of system calls is performed asynchronously by special in-kernel syscall threads". So it merely means an asynchronous exception or asynchronous system call. But once again the SPACE system says in relation with threads: "Two other thread operations are thr _portal and thr _exception. They implement a mechanism similar to UNIX signals. [A signal is an asynchronous notification sent to a process or to a specific thread within the same process in order to notify it of an event that occurred. Signals are similar to interrupts and are mediated by the kernel (possibly via system calls) and handled by processes.] These operations are very efficient in SPACE because they use the generalized exception mechanisms. thr _portal associates the indicated portal with an (X,v) pair. thr _exception will cause the exception to immediately appear to have occurred in the specified thread. If the thread is not running, it is given the current processor, and the caller of thr _exception is blocked. Only asynchronous exceptions can be invoked by thr _exception, since the portal types associated with synchronous exceptions may make faulty assumptions about saving state. To support general software signal delivery, a new generalized exception X is introduced, with parameter v specifying a signal number. Since a particular (X,v) can map to an arbitrary portal type, it is straight forward to implement special signal types which guarantee separate delivery of each example or pass parameters to the handler." So SPACE provides synchronous and asynchronous exceptions as part of its generalized exception mechanisms, but not the exception-less system call mechanism, because its generalized exception mechanisms are still based on synchronous processor exceptions.

Furthermore, we are back at the zoo of possibilities with advantages and disadvantages, but no silver bullet when viewed from the point of classic operating systems.
As we already said in the past, one of our many ideas is based on utilizing all features of all operating systems, such as different types of capabilities, MMU and TLB, and NOMMU and NOTLB, synchronous and asynchronous exceptions, as well as message-based and shared-memory communications, and computing paradigms in an integrated and intelligent architecture whenever and wherever it is advantageous and solving the complexity by the Ontologic System itself.

Preliminary investigation of Linux Foundation and Scylladb started
As not expected otherwise, the developers of the Linux kernel have added some features of our Ontologic System that requires an investigation. In detail:

Something is odd or better said highly suspicious and dubious here:

Also note that a specific implementation is not relevant because we are talking about our original and unique integrating Ontologic System Architecture (OSA) and we might have provided a sufficient evidence to show a causal link with our Ontologic System.

Important to note is the fact, that we were able to show a causal links with our Ontologic System, which is already given with the

• introduction of the asynchronous system calls in Linux and the libaio library came after the publication of our Ontologic System and its integrating architecture on the one hand and
• our integrating Ontologic System Architecture (OSA) (here in relation with the OntoLinux variant) includes all relevant elements, such as the Linux kernel, kernel-less operating systems, and integrated synchronous and asynchronous modules as well as exception-less modules (see for example the integration of the Kernel-Less Operating System (KLOS) with the SPACE system) on the other hand,

and

• NOSQL database, which is the point Data Base Management System (DBMS) of the section Basic Properties of the webpage of the website of OntoLinux, and also our Ontologic File System (OntoFS), and
• asynchronous or concurrent programming framework or library, which includes matter of the reflective operating system Apertos (Muse) and the Cognac system based on Apertos, which again are also integrated in our Ontologic System by our integrating Ontologic System Architecture (OSA).

So not we but others have a problem.

Indeed,

Furthermore, somebody might have come to the combination or integration of the Linux kernel and the SPACE system as well without knowing our OntoLinux. At this point we merely have asynchronous exceptions but not our asynchronous system calls that avoid context switching also called exception-less system calls. This comes with the KLOS or the integration of the KLOS with the SPACE system, because KLOS has no down-calls to avoid the ring transition between user mode and kernel mode. The latter includes functions like aio poll for example. The same can also be done with a Single-Address Space Operating System (SASOS), like the operating system Opal mentioned in relation with segmentation and SPACE, that keep everything in the privileged or kernel mode.
But our Ontologic System is an original and unique overall work of art, and these combinations or integrations of Linux with KLOS, Linux with SPACE, and Linux with KLOS and SPACE, and so on are an essential part of our Ontologic System on the one hand and there is no cherry picking on the other hand.
Even if this latter fact would not be sufficient as an evidence, then adding another part of our Ontologic System will provide an evidence that shows the required causal link. Obviously, the latter is unavoidable respectively has already happened with Fault-Tolerant, Reliable, and Trustworthy Distributed Systems (FTRTDSs), cloud computing systems, an asynchronous programming library, and a NOSQL database, as well as said NOSQL database on top of said asynchronous programming library.

Why a developer also comes up again with that other attempt to create a legal loophole remains a riddle (not really).
It would have been better for the responsible entities to wait until we have finished our investigations and explanations so that they can see the whole picture in relation with the asynchronous and concurrent programming paradigms, specifically in conjunction with the avoidance of context switching and also in relation with the Linux kernel and kernels of UNIX variants, though our improvements are general that can be utilized with every operating system.

The Linux community has had more than a decade to add such features and functionalities to the Linux kernel, but only after we presented our Ontologic System the developers woke up and began to act, as it is also the case with the distributed ledger project and other activities, which for sure should be used together with such an asynchronous framework, databases, cloud computing and other distributed computing paradigms, virtualization, and this and that, and in this way even proves the copyright infringement in a more obvious way. This is not the way it works, especially in relation with the copyright.

There was a big discussion about the introduction of the GNU is not Unix General Public License Version 3 (GNU GPLv3) for the Linux kernel, specifically in relation with copyright, copyright, copyright, and blocking others from linking against their kernel (compare with Android and its Bionic library), but now we observe more and more that others' copyrights are not respected at all. The mask is down and when going on this way, then at least this license does not work anymore, even not for Linux, and more and more legal issues will surface.

In addition, the Linux community is mimicking C.S. and our corporation.
Eventually, the Linux communty is only shooting in its own feet with such an attitude and such activities.

It also seems to be that the company Red Hat is participating once again, as can be seen with its two Linux distributions, which would be no surprise on the one hand and strengthens our allegations on the other hand, and as it is the case with that NOSQL database company, which also copied other parts of our Ontologic System already in the past with its copy of our cloud computing focused operating system and asynchronous programming library (see also the related section below).

The case of the Linux Foundation let us to the company Scylladb with its illegal plagiarisms of our Cloud Operating System (COS) based on our Ontologic System (hypervisor, kernel-less KLOS or/and SPACE system, interrupt handling in threads, distributed system, specifically grid computing and cloud computing, Apertos), parts of our asynchronous and concurrent programming framework complementing programming frameworks based on threads, shared memory, mapped files, and other classic Linux programming techniques (e.g. message-based communication, see the L4 microkernel and active object model or actor model discussed in the Cognac system based on Apertos plus kernel-less KLOS or/and SPACE system; one thread per core, see atomic active object or atomic actor also discussed in the Cognac system; High Performance Computing (HPC); multicore; user-space networking stack with zero-copy, zero-lock, and zero-context-switch, see the integration of KLOS and SPACE, and also Virtual Interface Architecture (VIA) and non-blocking programming language X10 both used for HPC but here with internet protocols) included in our Ontologic System, and the combination and integration of our asynchronous and concurrent programming framework with our Ontologic File System (OntoFS), as well as its mimicking of C.S. and our corporation, which we have added to our investigation pipeline.

A simply implication is that the Zero-copy User-mode File System (ZUFS) is also included in our OS, as can be seen easily with the integration of our exception-less system call mechanism based on the integration of KLOS and SPACE, and the service domains, that handle specific kernel services in user mode providing a networking stack and a file system implementation also based on SPACE (see also the Investigations::Multimedia of the 15th and 18th of May 2018).

Our Ontologic System is not only an original and unique collection and an original and unique integration of original and unique ideas, but also constitutes an original and unique expression of its creator, C.S.. View it like a painting, a sculpture, or a novel, and note that an idea can be an original and unique expression of its creator.
At least the independent entities have proven a further time that at least in parts our OS

25.May.2018
Ontonics Further steps
We were able to improve the already further improved device mentioned in the Further steps of the 29th of April 2018 and 2nd of May 2018 in an even much more significant way than before.
In the course of this we found out why other entities failed to get it working on the one hand and why our solution works so well on the other hand.

SOPR #120
The members of our SOPR, actually only one with the supervisor, have decided unanimously with a sufficient majority of 100% of the eligible voters to completely rethink

• changing some procedures in relation with the licensing of open source hardware and software projects,
• changing some procedures in relation with the funding of open source hardware and software projects, and
• SOPR license and SOPR license extension for open source hardware and software,

where required and reasonable, and even

as already suggested in the issues #118 of the 14th of May 2018 and #119 of the 20th of May 2018.
Potentially, we were much too nice so that our offer has not been understood as a chance and a consensus by too many entities.

In relation with the AoA we are thinking about removing it without substitution.

In relation with the ToS we are thinking about updating it, so that it matches our business plan, strategy, and goal in a better way.

In relation with the LM we are thinking about

Maybe we will consultate some judges to find the objective values.

In relation with the funding of open source hardware and software projects we have withdrawn any commitment of support and instead are thinking about other ways that could be similar to activities of other companies. Needless to say, a distinct social competence is mandatory for participating in the new procedure.

In relation with our SOPR license and SOPR license extension for open source hardware and software we are thinking about

• select an open source license, which is accredited by our SOPR, or
• provide an open source license, which can be accredited by our SOPR,

and

There will be no more concessions and the time of experimenting was over in 2016.

Btw.: The Linux kernel is beginning to become illegal software (e.g. libaio), as it is the case with the software of its sponsors and other open source projects, which also affects the Ontologic System variant Android.
It is unbelievable: There are companies that steal our Intellectual Properties (IPs) to make money. Then they take a part of this money to sponsor open source software foundations, like the Linux Foundation, the Apache Foundation, and the Mozilla Foundation, and many more organizations related to this and that, and to steal even more of our IPs and they are even supported in doing so by the foundations to increase the damage inflicted in this way. Are they or we totally nuts? They all must come down to earth again and understand that they are committing crimes, and even crimes in orchestrated ways and generating a very high damage, which means serious crimes. And no, we have not written the laws that they are infringing.

27.May.2018
Website update
We managed to finish the Clarification of the 11th of May 2018. The other matter remained the same with the exception of the matter related to the reflective operating systems Apertos (Muse) and Evoos, The Proposal, and the conclusion proving the initial assertion.
The most important point for us is that we were able to show by comparison with systems of four different sources (Nick Szabo's systems, Askemos, and Apertos (Muse), as well as SPACE) that Fault-Tolerant, Reliable, Trustworthy, and Distributed Systems (FTRTDSs) are included in our Ontologic System, specifically the integration of validated and verified, and validating and verifying Virtual Machines (VMs) and Virtual operating systems (Voss) with validated and verified, and validating and verifying databases, better known as blockchain platforms with Turing complete VMs.
The next detail to be investigated by us is the combination of blockchain platforms and the Internet of Things (IoT) but about the combination of blockchain platforms and the field of SoftBionics we think that a clarification is not required at all.

Ontonics Further steps
When we worked on the newest improvement of the device mentioned in the Further steps of the 25th of May 2018 (actually the Further steps #1 of today), then we also looked at another solution for a problem.
Today, we thought about this other solution once again and concluded at first that it could be utilized for the construction of a different variant of the device. But before we sketched the design we also concluded that it explains the working principle of another device, which might work for the first time or if it already worked might perform once again.

In a subsequent step, we also integrated this solution into the material mentioned in the Further step of the 3rd of May 2018.

28.May.2018

17:04, 20:26, 23:56, and 32:31 UTC+2
Blockchain fraud will come to an end #2

In relation with the copyright infringement by the distributed operating system EOS.IO the short result of a short investigation is as follows: We have found many basic properties of our Ontologic System (OS), such as (mostly) being reflective and validated, including proof of existence (keyword ontology), cryptographically verified, distributed operating system or virtual operating system, databases, transactional, atomic, single-threaded application testnet, synchronous and asynchronous communication, message-based and shared-memory architectures, actor model, declarative role-based permission management system, Byzantine Fault Tolerance (BFT) protocols and Byzantine-Resilient Replication (BRR) method with voting, smart contract protocol, scope, Ethereum plagiarism, development environment, etc., and the integration of all, specifically a database with a Virtual Machine (VM) (see e.g. Ethereum once again), is much too much and in this constellation a doubtlessly clear evidence that shows the causal link with our original and unqiue work of art titled Ontologic System created by C.S.. Its white paper and system architecture is in parts only a bold copy of matter found on our website of OntoLinux.

Said this, using of EOS.IO is not for free even if the responsible entity claims that.
As we said before, our OS is the only legal platform (see also the notes Blockchain fraud will come to an end #1 of the 8th of May 2018 and Dump that island system of the 10th of May 2018) and in accordance with the actual jurisprudence, we are allowed to

For the estimation, we take the fees of the (pure) blockchain platform Bitcoin transformed in U.S. Dollar as reference value.

Btw.: Its Initial Coin Offering (ICO) gives us a first estimation for the objective value only of this part of our OS, which has to be tripled for an estimation of the damages. It is claimed that the EOS market capitalization was 4,588,080,009 U.S. Dollar on the 6th of April 2018 and 15.6 billion U.S. Dollar on the 1st of May 2018.
But to get a more precise estimation, we have to add the ICOs and market capitalizations respectively their translation into the overall revenues or damages (take the one that fits your mood best) of Ethereum, Tezos, and some other blockchain platforms as well.

Hasta la vista, babies, or what about 33% of the ICO instead of FBI and Co. due to investment fraud among other illegal activities, for sure in addition to the common licensing?
Honestly, we prefer to make a clear cut and tend to prohibit all distributed ledgers and other FTRTDSs, that are not managed by the Society for Ontological Performance and Reproduction (SOPR), or being more precise, we exclude any reproduction of the Ontologic Net (ON), Ontologic Web (OW), and Ontologic uniVerse (OV) from licensing.
Indeed, in this way everybody can continue with

while the integrity of our SOPR remains intact. Oh, yeah, that is it! Why have not we got this idea before?

EOS.IO is a fraud anyway. In fact, they are only stealing essential parts of our OS to make fast money and then immediately disappear again, and the cases of Ethereum, Tezos, and all the similar FTRTDSs are not much better.

Any other opinions or suggestions to be discussed by the Steering Committees of the SOPR?

29.May.2018

00:17, 08:05, and 10:21 UTC+2
Attention: Fraud with our OS

Do not invest your money in the distributed operating system EOS.IO and do not build any applications and services on top of EOS.IO (see the note Blockchain fraud will come to an end #2 of the 28th of May 2018 (yesterday)). In fact, it is a scam, because the responsible entity

Busted!!!
Furthermore, such blockchain-based systems and similar distributed systems will not work without the broad consensus upon the public, especially the industries, that can only be provided by our SOPR.

Our business unit Ontonics and our SOPR will ban such platforms As Soon As Possible (ASAP), though we do not accept other cryptocurrencies than the official digital currencies of sovereign states and the ones of our Ontologic Bank (OntoBank) anyway, and if the responsible entities refuse to give in and give the money back, then we have to inform the prosecutors due to the conduction of an investment fraud, and the promotion and the funding of illegal activities.

Btw.: There is no race, because we have already won the pot in 2006.

SOPR #121
We have thought and discussed about the following topics:

Request of the supervisor
Upon the request of the supervisor the members of our SOPR, actually only one with the supervisor, have decided unanimously with a sufficient majority of 100% of the eligible voters to update the Articles of Association (AoA) and the Terms of Service (ToS) with the License Model (LM) of our Society for Ontological Performance and Reproduction (SOPR) in relation with all elements that are related to the foundational infrastructure of the Ontologic System (OS).
This comprises as a first measure that any reproduction of the Ontologic Net (ON), the Ontologic Web (OW), and the Ontologic uniVerse (OV) has been explicitly excluded from licensing just right from the start to avoid prosecuting after a serious damage to the integrity of our SOPR has already happened.

This change was required because the test phase running since around July 2017 showed that otherwise it always leads to the

• conduction of investment frauds and
• promotion and funding of illegal activities,

In addition, we have made clear several times in the past already that everybody is only working on the realization of our OS in one way or another eventually.
Therefore, the SOPR is the place, where interests in relation with the ON, OW, and OV are unified, and not in individual external groups.
See also the Comment of the Day of the 5th of April 2018 and also add distributed virtual machines, and distributed operating systems or virtual operating systems.

As implications

• distributed ledgers,
• distributed virtual machines,
• distributed operating systems or virtual operating systems,
• distributed data stores or distributed storage systems, and
• distributed databases, as well as
• cryptocurrencies,

such as for example the Mobility Open Blockchain Initiative (MOBI), can work in the areas of local systems, and all kinds of systems, applications, and services, as well as related standards, and

• systems based on the operating system functionality and other functionalities of our Ontologic System Components (OSC), like for example Windows, iOS, Android, and so on, and
• autonomous vehicles,

but the

• the art projects titled Hovercity, Hoverland, and Superstructure, based on our OS, and also created by C.S., and
• autonomous vehicles,

Update of the License Model (LM)
The feedback we got so far in relation with the License Model (LM) shows that the commitment to the 5% share of the overall revenue generated with an Ontologic Application (OA) and Ontologic Net (ON), Ontologic Web (OW), and Ontologic uniVerse (OV) Service (OAOOOS or OAO³S) or simply Ontologic Application and Ontologic Service (OAOS) is intact.
One very large entity might have suggested to double the fixed fees.

We also came to the conclusion that no change of the LM is required, even not in relation with autonomous vehicles.
But we would like to give the reminder that also internal OAOSs are licensed in the same way as external OAOSs, despite it might look a little unusual at first sight, because we see this licensing of internal OAOSs as a compensation for the given allowance to other entities to utilize our OS for realizing parts of our businesses, that otherwise would be restricted through other measures of the right holder.

A prominent example is the field of generative technologies, specifically the variants which integrate the Computer-Aided Design (CAD) process with the manufacturing process based on the field of SoftBionics (SB) and other functionalities of our OS, that we would like to explain on the basis of the two following simplified use cases or business processes:

The logic behind the second case becomes comprehensible when the manufacturer produces

Also note that this is independent from the reproduction of the Ontologic System (OS), the Ontoscope (Os), and other items directly connected with our OS and our Os, that are licensed under fixed fees.

In addition, we continued the work on the structure of the LM, specifically on the height of the fees for some specific items and the overall balancing of the fees to keep them in the targeted limits.