liberforce a écrit 4730 commentaires

Intéressant, je n'étais pas au courant. Je me demande néanmoins si l'utilisation d'un n° de licence OEM avec ces ISO est légale ou est juste une tolérance.

http://www.macieira.org/~thiago/qt-stats/current/qt-all-full.employer.absolute.png

Parce que toi tu trouves ça rassurant ? Si on enlève Nokia (en bleu sur le graphique), il reste quoi ? Les yeux pour pleurer ?

C'est un vrai problème. Mais le Shell est encore jeune, extensions.gnome.org n'a que 6 mois depuis sa mise en ligne publique en verssion alpha, et n'est toujours qu'en version beta. Le message est: il y a un remplaçant aux applets pour ceux qui veulent personnaliser leur Shell, mais c'est en beta parce que le Shell évolue encore trop rapidement pour figer les API. Tu ne figer l'API d'un logiciel que quand il a atteint un niveau de maturité suffisant, sinon le développeur va se retrouvé coincé s'il n'a pas tout prévu avant. Il faudra donc encore un peu de temps que le Shell se stabilise, et ensuite l'API sera rendue stable. Les extensions auront alors la vie plus facile pour un moment.

Le design de GNOME Shell n'avait pas de place pour les applets. Cela était vu comme un soucis, mais les releases sont time-based, pas feature-based. Les inconvénients de la sortie sans équivalents aux applets ont été jugés inférieur à ceux apportés par le report de GNOME 3.0, qui avait d'aileurs déjà été reporté.

Depuis il est possible de faire des extensions à GNOME Shell. Le réel problème que j'y vois est celui pointé ci dessous par Albert: celui de la stabilité des API du Shell, car les développeurs d'extensions n'auront pas une patience infinie si on casse tout tous les 6 mois. Cela n'est malheureusement pas près de changer pour l'instant (cf Jasper St Pierre, un des développeur du Shell, cette semaine au GUADEC).

Ton besoin est très particulier, et personne n'a écrit ce code pour toi. Tu dois pouvoir faire ça en 10 lignes de bash, cela sera complètement intégré à l'environnement si tu as une interface graphique à afficher en utilisant Zenity. Tu peux l'ajouter à ta barre de lancement d'applications avec alacarte, et l'utiliser conjointement à l'extension qui affiche l'état de la gestion de fréquence.

Mais ce que je constate, c'est que tu pourrais blâmer le constructeur de la machine, qui a mal fait son boulot, ou fournir un patch pour l'extension GNOME Shell concernée mais non, c'est mieux de blâmer GNOME.

Ça me rappelle quelqu'un en fait :-)

Faisons un sondage sur dlfp

Tu te rappelle de l'affaire du sondage dont GNOME n'a pas voulu et qui s'est retrouvé sur phoronix ?

Je ne comprenais pas au début pourquoi tout le monde envoyait bouler le gars. J'ai fini par comprendre en lisant les justifications: un sondage web ne représente que les visiteurs d'un site, pas tes utilisateurs. Les votants de ton site ne sont qu'un sous ensemble de tes utilisateurs, et selon le type d'audience du site, cela pourrait donner tout et son contraire. Tu as aussi ceux qui votent alors qu'ils n'utilisent pas le logiciel, etc. Bref, un sondage web, c'est tout sauf fiable.

Le mode fallback n'est pas fait pour ceux qui n'aiment pas GNOME Shell, mais pour ceux pour qui GNOME Shell ne fonctionnait pas (pas d'accélération graphique). Depuis qu'il y a un fallback logiciel via llvmpipe, il est censé fonctionner en environnement non accéléré (ex: une machine virtuelle). Je peux donc te donner une raison supplémentaire de détester GNOME 3: le mode fallback va disparaître à terme.

Sorti de cela, je sais que gnome-panel est toujours maintenu, donc j'imagine qu'il doit être possible de se passer du shell et récupérer gnome-panel, mais il a sans doute d'autres pièces du puzzle à récupérer.

Dans ce cas, 2 solutions: gérer cela à la source avec /sys, ou améliorer l'extension pour GNOME Shell. Se plaindre qu'un cas d'utilisation peu répandu (même s'il est important pour ceux qui l'utilisent) soit cassé à la sortie d'un nouveau logiciel, c'est compréhensible, mais pas juste pour autant.

Tu penses peut être qu'il aurait fallu ne sortir GNOME 3 qu'une fois toutes les applets existantes réimplémentées ? Ton use case n'est pas prioritaire par rapport à un autre.

En faisant cela, ton nouveau logiciel ne sortira jamais, ou sera complètement dépassé à sa sortie. Et sortir GNOME 3 pour faire la même chose (comprendre: de la même manière) que GNOME 2, l'intérêt aurait somme toute été limité. La fonctionnalité existe toujours, le kernel le permet toujours, c'est juste l'interface qui change.

GNOME sort tous les 6 mois. Cela aurait retardé la sortie de GNOME 3 de 6 mois de plus, avec des mainteneurs contraints de conserver une compatibilité GNOME 2 encore un peu plus longtemps, ce qui complexifie le code et la charge de travail. À un moment, il fallait que cela sorte, et il est clair que l'on compte sur la communauté pour remplir les vides sur des use cases si ceux ci sont considérés comme importants… Il n'y a pas 2 personnes avec les mêmes besoins, aussi extensions.gnome.org permet à chacun de configurer son système à l'envie.

Note que moi aussi il y a des choses qui me manquent. Par exemple je n'aime pas le comportement du Alt-Tab par défaut. Mais il y a plein de choses sur lesquelles je pense y avoir gagné. La question est donc: est-ce que les avantages sont supérieurs aux inconvénients ?

Bien répondu mais la lutte avec Mathew Garett est souvent inégale ;-)

Extrait de: http://www.codon.org.uk/~mjg59/power/good_practices.html

Some systems have poor cooling mechanisms and so may overheat under heavy CPU load. One common attempt to work around this is to limit the maximum speed of the processor in order to reduce its heat output. However, this prevents the processor from running at full speed even when it's not in danger of overheating. This will result in it taking longer for the CPU to enter idle states, ironically resulting in it becoming hotter than neccesary and consuming more energy.

Summary: If users need to perform thermal management of their systems, write an application that monitors the temperature and limits the CPU speed appropriately. Don't attempt to perform thermal management by using power management functionality to statically limit the processor frequency.

Que tu vas payer entre 15 et 45€. Pour un truc que tu avais déjà payé.

Les devs GNOME sont des utilisateurs comme les autres. Ils sont développeurs sur quelques applications, mais utilisateurs sur les autres. Le problème se situe plutôt sur le fait que les développeurs de Nautilus virent des fonctionnalités, sans se rendre compte que cela va mécontenter les utilisateurs, et donc sans prendre le temps de les préparer au changement (en le justifiant notamment).

À leur décharge, il faut bien que le boulot avance aussi, et la manière dont GNOME est géré a toujours laissé pas mal de liberté, et la décision finale au mainteneur, parce que, comme dans pas mal de projets libres, c'est une méritocratie. C'est celui qui fait le boulot qui a le dernier mot. Là où ça me pose problème, c'est quand on accepte un feature d'un contributeur il y a 1 ou 2 ans (la split view), et qu'on la vire maintenant. Il aurait mieux valu ne pas l'accepter dès le départ, parce que les contributeurs se sentent trahis, et ont l'impression d'avoir travaillé pour rien. Mais quand on voit la quantité de bugs qu'il y a dans Nautilus, l'application est devenue d'une trop grand complexité, et il y a plein de choses qui peuvent être externalisée et rendues communes à tout le desktop (notamment la recherche). Simplifier Nautilus pour qu'il ait un comportement prévisible est donc je pense une bonne chose, mais il faut pour cela réduire les use case et "rigidifier" l'interface. En gros, il faut que l'interface par défaut soit la bonne, sans proposer 15 000 options.

Quand ton seul outil est un marteau, tous les problèmes ressemblent à un clou. Le but c'est donc d'avoir des outils adaptés à chaque tâche. C'est pour cela que la recherche est rendue globale et poussée vers le shell, où tu pourras chercher tes fichiers, tes contacts, tes programmes.

