OurOS

Aus C3D2
Version vom 28. Mai 2017, 11:00 Uhr von Vater (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „== Idee == OurOS soll ein zentrales Betriebssystem sein, das dezentral - als eigene Instanz - betrieben wird. OurOS soll ein nahezu fertiges System z…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

Idee

OurOS soll ein zentrales Betriebssystem sein, das dezentral - als eigene Instanz - betrieben wird.

OurOS soll ein nahezu fertiges System zum Betrieb eines Betriebssystem und dem Verwenden von Anwendungen sein. Es soll die Anwendung von einem Betriebssystem, etwa wie FreeNAS oder nach dem ServiceBSD#Konzept, sein. Im Unterschied zum (exemplarisch) FreeNAS, soll die standardmäßige Verknüpfung der einzelnen Anwendungen jedoch gegeben sein. Im Unterschied zum (exemplarisch) ServiceBSD#Konzept soll es um die klare Abtrennung der Arten von Daten (System, Konfiguration, Inhalte) gehen.

Es bedarf einer - eher sonst nicht so klaren - Abgrenzung der Arten von verwalteten Daten. Grundsätzlich sind das:

  • Betriebssystem
    öffentlich
  • Anwendung OurOS (Verwaltung vom Betriebsystem, samt der Verwaltung der einzelnen Anwendungen)
    öffentlich
  • einzelne Anwendungen (Pakete)
    öffentlich
  • Konfiguration für einzelne Anwendungen
    (auf Wunsch) öffentlich
  • Zugangsdaten der einzelnen Anwendungen
    nicht öffentlich
  • tatsächliche Daten der Anwendungen von Benutzerinnen und Benutzern
    nicht öffentlich

.

OurOS unterstellt, dass eigentlich gemeinsam ein Betriebssystem verwendet wird, das zentral (und nahezu öffentlich) verwaltet wird. Eigentlich sollen Anwendungen auch so gleich wie möglich konfiguriert sein. Konzeptionelle Ansätze werden dabei vorgegeben (durch die Entwicklung "verordnet"). (Selbstverständlich könnte sich auch ein individueller Zeig abgespaltet werden, was jedoch eben nicht Zweck des Konzeptes ist.) Es sollen sich nur Inhalte zum Betrieb der jeweiligen Instanz, wie etwa die Domain, unterscheiden.

Daten für den Betrieb der einzelne Anwendungen - etwa Zugangsdaten einer Anwendung bei der Verwendung einer Datenbank - dürfen jedoch selbstverständlich nicht öffentlich sein und sind daher lokal zu halten oder verschlüsselt öffentlich abzulegen.

Insbesondere abzugrenzen und selbstverständlich ausschließlich nicht öffentlich zu verwalten sind die Daten von Benutzerinnen und Benutzern. Das bedeutet, dass die Daten der Anwendungen, die Anwendungen für Benutzerinnen und Benutzer sind, separat zu halten sind, um sie besonders behandeln zu können. (Bei der Verwendung von ZFS sollten das beispielsweise ein eigenständiges Dataset sein.)

Das klare Trennen von Arten von Daten soll (kann) mit dem Erstellen und Einhängen von Strukturen von Ordnern (notfalls einzelnen Dateien) geschehen. Etwa bei der Verwendung von ZFS könnten Datasets dazu verwendet werden. So gäbe es - neben dem normalen Betriebssystem - mindestens ein Dataset für die Daten für jede einzelne Anwendung, die durch die Benutzerinnen und Benutzer entstehen. Aber auch schon allein die Anwendung selbst könnte (sollte) ein eigenes Dataset sein. (Gar könnte die Aktualisierung der einzelnen Anwendungen durch das Beziehen von einem aktuellen Snapshot der Anwendung erfolgen. (Es muss selbstverständlich getestet werden wie das bei den einzelnen Anwendungen möglich ist. (Aktualisierung nur im nicht laufenden Betrieb der Anwendung, Prozedur nach dem Neustart der aktualisierten Anwendung, ...)))

Es könnten "interessante" Ansätze verfolgt werden:

  • Aktualisierungen und gemeinschaftliche Anpassungen per ZFS
  • standardmäßige automatische Aktualisierungen

Bezeichnung

OurOS ist lediglich eine spontane Bezeichnung für ein mögliches Projekt.

Siehe auch