k3b-kde4

Kamikaze

Kamikaze

Warrior of Sunlight
Teammitglied
Mir ist es ja nie gelungen das ganze KDE4 Zeug auf meinem Notebook zu bauen, deshalb fahre ich immer noch das alte k3b.

Jetzt habe ich es mal auf einem anderen Rechner ausprobiert, da baut das Zeug.

Und ich musste feststellen, k3b-kde4 läuft nur mit HAL. :grumble:
 
Das wundert mich, wo doch eigentlich das große Wechseln zu udev (im Linux-Bereich) stattfindet ...
Zum Vergrößern anklicken....

Aber erst mit KDE4.6.
Außerdem benötigt man entweder udev oder HAL. Für FreeBSD heißt das: ohne HAL läuft bei KDE (fast) nichts.
 
Xorg verwendet inzwischen HAL, wen wunderts wenn KDE das auch braucht? Wir sollten lieber froh sein, dass KDE überhaupt noch HAL supportet im Gegensatz zu XFCE, die nurnoch udev/devicekit unterstützen (auch wenn sie darüber jammern).

Aber angeblich baut doch jemand ein replacement auf Basis von devd für uns, oder ist das wieder eingeschlafen?
 
Ah, ich habe gerade gelesen, dass DfBSD schon eine fast vollständige Implementierung von udev hat. Wieso schaffen die mit so wenig Man-Power eigentlich immer solche Sachen und FreeBSD nicht (…wegduckend…).
Nagut, die hattens auch nötiger weil die noch vor den devfs-Zeiten geforkt haben, oder?
 
Ich frage mich ja bis heute, wieso man nicht einfach mal ein vernünftiges Framework in Stil von kqueue(3) - was sich in FreeBSD, NetBSD und OS X findet - in Linux einbaut und diese 30 Abstraktionslayer im Userland zur Hölle schickt. Mit inotify hat man ja sogar einen Klon versucht, nur ist leider auf halben Weg stehen geblieben... Aber wir können gern wetten, wie es nun weitergeht: In ca. 24 bis 36 Monaten fällt dann auf, dass udev zur Geräteverwaltung und als Hardwareabstraktion auch Murks ist und man wieder was anderes will. Dann fummelt man die nächste halbgare Lösung. Ihr glaubt gar nicht, wie sehr ich mich jedes Mal wieder auf ein Neues über diese Frickelei aufregen kann.

EDIT: Jepp, DFly hatte irgendwann um und bei 4.8 geforkt. devfs kam mit FreeBSD 5.0, wurde dann mit 6.0 Pflicht. Aber ich sehe nicht ein, mein gutes, funktionierendes und durchdachtes devfs aufzugeben, nur weil es gerade modern ist da nenn Wrapper ins Userland zu legen, der doch nur wieder mknod(8) aufruft. *grrr*
 
Devicekit ist längst auf FreeBSD portiert. Die folgenden Infos sind aus schwammigen Tiefen meines Gedächtnisses, also mit Vorsicht zu genießen. So wie ich mich daran erinnere hat es laut Miwi nur ein Wochenende gedauert das zu portieren. Das liegt jetzt einfach auf Eis bis Xorg den Umzug macht. Für mich klang das so als würde es dann wahrscheinlich tatsächlich einfach von Anfang an funktionieren, soweit das bei Xorg irgendwie möglich ist.

Update:
Ich finde nichts in meinen Mail-Archiven und auch nicht im Forum. Entweder die Information kam über IRC oder ich bilde mir das alles ein.
 
Zuletzt bearbeitet:
Kamikaze schrieb:
Devicekit ist längst auf FreeBSD portiert. Die folgenden Infos sind aus schwammigen Tiefen meines Gedächtnisses, also mit Vorsicht zu genießen. So wie ich mich daran erinnere hat es laut Miwi nur ein Wochenende gedauert das zu portieren. Das liegt jetzt einfach auf Eis bis Xorg den Umzug macht. Für mich klang das so als würde es dann wahrscheinlich tatsächlich einfach von Anfang an funktionieren, soweit das bei Xorg irgendwie möglich ist.

Update:
Ich finde nichts in meinen Mail-Archiven und auch nicht im Forum. Entweder die Information kam über IRC oder ich bilde mir das alles ein.
Zum Vergrößern anklicken....

Ich erinnere mich auch an sowas. Aber Devicekit wird ja auch gerade in udev reingemerget, insofern sind die Interfaces bestimmt bald auch wieder andere…
 
Yamagi schrieb:
Aber wir können gern wetten, wie es nun weitergeht: In ca. 24 bis 36 Monaten fällt dann auf, dass udev zur Geräteverwaltung und als Hardwareabstraktion auch Murks ist und man wieder was anderes will. Dann fummelt man die nächste halbgare Lösung. Ihr glaubt gar nicht, wie sehr ich mich jedes Mal wieder auf ein Neues über diese Frickelei aufregen kann.
Zum Vergrößern anklicken....
Sehe ich genauso. Ich frage mich angesichts dessen und dem Geeiere mit den NVidia-Kernel Modulen immer wieder, warum soviele Firmen auf Linux setzen. Planungssicherheit ist etwas anderes. Ich kann mich da auch immer in Rage bringen, wenn bei uns die Diskussion aufkommt, Linux o. FreeBSD.

c.
 
was mich dabei besonders ärgert (neben der Tatsache, die Yamagi schön beschreibt), dass es genau immer dann was "Neues" gibt, wenn das "Alte" ziemlich gut funktioniert.
Es gab damals keinen Grund mehr für HAL, trotz des Linux-Gefrickels in /dev und so. Alles, was HAL da wollte, hatte man mit kleinen Lösungen irgendwie hinbekommen.
OK, dann kam HAL und es kam gewaltig und spätestens, seit die Xorg-Leute darauf setzten, war es doch mehr oder weniger verpflichtend. Wir wissen, welche Probleme es macht (ich schlage mich gerade wieder mit einem) und wir wissen, dass wir es zwar nicht gebraucht hätten, aber die meisten (glücklichen), deren HW es mitmacht, leben doch inzwischen gut mit HAL.
Kaum geht es, entscheiden die bei Linux sich für udev und gegen HAL und der Rest der Freien Welt bekommt vielleicht Glupschaugen oder Kieferstarre, kann es nicht fassen, aber wird es früher oder später irgendwie mitmachen müssen.
Und ganz genau, wie das wieder Yamagi ausführt, denke ich, dass es damit wieder weiter gehen wird.

Allerdings bin ich nicht sicher, ob es ohne diese Abstraction-Layer Systeme geht, wenn die Kernel recht verschieden sind? Müssten sich dann nicht alle ziemlich einig sein? Würde das die Entwicklungsmöglichkeiten nicht einschränken?
Ist es nicht ein Vorteil, soche Systeme ins Userland zu legen und allen weitergehenden Applikationen hier eine einheitliche, Kernel-unabhängige Schnittstelle zu bieten?
 
Das war für mich immer einer der Hauptkritikpunkte an HAL.

Eine Abstraktionsschicht sollte verschiedenen Systeme einheitlich zugänglich machen also Kompatibilität verbessern.

HAL hat genau das Gegenteil getan, erst mal war alles weniger kompatibel als vorher.
 
Moin,

mir war so, als hatte einer der Kernelgurus die Absicht sich die Implementierung von udev bzw. einem udev-Wrapper an die Backe zu nageln. Kann mich leider nicht mehr entsinnen, wer, wann und wo. Gibt es da schon Neuigkeiten?
 
Zuletzt bearbeitet:
Das war Warner Losh. Ich hatte ihn mal drauf hingewiesen, dass DragonFly eine udev-Implementierung hat und er sagte, dass er sich das mal anschauen wollte. Ob er dazu gekommen ist, weiß ich allerdings nicht.
 
Nachdem ich das alles gelesen habe bleibt mir eine Frage. Was ist udev? Ich dachte das wäre einfach eine andere Implementierung von /dev. Da kann man doch gar nichts inkompatibles drehen, der Zugriff erfolgt doch einfach Über Dateioperationen.
 
Udev nimmt Events via netlink Socket vom Kernel entgegen. Die Events werden von den jeweiligen Device Treibern versendet, wenn sich etwas tut, z.B. ein Device Node angelegt wird. Ob udev die Knoten in /dev anlegt oder nicht ist wahrscheinlich egal. Allerdings können auch andere Programme auf dem netlink Socket lauschen, um so mitzubekommen wenn sich etwas an den Devices tut.

Ich spekuliere jetzt einfach mal und behaupte, dass nicht udev selbst das Problem ist weshalb bestimmte Linux-Programme nicht ohne weiteres auf *BSD laufen, sondern das Prinzip, Events von Device Treibern via netlink Socket zu verschicken.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben