DBOS: A Database-Oriented Operating System

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
  • yazz

    Self Service Apps Without the IT Department

  • There are already some Dbos type systems out there. I built one which stores program state in SQLite databases and process state and programs are also stored in SQLite. In the oat I believe things like silver stream did the same too. The project I made is open source too: https://github.com/yazz/yazz

  • OSQuery

    SQL powered operating system instrumentation, monitoring, and analytics.

  • Exactly! https://osquery.io is one example that

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

    InfluxDB logo
  • ideas4

    An Additional 100 Ideas for Computing https://samsquire.github.io/ideas4/

  • I journal computer ideas and the ideas from database engineering are yet to percolate everywhere, especially to the desktop environment. Why is every company building frontends and backends when the CRUD problem could be solved properly once and for all and reused everywhere? We did the same for communication and kernels with Linux, Windows and BSD, and BSD sockets which is shared by practically everybody. Your React frontend is legacy and shall be rewritten in 5 years. But BSD sockets or the Linux kernel doesn't get rewritten everyday.

    Rather than writing hand rolled code for querying data structures and manipulating them as Linux does, we can define queries that retrieve data structures in in the shape we're looking for.

    To put this simply, this is extremely high level, and the idea that data layout, data structure and algorithm can be unaggregated for cache locality and performance and developer experience. We can form materialized views on top of other materialized views and calculate the most efficient retrieval and storage format based on the structure of the data.

    I suspect a materialized view, as in the data structures of the Linux kernel is more efficient than materializing a join at runtime.

    One of my ideas is "ideas4 9. Query for data structure", https://github.com/samsquire/ideas4#9-query-for-data-structu... which is the idea we should be capable of querying to retrieve data structure in the shape we want. The shape of the data lends itself to solving certain kinds of problems.

    An ideas3 is "Query database" https://github.com/samsquire/ideas3#17-query-database, we persist queries as we persist data and use them to optimise query format.

    I also had the idea # 10. in ideas4 to persist data access patterns directly and optimise that. https://github.com/samsquire/ideas4#10-access-pattern-serial...

  • ideas3

    An Extra 100 Ideas For Computing - https://samsquire.github.io/ideas3/

  • I journal computer ideas and the ideas from database engineering are yet to percolate everywhere, especially to the desktop environment. Why is every company building frontends and backends when the CRUD problem could be solved properly once and for all and reused everywhere? We did the same for communication and kernels with Linux, Windows and BSD, and BSD sockets which is shared by practically everybody. Your React frontend is legacy and shall be rewritten in 5 years. But BSD sockets or the Linux kernel doesn't get rewritten everyday.

    Rather than writing hand rolled code for querying data structures and manipulating them as Linux does, we can define queries that retrieve data structures in in the shape we're looking for.

    To put this simply, this is extremely high level, and the idea that data layout, data structure and algorithm can be unaggregated for cache locality and performance and developer experience. We can form materialized views on top of other materialized views and calculate the most efficient retrieval and storage format based on the structure of the data.

    I suspect a materialized view, as in the data structures of the Linux kernel is more efficient than materializing a join at runtime.

    One of my ideas is "ideas4 9. Query for data structure", https://github.com/samsquire/ideas4#9-query-for-data-structu... which is the idea we should be capable of querying to retrieve data structure in the shape we want. The shape of the data lends itself to solving certain kinds of problems.

    An ideas3 is "Query database" https://github.com/samsquire/ideas3#17-query-database, we persist queries as we persist data and use them to optimise query format.

    I also had the idea # 10. in ideas4 to persist data access patterns directly and optimise that. https://github.com/samsquire/ideas4#10-access-pattern-serial...

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts