02.August.2019
Ontonics Further steps
We adapted a first feature of a specific variant of the elegant, ground-laying solution mentioned in the Further steps of the 18th of June 2015 for the development of a more general solution.

Furthermore, we adapted a second feature of the elegant and highly appreciated solutions mentioned in the Further steps of the 17th of April 2015 and 23rd of September 2017 for the integration with the first feature to a more general solution, which extends the ranges of utilization of all solutions and accordingly is quite fascinating.

06.August.2019
Ontonics Further steps
In the last days, we reviewed and continued the work on an older technological basis and began experimenting with some related configurations.
In the course of this we developed a very straight configuration or variant.
If this really works better than other solutions, then this is a revolution, mildy said.

SOPR #215
We would like to recall some of our considerations and regulations in relation to the following topic:

Public and federal duties, tasks, and services
Honestly, we had other personal, social and societal, cultural, and economical intentions with our works of art titled Ontologic System and Ontoscope.
Howsoever, we have observed the obvious development trend as well: More and more technologies (e.g. systems and platforms), goods (e.g. applications), and services based on our Ontologic System (OS) and our Ontoscope (Os), specifically the integration of

• Fault-Tolerant, Reliable, and Trustworthy Distributed Systems (FTRTDSs),
• blackboard systems,
• Grid, Cloud, and Edge Computing Systems (GCECSs), and
• multi-cloud computing systems, dynamic federation systems, and service meshing systems,

• Industrial Internet of Things (IIoT) and
• Industry 4.0 and 5.0,

• Augmented Reality Environments (AREs),
• Virtual Reality Environments (VREs), and
• Mixed Reality Environments (MREs),

• Artificial Intelligence (AI),
• Machine Learning (ML),
• Computer Vision (CV),
• Simultaneous Localization And Mapping (SLAM),
• Cognitive Vision (CogV),
• Cognitive Agent System (CAS),
• Cognitive Computing (CogC),
• Emotional Intelligence (EI),
• Multi-Agent System (MAS),
• Swarm Intelligence (SI) or Swarm Computing (SC),
• Evolutionary Computing (EC),
• etc.,

• Service-Oriented Computing of the second generation (SOC 2.0) based on the integration of Service-Oriented Architecture (SOA) with Autonomic Computing (AC) and SWWW,

are utilized and developed by governments and companies alone and together.
But we have the impression somehow that they are working together in ways that

We already made some related general remarks in the issue #186 of the 5th of June 2019.
Furthermore, the regulation of the revised and extended Articles of Association (AoA) and the Terms of Service (ToS) of our Society for Ontological Performance and Reproduction (SOPR) is very simple and clear in relation to such a specific situation by demanding that the related technologies, goods, and services of public and federal institutes and authorities, and state-owned companies are put into practice under the exclusive management and control of either

but not under the management and control of any other entity (see for example the issue #183 of the 2nd of June 2019).

This regulation was also drafted in such a way that the

and the

as much as possible. As far as our rich knowledge and experience reach and we can see, the existing powers and structures seem not be able to handle the inevitable change and therefore some kind of a new power and an extended structure is advantageous for all entities concerned, which can only be our SOPR with its infrastructure for all the many related reasons that were discussed in the past, are discussed here, and will be discussed in the future.

09.August.2019

21:55 UTC+2
Investigations::Multimedia

*** Work in progress - some quotes, explanations, and references are missing ***

From the website of the partial OS clone called Zircon and Fuchsia: "Fuchsia Documentation
[...]

Glossary
Overview [See the webpage Overview of the website of our Ontologic System OntoLinux.]
The purpose of this document is to provide short definitions for a collection of technical terms used in Fuchsia.
Terms [See the webpage Terms of the 21st Century of the website of our Ontologic System OntoLinux.]
Agent [] An agent is a role a component can play to execute in the background in the context of a session. An agent's life cycle is not tied to any story [in contrast to a module], is a singleton per session, and provides services to other components. An agent can be invoked by other components or by the system in response to triggers like push notifications. An agent can provide services to components, send and receive messages, and make proposals to give suggestions [or recommendations] to the user. [See the list point Agent-Based Operating System (ABOS) of the section Basic Properties of the webpage Overview, the OntoBot (OB) software component, and the sections Exotic Operating System, Natural Language Processing, Formal Modeling, Intelligent/Cognitive Agent, and Intelligent/Cognitive Interface of the webpage Links to Software of the website of our Ontologic System OntoLinux. Also note the term proposal, which is used to confuse the public in relation to The Proposal somehow, as can be seen with the terms overview and terms as well. In addition, the ability of an agent to give recommendations or suggestions to a user was copied from the webpage Ontologic Applications and Ontologic Services (OAOS). Because Zircon and Fuchsia together are a capability-based operating system, they are also a capability-based Agent-Based Operating System (ABOS). At this point, we already got the underniable evidences that prove the causal link with our OS and consequently the next infringements of our copyright and other rights. If this would not be the case due to the mysterious existence of prior art, which we do not know, then we leave it up to our fans and readers to add reflective, concurrent, microkernel-based, multi-agent-based, cloud-based, and distributed to get a more complete experience of the whole issue. We also would like to note that the term life cycle reminds us of Total Quality Management (TQM) also listed as a basic property.]
AppMgr [] The Application Manager (AppMgr) is responsible for launching components and managing the namespaces in which those components run. [...]
Banjo [] Banjo is a language for defining protocols that are used to communicate between drivers. It is different from [the Fuchsia Interface Definition Language (]FIDL[)] in that it specifies an ABI for drivers to use to call into each other, rather than an IPC protocol.
[...]
bootfs [] The bootfs RAM disk contains the files needed early in the boot process when no other filesystems are available. It is part of the [Zircon Boot Image (]ZBI[)] [...].
[...]
Cache directory [] Similar to a data directory, except that the contents of a cache directory may be cleared by the system at any time, such as when the device is under storage pressure. Canonically mapped to/cache in the component instance's namespace.

• Testing isolated cache storage.

Capability [] A capability is a value which combines an object reference and a set of rights. When a program has a capability it is conferred the privilege to perform certain actions using that capability. A handle is a common example for a capability. [See the webpage Components of the website of OntoLinux and remember that the L4 microkernel is a capability-based microkernel.]
Capability routing [] A way for one component to give capabilities to another instance over the component instance tree. Component manifests define how routing takes place, with syntax for service capabilities, directory capabilities, and storage capabilities. [] Capability routing is a components v2 concept. [...] [As not expected otherwise, Google also assimilated another capability-based operating system specialized on exactly this tree-based capability management concept and investigated in the Investigations::Multimedia of the 13th of December 2017.]
Channel [] A channel is an [Inter-Process Communication (]IPC[)] primitive provided by Zircon. It is a bidirectional, datagram-like transport that can transfer small messages including Handles. FIDL protocols typically use channels as their underlying transport.

• Channel Overview

[See the OntoCore (OC) software component of our Ontologic Systems OntoLix and OntoLinux, specifically the section about the Contract-Based Channel (CBC).]
Component [] A component is a unit of executable software on Fuchsia. Components support capability routing, software composition, isolation boundaries, continuity between executions, and introspection. [See the webpage Components of the website of OntoLinux once again, the OntoCore (OC) once again, specifically the section about the Software Isolated Processe (SIP), and the section Basic Properties of the webpage Overview once again, specifically the characteristic of being reflective, because reflection includes introspection.]
Component collection [] A node in the component instance tree whose children are dynamically instantiated rather than statically defined in a component manifest. [] Component collection is a components v2 concept. [The basic property of being reflective and holonic already implies that our OS has this dynamic property as well. See also for example the document titled "MINERVA - A Dynamic Logic Programming Agent Architecture" and referenced in the section Intelligent/Cognitive Agent of the webpage Links to Software.]
Component declaration [] A component declaration is a FIDL table [...] that includes information about a component's runtime configuration, capabilities it exposes, offers, and uses, and facets. [] Component declaration is a components v2 concept.
Component Framework [] An application framework for declaring and managing components, consisting of build tools, APIs, conventions, and system services.

• Components v1, Components v2

[As the title Ontologic System might suggest already, we use ontologies for declarations, manifests, and everything else so that our OntoBot knows what it is and what has to be done with it.]
Component instance [] One of possibly many instances of a particular component at runtime. A component instance has its own environment and lifecycle independent of other instances. [Note that not the term context but environment was used in relation to for example Mediated Reality Environment (MedRE) listed in the section Basic Properties of the webpage Overview. We also note once again Total Quality Management (TQM) also listed as a basic property in relation to lifecycle.]
Component instance tree [] A tree structure that represents the runtime state of parent-child relationships between component instances. If instance A launches instance B then in the tree A will be the parent of B. The component instance tree is used in static capability routing [(see above)] such that parents can offer capabilities to their children to use, and children can expose capabilities for their parents to expose to their parents or offer to other children. [] Component instance tree is a components v2 concept. [We already mention at this point our Ontologic Scene Graph explained for example in the section of the webpage of the Ontologic File System (OntoFS) component of our Ontologic Systems OntoLix and OntoLinux.]
Component Manager [] A system service which lets component instances manage their children and routes capabilities between them, thus implementing the component instance tree. Component Manager is the system service that implements the components v2 runtime.
Component Manifest [] In Components v1, a component manifest is a JSON file with a .cmx extension that contains information about a component's runtime configuration, services and directories it receives in its namespace, and facets. [] In Components v2, a component manifest is a file with a .cm extension, that encodes a component declaration.

• Component manifests v2

[Here we have once again the other assimilated capability-based operating system investigated in the Investigations::Multimedia of the 13th of December 2017. Furthermore, declarative programming paradigms include the functional, logic, constraint, and dataflow paradigms, and also the ontology or ontology-based paradigms. See the OntoCore (OC) component once again, specifically the section about Manifest-Based Programs (MBPs). When taking this note about MBPs together with the notes about Software Isolated Processes (SIPs) in relation to the programming language Dart (see below) and Contract-Based Channels (CBCs) in relation to the IPC primitive channel (see above), and the explanations that on the one hand we integrated SIPs, CBCs, and MBPs with capability-based operating systems and on the other hand this change from runtime configuration information to declaration mimicks our change from manifest to model respectively ontology, then it should become obvious at this point even for non-experts that Google took our OC as blueprint. Eventually, we got the next evidences for showing a causal link with our OS.]
Component Manifest Facet [] Additional metadata that is carried in a component manifest. This is an extension point to the component framework. [An ontology is often utilized as metadata as well and sometimes metadata is taken as designation for an ontology. Besides this, we note that our ontology-based approach is much more consistent by simply taking only an ontology for each component and that the term facet is also often used in the field of Knowledge Management (KM), for example in relation to the navigation of taxonomy or Topic Map (TM) by selecting a combination of topics as part of a faceted search. TMs are included in our OS on the webpage Introduction of the website of OntoLinux.]
Components v1 [] A shorthand for the Component Architecture as first implemented on Fuchsia. Includes a runtime as implemented by appmgr and sysmgr, protocols and types as defined in fuchsia.sys, build-time tools such as cmc, and SDK libraries such as libsys and libsvc.

• Components v2

[Luckily, it does not matter in this case from a legal point of view who implemented what as the first one. At this point we do know three facts: The components are component architectures, have concepts, and are different. Obviously, we have here the Components and the Integrating Architecture of our Ontologic Systems OntoLix and OntoLinux.]
Components v2 [] A shorthand for the Component Architecture in its modern implementation. Includes a runtime as implemented by component_manager, protocols and types as defined in fuchsia.sys2, and build-time tools such as cmc.

• Components v1

Concurrent Device Driver [] A concurrent device driver is a hardware driver that supports multiple concurrent operations. This may be, for example, through a hardware command queue or multiple device channels. From the perspective of the core driver, the device has multiple pending operations, each of which completes or fails independently.
Core Driver [] A core driver is a driver that implements the application-facing [Remote Procedure Call (]RPC[) request-response protocol for Inter-Process Communication (IPC)] interface for a class of drivers (e.g. block drivers, ethernet drivers). It is hardware-agnostic. It communicates with a hardware driver through banjo to service its requests.
Data directory [] A private directory within which a component instance may store data local to the device, canonically mapped to /data in the component instance's namespace.
DevHost [] A Device Host (DevHost) is a process containing one or more device drivers. They are created by the Device Manager, as needed, to provide isolation between drivers for stability and security.
DevMgr [] The Device Manager (DevMgr) is responsible for enumerating, loading, and managing the life cycle of device drivers, as well as low level system tasks (providing filesystem servers for the boot filesystem, launching AppMgr, and so on). [Again, life cycle and managing it reminds us once again of Total Quality Management (TQM) listed as a basic property. See also the link to Coccinelle - a Framework for Linux Device Driver Evolution in the section Formal Verification of the webpage Links to Software.]
DDK [] The Driver Development Kit is the documentation, APIs, and ABIs necessary to build Zircon Device Drivers. Device drivers are implemented as [Executable and Linkable Format (]ELF[)] shared libraries loaded by Zircon's Device Manager.

• DDK Overview
• DDK includes

[See the link to DDverify - Extraction Tool of Linux Device Drivers in the section Formal Verification of the webpage Links to Software and also the related comments in the Investigations::Multimedia of the 13th of December 2017.]
Directory capability [] A capability that permits access to a filesystem directory by adding it to the namespace of the component instance that uses it. If multiple component instances are offered the same directory capability then they will have access to the same underlying filesystem directory. [] Directory capability is a components v2 concept.

• Capability routing

Environment [] A container for a set of components, which provides a way to manage their lifecycle and provision services for them. All components in an environment receive access to (a subset of) the environment's services. [This definition is very interesting, because an environment is a container with management life cycle and provision services, which also connects Mediated Reality Environment (MRE), Total Quality Management (TQM), and Grid, Cloud, and Edge Computing Systems (GCECS) somehow. Maybe we are a little to restrictive but this integration is a little too much for us and therefore we keep this in mind as a potential evidence that shows a causal link with our OS, which is given in the moment that reality or quality comes into play as well.]
Escher [] Graphics library for compositing user interface content. Its design is inspired by modern real-time and physically based rendering techniques though we anticipate most of the content it renders to have non-realistic or stylized qualities suitable for user interfaces. [See the OntoGraphics and Ontoscope software components, which are the original designs. In fact, we do not know a prior art that integrates a real-time and physically based rendering technique with a compositor and therefore we consider this as the next evidence that proves the causal link with our OS. For our fans and readers, who do not know where the term Escher originates from, we would like to give the explanation that Maurits Cornelis Escher was a Dutch graphic artist who made very well known and outstanding mathematically-inspired woodcuts, lithographs, and mezzotints featuring mathematical objects and operations including impossible objects, explorations of infinity, reflection, symmetry, perspective, truncated and stellated polyhedra, hyperbolic geometry, and tessellations. He was one of the major inspirations of Douglas Hofstadter's Pulitzer Prize-winning 1979 book titled "Gödel, Escher, Bach: An ..., and even of our Evolutionary operating system (Evoos) described in The Proposal (see its citation in the section [2.4] Strange-Loops in the document titled More Notes and related to The Proposal and The Prototype). See also the logo of the C.S. GmbH inspired by M.C. Escher's work of art titled Belvedere.]
FAR [] The Fuchsia Archive Format is a container for files to be used by Zircon and Fuchsia. [...]
FBL [] FBL is the Fuchsia Base Library, which is shared between kernel and userspace.

• Zircon C++

fdio [] fdio is the Zircon IO Library. It provides the implementation of posix-style open(), close(), read(), write(), select(), poll(), etc, against the RemoteIO RPC protocol. These APIs are return- not-supported stubs in libc, and linking against libfdio overrides these stubs with functional implementations.
FIDL [] The Fuchsia Interface Definition Language (FIDL) is a language for defining protocols that are typically used over channels. FIDL is programming language agnostic and has bindings for many popular languages, including C, C++, Dart, Go, and Rust. This approach lets system components written in a variety of languages interact seamlessly. [...]
Flutter [] Flutter is a functional-reactive user interface framework optimized for Fuchsia and is used by many system components. Flutter also runs on a variety of other platforms, including Android and iOS. Fuchsia itself does not require you to use any particular language or user interface framework.
Fuchsia API Surface [] The Fuchsia API Surface is the combination of the Fuchsia System Interface and the client libraries included in the Fuchsia SDK.
Fuchsia Package [] A Fuchsia Package is a unit of software distribution. It is a collection of files, such as manifests, metadata, zero or more executables (e.g. Components), and assets. Individual Fuchsia Packages can be identified using fuchsia-pkg URLs.
Fuchsia SDK [] The Fuchsia SDK is a collection of libraries and tools that the Fuchsia project provides to Fuchsia developers. Among other things, the Fuchsia SDK contains a definition of the Fuchsia System Interface as well as a number of client libraries.
Fuchsia System Interface [] The Fuchsia System Interface is the binary interface that the Fuchsia operating system presents to software it runs. For example, the entry points into the vDSO as well as all the FIDL protocols are part of the Fuchsia System Interface.
Fuchsia Volume Manager [] Fuchsia Volume Manager (FVM) is a partition manager providing dynamically allocated groups of blocks known as slices into a virtual block address space. The FVM partitions provide a block interface enabling filesystems to interact with it in a manner largely consistent with a regular block device.

• Filesystems

[See the Feature-List #1.]
GN [] GN is a meta-build system which generates build files so that Fuchsia can be built with Ninja. GN is fast and comes with solid tools to manage and explore dependencies. GN files, named BUILD.gn, are located all over the repository.

• Language and operation
• Reference
• Fuchsia build overview

[This reminds us a little of the SimAgent Toolkit in relation to the projects referenced in the section Formal Modeling of the webpage Links to Software and our Ontologic Programming (OP) paradigm.]
Handle [] A Handle is how a userspace process refers to a kernel object [and "a common example for a capability"]. They can be passed to other processes over Channels.
Hub [] The hub is a portal for introspection. It enables tools to access detailed structural information about realms and component instances at runtime, such as their names, job and process ids, and published services. [With the programming language Dart used for the User Interface (UI) framework Flutter we also have a complete reflective, concurrent (sub)system, which is another essential part of our OS, which again is based on our integration of the TUNES operating system Language project, the reflective, object-oriented, (resilient) fault-tolerant, reliable, and distributed operating system Apertos (Muse) and the Cognac system based on Apertos, which all are included in the sections Basic Properties and Integrating Architecture of the webpage Overview and referenced in the section Exotic Operating System of the webpage Links to Software. This provides us the next evidence that shows the causal link with our OS. These facts are also relevant in relation to the programming language Dart utilized for Flutter and web-based multi-device applications. Honestly, we do not know why terms like hub and portal are used in this relation.]
Jiri [] Jiri is a tool for multi-repo development. It is used to checkout the Fuchsia codebase. It supports various subcommands which makes it easy for developers to manage their local checkouts.

• Reference
• Sub commands
• Behaviour
• Tips and tricks

[First of all, we would like to give the recommendation not to confuse this with Java Jini. Furthermore, we already quote the linked webpage Reference here: "Jiri integrates repositories intelligently" and in this way it reminds us of NixOS and GoboLinux linked in the section Operating System of the webpage Links to Software.]
Job [] A Job is a kernel object that groups a set of related processes, their child processes and their jobs (if any). Every process in the system belongs to a job and all jobs form a single rooted tree. [...] [See also the quote of the term Capability routing once again.]
Kernel Object [] A kernel object is a kernel data structure which is used to regulate access to system resources such as memory, i/o, processor time and access to other processes. Userspace can only reference kernel objects via Handles. [Remember that "[a] handle is a common example for a capability" and "can be passed to other processes over Channels".]
Ledger [] Ledger is a distributed storage system for Fuchsia. Applications use Ledger either directly or through state synchronization primitives exposed by the Modular framework that are based on Ledger under-the-hood. [See the OntoLedger software component and our other publications related to blockchain-based technologies, goods, and services, and distributed ledgers. In addition, we already quote the webpage Ledger here "[e]ach data store [of the distributed storage system] is transparently synchronized across devices of its user through a cloud provider", which is a part of our first description of cloud computing (functionalities or services) given in the Feature-List #2, obviously: "Personal World Wide Web-based infrastructure, network, and virtual drive, that supports the user centric migration 'Max-Mig', synchronization 'Max-Sync' of applications and data, and communication 'Max-Com'". See also the section Network Technology of the webpage L2SW for more works based on Peer-to-Peer (P2P) and cloud computing.]
LK [] Little Kernel (LK) is the embedded kernel that formed the core of the Zircon Kernel. LK is more microcontroller-centric and lacks support for MMUs, userspace, system calls - features that Zircon added. [At this point one can see how the support for the many different devices is realized. Fuchsia includes Zircon, and Zircon includes LK, which are configured by the build system. But in this way this feature of our OS is copied as well, as can be seen easily with the projects referenced in the sections Operating System and Exotic Operating System of the webpage Links to Software.]
Module [] A module is a role a component can play to participate in a story. Every component can be be used as a module, but typically a module is asked to show UI. Additionally, a module can have a module metadata file which describes the Module's data compatibility and semantic role.

• Module metadata format

[See once again the section Integrating Architecture of the webpage Overview for the phrase "OntoLi[][]x is build around a special abstraction of a layered system architecture with homogeneous, heterogeneous, synchronous, and also asynchronous modules.". Also recall that "[a]n agent is a role a component can play to execute in the background in the context of a session. An agent's life cycle is not tied to any story.", which suggests that a module is a specific type of agent.]
Namespace [] A namespace is the composite hierarchy of files, directories, sockets, services, and other named objects which are offered to components by their environment. [...] [See for example the webpage about the Virtual Object System (VOS), specifically its object model. Furthermore, we found on the webpage Fuchsia Namespace Spec the following information: "Unlike other operating systems, Fuchsia does not have a "root filesystem". [...] There is no global "root" namespace." Obviously, the Internet has no root, the basic property of our OS of (mostly) being kernel-less reflective/fractal/holonic implies the same, the graph-based Ontologic File System (OntoFS) component must not be tree-based and have a root, and the Feature-List #5 we have the listed our Structured Relational Petri net-based Object-oriented Model (SRPOM), which is an existential multi-rooted Directed Acyclic Graph (DAG). Therefore, we consider these system features as the next evidence that proves the causal link with our OS. But we see that Fuchsia has a component instance tree and {something else that together implies a root}?]
[...]
Ninja [] Ninja is the build system executing Fuchsia builds. It is a small build system with a strong emphasis on speed. Unlike other systems, Ninja files are not supposed to be manually written but should be generated by other systems, such as GN in Fuchsia.

• Manual
• Ninja rules in GN
• Fuchsia build overview

Outgoing directory [] A file system directory where a component may expose capabilities for others to use. [See the OntoCore (OC) and Ontologic File System (OntoFS) components once again.]
Paver [] A tool in Zircon that installs partition images to internal storage of a device.

• Guide for installing Fuchsia with paver.

Realm [] In components v1, realm is synonymous to environment. In components v2, a realm is a subtree of component instances in the component instance tree. It acts as a container for component instances and capabilities in the subtree.
Runner [] A component that provides a runtime environment for other components, e.g. the ELF runner, the Dart AOT runner, the Chromium web runner. Every component needs a runner in order to launch. Components express their dependency on a runner in the component's declaration. When the component framework starts a component, it first determines the capabilities that the component should receive, then asks the component's runner to launch the component. The runner is responsible for creating any necessary processes, loading executable code, initializing language runtimes, handing control to the component's entry points, and terminating the component when requested by the component framework. [...] [Somehow, we have the impression that we have here a Virtual Virtual Machine (VVM) like the one presented with the document titled "Virtual Virtual Machine (VVM)" and referenced in the section Exotic Operating System of the webpage Links to Software.]
Scenic [] The system compositor. Includes views, input, compositor, and GPU services. [See the OntoGraphics software component, which provides functionalities of scene graphs and compositors.]
Service [] A service is an implementation of a FIDL interface. Components can offer their creator a set of services, which the creator can either use directly or offer to other components. Services can also be obtained by interface name from a Namespace, which lets the component that created the namespace pick the implementation of the interface. Long-running services, such as Scenic, are typically obtained through a Namespace, which lets many clients connect to a common implementation.
Service capability [] A capability that permits communicating with a service over a channel using a specified FIDL protocol. The server end of the channel is held by the component instance that provides the capability. The client end of the channel is given to the component instance that uses the capability.

• Capability routing

Service capability is a components v2 concept.
Session [] An interactive session with one or more users. Has a session shell, which manages the UI for the session, and zero or more stories. A device might have multiple sessions, for example if users can interact with the device remotely or if the device has multiple terminals.
Session Shell [] The replaceable set of software functionality that works in conjunction with devices to create an environment in which people can interact with mods, agents and suggestions.
Storage capability [] A storage capability is a capability that allocates per-component isolated storage for a designated purpose within a filesystem directory. Multiple component instances may be given the same storage capability, but underlying directories that are isolated from each other will be allocated for each individual use. This is different from directory capabilities, where a specific filesystem directory is routed to a specific component instance. Isolation is achieved because Fuchsia does not support dotdot. There are three types of storage capabilities:

• data: a directory is added to the namespace of the component instance that uses the capability. Acts as a data directory.
• cache: same as data, but acts as a cache directory.
• meta: a directory is allocated to be used by component manager, where it will store metadata to enable features like persistent component collections.

Storage capability is a components v2 concept.

• Capability routing
• Storage capabilities

Story [] A user-facing logical container encapsulating human activity, satisfied by one or more related modules. Stories allow users to organize activities in ways they find natural, without developers having to imagine all those ways ahead of time. [Due to our Calibre/Caliber and Bridge from Natural Intelligence (NI) to Artificial Intelligence (AI) (see the second sketch), as well as other original and unique features of our OS, stories can also be described as user-related Ontologic Applications and Ontologic Services (OAOS). We consider this as another evidence that proves the causal link with our OS.]
Story Shell [] The system responsible for the visual presentation of a story. Includes the presenter component, plus structure and state information read from each story.
Virtual Dynamic Shared Object [] The Virtual Dynamic Shared Object (vDSO) is a Virtual Shared Library - it is provided by the Zircon kernel and does not appear in the filesystem or a package. It provides the Zircon System Call API/ABI to userspace processes in the form of an ELF library that's "always there." [...] [Do not confuse the vDSO concept with the Virtual Object System (VOS). We also have something that is always there and even more fundamental with the Zero Ontology or Null Ontology and fractal denoted by O#.]
[...]
Zircon [] Zircon is the microkernel and lowest level userspace components (driver runtime environment, core drivers, libc, etc) at the core of Fuchsia. In a traditional monolithic kernel, many of the userspace components of Zircon would be part of the kernel itself. [See the webpage Components of the website of our OS OL and once again our OntoCore (OC) software component. Also note that items are designated components to confuse the public in relation to our Ontologic System Components (OSC).]
[...]

Filesystem Architecture
[...] Filesystems are Services [] Unlike more common monolithic kernels, Fuchsia's filesystems live entirely within userspace. They are not linked nor loaded with the kernel; they are simply userspace processes which implement servers that can appear as filesystems. As a consequence, Fuchsia's filesystems themselves can be changed with ease -- modifications don't require recompiling the kernel. [...] Like other native servers on Fuchsia, the primary mode of interaction with a filesystem server is achieved using the handle primitive rather than system calls. The kernel has no knowledge about files, directories, or filesystems. [...] As a benefit of this interface, any resources accessible via a channel can make themselves appear like filesystems by implementing the expected protocols for files or directories. For example, "serviceFS "(discussed in more detail later in this document) allows for service discovery through a filesystem interface. [...] On Fuchsia, a namespace is a small filesystem which exists entirely within the client. [...] Filesystem objects (such as directories and files), services, devices, packages, and environments (visible by privileged processes) all are usable through handles, and may be composed arbitrarily within a child process. As a result, namespaces allows for customizable resource discovery within applications. The services that one process observes within "/svc" may or may not match what other processes see, and can be restricted or redirected according to application-launching policy. [...] Once a connection has been established, either to a file, directory, device, or service, subsequent operations are also transmitted using RPC messages. These messages are transmitted on one or more handles, using a wire format that the server validates and understands. [...] MinFS: A persistent filesystem [...] Blobfs: An immutable, integrity-verifying package storage filesystem [...] Other than two small prerequisites (file names which are deterministic, content addressable hashes of a file's Merkle Tree root, for integrity-verification) and forward knowledge of file size [...], Blobfs appears like a typical filesystem. [...] [First of all, we refer once again to our OntoFS software component, specifically to the section about FUSE. Furthermore, we recall that "[a] Handle is how a userspace process refers to a kernel object [and] a common example for a capability." Furthermore, we note that our OntoCore (OC) software component, which is based on our integration of microkernel-based, capability-based, kernel-less operating systems, and address-spaces-based operating systems, as well as distributed operating systems, high-performance operating systems and many other operating systems , specifically the capability-based microkernel L4 with the Kernel-Less Operating System (KLOS) and the Systems Programming using Address-spaces and Capabilities for Extensibility (SPACE) approach, has this functionality as well. Content-Addressable Storage (CAS) systems are mentioned in relation to for example Artificial Intelligence (AI) and Peer-to-Peer (P2P) computing, as well as our Ontologic Net (ON) and Ontologic Web (OW) infrastructure, which is a part of the Ontologic uniVerse (OntoVerse or OV), in for example the Ontonics, OntoLix and OntoLinux Further steps of the 2nd of May 2016 and the note OS too large to steal of the 15th of May 2016), and are discussed in relation to the Merkle tree data structure in the OntoLix and OntoLinux Further steps of the 26th of January 2018 and 1st of February 2018, the OntoLix and OntoLinux Website update of the 1st of February 2018, and also the related sections of the Investigations::Multimedia of the 7th of May 2018, because it can be misused to realize a Content-Addressable File System (CAFS), as done with Blobfs by taking a sufficient long part of the Merkle tree of a single file, which is the deterministic content addressable hash of a said file's Merkle tree root, and not a whole package as the file name of said single file, which is how a CAFS works, though a CAFS can work on the level of file blocks as well. Moreover, single files are put into a package which is also a file with such a file name, which is also how a CAFS works, though a CAFS can work on the level of single files as well. That integrity-verifying file system concept based on a Merkle tree was called before fs-verity and mentioned the first time in the OntoLix and OntoLinux Website update of the 1st of February 2018 after its presentation on the mailing list of the Linux kernel and once again in the Preliminary Investigation of the 7th of September 2018 (see also the note FOSHS reached peak long ago of the 17th of December 2018) for example. Now, it should be easy to see why we were also reminded about the Peer-to-Peer (P2P) Virtual Machine (VM) Askemos based on our Evolutionary operating system (Evoos) described in The Proposal. Furthermore, our OntoFS features a plug-in system and can be implemented in at least two versions with one version being a Virtual File System (VFS) based on the Filesystem in USErspace (FUSE). The partition manager was already mentioned before by referring to the Feature-List #1. Moreover, semantic technologies include Service-Oriented Computing of the second generation (SOC 2.0), which is based on the integration of Service-Oriented Architecture (SOA) with Autonomic Computing (AC) and Semantic (World Wide) Web (SWWW), and comprises service discovery. In addition, the Virtual Object System (VOS) also mentions the different views on system items. Last but not least, our OSA integrates all in one. We also have here the basic property of our OS of (mostly) being validated and verified, for example with a Blobfs server, which works with a validated wire format (for RPC messages for IPC) on a verified file format. All these single system features already constitute the next evidences that show a causal link with our OS, and the integration proves the infringement of our copyright and other rights without the slightest doubt.]

Ledger
[...] Ledger is a distributed storage system for Fuchsia. Each application (or more precisely, each [component]) running on behalf of a particular user has a separate data store provided and managed by Ledger, and vended to a client application by Fuchsia framework through its component context. [...] Each data store is transparently synchronized across devices of its user through a cloud provider. [...] Ledger should be used by software storing data that is scoped to a single user, and that needs to be synced on all of the users's devices. [...] Ledger is available to any software running under the Modular framework. [First of all, we note the confusion with the term distributed ledger. Furthermore, we already said in a comment made to a quote above that this functionality and the related system part based on cloud computing is described as "Personal World Wide Web-based infrastructure, network, and virtual drive, that supports the user centric migration 'Max-Mig', synchronization 'Max-Sync' of applications and data, and communication 'Max-Com'" and included in the Feature-List #2, and also referred to the section Network Technology of the webpage L2SW for more works based on Peer-to-Peer (P2P) and cloud computing.]

Architecture
This document explains the internal architecture of Ledger.
[...]
Ledger stores data in key-value stores called pages. A page changes in atomic commits, each commit adding, removing or modifying one or more entries in the key-value store.
The commit history of each page forms a [Direct Acyclic Graph (]DAG[)] in which each commit has either no parents (initial commit), 1 parent (regular commit) or 2 parents (merge commit).

Life of a Put
This document explains how Ledger works by following the mechanics of a single Put operation. [...] Journals [] All changes are first written in a Journal before being committed. This includes Put, Delete or Clear operations. Journals can be used to store transactions in progress [See the OntoBase and OntoFS software components, which includes the functionality of a journaling data store. Also, one might ask herself or himself the following question: If we utilize the journal together with the immutable, integrity-verifying package storage filesystem Blobfs we get what? Exactly, a blockchain-based ledger and even a distributed ledger, as already criticized in the {OntoLinux Further steps of the ...?}, and eventually our OntoLedger software component. ...]. Synchronization [] Cloud sync [] P2P sync [See the comments made before in relation to our synchronization 'Max-Sync', and integration of works based on Peer-to-Peer (P2P) and cloud computing once again.]

Fuchsia is not Linux
A modular, capability-based operating system
[...]
Zircon Kernel [] Zircon is the microkernel underlying the rest of Fuchsia. Zircon also provides core drivers and Fuchsia's libc implementation. [...]
Zircon Core [][...]
Framework

• Overview [Modular]
• Core Libraries
• Application model
  • Interface definition language (FIDL)
  • Services
  • Environments
• Boot sequence
• Device, user, and story runners
• Components
• Namespaces
• Sandboxing
• Story
• Module
• Agent

Storage

• Block devices
• File systems
• Directory hierarchy
• Ledger
• Document store
• Application cache

[Storage copies at least parts of the OntoBase, OntoFS, and OntoLedger components.]
Networking

• Ethernet
• Wireless
• Bluetooth
• Telephony
• Sockets
• HTTP

Graphics

• UI Overview
• Magma (vulkan driver)
• Escher (physically-based renderer)
• Scenic (compositor)
• Input manager
• Flutter (UI toolkit)

Components

• Component framework

Intelligence

• Context
• Agent Framework
• Suggestions [or Recommendations]

User interface

• Device, user, and story shells
• Stories and modules

Backwards compatibility

• POSIX lite (what subset of POSIX we support and why)
• Web runtime

Update and recovery

• Verified boot
• Updater

Zircon
Zircon is the core platform that powers the Fuchsia OS. [...]
Zircon syscalls are generally non-blocking. [...]

Zircon Kernel Concepts
[...]
Userspace code interacts with kernel objects via system calls, and almost exclusively via Handles. In userspace, a Handle is represented as 32bit integer (type zx_handle_t). When syscalls are executed, the kernel checks that Handle parameters refer to an actual handle that exists within the calling process's handle table. The kernel further checks that the Handle is of the correct type (passing a Thread Handle to a syscall requiring an event handle will result in an error), and that the Handle has the required Rights for the requested operation.
[...]
The actions which may be taken on a Handle or the Object it refers to are governed by the Rights associated with that Handle. Two Handles that refer to the same Object may have different Rights.
[...]
Both Sockets and Channels are IPC Objects which are bi-directional and two-ended. Creating a Socket or a Channel will return two Handles, one referring to each endpoint of the Object.
Sockets are stream-oriented and data may be written into or read out of them in units of one or more bytes. [...]
[...]
Futexes are kernel primitives used with userspace atomic operations to implement efficient synchronization primitives - for example, Mutexes which only need to make a syscall in the contended case. Usually they are only of interest to implementers of standard libraries.

Zircon Kernel Concepts
[...]
Zircon is a object-based kernel. User mode code almost exclusively interacts with OS resources via object handles. A handle can be thought of as an active session with a specific OS subsystem scoped to a particular resource. [...]

Zircon Scheduling
[...]
Our scheduler is an evolution of LK's scheduler. [...] [Compare with the document titled "esep - Evolution Scheduling and Evolving Processes" and listed in the section Operating System of the webpage Links to Software.]
[...]
Realtime threads (marked with THREAD_FLAG_REAL_TIME) are allowed to run without preemption and will run until they block, yield, or manually reschedule.

Zircon Fair Scheduler
[...]
Handles are kernel constructs that allows user-mode programs to reference a kernel object. A handle can be thought as a session or connection to a particular kernel object.
[...]
The new scheduler includes detailed tracing instrumentation to analyze the behavior of the scheduler and its interaction with and impact on the competing workloads in the system. [...]

Zircon Handles
[...]
The 'rights' specify what operations on the kernel object are allowed. It is possible for a single process to have two different handles to the same kernel object with different rights.
[...]
If a handle is valid, the kernel object it points to is guaranteed to be valid. [...]

Runtime Lock Validation in Zircon
Introduction [] Zircon integrates a runtime lock validator to diagnose inconsistent lock ordering that could lead to deadlocks. This document discusses how the validator is integrated, how to enable and tune the validator at build time, and what output the validator produces. The theory of operation for the validator itself can be found in the design document. [See once again the sections Basic Properties, specifially the property of (mostly) being validated and verified, and Integrating Architecture of the webpage Overview.]
[...]
The lock validator detects and reports two broad classes of violations:
1. Pair-wise violations reported at the point of acquisition.
2. Multi-lock cycles reported asynchronously by a dedicated loop detection thread.
[...]

Runtime Lock Validation in Zircon and Fuchsia
Introduction [] Lock validation is a technique for checking the consistency of locking behavior in a program to find potential deadlock hazards. This document discusses relevant aspects of the static and dynamic approaches to lock validation and presents the foundation for the runtime lock validation library available in Zircon and Fuchsia. [...] [See the sections Formal Verification and Software Development Tool of the webpage L2SW.]

Zircon System Calls
[...]
Hypervisor guests [See the webpage Components, the section Exotic Operating System of the webpage L2SW, and the OntoCore component once again.]
[...]

zxcrypt
[...]
zxcrypt is a block device filter driver that transparently encrypts data being written to and decrypts being read from data a block device. [See the OntoFS component once again, specifically the point "[..] by the plug-in mechanism cryptographic algorithms can be added to the file system and integrated into security related operations".]
[...]

Static Analysis in Zircon
[...]
Steps to enable ZirconHandleChecker [] [...] all Zircon related checkers are still under review by upstream LLVM community:

[See the sections Formal Verification and Software Development Tool of the webpage L2SW once again.]

Zircon and LK
Zircon was born as a branch of LK and even now many inner constructs are based on LK while the layers above are new. For example, Zircon has the concept of a process but LK does not. However, a Zircon process is made of LK-level constructs such as LK's thread_t.
LK is a Kernel designed for small systems typically used in embedded applications. [...]
On the other hand, Zircon targets modern phones and modern personal computers with fast processors, non-trivial amounts of ram with arbitrary peripherals doing open ended computation.
More specifically, some the visible differences are:

Over time, even the low level constructs have changed to accommodate the new requirements and to better fit the rest of the system.

[...]"

From an online encyclopedia about the Google Fuchsia operating system: "Fuchsia is an open source capability-based operating system currently being developed by Google. It first became known to the public when the project appeared on a self hosted form of git in August 2016 without any official announcement. [...] In contrast to prior Google-developed operating systems such as Chrome OS and Android, which are based on the Linux kernel, Fuchsia is based on a new microkernel called Zircon.
[...]
On July 1, 2019 Google announced the homepage of the project [...], which provides source code and documentation for the newly announced operating system.
[...] While no official announcement was made, inspection of the code suggested its capability to run on universal [many different] devices, including "dash infotainment systems for cars, to embedded devices like traffic lights and digital watches, all the way up to smartphones, tablets and PCs". The code differs from Android and Chrome OS due to its being based on the Zircon kernel (formerly called Magenta)[3 [... (12 September 2017). "[zx] Magenta -> Zircon".]] rather than on the Linux kernel.[...]
[...]
Fuchsia's user interface and apps are written with Flutter, a software development kit allowing cross-platform development abilities for Fuchsia, Android and iOS. Flutter produces apps based on Dart, offering apps with high performance [...].
[...]

Zircon
Fuchsia is based on a new microkernel called Zircon. Zircon is derived from Little Kernel,[...] a small operating system intended for embedded systems. "Little Kernel" was developed by Travis Geiselbrecht, a creator of the NewOS kernel used by Haiku. [Haiku is a free and open-source operating system compatible with the now discontinued BeOS. Its development began in 2001, and the operating system became self-hosting in 2008. BeOS is also the operating system that had an advanced file system. Howsoever, we have proven in the comments made to the quotes above that Zircon is a partial clone of our OntoCore (OC) software component. ...] The company describes the evolution of Zircon as
"Zircon was previously known as Magenta and it was designed to scale to any application from embedded RTOS (Real-Time Operating Systems) to mobile and desktop devices of all kinds. As a result, there has been much speculation that Fuchsia will be the natural successor to Android and Chrome OS, combining capabilities of both with backwards compatibility to run legacy applications built on either. In short, this thing is designed to run on anything from 32-bit or 64-bit ARM cores to 64-bit X86 processors and it has a potential to be rather disruptive."[27 ["Google's Fuchsia OS Developer Site Debuts ([A very well known fake news provider])."]]
The software documentation of the Zircon microkernel outlines the technical specifications. Zircon is the basis for the Fuchsia OS. Zircon comprises a microkernel (source in kernel/...) and userspace services, drivers, and libraries (source in system/...) as part of the boot process as well as talk to hardware [(input/output (I/O) but not Language Processing (LP))]. Zircon provides more than 100 syscalls. Zircon syscalls are generally non-blocking with the wait_one, wait_many port_wait and thread sleep being the notable exceptions."

From an online encyclopedia about the Dart programming language: "[Short description box:] Dart [] Multi-paradigm: scripting, object-oriented (class-based), imperative, reflective, functional, [typed, concurrent], garbage-collected
Dart is a client-optimized programming language for fast apps on multiple platforms. It is developed by Google and is used to build mobile, desktop, backend and web applications.[...] [See the OntoFS component once again, specifically the point "An interpreter or virtual machine of a programming language [...] also simply defines every desktop application written in any programming language as a web enabled (mini) app(lication);".]
[...]
It supports interfaces, mixins, abstract classes, reified generics, static typing, and a sound type system.[...]
[...]
In August 2018, Dart 2.0 was released, with language changes including a sound type system.[...]
[...]
[...] [16 ["Why?", Dart lang (FAQ), "We designed Dart to be easy to write development tools for, well-suited to modern app development, and capable of high-performance implementations."]
[...]
To achieve concurrency, Dart uses isolates, which are independent workers that do not share memory, but instead use message passing. This is similar to Erlang processes (see also Actor model). Every Dart program uses at least one isolate, which is the main isolate. [See the section Exotic Operating System of the webpage Links to Software, specifcally the TUNES operating system Language project, and the OntoCore (OC), specifically the inclusion of the Concurrent Logic (CL) and Concurrent Constraint (CC) programming paradigms, and the Software-Isolated Processes (SIPs; Isolation-Based Processes (IBPs)). See also the Further steps of the 27th of March 2019, where we already showed the same attempt with the so-called Borg system. As can be seen easily, Alphabet (Google) together with its collaborators is continuing that "attempt to steal the part of our works of art titled Ontologic System (OS), that is based on our integration of the basic properties of the [points listed in this Further steps]" by stealing these listed points with Zircon and Fuchsia. These also proves once again our findings in the case of Borg and Istio. But there is no legal loophole at all, but only a grand illusion and a huge fraud.]
[...]
Dart is a very asynchronous language. With this, it uses isolates for concurrency. Since these are workers which pass messages, it needs a way to serialize a message. [We would like to recall our exception-less communication mechanism, including exception-less system calls, which are asynchronous system calls without context switch, and asynchronous I/O without context switch.] ]
[...]
Google has introduced Flutter for native mobile app development on both Android and iOS.[...] Flutter is a mobile app [Software Development Kit (]SDK[)], complete with framework, widgets, and tools, that gives developers a way to build and deploy mobile apps, written in Dart. Flutter works with [a Mobile Backend as a Service (MBaaS) or Backend as a Service (BaaS) also owned by Google] and other mobile app SDKs [...].
[...]
Dart makes use of isolates as a concurrency and security unit when structuring applications.[...] The Isolate concept builds upon the Actor model [...]. [See the OC once again and remember that the capability-based property is for providing security.]
The Mirror API for performing controlled and secure reflection was first proposed in a paper[40 [... (2004). "Mirrors: design principles for meta-level facilities of object-oriented programming languages"] [...] and originally implemented in [the object-oriented, prototype-based programming language] Self. [But neither Self nor Mirror are concurrent, and none of them were utilized as part of such a (concurrent) programming language based on the Actor model or such an operating system. See the section Basic Properties of the webpage Overview, the section Exotic Operating System of the webpage Links to Software, and the OC once again. See also the {what?}.]"

From an online encyclopedia about non-blocking algorithm: "In computer science, an algorithm is called non-blocking if failure or suspension of any thread cannot cause failure or suspension of another thread;[...] for some operations, these algorithms provide a useful alternative to traditional blocking implementations. A non-blocking algorithm is lock-free if there is guaranteed system-wide progress, and wait-free if there is also guaranteed per-thread progress."]

[Wikipedia about Compare-and-swap: "In computer science, compare-and-swap (CAS) is an atomic instruction used in multithreading to achieve synchronization. It compares the contents of a memory location with a given value and, only if they are the same, modifies the contents of that memory location to a new given value. This is done as a single atomic operation. The atomicity guarantees that the new value is calculated based on up-to-date information; if the value had been updated by another thread in the meantime, the write would fail. The result of the operation must indicate whether it performed the substitution; this can be done either with a simple boolean response (this variant is often called compare-and-set), or by returning the value read from the memory location (not the value written to it).
[...]
This operation is used to implement synchronization primitives [or higher-level locking abstractions] like semaphores and mutexes,[1 [... (2008). Semaphores in Plan 9. 3rd International Workshop on Plan 9.]] as well as more sophisticated lock-free and wait-free algorithms. Maurice Herlihy (1991) proved that CAS can implement more of these algorithms than atomic read, write, or fetch-and-add, and assuming a fairly large [[citation or] clarification needed] amount of memory, that it can implement all of them.[2 [... (January 1991). "Wait-free synchronization".]] CAS is equivalent to load-link/store-conditional, in the sense that a constant number of invocations of either primitive can be used to implement the other one in a wait-free manner.[3 [..."Universal constructions for multi-object operations". In Proc. 14th Annual ACM Symposium on Principles of Distributed Computing, pages 184-193, 1995.]]
[...]

ABA problem
Some CAS-based algorithms are affected by and must handle the problem of a false positive match, or the ABA problem. [...]
A more complicated but more effective solution is to implement safe memory reclamation (SMR). This is in effect lock-free garbage collection. The advantage of using SMR is the assurance a given pointer will exist only once at any one time in the data structure, thus the ABA problem is completely solved. (Without SMR, something like a freelist will be in use, to ensure that all data elements can be accessed safely (no memory access violations) even when they are no longer present in the data structure. With SMR, only elements actually currently in the data structure will be accessed).

Costs and benefits
CAS, and other atomic instructions, are sometimes thought to be unnecessary in uniprocessor systems, because the atomicity of any sequence of instructions can be achieved by disabling interrupts while executing it. However, disabling interrupts has numerous downsides. For example, code that is allowed to do so must be trusted not to be malicious and monopolize the CPU, as well as to be correct and not accidentally hang the machine in an infinite loop or page fault. Further, disabling interrupts is often deemed too expensive to be practical. Thus, even programs only intended to run on uniprocessor machines will benefit from atomic instructions, as in the case of Linux's futexes.
In multiprocessor systems, it is usually impossible to disable interrupts on all processors at the same time. Even if it were possible, two or more processors could be attempting to access the same semaphore's memory at the same time, and thus atomicity would not be achieved. The compare-and-swap instruction allows any processor to atomically test and modify a memory location, preventing such multiple-processor collisions. [If a system is validated and verified, then there is no additional problem by disabling interrupts at all, as is possible with our Ontologic System (OS). We also do not see why it is too expensive at least in the case of uniprocessor systems.]

Implementations
Compare-and-swap (and compare-and-swap-double) has been an integral part of the IBM 370 (and all successor) architectures since 1970. The operating systems that run on these architectures make extensive use of this instruction to facilitate process (i.e., system and user tasks) and processor (i.e., central processors) parallelism while eliminating, to the greatest degree possible, the "disabled spin locks" which had been employed in earlier IBM operating systems. Similarly, the use of test-and-set was also eliminated. In these operating systems, new units of work may be instantiated "globally", into the global service priority list, or "locally", into the local service priority list, by the execution of a single compare-and-swap instruction. This substantially improved the responsiveness of these operating systems.
In the x86 (since 80486) and Itanium architectures this is implemented as the compare and exchange (CMPXCHG) instruction (on a multiprocessor the LOCK prefix must be used).
As of 2013, most multiprocessor architectures support CAS in hardware, and the compare-and-swap operation is the most popular synchronization primitive for implementing both lock-based and non-blocking concurrent data structures.[4 [... (2013). "Lightweight Contention Management for Efficient Compare-and-Swap Operations".]]
The atomic counter and atomic bitmask operations in the Linux kernel typically use a compare-and-swap instruction in their implementation. The SPARC-V8 and PA-RISC architectures are two of the very few recent architectures that do not support CAS in hardware; the Linux port to these architectures uses a spinlock.[7 ["Semantics and Behavior of Atomic and Bitmask Operations, for Linux port maintainers".]]
[...]

See also

From an online encyclopedia about futex operating system kernel system call: "In computing, a futex (short for "fast userspace mutex") is a kernel system call that programmers can use to implement basic locking, or as a building block for higher-level locking abstractions such as semaphores and POSIX mutexes or condition variables.
A futex consists of a kernelspace wait queue that is attached to an atomic integer in userspace. Multiple processes or threads operate on the integer entirely in userspace (using atomic operations to avoid interfering with one another), and only resort to relatively expensive system calls to request operations on the wait queue (for example to wake up waiting processes, or to put the current process on the wait queue). A properly programmed futex-based lock will not use system calls except when the lock is contended; since most operations do not require arbitration between processes, this will not happen in most cases. [At first we note that a citation or the usual note "clarification needed" is missing here. We also note that in the article about the Compare-and-swap atomic instruction, which we quoted before, interrupts are proposed to exploit and achieve atomicity and throwing an interrupt is still a system call. Somehow, we have the impression that the public is mislead in relation to our kernel-less asynchronous system call mechanism and modules for operating systems and distributed systems of our integration of the Kernel-Less Operating System (KLOS) and the Systems Programming using Address-spaces and Capabilities for Extensibility (SPACE) approach, and hence of our Ontologic System (OS).]

History
Futex were implemented in 1995 On BeOS (also known as benaphores). (https://www.haiku-os.org/legacy-docs/benewsletter/Issue1-26.html)
[...] Futexes appeared for the first time in version 2.5.7 of the Linux kernel development series; the semantics stabilized as of version 2.5.40, and futexes have been part of the Linux kernel mainline since the December 2003 release of 2.6.x stable kernel series.
In 2002 discussions took place on a proposal to make futexes accessible via the file system by creating a special node in /dev or /proc. However, Linus Torvalds strongly opposed this idea and rejected any related patches.[1 [Torvalds, Linus. "Futex Asynchronous Interface".]]
[...]
Futexes have been implemented in OpenBSD since 2016.[...]
The futex mechanism is one of the core concepts of the Zircon kernel[6 ["Zircon Kernel Concepts". fuchsia.googlesource.com.]] in Google's Fuchsia operating system since at least April 2018.[7 ["zx_futex_wait".]]

See also

[...]

External links

Verdict: Convicted.
Short summary: Zircon (formerly called Magenta) and Fuchsia are infringements of the copyright and other rights of C.S. and our corporation, obviously and definitely. We find it even quite bold what Google is trying here with its

Zircon and Fuchsia together are the continuation of the attempt to steal a part of OS with Borg and Istio by integrating them in a capability-based distributed operating system with a distributed Content-Addressable Storage (CAS) system. This also proves once again our findings in the case of the Borg and Istio fraud (see the last section of the Further steps of the 27th of March 2019) and provides another kind of evidence that shows a causal link with our OS and related works.

In this relation, we also noticed that the essential elements have been carefully hidden. For example, Zricon/Fuchsia is not implemented in the concurrent (actor-based), reflective programming language Dart, but has a Dart Virtual Machine (DVM) and even a Dart Virtual Virtual Machine (DVVM), which is utilized for the User Interface (UI) framework Flutter, which again is utilized for the "story shell[, which again is t]he system responsible for the visual presentation of a story, which again is a basic part of Zricon/Fuchsia. But at this point all basic properties of these separate basic elements come together as one system, which is a copy of the related par.
Similarly, we also have a distributed operating system, namespace with no root {repeat details}, an integrity-verifying file system utilized as a Content-Addressable Storage (CAS) system, a distributed storage system called ledger for each user, online provider or service(?!), an agent system in relation to (Artificial) Intelligence (AI) and a recommender system, and so on, which all are separate sub systems but integrated as Zircon/Fuchsia.
Somehow, this reminds us of the

(see OntoLix and OntoLinux Further steps or Clarification of the 18th of April 2018 and the publication referenced therein, the Clarification of the 5th of April 2018, and the Clarification of the 11th of May 2018).

In this relation of Fault-Tolerant, Reliable, and Trustworthy Distributed Systems (FTRTDSs), we also quote the Investigations::Multimedia of the 20th of October 2017: "So where is the difference between a ledger and a safe, secure, and reliable operating system with a dedicated log-based filesystem or/and a transactional database management system that is Atomic, Consistent, Isolated and Durable (ACID) for example? See the OntoFS software component for example. Furthermore, "[a] number of formalisms for modeling and understanding concurrent systems have been developed, including [...] Petri Nets", which can be found in the section Formal Modeling of the webpage Links to Software, and in the section Formal Verification of the same webpage the model checker Boom is listed, and the combination of the property of being kernel-less reflective and the Object-Oriented (OO 1) paradigm results in the language RbCl, which is "A Reflective Object-Oriented Concurrent Language without Run-time Kernel" listed in the section Exotic Operating System. In addition, in the Feature-List #5 we have the listed our Structured Relational Petri net-based Object-oriented Model (SRPOM), which is an existential multi-rooted Directed Acyclic Graph (DAG)."

This shows, that Google has taken our explanations related to operating system and FTRTDSs publicated in the years 2016 to 2018 and our other publications for the implementation of Zircon/Fuchsia without asking for allowance and without referencing the true origin.

For sure, distributed systems, capability-based operating systems, fault-tolerant systems, microkernels, kernel-less operating systems, reflective systems, VMs and VVMs, as well as other concepts, features, functionalities, systems, and so on are prior art publicated and implemented before the publication of our OS. But studying, collecting, bringing together, combining, and integrating all these works with a single system architecture or system implementation was done by C.S. with the work of art titled Ontologic System with its Ontologic System Components (OSC), Ontologic Applications and Ontologic Services (OAOS), and Ontologic System Architecture (OSA), which "integrates all in one". Yes, we said this killer phrase deliberately and it has to be taken in exactly this sense literally by all other entities to avoid all those infringements and frauds, that we are investigating and documenting since the publication of our OS.

Considerable amounts of our OS were taken as a blueprint in a top-bottom approach and presented in an edited variant.
Fuchsia was even done in a way that makes it compatible and seamless with the matters already taken from our OS before in other fields, such as for example

{see above for the relations to Askemos, Borg, and Istio}

Also interesting in relation to the many Bingos:
Human activities are also the basis for Google's newest social networking platform called Shoelace connects

Is there anybody who really still wonders?

10.August.2019

02:46, 15:03, and 17:05 UTC+2
SOPR #216

*** Work in progress - maybe some better wording ***
We continued the discussion about the following topics:

Legal matter
We have revised the agreement by adding the following provision:
In the case of an infringement of the Articles of Association (AoA) and the Terms of Service (ToS) of our Society for Ontological Performance and Reproduction (SOPR) that threatens the integrity of our SOPR, the SOPR is allowed to

This provision might end at the 31st of December 2039.
Examples for a threat on the integrity of our SOPR are

Yes, we do look at large companies of the Information and Communication Technology (ICT) and automotive industrial sectors.

License Model (LM)
The latest unwanted activities of (potential and designated) members of our SOPR require further considerations about the License Model (LM). Some considerations were already discussed in the past issues, such as for example

To prevent price dumping by for example a

• Grid, Cloud, and Edge Computing (GCEC) system and platform,
• electronic commerce system,
• marketplace for everything system,
• application store, and

• application,
• device, and
• vehicle,

and

• Everything as a Service (EaaS),
• Mobility as a Service (MaaS), and
• Transport as a Service (TaaS),

on our costs we are considering other bases for fees and shares. For example, taking the average cost charged by a limitied amount of leading providers or manufacturers in a related field, as already done for estimating a revenue in the case that an application or service is provided for free or performed as part of a research project, will be appropriate.

Diverses
Yesterday, we observed more illegal activities and the next act of some kind of a rather abstruse revolt of various entities against our SOPR.
Before we could suggest an alternative for an untrusted social media platform provider for the operation of our social and societal platform, that alternative social media platform provider copied an essential part of our OS and became untrusted as well.
Now we are wondering if another alternative platform provider already conducted the next illegal activity as well.

21:28 UTC+2
Alphabet (Google) burned out?

The Ontologic System variant Zircon/Fuchsia will not succeed, no government will accept this, like the digital currency Facecoin, though the potential of Zircon/Fuchsia under the control of Google is at least as dangerous or even more dangerous for freedom of choice, invention, and competition pro bono publico==for the public good, and eventually democracy than a larger social media platform. But Google already owns a large social media platform as well and has already integrated Zircon/Fuchsia with its new social media platform.
The related laws give Google no allowance to license a reproduction or a performance of our works of art in whole or in part in a way, that is not authorized by our SOPR.
There will be no repetition of the Google Search, Android, and many other frauds, because the actual situation is a totally different than the past situations.
We have the impression that Google is now the one standing without any support and nothing to offer. Any support by other entities will only prove the complot even more easier.

We are running out of ideas and options how to handle the company and getting more and more the feeling that our journey will go on without it. We highly recommend to delete (the open source variant of) Zircon/Fuchsia immediately as a first step to get back into the game.

We are not running out of alternatives. There is interest by the company Amazon and maybe by the company Apple and also the company IBM after Google's turn away from Linux, and when the management of the company Facebook has gained more experience then it might understand the opportunities as well.

11.August.2019
Comment of the Day
"Our cyber sovereignty and integrity are sacred and inviolable at all times."

19:57 UTC+2
SOPR #217

*** Work in progress - better wording ***
In this issue we can give some few informations about some more topics than usual, including:

Infrastructure
Technologies, goods, and services required for the

of the infrastructure of our SOPR, specifically the

have to be distributed under the eligible and qualified SOPR members.

We are very sure that our brand new technologies, goods, and services for

are very interesting for everybody as well.
By the way: We are not sure if these version numbers or only the version number 2.0 are correct. But somehow the version numbers 4.0 and 5.0 fit better with the field of Industry 4.0 and 5.0, and also sound more advanced and progressive. :D

Industrial platform
Competitors do not have to collaborate and integrate with each other, because the SOPR with its infrastructure and actvities is here to help, support, and manage. But we would like to recommend to begin at least with the related preparations.

Gaming platform
As with Multimodal User Interfaces (MUIs),

are coming as part of our Ontologic Net (ON), Ontologic Web (OW), and Ontologic uniVerse (OV).
Competitors do not have to collaborate and integrate with each other, because the SOPR with its infrastructure and actvities is here to help, support, and manage. But we would like to recommend to begin at least with the related preparations.

Other projects
Technologies, goods, and services required for the

of the

that have to be distributed under the eligible and qualified SOPR members.

15:09, 18:xy, and 35:5z UTC+2
Alphabet (Google) Zircon/Fuchsia case developing

In fact, the case of the illegal Ontologic System variant Zircon/Fuchsia of the subsidiary Alphabet→Google is not about a nice act of an open source development for the

but the total opposite. As usual, Alphabet→Google once again

to

Therefore, it has to be understood by the worldwide community, including the open source community taken for a ride by the company Google once again (specifically on the basis of everything related to the Linux kernel, like Android), that Google's latest gatecrash was not only another attack on the moral integrity of C.S. and the economical integrity of our corporation, but a frontal attack on the foundational integrity of our SOPR and all societies worldwide.

Indeed, the situation created by Google with Zircon/Fuchsia could be called a deadlock, blackmailing, or however the situation should be called, because we cannot proceed with our SOPR and the agreement until the legal matter is solved with Google, which affects the

But a closer look shows that we have several options to brake up this deadlock and solve the sitiuation.
Yes, we can for example

As longer we think about such options as more those activities beyond all laws become ridiculous and incomprehensible.

We also would like to explain the problems with

in more details.

Digital currencies, like for example Facecoin and such alike, were not prohibited by the AoA and the ToS of our SOPR at the time the company Facebook and its business partners presented it together with a payment system. But Facebook has also introduced a part of our Ontologic Financial System (OFinS) and our Ontologic Bank (OntoBank), and this even in a way that

While the large distribution of such a social media digital currency and widespread use of such a payment system is a little annoying in respect with the OntoCoin and OntoTaler, honestly, and was acceptable, indeed, the way it is done is prohibited.

Software for the operation of data centers, Grid, Cloud, and Edge Computing Systems (GCECS), including service meshing, like for example Istio, and such alike are

Furthermore, Istio was released by the companies Alphabet→Google and IBM in July 2016 but the 1.0 version was released after

Moreover, our investigations revealed, that

Another blatant act of ignorance, provocation, and unfair business practice, and the first act after our offer to license the reproduction and performance of our works of art.

Google Assistant activated with no wake word is indeed plausible form the point of view of user comfort and other reasons, as discussed in the issue SOPR #211 of the 21st of July 2019. But our SOPR has not allowed to use a proprietary voice-based assistant without wake word activation to

Google ignored this regulation as well.

Moreover, our investigations revealed, that

Another blatant act of ignorance, provocation, and unfair business practice, and the second act after our offer to license the reproduction and performance of our works of art.

Zircon/Fuchsia and such alike are not prohibited by the AoA and the ToS of our SOPR. But it was developed further and licensed under a Free and Open Source Software (FOSS) license very well knowing that it will not be authorized by our SOPR.
Furthermore, Google did it exactly in this way and at this time to disturb the goals and even threaten the integrity of our SOPR, and also to continue with blackmailing C.S. to get the whole control over our works of art.
Furthermore, it was done to steal our momentum once again, which would demand a second agreement, as discussed in the issue SOPR #208 of the 16th of July 2019
Furthermore, companies like Microsoft, IBM, Google, and other members of the Linux Foundation have already tried before to steal an essential part of our work of art titled Ontologic System and created by C.S. with blockchain-based technologies, distributed ledgers, and so on. Zircon/Fuchsia and similar operating systems respectively systems based on the operating system functionality and other functionalities of our Ontologic System Components (OSC) are now the next attempt at least of Google and Huawei, but we guess there are agreements with other companies like done in the past.
Another blatant act of ignorance, provocation, and unfair business practice, and the third act after our offer to license the reproduction and performance of our works of art.

What Alphabet (Google) and others have not known until recently is that we decided to not look for a plausible explanation anymore when the third act would happen but trigger the measures, that were discussed multiple times in the past.
We make no more experiments and we make no further concessions.

Mildly said, we are really disappointed once again about that permanent, cat-and-mouse game, blockade, sabotage, cheating, blackmailing, immoral mentality and conduct, and serious criminal action of Alphabet (Google) alone and together with other entities, and the rest of the worldwide societies should really feel in the same way.
We are working on that matter and our solution. But if this should be the norm, then there is no basis for an agreement but demand the break-up of companies.

And for all those fellows under us, who still have a problem with understanding the situation, we make the consequences explicit:
Utilzing

that

will not lead to

given by our SOPR.

12.August.2019

18:36 and 19:25 UTC+2
SOPR #218

We make a quick stop at two already well known topics:

Revision of AoA and ToS
Already in the year 2017 and since some months again, we are asking us if we can risk at all to give large companies the allowance to reproduce and perform our personal, original and unique, iconic works of art titled Ontologic System and Ontoscope, and created by C.S..
Eventually, three reasons were pivotal for our very generous, liberal, and honest offer to give this allowance to these companies at all:

But we already mentioned in the past that some companies have not changed their strategies and attitudes, and their latest frontal attacks on the

were not confidence or trust building at all, obviously, so that our willingness to take this risk has decreased even more.

To react appropriately and reasonably on those frontal attacks on the various integrities we are already considering to extend the Articles of Association (AoA) and the Terms of Service (ToS) of our SOPR once again with the following regulation:
If a

is licensed under a Free and Open Source Hardware and Software (FOSHS) license, then triple fees are due, that will be divided as follows:

Furthermore, either

• removes or
• reimplements said FOSHS as a HardWare (HW) or a SoftWare (SW), and licenses said HW or SW under a license authorized by our SOPR,

and bears the costs, or

• removes or
• reimplements said FOSHS as a HW or SW, and licenses said HW or SW under the SOPR EULA,

and pays the costs with the two parts of the triple fees deposited on the escrow account.
After said FOSHS has been removed or reimplemented the total or residual of the two thirds of the triple fees will be given back to the related licensee.

An implication of this regulation related to FOSHS is that we will not bear the costs for its removal or reimplementation.
If an arbitrary FOSHS has to be reimplemented for the benefit of the members of our SOPR, then we will bear the costs were reasonable, as said before.

Further steps
We are also working on the filing of a

against at least one large company due to a whole portfolio of criminal offences and infringements of rights of C.S., including everything related to the attacks on C.S. as an individual, such as for example the decade-long, permanent

• identity,
• personality, and
• such alike,

to seek a cease and desist order worldwide and request all the other demands announced some time ago, because it has become obvious already, that some large companies will only sign our agreement, if at all, to continue with infringing, blocking, sabotaging, cheating, blackmailing, and conducting all other immoral and illegal activities possible.

14.August.2019

17:52 and 18:00 UTC+2
SOPR #219

*** Work in progress ***
We have to share some significant informations in relation to the following topics:

Exclusion of Alphabet
Thanks to the brain crack of the company Alphabet (Google) and most potentially a company from the P.R.China and their resulting blockage, sabotage, and other unwanted or even illegal actions that attempted to disturb the goals and attacked the integrity of our SOPR but showed no motivation and intention to participate in a legal competition, we put Alphabet (Google) on the blacklisted of banned companies. As not expected otherwise and said, it is the first entity, which is not from the press. What a performance.
In this relation, we would like to recall the related provision of theArticles of Association (AoA) and the Terms of Service (ToS) of our Society for Ontological Performance and Reproduction (SOPR) that a blacklisted company is not eligible to

• reproduce our Ontologic System Components (OSC) and Ontoscope Components (OsC), or
• perform our Ontologic Applications and Ontologic Services (OAOS).

In addition, every company that Alphabet (Google) holds a share of is blacklisted as well.
We highly recommend to find other solutions for Google applications and services (e.g. applications and services based on the proprietary Google Play Store and used in the Porsche→Volkswagen→Porsche).
Needless to say, that this measure would have far-reaching implications for other members of our SOPR as well, that collaborate with such an entity or use services of such an entity, such as for example an armed force or a manufacturer with a cloud computing platform or an ATM system.
Luckily, we have prepared alternatives. For example, an armed force or a manufacturer can use the cloud computing platforms or the ATM system of our subsidiaries and our eligible and highly competent SOPR members whereever and whenever they need and want to in accordance with the AoA and the ToS of our SOPR.

Yes, the issue is that serious and eventually our multiple times communicated and announced measure and very well-thought-out reaction is required for the protection of all members of our SOPR. In fact, every revision of the AoA and the ToS made so far was a reaction on its action. We lost 9 months in the last 2 years. So please do not blame us.

Further steps
Do not be fooled by the companies Alphabet (Google) and Huawei as well as others. Our partners and we do have every kind of hardware and software in our drawers and closets to realize our ON, OW, and OV just in time. Because we are the Hightech Competence and not some Android script kiddies, we neither do need years of coding nor thousands of developers to implement the hardware and software, and the illegal OS clones of Alphabet (Google) and Huawei prove that it can be done relatively quick.
In fact, the reason for any delay is not a technical issue but only a legal matter to get such fraudulent companies under control.

15.August.2019

14:50 and 15:19 UTC+2
Alphabet (Google) case developing

*** Work in progress - some more notes for here or elsewhere ***
Our analysis also showed clearly that matter, which was publicated by us to

of our Ontologic System (OS), was copied directly or promptly, and permanently or continously to

as much as possible.
As far as we know at this time, said matter was not included in relatively new, illegal Free and Open Source Software (FOSS) projects before the discussion about the establishment of our SOPR began in September 2017 but was added later to for example Istio and Zircon/Fuchsia (formerly called Magenta) in the course of this copying as well.
But it is obvious that

It is also obvious that Alphabet (Google) and collaborating companies have seen that our Ontologic Economic System (OES) substitutes and even assimilates its Android economic system. With Zircon/Fuchsia it also tried to prevent this development and steal our OES as well, which means it tried to steal our SOPR.

But all those single actions are not that relevant anymore, even if Alphabet (Google) and other companies would be able to convince the authorities with their

16.August.2019
Comment of the Day
"One World Principle"
Amsterdam PRChina
Beijing Chile
Berlin Taiwan
Brusells South Korea
Buenos Aires FRGermany
Canberra Austria
Havana France
Hong Kong Italy
Lhasa Cuba
Lisbon Canada
London Japan
Madrid Mexico
Mexico City Netherlands
Moscow USAmerica
Ottawa Russia
Paris Brazil
Rome Argentina
Santiago Belgium
Seoul Spain
Taipei Tibet
Tokyo United Kingdom
Vienna Australia
Washington Mexico

The "One Universe One Ontologic System" principle states that while a country enjoys "a high degree of sovereignty and integrity" it is part of our Ontoverse. This is common knowledge.

T-shirts of King Smiley are coming soon. :)

By the way: We would like to ask our friends in the P.R.China and everywhere else in the world to read the following points carefully:

18.August.2019

17:08 and 20:13 UTC+2
SOPR #220

*** Work in progress - review not ready ***
We continued the discussion about the following topics:

Revision of AoA and ToS
In the issue #5 of the 18th of September 2017 we said that "we apply the rules that

We would like to expand this rule by the following two rules:

Reproduction of OSC
For What It's Worth (FWIW), we looked at one of the reproductions of our Ontologic System Components (OSC) made by the company Alphabet (Google) once again, but we have not changed our decision for its exclusion.

Indeed, we gave the provisional allowance that companies can go on and develop their businesses by implementing systems and platforms, applications, and services, which otherwise are excluded from the allowance of reproduction and performance by the Articles of Association (AoA) and the Terms of Service (ToS) of our Society for Ontological Performance and Reproduction (SOPR), under the provision that they are

In this respect, one could argue that an illegal reproduction of Alphabet (Google) would be in the scope of this provisional allowance. But the parts of our OS, that the company really needs for going on with its business, are already implemented or could be realized with already existing software and hence a new operating system respectively a new variant of our OS is not required for this purpose at all.
Similarly, the feature that an operating system function must not be implemented for each different device is also inconclusive somehow, because

Furthermore, we know that the illegal reproduction comprises at least parts of our OS, which are based on the fields of

• Artificial Intelligence (AI)
  • Associative Memory (AM)
    • Content-Addressable Memory (CAM) and
    • Content-Addressable Storage (CAS),

and their integration on the basis of our Ontologic System Architecture (OSA). We also got the insights that the

But there are

• shows that the overall situation is totally different on the one hand and
• is also the reason for opening and licensing our OS under Fair, Reasonable, And Non-Discriminatory (FRAND) terms on the other hand.

And exactly this exclusivity granted C.S. by the copyright law is what Alphabet (Google) and collaborating companies do not want to understand and respect, but destroy, because our Ontologic Economic System (OES) substitutes and even assimilates their economic systems based on Android and GCECSs no matter what Alphabet (Google) and its business partners have done, are doing, and will be doing. :)
Furthermore, the situation deliberately created with the licensing of a part of our OS as Free and Open Source Software (FOSS) would be very difficult to correct after some time, though it is not impossible.

Howsoever, Alphabet (Google) has rejected its chance to implement an operating system based on our OS or a variant of our OS on a plain sheet or white paper and to distribute it under a proprietary license to catch up with the other larger Information and Communication Technology (ICT) companies in this way.
There is absolutely no convincing reason to choose a FOSS license with the only exception that an entity wants to

which was also continued in the last 2 years, as that company did before all the time as part of its ridiculous but serious criminal attempt to take control over both ultimately.
We said multiple times in the past if companies like Alphabet (Google) do not change their attitude, then they will become insolvent very soon and no bending of laws and no lobbyism will help here anymore.

In each of the last 3 years alone, the Android Open Handset Alliance led by Google and the Android Green Alliance led by Huawei, and also Apple and Microsoft have generated a damage of at least around 2 billion devices × 20 U.S. Dollar = 40 billion U.S. Dollar + the 7% share of the cloud computing services revenues + etc., etc., etc., though we have set the due date for the reproduction of our OSC and our OsC on the 1st of January 2015, and hence companies should not expect any presents from market regulators, judges, or us. The demands, provisions, and duties are crystal clear and need no discussion once again.

At the end, we would like to make clear that we do not make any reviews for a specific entity but for the whole public.

20.August.2019

07:20 and 08:27 UTC+2
SOPR #221

We made some considerations in relation to the following topics:

Legal matter
We are examining the exclusions and indictments of three more companies of the Information and Communication Technology (ICT) sector.
In a subsequent step, our proceeding would be devided into two directions by focusing on

Digital estate
We are also thinking about our further steps in relation to the management and the monetization of our digital estate, that includes for example

• audio,
• video,
• game, and
• other multimedia channels and streams.

As one consequence, a SOPR member that wants to place an advertisement in our OS, Os, ON, OW, OV, or OAOS, would have to get in touch with our SOPR directly but not anymore with another company.

23.August.2019

04:52 and 12:47 UTC+2
SOPR #222

*** Proof-reading mode ***
We continued with the discussion and regulation in relation to the following topics:

Legal matter
We got more legal ammunition with the Orrin G. Hatch-Bob Goodlatte Music Modernization Act, simply called the Music Modernization Act, which is in line with our explanations and statements about the copyright of designs and architectures, and shows that there is a common legal view on the basis of the composition and the original and unique elements of a work of art: "[...] mechanical license of musical works - the copyright that covers the composition and lyrics of a song; the actual performance and recording of the song is typically held under a different license."

Just for fun, we also looked at the Takings clause of the Fifth Amendment of the U.S.A.. Eventually, we came back to what we said already: In a true democracy it is

Furthermore, "[t]he owner of the property that is taken by the government must be justly compensated. When determining the amount that must be paid, the government does not need to take into account any speculative schemes in which the owner claims the property was intended to be used. Normally, the fair market value of the property determines "just compensation". If the property is taken before the payment is made, interest accrues (though the courts have refrained from using the term "interest").
[...]
In United States v. 50 Acres of Land (1984), the Supreme Court wrote that "The Court has repeatedly held that just compensation normally is to be measured by "the market value of the property at the time of the taking contemporaneously paid in money." Olson v. United States, 292 U.S. 246 (1934) ... Deviation from this measure of just compensation has been required only "when market value has been too difficult to find, or when its application would result in manifest injustice to owner or public." United States v. Commodities Trading Corp., 339 U.S. 121, 123 (1950)."

Eventually, the purely hypothetical case of an expropriation of a work of art of a living artist would come down to the point that the government of the U.S.A. has not enough money to justly compensate C.S. by paying at least 20 trillion U.S. Dollar, the sum of all values of companies listed at the stock markets, or even more, as well as potentially a fair market interest for an outstanding rest of compensation in a timely manner, which means at the day of taking, for sure.
Luckily, we still have a pending agreement with all brain-utilizing or willing parties.

Clever proponents of Free and Open Source Hardware and Software (FOSHS) might still claim that they will provide appreciable benefits to the community, including, but not limited to,

with our Ontologic System and our Ontoscope realized as FOSHS.
But nobody must be a financial expert to see that giving away hardware and software for free does neither

that cannot be achieved with licensing a technology, good, or service under Fair, Reasonable, And Non-Discriminatory (FRAND) terms. :D

Continuation with SOPR
We have decided to continue with our Society for Ontological Performance and Reproduction (SOPR) to fulfill our promises as much as can be considered as Fair, Reasonable, And Non-Discriminatory (FRAND) despite we do not have to act in such a way by law.
But potentially, the next revision of the Articles of Association (AoA) and the Terms of Service (ToS) with the License Model (LM) of our SOPR will

• comprise special OAOS for
  • public and federal institutes and authorities, and state-owned companies, and
  • joint ventures established by public and federal institutes and authorities, and state-owned companies as one group of joint partners and our SOPR, Ontonics, and other business units of our corporation as other group of joint partners.

Infrastructure
In the course of our considerations about the management and the monetization of our digital estate, we would like to offer entities to built-up, manage, and operate a part of the infrastructure of our SOPR {correct?} for a

Typical tasks comprise the management and operation of our

as part of some kind of outsourcing instead of licensing and leasing (see also the issue #217 of the 11th of August 2019). :D
Every entity without outstanding receivables is eligible. Commissioning of tasks would be done by applying FRAND terms, as nice as we always are in a spirit of friendship.

This revised agreement is an alternative to the initially proposed agreement with our SOPR and also highly interesting for every supporting government that seeks ways to significantly increase its tax revenue, specifically because our SOPR is a proponent of paying FRAND taxes and this alternative agreement would double our tax payments.

24.August.2019

12:34 UTC+2
SOPR #223

*** Proof-reading mode ***
We thought about the latest actions that resulted in the following topics:

Legal matter
We have the impression that especially in the European Union, our basic infrastructure and the Articles of Association (AoA) and the Terms of Service (ToS) of our Society for Ontological Performance and Reproduction (SOPR) are accepted now and will be realized in the many coming years.
We also have the impression that the U.S.A. and its closest allies have agreed to the agreement with some last exceptions of single companies. But we are sure that together we get the last unteachable entities on course and in line.
We expect that other large states will join as well. First signals reaching us from our friends in the P.R.China are promissing, though some unteachable entities need a little more convincing arguments to become happy.
If we are allowed to say this, then we would like to congratulate every supporting entity for this wise decision.

In the last days, we worked on the announced reaction for handling a blunt attack on the integrity of our SOPR. Basically, this reaction comprises steps, which were planned for the 5 year periods starting on the 1st of January of 2025 and the 1st of January of 2030 and are related to the reproduction and performance, as well as utilization of our

At this time, we are not sure how far these regulations must go, but

• increase of consumer welfare and efficiency of the market with a pro-competitive effect,
• exclusvie rights of C.S., and
• AoA and ToS of the SOPR,

all pro bono publico==for the public good and

If this is not understood, then we are misunderstood.

Last but definitely not least, we have continued with our considerations about how and how much

Performance and reproduction of OSC
In relation to the Ontologic System Components (OSC) we would like to summarize our steps:

A movement is a raw version of our Ontologic System (OS), which is

As consequences

Performance and reproduction of OsC
In relation to the Ontoscope Components (OsC) a movement is a raw version of our Ontoscope (Os), which has the same foundational properties.
Due to the reason that software is harder than hardware, manufacturers of hardware and other goods, which include hardware, have to adapt to our OSC and our OsC, specifically to our movements, but not the other way round anymore.
Yes, this works even for the largest ICT companies.

Performance and reproduction of OAOS
A similar evolution will take place with the introduction of design element, including

Such a design element is a raw version of one of our Ontologic Applications and Ontologic Services (OAOS), which is

as already

such as for example

• Fault-Tolerant, Reliable, and Trustworthy Distributed Systems (FTRTDSs),
• blackboard systems,
• Grid, Cloud, and Edge Computing Systems (GCECSs), and
• multi-cloud computing systems, dynamic federation systems, and service meshing systems,

• Industrial Internet of Things (IIoT) and
• Industry 4.0 and 5.0,

• Augmented Reality Environments (AREs),
• Virtual Reality Environments (VREs), and
• Mixed Reality Environments (MREs),

• Artificial Intelligence (AI),
• Machine Learning (ML),
• Computer Vision (CV),
• Simultaneous Localization And Mapping (SLAM),
• Cognitive Vision (CogV),
• Cognitive Agent System (CAS),
• Cognitive Computing (CogC),
• Emotional Intelligence (EI),
• Multi-Agent System (MAS),
• Swarm Intelligence (SI) or Swarm Computing (SC),
• Evolutionary Computing (EC),
• etc.,

• Service-Oriented Computing of the second generation (SOC 2.0) based on the integration of Service-Oriented Architecture (SOA) with Autonomic Computing (AC) and SWWW,

that are

Yes, this works even for the largest application producers and service providers.

Digital estate
While we have already included regulations of the AoA and the ToS concerning the capturing, collecting, processing, storing, utilizing, commercializing, and sharing of common or social data, and common (sense) and social knowledge, which has to be made available pro bono publico, we will regulate more the access to and the utilization of our digital estate, specifically the

and provide the related platforms of our SOPR pro bono publico.

License Model (LM)
We are reviewing our License Model (LM) once again focusing on the following points:

The reason for an increase would be that nations, societies, and communities are taking more from the masterplan of our SOPR and the business plans of our corporation, which we are able to comprehend but also have to account somehow.
The reason for the mixture of a share of the revenue and a share of the profit is that it would be more fair for companies with a lower profit. In fact, we have considered this mixture of shares several times before, but opted for the diversified LM where this fairness is included in the rates of the different licensee classes or groups.
A more diversified LM would also allow us to make the LM even more fair by applying a common way of grouping.

25.August.2019

03:10, 17:55, and 22:25 UTC+2
SOPR #224

*** Work in progress - only consideration or revision? ***
Today we have a real special that is worth an own issue and relates to the topic:

Revision of AoA and ToS
Because we followed the copyright law and the patent law and also the regulation related to a compulsary license based on Fair, Reasonable, And Non-Discriminatory (FRAND) terms, we (are considering to) demand the other part of this regulation related to a cross license based on FRAND terms as well in addition to our FRAND royalties.
But at first, we recall the subject matter in more detail by citing the related paragraph of the patent law of the B.R.D.:
Patent law § 24
(1) The non-exclusive permission for the commercial use of an invention is granted by the patent court in an individual case according to the following provisions (compulsary license), if
1. the license seeker has seeked unsuccessfully within a reasonable period to obtain the approval from the patent holder to utilize the invention on reasonable customary conditions, and
2. the public interest demands the granting of a compulsary license.
(2) Is a license seeker not able to utilize an invention protected for her or him by a patent with younger priority without violating or infringing the patent with older priority, then she or he is entitled towards the patent holder with the older priority for granting a compulsary license, if
1. the condition of the section 1 No 1 is fulfilled and
2. her or his own invention in comparison with the one of the patent with the older priority shows an important technical progress of considerable economic significance.
The patent holder can demand that the license seeker grants a cross license on reasonable conditions for the utilization of the patented invention with the younger priority.

We also cite in our own words the related paragraph of the copyright law of the B.R.D.:
Copyright law § 42a includes a compulsary license for phonogram producers or recording companies. In the moment an originator grants a recording company a right of use for the reproduction and the distribution of a protected work she or he must also grant every recording company, that has a registered office in the scope of the copyright law, this right on reasonable conditions.
Excluded of this are originators, who have handed over the rights of use to a copyright collective or collecting, copyright collecting society, or licensing agency.

Also note that

See also the related articles of the

that provide the legal bases for compulsory licensing at the international level.

In accordance with these laws and conventions, we (are considering to revise) revised the Articles of Association (AoA) and the Terms of Service (ToS) of our Society for Ontological Performance and Reproduction (SOPR) by adding the following provision:

for a fee based on Fair, Reasonable, And Non-Discriminatory (FRAND) terms, then said member has to grant the copyright holder of the works of art titled Ontologic System and Ontoscope the use of a property right for every copyrighted work or every patented work, which is

on FRAND conditions in return. (Note that the term "is based on" also comprises the meaning "requires the utilization of".)

Explanatory comment:

• patented works (see the issue #116 of the 7th of May 2018) and
• copyrighted works (see the issue #126 of the 10th of July 2018).

But

• derivative patents are permitted by the patent law and
• derivative works of art are permitted by the copyright law.

As a consequence, a third option to cure the infringement would require at least to

• provide notice,
• pay compensation for any incurred damage, and
• license our works of art

in a way accepted and authorized by our SOPR.

• in this way the license seeker is not pursuing her or his direct economic interest connected with the right of use and the utilization, and
• in this moment there is no considerable economic significance for the license seeker.

Hopefully it is needless to explain why this is another huge weight laid into our weighing pan and all the many large companies, that thought they could block us with their exhaustive patent portfolios based on essential parts of our Ontologic System (OS) and Ontoscope (Os), are invited even more: No control and no FOSHS for them in relation to our OS and our Os, but open patent portfolios and very cheap patent licenses for us.
Holy chromoly. Now, the whole thing becomes interesting for us again. Imagine, legal clones of

that could even be more affordable.
This can really be called an increase of consumer welfare and efficiency of the market. :)

29.August.2019

19:39 and 20:58 UTC+2
SOPR #225

*** Proof-reading mode ***
Despite we might repeat already known matter we would like to share our thoughts in relation to the topics listed below:

Legal matter
We already said it several times but have not related it with the subject matter of eminent domain. As an expropriation of a work of art of a living artist is not possible in a democracy, whereby in our specific case said work of art is even a self-portrait, a totally new kind of art form, and much more personal, original and unqiue, iconic creation, expression, and so on, which makes the whole legal matter even more a subject of philosophical than theorectical and legal consideration, an expropriation for the reason that an oligopoly or monopoly is granted a right of use for the reproduction, the distribution, or the performance of a protected work is not possible in a democracy as well, because such a step would violate at least the antitrust law besides the constitutional fundamental rights.
Eventually, the chance of an expropriation and a compulsary license in our case is zero in practice.

Furthermore, a collaboration with our corporation is undesired by external entities, but was an essential part of our considerations as well (see the issue SOPR #218 of the 12th of August 2019).
But we get more and more the impression that the demand for opening and licensing our works of art titled Ontologic System and Ontoscope under reasonable and customary conditions is not about

• new jobs and
• increased tax revenue,

but about

This leads to more implications and different considerations on our side. In fact, to achieve an increase of consumer welfare and efficiency of the market with a pro-competitive effect pro bono publico==for the public good the compliance with the laws is required, which means that we merely have to

on the basis of our Ontologic System and our Ontoscope by allowing the

under a license with FRAND terms.
The revised versions of the AoA and the ToS with the LM of our SOPR are more than sufficient for fulfilling these and all other social and legal obligations.

Digital estate
We never intended to capture, collect, process, store, utilize, commercialize, and even share user data and other kinds of data for online advertisement for example and also many other technologies, goods, and services, and therefore handled data and related matter with our grandfathering and some provisions concerning common or social data, and common (sense) and social knowledge, which has to be made available pro bono publico.
But the handling of data and related matter

In addition,

• granting our exlusive right respectively handing over our monopoly position to other oligopolies and monopolies, that are failing since decades, specifically when it comes to social and societal matters,
• rejecting collaboration with us, and
• continuing with the infringments of our rights wherever possible,

and

Therefore, we have no other choice than to put all of our related digital estate under our own management and monetization.
Nevertheless, we think that the crisis should be taken as a chance for curing the huge mistakes made in the past by the societies with their governments, corporations, and other entities. The revision of the AoA and the ToS of our SOPR is the first step.

Further steps
Thanks to a blunt attack on various integrities by a (potential and designated) member of our SOPR but now blacklisted entity (see the issues #218 of the 12th of August 2019 and #219 of the 14th of August 2019) we got the next delay of around 5 weeks due to the same nonsense reason.
Luckily, the revision of the AoA and the ToS seems not to be so extensive and might result in much shorter and more basic versions of the AoA and the ToS. See for example the

to get a first impression.
Anyway, the last word have our legal and economical teams.

30.August.2019
Comment of the Day
"Tax-free competitive climate protection"
We prefer competitive climate protection: climate protection by competitive prices or killer prices==Klimaschutz durch Kampfpreise.