"Als Kernel soll Linux 2.6.22 mit zusätzlichen Treibern zum Einsatz kommen, das Grafiksystem soll X.org 7.3 sein. Damit soll die Konfigurationsdatei xorg.conf entfallen, da sich das neue X11 weitgehend automatisch konfiguriert. Ubuntu will auf alternative Treiber und Standardeinstellungen zurückfallen, wenn ein Problem erkannt wird."
Hm da bin ich auch mal gespannt wie das funktionieren soll. Besonders da es ja auch Sachen gibt die man nach wie vor in besagter Datei einstellen muss. Allerdings könnte ich mir vorstellen das die xorg.conf in mehrere kleinere Dateien aufgeteilt wird die leichter wartbar sind. Irgendwo müssen die Einstellungen die einmal automatisch erfasst wurden ja abgelegt werden.
Der Rückfall auf alternative Treiber und Standardwerte ist so wie ich es verstanden habe so gedacht das der XServer dann auf VESA zurückfällt damit der User selbst im Notfall noch eine grafische Oberfläche hat auf der man entsprechende Konfigurationsprogramme anbieten kann.
Von Anonymous Coward am Mi, 20. Juni 2007 um 13:04 #
Nur ist die auch seit 20 Jahren unbrauchbar, da sie viel zu viel Bandbreite erfordert. Ohne NX will man sich das wirklich nicht antun, und ich verstehe wirklich nicht, wieso NX nicht schon längst in X.org aufgenommen worden ist. RDP ist nämlich einfach mal besser als das nackte X-Protokoll.
Hmm, nun ja, schnell ist es in der Tat nicht, aber es kann in manchen Fällen sehr hilfreich sein. In Verbindung mit ssh -C läßt sich über eine normale DSL-Leitung im Notfall arbeiten. Keine Frage, RDP, NX und VNC sind effizienter, müssen aber extra installiert und eingerichtet werden. Die Netzwerk-Transparenz von X (und i.d.R. ssh) sind einfach vorhanden.
Ausgemachter Unsinn - ich kann von einem Rechner auf 3 verschiedenen Netzwerkkisten via ssh -X dutzende grafische Programme fernsteuern. Von einem Bandbreitenproblem dabei habe ich noch nichts bemerkt...
Finde ich keine gute Idee. Irgendwo muss ich doch angeben können, welche Auflösung, Vertikalfrequenz, Mausanschluss u.s.w. ich verwenden will. Das alles vom System vorgeschrieben zu bekommen, kann es doch nicht sein!
Vorallem, wenn mal was falsch erkannt wird, dann kann man möglicherweise gar nicht mit dem System arbeiten.
Soll ja nicht heißen, dass Du es nichtmehr fest einstellen kannst. Eine existente xorg.conf wird auch nach wie vor ausgewertet. Nur geht es halt auch ganz ohne.
Automatische Konfiguration auch für das Tastenlayout?
Bei Fedora, dass seit FC6 und xorg 7.2 auch keine direkte Konfiguration von Xorg mehr brauchte (ausser Sondereinstellungen,), wobei die xorg.conf selbst aber noch vorhanden war, muss dieses immer noch angegeben werden. Wie macht das Ubuntu dann? Definiert es bei de_DE.UTF-8 automatisch de-latin1-nodeadkeys als Tastaturlayout?
Bei Fedora, dass seit FC6 und xorg 7.2 auch keine direkte Konfiguration von Xorg mehr brauchte (ausser Sondereinstellungen,), wobei die xorg.conf selbst aber noch vorhanden war, muss dieses immer noch angegeben werden. Die Tastaturbelegung kann man als normaler Nutzer festlegen und auch jederzeit on-the-fly wechseln. Das könnte man also völlig transparent in die Desktopumgebung integrieren.
Von Manfred Tremmel am Mi, 20. Juni 2007 um 13:09 #
Bin schon gespannt, wie die Konfiguration meines Grafiktabletts (mit den IDs der Stifte), des Touchpads (Scrolleiste, Klickverhalten, ...) oder spezielle Modlines (schon mal einen Sony 40" Fernseher angeschlossen, der ist sehr wählerisch mit dem Eingangssignal, automatisch lief da gar nix) definiert werden. Eine xorg.conf im Normalfall nicht mehr zu brauchen ist toll, aber sie für Sonderfälle nicht mehr zur Verfügung zu haben, ist grausam.
>>Damit soll die Konfigurationsdatei xorg.conf entfallen, da sich das neue X11 weitgehend automatisch konfiguriert.
>wie geil ist das denn?
Überhaupt nicht geil - mit etwas Glück funktioniert alles in 80% aller Fälle ganz OK und vielleicht in 50% Fehlerlos.
Ich freue mich schon auf die Beschwerden der Leute, bei denen was schief geht. Inwiefern die Abschaffung einer zentralen Konfigurationsdatei, mit der man die meisten Probleme lösen kann, einen Fortschritt darstellt, erschliesst sich mir jetzt nicht so ganz...
Was "geil" wäre, wäre ein grafisches Werkzeug zum Einstellen von X - ja genau: sowas wie Sax oder DrakX
> Überhaupt nicht geil - mit etwas Glück funktioniert alles in 80% aller Fälle ganz OK und vielleicht in 50% Fehlerlos.
Herrlich. Das muss bestimmt ein tolles Gefühl sein alles neue erst einmal schlecht zu reden, obwohl man es bis jetzt nicht in Aktion gesehen hat.
> Ich freue mich schon auf die Beschwerden der Leute, bei denen was schief geht.
Und wie schlimm soll es noch werden? Bei einer Fehlkonfiguration durch den User bekommt er jetzt schon einen blauen Bildschirm mit englischen PC-Fachbegriffen vorgeworfen und landet dann allein und verlassen auf der Konsole. Die Konsole verrät ihm nicht was jetzt zu tun ist und du kannst nicht von jedem verlangen, das er der englischen Sprache mächtig ist.
>Inwiefern die Abschaffung einer zentralen Konfigurationsdatei, mit der man die meisten Probleme lösen kann, einen Fortschritt darstellt, erschliesst sich mir jetzt nicht so ganz...
Keine Angst, das kann man bestimmt einstellen. Wir sind doch hier nicht bei MS.
> Was "geil" wäre, wäre ein grafisches Werkzeug zum Einstellen von X - ja genau: sowas wie Sax oder DrakX
Habe zwar jetzt keinen Link dazu, aber ja so etwas soll kommen.
> Überhaupt nicht geil - mit etwas Glück funktioniert > alles in 80% aller Fälle ganz OK und vielleicht in 50% Fehlerlos
Ich nahme an du hast diese Zahlen in umfangreichen Statistiken ermittelt, oder ist es doch nur ein schlechtreden bevor man es selbst überhaupt getestet hat?
> Inwiefern die Abschaffung einer zentralen Konfigurationsdatei
Nichts wird abgeschafft, es ist nur nicht mehr zwingend notwendig.
> Was "geil" wäre, wäre ein grafisches Werkzeug > zum Einstellen von X - ja genau: sowas wie Sax oder DrakX
Genau das soll die neue XOrg Version auch vereinfachen. Mit Sax und Co. kann man die xorg.conf zwar grafisch bearbeiten, doch an den grundsätzlichen Problemen des X-Servers ändern diese Tools nichts. Wenn mal doch was falsch eingestellt wurde landet man in der Konsole; man kann vieles nicht bei laufendem X-Server ändern (bzw. es ist danach ein Restart des X-Servers notwendig; ändert man die Hardware ändert sich die xorg.conf nicht automatisch mit. Eine statische Konfigurations-Datei ist in Zeiten wo man mal eben einen zweiten Bildschirm/Beamer/... oder ein neues Eingabegerät anschießt, ohne den PC dabei zu herunterfahren, einfach nicht mehr tragbar. Klar gab es Tools welche um ein paar Probleme herumarbeiteten, doch jetzt wird das Problem endlich an den Wurzeln gelöst.
Ich denke hier sollten sich einige Leute mal über die neuen Features von XOrg informieren, bevor sie über - an den Haaren herbeigezogenen - Probleme flamen.
> Ich nahme an du hast diese Zahlen in umfangreichen Statistiken ermittelt
Nur meine Erfahrung aus den 200 Linuxinstallationen, die ich in letzter Zeit gemacht hab...
> Klar gab es Tools welche um ein paar Probleme herumarbeiteten, doch jetzt wird das Problem endlich an den Wurzeln gelöst.
Wenn das Problem wirklich gelöst wird (das heisst, wenn alle Kombinationen aus Grafikchip/Monitor/Eingabegerät Problemlos automatisch optimal konfiuriert werden...) dann kann ich nur gratulieren und Danke! sagen. Ich bin aber sicher, dass die Zukunft nicht einfacher, sondern komplexer wird und Menschen können auf komplexe Probleme immer noch am besten einwirken. Deshalb macht mich die Aussicht darauf, dass eine einfache Möglichkeit der Einflussnahme wir xorg.conf entfallen könnte, eben etwas nervös.
Wenn es wirklich konsequent so gelöst wird, dass die Konfiguration über xorg.conf immer parallel erhalten bleibt, nehme ich meine Einwände gerne zurück....
> Nur meine Erfahrung aus den 200 Linuxinstallationen, > die ich in letzter Zeit gemacht hab...
Ach, du hast bereist 200 Installationen mit XOrg 7.3 gemacht, welches noch nicht mal released wurde?
> Wenn das Problem wirklich gelöst wird (das heisst, wenn > alle Kombinationen aus Grafikchip/Monitor/Eingabegerät > Problemlos automatisch optimal konfiuriert werden...) dann > kann ich nur gratulieren und Danke! sagen.
Nein, das hab ich nie geschrieben, du reißt hier Sachen aus dem Zusammenhang, und drehst mir das Wort im Mund um.
Ich hab konkrete Probleme genannt welche der X-Server unter Linux bis jetzt hatte, und welche mit 7.3 gelöst werden. Das Wort alle hab ich nirgends verwendet.
> Ach, du hast bereist 200 Installationen mit XOrg 7.3 gemacht, welches noch nicht mal released wurde?
Bleib cool - ich meine natürlich, dass ich reichlich Gelegenheit hatte/habe, zu sehen, wie die Erfolgsrate der in Installern eingesetzten automatischen Grafikkonfigurationen normalerweise aussieht.
Es gibt einfach sehr viele Fälle, wo nach der Installation out of the box noch per Hand eingegriffen werden muss, um eine optimales Resultat zu erhalten. Fehler werden auch meist nicht von Xorg selbst, sondern eben von der Konfig-Automatik verursacht.
> Das Wort alle hab ich nirgends verwendet.
Nein, das habe ich verwendet: weil eine Automatik entweder alle Probleme lösen muss oder eine blosse, untergeordnete Hilfsfunktion (wie eben Sax oder dpkg-reconfigure) sein sollte.
Um Missverstndnisse zu vermeiden: Ich fände mehr Automatik in der Konfiguration von Xorg ganz grossartig. Nur darf das nicht die Möglichkeit einschränken, per Hand eingreifen zu können.
> weil eine Automatik entweder alle Probleme lösen > muss oder eine blosse, untergeordnete Hilfsfunktion > (wie eben Sax oder dpkg-reconfigure) sein sollte.
Nein sehe ich nicht so. Die "Automatik des X-Servers" sollte grundsätzlich mal einen Funktionierenden Desktop zur Verfügung stellen (nicht jeder Linux Nutzer kann oder will manuell, in der Konsole, die xorg.conf editiern) und Situationen in denen plötzlich der X-Server nicht mehr startet möglichst vermeiden (neue Hardware, neuer Kernel und $Binärtreiber nicht passend neu kompiliert, ...). Der Benutzer kann danach noch immer mit einem beliebigen Config-Tool den/die Bildschirm/e, Maus, ... nach seinen wünschen einrichten. Im Idealfall geschieht das auch nicht durch eine statische Config-Datei welche nach jeder Änderung einen Neustart des X-Servers benötigt.
> Nur darf das nicht die Möglichkeit > einschränken, per Hand eingreifen zu können.
Und wo ist dann das Problem? Es steht nirgends dass es in 7.3 so sein wird, und es ist auch für die Zukunft nicht geplant.
Genau darum schrieb ich auch schon in meinem ersten Post: erst informieren, dann flamen.
Ich benutze Ubuntu auf dem Desktop nun schon seit der Zeit als Warty noch nicht draußen war und muss sagen das ich damit bisher sehr gute Erfahrungen gemacht habe. Bin gespannt wie Gutsy daherkommt.
Naja ist ja noch einige Zeit hin aber werde mir wohl mal Tribe 1 herunterladen und auf den Testrechner spielen um mit Fehlerreports beim Bughunting zu helfen.
Hat jemand Erfahrung mit der Umstellung von Ubuntu auf normalen Betrieb mit root? Das derzeitige Standardkonzept ist mir zu umständlich und zu gefährlich, siehe auch: http://www.pro-linux.de/forum/viewtopic.php?t=1032931
Was ist dir an dem Konzept zu umständlich? Ob ich nun su oder sudo -i eingebe um eine Root-Console zu haben, macht den Kohl doch nicht fett.
Und was ist dir an dem Konzept zu gefährlich? Ich finde es jedenfalls toll für meinen Dad. Der braucht sich nur ein passwort merken und ist richtig glücklich. Und ne zusätzliche Gefahr sehe ich auch nicht.
> Ob ich nun su oder sudo -i eingebe um eine Root-Console zu haben
sudo geht nur bei usern, die zur Gruppe admin gehören. su hingegen sollte immer gehen und dabei das root-Passwort abfragen.
> Und was ist dir an dem Konzept zu gefährlich?
Mein User sollte nicht aus Fahrlässigkeit oder durch Schadsoftware was am System pfuschen (können). Wird ein extra root-Passwort (und nicht das Userpasswort) abgefragt, so ist die Gefahr geringer. Die "Hemmschwelle", das root-passwort einzugeben ist höher als beim user-passwort. In normalen Fällen will man bei Mehrbenutzersystemen seinen Nutzern das root-Passwort auch gar nicht verraten. Nur ganz vertrauenswürdige, dh kompetente User, sollten das root-passwort kennen. Gleichzeitig soll der Admin von jedem User-account ausgehend mit su am System werkeln können, ohne sich extra in einen speziellen User-account, welcher zur Gruppe admin gehört, einloggen zu müssen.
Schadsoftware? Wie soll die am System pfuschen koennen? Die hat das User-Passwort genausowenig wie das Root-Passwort. Wo ist der Unterschied aus Sicht der Schadsoftware?
> In normalen Fällen will man bei Mehrbenutzersystemen seinen Nutzern das > root-Passwort auch gar nicht verraten.
Dann nimmt man die Nutzer aus der admin-Gruppe heraus und schon geht sudo nicht mehr. Insb. kann man dem Nutzer beliebig sudo-Rechte zuteilen und entziehen, ohne ihm das root-Passwort verraten zu muessen.
> Gleichzeitig soll der Admin von jedem User-account ausgehend mit su am > System werkeln können, ohne sich extra in einen speziellen User-account, > welcher zur Gruppe admin gehört, einloggen zu müssen.
"sudo passwd root", und schon funktioniert su wie gewohnt
> Dann nimmt man die Nutzer aus der admin-Gruppe heraus und schon geht sudo nicht mehr. Insb. kann man dem Nutzer beliebig > sudo-Rechte zuteilen und entziehen, ohne ihm das root-Passwort verraten zu muessen.
Ja, genau! Ich verstehe das Problem von manchen Leuten nicht. Wenn natürlich jeder Nutzer-Account Admin-Rechte haben muss, weil man stinkefaul ist, passiert das natürlich immer auf eigenes Risiko, wenn man jemanden an der Rechner ist, der für Admin-Rechte gar nicht qualifiziert ist!
Man richtet dem lieben Papa, der sich nicht auskennt, einfach ein Benutzerkonto ohne Adminrechte ein, dann kann der auch nichts verpfuschen!
Wird ein extra root-Passwort (und nicht das Userpasswort) abgefragt, so ist die Gefahr geringer. Dann setz in der /etc/sudoers doch die Option targetpw.
In normalen Fällen will man bei Mehrbenutzersystemen seinen Nutzern das root-Passwort auch gar nicht verraten. Das ist eher ein Grund pro sudo.
Nur ganz vertrauenswürdige, dh kompetente User, sollten das root-passwort kennen. Dann kannst du ja dein root-Kennwort auf einer Mailingliste des CCC posten.
Gleichzeitig soll der Admin von jedem User-account ausgehend mit su am System werkeln können, ohne sich extra in einen speziellen User-account, welcher zur Gruppe admin gehört, einloggen zu müssen. Genau das sehen einige anders. Es gibt nicht umsonst pam_wheel.
Nun, ich hatte mal vor kurzem testweise Kubuntu Feisty Fawn auf mein Notebook installiert. Mittlerweile läuft da wieder Debian Sid/Sidux drauf, die Gründe: Das System kroch, und war auch mit hdparm nicht zum schnelleren Laufen zu bewegen. Ich hatte beim Installieren den Expertenmodus gewählt, dort kann man angeben, ob root samt Paßwort eingerichtet werden soll, was ich getan habe. Das Üble: Sämtliche Aktionen unter KDE, die das Admin Paßwort brauchen, funktionierten nicht, weder das Nutzerpaßwort noch das Root Paßwort wurden akzeptiert.
Nun läuft Sidux auf dem System und ich habe damit keine Schwierigkeiten.
Aber jede/r soll das System nutzen, womit sie/er am besten klar kommt, no flame please
Mit Kubuntu hatte ich auch immer Probleme. Ubuntu und Kde läuft leider häufig nicht wirklich zufriedenstellen. Ubuntu und Gnome läuft bei mir jedoch einwandfrei und macht von Version zu Version erhebliche Fortschritte. Schon zwischen feisty und dapper (vor einem Jahr) liegen Welten.
Aber du hast schon Recht: jeder soll das System benutzen, welches für ihn am Besten passt. Ich suche ja auch immer noch nach einer guten auf debian oder ubuntu basierenden Kde-Distro, die ich für meinen Desktop verwenden kann.
Ich suche ja auch immer noch nach einer guten auf debian oder ubuntu basierenden Kde-Distro, die ich für meinen Desktop verwenden kann.
Dafür wäre evtl. wirklich das von Deinen Vorposter erwähnte Sidux interessant. Persönlich neige ich zwar eher Gnome zu aber jeden das seine. Und man muss die Distribution nehmen die den eigenen Ansprüchen am besten genügt.
Gut ich gebe zu mich eher mit Ubuntu den mit Kubuntu auszukennen was daran liegt das ich persönlich Gnome bevorzuge. Dort hatte ich derlei Probleme noch nicht. Interessant wäre in Deinem Fall nicht nur die Sache mit hdparm sondern auch ob bei der Sidux Installation die selben Pakete vorhanden sind und auch die selben Dienste im Hintergrund laufen. Ich habe hier wie gesagt Ubuntu laufen und es läuft gut. Sowohl auf dem Desktop als auch auf dem Notebook. Natürlich ist es durchaus möglich das Ubuntu besser als Kubuntu abgestimmt ist. Habe mal was dahingehend gehört.
Ich habe (momentan) Ubuntu auf meinem homeserver (älterer p4 Dell Rechner) und auf meinem Notebook und auf beiden Systemen ist die Festplattenperformance mies, an USB Laufwerke brauch ich gar nicht erst zu denken...ist seit der Umstellung der IDE Treiber bei mir so, helfen konnte mir keiner...werd wohl bald wieder auf die Kombination Fedora+gentoo umschwenken, auch wenn ich fast 2 Jahre hochzufrieden mit ubuntu war.
Nun die Distribution scheint je nach Hardware in der Tat recht unterschiedlich zu reagieren. Hier läuft es wie gesagt gut und das auch mit einer USB-Festplatte mit 250GB. Klar gibt es auch bei Ubuntu immer noch viel zu verbessern aber sonst wäre es ja langweilig wenn es nichts mehr Neues mehr gäbe.
Grüße Sturmkind
PS. Auf dem Servern habe ich weiterhin Debian da es mir dafür bisher als besser geeignet als Ubuntu erscheint. Ist aber wohl letztendlich nur Geschmackssache.
Sudo kann man auch ganz einfach selbst einrichten, nicht nur unter Ubuntu:
$ su - # visudo ... # Members of the admin group may gain root privileges %admin ALL=(ALL) ALL ... # # falls die Gruppe "admin" noch nicht existiert # addgroup --system admin # # Standardbenutzer zur Gruppe admin hinzufügen # adduser admin
Unter manchen Systemen ist adduser/addgroup nicht verfügbar, dann muss man halt useradd(1)/groupadd(1) verwenden.
Es wäre mal schön, diese ganzen Tipps an zentraler Stelle (Ubuntu-Wiki) zu sammeln und zu bewerten, denn überall im Netz findet man andere Varianten und meine Kompetenz reicht nicht aus, zu entscheiden, was nun richtiger ist d.h. was zu den wenigsten Problemen führt und die Umstellung auf root-Konzept am besten vollzieht. Dabei erinnere ich mich schwach, in der c't gelesen zu haben, eine Umstellung auf root-Konzept bei Ubuntu wäre nicht empfehlenswert weil nicht ohne Probleme möglich. Genauso wie es bei Debian nicht empfehlenswert wäre, sudo zu verwenden. Es war ein Artikel wo das aktuelle stabile Debian (Etch) beschrieben wurde, glaube ich.
Von Kai F. Lahmann am Mi, 20. Juni 2007 um 12:51 #
die Gründe pro sudo sind für mich: · Ich kann mehrere Admins haben, ohne ein Passwort rumreichen zu müssen. · zwischen "darf alles" und "darf nix" gibt es theoretisch Abstufungen, es müsste sogar möglich sein, bestimmte Tätigkeiten (Lesen in fremden Userordnern) so wirklich sämtlichen Benutzern inkl. Admins zu verbieten. · die Benutzer werden wirksam davon abgehalten, sich als Admin anzumelden - ein als root laufender Browser oder Mailclient ist mit Sicherheit ein wesentlich größeres Loch, als jedes noch so schlechte Passwort!
wie geil ist das denn?
Der Rückfall auf alternative Treiber und Standardwerte ist so wie ich es verstanden habe so gedacht das der XServer dann auf VESA zurückfällt damit der User selbst im Notfall noch eine grafische Oberfläche hat auf der man entsprechende Konfigurationsprogramme anbieten kann.
Grüße
Sturmkind
Nicht ganz, Win95 ist aus 640x480 zurückgefallen (nicht 800x600). Meistens hat sich jedoch das gesamte System bei Grafikproblemen verabschiedet.
Jörg
cya, jens:wq
Ausgemachter Unsinn - ich kann von einem Rechner auf 3 verschiedenen Netzwerkkisten via ssh -X dutzende grafische Programme fernsteuern. Von einem Bandbreitenproblem dabei habe ich noch nichts bemerkt...
Lokal daheim reicht eigentlich und da ist X über eine 1 GBit Leitung mehr als schnell genug.
welche Auflösung, Vertikalfrequenz, Mausanschluss u.s.w. ich verwenden will.
Das alles vom System vorgeschrieben zu bekommen, kann es doch nicht sein!
Vorallem, wenn mal was falsch erkannt wird, dann kann man
möglicherweise gar nicht mit dem System arbeiten.
Die Frage ist wo die Configs dann gespeichert werden, und wie der XServer das mitbekommt.
Außerdem wird es, wie geschrieben, einen Fallback geben der bei jedem laufen sollte.
Eine existente xorg.conf wird auch nach wie vor ausgewertet. Nur geht es halt auch ganz ohne.
Bei Fedora, dass seit FC6 und xorg 7.2 auch keine direkte Konfiguration von Xorg mehr brauchte (ausser Sondereinstellungen,), wobei die xorg.conf selbst aber noch vorhanden war, muss dieses immer noch angegeben werden. Wie macht das Ubuntu dann? Definiert es bei de_DE.UTF-8 automatisch de-latin1-nodeadkeys als Tastaturlayout?
Die Tastaturbelegung kann man als normaler Nutzer festlegen und auch jederzeit on-the-fly wechseln. Das könnte man also völlig transparent in die Desktopumgebung integrieren.
Eine xorg.conf im Normalfall nicht mehr zu brauchen ist toll, aber sie für Sonderfälle nicht mehr zur Verfügung zu haben, ist grausam.
>wie geil ist das denn?
Überhaupt nicht geil - mit etwas Glück funktioniert alles in 80% aller Fälle ganz OK und vielleicht in 50% Fehlerlos.
Ich freue mich schon auf die Beschwerden der Leute, bei denen was schief geht. Inwiefern die Abschaffung einer zentralen Konfigurationsdatei, mit der man die meisten Probleme lösen kann, einen Fortschritt darstellt, erschliesst sich mir jetzt nicht so ganz...
Was "geil" wäre, wäre ein grafisches Werkzeug zum Einstellen von X - ja genau: sowas wie Sax oder DrakX
Herrlich. Das muss bestimmt ein tolles Gefühl sein alles neue erst einmal schlecht zu reden, obwohl man es bis jetzt nicht in Aktion gesehen hat.
> Ich freue mich schon auf die Beschwerden der Leute, bei denen was schief geht.
Und wie schlimm soll es noch werden? Bei einer Fehlkonfiguration durch den User bekommt er jetzt schon einen blauen Bildschirm mit englischen PC-Fachbegriffen vorgeworfen und landet dann allein und verlassen auf der Konsole. Die Konsole verrät ihm nicht was jetzt zu tun ist und du kannst nicht von jedem verlangen, das er der englischen Sprache mächtig ist.
>Inwiefern die Abschaffung einer zentralen Konfigurationsdatei, mit der man die meisten Probleme lösen kann, einen Fortschritt darstellt, erschliesst sich mir jetzt nicht so ganz...
Keine Angst, das kann man bestimmt einstellen. Wir sind doch hier nicht bei MS.
> Was "geil" wäre, wäre ein grafisches Werkzeug zum Einstellen von X - ja genau: sowas wie Sax oder DrakX
Habe zwar jetzt keinen Link dazu, aber ja so etwas soll kommen.
> alles in 80% aller Fälle ganz OK und vielleicht in 50% Fehlerlos
Ich nahme an du hast diese Zahlen in umfangreichen Statistiken ermittelt, oder ist es doch nur ein schlechtreden bevor man es selbst überhaupt getestet hat?
> Inwiefern die Abschaffung einer zentralen Konfigurationsdatei
Nichts wird abgeschafft, es ist nur nicht mehr zwingend notwendig.
> Was "geil" wäre, wäre ein grafisches Werkzeug
> zum Einstellen von X - ja genau: sowas wie Sax oder DrakX
Genau das soll die neue XOrg Version auch vereinfachen. Mit Sax und Co. kann man die xorg.conf zwar grafisch bearbeiten, doch an den grundsätzlichen Problemen des X-Servers ändern diese Tools nichts.
Wenn mal doch was falsch eingestellt wurde landet man in der Konsole; man kann vieles nicht bei laufendem X-Server ändern (bzw. es ist danach ein Restart des X-Servers notwendig; ändert man die Hardware ändert sich die xorg.conf nicht automatisch mit.
Eine statische Konfigurations-Datei ist in Zeiten wo man mal eben einen zweiten Bildschirm/Beamer/... oder ein neues Eingabegerät anschießt, ohne den PC dabei zu herunterfahren, einfach nicht mehr tragbar.
Klar gab es Tools welche um ein paar Probleme herumarbeiteten, doch jetzt wird das Problem endlich an den Wurzeln gelöst.
Ich denke hier sollten sich einige Leute mal über die neuen Features von XOrg informieren, bevor sie über - an den Haaren herbeigezogenen - Probleme flamen.
Nur meine Erfahrung aus den 200 Linuxinstallationen, die ich in letzter Zeit gemacht hab...
> Klar gab es Tools welche um ein paar Probleme herumarbeiteten, doch jetzt wird das Problem endlich an den Wurzeln gelöst.
Wenn das Problem wirklich gelöst wird (das heisst, wenn alle Kombinationen aus Grafikchip/Monitor/Eingabegerät Problemlos automatisch optimal konfiuriert werden...) dann kann ich nur gratulieren und Danke! sagen.
Ich bin aber sicher, dass die Zukunft nicht einfacher, sondern komplexer wird und Menschen können auf komplexe Probleme immer noch am besten einwirken. Deshalb macht mich die Aussicht darauf, dass eine einfache Möglichkeit der Einflussnahme wir xorg.conf entfallen könnte, eben etwas nervös.
Wenn es wirklich konsequent so gelöst wird, dass die Konfiguration über xorg.conf immer parallel erhalten bleibt, nehme ich meine Einwände gerne zurück....
> die ich in letzter Zeit gemacht hab...
Ach, du hast bereist 200 Installationen mit XOrg 7.3 gemacht, welches noch nicht mal released wurde?
> Wenn das Problem wirklich gelöst wird (das heisst, wenn
> alle Kombinationen aus Grafikchip/Monitor/Eingabegerät
> Problemlos automatisch optimal konfiuriert werden...) dann
> kann ich nur gratulieren und Danke! sagen.
Nein, das hab ich nie geschrieben, du reißt hier Sachen aus dem Zusammenhang, und drehst mir das Wort im Mund um.
Ich hab konkrete Probleme genannt welche der X-Server unter Linux bis jetzt hatte, und welche mit 7.3 gelöst werden. Das Wort alle hab ich nirgends verwendet.
Bleib cool -
ich meine natürlich, dass ich reichlich Gelegenheit hatte/habe, zu sehen, wie die Erfolgsrate der in Installern eingesetzten automatischen Grafikkonfigurationen normalerweise aussieht.
Es gibt einfach sehr viele Fälle, wo nach der Installation out of the box noch per Hand eingegriffen werden muss, um eine optimales Resultat zu erhalten. Fehler werden auch meist nicht von Xorg selbst, sondern eben von der Konfig-Automatik verursacht.
> Das Wort alle hab ich nirgends verwendet.
Nein, das habe ich verwendet: weil eine Automatik entweder alle Probleme lösen muss oder eine blosse, untergeordnete Hilfsfunktion (wie eben Sax oder dpkg-reconfigure) sein sollte.
Um Missverstndnisse zu vermeiden: Ich fände mehr Automatik in der Konfiguration von Xorg ganz grossartig. Nur darf das nicht die Möglichkeit einschränken, per Hand eingreifen zu können.
> muss oder eine blosse, untergeordnete Hilfsfunktion
> (wie eben Sax oder dpkg-reconfigure) sein sollte.
Nein sehe ich nicht so. Die "Automatik des X-Servers" sollte grundsätzlich mal einen Funktionierenden Desktop zur Verfügung stellen (nicht jeder Linux Nutzer kann oder will manuell, in der Konsole, die xorg.conf editiern) und Situationen in denen plötzlich der X-Server nicht mehr startet möglichst vermeiden (neue Hardware, neuer Kernel und $Binärtreiber nicht passend neu kompiliert, ...).
Der Benutzer kann danach noch immer mit einem beliebigen Config-Tool den/die Bildschirm/e, Maus, ... nach seinen wünschen einrichten. Im Idealfall geschieht das auch nicht durch eine statische Config-Datei welche nach jeder Änderung einen Neustart des X-Servers benötigt.
> Nur darf das nicht die Möglichkeit
> einschränken, per Hand eingreifen zu können.
Und wo ist dann das Problem? Es steht nirgends dass es in 7.3 so sein wird, und es ist auch für die Zukunft nicht geplant.
Genau darum schrieb ich auch schon in meinem ersten Post: erst informieren, dann flamen.
Naja ist ja noch einige Zeit hin aber werde mir wohl mal Tribe 1 herunterladen und auf den Testrechner spielen um mit Fehlerreports beim Bughunting zu helfen.
Grüße
Sturmkind
http://www.pro-linux.de/forum/viewtopic.php?t=1032931
sudo passwd root
lg
Ob ich nun su oder sudo -i eingebe um eine Root-Console zu haben, macht den Kohl doch nicht fett.
Und was ist dir an dem Konzept zu gefährlich?
Ich finde es jedenfalls toll für meinen Dad. Der braucht sich nur ein passwort merken und ist richtig glücklich. Und ne zusätzliche Gefahr sehe ich auch nicht.
sudo geht nur bei usern, die zur Gruppe admin gehören. su hingegen sollte immer gehen und dabei das root-Passwort abfragen.
> Und was ist dir an dem Konzept zu gefährlich?
Mein User sollte nicht aus Fahrlässigkeit oder durch Schadsoftware was am System pfuschen (können). Wird ein extra root-Passwort (und nicht das Userpasswort) abgefragt, so ist die Gefahr geringer. Die "Hemmschwelle", das root-passwort einzugeben ist höher als beim user-passwort. In normalen Fällen will man bei Mehrbenutzersystemen seinen Nutzern das root-Passwort auch gar nicht verraten. Nur ganz vertrauenswürdige, dh kompetente User, sollten das root-passwort kennen. Gleichzeitig soll der Admin von jedem User-account ausgehend mit su am System werkeln können, ohne sich extra in einen speziellen User-account, welcher zur Gruppe admin gehört, einloggen zu müssen.
Schadsoftware? Wie soll die am System pfuschen koennen? Die hat das User-Passwort genausowenig wie das Root-Passwort. Wo ist der Unterschied aus Sicht der Schadsoftware?
> In normalen Fällen will man bei Mehrbenutzersystemen seinen Nutzern das
> root-Passwort auch gar nicht verraten.
Dann nimmt man die Nutzer aus der admin-Gruppe heraus und schon geht sudo nicht mehr. Insb. kann man dem Nutzer beliebig sudo-Rechte zuteilen und entziehen, ohne ihm das root-Passwort verraten zu muessen.
> Gleichzeitig soll der Admin von jedem User-account ausgehend mit su am
> System werkeln können, ohne sich extra in einen speziellen User-account,
> welcher zur Gruppe admin gehört, einloggen zu müssen.
"sudo passwd root", und schon funktioniert su wie gewohnt
> sudo-Rechte zuteilen und entziehen, ohne ihm das root-Passwort verraten zu muessen.
Ja, genau! Ich verstehe das Problem von manchen Leuten nicht.
Wenn natürlich jeder Nutzer-Account Admin-Rechte haben muss, weil man stinkefaul ist, passiert das natürlich immer auf eigenes Risiko, wenn man jemanden an der Rechner ist, der für Admin-Rechte gar nicht qualifiziert ist!
Man richtet dem lieben Papa, der sich nicht auskennt, einfach ein Benutzerkonto ohne Adminrechte ein, dann kann der auch nichts verpfuschen!
Dann setz in der /etc/sudoers doch die Option targetpw.
In normalen Fällen will man bei Mehrbenutzersystemen seinen Nutzern das root-Passwort auch gar nicht verraten.
Das ist eher ein Grund pro sudo.
Nur ganz vertrauenswürdige, dh kompetente User, sollten das root-passwort kennen.
Dann kannst du ja dein root-Kennwort auf einer Mailingliste des CCC posten.
Gleichzeitig soll der Admin von jedem User-account ausgehend mit su am System werkeln können, ohne sich extra in einen speziellen User-account, welcher zur Gruppe admin gehört, einloggen zu müssen.
Genau das sehen einige anders. Es gibt nicht umsonst pam_wheel.
su 'user der zur gruppe admin gehört'
sudo -i
sollte aber immer gehen
Grüße
Sturmkind
PS. Man sollte Umständlichkeit nicht mit mangelnder Flexibilität seitens der eigenen Person verwechseln.
Das System kroch, und war auch mit hdparm nicht zum schnelleren Laufen zu bewegen. Ich hatte beim Installieren den Expertenmodus gewählt, dort kann man angeben, ob root samt Paßwort eingerichtet werden soll, was ich getan habe. Das Üble: Sämtliche Aktionen unter KDE, die das Admin Paßwort brauchen, funktionierten nicht, weder das Nutzerpaßwort noch das Root Paßwort wurden akzeptiert.
Nun läuft Sidux auf dem System und ich habe damit keine Schwierigkeiten.
Aber jede/r soll das System nutzen, womit sie/er am besten klar kommt, no flame please
Beste Grüße,
Holger
Aber du hast schon Recht: jeder soll das System benutzen, welches für ihn am Besten passt.
Ich suche ja auch immer noch nach einer guten auf debian oder ubuntu basierenden Kde-Distro, die ich für meinen Desktop verwenden kann.
Dafür wäre evtl. wirklich das von Deinen Vorposter erwähnte Sidux interessant. Persönlich neige ich zwar eher Gnome zu aber jeden das seine. Und man muss die Distribution nehmen die den eigenen Ansprüchen am besten genügt.
Grüße
Sturmkind
Debian selbst.
Neben Gentoo die vielleicht besten KDE Pakete überhaupt.
Grüße
Sturmkind
Grüße
Sturmkind
PS. Auf dem Servern habe ich weiterhin Debian da es mir dafür bisher als besser geeignet als Ubuntu erscheint. Ist aber wohl letztendlich nur Geschmackssache.
$ su -
# visudo
...
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
...
# # falls die Gruppe "admin" noch nicht existiert
# addgroup --system admin
# # Standardbenutzer zur Gruppe admin hinzufügen
# adduser admin
Unter manchen Systemen ist adduser/addgroup nicht verfügbar, dann muss man halt useradd(1)/groupadd(1) verwenden.
# adduser user admin
sudo passwd
danach noch gksu-config oder ähnlich aufrufen und aus su stellen ...
Dabei erinnere ich mich schwach, in der c't gelesen zu haben, eine Umstellung auf root-Konzept bei Ubuntu wäre nicht empfehlenswert weil nicht ohne Probleme möglich. Genauso wie es bei Debian nicht empfehlenswert wäre, sudo zu verwenden. Es war ein Artikel wo das aktuelle stabile Debian (Etch) beschrieben wurde, glaube ich.
· Ich kann mehrere Admins haben, ohne ein Passwort rumreichen zu müssen.
· zwischen "darf alles" und "darf nix" gibt es theoretisch Abstufungen, es müsste sogar möglich sein, bestimmte Tätigkeiten (Lesen in fremden Userordnern) so wirklich sämtlichen Benutzern inkl. Admins zu verbieten.
· die Benutzer werden wirksam davon abgehalten, sich als Admin anzumelden - ein als root laufender Browser oder Mailclient ist mit Sicherheit ein wesentlich größeres Loch, als jedes noch so schlechte Passwort!
Das geht nicht. root kann sich immer Zugriffsrechte beschaffen.