eine solche Umgebungsverwaltung auf System-Ebene. Auf der Desktop-Ebene hat sie nichts verloren. Projekte wie etc/net versuchen bereits, Inkonsistente Netzumgebungen zu erkennen und das System darauf einzustellen.
Zusätzlich sollte das hotplug/udev-System ausgeweitet werden, um tatsächlich alle Peripherie, die änderbar ist, zu erfassen. Beispielsweise ermöglichen die neuen pcmciautils, das udev-System mitzunutzen.
Wenn man diese Anstrengungen zur besseren Hardwarenutzung auf die Systemebene verlagern kann, sollte es auch kein Problem sein, den Desktop dazu zu nutzen, die Feinheiten der Konfiguration unkompliziert einzurichten.
Sehe ich genauso. Ich bin froh, dass sich bei KDE jemand mit einer solchen Lösung befasst, aber weiter unten im System wäre es korrekter. Mein Server (jaja, nicht mobil und Netzwerktechnisch ändert sich da auch nicht viel) ohne grafischem Desktop soll auch auf USB-Geräte etc. korrekt reagieren können...
> Sehe ich genauso. Ich bin froh, dass sich bei KDE jemand mit einer solchen Lösung befasst, aber weiter unten im System wäre es korrekter.
Exakt. Die GNOMEr wissen, wie's geht. http://www.gnome.org/projects/NetworkManager/ ist z.B. unterhalb angesiedelt. Soviel zum Thema "not invented here" :).
Jetzt musst du mir nur noch erklären, warum der GNOME-Ansatz tiefer sitzen soll als das geplante solid. Ist beides eine Shared Library mit HAL und darunter liegendem Hardwarezugriff.
"Not invented anywhere" lasse ich ja noch gelten, aber vielleicht haben die KDEler ja eine bessere Idee (vgl. CORBA -> DCOP)?
Auf der solid-Seite sind nicht wirklich viele Angaben gemacht worden. Es bleibt abzuwarten, welche Teile wirklich auf den KDELibs basieren werden (evtl. nur die "frontends"?) und welche nicht.
Es gibt heute schon eine Vielzahl an Geräten, die sich über libs ansteuern lassen. Ein Beispiel (leider teilweise ein negatives...) ist libusb.
Es mag sein, das der Haupttreiber vom udev geladen wird, was aber mit dem Gerät weiterhin gemacht wird liegt im Userspace. Ähnlich verhält es sich mit Bluetooth-Komponenten. Dieses System wird ziemlich sicher keinen Treiber ersetzen, sondern nur die schon jetzt verfügbaren Techniken besser verbinden und nutzen.
> Eigentlich ist es ja nicht mal eine reine Unix-Umgebung Hä?
"KDE is a powerful Free Software graphical desktop environment for Linux and Unix workstations. It combines ease of use, contemporary functionality, and outstanding graphical design with the technological superiority of the Unix operating system." http://www.kde.org/
Vorher sollte aber per default ein Linux-System so konfiguriert sein, dass zwei Netzwerkkarten nicht unwillkuerlich vertauscht werden beim Booten, und ich manuell irgendwelche udev-Rules einrichten muss, damit sie korrekt festgenagelt werden (was hier mit den Namen eth0 und eth1 aber auch nicht funktioniert: debian/sid.)
Von Christian Nitschkowski am Mi, 4. Januar 2006 um 21:58 #
Betreffs eth0/eth1: versuchs mal mit SUSE ;-) (bevor einer meckert: ich _vermute_ andere große Desktopdistris (man stelle sich hier die Nennung der eigenen favorisierten Distribution vor) können das auch. Ich weiß es nur halt von SUSE, weil ich die derzeit benutze.
Dein Debian vertauscht unvorhersehbar NIC-Namen? Das habe ich noch nicht erlebt, aber es gibt zwei Möglichkeiten, die der Grund sein können: 1) du hast zwei unterschiedliche NIC Chipsätze und läßt deinen Kernel die Module Autoladen. Trage die Module in der erwünschten NIC-Reihenfolge in /etc/modules ein und dein Problem ist Vergangenheit. Bei gleichen NICs, siehe weiter unten. 2) in beiden NICs steckt beim Start kein Kabel bzw. ein Kabel ohne Gegenstelle, d. h. ohne Last. Und dann ist das ja auch wurscht
Ansonsten kriegt der NIC mit Kabel immer eth0, haben beide NICs Kabel eingesteckt und Last drauf, dann bekommt der NIC mit der höheren Hardwarepriorität eth0, z. B. PCI > ISA, meistens Onboard > PCI, bei 2 * PCI kommt es auf diese PCI-Trigger/Channel an - wie die genau funktionieren weiß ich nicht - und die sollen sich gelegentlich ändern, wenn z. B. USB-Bridges vom Chipsatz in den PCI-Bus eingeschleift werden und man mal ein USB-Gerät beim Start angesteckt hat und mal nicht. Besonders auffällig sind da angebl. VIA und NVidia Chipsätze und die Treiber der Hersteller sollen auch helfen. Ich habe aber bisher keine Probleme damit gehabt, allerdings findet man solche Chipsätze nicht so häufig Servern bzw. Routern.
Ich bin da sicher kein Experte, insofern verlasse dich nicht drauf.
> Dein Debian vertauscht unvorhersehbar NIC-Namen? Das habe ich noch nicht erlebt, aber es gibt zwei > Möglichkeiten, die der Grund sein können:
Ich hab das auf meinem Debian System leider schon derart oft erlebt, dass ich schließlich doch udev rules gesetzt habe. Vielleicht hat sich das bei aktuellen udev-Versionen schon erledigt, aber darauf lasse ich es nicht mehr ankommen. Egal welche Kabel eingesteckt waren, egal ob ich die Module manuell geladen habe,eth0 und eth1 wurden willkürlich vertauscht! Insbesondere auch dann, wenn nur ein Kabel eingesteckt war...
das hat "fast" nichts mit Debian zu tun, sondern liegt an deiner Hardware bzw. dem/n Treiber(n). Manchmal reicht es schon, eine Netzwerkkarte einfach in einen anderen Slot zu stecken. Ansonsten hat mein Vor-Vor-Redner das schon gut erklärt.
natürlich hat das nichts mit Debian zu tun. Es ging mir ja gerade darum, dass solche Probleme aber _auch_ bei Debian auftauchen.
Bevor ich aber die Netzwerkarte meines Notebooks in einen anderen Slot stecke, lasse ich sie doch lieber von udev in lan bzw. wlan (lan0/lan1 beim Desktop) umbenennen ;-)
Nun, ich bin nicht der Einzige mit diesem Problem. siehe hier. Das Eintragen in /etc/modules brachte auch nichts.
Ich habe zwei Interfaces, die mit den Kernelmodulen sis900 und ne2k_pci bedient werden. An dem einen haengt das dsl-Modem, an dem anderen ein Hub, an dem meistens nichts Anderes, Angeschaltetes haengt (halt nur manchmal und dann auch meist nicht zur Bootzeit).
Nach Aussagen des udev-Package-Maintainers stimmt Deine Aussage zur Festlegung der eth* devices nicht (ich hatte sie naemlich so aehnlich auch vorher gehoert und es in einer Mail/Bugreport an ihn erwaehnt). Die einzige Art, devices festzulegen, sei ueber udev-rules. Alles andere sei Zufall. (Ich weiss dann aber nicht, wie Linux ueberhaupt mal funkioniert haben soll, als es noch kein udev gab )
Mit nameif und ifrename kam ich nicht weiter. Vor udev abgesetzt, gab es die devices noch nicht, nach udev konnten sie nicht mehr umbenannt werden. Ich denke, dass der richtige Weg (der aber irgendwie automatisiert sein sollte), der ueber udev-rules ist. Vergleiche: debianforum Bloederweise kann man eth? Namen dann nicht verwenden, sondern muss sich andere einfallen lassen. Ich hoffe, dass das keine grossen Nebenwirkungen hat, so dass ich ueberall manuell dran muss.
Man man... Bei KDE geht echt was vorwärts, alle achtung! Die Ansätze, Pläne und Visionen, die von diesem Projekt ausgehen zielen alle in die richtige Richtung und sind eine große Bereicherung für den Desktop unter Linux. Irgendwann entwickelt KDE noch selbst das Betriebssystem zu ihrem DE
> Die Ansätze, Pläne und Visionen, die von diesem Projekt ausgehen
naja, ganz so "visionär" seh ich die ankündigung nicht. andere systeme können das seit jahren. ich sehe das eher als implementieren von bereits lange fehlenden features ...
Denke ich nicht. Das was auf Systemebene existiert (udev,(cold|hot)plug,dbus,hal) ist meiner Meinung mach ausreichend, auch wenns oft nicht wirklich ausgenutzt wird. Was solid jetzt noch mehr bringen kann, ist die angesprochen Interaktion mit dem Benutzer die kann und sollte nicht auf Systemebende stattfinden.
Bisher gibt es "nur" die ganzen Bibliotheken, die mit dem system direkt in kontakt treten aber keine umgebung die davon so weit abstrahiert, dass der benutzer nichts weiter tun muss als seinen rechner zu starten oder sein usb einzustecken und es klappt alles. Da müssen bisher immer noch die distributoren nachhelfen mit irgendwelchen scripts usw...
Hier muss etwas her, dass das automatisch übernimmt und da ist man mit solid hoffentlich mal auf dem besten weg
Es geht bei Solid u.a. darum, bessere Schnittstellen zwischen den existierenden Hardware-Libraries und den Desktop-Applikationen zu schaffen. Insbesondere vor dem Hintergrund, dass KDE künftig auf Linux, Windows und Mac OS X nativ laufen soll, ist da abstraktionsmäßig noch viel zu tun.
das ist doch kein Ersatz für udev, HAL ect... die libkdehw biete lediglich die Möglichkeit auf Ereignisse, welche von HAL ect. ausgelöst wurden, zu reagieren. Genau so verhällt es sich mit dem Netzwerk. Es stellt halt nur eine EINHEITLICHE Schnittstelle für KDE Programme zu diesen, für den Desktop wichtigen Elementen, dar.
HAL ist jetzt schon ein echtes Problem und es wurde bis heute nicht geschaft DVD-RAM-Medien unter Linux mit HAL ordentlich zu betreiben. Wir ein RAM-Medium mit HAL eingebunden hat man 1. keine Schreibrechte als normaler User und 2. auch Geschwindigkeiten von 20kb/s... wenn überhaupt.
Und dabei ist DVD-RAM ein so geniales Medium und sicher noch dazu. Es ist eigentlich eine sehr geniale Diskette und eignet sich als Backup-Medium - haben die Medien doch eine garantierte Haltbarkeit von mind. 25 Jahren.
Ich glaube nicht, dass deine Probleme durch HAL direkt verursacht sind. HAL sendet lediglich DBUS-messages aus, wenn z.B. Medien eingelegt werden. HAL selbst bindet keine Devices ein und übernimmt auch nicht das Lesen o.Ä.
also erstmal finde ich es ja immer wieder interessant zu sehen, wie schnell die Entwicklung von KDE voran geht. Aber wieso schmeißen jetzt alle mit so wilden Begriffen um sich? Appeal, Plasma, Solid usw.? Kommt mir das nur zur Zeit so extrem vor, oder war das schon immer so? Microsoft hats ja vorgemacht mit Avalon, Indigo usw. Man muss die Begriffe immer erst entschlüsseln, um zu erfahren, dass sich dahinter eigentlich einfache Konzepte befinden :))
Könnte man sicherlich. Ob man das will, wenn man damit mal länger gearbeitet hat, ist die nächste Frage. Ich kann auf einen Plugger gerne verzichten, das Partitionierungstool von Mandriva ist auch schön, einige yast module sicher auch, nur ist YAST so mit SuSE verwachsen, daß schon der Port auf Debian seit x Monaten unterwegs ist und kaum nennenswerte Erfolge feiert. Ob wegen technischer Probleme, Manpower oder Frustration ist mir nicht bekannt. Und als Paketverwalter ist yast erbärmlich, zumndest im Vergleich mit urpmi, apt und smart, die anderen kenne ich nicht ...
Zusätzlich sollte das hotplug/udev-System ausgeweitet werden, um tatsächlich alle Peripherie, die änderbar ist, zu erfassen. Beispielsweise ermöglichen die neuen pcmciautils, das udev-System mitzunutzen.
Wenn man diese Anstrengungen zur besseren Hardwarenutzung auf die Systemebene verlagern kann, sollte es auch kein Problem sein, den Desktop dazu zu nutzen, die Feinheiten der Konfiguration unkompliziert einzurichten.
Gruß, Alex
Markus
Exakt. Die GNOMEr wissen, wie's geht. http://www.gnome.org/projects/NetworkManager/ ist z.B. unterhalb angesiedelt. Soviel zum Thema "not invented here" :).
Jetzt musst du mir nur noch erklären, warum der GNOME-Ansatz
tiefer sitzen soll als das geplante solid. Ist beides eine
Shared Library mit HAL und darunter liegendem Hardwarezugriff.
"Not invented anywhere" lasse ich ja noch gelten, aber
vielleicht haben die KDEler ja eine bessere Idee
(vgl. CORBA -> DCOP)?
Gruß
L00NIX
Lt. Projektseite baut solid auf KDE-Bibliotheken auf wohingegen NetWorkManager nur von Glib abhängt.
Auf der solid-Seite sind nicht wirklich viele Angaben gemacht
worden. Es bleibt abzuwarten, welche Teile wirklich auf den KDELibs
basieren werden (evtl. nur die "frontends"?) und welche nicht.
Gruß
L00NIX
Es mag sein, das der Haupttreiber vom udev geladen wird, was aber mit dem Gerät weiterhin gemacht wird liegt im Userspace. Ähnlich verhält es sich mit Bluetooth-Komponenten. Dieses System wird ziemlich sicher keinen Treiber ersetzen, sondern nur die schon jetzt verfügbaren Techniken besser verbinden und nutzen.
Hä?
"KDE is a powerful Free Software graphical desktop environment for Linux and Unix workstations. It combines ease of use, contemporary functionality, and outstanding graphical design with the technological superiority of the Unix operating system."
http://www.kde.org/
>> Unix-Umgebung
>Hä?
KDE4 soll auch unter Windows laufen. Bzw. die Anwendungen, nicht der gesamte Desktop.
Vorher sollte aber per default ein Linux-System so konfiguriert sein, dass zwei Netzwerkkarten nicht unwillkuerlich vertauscht werden beim Booten, und ich manuell irgendwelche udev-Rules einrichten muss, damit sie korrekt festgenagelt werden (was hier mit den Namen eth0 und eth1 aber auch nicht funktioniert: debian/sid.)
(bevor einer meckert: ich _vermute_ andere große Desktopdistris (man stelle sich hier die Nennung der eigenen favorisierten Distribution vor) können das auch.
Ich weiß es nur halt von SUSE, weil ich die derzeit benutze.
1) du hast zwei unterschiedliche NIC Chipsätze und läßt deinen Kernel die Module Autoladen. Trage die Module in der erwünschten NIC-Reihenfolge in /etc/modules ein und dein Problem ist Vergangenheit. Bei gleichen NICs, siehe weiter unten.
2) in beiden NICs steckt beim Start kein Kabel bzw. ein Kabel ohne Gegenstelle, d. h. ohne Last. Und dann ist das ja auch wurscht
Ansonsten kriegt der NIC mit Kabel immer eth0, haben beide NICs Kabel eingesteckt und Last drauf, dann bekommt der NIC mit der höheren Hardwarepriorität eth0, z. B. PCI > ISA, meistens Onboard > PCI, bei 2 * PCI kommt es auf diese PCI-Trigger/Channel an - wie die genau funktionieren weiß ich nicht - und die sollen sich gelegentlich ändern, wenn z. B. USB-Bridges vom Chipsatz in den PCI-Bus eingeschleift werden und man mal ein USB-Gerät beim Start angesteckt hat und mal nicht. Besonders auffällig sind da angebl. VIA und NVidia Chipsätze und die Treiber der Hersteller sollen auch helfen. Ich habe aber bisher keine Probleme damit gehabt, allerdings findet man solche Chipsätze nicht so häufig Servern bzw. Routern.
Ich bin da sicher kein Experte, insofern verlasse dich nicht drauf.
Ich hab das auf meinem Debian System leider schon derart oft erlebt, dass ich schließlich doch udev rules gesetzt habe. Vielleicht hat sich das bei aktuellen udev-Versionen schon erledigt, aber darauf lasse ich es nicht mehr ankommen. Egal welche Kabel eingesteckt waren, egal ob ich die Module manuell geladen habe,eth0 und eth1 wurden willkürlich vertauscht! Insbesondere auch dann, wenn nur ein Kabel eingesteckt war...
Grüße,
fex
das hat "fast" nichts mit Debian zu tun, sondern liegt an deiner Hardware bzw. dem/n Treiber(n). Manchmal reicht es schon, eine Netzwerkkarte einfach in einen anderen Slot zu stecken. Ansonsten hat mein Vor-Vor-Redner das schon gut erklärt.
- Jens
natürlich hat das nichts mit Debian zu tun. Es ging mir ja gerade darum, dass solche Probleme aber _auch_ bei Debian auftauchen.
Bevor ich aber die Netzwerkarte meines Notebooks in einen anderen Slot stecke, lasse ich sie doch lieber von udev in lan bzw. wlan (lan0/lan1 beim Desktop) umbenennen ;-)
--fex
Ich habe zwei Interfaces, die mit den Kernelmodulen sis900 und ne2k_pci bedient werden. An dem einen haengt das dsl-Modem, an dem anderen ein Hub, an dem meistens nichts Anderes, Angeschaltetes haengt (halt nur manchmal und dann auch meist nicht zur Bootzeit).
Nach Aussagen des udev-Package-Maintainers stimmt Deine Aussage zur Festlegung der eth* devices nicht (ich hatte sie naemlich so aehnlich auch vorher gehoert und es in einer Mail/Bugreport an ihn erwaehnt). Die einzige Art, devices festzulegen, sei ueber udev-rules. Alles andere sei Zufall. (Ich weiss dann aber nicht, wie Linux ueberhaupt mal funkioniert haben soll, als es noch kein udev gab
)
debianforum
Bloederweise kann man eth? Namen dann nicht verwenden, sondern muss sich andere einfallen lassen. Ich hoffe, dass das keine grossen Nebenwirkungen hat, so dass ich ueberall manuell dran muss.
naja, ganz so "visionär" seh ich die ankündigung nicht. andere systeme können das seit jahren. ich sehe das eher als implementieren von bereits lange fehlenden features ...
Linus hat recht, die KDE tut halt echt was für den Linux-Desktop :)
Ich wünsche ein gutes Gelingen für dieses Projekt!
Was solid jetzt noch mehr bringen kann, ist die angesprochen Interaktion mit dem Benutzer die kann und sollte nicht auf Systemebende stattfinden.
Bisher gibt es "nur" die ganzen Bibliotheken, die mit dem system direkt in kontakt treten aber keine umgebung die davon so weit abstrahiert, dass der benutzer nichts weiter tun muss als seinen rechner zu starten oder sein usb einzustecken und es klappt alles. Da müssen bisher immer noch die distributoren nachhelfen mit irgendwelchen scripts usw...
Hier muss etwas her, dass das automatisch übernimmt und da ist man mit solid hoffentlich mal auf dem besten weg
Einfach mal die Webseite anschauen ...
das ist doch kein Ersatz für udev, HAL ect... die libkdehw biete lediglich die Möglichkeit auf Ereignisse, welche von HAL ect. ausgelöst wurden, zu reagieren. Genau so verhällt es sich mit dem Netzwerk. Es stellt halt nur eine EINHEITLICHE Schnittstelle für KDE Programme zu diesen, für den Desktop wichtigen Elementen, dar.
mfg manne
Und dabei ist DVD-RAM ein so geniales Medium und sicher noch dazu. Es ist eigentlich eine sehr geniale Diskette und eignet sich als Backup-Medium - haben die Medien doch eine garantierte Haltbarkeit von mind. 25 Jahren.
Ich tippfe auf den Kernel bzw. die Treiber
Schon mal die KDVD-RAM Tools 0.4 ausprobiert?
Die nutzen HAL!
Schon mal die KDVD-RAM Tools 0.4 ausprobiert?
Die nutzen HAL!
PS: Nach dem mounten der DVD-RAM einfach die Rechte vom Mount Point ändern das wars.
also erstmal finde ich es ja immer wieder interessant zu sehen, wie schnell die Entwicklung von KDE voran geht. Aber wieso schmeißen jetzt alle mit so wilden Begriffen um sich? Appeal, Plasma, Solid usw.? Kommt mir das nur zur Zeit so extrem vor, oder war das schon immer so? Microsoft hats ja vorgemacht mit Avalon, Indigo usw. Man muss die Begriffe immer erst entschlüsseln, um zu erfahren, dass sich dahinter eigentlich einfache Konzepte befinden :))
Gruß
Mike
;)
Also was weiss ich, das Partitionstool von YAST usw.
Gruß
.