Dash-to-Dock benutze ich so, dass das Dock schon versteckt ist, aber auch eingeblendet wird, wenn ich mit der Maus an der linken Bildschirmrand fahre, statt wie standardmäßig nur in der linken oberen Ecke, und ich lande nicht in der Aktivitätenübersicht, wenn ich die gar nicht brauche. Ich sehe nicht, warum das ein massiv anderes Paradigma wäre.
Was mir an der GNOME Shell so gut gefällt, sind einerseits die dynamischen Arbeitsflächen (ein Desktop, der sowas nicht hat, will ich nicht mehr), die schnelle Übersicht über die geöffneten Fenster und das man alles per Suche erreichen kann (viel schneller als sich durch ein Menü durchzuklicken). Natürlich kann man sich alles so anpassen, wie man es gerne hat und jeder hat seinen eigenen Geschmack, aber ich finde, man sollte neue Konzepte zumindest mal ausprobieren statt für alle Ewigkeit an ggf. ineffizienten alten Konzepten festzuhalten.
Ich verstehe auch nicht, warum die Menschen immer gleich so dramatisch werden, dass GNOME den Benutzern irgendwas "aufdrücken" will dass "völlig unbenutzbar" ist etc. Niemand wird zu irgendetwas gezwungen und wem etwas nicht gefällt der nimmt halt was anderes.
Zu Ihrem letzten Absatz eine kleine Anekdote: Obwohl ich als Laie die Technik dahinter nicht ganz raffe, hat GNOME bzw. einige Komponenten seit der Nutzung gewisser Middleware-Features (von DBus oder systemd) eine gewisse Eigenheit: So werden gewisse Anwendungen per DBus-Activation via systemd --user angestoßen, so z.B. das GNOME-Terminal. Das Problem ist, das die traditionellen Regeln der Vererbung der umask(2) der Sitzung nicht mehr greift, da dieses Konzept anders funktioniert als die bisherigen Sitzungsverwaltungen.
Es ist schon ein wenig her, sodass ich vermutlich einige Details vergessen habe. Mein Ziel war es, die die standardmäßig Einstellung für umask(2) zu ändern, sodass normale Nutzersitzungen (tty und GNOME) standardmäßig eine umask 0002 statt der üblichen 0022 nutzt. Das kann deshalb sinnvoll sein, um die Zugriffsrechte unter den Einzelnutzern eines Systems standardmäßig strikter einzuschränken - und das ohne den Nutzern die Eigene Kontrolle über diese Einstellung zu verwehren.
Dafür gibt es inzwischen unterschiedlichste Konfigurationspunkte, die alle unterschiedlich nuancierte Konsequenzen haben: /etc/profile, /etc/login.defs oder via PAM (distributionsspezifisch) mittels pam_umask(8), z.B. /etc/pam.d/common-session (Debian und Derivate). Letzteres war meiner Meinung nach die beste Methode für eine Systemweite Standardeinstellungsänderung, falls die Distribution PAM unterstützt (bspw. unterstützt Slackware PAM aus mir teils nachvollziehbaren Gründen bis heute nicht). Soweit so gut. Ändert man die PAM-Regeln entsprechend und startet eine neue GNOME-Sitzung samt GNOME-Terminal, so gibt ein umask(1p) weiterhin 0022 aus, obwohl mit dem traditionellen Verhalten 0002 zu erwarten wäre.
Die Überschreibung des UMask-Attributs einer entsprechenden Unit-Datei von systemd, z.B. dies des Login-Managers, Session-Managers oder DBus (Welche wäre korrekt?), hatte ich damals dann nicht mehr probiert und aufgegeben, da ich systemd noch nicht hinreichend durchdrungen hatte. Erst später las ich dann davon, dass sich das Problem so lösen lassen müsste.
Fakt ist, dass das neue Verhalten zwar dokumentiert ist, aber nur an der neuen Konfigurationsschnittstelle von systemd (Unit-Dateien). Die alten Konfigurationsschnittstellen wurden durch diese Eigenheit von GNOME de facto falsch oder unvollständig und damit unbrauchbar oder mindestens irreführend.
Ich finde, dass soetwas gewaltig nervt, gerade wenn man sich ernsthaft bemüht. Und nein, ich finde diesen Anwendungsfall, bzw. die Unterstützung dieser Konfiguration nicht besonders speziell, zumal sie zuvor jahrelang einwandfrei funktionierte, und bis heute keine vernünftigen Hinweise oder Dokumentation existiert bzw. angepasst wurde.
In diesem Sinne kann ich einige Menschen in Ihrer Einstellung zu GNOME >=3.x schon verstehen.
Hattet Ihr ähnliche Erfahrungen?
Disclaimer: Das soll keine Hasstirade gegen GNOME, systemd oder DBus sein. Diese Projekte sind in tolles Geschenk und enorm nützlich. Leider gehen solche Dinge dann häufiger unter.
Quellen: Fast alle hilfreichen Kommentare und Querverweise finden sich in den Antworten dieser Frage, insbesondere aber jener. Unter den Querverweisen befinden sich auch welche auf Fehlerberichte, die leider bis heute vor sich hinschimmeln...
Das ist natürlich sehr nervig, da gebe ich dir Recht. Mich stört es allgemein unter Linux, dass die Konfigurationsoptionen so verstreut und uneinheitlich sind. Es gab immer wieder Ansätze, das in den Griff zu bekommen, wie YaST von Suse, oder die deklarative Konfiguration von NixOS, oder eben auch systemd mit seinen Unit-Files, aber leider führt das dann oft dazu dass man parallel alles konfigurieren muss.
Besonders schlimm ist ja Netzwerkkonfiguration. Auf dem Desktop hat sich ja zum Glück der NetworkManager durchgesetzt, aber auf dem Server gibt es je nach Distribution eine eigene Methode, /etc/network/interfaces bei Debian, netplan bei Ubuntu, wicked bei Suse, netctl bei Arch, und es gibt natürlich noch systemd-networkd, und wenn man ganz viel Pech hat, überschreibt irgendein Tool die Konfiguration eines anderen Tools. Yeah!
Dash-to-Dock benutze ich so, dass das Dock schon versteckt ist, aber auch eingeblendet wird, wenn ich mit der Maus an der linken Bildschirmrand fahre, statt wie standardmäßig nur in der linken oberen Ecke, und ich lande nicht in der Aktivitätenübersicht, wenn ich die gar nicht brauche. Ich sehe nicht, warum das ein massiv anderes Paradigma wäre.
Was mir an der GNOME Shell so gut gefällt, sind einerseits die dynamischen Arbeitsflächen (ein Desktop, der sowas nicht hat, will ich nicht mehr), die schnelle Übersicht über die geöffneten Fenster und das man alles per Suche erreichen kann (viel schneller als sich durch ein Menü durchzuklicken). Natürlich kann man sich alles so anpassen, wie man es gerne hat und jeder hat seinen eigenen Geschmack, aber ich finde, man sollte neue Konzepte zumindest mal ausprobieren statt für alle Ewigkeit an ggf. ineffizienten alten Konzepten festzuhalten.
Ich verstehe auch nicht, warum die Menschen immer gleich so dramatisch werden, dass GNOME den Benutzern irgendwas "aufdrücken" will dass "völlig unbenutzbar" ist etc. Niemand wird zu irgendetwas gezwungen und wem etwas nicht gefällt der nimmt halt was anderes.
Zu Ihrem letzten Absatz eine kleine Anekdote:
Obwohl ich als Laie die Technik dahinter nicht ganz raffe, hat GNOME bzw. einige Komponenten seit der Nutzung gewisser Middleware-Features (von DBus oder systemd) eine gewisse Eigenheit: So werden gewisse Anwendungen per DBus-Activation via
systemd --userangestoßen, so z.B. das GNOME-Terminal. Das Problem ist, das die traditionellen Regeln der Vererbung derumask(2)der Sitzung nicht mehr greift, da dieses Konzept anders funktioniert als die bisherigen Sitzungsverwaltungen.Es ist schon ein wenig her, sodass ich vermutlich einige Details vergessen habe. Mein Ziel war es, die die standardmäßig Einstellung für
umask(2)zu ändern, sodass normale Nutzersitzungen (tty und GNOME) standardmäßig eine umask 0002 statt der üblichen 0022 nutzt.Das kann deshalb sinnvoll sein, um die Zugriffsrechte unter den Einzelnutzern eines Systems standardmäßig strikter einzuschränken - und das ohne den Nutzern die Eigene Kontrolle über diese Einstellung zu verwehren.
Dafür gibt es inzwischen unterschiedlichste Konfigurationspunkte, die alle unterschiedlich nuancierte Konsequenzen haben:
/etc/profile,/etc/login.defsoder via PAM (distributionsspezifisch) mittelspam_umask(8), z.B./etc/pam.d/common-session(Debian und Derivate). Letzteres war meiner Meinung nach die beste Methode für eine Systemweite Standardeinstellungsänderung, falls die Distribution PAM unterstützt (bspw. unterstützt Slackware PAM aus mir teils nachvollziehbaren Gründen bis heute nicht).Soweit so gut. Ändert man die PAM-Regeln entsprechend und startet eine neue GNOME-Sitzung samt GNOME-Terminal, so gibt ein
umask(1p)weiterhin 0022 aus, obwohl mit dem traditionellen Verhalten 0002 zu erwarten wäre.Die Überschreibung des UMask-Attributs einer entsprechenden Unit-Datei von systemd, z.B. dies des Login-Managers, Session-Managers oder DBus (Welche wäre korrekt?), hatte ich damals dann nicht mehr probiert und aufgegeben, da ich systemd noch nicht hinreichend durchdrungen hatte. Erst später las ich dann davon, dass sich das Problem so lösen lassen müsste.
Fakt ist, dass das neue Verhalten zwar dokumentiert ist, aber nur an der neuen Konfigurationsschnittstelle von systemd (Unit-Dateien). Die alten Konfigurationsschnittstellen wurden durch diese Eigenheit von GNOME de facto falsch oder unvollständig und damit unbrauchbar oder mindestens irreführend.
Ich finde, dass soetwas gewaltig nervt, gerade wenn man sich ernsthaft bemüht. Und nein, ich finde diesen Anwendungsfall, bzw. die Unterstützung dieser Konfiguration nicht besonders speziell, zumal sie zuvor jahrelang einwandfrei funktionierte, und bis heute keine vernünftigen Hinweise oder Dokumentation existiert bzw. angepasst wurde.
In diesem Sinne kann ich einige Menschen in Ihrer Einstellung zu GNOME >=3.x schon verstehen.
Hattet Ihr ähnliche Erfahrungen?
Disclaimer: Das soll keine Hasstirade gegen GNOME, systemd oder DBus sein. Diese Projekte sind in tolles Geschenk und enorm nützlich. Leider gehen solche Dinge dann häufiger unter.
Quellen: Fast alle hilfreichen Kommentare und Querverweise finden sich in den Antworten dieser Frage, insbesondere aber jener. Unter den Querverweisen befinden sich auch welche auf Fehlerberichte, die leider bis heute vor sich hinschimmeln...
Das ist natürlich sehr nervig, da gebe ich dir Recht. Mich stört es allgemein unter Linux, dass die Konfigurationsoptionen so verstreut und uneinheitlich sind. Es gab immer wieder Ansätze, das in den Griff zu bekommen, wie YaST von Suse, oder die deklarative Konfiguration von NixOS, oder eben auch systemd mit seinen Unit-Files, aber leider führt das dann oft dazu dass man parallel alles konfigurieren muss.
Besonders schlimm ist ja Netzwerkkonfiguration. Auf dem Desktop hat sich ja zum Glück der NetworkManager durchgesetzt, aber auf dem Server gibt es je nach Distribution eine eigene Methode, /etc/network/interfaces bei Debian, netplan bei Ubuntu, wicked bei Suse, netctl bei Arch, und es gibt natürlich noch systemd-networkd, und wenn man ganz viel Pech hat, überschreibt irgendein Tool die Konfiguration eines anderen Tools. Yeah!
Ja, da gelobe ich mir wesentlich konsistentere Systeme wie die BSDs.
s/ge//
> Übersicht über die geöffneten Fenster und das man alles per Suche erreichen kann (viel schneller als sich durch ein Menü durchzuklicken).
Compitz?
Beispiel:
http://i.imgur.com/ktsw1QF.png