Zukunft von hald und dbus in BSD oder: Kann mal bitte jemand den Müll rausbringen? :-)

suiyuan

suiyuan

Well-Known Member
N'aabend,

als einfacher Benutzer ohne Programmiererfahrung wunder ich mich über die Abhängigkeiten, die so einige Programme und auch DEs mit sich bringen, wenn sie per PKG installiert werden. Dazu zähl ich vor allem HAL und dbus.
Diese beiden Biester stammen ja aus der Linuxwelt, wo sie schon längst verstorben sind. Nachdem mit Lumina längerfristig eine brauchbare Alternative zu gnome, KDE und co. am Entstehen ist, gibt es immer weniger Grund, diese beiden Zombies weiter mitzuschleppen. Ist längerfristig geplant, den Müll rauszubringen? Immerhin belegen die Zombies Platz im RAM...

suiyuan
 
HAL ist verstorben, ja, aber DBUS nicht. Das wandert sogar demnächst zu teilen in den Linux-Kernel (Stichwort KDBUS).
 
HAL sollte mal in eine Kiste gepackt und zur Tür rausgetragen werden. Wie das mit allem gemacht wird, was tot ist.

Ich frag mich halt, wie das in Zukunft mit Programmen laufen wird, die DBUS voraussetzen. KDBUS ist ja auf den Linux-Kernel abgestimmt und wird sicher wieder nicht richtig unter BSD laufen. Wie wird das dann mit IBUS (Texteingabe beispielsweise für Chinesisch) weitergehen? Die würden ja dann nicht mehr funktionieren.
 
HAL nähert sich dem Ende. X.org unterstützt bereits seit längerem FreeBSDs nativen devd(8) um Hotplug zu erkennen. Die großen Desktopumgebungen werden Unterstützung dafür sicher auch bald eliminieren. Ich finde es nicht gut, aber wahrscheinlich ist auch für FreeBSD in Sachen Desktop die Zukunft, KDBUS zu implementieren und einen systemd-Wrapper drum herum zu schweißen. Das muss nicht mal so schlimm sein, wie es nun klingt. Immerhin handelt es sich zur Abwechslung sogar mal um halbwegs definierte Schnittstellen, die vielleicht sogar über einen längeren Zeitraum stabil bleiben könnten...
 
Das sind gute Nachrichten. Hauptsache es funktioniert und es wird nicht ständig was geändert um des Änderns willen.

Weißt du zufällig, wann das ungefähr sein wird? Damit ich rechtzeitig eine Flasche Spezi kaltstellen kann. HAL riecht mittlerweile schon etwas streng...
 
Ich bin von HAL auch nicht begeistert, aber so lange es keine Alternative dazu gibt, um Medien mit grafischer Integration automatisch in die DE's ein- und auszubinden, bin ich froh, dass es noch da ist.
 
abeginner schrieb:
Nur deswegen ein Problem oder wo drückt der Schuh? :)
Zum Vergrößern anklicken....

Also ich lese aus dem Thema eher ein hohes Bewußtsein für das heraus, was ich „Systemhygiene“ nennen würde. *g* Ein Aspekt übrigens, dem ich voll und ganz beipflichte. Man muß sich sein System ja nicht unbedingt zumüllen - je weniger Kram da rumliegt, den man eigentlich nicht braucht, desto angenehmer. Und Leichen sind noch mal eine Stufe heftiger - sie stinken, sondern (gefühltes) Leichengift ab und sind halt einfach eine unschöne Sache... ;)

Gerade wenn man möglichst alle seine Pakete selbst baut, kommt da an Abhängigkeiten zur Bauzeit so einiges herein, was einem das kalte Grausen beschert. Wobei ich sagen muß, daß da meine Erfahrungen mit *BSD sogar besser sind als mit Linux. Allgemein sind die BSDs ja etwas konservativer - und trotztdem gleichzeitig aufgeräumter. Es ist schon speziell, wenn man eine abgewandelte Variante von Arch Linux baut und deswegen sämtliche Pakete selbst bauen muß und dann auf dieser bleeding edge-Distri plötzlich GTK+ in version 1 baut, weil ein alter Mediaplayer dieses stark veraltete Toolkit braucht, weil ein Plugin diesen benötigt, weil ein Audio-codec so konfiguriert wird, daß es diesen braucht, usw., usf.

