service d'identification , conçu pour unifier la connexion des utilisateurs à divers sites de projets KDE. MyKDE a remplacé le système d'authentification unique Identity.kde.org, qui a été implémenté comme un simple module complémentaire PHP sur OpenLDAP. La raison de la création du nouveau service est que Identity.kde.org est lié à des technologies obsolètes qui interfèrent avec la mise à jour de certains autres systèmes KDE, ainsi que d'autres. , comme un processus manuel de suppression de comptes fastidieux, des délais très longs avant de terminer l'inscription (jusqu'à 30 secondes), une mise à l'échelle inefficace des groupes, des mesures trop maladroites contre le spam.
MonKDE en Python en utilisant le framework et le module Django . MySQL est utilisé pour stocker les comptes. Le code MyKDE est un fork du système , distribué sous licence GPLv3.0. En plus d'organiser la connexion à MyKDE, le support des profils publics est également implémenté, ce qui permet, si l'utilisateur le souhaite, de rendre visibles certaines informations le concernant aux autres participants, comme son nom complet, son avatar, la liste des projets et les liens vers réseaux sociaux et site internet personnel.
Actuellement, le système d'identité MyKDE peut déjà être utilisé pour se connecter au wiki KDE et sera bientôt adapté pour se connecter à d'autres sites du projet. Les comptes Identity.kde.org existants, ainsi que les informations sur les associations de groupes, seront automatiquement transférés la première fois qu'un utilisateur se connectera via MyKDE. L'enregistrement de nouveaux comptes est désactivé pendant la migration, mais l'utilisateur peut s'inscrire sur l'ancien site Identity.kde.org et il sera transféré lors de la connexion via MyKDE. Une fois la période de migration terminée, les comptes non migrés seront gelés.
De plus, on peut noter un mécanisme facultatif qui vous permet de lancer le bureau KDE Plasma à l'aide de systemd. Il est à noter que l'utilisation de systemd vous permet de résoudre les problèmes de configuration du processus de démarrage - le script d'initialisation standard comprend des paramètres de fonctionnement strictement définis qui ne permettent aucune variation. Par exemple, il n'existe aucun moyen de démarrer krunner avec différentes variables d'environnement, de contrôler l'allocation des ressources système, d'ajouter un script personnalisé qui s'exécute au redémarrage du shell ou d'afficher la boîte de dialogue de configuration initiale après le chargement de kwin mais avant de démarrer Plasma. Le script actuel nécessite une édition de code pour un tel changement, et systemd fournit des outils prêts à l'emploi pour s'adapter à vos besoins, à la fois pour les développeurs de distribution et pour les utilisateurs finaux.
Un fichier cible a été préparé pour être exécuté sous systemd
plasma-workspace.target et un ensemble de services pour lancer divers sous-systèmes KDE. La prise en charge de l'ancien mécanisme de démarrage automatique (/etc/xdg/autostart ou ~/.config/autostart) reste inchangée, grâce à l'utilisation du mécanisme de génération automatique de services introduit dans (sur la base des fichiers .desktop, les services systemd correspondants sont automatiquement créés). Le code implémenté devrait être inclus dans la version KDE Plasma 5.21. Par défaut, l'ancien script sera enregistré, mais à l'avenir, après avoir testé et analysé les retours, il est possible qu'il soit activé par défaut. Pour passer au démarrage basé sur systemd et afficher l'état de démarrage, vous pouvez utiliser les commandes :
kwriteconfig5 --file startkderc --group Général --key systemdBoot true
systemctl --statut de l'utilisateur plasma-plasmashell.service
Source: opennet.ru