gnumdk a écrit 7509 commentaires

tu ne perds pas tes clients et ils sont repositionnés selon ta nouvelle configuration.

Depuis quand tuer un WM cause une perte de clients X11 ?

Et ca te gonfle pas qu'ils revalident l'ensemble des ACLs même quand tu rajoutes une connerie et que tu décoches partout ou c'est marqué récursif ?

Perso, même sur les serveurs Windows, je fais avec icacls parce qu'il fait ce que je lui demande.

Moi je dirais que vu que Active Directory a encore de beau jour devant lui, samba aussi…

Nan, ca a tjs été comme ca ;)

On veut que le dossier "compta" soit accessible en lecture/écriture pour le personne du groupe "compta" et le groupe "direction", et en lecture seule pour le groupe "finance" et le groupe "RH".

$ setfacl -m g:compta:rwx compta
$ setfacl -m g:direction:rwx compta
$ setfacl -m g:finance:r-x compta
$ setfacl -m g:RH:r-x compta

$ setfacl -m o::rwx production
$ setfacl -m g:interim:--- production

d'économiser de la batterie en utilisation de base et d'avoir de la puissance en
utilisation intensive

Sur quoi se base le changement ? En dehors des gamers, j'aimerai bien savoir pour qui une pauvre carte INTEL ne suffit pas…

Et encore, un gamer sur un laptop…

Euh, tout ce que tu demandes est possible avec les ACLs standards…

Par contre, les ACLs NTFS sont effectivement plus évoluée pour la raison suivante:
http://linuxfr.org/forums/linuxg%C3%A9n%C3%A9ral/posts/acls-posix-vs-acls-ntfs

Vous allez me dire que jamais au grand jamais vous n'avez taper une adresse ipv4 dans une console ?

Déjà, faut réussir à retenir l'ip du DNS par coeur, ensuite si t'es pas enregistré dans le DHCP, tu peux aussi rajouter l'ip temporaire que tu vas configurer sachant que tu ne dois pas entrer en conflit avec une machine du réseau, celle du routeur, …

Je dis pas qu'il faut pas migrer, je dis juste que c'est plus compliqué à appréhender et que les DSI freinent des deux pieds pour y passer sur les LANs. (Enfin, faudrait il déjà qu'il y ai de l'ipv6 sur les machines en ip publique…)

Ici, ca sera migration en IPV6 pour la partie frontal et IPV4 derrière pour le LAN…

Alors, je suis d'accord que c'est naze mais bon, ipv6 pose quand même un gros problème dans la vie de tous les jours: Qui est capable de connaitre une adresse v6 par coeur ?

D'ailleurs, j'avais pas vu mais Cinnamon n'est pas un fork de GNOME3 mais un fork de Gnome Shell.

Il est disponible ainsi que ses logiciels liés (Andromeda, qupzilla, cubebox, vaccum)

A noté quand même que "liés" est au sens openSUSE car ces logiciels ne font pas partis de Razor-qt.

Pas du tout, Canonical est arrivé bien après

Non, Mandriva c'est 2005. Et Mandrake était numéro 1 sur le desktop avant l'arrivée d'Ubuntu…

Est-ce prévu d'intégrer ça dans le calendrier du shell ?

Cette phrase n'a pas de sens :)

• Gnome-Shell, il me semble, ne supporte plus Xembed pour ses applications
• Le calendrier du shell est en js
• Cela existe surement déjà dans le calendrier du shell avec les anniversaires d'Evolution, non?

pour couler Mandrake avant que cette distribution ne prenne trop d'ampleur.

Mwai, enfin avec ou sans lui, j'ai quand même de grand doute sur le fait que Mandriva était en mesure de prendre de l'ampleur:
- Concurrence rude de la part de Canonical sur le desktop
- Concurrence rude de la part de Redhat et Suse sur les serveurs
- Outils de configuration à l'IHM peu conviviale (même combat chez Suse de ce coté là)

The reason for creating status notifiers, and why Canonical built their appindicator library on top of that technology, was because, quite simply, the XEmbed based system tray icons were broken. They did not lend themselves to a modern presentation, failed to provide a compelling answer for mobile/tablet/netbook form factors and lacked any mechanism to communicate vital metadata to the host visualization. I won't go into all the technical details here (others have covered them elsewhere in the past), but suffice it to say that the old XEmbed system was increasingly becoming a blocker and status notifiers were a big step in a better direction. When we started work on them, it was our goal for the very start to make them attractive to and useful for others so that we didn't accidentally create a "separate silo" technology.

http://aseigo.blogspot.fr/2011/03/collaborations-demise.html

Ellez, hop, un petit troll sur GNOME au passage:

"we wished there was some constructive discussion around it, pushed by the libappindicator developers; but it didn’t happen": I can't speak for the GNOME / libappindicator dev collaboration efforts, but KDE Plasma devs have been working with libappindicator devs for some time now. We don't always agree, but we do tend to get things done and share efforts along the way. In addition, there was a lot of communication about Status Notifiers on the freedesktop.org xdg list where good feedback was offered and the specification improved significantly as a result. So communication really can't be to blame here, at least not communication by those outside of GNOME.

Mandriva Class est l’une des plate-formes de e-learning les plus accessibles sur le marché.

Y'a quand même aussi italc http://italc.sourceforge.net/ même si le développement semble un peu mort :(

Mandriva Class, licence proprio j'imagine, non ?

En fait, j'ai dit une connerie: KDE et Unity utilise KStatusNotifierItem (protocole créé par KDE).

Je dirais donc que vu que KSNI/libindicator offre un fallback, autant coder un indicator qui est quand même bien moins crade comme solution.

KDE utilise DBusSystemTray mais reste compatible avec l'ancienne norme
Unity utilise les applications indicators mais reste compatible avec l'ancienne norme
Et je crois que Gnome-Shell ne supporte aucun des 3

Donc ce n'est pas une obligation de le porté vers les app indicators vu que ca rendrez le logiciel non supporté pour les autres envs.

Même pas de puce NFC !?!

Tant mieux, si ca pouvait retarder cette techno merdique et discriminatoire…

En effet, on entend de plus en plus parler de cela pour remplacer les cartes monéo mais quid des gens qui n'ont pas les moyens/l'envie d'acheter une portable High Tech…

Il faut appeler la methode reconfigure() du module kded via qdbus.

Ok, c'est bon…

Et tu as suivi toute le procédure sur le site kde-apps ? En particulier le choix du type de menu ?

qdbus org.kde.kded /modules/appmenu

donne quoi ?

icon-tasks disponible dans les kdeplasma-addons (donc officiel).

C'est utilisé par défaut sous Mageia d'ailleurs.

J'en profite (ca m'évitera de faire un autre journal plus tard) que les scripts dockmanager pour Kde et plus ont reçus quelques nouvelles applications en support:
http://kde-look.org/content/show.php/dockmanager-kde_and_extra?content=151511

Pour rappel ces scripts permettent à icon-tasks de proposer des actions contextuels ou des personnalisations aux lanceurs d'applications.

Et que fait exactement kded-appmenu?

plasma-widget-menubar était à la fois un plasmoid KDE et à la fois un Registrar dbusmenu (le truc qui vole le menu aux applications).

Problème, il vole la possibilité aux autres applications de récupérer les menus, krunner-appmenu utilise une astuce pour contourner le problème mais du coup ne sais pas récupérer les menu sans le plasmoid.

Kded-appmenu est aussi un Registrar dbusmenu et libkappmenu est la librairie qui permet aux autres outils (un plasmoid, krunner, what else) de demander à ce registrar les menus.