Ich kann also dem Themenersteller nur beipflichten: Tote soll man einfach ruhen lassen. Alles andere ist unanständig.
 
Hab den Titel mal für spätere Suchende geändert. Da mir das Original jedoch so gefiel blieb es mit erhalten.
 
Meine paar Cent zu dem Thema: Um so mehr Abhängigkeiten man zwischen den Softwarepaketen hat, um so komplexer wird das Gesamtsystem.
Um so komplexer dieses ist, um so schwerer wird es zu verwalten etc., entsprechend sollte man die Komplexität auf dem geringsten (möglichen|notwendigen) Niveau halten,
das praktikabel ist.

Und gerade so halb bis ganz Tote wie HAL zeigen das Problem:
Ballast, der eigentlich garnicht gebraucht wird, aber doch immer mitgezogen wird, weil keiner weiß was passier,t wenn mans einfach weglässt.
 
Jopp, bin auch der Meinung, unnötige Komplexität muß nicht sein. Grad bei der Fehlersuche ist es angenehm, wenn bestimmte Dinge sich von vorneherein ausschließen lassen, weil sie nicht (mehr) da sind und außerdem der Nachfolger (devd) bereitsteht.

Beim Installieren von Paketen ist mir aufgefallen, daß es einiges mehr gibt (etwa auch PulseAudio), wo ich mich frag, wofür das reingezogen wird. Wäre schön, sowas in nicht allzuferner Zukunft von vorneherein gar nicht erst auf die Kiste zu bekommen.
 
cabriofahrer schrieb:
Ich bin von HAL auch nicht begeistert, aber so lange es keine Alternative dazu gibt, um Medien mit grafischer Integration automatisch in die DE's ein- und auszubinden, bin ich froh, dass es noch da ist.
Zum Vergrößern anklicken....

Das ist so nicht richtig. GUI-Mount- und Automount-Funktionen waren in KDE, Gnome und XFCE (damals noch in Großbuchstaben geschrieben) schon vorhanden, da gab es HAL noch gar nicht. Das Ziel von HAL, eine abstrahierte Schnittstelle zu jeglicher Form von Hardware zu realisieren, hat sich durch sein Ableben ja insoweit fast schon erledigt. Sobald die BSD-nativen Lösungen (devd und automounter) eine bessere Integration in die GUI-Welt erhalten haben (gern auch in Luminar), besteht auch kein Grund mehr, die Leichenfäule von HAL für ein Lebenszeichen zu halten. Insgesamt bietet auch die systemd-bedingte tendenzielle Abspaltung vieler Linux-Distributionen von der Kompatibilitäts- und Interoperabilitätszielsetzung, die sich im UNIX- und Linux-Umfeld etabliert hat, genug Potential, hier den nativen Lösungen Vorrang vor der Schlacht ums kalte Nacharbeits-Buffet zu geben, denn besonders unter BSD ist die Situation für Entwickler angenehmer, da eine längerfristig stabile API-Umgebung gegeben ist, die es leichter macht, Lösungen umzusetzen, als (wie im Linux-Umfeld oft üblich) einem sich ständig verändernden Ziel hinterherzulaufen. Das betrifft nicht nur die "HAL-Notwendigkeit" des Medienzugriffs, sondern auch die Arbeit mit Netzwerkhardware, Netzwerkeinstellungen oder Endgeräten wie Druckern, Scannern, Kameras und Multimediakomponenten.
 
