liberforce a écrit 4744 commentaires

Pour reformuler plus simplement: la popularité et la satisfaction sont deux choses complètement différentes.

Donc tu pars du principe que tous les utilisateurs d'ordinateurs savent qu'il existe autre chose que Windows ? Que tous sont capables d'acheter une machine sans payer Windows et installer autre chose ? On ne doit pas être sur la même planète…

L'éclairage publique bon sang ! Euh… wait !

C'est représentatif des utilisateurs de Debian, pas des utilisateurs de GNOME. En plus, tu compares les packages installés, pas les packages utilisés. Et pour finir, tu ne compares que les gens qui utilisent un environnement plutôt qu'un autre, mais qui te dit que tous les utilisateurs ont testé tous les environnement ?

De plus, pour un peu que tu aies deux environnements sur ta machine, dont un n'est jamais utilisé, les deux ont le même poids. Il faudrait donc compter les packages marqués "vote" et pas "installed":

installed is the sum of the four categories below:
vote is the number of people who use this package regularly
old is the number of people who installed, but don't use this package regularly
recent-ctime is the number of people who upgraded this package recently
no-files is the number of people whose entry didn't contain enough information (atime and ctime were 0).

Si on prend les packages utilisés régulièrement, alors je pense qu'il y a comme un soucis avec popcon, parce que les chiffres Xfce ne me paraissent pas crédibles.
http://qa.debian.org/popcon-graph.php?packages=gnome-panel%2C+gnome-shell%2C+xfce4&show_vote=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

Étonnamment, je prédis une envolée de Xfce dès la sortie de la prochaine stable. Il sera plus utilisé car sera l'environnement de bureau par défaut. Est-ce que le nombre d'utilisateurs est une mesure crédible de la satisfaction des utilisateurs ? Je ne crois pas, sinon Windows satisferait des millions de gens.

Mais est-ce que 48 ans c'est un peu jeune pour être bronsonisé ? Ça se discute.

Je me souviens que c'est ma calculatrice qui a passé le bac chimie. Merci les diagrammes de la saponification stockés dans la HP 48…

Apparemment il y a un léger overhead pour les fonctions inline, ce n'es pas strictement identique. Mais ça te donne de la vérification statique de type, et je trouve ça largement acceptable comme contrepartie.

En cas de doute tu peux optimiser cela. La GLib utilise les macros G_LIKELY/G_UNLIKELY comme front-end aux directives gcc idoines.

Du coup, un:

if G_UNLIKELY (f == NULL) return;

n'est pas moins clair ni performant, juste un poil plus lourd à écrire. Reste plus qu'à tester la version avec et sans pour son architecture, pour savoir si cela apporte quelque chose ou si la prédiction de branches de gcc est suffisante.

Ah mais je suis d'accord avec toi sur les assert, c'est juste que tu n'as pas dit que c'était pour une bibliothèque ;-).

Pour le has_data, je dirais que un popcorn_bag.has_data() est plus laid que popcorn_bag.is_empty(), même si effectivement, quand on écrit une application on a tendance à tester plus souvent la présence que l'absence de données (sauf dans les préconditions).

Si tu veux faire court en général:

au lieu de:

    unsigned char sf_has_data(SmallFifo * f)
    {
        if(f==NULL) return 0x00;
        if(f->count>0) return 0xEB; /* mes initiales \o/ */
        return 0x00;
    }

utilise plutôt:

    unsigned char sf_has_data(SmallFifo * f)
    {
        assert (f != NULL);
        return (f->count > 0);
    }

Tu pourras désactiver les assertions dans un build en mode release. Perso je fais plutôt des fonctions is_empty que has_data, je pense que c'est plus répandu. Ah, et tu gagnes un tout petit peu sur le return, mais tu n'as certes plus tes initiales :)

Mettons que tu as une structure qui contient un tableau d'octets, c'est une très mauvaise idée de le retourner par valeur. Tu vas te retrouver à copier toute la structure alors que tu aurais juste pu passer l'adresse d'une structure déjà allouée à remplir. Copier un pointeur (8 octets en 64 bits) est plus rapide que de copier beaucoup plus d'octets…

Mouais… Suis pas fan de retourner directement des structures… J'ai tendance à passer par adresse que par valeur, parce que ton truc ne marche plus le jour où tu retournes une grosse structure (enfin si, ça marche, mais c'est lent).

#include <assert.h>

void expmatch (char *s, char **debut, char **motif)
{
    assert (debut != NULL);
    assert (motif != NULL);
    *debut = s;
    *motif = s+3;
}

int
main (void)
{
    char *debut = NULL;
    char *motif = NULL;

    /* hop, on passe l'adresse du pointeur plutôt que son contenu */
    expmatch ("string", &debut, &motif);

    printf ("Chaîne entière : %s\nMotif recherché : %s\n", debut, motif);
    return 0;
}

Alors oui, dans le prototype, on voit du pointeur double, mais il ne faut pas avoir peur :)

Et pour bien comprendre les pointeurs, un petit cours avec Binky:
http://www.youtube.com/watch?gl=FR&hl=fr&v=6pmWojisM_E

Et pour bien lire les déclarations:
http://www.antlr.org/wiki/display/CS652/How+To+Read+C+Declarations
(et comme le lien a l'air un peu cassé:)
http://web.archive.org/web/20090318154941/http://www.antlr.org/wiki/display/CS652/How+To+Read+C+Declarations

Hum… Je pense que ce tu voulais dire c'est que ce journal a plutôt sa place dans les forums :-)

En même temps, GNOME 3 a justement supprimé l'affichage sur le bureau d'autre chose que le fond d'écran. Ils sont partis d'un constat simple: l'utilisateur de base a du mal à accéder aux fichiers sur le bureau s'ils sont derrière plein de fenêtres. En plus, suffit de voir le bureau d'utilisateurs de Windows: c'est souvent un gros bordel sans non, le fait que ce soit sous leurs yeux étant une excuse pour "j'ai pas besoin de ranger".

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.