Regarde comment se présente la boîte de téléchargement de Firefox, tu peux faire un clic droit et demander à ouvrir le dossier contenant ce fichier. J'imagine que c'est un peu vers ça que tend GNOME, et ton fichier sera visible dans Nautilus ou dans Documents.

Prenons les choses dans l'autre sens. Si on attend qu'un logiciel soit parfait pour commencer le boulot sur un autre logiciel qui en dépend, la super feature que tu attends sera dépassée le jour où tu l'auras entre les mains. Le seul moyen c'est donc de paralléliser, et corriger au fur et à mesure la direction. C'est de l'itératif, de l'approche et erreur, comme à peu près tout dans la vie puisque l'être humain fonctionne comme ça.

On peut tout à fait vivre sans panneau latéral avec une arborescence, même si je comprends la douleur de ceux qui l'avaient complètement intégré à leur workflow. Je me suis néanmoins toujours demandé comment on pouvait être efficace avec ce truc là, les gens passant 3 plombes à retrouver le dossier dans lequel faire le "copier", puis 3 autres plombes pour le "coller".

Et comment tu la récupères légalement cette ISO ? C'te bonne blague.

Ce que j'aime, c'est qu'à chaque version majeure, ont a les mêmes barbus qui crient au massacre. Quand GNOME 2 est sorti, les utilisateurs en colère criaient "rendez nous GNOME 1". Quelques années plus tard, si tu demandais aux gens s'ils voulaient passer sous GNOME 1, c'était hors de question. Là GNOME 3 est sorti il y a un an, on entend "rendez-nous GNOME 2!". Vivement GNOME 4, on entendra peut être les utilisateurs qui aiment GNOME 3. Les mécontents se font toujours plus entendre que ceux qui sont satisfaits.

Les gens n'aiment ni gnome3 ni le truc d'ubuntu, pourquoi l'orientation des bureaux va contre la majorité des utilisateurs?

Peut être parce que les gens ont souvent l'impression d'être dans le camp de la majorité des utilisateurs, alors que dans l'absolu, personne n'en sait rien, vu qu'il n'y a aucun chiffre ?

Peut être parce que parce qu'il y a de nouveaux utilisateurs chaque jour et que les gens qui ont dû faire l'effort d'apprendre à se servir d'une interface n'acceptent pas que les nouveaux arrivants ne triment pas comme eux ?

Peut être parce que les gens en général sont rétifs au changement et n'ont pas envie de réapprendre à se servir d'une autre interface, alors ils ne perçoivent pas forcément que ce qui est différent n'est pas fondamentalement mauvais ?

Tu ne pouvais pas choisir plus mauvais exemple. Cela fait des années que l'on sait que ce type de choix ne sert à rien. C'est au système d'avoir un comportement correct par défaut, et pas à l'utilisateur de devoir configurer un truc dont il devrait se foutre complètement, vu que tout ce qu'il veut, c'est que ça fonctionne.

Blâmer un logiciel de ne pas te fournir une interface pour pourrir sa configuration par défaut, ça me parait un peu limite… Surtout que le power user qui tient absolument à avoir cette possiblité doit être capable de scripter un echo de la valeur qui va bien dans /sys.

Pas sûr. La différence de confort entre un vrai clavier et un clavier virtuel est quand même assez énorme, donc les gens habitués à un vrai clavier auront peut être du mal. Mais avec les jeunes, qui s'adapteront plus vite à ce changement, cela pourrait je pense menacer le laptop.

Que de conditionnel. Bon, en fait, c'est sûr que sans les commentaires live de la présentation, c'est un peu dur de se faire une idée.

Ce qui est vrai: le constat. Le monde du desktop a une grosse concurrence en face, et les appareils mobiles ont pris de plus en plus de place. De plus, tous les développeurs d'applications ne sont pas forcément fan ni d'Androïd ni d'iOS.

