Ergebnis 1 bis 4 von 4

Thema: Wozu HAL, DBUS und PolicyKit?

  1. #1
    Neuer Benutzer
    Registriert seit
    17.02.2008
    Beiträge
    8

    Wozu HAL, DBUS und PolicyKit?

    Hallo Forum,

    welche Aufgabe erfüllen HAL, DBUS und PolicyKit?
    Mir erschließt sich angesichts einer POSIX-Schnittstelle der Sinn dieser "Anwendungen" überhaupt nicht.

    Ich erlebe es immer häufiger, dass Anwendungen unter FreeBSD extreme Probleme verursachen, wenn die genannten Programme aktiviert sind. Xorg 7.4 ist so ein Kandidat.

    Provokante Frage: Ist das schon die Linuxifizierung von Unix?

    Ich bitte um Aufklärung.

    Viele Dank schin einmal.

    JueDan

  2. #2
    Neuer Benutzer
    Registriert seit
    19.02.2009
    Beiträge
    3
    Moin Moin,
    HAL = Hardware Abstraction Layer
    HAL ist eine zwischen Schicht die dafür sorgt das Programme auf Hardware über eine Schnittstelle zugreifen können, ohne sich um die speziellen Bedürfnissen der Hardware kümmern zu müssen. Wenn eine neue Festplatte eine ganz spezielle Blockgröße zum schreiben der Daten benutzt, dann kümmert sich HAL darum und nicht die Programme die schreiben wollen.
    D-Bus = IPC System (Inter-Process Communication)
    D-Bus ist eine Schittstelle über der Programme Nachrichten, Signale und Daten unter einander austauschen können. D-Bus ist (war?) ein Versuch eine std Schnittstelle zu bieten, damit nicht jedes Programm seine eigene API (und damit eigene eigenheiten, namens Scheme usw usw) mitbrigen muss.
    PolicyKit = Rechte System
    Der Versuch *nix endlich ein modernes Rechtssystem zu verpassen.
    > Provokante Frage: Ist das schon die Linuxifizierung von Unix?
    Provokante Antwort: Nein, das sind Versuche dem altem Segelschiff Unix modernere Konzepte und Technicken zu Verpassen. Bildlich gesprochen wurde Unix ein Dieselmotor, eine Rehling und eine Funkkommunikationsanlage verpasst.
    mfg
    Allen Welsh Dulles

  3. #3
    Neuer Benutzer
    Registriert seit
    17.02.2008
    Beiträge
    8
    Hallo Allan,

    Zitat Zitat von 'Allen Dulles',index.php?page=Thread&postID=13443#post134 43
    Moin Moin,
    HAL = Hardware Abstraction Layer ...
    Das ist Aufgabe des Betriebssystems, oder besser des Kernels.
    Ich habe mich mal schlau gemacht, warum HAL - bei Linux! - eingeführt wurde. Die Entwickler haben sich in ihrem eigenen Dschungel verlaufen. Wenn ein Gerät am System angeschlossen wird, dann findet man Informationen zu diesem Gerät an zuvielen verschiedenen Stellen. Leider hat man es auch nicht geschafft, einen funktionierenden Hardware-Monitor (device-daemon) auf die Füße zu stellen, der an zentraler Stelle die Informationen zum Gerät bereit stellt.
    Welche Anwendung - außer Systemanwenung - muß denn die Sektorgröße kennen? Richtig, außer Systemanwenungen wie fdisk, label, usw. keine. OpenOffice ist das wurscht, wieviele Bytes ein Sektor hat.

    D-Bus = IPC System (Inter-Process Communication) ...
    Gibt es bei UNIX schon seit langer Zeit. Diese IPC war Vorbild für OS/2... (Als ehemaliger OS/2-Software-Entwickler weiß ich das).

    PolicyKit = Rechte System
    Der Versuch *nix endlich ein modernes Rechtssystem zu verpassen.
    Was ist daran unmodern? Es ist effizient. Bist Du schon an die Grenzen gestoßen? Eine gute Planung der Rechtevergabe ist halt Voraussetzung.

    > Provokante Frage: Ist das schon die Linuxifizierung von Unix?
    Provokante Antwort: Nein, das sind Versuche dem altem Segelschiff Unix modernere Konzepte und Technicken zu Verpassen. Bildlich gesprochen wurde Unix ein Dieselmotor, eine Rehling und eine Funkkommunikationsanlage verpasst.
    In meinen Augen ist das doch der Versuch, Unix zu Linuxifizierung.
    Denn, warum braucht man unter Solaris und FreeBSD (nur zwei Beispiele) diesen HAL und DBUS nicht? Wenn manunter FreeBSD oder Solaris eine Maus während des Betriebs anstöpselt oder abstöpselt wird das vom Kernel registriert und die entsprechenden Treiber in /dev angelegt bzw. entfernt.
    Ebenso verhält es sich mit DBUS. Die genannten Beispiel-OS kennen das schon seit Jahren. Und wenn die Anwendungsprogrammierer damit nicht zurecht kommen, dann müssen sie sich die Dokumentation halt nochmals durchlesen.

    Leider ist es halt so, dass diese zusätzlichen Ebenen folgende negative Effekte haben:
    (*) Verarbeitungsgeschwindigkeit wird herabgesetzt
    (*) Höherer Speicherverbrauch
    (*) Zahl der Abhängigkeiten steigt, was letztlich die Fehleranfälligkeit drastisch erhöht
    (*) Sicherheitslücken: potenziert sich mit jeder zusätzlichen Ebene

    Sehr schön ist es im Moment bei XOrg 7.4 zu beobachten. Unter FreeBSD ist dieses Teil eine Totalkatastrophe und ein Schwachsinn sonders gleichen.FreeBSD (auch (Open-)Solaris) bietet genau diese Dynamik der Geräteerkennung, die mit HAL nachprogrammiert wurde. Das ist krank - Sorry.

    Leider kommt man speziell bei Gnome nicht mehr an HAL und DBUS vorbei. Hoffentlich bleibt es dabei, daß nur einige wenige Programme dieses Zeug benutzen.

    Viele Grüße

    JueDan

  4. #4
    Neuer Benutzer
    Registriert seit
    19.02.2009
    Beiträge
    3
    Hi JueDan,
    Zitat Zitat von 'JueDan',index.php?page=Thread&postID=13444#post13 444
    Das ist Aufgabe des Betriebssystems, oder besser des Kernels.
    Ich habe mich mal schlau gemacht, warum HAL - bei Linux! - eingeführt wurde. Die Entwickler haben sich in ihrem eigenen Dschungel verlaufen. Wenn ein Gerät am System angeschlossen wird, dann findet man Informationen zu diesem Gerät an zuvielen verschiedenen Stellen. Leider hat man es auch nicht geschafft, einen funktionierenden Hardware-Monitor (device-daemon) auf die Füße zu stellen, der an zentraler Stelle die Informationen zum Gerät bereit stellt.
    Welche Anwendung - außer Systemanwenung - muß denn die Sektorgröße kennen? Richtig, außer Systemanwenungen wie fdisk, label, usw. keine. OpenOffice ist das wurscht, wieviele Bytes ein Sektor hat.
    HAL gibt es weil es eine strikte Trennung zwischen Kernel- und Userspace gibt. Das Bsp. mit der Festplatte war von mir wirklich unglücklich gewählt, aber wenn ein Programm aus dem Userspace auf HW zugreifen möchte geht das nur über zwischen Schichten wie eben HAL.
    Gibt es bei UNIX schon seit langer Zeit. Diese IPC war Vorbild für OS/2... (Als ehemaliger OS/2-Software-Entwickler weiß ich das).
    IPC und RPC Systeme gibt es schon seit den ersten Multitasking Systemen. D-Bus ist nur ein Versuch eine einheitliche IPC Schnittstelle anzubieten.
    Was ist daran unmodern?
    Was ist an Lesen, Schreiben ausführen modern?
    Es ist effizient.
    Nein, ist es nicht. Oder warum gibt es wohl ACLs und den ganzen Quatsch?
    Bist Du schon an die Grenzen gestoßen? Eine gute Planung der Rechtevergabe ist halt Voraussetzung.
    Ja bin ich. Und das Gruppen gefrickel ist mehr als zum Kotzen. Übrigens, PK ist für Rechtesystem für Programme und Prozesse. Versuche mal einen Prozess nur das Recht zu lesen zu geben.
    In meinen Augen ist das doch der Versuch, Unix zu Linuxifizierung.
    Denn, warum braucht man unter Solaris und FreeBSD (nur zwei Beispiele) diesen HAL und DBUS nicht? Wenn manunter FreeBSD oder Solaris eine Maus während des Betriebs anstöpselt oder abstöpselt wird das vom Kernel registriert und die entsprechenden Treiber in /dev angelegt bzw. entfernt.
    Ebenso verhält es sich mit DBUS. Die genannten Beispiel-OS kennen das schon seit Jahren. Und wenn die Anwendungsprogrammierer damit nicht zurecht kommen, dann müssen sie sich die Dokumentation halt nochmals durchlesen.
    Komisch, bei meinem openSolaris kümmert sich HAL um die Maus und den Kram. Und das die Xorg Leute mehr auf Linux setzen als auf die anderen *nixe setzen ist leider wahr, hat aber nix mit deiner Ausgangsfrage zu tun.

    mfg
    Allen Welsh Dulles

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •