FAQ
What is Samsonium?
Samsonium is a highly scalable open source operating system.
Why do we need to design and build yet another operating system, there's plenty out there?
The major demands in IT systems from the user's and expert's perspective:
- Fast and reliable data management.
- Simplicity.
- High availability.
- Security.
- Uniform open standards.
- Tackling the escalated complexity.
- Fast and reliable error diagnostics and resolution.
- Lowering the need for system and software maintenance.
- Uniform open code standards for platform independent operation.
- Uniform licensing policy to tackle legal complexity.
- Published under open source license that places the user to the highest priority over the manufacturer and guarantees their position.
There are numerous software applications or operating systems solve one or a set of these problems but there is no uniform comprehensive solution.
How does Samsonium solve all these problems?
By its type-safe multidimensional database system without using file systems.
Why is that good?
The currently used file systems do not provide type-safe data management and fully platform independent network access. Today it is essential for most software applications thus each application has to make sure of the data integrity by its own methods or use some sort of external solution for every problem.
What is wrong with file systems?
The main problem is file systems are approximately 40-year-old technologies were originally designed for organising data on tape devices. The data was retrieved sequentially via serial access, often winding through all the data stored on the tape. Some related information such as date, size and content identifier name were also assigned to the data blocks for identification. Typically two type of data were used: plain text and some executables with binary content thus there was no need for advanced data-integrity verification as the two type of data are well-distinguishable. Due to the small number and size of data blocks (up to bytes) per tape advanced data identification, grouping and fast random lookup was not a requirement. Today's demands were unimaginable at the time. Corporates, government organisations and individuals built their computer networks on file systems as it was relatively simple to implement or license and make them partially interoperable. They were never intended to be used for what we are using them today. People just started using them, became a culture but we moved way far from the original purpose of them. Today we use disk and semiconductor based storage devices with random access to terrabytes of data, often fragmented into billions of blocks. The variety of content can not be numbered nor reliably identified what software application can handle them. Relying on file-extensions provides only a quasy-normative identification without guarantee. External solutions or the target application itself is needed to identify the data and read its content. Today the complete digital data mankind has is stored on dozens of type-unsafe different filesystems and target-oriented database systems. They are managed by hundreds of thousands of different software applications (or more). As they could not meet the requirements anymore they were patched around to catch up to the growing needs and their deficiencies were covered by various database systems resulting unnecessary complexity with all its side-effects.
-------------------
Mankind's today software engineering culture is roughly comaparable to a garage being extended in the backyard for decades to finally get a skyscraper to home billions. (If somebody ever tried to migrate a website CMS from one server to another with its database know exactly what it all mean. Not to mention multple CMS systems with multiple databases running on different server platforms.)
-------------------
which also replaces the currently used file systems and text based programming languages. Samsonium's database system Compared to other operating systems the resources are virtually described by points and their relations represent vectors in a virtual multidimensional field. Resources can be anything, either hardware devices or software components or user documents. All resources are maintained transparently through the points and vectors by common interfaces, including hardware devices, networks and the source code itself. What makes the difference is the specified target. This structure completely removes the necessity of any kind of regular text-based source code management solutions, scripting languages, complicated revision control tools and plenty of other inconveniences we may don't even notice today. The standardised interfaces make allow to use artificial intelligence algorithms on the entire graph to focus and process certain part of it, analyse, develop, translate, test, debug our software projects or optimise hardware resources, network systems or any other user defined data. Capable to create multiple revisions of either certain points of the field (e.g. specific program components: blocks, methods, fields, classes, etc). Since everything is type-safely developed and no different programming languages are involved (no 'language' at all) the API can be flexibly standardised (by using interface, class and subclass parameters that are mergeable) thus there is no more obstacle with interoperability between functionally interoperable algorithms. Installable software components are also managed through the virtual field. The flexibility of virtual field foundation makes allow to overlay it by user defined interfaces (e.g. conventional file systems for backward compatibility, RDBMS, LDAP, etc) or either overlap them. Fields on network nodes can also be interconnected on lower levels, cluster entire computer networks without additional complex infrastructure. It is also possible to design and simulate complete computer networks in a virtual environment without the need of the live hardware environment and deploy it later onto the hardware in a ready-to-use condition.