Le rachat de Motorola par Google ne simplifie pas le marché mobile (Google devient un concurrent direct de ses partenaires d'hier fabricants de matériel). Nokia semble aussi arriver à un rapprochement avec Microsoft tel qu'il y a aussi de rumeurs de rachat. Le constat c'est donc que oui, on ne peut plus trop développer uniquement pour le desktop, et que ne pas évoluer, c'est risquer de disparaitre.

Maintenant il faut comprendre aussi comment se passe un GUADEC et comment sont prises les décisions. Les développeurs qui ont fait la présentation font en général un état des lieux, et explorent des pistes. Le fait que cette présentation soit au début du GUADEC a été complètement intentionnel: le but est de jeter un pavé dans la mare, afin que les gens qui sont présents au GUADEC se réunissent et prennent des décisions quant à la direction du projet. Ce qui est pris comme des affirmations est donc à prendre avec de grosses pincettes, tout bonnement parce qu'il n'y a pas eu d'annonce officielle, et que GNOME est une communauté, et qu'il faudra bien que tout le monde rame dans le même sens pour avancer.

En off, il se dit plutôt que GNOME a raté le train des tablettes, que pour développer pour le mobile il faudrait déjà avoir du matos sur lesquels les développeurs pourraient programmer et déboguer…

Un autre soucis actuel de GNOME est le manque de leadership, et de décisionnel. Qui dirige le projet ? Le board de la Fondation GNOME ? La release team ? La design team ? En fait jusqu'à présent c'est plutôt personne. D'où des réunions cette semaine. Les dernières nouvelles c'est plutôt que la release team dont le but pour l'instant est de s'assurer que le projet est capable de livrer quelque chose tous les 6 mois, de qualité acceptable, pourrait avoir des super-pouvoirs supplémentaires.

GNOME OS est encore dans les cartons, certains chez Red Hat ont l'air de pousser un peu plus dans ce sens, mais ça reste tout de même encore globalement flou. Énoncer des dates et des développements futurs, c'est tenter de donner corps à une vision d'ensemble, et rendre ces visions réalité. C'était le cas déjà quand GNOME 3.0 a été annoncé lors d'un GUADEC, mais c'était alors par un membre de la release team, afin que le projet commence à prendre vie, quitte à ce que la sortie soit reportée (ce qui a été le cas). Mais pour l'instant ce sont surtout des voeux pieux, et des moyens de dire à la communauté "il font qu'on se sorte les doigts du cul et que l'on décide de ce que l'on veut faire". Prenons une décision.

Pour ce qui est de l'abandon du desktop, je t'avoue que les échos de la réunion de la release team de ce matin, c'est plutôt que la cible priviégiée c'est plutôt du laptop, tout en restant accessible en tactile. On est encore loin de ton téléphone ou ta tablette, mais on est aussi loin d'abandonner ton desktop. On attend néanmoins des réponses officielles aux questions posées lors de ce GUADEC.

C'était liberforce, en direct du GUADEC A Coruña. A vous les studios.

Ah flûte, difficile de mettre un R et un Z… J'ai pris le 4 pour le R, mais c'est pour le A, suis-je bête. 62052OB1 nous donne donc approximativement: groszobi. Merci pour lui.

Merci pour les progrès. Je me demandais aussi si la gestion du choix ogg/mp3 se faisait correctement. Concrètement, j'ai testé sur l'iPad d'un pote, et ça marchait pas, alors que l'iPad sait lire le mp3, et que j'avais décoché les cases de gestion du ogg dans jplay…

Si décoche ces cases, il y a un message juste au dessus disant qu'il faut recharger la page pour que la modification prenne effet. Mais si on la recharge, les cases réapparaissent cochées.

Pour rétablir la parité, je propose d'adopter 0x640520B1.

Mes appels à make n'échouent pas.

Je suis Chuck Norris et j'approuve ce message !

Et pour 0xDEADDEAD, c'est les zombies qui vont faire la gueule. Si on veut se sentir offensé, on peut toujours trouver une raison.

Je propose: make && zenity --notification --text="Compilation terminée"

Après, les notifications sonores, c'est bien aussi…

Clairement, c'est de mauvais goût, clairement, ce serait mieux de l'enlever, mais de là à faire un tel barouf on a un peu l'impression de lire Closer, là… Si OxB16B00B5 est offensant pour les femmes et 0xDEADBEEF pour les indous, il va pas rester grand chose comme constante mnémotechnique hexadécimale.