Welcome to SIRTX

Welcome to Simple Information Retrieval, Transfer and eXecution or SIRTX.

SIRTX is a research operating system for small devices. Its aim is to provide both real world solutions but also to study how it's unique design interacts with the real world.

SIRTX is made for small embedded devices, however can also be run on a POSIX host system. This flexibility allows for very portable code, fast testing and deployment, reduced requirements for test equipment, and faster training of users.

8919 (* 0) "Welcome to SIRTX" ~>

FAQ

Frequently Asked Questions

General questions

What is SIRTX?: SIRTX is a research operating system for small devices. In contrast to other operating systems it is centred around a central database.
Is SIRTX Free Software or Open Source?: Not yet. It is planed to at least free some of its components and/or reuse them in other projects that are Free Software.
Is there a demo?: Just contact us and we'll provide you with a demo access.
What platforms are supported?: Currently SIRTX runs natively on sufficiently large AVR microcontrollers (such as ATMega32) and as a guest on POSIX systems.
How to pronounce SIRTX?: "sirtex" with no breaks or pauses will do perfectly fine. Feel free to guess where the extra "e" comes from.
Is there a GUI?: A graphical user interface is currently in active development.
Is this a retro system/project?: No. While the look and feel might remind some of a retro computing related project SIRTX is all about modern technologies.
Where is the BASIC?: SIRTX is no retro computing project. There is no BASIC.
Does SIRTX support SQL?: The database in SIRTX is a semantic database. This is a different kind of database than SQL is designed to work with. While possible, we do not include a SQL interface but provide an interface better aligned with semantic data and the constraints of small systems.
Why don't you just make it exactly like ...?: If it would be the same as some other system what would be the fun? If you are happy with some other system clearly you should use that.

What is?

A Tag: A tag is an abstract entity that holds all metadata of a subject. Each tag is associated with exactly one subject.
A Subject: A subject is abstract (e.g. a concept like "reading") or specific (something one can touch) "thing". Each subject is associated with exactly one tag.
An Object: An object is programming interface that allows access to a specific tag-subject pair.
A handle: A handle is a way code (e.g. a function) can access an object (any system resource). It is similar to file descriptor (or file handle) on POSIX systems.
A link: Link is a collective term for relations and metadata.
A relation: A relation is a connection between two tags.
Some Metadata: Metadata is a value connected to a tag. It can be understood as a degenerated relation.
A function: A function is code that can be called to accomplish some task. Other systems call this a command, program, or executable.
A port: Ports are interfaces of functions. They are used to provide input and output to them. Other systems call these arguments, operands, inputs, and outputs.
A logical: A logical is a name associated with a tag for quick access by a user-friendly alias.
A function number: Many functions have in addition to their name also a number for easy access on numeric keyboards
sni (sirtx numerical identifier): A sirtx numerical identifier is a numerical identifier that is given to many core tags. It is used mostly internally, for programming, and scripting. It can also be used as a shortcut to access the tag in question. See the list for more details.
sid (small-identifier): A small identifier is a numerical identifier given to some tags of general interest. This list is not part of SIRTX, however the system features specific support for it to ease use and interoperation.
A virtual handle: A virtual handle is a handle of a boxed native/simple type that uses some properties of the memory layout in order to store its data. Virtual handles do not require any storage (only the pointer to them). They provide a very powerful middle ground between boxed and unboxed types as they come with most of the benefits of both worlds.

Using the system

What commands are there?

See our list of functions.

My terminal looks wrong. How can I change my terminal type?

You can do so with:

control %stdin setvalue TERM="xterm"

(replace xterm with your terminal type)

What are the supported format/prompt variables?

See here.

Which character set is SIRTX using?

SIRTX uses Unicode for most tasks. All user interaction is in UTF-8 (transparently downgraded to US-ASCII on the smallest systems). So users and developers alike should not worry about character encodings.

What is the lifespan of a tag identifier?

The lifespan of a tag id (sirtx_id_t) is the current session. Of a local identifier until it is reset, likely at the next function call. Function numbers, function names, and logicals are stable at least to the release of SIRTX. Many other identifiers are fully stable (UUIDs, SIDs, SNIs, ...).

Developer questions

What is the easiest way to write software for SIRTX?: See SIRTX VM.
Why isn't this ist POSIX ("UNIX", "Linux")?: SIRTX tries to build a new anc clean system. POSIX is a collection of different parts accumulated over the more than sixty years. Not supporting POSIX is an intentional choice to allow a clean design. However, there are a number of good concepts that you also find in SIRTX.
Why don't you have a POSIX compatibility layer?: POSIX based applications will inherently feel alien to the user. Providing a POSIX layer would allow a big number of software packages to be ported at the cost of system quality. This project focuses on quality.
Does SIRTX use an RPC based microkernel?: No, while the API seems a bit similar it is in fact not an RPC implementation. It adds a few features to a classic syscall based API that allows it to be used similar to an RPC based API but with way less of the performance penalities.
Should I use a tag id or a handle?: When considering whether to use a sirtx_id_t or a sirtx_handle_t* the handle is always preferred unless there are specific requirements. Note that the SIRTX VM always stores handles in its registers.
Should I store numbers, booleans, or similar raw or as a handle?: When in doubt those should be stored as handles. This will allow them to be used with all of the API. Note that the SIRTX VM always stores them as handles in its registers.
Doesn't storing everything as a handle come at performance penalties or wasted memory?: Storing data commonly known as native, simple, or unboxed types as handles (boxed) comes at little cost as SIRTX can often use virtual handles for this. Virtual handles do not require extra memory and are about the same performant as unboxed types.
How do I create a virtual handle?: SIRTX will automatically create virtual handles whenever the to be stored value allows it. There is no need to request them specifically.

8291 (* 0) "FAQ" ~>

Imprint

The legal stuff

Author

All content and documentation within this website is accredited to Philipp Schafft.

External hyperlinks

This site doesn't contain any hyperlinks to external resources but that of the author.

Privacy

Access to this site is logged. The logs are used only for administrative purposes such as monitoring.
The logs are periodically deleted by the system administrator. For protection of your privacy no data is passed to third parties.

Copyright

The contents on this page is copyrighted and all rights are reserved. All content is copyrighted and owned by the author Philipp Schafft. The usage (in parts) of any content on this page requires specific permission in writing from the operator.

8101 (* 0) "Imprint" ~>