nud a écrit 898 commentaires

On fait pas, on va dans l'overview?

L'idée c'est de faire une UI adaptée aux deux, pas une UI uniquement orientée tablette.

Note que pour profiter du WM, tu peux utiliser Left, Right et Up pour maximiser à gauche, à droite ou complètement.

J'avouerai sans peine qu'au jour le jour j'ai plus tendance à utiliser deux instances de nautilus que le split view, sans trop savoir pourquoi. Mais j'ai déjà eu des problèmes de confusion vis à vis du focus.

En même temps, je me fais l'avocat du diable ici, mais il ne s'agit que d'un commit dans une branche de développement. Il n'est pas dit que le commit qui implémente le truc génial ne va pas arriver avant la prochaine version stable, donc en pratique on ne peut pas encore parler de suppression de fonctionnalité sans meilleure alternative.

'faut pas confondre non plus la boite xamarin qui a été fondée par un type qui ne contribue plus à gnome depuis des lustres et gnome qui ne contient plus rien en mono (sauf peut-être tomboy qui peut être remplacé par gnote sans perte de fonctionnalité).

Je ne crois pas que mono dans gnome soit encore d'actualité.

IL EÛT ÉTÉ AMUSANT D'AVOIR UNE ALTÉRATION DE LA CSS PAR DÉFAUT DE LINUXFR.ORG POUR L'OCCASION. UN SIMPLE *{TEXT-TRANSFORM:UPPERCASE} EN CSS DEVRAIT ÊTRE SUFFISANT…

À COGITER POUR LE 22 OCTOBRE PROCHAIN?

OU DU PHP, LES FONCTIONS BUILT-IN SONT INSENSIBLES À LA CASSE.

Le plus souvent, quand on a un gros déploiement à faire, les switches et la plupart des routeurs arrivent avant les connexions internet… Et déjà, faut configurer le routeur pour qu'il puisse se connecter à Internet via ADSL, VDSL ou n'importe quoi d'autre.

Ensuite, je n'ai pas lu le lien, mais ça implique que toutes les adresses mac qui se connectent, etc, sont envoyées sur le "cloud" pour la consultation des statistiques des ports, etc? Est-ce que cela requiert que Cisco puisse se connecter directement chez tout un chacun ? Voilà qui va poser des problèmes avec les politiques de sécurité des grandes boites (comme des petites si elles savaient).

Peut-être un succès aussi retentissant que la Cisco Cius ?

Ça dépend probablement de la définition de power-user.

On appelle ça la casse.

Au cœur même de la philosophie GNOME, il y a l'idée d'avoir tout ce qu'il faut pour bosser sans jamais ouvrir un terminal. Je ne dis pas qu'ils ont tout à fait réussi sur ce point, juste que GNOME n'est pas/plus fait pour les power user, point barre. Madame Michu (TM) se tape complètement de savoir quel est son système d'init.

Je pense que beaucoup de power users ne passent pas leur temps à tweaker leur système. Pour ma part quand j'avais 16 ans je pouvais passer beaucoup de temps à chipoter. Maintenant, je veux un système qui juste marche.

sudo est setuid 0.

Probablement un oubli de l'outil, DBus permet de gérer les erreurs de façon tout à fait satisfaisante pour un protocole d'IPC.

Je suis d'accord avec ton commentaire sauf sur un point: je ne comprends pas pourquoi tout le monde dit que dbus n'existe pas sur les autres unix alors que cela fonctionne en fait sur tous les unix qui proposent gnome 2.12+ ou kde 4+ (c'est une dépendance hard des deux environnements de bureau)… Même sur OpenBSD 4.9…

Justement, le problème c'est que tout est différent et que tout qui veut modifier ces paramètres doit avoir du code spécifique pour chaque distro (cf system-tools-backend).

Le principe de passer à un service dbus, c'est:

• soit tout le monde utilise le même fichier comme prôné par systemd
• soit la distro maintient elle-même la série de mini-démons qui va modifier ses fichiers de config à elle qui sont différent de toutes les autres distros pour sans doute une très bonne raison.

Dans tous les cas cela ne change pas grand chose à la situation antérieure, si ce n'est que la maintenance des bouts de code spécifiques à une distro seront maintenus par la distro en question plutôt qu'upstream où ils ont toujours été mal maintenus de toute façon (par manque d'intérêt ou d'implication des distros "mineures")

Et je rappelle par ailleurs qu'un "démon dbus" ne veut pas dire un process qui tourne en permanence, mais un process activé par dbus, qui fait son office puis se termine grâce au bon vieux exit(3).

Ça fait des années que tu utilises udev. Vas-tu arrêter parce que les sources ont migré dans le même dépôt git que systemd ? Ou vas-tu te sentir obligé d'utiliser systemd ?

Je parlais évidemment du jour 0 du protocole dbus.

Si je parle de la France et que je parle du jour 0, je ne parlerai évidemment pas du big bang.

La plupart des gens préfère quand même avoir la même timezone pour toutes les sessions d'un même ordinateur (graphique ou tty) et pour tous les utilisateurs…

C'est même tout le principe de dbus-activation, qui est là depuis le jour 0.

Changer de fuseau horaire ça se fait en fixant la variable d'environnement TZ des processus concernés. Aucun privilège nécessaire.

Le but c'est quand même que le changement soit sauvegardé et persistant au reboot. C'est pourquoi system-tool-backends a une implémentation différente pour chaque distro parce que chacun stocke la timezone d'une façon différente.

sortir systemd pour ces conneries

C'est inexact. Gnome a sorti la nouvelle API dbus définie par freedesktop.org pour changer l'heure (via policykit d'ailleurs il me semble), API qui n'est pour l'instant implémentée que par un petit programme de 1000 lignes qui se trouve dans le repository de systemd, à côté de systemd, d'udev et d'autres petits programmes du même genre.

C'est juste une façon d'utiliser les bons outils (policykit, et donc dbus) plutôt que des outils d'un autre âge (system-tools-backend et des scripts shell). Notez encore une fois que la nouvelle dépendance est une dépendance sur une API (triviale de surcroît), mais pas sur systemd proprement dit.

Le premier problème, c'est que les codes propres à chaque distro ne sont implémentés généralement que pour fedora, debian et parfois opensuse. C'est pourquoi changer le serveur NTP depuis Gnome n'a pour ainsi dire jamais fonctionné avec, disons, ArchLinux.

Non, il fait aussi l'équivalent d'inetd (càd ouvrir les ports et lancer le service lorsque quelqu'un se connecte dessus) et le fait aussi pour les sockets unix. Ça permet de tout lancer sans réfléchir et de laisser les IO bloquantes ordonancer tout pour toi.

Non. Le service est activé, répond, puis exit(). Ça ne prendra pas plus de ressources qu'un system(/sbin/script-qui-fait-la-même-chose).

Le fait d'avoir une API DBus c'est intéressant pour les développeurs desktop, il suffit de regarder le code de liboob et des anciens system-tools pour s'en rendre compte (appels fragiles à sudo/su, spécificités pour chaque distro, plein de trucs pas implémentés pour plein de distros comme… arch).

Après l'API DBus de systemd est utilisée parce que c'est la première à être là (ou en tout cas à être connue des développeurs). Chaque distro peut implémenter ces API comme elle l'entend, sans utiliser systemd pour autant (c'est la route suivie par Debian il me semble).

la traditionnelle ảnh

C'est une photo traditionnelle ? Pour moi la délicieuse personne sur cette photo porte une Áo dài ;-)

Sinon, simple curiosité, quelle méthode utilises-tu pour apprendre le vietnamien ?