Darauf habe ich gewartet. Naja, mehr oder weniger. Der KDE Schlüsselbund ist für mich nie das Gelbe vom Ei gewesen. Vielleicht auch wegen der Gewöhnung an den Gnome-Keyring. Ich finde halt dieser ist komfortabler. Nur vielleicht nicht so intuitiv wie der von KDE. Wie auch immer. So etwas kann man nur begrüßen. Die Entscheidung bleibt nun jedem selbst überlassen! Top!
"Der KDE Schlüsselbund ist für mich nie das Gelbe vom Ei gewesen. Vielleicht auch wegen der Gewöhnung an den Gnome-Keyring. Ich finde halt dieser ist komfortabler. Nur vielleicht nicht so intuitiv wie der von KDE."
Aha, der Gnome-Keyring ist komfortabler aber nicht so intuitiv ?
Wie kommts ? Gnome schreibt sich doch immer die Benutzerfreundlichkeit auf die Fahnen...
Da gab es das Portland-Projekt, das zwar die Dialoge nicht vereinheitlichen, aber dafuer sorgen sollte, dass in der jeweiligen Desktop-Umgebung der jeweilige Dateidialog hochkommt, egal ob die Anwendung selbst KDE- oder Gnome-Anwendung ist. Davon habe ich aber schon laenger nichts mehr gehoert...
Davon hat man aber noch nicht so viel gemerkt, es sei denn dessen verdienst ist es, daß manche Qt4-Anwendungen (soll heißen nicht alle, dabei sind VLC und VirtualBox) nach meinen Upgrade auf KDE 4.3RC2 die KDE4-Dateiauswahldialoge verwenden.
Die Dateiauswahldialoge haben wenig damit zu tun. Bei xdg-open geht's drum, dass man nicht annimmt, dass bestimmte Programme da sind. Zum Beispiel würde auf meinem System ein Programm, was ein Textfile mit "gedit /home/sebas/file.txt" versucht zu öffnen, nicht funktionieren. Sobald hier xdg-open benutzt wird, tut's (weil das halt auf KDE Apps umlenkt).
Das nenne ich eine Spitzfindigkeit (und auch ein bisschen arrogant). Idealsterweise (ja, das Wort gibt es nicht) müsste ich keine Datei auswählen, sondern das Programm weiß, was ich will. Da das nicht geht, braucht es halt den Dialog. Von diesem Standpunkt aus gesehen, gibt es keinen Grund, wieso keine Suche integriert sein sollte, denn das Ziel it ja nicht den Benutzer etwas auswählen zu lassen, sndern ihn etwas finden zu lassen. Da ist eine Suche doch alles andere als eine schlechte Idee. Die angestrebte Entwicklung datenbankbasierter Dateisysteme zeigt ebenfalls, wieso das keine schlechte Idee ist.
Dann muss man sie staendig in jeder Anwendung erneut eintippen. Das will kaum jemand. Und eine zentrale Loesung ist besser, als wenn Anwendungen sie, evtl. gar unverschluesselt, in der eigenen Konfiguration speichern.
Das hängt am obigen Text. Da ist von Passwörtern die Rede. Und bei kwallet denken manche Nutzer anscheinend an diese Software KWalletmanager, die immer gerne die eigenen Passwörter abspeichern möchte.
Von Manfred Tremmel am So, 19. Juli 2009 um 19:53 #
Man sollte für jeden Dienst ein eigenes Passwort verwenden, dieses sollte möglichst lang und kryptisch sein, Groß-/Kleinschreibung, Ziffern und Sonderzeichen enthalten und man sollte es nach Möglichkeit immer wieder mal ändern. Das ganze soll dann nicht aufgeschrieben und/oder abgespeichert werden. Das mag in der Theorie ja wunderbar sein, aber in der Praxis können sich Menschen solche Passwörter nur sehr schwer merken. Ab einer gewissen Anzahl (ich hab da mal im Büro eine Analyse gemacht und kam dort schon auf fast 50 Passwörter nur bei mir, dazu dann noch die privaten,...) ist das einfach nicht mehr machbar. In der Praxis werden dann entweder leicht merkbare Passwörter benutzt, ein Passwort immer wieder verwendet oder das ganze notiert (ein Kollege hat ne Excel Tabelle, andere haben es unter der Tastatur kleben). Wenn das Passwort notiert wird, dann doch am besten in einem verschlüsselten Container, wie es die beiden Tools hier machen. Ich bin froh, mein KWallet zu haben.
Von anyoneirgendwer am So, 19. Juli 2009 um 22:18 #
Jap genau so sehe ich das auch.
Die sensibelsten Passwörter hab ich in meinem Kopf gespeichert und die anderen sind momentan noch in einer Textdatei, ist zwar leider net so sicher, aber irgendwann zügel ich das auch mal noch um in einen Passwortspeicher wie gnome-keyring.
[0] Bei mehrfachem Überschreiben mit shred kann es passieren, daß die Daten auf HD wegen des Hardware-Puffers tatsächlich nur einmal geschrieben werden.
das man erst durch mehrmaliges Überschreiben etwas "sicher" löscht, ist mittlerweile überholt. Die haben es mal getestet, in dem Sie versuchten den vorherigen Zustand nach dem Überschreiben festzustellen. Ja, mit irgendwie 9x% Sicherheit geht es sogar. Allerdings bleibt schon nach ein paar Bits soviel Unsicherheit zurück, das es einfach nicht praktikabel ist. die Genauigkeit rutscht ja sehr schnell dann unter 50%. Und dann kannst du auch direkt /dev/urandom auslesen.
Ich denke inzwischen, Paranoiker, die in jedem Büro einen Sicherheitsstandard einführen wollen, der für eine Atomraketenrampe reichen würde, machen die allgemeine Sicherheit nicht besser, sondern schlechter.
Wer wirklich Sicherheit will, muss normale Menschen als intelligente Wesen ernst nehmen und ihnen Alltagstaugliche Lösungen in die Hand geben. Der GNOME-Keyring und KWallet sind alltagstauglich und ein schwer crackbares Masterpasswort kann auch alltagstauglich sein.
Ein synthetisches James-Bond-Szenario, in dem finstere Gestalten Passwörter aus dem Schulsekretariat klauen und mit irgendwelchen Wundermaschinen Wörterbuchsichere Hashes cracken ist vielleicht faszinierend, normalerweise aber albern.
- Anbindung an GDM/KDM (so das man nach dem Login nicht nochmal das Passwort für den Keystore eingeben muss) - Integration von SSH-Key-Passphrases (so das nach dem Login automatisch die Passphrases der eignen SSH-Keys in den SSH-Agent gefüttert werden können) - Der Ablageort für den Keystore sollte konfigurierbar sein (z.B. WebDAV, SMB, FTP, SCP,...)
Das sollte sehr einfach sein, einfach ein PAM Modul schreiben falls es das noch nicht gibt. Nachteil wäre, dass das Loginpasswort dann natürllich immer mächtiger wird, aber das ist der Preis der Bequemlichkeit.
- Anbindung an GDM/KDM (so das man nach dem Login nicht nochmal das Passwort für den Keystore eingeben muss)
Sofern man nicht so dämlich ist, KDE zu benutzen hat man das schon. - Integration von SSH-Key-Passphrases (so das nach dem Login automatisch die Passphrases der eignen SSH-Keys in den SSH-Agent gefüttert werden können)
Leider nicht. Nach der automatischen Anmeldung unter Gnome muss der Schlüsselbund, beispielsweise für Evolution oder W-Lan, immer mit dem Passwort aufgesperrt werden. Das nervt doch ziemlich
Nach der automatischen Anmeldung unter Gnome muss der Schlüsselbund, beispielsweise für Evolution oder W-Lan, immer mit dem Passwort aufgesperrt werden.
nach der automatischen, in der Tat. Und das ist auch gut so. Sonst aber nicht.
Hallo, Also gconf auf keinen Fall, die Fehler sind zu gravierend. Z.B. ist ein Fehler seit gut einem Jahr vorhanden, der faktisch Linux zu einem Single-User-System macht. Und dies in allen distris, selbst mein Gentoo mit neusten gconf hat immer noch diesen Fehler. Und leider sind auch unter gentoo manche Programme nur mit gconf installierbar. Und damit ist mein Linux nur noch im Single-User-Modus lauffähig. Also, wenn dann ein wesentlich einfacheres System, das dann nicht so fehleranfällig ist.
Von Christopher Roy Bratusek am Mo, 20. Juli 2009 um 07:15 #
Welcher Fehler? Bei mir funktioniert GConf nur als root nicht, ansonsten habe ich keine Probleme. Bitte nen Link zum Bugreport, hab demnächst zwei Wochen Urlaub und wollte ein paar mehr oder weniger triviale Sachen für Nautilus machen, evtl. schau ich mir das auch mal an.
Hallo, es sind hunderte von bugreports für diesen Fehler vorhanden, sie beziehen sich auf verschiedene Ebenen ( ssh zu anderen Rechner, root, unterschiedliche User auf einen Rechner) siehe hier: https://bugs.launchpad.net/ubuntu/+source/gconf/+bug/367169 Stichwort gconf communication server
Elektra hat eigentlich nichts mit der Windows Registry gemeinsam, dieser Kontext kam über den unglücklich gewählten ursprünglichen Projektnamen "Linux Registry". Nachdem das die falschen Assoziationen hervorrief und Diskussionen über die Sache ansich erschwerte, wurde der Name geändert. Wie man sieht, scheint es trotzdem noch zu Reflexreaktionen zu kommen
Elektra Konfiguration kannst du nicht nur mit dem Texteditor bearbeiten. Es gibt sogar (zumindest theoretisch) verschiedene Backends wo du sogar frei wählen kannst wie die Konfigurationsdateien aussehen sollen.
Mach ein ldd /usr/lib/libgconf-2.so.4 und dir ist klar warum Kde niemals gconf verwenden wird können.
Ich vertraue diesen Gnome und KDE Sachen nicht. Man sieht ja wie die Gnome Leute bei Freedesktop für ihre Technologieinfektion kämpfen. Na gut, dann halt jetzt das Keykit.
Hoffentlich lassen sich die KDE-Leute nicht übers Ohr hauen, nicht wegen KDE sondern wegen der ganzen anderen desktop environments.
Jeder weiss wie die Ökonomie der Argumentation im Freedesktop Projekt ist. Gerade die Interessen kleiner Desktopumgebungen werden glatt ignoriert. Ansonsten pushen Gnome-Mitglieder wie verrückt für ihre eigenen Technologien als "standard".
Ich vermisse in dem Blogeintrag einen tragfähigen/richtungsweisenden Verbesserungsvorschlag. Freedesktop scheint hier so gut/schlecht zu arbeiten, wie jedes andere frei zusammengewürfelte Gremium auch. Wenn es so läuft, kann ich den Frust zwar verstehen, aber was wäre denn eine Alternative?
Der krasse Gegensatz wäre das Vorgehen des w3c, wo alles tot diskutiert wird, bis irgendjemand kommt und mit eigenen Erweiterungen die Richtung quasi von außen diktiert (siehe HTML5 und die Whatwg sowie das sterben so ambitionierter recommendations wie xhtml2 und xsl-fo ohne wirklich brauchtbare implementierung).
Man könnte kleine Arbeitsgruppen bilden, vielleicht demokratisch bestimmt. Aber wer entscheidet dann, wer wählen darf und welche Arbeitsgruppen gebildet werden. Wenn es dann nach Mehrheitsverhältnissen ginge, wären die kleinen DEs ja wieder benachteiligt. Außerdem ginge das Ausdiskutieren auf Kosten der Entwicklungsgeschwindigkeit der großen DEs, woran die Mehrheit der Entwickler/User ja (leider?) auch kein Interesse hat. Die Arbeitsgruppen bräuchten außerdem Deadlines, damit nichts zu tode diskutiert wird und man gezwungen ist zu einem Ergebnis zu kommen. Ferner müssten die DEs gezwungen werden, nicht an den Entwürfen der Arbeitsgruppen vorbei zu entwickeln.
Ich stecke da nicht drin, wie man ließt, aber da braucht es ja wohl mehr als Gemotze auf der Mailingliste. Wurde das in Gran Canaria zur Sprache gebracht...
Das Problem mit freedesktop ist, dass dort bestimmte Parteien ihre Technologie als "Standard" durchdrücken möchten und andere Technologien durchaus ohne Angabe von Gründen abgelehnt werden. Also von Transparenz keine Spur.
Ein weiteres, kleineres Problem ist, das dort z.T. Technologien ins Blaue entworfen werden, die weder durchdacht sind, noch eine funktionierende Implementierung besitzen (aber natürlich "Standard" werden sollen), während existierende Implementierungen geflissentlich ignoriert werden.
Es gab Meetings diesbezüglich während GCDS, aber ich weiß nicht, was dabei herausgekommen ist.
"Ferner müssten die DEs gezwungen werden, nicht an den Entwürfen der Arbeitsgruppen vorbei zu entwickeln."
Niemand lässt sich zu irgendetwas zwingen, schon gar nicht wenn der Prozess nicht transparent ist. Außerdem hört sich dein Vorschlag doch stark nach "Design by Committee" an. Das hat noch nie funktioniert.
Niemand lässt sich zu irgendetwas zwingen, schon gar nicht wenn der Prozess nicht transparent ist. Außerdem hört sich dein Vorschlag doch stark nach "Design by Committee" an. Das hat noch nie funktioniert. Ich schrieb ja auch, dass das keine ideale Lösunug sei (w3c). Ich wollte nur darauf hinaus, dass das Problem nicht so einfach zu lösen ist.
Ich vermisse in dem Blogeintrag einen tragfähigen/richtungsweisenden Verbesserungsvorschlag.
Ich vermisse viel mehr ein Beispiel für die Behauptung, bisherige Specs wären für kleinere DEs schwierig zu implementieren oder übermäßig groß.
Freedesktop scheint hier so gut/schlecht zu arbeiten, wie jedes andere frei zusammengewürfelte Gremium auch.
Der wesentliche Punkt ist, dass Freedesktop.org kein Gremium ist, sondern eine Art Treffpunkt für Leute mit ähnlichen Zielen (Free Software Desktops und Applikationen). Es können natürlich nur bekannte Anforderungen berücksichtig werden, also solche, die von mitwirkenden Entwicklern vorgebracht werden.
1. Notiere Dir den ersten Teil des Passwort auf einen Zettel: Den ersten Teil erstellst Du z.B. aus der url in Groß- und Kleinschreibung und dazu ein paar Zahlen Zahlen. Irgendetwas, was Du Dir ggf. auch unterwegs wieder zusammenreimen kannst. Dieser Passwortteil ändert sich immer wieder. 2. Der zweite Teil ist immer gleich. Diesen lernst Du auswendig und verrätst ihn niemanden. Dieser beinhaltet 3 Buchstaben und 3 Zahlen und ist Deine persönliche PIN, die Du dem ersten Teil immer anhängst.
Vorteile: - Du kannst Dir Dein Passwort leicht merken. - Dein Passwort ist eine Kombination aus Zahlen, Sonderzeichen, Groß- und Kleinbuchstaben - Du kannst Dein Passwort auf einem Zettel notieren und trotzdem kann niemand damit etwas anfangen, weil Deine PIN geheim ist. - Dein Passwort ist für jede Seite ein unterschiedliches
Also: Keine Namen mehr und nie mehr gleiche Passwörter. Vergessen geht auch nicht mehr. Und das Rausfinden ist sehr schwierig und langwierig.
Ich als böser Webseitenbetreiber, komme aber so aber seinen PIN und kann ganz bequem mal rumprobieren. Z.B. meine Seite ist www.boese.de Und sein KW ist dann: boese123qwe dann probiere ich mal bei Ebay ebay123qwe, oder amazon123qwe.... Ansonsten ganz gute Idee...
Ich finde halt dieser ist komfortabler. Nur vielleicht nicht so intuitiv wie der von KDE.
Wie auch immer. So etwas kann man nur begrüßen. Die Entscheidung bleibt nun jedem selbst überlassen! Top!
Ich finde halt dieser ist komfortabler. Nur vielleicht nicht so intuitiv wie der von KDE."
Aha, der Gnome-Keyring ist komfortabler aber nicht so intuitiv ?
Wie kommts ? Gnome schreibt sich doch immer die Benutzerfreundlichkeit auf die Fahnen...
Portland ist demnach fertig.
Vorteil: Du kannst jeden Dreck hinzufügen
Nachteil: Theoretisch kann jedes GTK+ Programm einen etwas anderen haben.
>> Eigenschaften, Vorschau,
Im Standarddialog: versteckte einbeziehen ja/nein, Änderungsdatum, Größe, Vorschau hängt normalerweise vom Dateifilter, oder dem Entwickler ab
>> Suchfunktion muss dabei sein.
Muss nicht, Dateiauswahl, nicht Dateisuche
>> Muss nicht, Dateiauswahl, nicht Dateisuche
Das nenne ich eine Spitzfindigkeit (und auch ein bisschen arrogant). Idealsterweise (ja, das Wort gibt es nicht) müsste ich keine Datei auswählen, sondern das Programm weiß, was ich will. Da das nicht geht, braucht es halt den Dialog. Von diesem Standpunkt aus gesehen, gibt es keinen Grund, wieso keine Suche integriert sein sollte, denn das Ziel it ja nicht den Benutzer etwas auswählen zu lassen, sndern ihn etwas finden zu lassen. Da ist eine Suche doch alles andere als eine schlechte Idee. Die angestrebte Entwicklung datenbankbasierter Dateisysteme zeigt ebenfalls, wieso das keine schlechte Idee ist.
cu
ich glaube zwar, gerade einen Troll zu füttern, aber was hat der einheitliche Zugriff auf ein Hash-Storage mit der Speicherung von Passwörtern zu tun?
Da ist von Passwörtern die Rede.
Und bei kwallet denken manche Nutzer anscheinend an diese Software KWalletmanager, die immer gerne die eigenen Passwörter abspeichern möchte.
Einheitlich API macht das unsicherer - Unfug
Das mag in der Theorie ja wunderbar sein, aber in der Praxis können sich Menschen solche Passwörter nur sehr schwer merken. Ab einer gewissen Anzahl (ich hab da mal im Büro eine Analyse gemacht und kam dort schon auf fast 50 Passwörter nur bei mir, dazu dann noch die privaten,...) ist das einfach nicht mehr machbar.
In der Praxis werden dann entweder leicht merkbare Passwörter benutzt, ein Passwort immer wieder verwendet oder das ganze notiert (ein Kollege hat ne Excel Tabelle, andere haben es unter der Tastatur kleben).
Wenn das Passwort notiert wird, dann doch am besten in einem verschlüsselten Container, wie es die beiden Tools hier machen. Ich bin froh, mein KWallet zu haben.
Die sensibelsten Passwörter hab ich in meinem Kopf gespeichert und die anderen sind momentan noch in einer Textdatei, ist zwar leider net so sicher, aber irgendwann zügel ich das auch mal noch um in einen Passwortspeicher wie gnome-keyring.
# verschlüsseln:
gpg --output encrypted-file --symmetric --cipher-algo TWOFISH yourfile.txt
# plainfile überschreiben (zB. drei mal [0]) und unlinken:
shred -n 3 -z -u yourfile.txt
# entschlüsseln:
gpg --output yourfile.txt --decrypt encrypted-file
[0] Bei mehrfachem Überschreiben mit shred kann es passieren, daß die Daten auf HD wegen des Hardware-Puffers tatsächlich nur einmal geschrieben werden.
Die haben es mal getestet, in dem Sie versuchten den vorherigen Zustand nach dem Überschreiben festzustellen.
Ja, mit irgendwie 9x% Sicherheit geht es sogar. Allerdings bleibt schon nach ein paar Bits soviel Unsicherheit zurück, das es einfach nicht praktikabel ist. die Genauigkeit rutscht ja sehr schnell dann unter 50%. Und dann kannst du auch direkt /dev/urandom auslesen.
Oft genug auf Basis von gefühltem Wissen:
heise.de: Sicheres-Loeschen-Einmal-ueberschreiben-genuegt
Einmal shred reicht also - wundert mich nicht...
Wer wirklich Sicherheit will, muss normale Menschen als intelligente Wesen ernst nehmen und ihnen Alltagstaugliche Lösungen in die Hand geben. Der GNOME-Keyring und KWallet sind alltagstauglich und ein schwer crackbares Masterpasswort kann auch alltagstauglich sein.
Ein synthetisches James-Bond-Szenario, in dem finstere Gestalten Passwörter aus dem Schulsekretariat klauen und mit irgendwelchen Wundermaschinen Wörterbuchsichere Hashes cracken ist vielleicht faszinierend, normalerweise aber albern.
Und du bist jetzt #103 der FPL
Wünschenswert wäre aus meiner Sicht auch noch:
- Anbindung an GDM/KDM
(so das man nach dem Login nicht nochmal das Passwort für den Keystore eingeben muss)
- Integration von SSH-Key-Passphrases
(so das nach dem Login automatisch die Passphrases der eignen SSH-Keys in den SSH-Agent gefüttert werden
können)
- Der Ablageort für den Keystore sollte konfigurierbar sein
(z.B. WebDAV, SMB, FTP, SCP,...)
Viele benutzen eh meist nur ein Passwort, also ändert sich nichts.
Aber jetzt wird ja alles schön und gut
(so das man nach dem Login nicht nochmal das Passwort für den Keystore eingeben muss)
Sofern man nicht so dämlich ist, KDE zu benutzen hat man das schon.
- Integration von SSH-Key-Passphrases
(so das nach dem Login automatisch die Passphrases der eignen SSH-Keys in den SSH-Agent gefüttert werden
können)
s.o.
Kann man auch anders sagen.
Das nervt doch ziemlich
nach der automatischen, in der Tat. Und das ist auch gut so. Sonst aber nicht.
Nein Danke!
Ich fände eine Einigung auf gconf oder so besser. Gconf dateien kann ich auch wunderbar im Texteditor bearbeiten und das ist auch gut so!
mfg,
paul
Also gconf auf keinen Fall, die Fehler sind zu gravierend. Z.B. ist ein Fehler seit gut einem Jahr vorhanden, der faktisch Linux zu einem Single-User-System macht. Und dies in allen distris, selbst mein Gentoo mit neusten gconf hat immer noch diesen Fehler.
Und leider sind auch unter gentoo manche Programme nur mit gconf installierbar. Und damit ist mein Linux nur noch im Single-User-Modus lauffähig.
Also, wenn dann ein wesentlich einfacheres System, das dann nicht so fehleranfällig ist.
Tschüss
Jürgen
siehe hier: https://bugs.launchpad.net/ubuntu/+source/gconf/+bug/367169
Stichwort gconf communication server
Tschüß
Jürgen
Nein, das besser GConf.
Elektra hat eigentlich nichts mit der Windows Registry gemeinsam, dieser Kontext kam über den unglücklich gewählten ursprünglichen Projektnamen "Linux Registry".
Nachdem das die falschen Assoziationen hervorrief und Diskussionen über die Sache ansich erschwerte, wurde der Name geändert. Wie man sieht, scheint es trotzdem noch zu Reflexreaktionen zu kommen
Mach ein
ldd /usr/lib/libgconf-2.so.4
und dir ist klar warum Kde niemals gconf verwenden wird können.
Umgekehrt gilt es genauso.
Hoffentlich lassen sich die KDE-Leute nicht übers Ohr hauen, nicht wegen KDE sondern wegen der ganzen anderen desktop environments.
http://blog.lxde.org/?p=361
Ich vermisse in dem Blogeintrag einen tragfähigen/richtungsweisenden Verbesserungsvorschlag. Freedesktop scheint hier so gut/schlecht zu arbeiten, wie jedes andere frei zusammengewürfelte Gremium auch. Wenn es so läuft, kann ich den Frust zwar verstehen, aber was wäre denn eine Alternative?
Der krasse Gegensatz wäre das Vorgehen des w3c, wo alles tot diskutiert wird, bis irgendjemand kommt und mit eigenen Erweiterungen die Richtung quasi von außen diktiert (siehe HTML5 und die Whatwg sowie das sterben so ambitionierter recommendations wie xhtml2 und xsl-fo ohne wirklich brauchtbare implementierung).
Man könnte kleine Arbeitsgruppen bilden, vielleicht demokratisch bestimmt. Aber wer entscheidet dann, wer wählen darf und welche Arbeitsgruppen gebildet werden. Wenn es dann nach Mehrheitsverhältnissen ginge, wären die kleinen DEs ja wieder benachteiligt. Außerdem ginge das Ausdiskutieren auf Kosten der Entwicklungsgeschwindigkeit der großen DEs, woran die Mehrheit der Entwickler/User ja (leider?) auch kein Interesse hat.
Die Arbeitsgruppen bräuchten außerdem Deadlines, damit nichts zu tode diskutiert wird und man gezwungen ist zu einem Ergebnis zu kommen. Ferner müssten die DEs gezwungen werden, nicht an den Entwürfen der Arbeitsgruppen vorbei zu entwickeln.
Ich stecke da nicht drin, wie man ließt, aber da braucht es ja wohl mehr als Gemotze auf der Mailingliste. Wurde das in Gran Canaria zur Sprache gebracht...
Steht doch ganz am Ende: Mitmachen!
Nicht Vorschreiben lassen, sondern selber Diktieren.
Ein weiteres, kleineres Problem ist, das dort z.T. Technologien ins Blaue entworfen werden, die weder durchdacht sind, noch eine funktionierende Implementierung besitzen (aber natürlich "Standard" werden sollen), während existierende Implementierungen geflissentlich ignoriert werden.
Es gab Meetings diesbezüglich während GCDS, aber ich weiß nicht, was dabei herausgekommen ist.
Niemand lässt sich zu irgendetwas zwingen, schon gar nicht wenn der Prozess nicht transparent ist. Außerdem hört sich dein Vorschlag doch stark nach "Design by Committee" an. Das hat noch nie funktioniert.
Ich schrieb ja auch, dass das keine ideale Lösunug sei (w3c). Ich wollte nur darauf hinaus, dass das Problem nicht so einfach zu lösen ist.
Ich vermisse viel mehr ein Beispiel für die Behauptung, bisherige Specs wären für kleinere DEs schwierig zu implementieren oder übermäßig groß.
Freedesktop scheint hier so gut/schlecht zu arbeiten, wie jedes andere frei zusammengewürfelte Gremium auch.
Der wesentliche Punkt ist, dass Freedesktop.org kein Gremium ist, sondern eine Art Treffpunkt für Leute mit ähnlichen Zielen (Free Software Desktops und Applikationen).
Es können natürlich nur bekannte Anforderungen berücksichtig werden, also solche, die von mitwirkenden Entwicklern vorgebracht werden.
1. Notiere Dir den ersten Teil des Passwort auf einen Zettel:
Den ersten Teil erstellst Du z.B. aus der url in Groß- und Kleinschreibung und dazu ein paar Zahlen Zahlen. Irgendetwas, was Du Dir ggf. auch unterwegs wieder zusammenreimen kannst. Dieser Passwortteil ändert sich immer wieder.
2. Der zweite Teil ist immer gleich. Diesen lernst Du auswendig und verrätst ihn niemanden. Dieser beinhaltet 3 Buchstaben und 3 Zahlen und ist Deine persönliche PIN, die Du dem ersten Teil immer anhängst.
Vorteile:
- Du kannst Dir Dein Passwort leicht merken.
- Dein Passwort ist eine Kombination aus Zahlen, Sonderzeichen, Groß- und Kleinbuchstaben
- Du kannst Dein Passwort auf einem Zettel notieren und trotzdem kann niemand damit etwas anfangen, weil Deine PIN geheim ist.
- Dein Passwort ist für jede Seite ein unterschiedliches
Also: Keine Namen mehr und nie mehr gleiche Passwörter. Vergessen geht auch nicht mehr. Und das Rausfinden ist sehr schwierig und langwierig.
Grüße
Z.B.
meine Seite ist www.boese.de
Und sein KW ist dann: boese123qwe
dann probiere ich mal bei Ebay ebay123qwe, oder amazon123qwe....
Ansonsten ganz gute Idee...