Login
Newsletter

Thema: Wie lange sind Sie schon bei der gleichen Distribution?

2 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
2
Von Jürgen Sauer am Sa, 15. Dezember 2012 um 09:14 #

:oops:

Das finde ich ja so komisch. Da gibt es die einen, die ständig Probleme mit KDE-Programmen haben, und andere, die gar nicht nachvollziehen können, wovon die "Betroffenen" reden.

Das liegt an einem Qualitätsmangel im Testverfahren des KDE, das ist einfach nur "schlampig" zu nennen.

Die Gründe, weshalb viele User, besnders im Unternehmensumfeld, mit KDE Programmen Probleme haben ist, das nicht mehr "multi-user" getestet wird. Wir erinern uns, daß ist das Kernfeature #1 aller Linux Installationen.

KDE ist besonders nicht mehr "multi-user" sondern nur noch Single User.

Hat ein Unternehmen eine Zentrale Server Archtektur, von welcher das /home Verzeichnis via NFS gemountet wird (Standard Setup!) dann versagen die zentralen Dienste im KDE, wie Nepomuk und akonadi Ihren Dienst komplett.

Es kommt sogar zu reproduzierbar wiederkehrenden Datenverlusten und SERVER-DDOS gegen den /home NFS Server.

Im Verzeichnis $HOME/.local/ liegen die embedded MySQL Datenbanken von einigen Programmen, wie Akonadi und Nepomuk.

Loggt sich ein $USER mal von einer anderen Client Maschine synchron ein, zerstört sich die Akonadi und Nepomuk embeded Datenstruktur!

Ergebnis ist das nun 2 Knoten anfangen wie irre CPU, Bandbreite und NFS Serverresourcen zu fressen bis zum abwinken des NFS Server (quota stop) oder falls da nun mehr als 2 Clients oder 3-4 User betroffen sind, dann ist das gesammte Netzwerk Segment TOT, 100% Bandbreite werden dann sinnlos "gefressen".

Die für Unternehmen zwingenden Features "Kontact" und die Dateisuche kann man nicht mehr nutzen, oder installieren.

Das Layout, das Engennering, die Software Architektur nenne ich - und ich denke mal zu recht - nur SCHLAMPIG.
Ins $HOME dürfen keine Datenbanken, die das Desktop direkt und unmittelbar schreibend braucht. Diese werden ja sofort geschrieben und somit zerstört, sobald es wirklich mal zu einem Multiuser Zugriff kommt! Genau das ist ja unter Linux eine der Design Funtamentale!

Die Entwickler die man auf dieses Problem hinweist tun in Ihrer Arroganten Hybris Sphäre einfach: Nichts!

Ich vermute mal, die Test finden auf dem "Entwicklernotebook" solo statt. Da kann man solche Probleme ja auch nicht nachvollziehen!

Ein Workaround wäre dieses Xsession.d Script:


$ cat /etc/X11/Xsession.d/95xdg-axs
#!/bin/sh
# http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
# $XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

# Lokales Verzeichnis am besten nach /var/tmp/$USER
LOCAL="/var/tmp/$USER"
CONFIG="$LOCAL/config"
DATA="$LOCAL/share"
test -d "$LOCAL" || mkdir -p "$LOCAL"
test -d "$CONFIG" || mkdir -p "$CONFIG"
test -d "$DATA" || mkdir -p "$DATA"

# Existiert $HOME/.config ? => Hinein Syncen
STDCFG="$HOME/.config"
# test -d "$STDCFG" && rsync -au --delete-excluded --exclude chromium/SingletonCookie --exclude chromium/SingletonLock chromium/SingletonSocket "$STDCFG/" "$CONFIG/"


$XDG_DATA_HOME => $HOME/.local/share
STDDAT="$HOME/.local/share"
test -d "$STDDAT" && rsync -au --delete-excluded "$STDDAT"/ "$DATA/"

rm -f $CONFIG/chromium/Singleton*

export XDG_CONFIG_HOME="$CONFIG"
export XDG_DATA_HOME="$LOCAL"

Jürgen
PS: Schönes Wochenende

Pro-Linux
Traut euch!
Neue Nachrichten