Gibts denn so hübsches auch für andere BSDs. Devd ist doch nur für FreeBSD und seine Ableger verfügbar. Wie schauts denn mit OpenBSD & NetBSD aus?
 
Equinox schrieb:
Sobald die BSD-nativen Lösungen (devd und automounter) eine bessere Integration in die GUI-Welt erhalten haben (gern auch in Luminar), besteht auch kein Grund mehr, die Leichenfäule von HAL für ein Lebenszeichen zu halten.
Zum Vergrößern anklicken....

Genau darauf warte ich seit Jahren. Ich habe zudem gerade durch diesen Punkt auch das Gefühl, dass die Entwickler sich kaum Gedanken aus der Sicht eines typischen Desktop Users machen. FreeBSD als Desktopsystem ist nach wie vor ein Geheimtipp für Leute, die wohl eher zufällig über Linux darauf gestoßen sind...
Ansonsten auch super der Rest deines Beitrags über die weiter möglichen Ausblicke.
 
@suiyuan: Dann dürfte dich folgendes wohl besonders interessieren
FreeBSD ports/UPDATING schrieb:
20141219:
AFFECTS: users of x11/xorg and all xorg ports
AUTHOR: dumbbell@FreeBSD.org

The X.Org server (x11-servers/xorg-server) is updated to 1.14. All
ports which provide X.Org drivers must be updated simultaneously, i.e.
x11-drivers/xf86-*, emulators/virtualbox-ose-additions, net/tigervnc,
etc.

The input device autodetection backend is switched from HAL to devd.
If you configure your keyboard layout through HAL .fdi files, you need
to migrate this configuration to plain X.Org configuration files.

Up-to-date instructions and a description of the changes brought by
this update are detailed in a blog post:

http://blogs.freebsdish.org/graphics/2014/11/19/xserver-1-14-update-ready/
Zum Vergrößern anklicken....
 
GNOME ist doch ohnehin tot, dachte ich. Wenn die Debianer das nicht mal mehr geschenkt nehmen wollen...
 
Also die 1.14er-Version in den Ports mag mich so gar net. make config zeigt eindeutig an, dass DEVD ausgewählt ist, aber beim configure wird eine große Warnung ausgegeben, dass weder HAL noch DEVD ausgewählt seien, und daher Hotplugging nicht funktionieren würde. Nach make install funktioniert leider gar kein Eingabegerät mehr :(
Ich musste 1.12 aus den packages installieren, dafür aber HALD wieder starten, welches ich eigentlich abgestellt hatte, da ich meinen eigenen 1.12er ohne HAL kompiliert hatte. Gibt es eine Möglichkeit, updates zum portstree wieder rückgängig zu machen? Dann könnte ich zumindest wieder den 1.12er ohne HAL betreiben, besser als nicht.
 
Debian ist ja durchaus willens, nach Alternativen zu suchen.

Fedora hatte ich gerade vergessen. Mein Fehler, pardon.
 
CrimsonKing schrieb:
Debian ist ja durchaus willens, nach Alternativen zu suchen.
Zum Vergrößern anklicken....

Sicherlich. Aber leider ist, trotz der großen Auswahl, nicht viel vorhanden (so doof das klingt).

An großen Umgebungen die mit Windows und OS X "mithalten" können im Funktionsumfang, bleiben nur GNOME und KDE. Alle anderen sind irgendwo zwischen TWM und XFCE.

Und dann geht es halt beim Geschmack los. Wer gerne alles über eine GUI konfigurieren will und möglichst Windows-nah sein will, der nimmt KDE. Wer OS X-nah etwas vorgesetzt bekommen haben will ("friss oder stirb"), der nimmt GNOME.

Funktionieren tun beide relativ gleich gut und haben einen vergleichbaren Funktionsumfang (im Sinne von "wir verstecken das Terminal").

Ansonsten halt weitersuchen bei all den anderen Systemen und das was man braucht noch mit dazu basteln, oder entsprechend konfigurieren, bis man das Wunsch-System hat.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben